Met de publicatie van RFC 9116 eerder dit jaar is er nu een eenduidige manier beschikbaar voor organisaties om hun ‘vulnerability disclosure‘-beleid en contactpersonen te publiceren. Daartoe is een tekstformaat bedacht dat zowel voor machines als mensen leesbaar is en op de website gepubliceerd wordt in het bestand security.txt.
De informatie en verwijzingen in dit bestand moeten orde scheppen in de chaos van allerlei verspreide en/of verouderde policypagina’s en meldpunten, en een eenduidige ingang bieden naar de actuele policy’s en contacten.
Security-onderzoekers en white-hat (ethische) hackers kunnen de informatie in het security.txt-bestand gebruiken om te achterhalen wat het disclosurebeleid van de betreffende organisatie is en wie zij kunnen benaderen als zij een veiligheidsprobleem hebben ontdekt. Daarmee kunnen ontvangers van dergelijke meldingen sneller in actie komen en maatregelen treffen om schade te voorkomen of te beperken. Denk bijvoorbeeld aan een bedrijf waarvan gestolen bestanden te koop worden aangeboden op het dark web. Daarnaast is de verwachting dat de duidelijkheid en toegankelijkheid van security.txt bij brede adoptie ook zal leiden tot meer meldingen en minder incidenten.
Het is helaas geen uitzondering dat de vinders van een kwetsbaarheid geen ingang of gehoor kunnen vinden voor hun melding. Dat leidt er dan toe dat zij het opgeven, of overgaan tot directe publicatie (full disclosure). Dat laatste wordt door de hardliners ook wel gezien als dé manier om een organisatie af te straffen of onder druk te zetten om haar zaakjes beter te regelen.
Responsible disclosure, wat tegenwoordig Coordinated Vulnerability Disclosure (CVD) heet, geeft organisaties de gelegenheid om (in samenwerking met de melder) het probleem in kaart te brengen, een oplossing te vinden en deze uit te rollen.
Naast het disclosurebeleid en de contactinformatie van verantwoordelijken zijn ook het bestaan van een ‘bug bounty’-programma of een andere vorm van financiële compensatie zaken die in het security.txt-bestand thuishoren.
De DTC-notificatiedienst
Voor de publicatie van de policy’s is nooit een eenduidige plek geweest, maar als universele ingang is wel ooit het mailadres security@example.nl bedacht. Een andere veelgebruikte ingang is natuurlijk de contactinformatie voor een domeinnaam zoals die genoteerd staat bij de registry (organisaties zoals SIDN die verantwoordelijk zijn voor het beheer van een topleveldomein).
“Voor ons (en veel anderen) is de contactinformatie het belangrijkst,” vertelt Kim van der Veen, projectleider voor het Digital Trust Center (DTC) bij het Ministerie van Economische Zaken en Klimaat. DTC helpt vooral mkb-bedrijven om hun veiligheid te verbeteren. Daarvoor bieden zij (algemene) adviezen en tools aan op hun website.
Vorige zomer is daar een notificatiedienst bijgekomen, waarbij individuele bedrijven proactief benaderd worden als ernstige kwetsbaarheden in hun systemen of concrete bedreigingen worden gemeld. “Dat houdt in dat wij bedrijven bellen, waarschuwen voor specifieke cybersecuritybedreigingen, en zo veel mogelijk handelingssperspectief aanreiken. Dat laatste betekent bijvoorbeeld dat ze hun software moeten patchen of hun configuratie moeten aanpassen.”
Handmatig uitzoekwerk
“De input voor die meldingen wordt bij ons aangeleverd door partijen die beschikken over doelwit- en slachtofferinformatie, waaronder het NCSC,” vervolgt Van der Veen. “In de meeste gevallen hebben we als startpunt alleen een IP-adres beschikbaar. Via Reverse DNS proberen we daar dan een domeinnaam bij te vinden. Daarna gaan we op de website op zoek naar een ingang voor onze melding. Als we mazzel hebben, vinden we dan het telefoonnummer van de receptie of een algemeen infomailadres. Vervolgens moeten we maar hopen dat onze waarschuwing op de juiste plaats belandt en opvolging krijgt.”
Het afgelopen jaar heeft DTC op deze manier 4.600 meldingen verwerkt, veelal aangeleverd in de vorm van lijsten met IP-adressen. Vanwege al het handmatige uitzoekwerk en het belang van snel handelen, is gelijk duidelijk dat DTC enorm geholpen is met de informatie in het security.txt-bestand. “Persoonsgegevens in de Whois-database zijn tegenwoordig afgeschermd, en serviceproviders of SIDN kunnen ons om privacyredenen niet zomaar de gegevens van de domeinnaamhouder leveren. Inmiddels zijn we wel met SIDN in gesprek om te zien of er toch een mogelijkheid is om via Whois een notificatie te versturen als geen security.txt-bestand beschikbaar is. Tegelijkertijd blijkt veel van de contactinformatie in Whois verouderd of onjuist (klanten kunnen die gegevens immers zelf niet aanpassen). Vandaar dat we iedereen willen oproepen om op zijn minst zijn contactinformatie in het security.txt-bestand te publiceren.”
Campagne
Een paar weken geleden is DTC dan ook een campagne begonnen [1, 2] om het gebruik van security.txt te stimuleren. Voor ondernemers wordt in een paar stappen uitgelegd wat ze moeten doen, en voor IT-dienstverleners is er een aparte pagina beschikbaar waarin meer vermeld wordt over de informatievelden in het security.txt-bestand.
“Wij zijn inmiddels ruim een jaar bezig met onze notificatiedienst,” vertelt Van der Veen. “Er is voor ons veel winst te behalen met het security.txt-bestand, maar we wilden wachten tot de officiële RFC beschikbaar zou zijn. Wel hebben we samen met het NCSC tijdens de ontwikkeling van de RFC input en feedback geleverd. We hebben ons hard gemaakt voor de opname van deze standaard in de Internet.nl-testportal en gesuggereerd dat hij ook op de ‘pas toe of leg uit’-lijst (ptolu) van Forum Standaardisatie wordt geplaatst (dit proces loopt).”
Desondanks noemt Van der Veen het spannend om een nieuwe RFC zo te omarmen: “Overheden zijn meestal meer reactief, maar we zien absoluut de potentie van deze standaard. Hetzelfde geldt voor veel van de andere stakeholders en ambassadeurs [waar SIDN er een van is]”.
Het security.txt-bestandsformaat
Het formaat van de informatie in het security.txt-bestand steekt heel simpel in elkaar: het bevat tekstregels met daarin steeds een veld bestaande uit een naam en een waarde, bijvoorbeeld:
Contact: mailto:security@example.nl Contact: tel:+31-654322345
Alles bij elkaar zijn er op dit moment 8 van dergelijke velden gedefinieerd. Voor een overzicht met uitleg en voorbeelden verwijzen we je graag naar de specificatie in de RFC zelf.
Commentaarregels beginnen met een hekje:
# Commentaar hier
Onderaan kan nog een digitale handtekening (gebaseerd op OpenPGP) toegevoegd worden.
Het security.txt-bestand zelf publiceer je op deze locatie:
https://example.nl/.well-known/security.txt
al is https://example.nl/security.txt om historische redenen ook toegestaan. Om te voorkomen dat er onderweg met het bestand gerommeld kan worden, is het gebruik van HTTPS daarbij verplicht.
De RFC geeft ook een definitie voor de inhoud van security.txt in ABNF, een specificatie waaruit direct software (een parser) afgeleid kan worden om de inhoud automatisch te verwerken.
SIDN’s security.txt-bestand
Ons eigen security.txt-bestand vind je hier:
https://www.sidn.nl/.well-known/security.txt.
Het is geschreven door technical security officer Melvin Elderman. Wat opvalt is dat er nogal veel informatie als commentaar is toegevoegd (die dus niet machine-leesbaar is), wat suggereert dat de velden niet toereikend zijn. Maar dat valt volgens Elderman wel mee. “Ik vind het een mooi concept, en het is goed dat het nu gestandaardiseerd is. Wat ik misschien wel mis, is iets over het expertiseniveau: security-specialisten hebben de neiging om hele technisch rapportages aan te leveren; een kwetsbaarheid moet immers reproduceerbaar zijn. Grotere bedrijven hebben een eigen IT-afdeling en security-budget. Maar aan de andere kant kan ook een bakkersbedrijf zitten, dat die meldingen alleen maar kan doorzetten naar zijn serviceprovider (en zelfs daar zit niet altijd voldoende expertise). Maar voor nu kun je dat soort informatie dus wel als commentaar in je security.txt-bestand zetten.”
Iets anders is dat het security.txt-bestand met OpenPGP ondertekend kan worden, maar bij SIDN wordt OpenPGP op dit moment niet meer gebruikt. Elderman: “We hadden voorheen wel een sleutelpaar, maar dat werd door melders van kwetsbaarheden niet gebruikt. Voor nu bieden we dus een S/MIME-sleutel die mensen kunnen gebruiken om ons versleutelde berichten te sturen. Tegelijkertijd was dit wel aanleiding om OpenPGP binnen ons SOC versneld nieuw leven in te blazen.”
Je eigen security.txt-bestand
Zoals hierboven besproken is het security.txt-formaat zo eenvoudig dat je dat makkelijk handmatig uit kunt schrijven. Maar nog simpeler is om het te laten genereren op deze site:
Voor een check kun je op de Internet.nl-testportal terecht:
Waar de contactinformatie voor DTC het belangrijkste is, benadrukt Elderman dat ook het achterliggende proces en de policy in orde moeten zijn. “Anders wek je verwachtingen die je niet waar kunt maken en stel je mensen teleur. Dat achterliggende proces kan zo eenvoudig zijn als een mailbox die daadwerkelijk gelezen wordt en de policy dat een melder binnen een week een eerste antwoord moet krijgen.”
Voor een financiële incentiveregeling voor security.txt zoals die al bestaat voor onder andere DNSSEC en IPv6 is het nu nog te vroeg. Wel kunnen we melden dat uit onze eigen metingen blijkt dat security.txt inmiddels op 61.819 (1,3 procent) van de domeinen met een actieve website in de .nl-zone beschikbaar is. Over een aantal maanden brengt SIDN Labs een publicatie uit waarin zij de ontwikkeling van security.txt in de .nl-zone bespreken.
