image

IETF publiceert na jarenlang proces RFC 9116 voor "security.txt" bestand

donderdag 28 april 2022, 17:10 door Redactie, 8 reacties

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.

Image

Reacties (8)
28-04-2022, 19:48 door Anoniem
Volgens de bedenkers van het voorstel beschikken onafhankelijke beveiligingsonderzoekers vaak niet over de kanalen om kwetsbaarheden te melden.

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...
28-04-2022, 23:43 door Anoniem
Door Anoniem:
Volgens de bedenkers van het voorstel beschikken onafhankelijke beveiligingsonderzoekers vaak niet over de kanalen om kwetsbaarheden te melden.

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.
29-04-2022, 08:01 door Anoniem
Door Anoniem: Als die kanalen in de security.txt staan zijn ze er dus gewoon, en is security.txt per definitie overbodig.
Vind je? Volgens mij is er een verschil tussen een contactmogelijkheid die wel bestaat maar nergens vermeld wordt en een die wel netjes vermeld wordt. Ik denk dat ook een beveiligingsonderzoeker met een hoog 1337-gehalte wel wat beters te doen heeft dan tijd te verspillen aan zoiets als het "contact"-doolhof van bijvoorbeeld NS. Het voegt echt wel wat toe als het op een voorspelbare plek gewoon genoemd wordt.
29-04-2022, 09:08 door Anoniem
Door Anoniem:
Volgens de bedenkers van het voorstel beschikken onafhankelijke beveiligingsonderzoekers vaak niet over de kanalen om kwetsbaarheden te melden.

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...
Nee daar heb je geen specifiek bestand voor nodig. Waar je het wel nodig voor hebt is automatiseren van contactinformatie verwerking. Nu hoef je enkel simpel script te coderen en te draaien en je kunt per bedrijf waar je mee werkt Enkel relevante contact informatie koppelen aan je CRM.

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.
29-04-2022, 10:37 door Anoniem
Door Anoniem:
Door Anoniem:
Volgens de bedenkers van het voorstel beschikken onafhankelijke beveiligingsonderzoekers vaak niet over de kanalen om kwetsbaarheden te melden.

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...
Nee daar heb je geen specifiek bestand voor nodig. Waar je het wel nodig voor hebt is automatiseren van contactinformatie verwerking. Nu hoef je enkel simpel script te coderen en te draaien en je kunt per bedrijf waar je mee werkt Enkel relevante contact informatie koppelen aan je CRM.

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."
29-04-2022, 10:39 door Anoniem
Door Anoniem:
Door Anoniem:
Volgens de bedenkers van het voorstel beschikken onafhankelijke beveiligingsonderzoekers vaak niet over de kanalen om kwetsbaarheden te melden.

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...
Nee daar heb je geen specifiek bestand voor nodig. Waar je het wel nodig voor hebt is automatiseren van contactinformatie verwerking. Nu hoef je enkel simpel script te coderen en te draaien en je kunt per bedrijf waar je mee werkt Enkel relevante contact informatie koppelen aan je CRM.

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).
29-04-2022, 15:00 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Volgens de bedenkers van het voorstel beschikken onafhankelijke beveiligingsonderzoekers vaak niet over de kanalen om kwetsbaarheden te melden.

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...
Nee daar heb je geen specifiek bestand voor nodig. Waar je het wel nodig voor hebt is automatiseren van contactinformatie verwerking. Nu hoef je enkel simpel script te coderen en te draaien en je kunt per bedrijf waar je mee werkt Enkel relevante contact informatie koppelen aan je CRM.

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).
We doen het zelf enkel bij onze relaties waar we al verwerking overeenkomsten hebben. Relaties zijn echter soms te lui of vergeten enige wijzigingen in management en policies door te geven aan de betrokken derden. We runnen dan ook om de X maanden een script en als er een afwijking zit in de huidige kopie vs oude dan nemen we contact op met de relatie voor verdere bespreking. Dat voorkomt dat we melding moeten maken van een datalek omdat iemand vergeten was bijvoorbeeld een bedrijfs overname te vermelden als we informatie delen met de oude relatie.

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.
24-11-2022, 09:02 door lorde
[Verwijderd door moderator]
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.