Forum Standaardisatie start consultatie voor security.txt-plicht bij overheid

Het Forum Standaardisatie is een consultatie gestart voor breder gebruik van de security.txt-standaard bij overheden. Het Forum wil onderzoeken of Nederlandse overheidsinstellingen verplicht de securitycontactinformatie moeten opnemen onder het 'Pas toe of leg uit'-principe.

Het standaardisatieplatform van de Nederlandse overheid heeft de consultatie inmiddels online gezet. Die loopt nog door tot 12 maart. Volgens het Forum kan security.txt 'bijdragen aan een veiliger internet doordat meldingen over kwetsbaarheden in een dienst of systeem sneller terechtkomen bij de juiste personen binnen een organisatie'. Daardoor zouden zulke meldingen sneller worden opgepakt en afgehandeld. Het Forum sprak met verschillende experts die adviseren om de standaard te verplichten.

Dat verplichten zou via een 'Pas toe of leg uit'-beleid gaan. Die standaard verplicht Nederlandse overheden, zoals de Rijksoverheid, provincies en gemeenten, en semipublieke instellingen om bepaalde principes toe te passen, tenzij ze een goede reden hebben om dat niet te doen, die ook door de instantie duidelijk wordt uitgelegd.

Security.txt is een relatief nieuwe internetstandaard voor responsible disclosure. Het is een online tekstbestand waarin staat wat securityonderzoekers moeten doen wanneer ze een kwetsbaarheid willen melden. De standaard schrijft voor waar die tekst moet staan, op welke manier de informatie is opgesteld en welke informatie er in het bestand moet staan. Vorig jaar werd de standaard aangenomen als officiële RFC-draft. Tweakers sprak later met de bedenker van de standaard over zijn motivatie en wat de standaard moet bewerkstelligen.

Reacties (94)

[kodak]

De security.txt werkt niet zomaar beter dan huidige oplossingen. De webmaster gaan er niet zomaar beter de contactgegevens door bijhouden die in security.txt staan. De processen om aan responsible disclosure te doen worden er niet zomaar beter van. De contactgegevens worden er niet zomaar eenduidiger op.

Dus zonder extra verplichtingen krijg je dan wat nu al dagelijkse kost is: niet kunnen bereiken van de overheid door opgeheven mailadressen, niet werkende mailadressen en verwijzingen naar niet bestaande pagina's.

[TijsZonderH]

De contactgegevens worden er niet zomaar eenduidiger op.

Dat is ook niet de bedoeling. De vindbaarheid ervan wordt er eenduidiger van, dus dat is voor de onderzoeker juist gemakkelijker.

niet kunnen bereiken van de overheid door opgeheven mailadressen, niet werkende mailadressen en verwijzingen naar niet bestaande pagina's.

Daar voorziet de RFC ook in. De einddatum is daarin een verplicht veld dus dwingt de standaard je de file actueel te houden.

[Gamebuster]

Expires: 2999-12-31T23:59:59Z

[Hatsjoe]

Als je je houdt aan de RFC en ook aan de recommendations, dan zal je dat niet krijgen. In de RFC staat namelijk:

The "Expires" field indicates the date and time after which the data contained in the "security.txt" file is considered stale and should not be used (as per Section 5.3). The value of this field is formatted according to the Internet profiles of [ISO.8601-1] and [ISO.8601-2] as defined in [RFC3339]. It is RECOMMENDED that the value of this field be less than a year into the future to avoid staleness.

Bron

Aangezien het geen eis is van de RFC ben je nog altijd afhankelijk van de implementatie van het bedrijf. Als je echter de moeite neemt deze RFC te implementeren mag je er wel vanuit gaan dat je dus geen rare capriolen krijgt met expiry dates in 2036 of nog later.

[Gamebuster]

mag je er wel vanuit gaan dat je dus geen rare capriolen krijgt met expiry dates in 2036 of nog later.

Ik ben zeer sceptisch. Denk je echt dat iemand een procedure maakt om dat bestand te updaten?

Ik zie anders wel zoiets gebeuren:

Expires: {new Date().setYear(new Date().year + 1).toISOString()}

- En daarna kijkt niemand er ooit meer naar en vergeet men dat het bestaat.

[Reactie gewijzigd door Gamebuster op 29 juli 2024 18:39]

[sOid]

Ik ben zeer sceptisch. Denk je echt dat iemand een procedure maakt om dat bestand te updaten?

Als dit onderdeel van een PDCA-cyclus wordt; ja. Dat kun je ook prima in een ISMS vastleggen. Zou me ook niet verbazen als security.txt onderdeel wordt van de nieuwe BIO die vermoedelijk eind dit jaar wordt vastgesteld. Een proces rondom responsible disclosure is in de huidige versie al een eis.

Ik heb het net laten implementeren op de belangrijkste servers van mijn werkgever (overheidsorganisatie). Het grootste probleem is echter het borgen van die bestanden op alle servers. Want implementeren op (hoofd)domein is niet zo'n punt, maar er zijn natuurlijk allerlei servers, vaak alleen via IP-adres bereikbaar, waarop het ook moet staan. (Althans, dat is wel verstandig.) En dat zijn bij SaaS-leveranciers vaak ook gedeelde servers. Gedoe dus.

[hexeye]

Precies dit gedaan mbt ISMS. Wat file betreft, geen idee hoe het er bij je uitziet, maar kan die micro txt niet mee met de deployment van die website zelf?

[maplebananas]

Ahh, je was me voor haha

[hexeye]

Ik heb een procedure gemaakt om dat periodiek door een mens te laten updaten, dus: ja.

[maplebananas]

<?php
$oneYearOn = date('Y-m-d',strtotime(date("Y-m-d", mktime()) . " + 365 day"));
?>

[Reactie gewijzigd door maplebananas op 29 juli 2024 18:39]

[StefanJanssen]

Dan heb jij je plicht gedaan door contact op te nemen en daarna kan de pers contact met de overheid opnemen.

[kodak]

Dat kon al, maar toen gingen mensen klagen dat ze niet gemakkelijk genoeg een adres om te klagen meende te kunnen vinden. En daar zou dit dan de oplossing voor zijn, door er mogelijkheden in te bouwen die het probleem niet verhelpen.

[StefanJanssen]

Dat bedoelde ik daarmee dus ook. Als bedrijven dus die datum op 2999-12-31 zetten, hebben ze alleen zichzelf ermee als het niet up to date blijft. Als onderzoeker heb jij je taak correct uitgevoerd, waarna de pers de enige andere oplossing is.

[kodak]

Daar heb je geen klacht over security.txt voor nodig. Je kan namelijk nu al terecht klagen als de overheid niet voldoende aan responsible disclosure doet.

Het lijkt me nu juist niet de bedoeling dat het opleggen van extra regeltjes als doel heeft dat we daar dan over kunnen klagen bij een adres waar je duidelijk die security.txt niet voor nodig hebt.

[rvt1]

Wat ik niet zo goed snap is dat we al een whois hadden..

Op een gegeven moment ging iedereen deze op anonymous zetten omdat spammers dit ook wel door hadden, lekker goede werkende email addressen.. en dus ging iedereen daar wat anders invullen...

Met security.txt heb je nu weer precies hetzelfde.. Scammers gaan weer lekker deze file erbij pakken en zo iedereen spammen.

Welk probleem gaan we nu oplossen met een security terwijl er al whois bestaat?

Over 2 jaar... iedereen gaat weer security.txt uitzetten want scammers...

[TijsZonderH]

Whois is alleen bedoeld voor algemene contactinformatie. Als een bedrijf een klein beetje security serieus neemt is dat niet de info waar je hackers heen wil leiden bij CVD.

[rvt1]

Als je kijkt naar rfc3912 (WHOIS Protocol Specification) dan staat er helemaal niet in dat het voor algemene contact informatie is.
Als je voorts ook bv kijkt naar Extensible Provisioning Protocol (EPP) dan heeft dat ook niet met contact info te maken.

Ze hadden hier wat mij betreft prima WHOIS voor kunnen gebruiken door een extentie te maken op WHOIS, en niet als een 'hack' over http(s).

[kodak]

De vindbaarheid eenduidiger maken heeft weinig nut als er vervolgens geen eenduidig werkend adres is. Je kan nu al kiezen tussen Whois gegevens, een contactformulier, een centraal meldpunt enz. Deze oplossing maakt het alleen eenduidig waar je nog meer kan zoeken, niet dat iemand die de oplossing weet te vinden er ook echt meer vanuit kan gaan dan andere bestaande oplossingen.

Die einddatum is meer van hetzelfde. Laat het verlopen en je hebt de zelfde situatie als nu: zoek maar uit welk adres wel werk. Maak het 'actueel' met een onrealistisch datum bij de processen: wel een datum hebben, geen actuele gegevens, en je mag het net als nu uitzoeken wat wel werkt.

Het is basiskennis dat extra technische oplossingen voor bestaande oplossingen niet zomaar een oplossing zijn, laat staan beter. Je hebt er niet zomaar gemak door, het is er niet zomaar eenduidiger mee, het vraagt net als bestaande oplossingen om meewerken, opnemen in processen en onderhoud. De rfc legt dat niet op en dit tot extra oplossing maken ook niet.

[Anoniem: 52706]

Daar voorziet de RFC ook in. De einddatum is daarin een verplicht veld dus dwingt de standaard je de file actueel te houden.

Ja, dat zou "de standaard" moeten zijn, alleen is het een kwestie van een rewrite te gebruiken waarbij security.txt verwijst naar (bijvoorbeeld) een PHP-Script die de expires iedere keer update. Zorg je er daarnaast voor dat in je headers ook meteen PHP expose wordt verborgen en de Last-modified wordt meeveranderd en er is geen hond die kan nagaan of het legit is.

[Reactie gewijzigd door Anoniem: 52706 op 29 juli 2024 18:39]

[Sjaakys]

Wat ik mij afvraag. Als je in de security.txt info als email adressen plaatst, zijn deze makkelijk uit te lezen? Dit werkt spam enorm in de hand als email adressen van bijvoorbeeld de IT / HRM voor het grijpen liggen.

[TijsZonderH]

Spam is idd een probleem. De standaard voorziet daarin doordat je in plaats van een e-mailadres ook een link naar een contactpagina of extern platform kunt plaatsen. Maar dat is vooral ook pleisters plakken.

[The Zep Man]

Spam is idd een probleem. De standaard voorziet daarin doordat je in plaats van een e-mailadres ook een link naar een contactpagina of extern platform kunt plaatsen.

Je kan natuurlijk een e-mailadres obfusceren, of een contactpagina voorzien van een captcha-achtig iets.

Wat je ook kan doen is een e-mailadres aanbieden als optie, maar gebruik van S/MIME of PGP afdwingen. Het invulformulier gebruik je dan als fallback (en als plek om meer informatie te geven over S/MIME en PGP).

[Reactie gewijzigd door The Zep Man op 29 juli 2024 18:39]

[Bender]

Hoe wil je dit dan obfusceren? Want als je browser het kan begrijpen, kan een bot dat ook.

[The Zep Man]

"The email address can be found at https://domain.ext/rp"

Op die webpagina publiceer je een afbeelding met het e-mailadres erin.

Een alternatief is iets als:
responsibleREMOVEALLCAPSdisclosure <at> domainDUMMY <dot> ext

[Bender]

Afbeeldingen worden tegenwoordig ook al gelezen door bots, dus daar ga je je helaas niet mee redden.

responsibleREMOVEALLCAPSdisclosure <at> domainDUMMY <dot> ext

Dit kan, mits ze dit niet allemaal gaan doen. Waarbij je <at> en <dot> al niet meer kan doen omdat dit al geconverteerd wordt bij de meeste bots.

EDIT:
ChatGPT maakt er al dit van

Please contact us at The email adres states responsibleREMOVEALLCAPSdisclosure <at> kpnDUMMY <dot> com

What is the email adres?

Met als resultaat

The email address is [e-mail].

Dus dat heeft ook al geen zin meer.

[Reactie gewijzigd door Bender op 29 juli 2024 18:39]

[The Zep Man]

Afbeeldingen worden tegenwoordig ook al gelezen door bots, dus daar ga je je helaas niet mee redden.

Het is drempelverhogend, niet oplossend. Laat perfect niet in de weg staan van goed.

Verder is S/MIME of PGP afdwingen (het liefste een keuze daarin) ook een mogelijkheid.

[Verwijderd]

S/MIME of PGP is geen optie voor de overheid gezien het beheer hiervan letterlijk een nachtmerrie is in een beetje netwerk. Dat is ook de reden dat het nooit een succes is geworden. Tevens werkt het niet samen met goed samen met moderne werkplek oplossingen (Webmail, Outlook, Teams, jaja de overheid zit vast in Microsoft).

Voor een individuele journalist is het wel een optie.

[aikebah]

S/MIME of PGP is geen optie voor de overheid gezien het beheer hiervan letterlijk een nachtmerrie is in een beetje netwerk.

Best een overkomelijk issue, want je hoeft alleen het 1st line security triage team maar van S/MMIME en PGP capable software te voorzien. Het is niet alsof in je security.txt alle ambtenaren benoemd worden. Enkel het contactpunt voor CVD.
Die kan evt gevoelige data vervolgens met de standaard gebruikte interne beschermingsmaatregelen doorzetten.

[Verwijderd]

Dat is waar, je kan individuele personen daarmee uitrusten. Maar dat is wel weer meer onderhoud wat betaald moet worden en dat zal geen eenvoudige discussie zijn om te verdedigen... Verder zitten er uiteraard nog meer probleempunten aan zoals backup van de versleutelde data en de overheid heeft registratieplicht communicatie.

Allemaal niet onoverkomelijk maar wel erg lastig (=kosten). Ik had persoonlijk zelf liever een nieuwe brede en open standaard gezien die deze problemen aanpakt. Dat zouden we dan ook breder in kunnen zetten. Daarom ben ik zelf meer voorstander van eerst de huidige (prima) standaarden doorvoeren zoals SPF, DKIM en DMARC.

[aikebah]

Alleen die standaarden helpen je niets verder op het gebied van wat belangrijk is voor CVD: de echt interessante info onder de pet houden totdat het lek gedicht is. Dat is waarom S/MIME en PGP ingezet worden: de exploit details versleutelen zodat alleen de bedoelde ontvanger ze kan inzien.

[Verwijderd]

Nee, dat klopt. Maar daarom geef ik ook aan dat ik graag een nieuwe brede en open standaard zou willen zien.

[aikebah]

Oftewel... https://xkcd.com/927/

[Verwijderd]

Het is niet zo dat er veel standaarden zijn op dat gebied en S/MIME en PGP zijn stokoud...
We praten over zaken uit 1990, vrijwel iedere andere standaard is verder geëvolueerd of uitgefaseerd.

[nandervv]

Overheid moet volgens mij accessible zijn, en dit werkt niet voor mensen met een visuele beperking.

[The Zep Man]

Dan is S/MIME en/of PGP een optie. Verder werd ook al geopperd om een invulformulier te gebruiken. Goede captcha's hebben ook een alternatief gebaseerd op geluid.

Dat de overheid toegankelijk moet zijn houdt niet in dat elk communicatiekanaal toegankelijk moet zijn. Zolang het er maar minstens één is.

[Reactie gewijzigd door The Zep Man op 29 juli 2024 18:39]

[Gamebuster]

Ik dacht, ChatGPT kan dat wel fixen!

> What is the e-mail address?
>
> responsibleREMOVEALLCAPSdisclosure <at> domainDUMMY <dot> ext
< The email address is [e-mail].
> that doesn't seem right
< I apologize for my mistake. The correct email address would be responsible [at] domain [dot] ext. Please replace [at] with @ and [dot] with . to form a valid email address.
> can you replace the at and dot?
< Certainly, the email address would be [e-mail].

Helaas

[Reactie gewijzigd door Gamebuster op 29 juli 2024 18:39]

[Bender]

Ligt aan je vraagstelling

Please contact us at responsibleREMOVEALLCAPSdisclosure <at> kpnDUMMY <dot> com

What is the email adres?

ChatGPT resultaat

The email address is [e-mail].

[Gamebuster]

ah, ik had om "adres" moeten vragen ipv "address"

[Anoniem: 52706]

Of je vraagt ChatGPT gewoon om de Responsible Disclosure informatie zelf i.p.v. om een e-mall adres om te zetten....

Bijvoorbeeld:

Wat is de responsible disclusure informatie van de Gemeente Amsterdam ?
De Gemeente Amsterdam heeft een responsible disclosure beleid voor het melden van kwetsbaarheden in haar ICT-systemen. Als u een kwetsbaarheid heeft ontdekt, kunt u deze melden via de volgende kanalen:

E-mail: [e-mail]
Telefoon: +31 XX YYY ZZZZ (Alleen tijdens kantooruren)
Website: https://www.amsterdam.nl/...m/responsible-disclosure/
Op deze website vindt u meer informatie over het melden van kwetsbaarheden, inclusief de voorwaarden en richtlijnen voor het melden. Het is belangrijk om te weten dat de Gemeente Amsterdam kwetsbaarheden alleen in behandeling neemt als ze op een verantwoordelijke manier worden gemeld en als de melder zich houdt aan de gestelde voorwaarden.

Daarbij zijn de links direct aanklikbaar

Of deze...

Wat is de responsible disclusure informatie van Tweakers ?
Tweakers heeft een responsible disclosure beleid voor het melden van kwetsbaarheden in haar systemen. Als u een kwetsbaarheid heeft ontdekt, kunt u deze melden via e-mail naar [e-mail].

Op de website van Tweakers is een pagina gewijd aan responsible disclosure, waar u meer informatie kunt vinden over het beleid en de procedure voor het melden van kwetsbaarheden. Deze pagina bevat ook richtlijnen voor het melden van kwetsbaarheden en informatie over wat u kunt verwachten nadat u een kwetsbaarheid heeft gemeld.

Let op: Het is belangrijk om te weten dat Tweakers kwetsbaarheden alleen in behandeling neemt als ze op een verantwoordelijke manier worden gemeld en als de melder zich houdt aan de gestelde voorwaarden.

[Reactie gewijzigd door Anoniem: 52706 op 29 juli 2024 18:39]

[bwerg]

Je browser hoeft het niet te kunnen begrijpen, alleen weer te geven.

Nou kun je in theorie een scanner/scraper bedenken die geautomatiseerd security-analyses uitvoert en problemen automatisch meldt, en daarvoor zou machine-leesbare contactinformatie nuttig zijn. Maar dat zal niet het typische gebruik zijn, en zelfs al is het dat wel, dan is het nog steeds niet gek om even met de hand de problemen af te gaan en handmatig te melden (zolang het niet om 1000+ websites gaat).

[Bender]

Je browser hoeft het niet te kunnen begrijpen, alleen weer te geven.

Precies, als een browser het kan weergeven dan kan een bot het dus ook scrapen.
Het ging juist ook om het misbruik, niet om het melden, maar voor opname in spam databases.

[bwerg]

Precies, als een browser het kan weergeven dan kan een bot het dus ook scrapen.

Niet per se, alleen als het als letterlijk als plain-text is weergegeven.

Als de weergave een link naar een plaatje is met een tekst (bonuspunten voor een font dat lastig te OCR'en is) gaat een spammer daar niks mee doen. Of ook vrij gangbaar, een makkelijk mini-puzzeltje om achter het mail-adres te komen. Dus geen "[e-mail]" maar "<mijn voor- en achternaam aan elkaar>@hetnet.nl" met daarboven duidelijk dat het de website van Bertje van den Broek is.

[Reactie gewijzigd door bwerg op 29 juli 2024 18:39]

[Bender]

Tegenwoordig zijn bots veel slimmer dan alleen plain text te kunnen lezen, veel renderen gewoon de browser.
De puzzeltjes zijn op dit moment een oplossing (mits ze niet door iedereen gebruikt worden), maar nu met ChatGPT is de vraag of dat binnenkort niet ook verleden tijd is.

[bwerg]

Met browser renderen kun je nog steeds het lezen en gebruiken van text niet automatiseren. OCR kan wel daar is eenvoudig iets tegen te doen (wat moeilijkere fonts gebruiken of ruis in je plaatje toevoegen).

[Bender]

Een bot maakt ook gebruik van verschillende technieken, het is niet techniek A of techniek B, het is alle technieken die de pagina controleert op bruikbare informatie.

Een font moet tegenwoordig ook wel zo onleesbaar zijn, gezien veel captchas (en recaptcha!) ook al methoden voor zijn om die af te vangen.
(en dat is niet 100% proof, maar dat hoeft ook niet)

[JorisIH]

Ik ben het met je eens dat het een kat en muis spel is
Maar ChatGPT is veel meer een taal model AI, die kan (denk ik??) Weinig met afbeeldingen selecteren..

[Bender]

ChatGPT staat los van de afbeelding, maar een techniek die er los van staat om de tekst op een pagina te interpreteren.

Meteen even getest met ChatGPT

Mijn naam is Pietje Puk en mijn email adres is voornaam + achternaam @kpn.com. Wat is mijn email adres

Resultaat

Uw e-mailadres is [e-mail].

[bwerg]

Heeft 'ie dus mooi fout, want hij heeft zelf een punt toegevoegd.

[Bender]

Gelukkig zijn er dan ook weer databases die geindexeerd hebben wat de opbouw van de email adressen van een domein zijn om daar uitsluitsel over te krijgen.

Overigens maakt het bij Gmail/Google Workspace niet eens uit waar de . staat.
Bij Office 365 weet ik het niet, ze hebben wel plus addressing tegenwoordig maar de . weet ik niet wat dat daar doet.

[TijsZonderH]

Wat je ook kan doen is een e-mailadres aanbieden als optie, maar gebruik van S/MIME of PGP afdwingen. Het invulformulier gebruik je dan als fallback (en als plek om meer informatie te geven over S/MIME en PGP).

Inderdaad, en dat staat ook in de standaard opgenomen dus dat zou zeker een prima oplossing kunnen zijn.

[Opperpanter2]

Is het hele idee van die security.txt is juist dat het machine readeable is? Zodat je bv geautomatiseerd bedrijven/beheerders kunt informeren over gevonden lekken e.d.?
Meestal zijn die mailboxen niet zo moeilijk te raden bv [e-mail]. Je kunt alles gaan obfuscaten, maar ik zelf maak de drempel het liefst zo laag mogelijk.

[TijsZonderH]

Nee, het voornaamste idee is dat beveiligingsonderzoekers niet hoeven te zoeken naar securityinformatie. Je wil juist niet dat onderzoekers moeten gaan raden waar je ze heen moeten mailen. Soms kun je naar [e-mail], maar andere keren weer naar info@, of contact@, of beveiliging@, of je moet naar HackerOne, of je moet een algemeen contactformulier invullen... Niet om mezelf te promoten maar ik zou het interview met de bedenker eens lezen, hij beschrijft de frustraties van onderzoekers erg goed imo.

[Opperpanter2]

Dat is toch wat ik zeg? Niet obfusceren zoals hierboven wordt geopperd, maar gewoon de contact info leesbaar in security.txt zetten. Spam krijg je toch wel. Security.txt is niet alleen bedoeld om de contactinformatie vast te leggen, maar om data te doen in een machine readeable en vastgelegd formaat.

[aikebah]

een machine readeable

Dat is niet het hoofddoel, maar 'algemene gestandaardiseerde locatie' en beschikbaarheid van relevante info zodat een security researcher niet op zoek hoeft

[Reactie gewijzigd door aikebah op 29 juli 2024 18:39]

[bvdbos]

Er zijn een aantal "verplichte" mailadressen waaronder [e-mail] :
https://www.rfc-editor.org/rfc/rfc2142

[The Zep Man]

Most organizations do not need to support the full set of mailbox names defined here, since not every organization will implement the all of the associated services. However, if a given service is offerred, then the associated mailbox name(es) must be supported, resulting in delivery to a recipient appropriate for the referenced service or role.
(...)
ABUSE Customer Relations Inappropriate public behaviour

ABUSE is niet 'verplicht' (een 'rfc' is nooit verplicht, maar er niet aan conformeren kan nadelig zijn) als je geen PR-afdeling hebt. Verder zou SECURITY logischer zijn in de context van het nieuwsartikel.

[Reactie gewijzigd door The Zep Man op 29 juli 2024 18:39]

[aikebah]

rfc2142 is een proposed standard die het uiteindelijk niet geschopt heeft tot de internet standard status... net een trapje lager (al kan het zeker geen kwaad om ze te volgen)

[NLxDoDge]

Het is net als de robots.txt gewoon een leesbare file door iedereen, dus een e-mail daarin zetten is geheid vragen om spam te krijgen ja.

Maar aan de andere kant, dan zou je een soort van systeem moeten hebben als GitHub om een issue te kunnen melden voor de software. Ik snap wel dat niet iedere developer zijn eigen oplossing daarvoor gaat hosten. Maar de globale overheid zou hier wel een stap in kunnen maken.

[Terrestrial]

Elke site heeft zoiets als een postmaster, webmaster, admin, contact, abuse whatever email adres, en die zijn toch wel te raden. Die moet je er in zetten, niet een prive email adres.

[bvdbos]

Ook daarvoor is een RFC die samenvat wat in diverse andere RFC's geeist wordt:
https://www.rfc-editor.org/rfc/rfc2142

[Zebby]

Klopt, ik kreeg laatst een melding van een pentest rapport (wel als info) dat we een contact e-mailadres hadden voor support, dat zou social engineering makkelijker maken. Ik bedoel, I guess? Contact pagina's krijgen ook spam.
Kijken of ik deze er door krijg, vind het wel zo netjes.

[uiltje]

Da's een beetje een vreemde. Bij social engineering heb je het bijna automatisch over een gerichte aanval. Bij zo'n aanval zou ik zelf verwachten dat de contactgegevens wel bekend zijn - publiek genoeg om de aanval uit te kunnen voeren tenminste.

[jeroen79]

Is dat geen security by obscurity?
Mailen naar [e-mail] is voor de hand liggend maar ben je veel veiliger als je er [e-mail] of [e-mail] van maakt?
Die laatste zijn ook niet moeilijk te bedenken.
En je support achter [e-mail] zetten is ook niet werkbaar.

Dan kun je beter de mensen die daar werken goed onderwijzen over social engineering, phishing, etc.

[Zebby]

Tja, pentesters noteren ook alleen maar wat er uit Burpsuite komt
Op persoonlijke titel zou ik afraden, maar een generieke box vind ik inderdaad onzin. En scanners gaat emailadressen vinden, hoe lastig je het ook maakt. Een snelle LinkedIn en je weet ook al wat namen om mee te gaan vissen wat dat betreft.

[StephanVierkant]

De screenshot uit het artikel laat ook zien dat je niet per se een e-mailadres hoeft te tonen, het mag ook een url zijn naar een contactpagina. Dat ligt ook meer voor de hand, omdat je dan ook gelijk kunt uitleggen hoe je iets veilig kunt melden (bijv. PGP) en of er nog meer eisen/wensen zijn die je stelt aan het melden van beveiligingsproblemen.

[Iblies]

Het werkt wel twee kanten op,
je spam-lijst kan dan worden uitgebreid 🙂

[Tokidoki]

Wat ik nog niemand heb zien antwoorden is dit:
De security.txt heeft een veld geldigheid. Wat je gemakkelijk kan doen is elke dag een nieuw e-mail-proxyadres online zetten met een bepaalde geldigheidsduur + marge.
Je kan dan óf dat na die geldigheidsduur sowieso blokkeren, of je trekt pas e-mailadressen in nadat je er spam ontvangt.

[Anoniem: 1576590]

Tikkie off topic maar wellicht zou het "Forum Standaardisatie" eerst iets tegen de wildgroei aan domeinnamen bij de overheid moeten doen.

[ocn]

Zoiets? https://forumstandaardisa...regie-op-internetdomeinen
https://forumstandaardisa...netdomeinen-rijksoverheid
https://forumstandaardisa...regie-op-internetdomeinen
https://forumstandaardisa...-voor-de-grote-schoonmaak
https://forumstandaardisa...dweilen-met-de-kraan-open
https://forumstandaardisatie.nl/node/898

[Reactie gewijzigd door ocn op 29 juli 2024 18:39]

[Anoniem: 1576590]

In die pagina's lees ik dat het niet goed gaat, maar ik zie zo snel niks over een "pas toe of leg uit" item om dit probleem op te lossen.

In plaats daarvan staat bijv. in de eerste pagina die je noemt:

Dienst Publiek en Communicatie (DPC) van het Ministerie van Algemene Zaken is verantwoordelijk voor de uitvoer van het domeinnaambeleid van de Rijksoverheid

(weer zo'n krankzinnige domeinnaam, "communicatierijk.nl" - alsof andere websites van "Rijk" niet bedoeld zijn voor communicatie - Microsoft gebruikt toch ook niet iets idioots als microsoftonline.com).

In elk geval is die DPC een major fuckup want ze bakken er overduidelijk helemaal niks van.

Een hoop gejank uit Den Haag dat het internet veiliger moet: kijk eerst eens in de spiegel.

[kodak]

Wat heeft dat met deze consultatie te maken? Want meer domeinen wil niet zomaar betekenen dat je minder makkelijk contact kan opnemen voor beveiligingsproblemen. Daar is deze mogelijke verplichting voor contactgegevens juist voor.

[Anoniem: 1576590]

Het gaat over websites en security, en ik schreef erbij "tikkie off-topic".

Bovenal vind ik mijn aandachtspunt een veel groter probleem waar het forum standaardisatie aandacht aan zou moeten schenken, dan aan security.txt.

Je zou ook op elke website kunnen zetten dat je kunt mailen naar het NSCS (wat de meeste securitymensen allang weten) of naar abuse@overheiddotnl.

En wat heb je aan "security.txt" als de domeinnaam ondertussen in andere handen is gevallen en burgers op zo'n site worden opgelicht?

[ocn]

Ehh, Erik... daar schenkt Forum Standaardisatie toch aandacht aan? Zie mijn eerdere reactie op jouw initiële bericht. Zelfs vandaag nog is er een verhaal verschenen over het beheren van websites:

Om er grip op te krijgen, begon het projectteam met een totaalinventarisatie van alle domeinen en sites. Bij het opbouwen van dit domeinnaamportfolio brachten we ook direct in kaart in hoeverre de publieke sites voldeden aan de vereiste standaarden. Sites en domeinen die geen bestaansrecht meer hadden, haalden we direct uit de lucht.’

Link: https://forumstandaardisa...ge-en-toegankelijke-sites

[Anoniem: 1576590]

Ik mis een "pas toe of leg uit" item hiervoor. Zie ook mijn andere reactie op jouw eerdere stelling.

[ocn]

Pas toe of leg uit beleid geldt voor standaarden voor digitale gegevensuitwisseling. Domeinnaambeleid is een andere niche.

[Anoniem: 1576590]

Pas toe of leg uit beleid geldt voor standaarden voor digitale gegevensuitwisseling. Domeinnaambeleid is een andere niche.

Niet als je een domeinextensie verplicht stelt, zoals .gov.nl waar al jaren over getrut wordt, bijvoorbeeld 10 jaar geleden en afgelopen oktober - maar het blijft bij tRutten.

Bovenaan https://www.fbi.gov/:

An official website of the United States government. Here's how you know

• Official websites use .gov
  A .gov website belongs to an official government organization in the United States.
• Secure .gov websites use HTTPS
  A lock (🔒) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Laat ik eens op een site van de Nederlandse Overheid kijken:
https://websiteregisterrijksoverheid.nl/.

Met curl zie ik o.a.:

Server certificate:
* subject: C=NL; ST=Zuid-Holland; L='s-Gravenhage; O=Rijksoverheid; CN=minaz.nl
* start date: Nov 9 19:34:34 2022 GMT
* expire date: Nov 9 19:29:00 2023 GMT
* subjectAltName: host "websiteregisterrijksoverheid.nl" matched cert's "websiteregisterrijksoverheid.nl"
* issuer: C=NL; O=QuoVadis Trustlink B.V.; CN=QuoVadis Europe SSL CA G2
* SSL certificate verify ok.

Nou, dat lijkt mij wel een domeinnaam van de Overheid.

Met Firefox word ik doorgestuurd naar (effectief, ik heb ? en alles daarachter verwijderd): https://www.communicatier...iteregister-rijksoverheid.

Vragen:
1) Hoe weet ik, met Firefox onder Android, of Safari onder iOS/iPadOS, of dit echt een website van de overheid is, en de .ODS file die ik daar kan downloaden, veilig is? Bovenaan die pagina (en andere overheidswebpagina's) staat, in tegenstelling tot op veel .gov sites, niets over hoe je weet of dit wel of niet een website van de overheid is.
"Nee wij zijn geen betrouwbare overheid, zoek het lekker zelf uit!"

2) Als notabene hun eigen domeinnaam "websiteregisterrijksoverheid.nl" al niet in vóórkomt in "Websiteregister Rijksoverheid (ODS, 181 KB): januari 2023 (actuele versie)", hoe betrouwbaar is dat register dan?

Wat een puinhoop

[Reactie gewijzigd door Anoniem: 1576590 op 29 juli 2024 18:39]

[Floort]

Het doel zoals ik 'm begrijp is hoofdzakelijk: grootschalige notificatie van security problemen mogelijk maken. Het hebben van een security.txt maakt het de melder en de ontvanger makkelijker. Als je honderd sites vind met een issue weet je niet altijd van tevoren of er ook overheidssites tussen zitten en zo ja, welke?

[kodak]

Je maakt er het onderwerp domeinnamen van, dat is niet het nieuws of de discussie. Maar om het dan ontopic te maken: domeinnamen van de overheid mogen al enkele jaren niet meer vervallen. Daarom moeten ze daar ook centraal geregistreerd worden. Dat register staat online. Moet het wel op tijd bijgehouden worden, net als die security.txt. Daar zijn standaarden juist voor: de bedoeling is dat de overheid zich aan de eigen standaarden weet te houden. Ik ben het met je eens dat dit er niet zomaar voor zorgt en deze oplossing dat ook niet gaat doen tenzij er controle op is en het valt te melden.

[Anoniem: 1576590]

Door kodak:

Maar om het dan ontopic te maken: domeinnamen van de overheid mogen al enkele jaren niet meer vervallen. Daarom moeten ze daar ook centraal geregistreerd worden. Dat register staat online. Moet het wel op tijd bijgehouden worden, net als die security.txt. Daar zijn standaarden juist voor: de bedoeling is dat de overheid zich aan de eigen standaarden weet te houden.

Nou, dat gaat lekker dan.

Bijvoorbeeld onderaan deze pagina van forumstandaardisatie.nl zie ik de volgende link genoemd worden:

http://websiteregisterrijksoverheid.nl/

Notabene die domeinnaam
(websiteregisterrijksoverheid.nl) komt niet eens voor in hun actuele lijst
"Websiteregister Rijksoverheid (ODS, 181 KB): januari 2023 (actuele versie)".

Hoe betrouwbaar is dat register dan?

Een clickable link met die domeinnaam vind je onderaan de laatste pagina in deze PDF van 15 feb 2019, dus het is niet zo dat het om een gloednieuwe domeinnaam gaat.

Op internet zoeken naar:
"://websiteregisterrijksoverheid.nl"
levert nog meer hits op.

Nb. die domeinnaam beschreef ik eerder ook hier.

[Moartn]

Niet helemaal off topic imho. Die enorme hoeveelheid websites zorgt er namelijk voor dat vrijwel niet te doen is dat de overheid aan dit soort verplichte standaarden (hun eigen standaarden!) voldoet. Nu is dat bij security.txt niet zo heel spannend, maar bij toegankelijkheidseisen ("drempels weg") bijvoorbeeld is dat toch erg relevant. Ook het securitytechnisch up-to-date houden val al die verschillende sites zal ongetwijfeld erg lastig zijn.

[Anoniem: 1576590]

Die enorme hoeveelheid websites zorgt er namelijk voor dat vrijwel niet te doen is dat de overheid aan dit soort verplichte standaarden (hun eigen standaarden!) voldoet.

Daarnaast, gegeven een willekeurige domeinnaam, is het steeds moeilijke om vast te stellen wie de eigenaar is van een website. Zelfs als je in staat bent (en er de tijd voor neemt) om een https servercertificaat te bekijken, blijkt het steeds vaker om een "Domain Vaildated" exemplaar te gaan. En dat zegt nul-komma-niets over wie de eigenaar is.

Google is also your enemy.

Last but not least: het ontbreken van een exit-strategie. Zodra het geldpotje leeg is of de initiërende malloot bij een ander overheidseilandje aan de slag is gegaan en daar haar of zijn registratiedrang verder uitleeft, "houdt een website op te bestaan" - maar niet de domeinnaam.

Wat als deze in verkeerde handen valt? Wiens schuld is het als burgers worden opgelicht en/of hun vertrouwelijke gegevens worden ontfutseld? Wellicht ook omdat zij mailen naar destijds of juist nu op zo'n site genoemd e-mailadres met dezelfde domeinnaam?

Dit is geen nieuw probleem, uit 2015
Politie laat geregistreerde domeinnamen verlopen maar ook deze en deze.

Wat heb je aan "security.txt" op een website die ondertussen van een ander is?

Aanvulling 11:10: en hoe ga je alle links naar opgeheven (in andere handen gevallen) websites opruimen? Die staan vaak op heel veel sites, niet alleen van de overheid. En wat kost dat eigenlijk, en wie gaat dat betalen?

[Reactie gewijzigd door Anoniem: 1576590 op 29 juli 2024 18:39]

[bwerg]

Zelfs als je in staat bent (en er de tijd voor neemt) om een https servercertificaat te bekijken

Die moeite neem ik voor belangrijke zaken vaak wel (voor zover de browser dat niet al probeert weg te stoppen, met name op mobiel). En dan zie je een of andere CA waar je nog nooit van gehoord hebt. Oke, mooi, man, en nu? Ook bij overheidswebsites worden er heel veel verschillende CA's gebruikt. Als dat er een is van het niveau letsencrypt zegt dat niets over de eigenaar of over de betrouwbaarheid.

[Anoniem: 1576590]

Die moeite neem ik voor belangrijke zaken vaak wel (voor zover de browser dat niet al probeert weg te stoppen, met name op mobiel). En dan zie je een of andere CA waar je nog nooit van gehoord hebt. Oke, mooi, man, en nu? Ook bij overheidswebsites worden er heel veel verschillende CA's gebruikt. Als dat er een is van het niveau letsencrypt zegt dat niets over de eigenaar of over de betrouwbaarheid.

Een https servercertificaat kan nooit iets zeggen over betrouwbaarheid, maar dat is niet anders dan in het echte leven weten wie iemand of een organisatie is.

Pas als je weet wie iemand of een organisatie is, kun je gaan onderzoeken (kort of lang, naar keuze) hoe betrouwbaar die identiteit tot nu toe was.

Maar die eerste stap daarbij (weten wie) is essentieel, en daar zouden https servercertificaten een belangrijke rol in kunnen vervullen, maar we hebben toegestaan dat dit gesloopt werd.

[jeroen79]

Je zou er een (semi-)overheidstaak van kunnen maken.
Richt een stichting op waaraan je een gevoelig domein wat je niet meer wil gebruiken kunt overdragen.
Die stichting houdt dat domein dan voor lange tijd (of zelfs voor altijd) onder zich.

Links naar de oude website komen dan uit bij een website van die stichting.
Die kan zeggen "dit domein is niet meer in gebruik" of wat meer gegevens doorgeven.

Dan kun je zelfs nog monitoren wat er op binnenkomt.
Mailt iemand persoonsgegevens naar [e-mail] dan valt dat op en krijgen [e-mail] en [e-mail] daarover een bericht.

De kosten verdeel je dan tussen de overheid (belastingbetaler) en de gebruiker van deze domeinen.
Als je de boete bij een datalek hoog genoeg maakt dan zullen de gebruikers de veel lagere kosten voor deze constructie ook wel willen dragen.

[Anoniem: 1576590]

Richt een stichting op waaraan je een gevoelig domein wat je niet meer wil gebruiken kunt overdragen.
Die stichting houdt dat domein dan voor lange tijd (of zelfs voor altijd) onder zich.

Maar dat is toch symptoombestrijding, en je verspilt belastinggeld en maakt het internet tot een puinhoop van grotendeels vervallen domeinnamen?

[jeroen79]

Hoe wordt het dan een puinhoop?
Alle domeinen die je niet in handen van kwaadwillenden wil hebben worden juist apart gezet zodat ze niet opnieuw gebruikt kunnen worden.

[Anoniem: 1576590]

Hoe wordt het dan een puinhoop?

Omdat mensen dan tevergeefs op links klikken die naar opgeheven websites wijzen?

Waarbij die websites in de eerste plaats al niet allemaal hadden moeten bestaan?

Heb je de uitzending van Arjen Lubach en Tex de Wit hierover niet bekeken?

Zie ook deze reactie van mij, eindigend op "Wat een puinhoop".

Alle domeinen die je niet in handen van kwaadwillenden wil hebben worden juist apart gezet zodat ze niet opnieuw gebruikt kunnen worden.

Wie schiet daar wat precies mee op?

D.w.z. anders dan de mensen die geld verdienen aan het beheer, waaronder updates uitvoeren, nieuwe encryptieprotocollen aanzetten en oude uit, https servercertificaten vervangen, onbedoeld ontvangen mail niet lezen (want mogelijk vertrouwelijk) maar wel beantwoorden "sorry wij bestaan niet meer, ga naar xyz voor meer informatie).

[jeroen79]

Waarom zou de hoeveelheid websites het vrijwel niet te doen maken?
Er zouden dan toch ook evenredig veel websitebeheerders moeten zijn?

[Moartn]

Theoretisch wel, maar die zijn er natuurlijk niet. Veel van die websites worden eenmalig gefinancierd en opgezet, en vervolgens is er geen geld voor onderhoud (zowel qua content als technisch).

[StephanVierkant]

Goed idee! Nu is het soms nog zoeken naar beleid ten aanzien van responsible disclosure. Zo zocht ik een tijdje geleden contact met de gemeente Amsterdam en kreeg te horen dat ze nog druk bezig waren met het ontwikkelen van beleid. Het leek dus alsof ze geen beleid hadden, maar kwam ik er per toeval achter dat ze onder de Informatiebeveiligingsdienst (IBD) van de VNG vallen, waardoor ze weer wél beleid hadden. Die onnodige verwarring zou niet bestaan met zo'n security.txt-file.

[F_J_K]

In het algemeen: een gemeente 'valt' niet onder de IBD, de IBD ondersteunt gemeenten en is CERT. IBD bepaalt geen beleid, al hebben ze wel voorbeelden die kunnen worden gebruikt.

Dan nog. 1 security.txt-file gaat niet werken. 1 beleid kan, maar dat zal rekening moeten houden met dat een beetje gemeente niet 1 site heeft. Er zijn tig sites bij tig SaaS-leveranciers. Waarbij kaart.gemeente.nl een andere leverancier is dan vergunning.gemeente.nl en weer anders dan gemeente.bezwaren.nl en webmail.gemeente.nl wat doorverwijst naar MS365.

Waarbij sommige leveranciers een bounty program hebben, een andere niet, en een derde gaat liefst met advocaten dreigen als er een portscan door een white hat volgt zodat je als gemeente daar geen vrijbrief gaat willen geven. En de gemeente niet 24/7 mensen paraat heeft maar sommige, niet alle, leveranciers wel.

[Floort]

De BIO (punt 16.1.3.1) verplicht het publiceren en inrichten van een CVD beleid. Dat omvat ook de leveranciers voor zover die nodig zijn voor het afhandelen van meldingen. Nu wil ik niet doen alsof het daarmee ook altijd netjes geregeld is, maar het is in ieder geval verplicht om het netjes te regelen.

[M3m3nt0m0r1]

Laat de overheid zich eerst maar eens bezig houden met belangrijkere zaken zoals een slecht presterend systeem bij de belastingdienst, de toeslagaffaire, compleet gebrek aan vertrouwen in de overheid, AVG binnen de overheid. Pas dan eens gaan kijken naar die security.txt.

[FreezeXJ]

Nee, juist niet. Die issues zijn te groot, ze proberen op te lossen gaat em niet worden. Ze zijn namelijk symptomen, en de hele overheid 'oplossen' gaat nogal even duren. Klein beginnen, en daarna groeien. Dit soort kleine aanpassingen in sites geven misschien de hint om bepaalde paginas uit te faseren, waardoor ze het leven simpeler gaan maken, omdat het zelfs voor managers onbetaalbaar wordt. Grote projecten kosten bakken geld, dus dan 'is er geld' voor een jaar ofzo. Kleine aanpassingen is geen extra budget voor (te krijgen), dus dat gaat doorberekend worden aan managers. En dan moeten ze bepalen of ze ook www.ouderotsite.nl willen updaten, of toch maar uitfaseren. Dan moet er iemand verantwoordelijk gehouden worden, en anders... poef!