TDC Group Responsible Disclosure Guideline


TDC Group have a wide range of services and that is dependent of even more devices, and even though we aim to keep them secure and up to date, skilled security researchers do find vulnerabilities.

Just as important as discovering security flaws is reporting the findings so that users can protect themselves and vendors can repair their products. Public disclosure of security information enables informed consumer choice and inspires vendors to be truthful about flaws, repair vulnerabilities, and build more secure products. Disclosure and peer review advance the state of the art in security. Researchers can figure out where new technologies need to be developed, and the information can help policymakers understand where problems tend to occur.

On the other hand, vulnerability information can give attackers who were not otherwise sophisticated enough to find the problem on their own the very information they need to exploit a security hole and cause harm. 

If you, as a skilled security researcher, discovers a vulnerability and prove it exploitable we would like to hear privately from you before public disclosure. This is what we understand as responsible disclosure.

TDC understanding of responsible disclosure
TDC understand the following guidelines as beeing responsible disclosure:
• Only TDC is notified of the vulnerability.
• The vulnerability report must conform to the guideline below.
• TDC is given 5 days to verify the vulnerability.
• TDC is given 90 days after the verification to mitigate the vulnerability.
• TDC will acknowledge the finder of the vulnerability in a public announcement.
• The security researcher will be kept informed during the process.

After these steps the security researcher can to disclose the vulnerability and the acknowledgement from TDC in public.

The responsible disclosure processes
After finding a vulnerability and reproducing the exploit follow these steps:
• Write a vulnerability report – see the content guideline below
• Encrypt the report with TDC SOC public key. The key Id and signature can be found at https://soc.tdc.dk/rfc2350.txt 
• Send the report to soc@soc.tdc.dk
• Please allow for us to qualify the report – Does it conform to the guideline below.
• You will be notified upon confirmation
• Allow us 5 days for verification of the vulnerability.
• You will be notified upon verification
• Allow us 90 days to mitigate the vulnerability.
• TDC will make a public announcement acknowledging your contribution.
• You will be notified and acknowledged.

You will be informed along the way and to a certain extend you will also be involved in the process.

Vulnerability report content guideline
The vulnerability report must contain all the information we need to reproduce exploitation of the vulnerability.
The information needed includes:
• Type of security vulnerability
• Exact details of the product/service concerned
• Clear and comprehensible description of the vulnerability and all information necessary to identify the affected system
• Potential exploitation of the vulnerability must be clearly verifiable, for example with step by step instructions, description of tools and artifacts used during discovery.
• Additional information such as PoC scripts, screenshots, HTTP requests etc.

And the vulnerability must be in scope. Out of scope vulnerabilities and defects are listed in the next section.

Out of Scope
The following types of vulnerabilities / defects are considered out of scope. We have no interest in hearing about them as we most likely already are aware or we have implemented means of mitigation: 
1. Reports from automated tools or scans
2. Issues without clearly identified security impact (such as clickjacking on a static website), missing security headers, or descriptive error messages
3. Missing best practices, information disclosures, use of a known-vulnerable libraries or descriptive / verbose / unique error pages (without substantive information indicating exploitability)
4. Speculative reports about theoretical damage without concrete evidence or some substantive information indicating exploitability
5. Forms missing CSRF tokens without evidence of the actual CSRF vulnerability
6. Self-exploitation (e.g., cookie reuse)
7. Reports of insecure SSL / TLS ciphers (unless you have a working proof of concept, and not just a report from a scanner such as SSL Labs) 
8. Our policies on presence/absence of SPF / DMARC records
9. Password complexity requirements, account/e-mail enumeration, or any report that discusses how you can learn whether a given username or email address has a TDC-related account
10. Missing security-related HTTP headers which do not lead directly to a vulnerability
11. Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user
12. Social engineering of TDC employees or contractors
13. Any physical attempt against TDC property or data centers
14. Presence of autocomplete attribute on web forms
15. Missing secure cookie flags on non-sensitive cookies
16. Denial of Service Attacks
17. Banner identification issues (e.g., identifying what web server version is used)
18. Open ports which do not lead directly to a vulnerability
19. Open redirect vulnerabilities
20. Publicly accessible login panels
21. Clickjacking
22. Content spoofing / text injection

This concludes TDC guideline for responsible disclosure.