Stel: een onderzoeker vindt een lek in de webshop van jouw klant, en wil het netjes melden. Waar moet diegene heen?

Op de site staat een contactformulier voor offerteaanvragen en een info@-adres. Dus gaat er een mail heen. Die komt bij de receptie terecht, wordt gelezen als spam, of blijft twee weken liggen. Na een tijdje houdt de melder het voor gezien. Of het gaat naar X, waar de rest van het internet meekijkt.

Wat is een security.txt?

Een tekstbestand op een vaste plek: https://jouwdomein.nl/.well-known/security.txt. Meer is het niet. Onderzoekers, scanners en geautomatiseerde tools kijken daar als eerste, omdat het altijd op dezelfde plek staat. Het formaat ligt vast in RFC 9116.

Er zijn twee verplichte velden:

Contact: mailto:security@jouwdomein.nl
Expires: 2027-08-14T00:00:00.000Z

Contact spreekt voor zich. Expires is de houdbaarheidsdatum. Staat die in het verleden, dan beschouwen onderzoekers en tools het hele bestand als ongeldig. Zet je hem één keer neer en vergeet je hem daarna, dan is het over een jaar waardeloos. Dan ben je slechter af dan zonder, want je hebt de indruk gewekt dat er iemand meeleest.

Voor de Nederlandse overheid is het al verplicht

Dit is geen vrijblijvende best practice meer. Sinds 25 mei 2023 staat security.txt op de 'pas toe of leg uit'-lijst van het Forum Standaardisatie. Dat betekent dat gemeenten, provincies, het rijk, de waterschappen en alle uitvoeringsorganisaties de standaard moeten toepassen. Doen ze het niet, dan moeten ze uitleggen waarom.

Er zit ook een lijn naar de Baseline Informatiebeveiliging Overheid. De BIO eist dat je een procedure hebt voor het ontvangen en afhandelen van kwetsbaarheidsmeldingen. Een security.txt is het meest zichtbare deel van die procedure: het is de plek waar je hem publiceert.

Internet.nl test er inmiddels op in de domeintest. Een meting begin 2023 liet zien dat toen slechts 20% van de onderzochte overheidssites een security.txt had. Vandaar de verplichting.

Bouw of beheer je sites voor een gemeente, een provincie, een zorginstelling of een uitvoeringsorganisatie, dan is dit iets waar je klant op afgerekend wordt. Wij staan zelf in de Internet.nl Hall of Fame, dus we kennen die test van binnenuit. Bekijk hoe we omgaan met security →

En deze week: Duitsland roept alle websites op

Het Duitse Bundesamt für Sicherheit in der Informationstechnik (het BSI, de Duitse tegenhanger van ons NCSC) riep deze week beheerders van alle websites op om een security.txt te publiceren.

De aanleiding is een schamel cijfer: 1,8% van de Duitse websites heeft er een. Nederland doet het met zo'n 14% een stuk beter. Alsnog laat 86% van de Nederlandse sites in het midden wat er moet gebeuren als iemand een lek vindt. Lees het bericht op Security.NL

Het BSI wijst daarbij vooruit naar de Cyber Resilience Act. Die stelt eisen aan hoe je omgaat met kwetsbaarheden en meldingen daarover. Een vindbaar meldadres is dan het minimum. De richting is duidelijk: wat bij de overheid begon als verplichting, schuift op naar de rest.

Wat het je nu al oplevert

Het praktische voordeel is dat een melding bij de juiste persoon aankomt in plaats van bij de afdeling verkoop. Dat scheelt dagen. Bij een actief misbruikt lek zijn dat de dagen die ertoe doen.

Het tweede voordeel is subtieler. Een onderzoeker die een lek meldt, neemt een risico. De reflex om boos te worden op de boodschapper zit er bij veel organisaties nog in. Een security.txt met een link naar je disclosure-beleid zegt: we weten hiervan, we stellen het op prijs, dit zijn de spelregels. Dat haalt de spanning eruit, en daarmee de kans dat iemand het maar publiek maakt.

Het derde: je klanten gaan ernaar vragen. Security-vragenlijsten bij aanbestedingen en enterprise-deals bevatten steeds vaker een regel over gecoördineerde kwetsbaarheidsmelding. "Ja, kijk maar op ons domein" is een prettiger antwoord dan een toelichting van drie alinea's.

Wij hebben er zelf ook een, met een verwijzing naar ons beleid en naar de Hall of Fame waarin melders een plek krijgen. Bekijk ons responsible-disclosurebeleid

De velden die je verder kunt gebruiken

Naast Contact en Expires zijn er een paar optionele velden die het bestand pas echt nuttig maken:

  • Policy - een link naar je disclosure-beleid. Hier leest een onderzoeker wat je verwacht, wat diegene van jou mag verwachten, en waar de grenzen liggen.
  • Encryption - een link naar je publieke PGP-sleutel, zodat een melding versleuteld verstuurd kan worden. Handig als het lek zelf gevoelige informatie prijsgeeft.
  • Acknowledgments - de pagina waar je melders bedankt. Erkenning is voor veel onderzoekers de reden dat ze het doen.
  • Preferred-Languages - de talen waarin je team kan lezen. Scheelt een melding in het Duits die niemand oppakt.
  • Hiring - een link naar je security-vacatures. Je wordt tenslotte gelezen door precies het soort mensen dat je zoekt.

De keerzijde, eerlijk gezegd

Twee dingen om rekening mee te houden.

Het is handwerk, en handwerk verloopt. Een adres van een collega die vorig jaar vertrok. Een typefout in het e-mailadres. Een Expires-datum die verstreken is. Bij één domein houd je dat bij. Bij tachtig domeinen gebeurt dat niet meer. Precies daar zit het verschil tussen een security.txt hebben en er een hebben die werkt.

Je publiceert een adres. Dat wordt gevonden door onderzoekers, en ook door mensen die zich als onderzoeker voordoen. Reken op phishing die eruitziet als een melding, met een bijlage of een link die je vooral moet openen. Behandel binnenkomende meldingen dus zoals je elke andere onverwachte mail behandelt, en verifieer wie je aan de lijn hebt voordat je iets gevoeligs deelt.

Beide zijn te overzien. Ze wegen niet op tegen een lek dat je pas via de pers hoort.

Op Core zet je hem direct aan

Een bureau met tachtig domeinen in beheer gaat geen tachtig tekstbestandjes onderhouden. Zeker niet met een datum die je jaarlijks moet oprekken.

Op Core werkt het andersom. Je maakt één security.txt-policy aan en koppelt die aan zoveel domain routers als je wilt. Pas je de policy aan, dan is die wijziging direct op alle gekoppelde domeinen zichtbaar. Eén keer de Expires-datum bijwerken, klaar voor je hele portfolio.

Wat je in een policy kwijt kunt:

  • Een naam voor jezelf, om policies uit elkaar te houden in het paneel
  • De Expires-datum
  • Contactadressen: e-mailadressen, URL's, of allebei. Er moet er minstens één zijn.
  • URL's voor je beleid, je PGP-sleutel, je Hall of Fame en je vacatures
  • Voorkeurstalen (Nederlands en Engels)
  • Een vinkje 'standaard voor dit cluster', zodat elke nieuwe domain router hem automatisch krijgt

Koppelen kan van twee kanten: vanuit de policy zelf zet je in één scherm alle domain routers aan die je wilt, of je kiest per domain router een policy in de Security.txt-tegel. Het gaat ook via de API, dus je kunt het meenemen in je eigen provisioning.

Vanaf dat moment serveren wij het bestand op /.well-known/security.txt, opgemaakt volgens RFC 9116. Er staat niets op schijf dat kan verlopen of per ongeluk overschreven raakt bij een deploy. Zit er geen policy aan een domain router, dan krijgt een bezoeker gewoon een 404, net als bij elk ander pad dat niet bestaat.

Twee dingen om te weten

  • Een wildcard-domain router serveert het bestand niet op de subdomeinen die eronder vallen. Wil je het op app.klant.nl, dan heb je een domain router voor die hostnaam zelf nodig.
  • Een policy en de domain routers die je eraan koppelt, horen in hetzelfde cluster te zitten.

De volledige uitleg staat in onze documentatie. Lees alles over security.txt-policies

Kortom

Voor de Nederlandse overheid is een security.txt al drie jaar verplicht. Duitsland vraagt er nu om voor iedereen, en de Cyber Resilience Act duwt dezelfde kant op. Van "netjes" wordt dit "verwacht", en daarna gewoon "vereist".

Draai je bij ons en wil je het voor je hele portfolio in één keer regelen? Neem contact met ons op. We zetten hem samen op.