TDC Group Responsible Disclosure Guideline


TDC Group utilizes a wide range of services that depend on and are delivered by many different components. Although we strive to keep them secure and up to date, skilled security analysts still discover vulnerabilities from time to time.

Discovering security vulnerabilities is paramount, but more important still is to report them when discovered, allowing users to protect themselves and vendors to repair their products. Public disclosure of security vulnerabilities empowers the informed consumer and enables vendors to fix issues, and subsequently release software updates. It also forces vendors to be more transparent regarding the flaws in their products. Together, public disclosure and peer review result in safer products for the consumer and advance security processes by allowing developers to figure out where new technologies need developing. The information can also help policymakers understand where problems tend to occur, and thereby set demands for vendors.

On the other hand, public disclosure of vulnerabilities can also give attackers, who were otherwise incapable of discovering these issues on their own, the very information they need to exploit security loopholes and cause harm.

If you, as a skilled security analyst, discover a vulnerability and prove its exploitability, we would like to hear privately from you, before disclosing it publicly. This is what we at TDC call Responsible Disclosure.

Guidelines for Responsible Disclosure

TDC’s understanding of responsible disclosure is summarized as follows:

• Only TDC should be notified of the vulnerability
• The vulnerability report must comply with guidelines set out in the section “Vulnerability report content guideline”
• TDC is given 5 days to verify the vulnerability
• TDC is given 90 days to mitigate the vulnerability following its verification
• TDC will publicly recognize your effort in discovering the vulnerability
• TDC will keep you informed throughout the process

Following these steps, you are welcome to disclose your findings and TDC’s recognition in public.

The responsible disclosure processes

Once you have discovered a vulnerability and proven its exploitability, you must 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
• TDC will check if the report complies with the guidelines below
• If yes, you will receive written confirmation
• Allow us 5 days to verify the vulnerability
• If verified, you will receive written confirmation
• Allow us 90 days to mitigate the vulnerability
• TDC will publicly recognize your contribution in a press release

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 required to reproduce exploitation of the vulnerability:

• The type of security vulnerability
• The exact details of the product/service concerned
• A clear and comprehensive description of the vulnerability and all information necessary to identify the affected system
• Potential exploitation of the vulnerability must be clearly verifiable and replicable, for example through step-by-step instructions, description of tools and artifacts used during discovery
• Additional information such as PoC scripts, screenshots, HTTP requests etc.

Additionally, the vulnerability must be in scope to warrant our investigation. Out of scope vulnerabilities and defects are listed in the following section.

Out of Scope vulnerabilities

The following types of vulnerabilities / defects are considered out of scope since we most likely are already aware of, or, have implemented the necessary means to mitigate:

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