IETF publiceert na jarenlang proces RFC 9116 voor "security.txt" bestand
De Internet Engineering Task Force (IETF) heeft na een proces van vijf jaar een RFC (Request for Comments) gepubliceerd voor "security.txt", een bestand waarmee organisaties en websites hun beleid voor het omgaan met beveiligingslekken kunnen vermelden. Door de publicatie van RFC 9116 is security.txt nu een specificatie geworden, maar geen internetstandaard.
De IETF is een standaardenorganisatie die zich via discussies binnen de internet community bezighoudt met het ontwikkelen van vrijwillige internetstandaarden. Vijf jaar geleden kwamen Edwin Foudil en Yakov Shafranovich van securitybedrijf Nightwatch Cybersecurity met het idee voor security.txt. Volgens de bedenkers van het voorstel beschikken onafhankelijke beveiligingsonderzoekers vaak niet over de kanalen om kwetsbaarheden te melden. Hierdoor kan het gebeuren dat gevonden beveiligingslekken niet worden gerapporteerd.
Het bestand security.txt moet dit voorkomen, onder andere door contactgegevens te vermelden. Verschillende grote partijen zoals Facebook, Github en Google maken gebruik van security.txt. In 2017 dienden Foudil en Shafranovich een voorstel voor security.txt in bij de Network Working Group van de Internet Engineering Task Force (IETF) zodat het een nieuwe internetstandaard zou kunnen worden.
Via een RFC documenteert de IETF internetstandaarden. Het is echter ook mogelijk om RFC's te publiceren die de status "informatief" hebben. Het gaat in dit geval om informatieve specificaties bedoeld als algemene informatie voor de internet community en geen aanbeveling. Deze specificaties zijn buiten de internet community om opgesteld en zijn geen onderdeel van het proces voor het opstellen van internetstandaarden. Dat neemt niet weg dat Foudil en Shafranovich zeer blij zijn dat ze nu een RFC hebben.
Als die kanalen in de security.txt staan zijn ze er dus gewoon, en is security.txt per definitie overbodig. 99% van de security.txt bestanden zijn gevuld met variaties op "email: security@[domain]".
Als je daar de security.txt voor nodig hebt ben je de kwalificatie onderzoeker niet waard...
Als die kanalen in de security.txt staan zijn ze er dus gewoon, en is security.txt per definitie overbodig. 99% van de security.txt bestanden zijn gevuld met variaties op "email: security@[domain]".
Als je daar de security.txt voor nodig hebt ben je de kwalificatie onderzoeker niet waard...
Precies. Je hebt helemaal gelijk. En daarom ziet bijv. de Facebook security.txt er op dit moment zo uit:
Contact: https://www.facebook.com/whitehat/report/
Acknowledgments: https://www.facebook.com/whitehat/thanks/
Hiring: https://www.facebook.com/careers/teams/security/
# Found a bug? Our bug bounty policy:
Policy: https://www.facebook.com/whitehat/info/
# What we do when we find a bug in another product:
Policy: https://www.facebook.com/security/advisories/Vulnerability-Disclosure-Policy
Expires: Sat, 28 May 2022 14:39:38 -0700
Toch is het handig om het snel op te kunnen zoeken waar je moet zijn, in plaats van een zoektocht naar die informatie te moeten doen.
Als die kanalen in de security.txt staan zijn ze er dus gewoon, en is security.txt per definitie overbodig. 99% van de security.txt bestanden zijn gevuld met variaties op "email: security@[domain]".
Als je daar de security.txt voor nodig hebt ben je de kwalificatie onderzoeker niet waard...
Dat betekend niet veel als je maar 1 klant tegelijk afwikkelt maar als je honderden erin hebt is die paar seconde besparing al gauw zeer waardevol.
Ik zie echter meer voordeel voor corporate dan freelance en hobymatig eerlijk te zijn.
Als die kanalen in de security.txt staan zijn ze er dus gewoon, en is security.txt per definitie overbodig. 99% van de security.txt bestanden zijn gevuld met variaties op "email: security@[domain]".
Als je daar de security.txt voor nodig hebt ben je de kwalificatie onderzoeker niet waard...
Dat betekend niet veel als je maar 1 klant tegelijk afwikkelt maar als je honderden erin hebt is die paar seconde besparing al gauw zeer waardevol.
Ik zie echter meer voordeel voor corporate dan freelance en hobymatig eerlijk te zijn.
Vandaag worden veel mensen nog steeds aangeklaagd louter en alleen voor het melden van een security probleem.
Het grote voordeel van een dergelijke standaard en tekst is dat het bedrijf hiermee aangeeft dat het wendelijk en mogelijk is om securitymeldingen te doen en het dan dus bijna onmogelijk wordt om mensen aan te klagen voor de melding alleen.
(Uiteraard kunnen mensen nog steeds aangeklaagd worden als ze eerst misbruik hebben gemaakt, etc...)
Een security.txt kan ook aangeven: "We don't care, don't contact us."
Als die kanalen in de security.txt staan zijn ze er dus gewoon, en is security.txt per definitie overbodig. 99% van de security.txt bestanden zijn gevuld met variaties op "email: security@[domain]".
Als je daar de security.txt voor nodig hebt ben je de kwalificatie onderzoeker niet waard...
Dat betekend niet veel als je maar 1 klant tegelijk afwikkelt maar als je honderden erin hebt is die paar seconde besparing al gauw zeer waardevol.
Ik zie echter meer voordeel voor corporate dan freelance en hobymatig eerlijk te zijn.
Ik geloof niet dat het de bedoeling was van deze standaard om als bron te dienen voor scrapers van e-mail adressen...
Maar dat is wel een interessant side-effect natuurlijk. Wellicht is DAT de reden dat ik nog wel eens pogingen zie om
dat bestand (wat ik niet heb) van mijn webserver te fetchen.
Het idee was meer dat je dit bestand ophaalt NADAT je geconstateerd hebt dat er een of ander beveiligingsprobleem
is en je dat aan de juiste kanalen wilt melden, maar ja zo gaat dat niet werken in de wereld natuurlijk. Misbruik is veel
aantrekkelijker (kennelijk).
Als die kanalen in de security.txt staan zijn ze er dus gewoon, en is security.txt per definitie overbodig. 99% van de security.txt bestanden zijn gevuld met variaties op "email: security@[domain]".
Als je daar de security.txt voor nodig hebt ben je de kwalificatie onderzoeker niet waard...
Dat betekend niet veel als je maar 1 klant tegelijk afwikkelt maar als je honderden erin hebt is die paar seconde besparing al gauw zeer waardevol.
Ik zie echter meer voordeel voor corporate dan freelance en hobymatig eerlijk te zijn.
Ik geloof niet dat het de bedoeling was van deze standaard om als bron te dienen voor scrapers van e-mail adressen...
Maar dat is wel een interessant side-effect natuurlijk. Wellicht is DAT de reden dat ik nog wel eens pogingen zie om
dat bestand (wat ik niet heb) van mijn webserver te fetchen.
Het idee was meer dat je dit bestand ophaalt NADAT je geconstateerd hebt dat er een of ander beveiligingsprobleem
is en je dat aan de juiste kanalen wilt melden, maar ja zo gaat dat niet werken in de wereld natuurlijk. Misbruik is veel
aantrekkelijker (kennelijk).
Maar ja net als WHOIS zeer makkelijk natuurlijk te misbruiken voor marketing spam al kun je je afvragen wat ze eraan hebben behalve dat ze IP reputatie schade oplopen. Beetje alsof een inbreker zijn, haar diensten gaat adverteren bij een politie frontdesk.
Deze posting is gelocked. Reageren is niet meer mogelijk.
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?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
