Zeer weinig Nederlandse websites voorzien van security.txt-bestand
Zeer weinig Nederlandse websites zijn voorzien van een een security.txt-bestand. Volgens cijfers van de Stichting Internet Domeinregistratie Nederland (SIDN), de organisatie die de .nl-domeinnamen beheert, gaat het om slechts 2,5 procent van de .nl-domeinnamen. Toen er met de metingen op 1 juli 2022 werd begonnen stond de teller op 1,25 procent. Ruim twee jaar later is het percentage net verdubbeld. Vorig jaar waren er 6,3 miljoen .nl-domeinnamen geregistreerd. Dat zou inhouden dat ruim 157.000 .nl-websites een security.txt-bestand hebben.
SIDN wil vanaf volgend jaar een financiële prikkel voor de toepassing van security.txt opnemen in de Registrar Scorecard (RSC). Dat betekent dat de .nl-registrars straks een kickback krijgen op .nl-domeinnamen waarvan de website een valide 'security.txt'-bestand bevat", aldus de stichting. Security.txt is een bestand waarmee organisaties en websites hun beleid voor het omgaan met beveiligingslekken kunnen vermelden. Volgens de bedenkers van security.txt beschikken onafhankelijke beveiligingsonderzoekers vaak niet over de kanalen om kwetsbaarheden te melden.
Hierdoor kan het gebeuren dat gevonden beveiligingslekken niet worden gerapporteerd. Via security.txt moet het proces rond het melden en afhandelen van gevonden beveiligingsproblemen worden gestroomlijnd en versneld. "Van open standaarden is bekend dat een kritieke massa nodig is om het gebruik op gang te brengen. De incentiveregeling van SIDN is bedoeld als tijdelijke maatregel om de adoptie van specifieke standaarden over die eerste drempel heen te tillen", zo laat de stichting verder weten. Dit najaar zullen de Vereniging van Registrars, SIDN Fonds en SIDN aandacht vragen voor het gebruik van security.txt.
Providers zoals Odido hebben lak aan de uitrol daarvan, met als gevolg dat we het nog niet kunnen gebruiken.
Het is niet zo alsof ze het niet kunnen doen, en toch zijn ze heel hard bezig met uitstellen.
(Ze willen niet innoveren maar geld verdienen. En IPv6 verdient niks voor hun, dus doen ze het niet.)
Het is een beetje zielig maar gelukkig heb je ze niet nodig.
Ik "denk" dat ik meer last heb van automatische meldingen van onderzoekers (die net zo automatisch bij herhaling denken dat iets een probleem zou zijn), dan dat werkelijk nuttige meldingen mij niet zouden bereiken.
Ik verwacht dat dit soort goed bedoelde initiatieven van SIDN menig website eigenaar niet eens bereiken.
Het is een beetje zielig maar gelukkig heb je ze niet nodig.
De oprichter van SIDN was zelfs lange tijd van mening dat het internet alleen voor bedrijven en instellingen moest zijn. Deze alleen heersende en alleen beherende kinderjuf verbood dan ook lange tijd dat privé personen een domeinnaam mochten aanvragen. Veel privé-personen zijn voor hun domein toen ook uitgeweken naar buitenlandse domeinen.
Meeste is quickscan troep waar je echt niks mee kan zeker als je al goede eigen monitoring platforms bezit en de echt waardevolle meldingen gaan niet naar indivudele sites maar naar ISP's of software makers.
En als SIDN dit zo graag wil het zich ook wel eens houden aan de afspraken over wat er in een security.txt staat
A "security.txt" file MUST only apply to the domain or IP address in
the URI used to retrieve it, not to any of its subdomains or parent
domains. A "security.txt" file MAY also apply to products and
services provided by the organization publishing the file.
# Most of our other websites will redirect to this central file,
Je hoort ook niet je algemene solicitatie links er in the plempen enkel wat security related it.
Field Name: Hiring
Description: link to the vendor's security-related job positions
Multiple Appearances: yes
Status: current
Change controller: IETF
Reference: RFC 9116
Of ander voorbeeld wat dacht je van overheid zelf
https://www.digitaleoverheid.nl/nieuws/standaard-security-txt-nu-verplicht-voor-overheid/
Forum Standaardisatie heeft op 25 mei 2023 de standaard security.txt toegevoegd aan haar ‘Pas toe of leg uit’-lijst. Hiermee zijn Nederlandse gemeenten, provincies, rijk, waterschappen en alle uitvoeringsorganisaties verplicht om deze open standaard toe te passen.
Heeft digitaltrustcenter.nl eentje? nope 404
Heeft overheid.nl eentje? nope 403 (wtf)
OK laatste poging dan de gene die dit verplicht stelden forumstandaardisatie.nl en nope 403 as well.
Well so much for verplichting hier en dat horen dus eigenlijk volgens overheid dan weer 302s te zijn naar .ncsc.nl/.well-known/security.txt wat again weer niet volgens de afspraken is gezien losse en subdomeinen niet mogen gaan naar een securty.txt buiten hun domein om zoals in RFC 9116 toegelicht.
En dit is exact waarom het dus *niet werkt* omdat mensen hun eigen interpretatie gaan geven aan wat er in moet staan wanneer het wel en niet noodzakelijk is of onnodig moeilijk maken terwijl er duidelijke afspraken over waren gemaakt. En wat hebben we sinds eerste concept 2017 en RFC 9116 in 2022 bereikt ermee? heel weinig.
Dus nee SIDN hou die paar cent korting per domein maar lekker bij je ik hou het wel bij reputabele contacten die ons weten te bereiken omdat ze zakelijke relaties met ons hebben die kunnen connecten naar een incident reporting platform of eigen monitoring via wel bekende kanalen zoals CISA, NIST, en noem maar op.
Als je een security.txt wil aanpakken met cryptografische sleutel en al, dan lijkt me dat prima. Maar ik denk net als deze andere lezer dat de meeste website eigenaren beter doen in het weglaten van dit bestand. Het wordt op schaal gebruikt door "onderzoekers" die hun diensten aanprijzen en alarmistische berichten sturen, en niet zelden de grens met oplichterij opzoeken. De meeste niet-techneuten kunnen echt niet een waardevol bericht onderscheiden van deze onzin.
De oprichter van SIDN was zelfs lange tijd van mening dat het internet alleen voor bedrijven en instellingen moest zijn. Deze alleen heersende en alleen beherende kinderjuf verbood dan ook lange tijd dat privé personen een domeinnaam mochten aanvragen.
Maar hij vond ook dat ieder bedrijf maar 1 domeinnaam mocht registreren. Was dat maar zo gebleven!
Meeste is quickscan troep waar je echt niks mee kan zeker als je al goede eigen monitoring platforms bezit en de echt waardevolle meldingen gaan niet naar indivudele sites maar naar ISP's of software makers.
En als SIDN dit zo graag wil het zich ook wel eens houden aan de afspraken over wat er in een security.txt staat
A "security.txt" file MUST only apply to the domain or IP address in
the URI used to retrieve it, not to any of its subdomains or parent
domains. A "security.txt" file MAY also apply to products and
services provided by the organization publishing the file.
# Most of our other websites will redirect to this central file,
Je hoort ook niet je algemene solicitatie links er in the plempen enkel wat security related it.
Field Name: Hiring
Description: link to the vendor's security-related job positions
Multiple Appearances: yes
Status: current
Change controller: IETF
Reference: RFC 9116
Of ander voorbeeld wat dacht je van overheid zelf
https://www.digitaleoverheid.nl/nieuws/standaard-security-txt-nu-verplicht-voor-overheid/
Forum Standaardisatie heeft op 25 mei 2023 de standaard security.txt toegevoegd aan haar ‘Pas toe of leg uit’-lijst. Hiermee zijn Nederlandse gemeenten, provincies, rijk, waterschappen en alle uitvoeringsorganisaties verplicht om deze open standaard toe te passen.
Heeft digitaltrustcenter.nl eentje? nope 404
Heeft overheid.nl eentje? nope 403 (wtf)
OK laatste poging dan de gene die dit verplicht stelden forumstandaardisatie.nl en nope 403 as well.
Well so much for verplichting hier en dat horen dus eigenlijk volgens overheid dan weer 302s te zijn naar .ncsc.nl/.well-known/security.txt wat again weer niet volgens de afspraken is gezien losse en subdomeinen niet mogen gaan naar een securty.txt buiten hun domein om zoals in RFC 9116 toegelicht.
En dit is exact waarom het dus *niet werkt* omdat mensen hun eigen interpretatie gaan geven aan wat er in moet staan wanneer het wel en niet noodzakelijk is of onnodig moeilijk maken terwijl er duidelijke afspraken over waren gemaakt. En wat hebben we sinds eerste concept 2017 en RFC 9116 in 2022 bereikt ermee? heel weinig.
Dus nee SIDN hou die paar cent korting per domein maar lekker bij je ik hou het wel bij reputabele contacten die ons weten te bereiken omdat ze zakelijke relaties met ons hebben die kunnen connecten naar een incident reporting platform of eigen monitoring via wel bekende kanalen zoals CISA, NIST, en noem maar op.
De domeinen die je noemt komen prima uit op een valide security.txt, geen idee wat voor check jij doet...
https://www.ziggo.nl/klantenservice/internet-wifi/veiligheid/meldpunt-beveiligingslekken
bughunters.google.com/report
https://hackerone.com/6f26eb8c-3646-48d0-a088-43296e1973ce/embedded_submissions/new
Met Wordpress is dat makkelijk; er is sinds kort een plugin voor die alles voor je automatiseert:
https://wordpress.org/plugins/generate-security-txt/
Wel heeft digitaleoverheid.nl eentje? nope 404
Heeft digitaltrustcenter.nl eentje? nope 404
Heeft overheid.nl eentje? nope 403 (wtf)
OK laatste poging dan de gene die dit verplicht stelden forumstandaardisatie.nl en nope 403 as well.
https://digitaleoverheid.nl/.well-known/security.txt
https://digitaltrustcenter.nl/.well-known/security.txt
https://overheid.nl/.well-known/security.txt
Maar verder heeft security.nl haar zaakjes prima op orde, en sowieso staat in https://security.nl/about hoe je contact met de redactie kunt opnemen.
Het is een beetje zielig maar gelukkig heb je ze niet nodig.
Behalve als je naar een .nl-domeinnaam wil op internet...
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?