TDC Group Responsible Disclosure Guideline


TDC Group har en lang række ydelser, som  leveres igennem og er afhængige af endnu flere komponenter. Selvom det er vores hensigt at holde alle komponenter "up to date" finder trænede sikkerhedsanalytikere til tider sårbarheder i komponenterne.

Det er vigtigt, at dygtige sikkerhedsfolk leder efter sårbarheder, men endnu vigtigere er, at disse sårbarheder deles med offentligheden, så de ansvarlige kan tage deres forholdsregler og leverandøren kan udbedre den. Offentliggørelse af sårbarheder "Public Disclosure" gør den kyndige forbruger i stand til at forholde sig til sårbarheden og gør leverandøren i stand til at rette softwaren i enheden og udsende en sikkerhedsopdatering. Det tvinger dem også til at forholde sig ærligt til deres produkters svage sider. Det fører til mere sikre produkter for forbrugerne og giver produktudviklerne mulighed for at løse de sikkerhedsproblemer, som ny teknologi introducerer. Offentliggørelsen af sårbarheder hjælper også beslutningstagerne til at forstå både muligheder og  begrænsninger i de forskellige teknologier, og sætter dem i stand til at stille krav til leverandørerne. 
På den anden side giver offentliggørelsen af en sårbarhed også mulighed for, at den kan udnyttes af personer med dårlige hensigter, som aldrig selv ville kunne opdage og gennemskue sårbarheden.

Hvis du som en dygtig sikkerhedsanalytiker opdager en sårbarhed og kan fremvise en metode hvorpå den kan udnyttes, så vil vi meget gerne høre fra dig inden du offentliggør dit fund. Det kalder vi i TDC for reponsible disclosure (ansvarlig offentliggørelse).

TDC's forståelse af responsible disclosure
TDC's opfattelse af responsible disclosure kan opsummeres i følgende guideline
• Kun TDC informeres omkring sårbarheden
• Sårbarhedsrapporten overholder retningslinjerne angivet i afsnittet "Retninglinjer for sårbarhedsrapport"
• TDC tillades fem dage til at verificere sårbarheden
• TDC tillades 90 dage efter verifikation til at udbedre/imødegå sårbarheden
• TDC anerkender din indsats, som finder af sårbarheden i en pressemeddelelse
• TDC holder dig informeret under hele processen
Efter disse skridt er du, som sikkerhedsanalytiker, frit stillet i forhold til offentliggørelse af sårbarheden og TDC's anerkendelse af din indsats.

Responsible disclosure processen
Efter du har fundet sårbarheden og vist at den kan udnyttes, skal du gøre som følger:
• Skriv en sårbarhedsrapport - se retninglinjerne nedenfor.
• Krypter rapporten med TDC SOC's offentlige PGP nøgle. Nøgle id og signatur kan findes på https://soc.tdc.dk/rfc2350.txt.
• Send den krypterede rapport til soc@soc.tdc.dk.
• Tillad TDC at sikre at rapporten overholder nedenstående retninglinjer.
• Du vil herefter modtage en bekræftelse.
• Tillad TDC fem dage til at verificere sårbarheden.
• Du vil få besked omkring vores verifikation.
• Tillad TDC 90 dage til at imødegå sårbaheden. Dette sker i tæt samarbejde med vores underleverandører og du vil muligvis blive inddraget i dette forløb.
• TDC vil offentliggøre rettelsen af sårbarheden og anderkende dit bidrag i en pressemeddelelse.
Du vil løbende holdes orienteret i den 90 dages periode. Du vil som tidligere nævnt kunne blive involveret i selve arbejdet med at imødegå sårbarheden.

Retninglinjer for en sårbarhedsrapport 
En sårbarhedsrapport skal indeholde alle de informationer der er nødvendige for at  TDC kan eftergøre udnyttelsen af den.

Den nødvendige information inkluderer:
• Typen af sårbarhed
• Nøjagtige detaljer omkring den enhed/service det drejer sig om.
• Klar og omfattende beskrivelse af sårbarheden og al information nødvendigt for at identificere berørte systemer.
• Udnyttelsen af sårbarheden skal kunne eftergøres, gerne med en "step by step" guide, samt en beskrivelse af de nødvendige værktøjer.
• Yderligere dokumentation i form at Proof of Concept scripts, screenshots, HTTP forespørgsler etc.

Det er vigtigt, at du sikrer dig at sårbarheden ikke er på listen over sårbarheder som er "Out of Scope", som kan ses i næste afsnit.

"Out of Scope" sårbarheder
De følgende sårbarheder anses for at være "out of scope" i forhold til denne procedure. Vi er højst sandsynligt allerede klar over dem og har allerede taget de nødvendige forholdsregler imod dem. (Listen er på engelsk, da det er meningsforstyrrende at oversætte den til dansk)

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 exploit-ability)
4. Speculative reports about theoretical damage without concrete evidence or some substantive information indicating exploit-ability
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