Security.txt en IT-dienstverleners
Hoe kun je als IT-dienstverlener een security.txt configureren voor je eigen domeinen en die van je klanten. Wanneer maak je één centraal security.txt-bestand en hoe implementeer je dit in bulk? Je leest het hieronder.
Wat is een security.txt-bestand?
Security.txt is sinds april 2022 een Internet Engineering Task Force (IETF) informational standard. Een security.txt-bestand is een tekstbestand dat organisaties in de gelegenheid stelt om een security-policy publiekelijk kenbaar te maken op een vooraf gedefinieerde URL op hun webserver(s). Dit bestand specificeert onder andere het beleid van de organisatie met betrekking tot het melden van kwetsbaarheden en via welke kanalen er hierover contact opgenomen kan worden. Hoe sneller de juiste persoon (of team) op de hoogte gesteld is, hoe sneller mitigerende maatregelen kunnen volgen.
Security.txt implementeer je zo
Security.txt is een klein txt-bestand dat op een webserver wordt geplaatst. Zie het voorbeeld bovenaan deze pagina. Regels die starten met een '#' karakter, dienen als commentaar.
- Genereer een security.txt-bestand. Dit kan bijvoorbeeld via securitytxt.org
- Plaats het bestand in de "/.well-known" directory op je webserver(s)
- Controleer of je webserver het bestand correct aanbiedt. Dit kan via de websitetest van internet.nl
Toelichting op security.txt velden
Naast de verplichte velden "Contact" en "Expires" zijn er een aantal velden optioneel.
De belangrijkste lichten we hieronder toe.
Contact:
Contact: mailto:security@voorbeeldbedrijf.nl
Contact: https://voorbeeldbedrijf.nl/contact
- Vermeld tenminste één contactmogelijkheid: een e-mailadres, link naar webformulier of telefoonnummer.
- Let erop dat het contactadres altijd begint met "mailto:", "https://" of "tel:"
- Je kunt meerdere contactmanieren opnemen. Het contactadres dat je het eerste noemt, heeft je voorkeur.
Encryption:
Encryption: https://voorbeeldbedrijf.nl/pgp.txt
- Wil je de mogelijkheid bieden om meldingen via een bericht te versturen dat PGP-versleuteld is?
- Zet in dit veld de locatie waar de PGP-sleutel te vinden is.
Preferred-Languages:
Preferred-Languages: nl,en
- Geef aan in welke taal er gecommuniceerd wordt.
- De eerstgenoemde taal is de voorkeurstaal.
Canonical:
Canonical: https://voorbeeldbedrijf.nl/.well-known/security.txt
- Vermeld hier de URL waarop dit security.txt-bestand geserveerd wordt.
- Vermeld voor subdomeinen een eigen canonical locatie.
Policy:
Policy: https://voorbeeldbedrijf.nl/security-policy/
- Dit veld vermeldt de locatie waar cyberonderzoekers het responsible disclosure beleid kunnen vinden.
- Een security.txt-bestand is opvraagbaar via het pad "/.well-known/security.txt" op het bijbehorende domein. Voor het domein voorbeeldbedrijf.nl zou een organisatie haar responsible disclosure beleid kenbaar kunnen maken door een security.txt-bestand beschikbaar te stellen op https://voorbeeldbedrijf.nl/.well-known/security.txt.
Security.txt in websitetest van Internet.nl
Internet.nl gebruikt in hun testscripts voor veilige internetinstellingen de door het Digital Trust Center beschikbaar gestelde code om je website te checken op de aanwezigheid van security.txt. Heb je het bestand niet volgens de standaard de security.txt file gepubliceerd, dan krijg je hier een melding van.
Dit script is ook opensource beschikbaar via Github. Het leest de security.txt file uit en controleert of deze voldoet aan de RFC 9116 standaard.
Security.txt verplicht voor de overheid
De internetstandaard security.txt is een jaar of 5 geleden ontstaan bij cyberonderzoekers Edwin Foudil en Yakov Shafranovich. Na diverse iteraties en consultatierondes is deze internetstandaard per 25 mei 2023 door Forum Standaardisatie aan de 'Pas toe of leg uit'-lijst toegevoegd. Dit betekent dat Nederlandse gemeenten, provincies, rijk, waterschappen en alle uitvoeringsorganisaties verplicht zijn om deze open standaard toe te passen. Voor alle andere organisaties in de publieke sector geldt een dringend advies om security.txt toe te passen.
Petra Oldengarm - Directeur Cyberveilig Nederland
Security.txt in bulk implementeren
Eén centraal security.txt-bestand voor al je domeinen of klanten?
Voor IT-dienstverleners zoals webhosters en managed service providers is het belangrijk om goed af te stemmen bij wie een kwetsbaarheidsmelding primair binnenkomt; bij de klant of bij de IT-dienstverlener. Security.txt biedt de mogelijkheid om voor alle domeinen die onder je organisatie vallen, of domeinen van klanten die IT-diensten bij jou afnemen, één centraal meldpunt voor kwetsbaarheden te organiseren. Dit betekent dat responsible disclosure (RD) en coordinated vulnerability disclosure (CVD) meldingen in eerste instantie bij jou als IT-dienstverlener binnenkomen. Je kunt besluiten om deze meldingen vervolgens met de betrokken klanten delen. Het is belangrijk hierover duidelijke afspraken te maken.
Een voorbeeld:
Je ontwikkelt webshopsoftware en biedt aan een groot aantal klanten webshops aan als SaaS-oplossing. Dan kan het voor jou heel relevant zijn om één security.txt-bestand te maken voor de domeinnamen van alle klanten waarvoor je de webshopapplicatie host. Als er een kwetsbaarheid geconstateerd wordt in de webshopsoftware, dan wil je daar graag snel van op de hoogte zijn zodat je deze kwetsbaarheid voor alle andere klanten kunt repareren.
Verwijzen naar één security.txt via een 302 redirect
Als het wenselijk is om in bulk voor veel domeinnamen te verwijzen naar één security.txt-adres, dan kan een HTTP 302 redirect handig zijn. Mogelijk handiger dan een apart security.txt-bestand voor elk domein afzonderlijk omdat:
-
veranderingen in het centrale security.txt-bestand slechts eenmaal hoeven worden doorgevoerd. Alle systemen die verwijzen naar het centrale security.txt-bestand zullen hierdoor automatisch verwijzen naar de aangepast content. Zonder een centraal security.txt-bestand zouden alle security.txt-bestanden op elk systeem geüpdatet moeten worden.
-
de vervaldatum ("Expires") van het centrale security.txt-bestand maar op één plek aangepast hoeft te worden zodra deze verstreken is. Zonder een centraal security.txt-bestand zouden alle systemen die gebruik maken van security.txt periodiek geüpdate moeten worden om de houdbaarheidsdatum te verversen.
Rewrite mogelijkheden
Apache
Bij een Apache webserver kun je bijvoorbeeld de volgende configuratie aanpassing doen om een redirect te maken naar een centrale security.txt-bestand.
############
RewriteEngine On
RewriteRule "^/.well-known/security\.txt$" https://www.example.nl/.well-known/security.txt [R=302,L]
RewriteRule "^/security\.txt$" https://www.example.nl/.well-known/security.txt [R=302,L]
#[eventueel bestaande RewriteRule regels hier]#
############
Microsoft internet Information Services (IIS)
Ook met Microsoft Internet Information Services (IIS) webservers is het mogelijk om een rewrite toe te passen. Op deze manier kunnen derden contact leggen met je organisatie indien er een kwetsbaarheid gevonden is op één van je (klant)systemen.
Domeinen in bulk testen
Als je verschillende domeinen in één keer wilt testen of je eigen securityscan wilt uitbreiden met een controle op security.txt, dan kun je hiervoor de open-source tool van het DTC gebruiken.
Voor het bouwen van de test is ook een python package met bouwstenen beschikbaar.
NGINX
Wil je security.txt configureren voor NGINX? Check dan de volgende Git repo. Hiermee kun je voor NGINX eenvoudig meerdere domeinen met security.txt beschikbaar stellen en ook eenvoudig beheren.
Vergeet niet op internet.nl nog even te checken of je file compliant is aan de standaard RFC 91116.
Disclaimer: Wij verwijzen hier naar een pagina van derden en zijn niet verantwoordelijk voor de correctheid/juistheid van deze informatie.
Brian Krebs - Techjournalist en blogger
Andere overwegingen
Elke klant een eigen security.txt
Wil je als IT-dienstverlener niet alle meldingen voor je klanten binnenkrijgen? Dan kun je overwegen om bij de uitrol van nieuwe webapplicaties je klanten te vragen of verplichten om zelf een security.txt-bestand te genereren. Voor veel CMS-systemen zijn er bijvoorbeeld al plugins beschikbaar om een security.txt-bestand te configureren.
Securityt.txt niet in de root folder
Toen de RFC nog in ontwikkeling was, werd er gebruik gemaakt van een security.txt-bestand in de root van het desbetreffende systeem. Bijvoorbeeld https://voorbeeldbedrijf.nl/security.txt. Bij de doorontwikkeling van deze RFC is er voor gekozen om het bestand niet in de root maar in de "/.well-known/"-folder te plaatsen om de root directory niet te vervuilen en overzichtelijk te houden. De RFC markeert deze paden als verouderd en raadt aan deze niet meer te gebruiken.
Security.txt als onderdeel van een Responsible Disclosure (RD-)beleid
Voor elke organisatie zal er een beleid of procedure beschreven worden hoe het omgaat met securitymeldingen. In een zogenoemd beleid voor Responsible Disclosure (RD) of Coordinated Vulnerability Disclosure (CVD) kun je aangeven wat je met de meldingen doet en wat de melder van jouw organisatie mag verwachten.
"A fundamental part of fixing data breaches is that we need to collectively strive to do better. We must all acknowledge that none of us are immune to security vulnerabilities and it must be one of our highest priorities to engage with those wanting to bring them to our attention.
Security.txt is a really simple idea that works well, it is just a simple text file."
Troy Hunt - Oprichter Have I Been Pwned
Wie mag dit security.txt-bestand gebruiken?
Het security.txt-bestand kan door derden, zoals ethische hackers, beveiligingsonderzoekers, cybersecuritybedrijven en overheidsorganisaties zoals NCSC en DTC, gebruikt worden om kwetsbaarheden te melden voor de systemen waarvoor het security.txt-bestand bedoeld is.
Digital Trust Center zal bij ernstige kwetsbaarheden onderzoeken of een organisatie security.txt heeft geconfigureerd. Als er een e-mailadres gevonden wordt, dan zal er (geautomatiseerd) een notificatie verstuurd worden naar dat e-mailadres. Digital Trust Center gebruikt bij een mailnotificatie altijd het afzenderadres: algemeen@digitaltrustcenter.nl.
Wat zijn de risico’s?
De handleiding bij RFC9116 meldt een klein aantal nadelen of risico's. Het belangrijkste risico is dat er door het opnemen van contactgegevens in een security.txt-bestand een risico op spam en nepmeldingen bestaat. Doordat deze contactgegevens door het publiceren van een security.txt-bestand publiek te vinden zijn, kunnen spammers en scammers dit adres ook vinden en gebruiken voor andere doeleinden, bijvoorbeeld phishing. Dit risico geldt voor elk e-mailadres dat op websites vindbaar is, zoals een e-mailadres voor vragen of contact. Denk daarbij aan contact@voorbeeldbedrijf.nl of pers@voorbeeldbedrijf.nl.
Daarom adviseren we om maatregelen te treffen om binnenkomende e-mails goed te filteren. Komt er na het filteren toch nog teveel spam binnen, dan kan een webformulier als security.txt-contactadres uitkomst bieden. Bijvoorbeeld: "Contact: https://voorbeeldbedrijf.nl/security-contact.html".
Ervaringsverhalen: security.txt in de praktijk
Een aantal bedrijven hebben security.txt al in gebruik en kunnen dus uit ervaring vertellen hoe het in de praktijk werkt. Laat je informeren over het nut, de nadelen en het gebruiksgemak van security.txt.
Vragen?
Heb je vragen over keuzes die je over de implementatie van security.txt maakt? Sluit je dan aan bij de DTC Community waar ondernemers en IT-professionals dagelijks kennis en informatie uitwisselen over cybersecurity-onderwerpen. Maak je interesse kenbaar via onderstaande button.