security.txt (standaard voor veilig internet)
Reactie
|
Naam
|
N / A (Mr P Wouters)
|
|
Plaats
|
Toronto
|
|
Datum
|
14 februari 2023
|
Vraag1
Wilt u reageren op het advies van de experts om security.txt te verplichten aan de overheid (‘pas toe of leg uit’-verplichting) (paragraaf 1 van het expertadvies)?
Het verplicht stellen van een security.txt bestand zorgt ervoor dat er alleen nog een extra locatie is waar contact gegevens moeten worden bijgehouden - en die vervolgens na enkele jaren volstaat met verouderde informatie. Een contact email op de homepage, die wel wordt bijgehouden, beheerd en vernieuwd, zal veel beter werken.
Bovendien kan de inhoud van de security.txt file nooit vertrouwd worden, omdat als je een beveiligingsprobleem wilt melden, dat je dat niet zeker kunt zijn dat je de eerste persoon bent die het beveiligingsprobleem ziet, en dat hackers niet al de inhoud van security.txt hebben veranderd om te voorkomen dat de echte beheerders op de hoogte gesteld worden.
De administratie van DNS (SOA record) en de domein informatie (WHOIS, RDAP) of zelfs twitter, zijn vele betere kanalen om die informatie door te geven omdat die onafhankelijk van de website beveiliging werken. Dus zelfs als een website onveilig is, zijn deze alternative kanalen hopelijk nog wel veilig, terwijl een security.txt file op een onveilige website niet te vertrouwen is. Zelfs als het om een iets andere website gaat (bv rapoteren van een probleem op "vergunningen.stad.nl" via de security.txt op stad.nl/security.txt) dan is het zeer waarschijnlijk dat deze verschillende websites met dezelfde software wordt beheerd en dus nog steeds de security.txt niet kan worden gebruikt omdat hackers deze verandert kunnen hebben.
Tijdens de "last-call" procedure voor deze RFC heb ik hier ook op verwezen: https://mailarchive.ietf.org/arch/msg/secdir/5l2Wdmj8m3qFBDWpdTvZL9qcokg/
Paul Wouters
Security Area Director at the IETF (maar was niet de SEC-AD toen deze draft besproken werdt)
Vraag2
Wilt u reageren op de constateringen en conclusies van de experts met betrekking tot de criteria voor de lijst verplichte standaarden waarop zij security.txt hebben getoetst voor verplichting via de ‘pas toe of leg uit’-lijst (paragrafen 5.1-5.4 van het expertadvies)?
Zoals hierboven beschreven, ben ik van mening dat deze verplichting geen enkele tegevoegde waarde heeft. Sterker nog, het zal een toegevoegd probleem worden als er steeds oude security.txt bestanden gebruikt worden die lijden tot miscommunicatie.
Als lid van de Internet Engineering Steering Group (IESG) bij de IETF, was ik betrokken bij de evaluatie van security.txt voor de IETF zelf (op ietf.org). Er is besloten dat de IETF niet kan garanderen dat de informatie actueel is en kan ook niet garanderen dat de IETF tijdig kan detecteren of de security.txt door hackers is aangepast. Zodoende zal de IETF zelf ook niet security.txt uitrollen op hun eigen domeinen.
Vraag3
Wilt u reageren op de adviezen van de experts aan het Forum Standaardisatie en Overheidsbreed Beleidsoverleg Digitale Overheid (paragraaf 6 van het expertadvies)?
Het is mijn professionale mening als internet beveiliging expert dat security.txt NIET verplicht of geadviseerd moet worden voor de overheid. Een beter alternatief zou zijn om de beter en duidelijker beleid uit te zetten voor het bijhouden van de gebruiksgevens in de WHOIS, voor de "Technical Contact", en in de toekomst voor RDAP voor Security Contacts.
Vraag4
Wilt u reageren op het doorlopen proces en de samenstelling van de expertgroep (paragraaf 3 van het expertadvies)?
N/A
Vraag5
Wilt u aanvullende overwegingen meegeven aan het Forum Standaardisatie en Overheidsbreed Beleidsoverleg Digitale Overheid (OBDO) in verband met de inhoud van dit expertadvies of het gevolgde proces?
N/A
