Experts adviseren verplicht gebruik security.txt door Nederlandse overheid
Nederlandse overheden, zoals het Rijk, provincies, gemeenten en waterschappen en instellingen uit de publieke sector zouden moeten worden verplicht om gebruik te maken van security.txt, 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.
Het Forum Standaardisatie, een adviescommissie die de publieke sector adviseert over het gebruik van open standaarden en de adoptie en naleving van het open standaardenbeleid monitort, toetst nu of de standaard geschikt is om te verplichten aan de overheid. Overheden worden via de 'Pas toe of leg uit'-lijst van het Forum verplicht om bepaalde standaarden toe te passen.
"De standaard security.txt draagt bij aan een veiliger internet doordat meldingen over kwetsbaarheden in een dienst of systeem sneller terecht komen bij de juiste personen binnen een organisatie. Hierdoor kunnen kwetsbaarheden sneller worden verholpen en is de kans kleiner dat cybercriminelen kwetsbaarheden gebruiken", aldus het Forum. Dat stelt dat security.txt voldoet aan het criterium om aan de 'Pas toe of leg uit'-lijst toe te voegen, aangezien dit het gebruik van de standaard bevordert.
Via Internetconsultatie.nl kan er tot 12 maart op het advies worden gereageerd. "Experts stellen vast dat er voldoende ervaring en draagvlag is binnen de Nederlandse overheid voor security.txt. De standaard heeft een lage drempel voor de (technische) implementatie ervan. Er is ondersteuning beschikbaar (kennis en tools) vanuit de Nederlandse overheid die wordt voortgezet na verplichting van security.txt aan overheden", aldus een uitleg bij de consultatie.
Reacties (27)
Verplicht, verplicht, verplicht, verplicht. Zo kennen we de denkwijze weer. Trek die site dan maar gewoon offline, dan is het gez**k ook opgelost.
Als je nou wat wil melden, dan zou je bij een beetje redelijke organisatie iets naar info@xxx kunnen sturen en krijg je wel antwoord wie dat gaat regelen. Dat zal bij ambtenaren wat moeilijker liggen, want het staat niet op hun protocol of check lijstje. Of een dedicated email address dan wel succesvol is? Na een jaar is de informatie verouderd en verouderde informatie is doorgaans schadelijker dan geen informatie...
Als je nou wat wil melden, dan zou je bij een beetje redelijke organisatie iets naar info@xxx kunnen sturen en krijg je wel antwoord wie dat gaat regelen. Dat zal bij ambtenaren wat moeilijker liggen, want het staat niet op hun protocol of check lijstje. Of een dedicated email address dan wel succesvol is? Na een jaar is de informatie verouderd en verouderde informatie is doorgaans schadelijker dan geen informatie...
We hebben toch het https://www.ncsc.nl/actueel/beveiligingsadviezen ?
Zelf ook aangedragen bij het managment van woningbouwcoorporatie.
De manager (een kei in financiën maar een leek in tech) heeft het voorstel afgewezen omdat we "geen hackers willen uitnodigen". Uitgelegd dat het beleid uitnodiging is en een whitepaper van het NCSC doorgegeven.
Zijn reactie: "Maar wij ontwikkelen niets zelf, andere coorporraties hebben het ook niet. Al het tech is uitbesteed. Dit gaat we niet doen."
Zou dus mooi zijn als het verplicht is.
De manager (een kei in financiën maar een leek in tech) heeft het voorstel afgewezen omdat we "geen hackers willen uitnodigen". Uitgelegd dat het beleid uitnodiging is en een whitepaper van het NCSC doorgegeven.
Zijn reactie: "Maar wij ontwikkelen niets zelf, andere coorporraties hebben het ook niet. Al het tech is uitbesteed. Dit gaat we niet doen."
Zou dus mooi zijn als het verplicht is.
Door Anoniem: We hebben toch het https://www.ncsc.nl/actueel/beveiligingsadviezen ?
Inderdaad. Het melden van beveiligingsproblemen bij de overheid kan bij het NCSC. Zie:
https://www.ncsc.nl/contact/kwetsbaarheid-melden
Het NCSC zet vervolgens de melding door naar de juiste partij.
Voor elke app moet je dan een /.well-known/security.txt bestand aanmaken.
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Natuurlijk moeten de rechten goed staan en moet je de bestanden goed onderhouden, en bij elke edit kunnen de rechten weer fout gezet worden...
Dit idee is net zo slim als de beste sloten kopen en dan een kastje aan de muur hangen met een kopie sleutel en een sticker erop 'alleen voor de brandweer indien brand te gebruiken'....
Maar het idee kwam ook van mensen die india en bangkok hun security certificaten halen. waar je voor 200 euro zo'n cert kunt kopen.
Maar voor hackers is zo'n mapje met rechten waar je bestanden kunt dumpen voor een overflow erg handig..
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Natuurlijk moeten de rechten goed staan en moet je de bestanden goed onderhouden, en bij elke edit kunnen de rechten weer fout gezet worden...
Dit idee is net zo slim als de beste sloten kopen en dan een kastje aan de muur hangen met een kopie sleutel en een sticker erop 'alleen voor de brandweer indien brand te gebruiken'....
Maar het idee kwam ook van mensen die india en bangkok hun security certificaten halen. waar je voor 200 euro zo'n cert kunt kopen.
Maar voor hackers is zo'n mapje met rechten waar je bestanden kunt dumpen voor een overflow erg handig..
Door Anoniem: Voor elke app moet je dan een /.well-known/security.txt bestand aanmaken.
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
bedoel je nou dat je dat met de hand zou moeten doen? Als je 400 applicaties met de hand beheert lijkt de kans me groot dat je nog een heleboel andere problemen hebt.
Door Anoniem:
Inderdaad. Het melden van beveiligingsproblemen bij de overheid kan bij het NCSC. Zie:
https://www.ncsc.nl/contact/kwetsbaarheid-melden
Het NCSC zet vervolgens de melding door naar de juiste partij.
Door Anoniem: We hebben toch het https://www.ncsc.nl/actueel/beveiligingsadviezen ?
Inderdaad. Het melden van beveiligingsproblemen bij de overheid kan bij het NCSC. Zie:
https://www.ncsc.nl/contact/kwetsbaarheid-melden
Het NCSC zet vervolgens de melding door naar de juiste partij.
Het zal daarom niet verbazen dat een van de indieners van het voorstel voor de NCSC werkt.
Door Anoniem: Voor elke app moet je dan een /.well-known/security.txt bestand aanmaken.
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Als jij 400 apps op een host draait en hiervoor 400 mapjes gaat aanmaken dan beschik je niet over de juiste kennis om 400 apps op 1 host te draaien.
13-02-2023, 12:15 door
Valheru
Door Anoniem: Voor elke app moet je dan een /.well-known/security.txt bestand aanmaken.
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Natuurlijk moeten de rechten goed staan en moet je de bestanden goed onderhouden, en bij elke edit kunnen de rechten weer fout gezet worden....
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Natuurlijk moeten de rechten goed staan en moet je de bestanden goed onderhouden, en bij elke edit kunnen de rechten weer fout gezet worden....
Of je maakt 1 redirect in je webserver(s) die .well-known opvangt en verwijst die allemaal naar dezelfde locatie zodat je het verder maar 1 keer hoeft bij te houden.
Door Anoniem:
Inderdaad. Het melden van beveiligingsproblemen bij de overheid kan bij het NCSC.
Door Anoniem: We hebben toch het https://www.ncsc.nl/actueel/beveiligingsadviezen ?
Inderdaad. Het melden van beveiligingsproblemen bij de overheid kan bij het NCSC.
Leuk dat we dat binnen Nederland hebben afgesproken, en dat sommigen het ook uit hun hoofd weten, maar ik denk zomaar dat de gemiddeld Indiase securityresearcher die kennis wat minder paraat heeft. Precies om die reden is er een standaard bedacht waar iedereen kan vinden waar hij of zij een melding kan maken, onder welke voorwaarden.
Dit is misschien toch wel de meest zinloze uitvinding van de laatste 20 jaar... Sinds jaar en dag hebben we contactformulieren met captcha's en voor een goede reden. Wat je hiermee gaat krijgen is dat er allemaal geautomatiseerde scans voorbij komen die bij alles wat ook maar lijkt op een kwetsbaarheid automatisch gaat mailen in de hoop een bug bounty oid op te strijken.
13-02-2023, 15:41 door
-Peter-
Door Anoniem: Dit is misschien toch wel de meest zinloze uitvinding van de laatste 20 jaar... Sinds jaar en dag hebben we contactformulieren met captcha's en voor een goede reden. Wat je hiermee gaat krijgen is dat er allemaal geautomatiseerde scans voorbij komen die bij alles wat ook maar lijkt op een kwetsbaarheid automatisch gaat mailen in de hoop een bug bounty oid op te strijken.
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
Peter
Door -Peter-:
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
Peter
Door Anoniem: Dit is misschien toch wel de meest zinloze uitvinding van de laatste 20 jaar... Sinds jaar en dag hebben we contactformulieren met captcha's en voor een goede reden. Wat je hiermee gaat krijgen is dat er allemaal geautomatiseerde scans voorbij komen die bij alles wat ook maar lijkt op een kwetsbaarheid automatisch gaat mailen in de hoop een bug bounty oid op te strijken.
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
Peter
Waar baseer jij dat op?
Wat een onzin, alsof een textbestandje met daarin ook contactgegevens (en een encryptiesleutel) daar wat aan gaat veranderen.
Als jij 400 apps op een host draait en hiervoor 400 mapjes gaat aanmaken dan beschik je niet over de juiste kennis om 400 apps op 1 host te draaien.
Hoewel ik mij 0,0 verdiept heb in spruitjes.txt, klinkt jouw inbreng nogal patronizing, met weinig werkelijke duiding.Dit is misschien toch wel de meest zinloze uitvinding van de laatste 20 jaar... Sinds jaar en dag hebben we contactformulieren met captcha's en voor een goede reden. Wat je hiermee gaat krijgen is dat er allemaal geautomatiseerde scans voorbij komen...
Ik denk dat ik mijn RP records maar eens uit mijn DNS ga halen.Vermoedelijke een zelfde 100/0 ratio spam/zinvolle melding.
...die bij alles wat ook maar lijkt op een kwetsbaarheid automatisch gaat mailen in de hoop een bug bounty oid op te strijken.
In zo'n geval zou het toch doeltreffend te noemen zijn. Maar lijkt mij nogal hypotetisch.Ik vermoed meer dat we nog meer diensten aangeboden gaan krijgen die niet gratis zijn.
En dagelijks 20x de nummer 1 positie in Google.
Door Anoniem: Verplicht, verplicht, verplicht, verplicht. Zo kennen we de denkwijze weer. Trek die site dan maar gewoon offline, dan is het gez**k ook opgelost.
Als je nou wat wil melden, dan zou je bij een beetje redelijke organisatie iets naar info@xxx kunnen sturen en krijg je wel antwoord wie dat gaat regelen. Dat zal bij ambtenaren wat moeilijker liggen, want het staat niet op hun protocol of check lijstje. Of een dedicated email address dan wel succesvol is? Na een jaar is de informatie verouderd en verouderde informatie is doorgaans schadelijker dan geen informatie...
Als je nou wat wil melden, dan zou je bij een beetje redelijke organisatie iets naar info@xxx kunnen sturen en krijg je wel antwoord wie dat gaat regelen. Dat zal bij ambtenaren wat moeilijker liggen, want het staat niet op hun protocol of check lijstje. Of een dedicated email address dan wel succesvol is? Na een jaar is de informatie verouderd en verouderde informatie is doorgaans schadelijker dan geen informatie...
Kwetsbaarheden kunnen in allerlei vormen komen (platte tekst, scripts, executables en noem maar op). Dat wil je niet zomaar via de mail versturen - daar is dat niet voor bedoeld.
Dan kan je wel gaan zeiken over ambtenaren / de overheid, maar zij zitten in een heel andere positie: alles moet transparant en moet daarom op bepaalde manieren vastgelegd worden.
En nee, het is niet zo dramatisch als jij schetst. Hier zomaar een voorbeeld van een mooi CVD proces: https://www.ncsc.nl/contact/kwetsbaarheid-melden/cvd-meldingen-formulier
Door Anoniem:
Leuk dat we dat binnen Nederland hebben afgesproken, en dat sommigen het ook uit hun hoofd weten, maar ik denk zomaar dat de gemiddeld Indiase securityresearcher die kennis wat minder paraat heeft. Precies om die reden is er een standaard bedacht waar iedereen kan vinden waar hij of zij een melding kan maken, onder welke voorwaarden.
Door Anoniem:
Inderdaad. Het melden van beveiligingsproblemen bij de overheid kan bij het NCSC.
Door Anoniem: We hebben toch het https://www.ncsc.nl/actueel/beveiligingsadviezen ?
Inderdaad. Het melden van beveiligingsproblemen bij de overheid kan bij het NCSC.
Leuk dat we dat binnen Nederland hebben afgesproken, en dat sommigen het ook uit hun hoofd weten, maar ik denk zomaar dat de gemiddeld Indiase securityresearcher die kennis wat minder paraat heeft. Precies om die reden is er een standaard bedacht waar iedereen kan vinden waar hij of zij een melding kan maken, onder welke voorwaarden.
Zo maar even 2 overheidssites opgezocht (ze allemaal bezoeken gaat me te lang duren, zie https://www.security.nl/posting/784419/Domeinnamen+willekeur) en deze 2 hebben allebei een link naar de pagina van het NCSC:
https://www.defensie.nl/kwetsbaarheid-melden
https://www.rijksoverheid.nl/kwetsbaarheid-melden
Het kan dus wel
Door -Peter-:
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
Door Anoniem: Dit is misschien toch wel de meest zinloze uitvinding van de laatste 20 jaar... Sinds jaar en dag hebben we contactformulieren met captcha's en voor een goede reden. Wat je hiermee gaat krijgen is dat er allemaal geautomatiseerde scans voorbij komen die bij alles wat ook maar lijkt op een kwetsbaarheid automatisch gaat mailen in de hoop een bug bounty oid op te strijken.
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
En wil je totaal verlost zijn van alle meldingen, eis dan dat meldingen met PGP encrypted worden!
Tis niet mijn idee... het staat letterlijk in de RFC waar deze consultatie naar verwijst...
elke app moet een EIGEN map hebben... En natuurlijk kunnen de beheerders of zelfs klanten verschillend zijn, dus ja, ook de inhoud van security.txt is dan voor elke app verschillend.
voor de mensen die patronizing gebruikten, denk je echt dat als je 400 apps host dat die allemaal dezelfde beheerder hebben? laat staan een SME...
En dat die beheerder ook iets weet van de app zelf?
Vaak zijn de beheerders mensen die iets doen met firewalls of netwerken, of loadbalancers, of reverse proxies, niet perse mensen die SAP kennis hebben, of java of php of ruby enz enz. en als ze het al hebben dan vaak voor beheerstaken, niet voor applicatie taken.
Ik heb kleine SMB's gezien die 1400 apps hostten... Voor elke afdeling al snel 40 stuks, varierend van inscannen inkomende goederen tot aangifte douane... En elke afdeling werkt anders.. sommige alleen voor china, sommige alleen voor nederland, sommige alleen voor product x, sommige voor product x, y en z enz enz. dat de achterkant allemaal aan elkaar geknoopt is, soms zelf met blockchain wil niet zeggen dat de voorkant niet verschillend is...
Het hosten van een app specifiek txt bestand zoals de RFC vereist is dan overkill en levert meer werk op dan nodig. dus verplichten? kzie daar alleen mogelijkheden voor subsidiesponzen... of bepaalde security mensen die wel even laag komen overvliegen, alles onderpoepen en weer weg gaan als een 150 euro/uur dakduif...
elke app moet een EIGEN map hebben... En natuurlijk kunnen de beheerders of zelfs klanten verschillend zijn, dus ja, ook de inhoud van security.txt is dan voor elke app verschillend.
voor de mensen die patronizing gebruikten, denk je echt dat als je 400 apps host dat die allemaal dezelfde beheerder hebben? laat staan een SME...
En dat die beheerder ook iets weet van de app zelf?
Vaak zijn de beheerders mensen die iets doen met firewalls of netwerken, of loadbalancers, of reverse proxies, niet perse mensen die SAP kennis hebben, of java of php of ruby enz enz. en als ze het al hebben dan vaak voor beheerstaken, niet voor applicatie taken.
Ik heb kleine SMB's gezien die 1400 apps hostten... Voor elke afdeling al snel 40 stuks, varierend van inscannen inkomende goederen tot aangifte douane... En elke afdeling werkt anders.. sommige alleen voor china, sommige alleen voor nederland, sommige alleen voor product x, sommige voor product x, y en z enz enz. dat de achterkant allemaal aan elkaar geknoopt is, soms zelf met blockchain wil niet zeggen dat de voorkant niet verschillend is...
Het hosten van een app specifiek txt bestand zoals de RFC vereist is dan overkill en levert meer werk op dan nodig. dus verplichten? kzie daar alleen mogelijkheden voor subsidiesponzen... of bepaalde security mensen die wel even laag komen overvliegen, alles onderpoepen en weer weg gaan als een 150 euro/uur dakduif...
Door Anoniem:
Waar baseer jij dat op?
Wat een onzin, alsof een textbestandje met daarin ook contactgegevens (en een encryptiesleutel) daar wat aan gaat veranderen.
Door -Peter-:
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
Peter
Door Anoniem: Dit is misschien toch wel de meest zinloze uitvinding van de laatste 20 jaar... Sinds jaar en dag hebben we contactformulieren met captcha's en voor een goede reden. Wat je hiermee gaat krijgen is dat er allemaal geautomatiseerde scans voorbij komen die bij alles wat ook maar lijkt op een kwetsbaarheid automatisch gaat mailen in de hoop een bug bounty oid op te strijken.
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
Peter
Waar baseer jij dat op?
Wat een onzin, alsof een textbestandje met daarin ook contactgegevens (en een encryptiesleutel) daar wat aan gaat veranderen.
Peter heeft een heel ruime Internet en security ervaring .
En heeft , ietwat cynisch , natuurlijk helemaal gelijk dat contactformulieren en capcha's een prima manier zijn om externe melders te ontmoedigen .
Door Anoniem: Verplicht, verplicht, verplicht, verplicht. Zo kennen we de denkwijze weer. Trek die site dan maar gewoon offline, dan is het gez**k ook opgelost.
Als je nou wat wil melden, dan zou je bij een beetje redelijke organisatie iets naar info@xxx kunnen sturen en krijg je wel antwoord wie dat gaat regelen. Dat zal bij ambtenaren wat moeilijker liggen, want het staat niet op hun protocol of check lijstje. Of een dedicated email address dan wel succesvol is? Na een jaar is de informatie verouderd en verouderde informatie is doorgaans schadelijker dan geen informatie...
Als je nou wat wil melden, dan zou je bij een beetje redelijke organisatie iets naar info@xxx kunnen sturen en krijg je wel antwoord wie dat gaat regelen. Dat zal bij ambtenaren wat moeilijker liggen, want het staat niet op hun protocol of check lijstje. Of een dedicated email address dan wel succesvol is? Na een jaar is de informatie verouderd en verouderde informatie is doorgaans schadelijker dan geen informatie...
Nee niet info maar security@
Info krijgt sowieso alleen maar spam.
Door Anoniem:
Als jij 400 apps op een host draait en hiervoor 400 mapjes gaat aanmaken dan beschik je niet over de juiste kennis om 400 apps op 1 host te draaien.
Eens!Door Anoniem: Voor elke app moet je dan een /.well-known/security.txt bestand aanmaken.
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Als jij 400 apps op een host draait en hiervoor 400 mapjes gaat aanmaken dan beschik je niet over de juiste kennis om 400 apps op 1 host te draaien.
Door Anoniem: Tis niet mijn idee... het staat letterlijk in de RFC waar deze consultatie naar verwijst...
elke app moet een EIGEN map hebben... En natuurlijk kunnen de beheerders of zelfs klanten verschillend zijn, dus ja, ook de inhoud van security.txt is dan voor elke app verschillend.
voor de mensen die patronizing gebruikten, denk je echt dat als je 400 apps host dat die allemaal dezelfde beheerder hebben? laat staan een SME...
En dat die beheerder ook iets weet van de app zelf?
Vaak zijn de beheerders mensen die iets doen met firewalls of netwerken, of loadbalancers, of reverse proxies, niet perse mensen die SAP kennis hebben, of java of php of ruby enz enz. en als ze het al hebben dan vaak voor beheerstaken, niet voor applicatie taken.
Ik heb kleine SMB's gezien die 1400 apps hostten... Voor elke afdeling al snel 40 stuks, varierend van inscannen inkomende goederen tot aangifte douane... En elke afdeling werkt anders.. sommige alleen voor china, sommige alleen voor nederland, sommige alleen voor product x, sommige voor product x, y en z enz enz. dat de achterkant allemaal aan elkaar geknoopt is, soms zelf met blockchain wil niet zeggen dat de voorkant niet verschillend is...
Het hosten van een app specifiek txt bestand zoals de RFC vereist is dan overkill en levert meer werk op dan nodig. dus verplichten? kzie daar alleen mogelijkheden voor subsidiesponzen... of bepaalde security mensen die wel even laag komen overvliegen, alles onderpoepen en weer weg gaan als een 150 euro/uur dakduif...
elke app moet een EIGEN map hebben... En natuurlijk kunnen de beheerders of zelfs klanten verschillend zijn, dus ja, ook de inhoud van security.txt is dan voor elke app verschillend.
voor de mensen die patronizing gebruikten, denk je echt dat als je 400 apps host dat die allemaal dezelfde beheerder hebben? laat staan een SME...
En dat die beheerder ook iets weet van de app zelf?
Vaak zijn de beheerders mensen die iets doen met firewalls of netwerken, of loadbalancers, of reverse proxies, niet perse mensen die SAP kennis hebben, of java of php of ruby enz enz. en als ze het al hebben dan vaak voor beheerstaken, niet voor applicatie taken.
Ik heb kleine SMB's gezien die 1400 apps hostten... Voor elke afdeling al snel 40 stuks, varierend van inscannen inkomende goederen tot aangifte douane... En elke afdeling werkt anders.. sommige alleen voor china, sommige alleen voor nederland, sommige alleen voor product x, sommige voor product x, y en z enz enz. dat de achterkant allemaal aan elkaar geknoopt is, soms zelf met blockchain wil niet zeggen dat de voorkant niet verschillend is...
Het hosten van een app specifiek txt bestand zoals de RFC vereist is dan overkill en levert meer werk op dan nodig. dus verplichten? kzie daar alleen mogelijkheden voor subsidiesponzen... of bepaalde security mensen die wel even laag komen overvliegen, alles onderpoepen en weer weg gaan als een 150 euro/uur dakduif...
Blijkbaar heb jij moeite om van een hoop bomes het bos te zien.
In één alinea roep je dat verschillende apps verschillende beheerders/contactpersonen kunnen hebben .
En dan klaag je dat de RFC zegt die je - precies om die reden - dus contact informatie verschillend *kunt* maken door per map een ander bestand te gebruiken ?
Dan heb je inderdaad een consultant nodig van 250 per uur (150 voor de kennis, 100 voor het geduld om je dat uit te leggen) .
En dan zeur je ook nog dat de meeste beheerders NIET de juiste contactpersoon zijn voor security zaken - ?!
Prima - nog meer reden dat je zo'n security.txt automatisch aanmaakt en plaatst - het enige dat voor de *buitenkant* nodig is dat dat bestand er met een geschikte inhoud uitkomt bij een standaard HTTP(s) GET van een bepaalde URL. Misschien laat je de webserver centraal het zelfde bestand leveren voor al die mappen . Misschien genereer je de security.txt's offline en plaats je ze automatisch .
Als je met het handje 1400 security.txt's zou gaan zitten tikken in notepad en in mapjes plaatsen - dan ben je inderdaad niet de persoon om wat te vinden van zo'n server of van zo'n beleidskeuze.
Dat kan , op een paar manieren, automatisch.
Met al die sub-afdelinkjes die je noemt van douana e.d. denk ik niet dat die allemaal een eigen security contact hebben .
Helemaal prima - hetzelfde bestand met iets als security-alert@minfin , of whatever er is aan organisatiebrede afdeling waar zo'n melding terecht moet komen voldoet dan prima om binnen al die mappen te (laten) plaatsen.
En zijn het wel eilandjes die hun eigen security doen - ook goed, dan wordt er passende security.txt gegenereerd voor die betreffende afdeling , die uitgeserveerd wordt vanaf hun deel van de webspace.
Automatisering is er om taakjes die veel van hetzelfde zijn automatisch te doen .
13-02-2023, 19:14 door
spatieman
net zo iets als robots.txt dus waar veel zoekmachines zich de poepert mee afvegen.
Door Anoniem: Tis niet mijn idee... het staat letterlijk in de RFC waar deze consultatie naar verwijst...
elke app moet een EIGEN map hebben... En natuurlijk kunnen de beheerders of zelfs klanten verschillend zijn, dus ja, ook de inhoud van security.txt is dan voor elke app verschillend.
Het woord "app" komt in heel RFC 9116 niet voor; "/.well-known/security.txt" is een pad onder een domeinnaam of IP-adres. Dus staat er niet letterlijk wat jij ervan maakt, zodat wat jij ervan maakt wel jouw idee is.elke app moet een EIGEN map hebben... En natuurlijk kunnen de beheerders of zelfs klanten verschillend zijn, dus ja, ook de inhoud van security.txt is dan voor elke app verschillend.
Voor de duidelijkheid: wat via een domeinnaam of IP-adres beschikbaar is kan een ouderwetse statische website zijn, er kunnen via paden of querystrings meerdere applicaties onder dezelfde domeinnaam ondergebracht zijn (in de zin dat ze op de server als gescheiden applicaties worden behandeld), en dezelfde applicatie kan via meerdere domeinnamen beschikbaar zijn. Dus de term "app" dekt de lading niet. De RFC gebruikt de term "app" dan ook niet maar geeft in plaats daarvan aan wat ze wel bedoelen.
Door Anoniem: Verplicht, verplicht, verplicht, verplicht. Zo kennen we de denkwijze weer. Trek die site dan maar gewoon offline, dan is het gez**k ook opgelost.
Als je nou wat wil melden, dan zou je bij een beetje redelijke organisatie iets naar info@xxx kunnen sturen en krijg je wel antwoord wie dat gaat regelen. Dat zal bij ambtenaren wat moeilijker liggen, want het staat niet op hun protocol of check lijstje. Of een dedicated email address dan wel succesvol is? Na een jaar is de informatie verouderd en verouderde informatie is doorgaans schadelijker dan geen informatie...
Als je nou wat wil melden, dan zou je bij een beetje redelijke organisatie iets naar info@xxx kunnen sturen en krijg je wel antwoord wie dat gaat regelen. Dat zal bij ambtenaren wat moeilijker liggen, want het staat niet op hun protocol of check lijstje. Of een dedicated email address dan wel succesvol is? Na een jaar is de informatie verouderd en verouderde informatie is doorgaans schadelijker dan geen informatie...
In de meeste redelijke organisaties gaat dit niet werken, info@ is de klantenservice, die snapt er dan niets van als je met een CVD melding aan komt zetten. Security@ is al een stuk beter vaak, maar die teams zijn meestal niet per e-mail bereikbaar (want teveel spam) maar via een formulier. Dit bestandje helpt simpelweg de melder: waar staat dat formulier? (want je kunt gewoon linken naar een formulier, hoeft geen mailadres te staan).
Eigenlijk doet de overheid nu het bedrijfsleven een plezier: door het een pas-toe-of-leg-uit standaard te maken gaat het worden toegepast bij alle leveranciers van de overheid en wordt dit dus algemeen in Nederland beter. Minder kwetsbaarheden in NL = minder kans op problemen voor gebruikers.
Door Anoniem: Voor elke app moet je dan een /.well-known/security.txt bestand aanmaken.
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Natuurlijk moeten de rechten goed staan en moet je de bestanden goed onderhouden, en bij elke edit kunnen de rechten weer fout gezet worden...
Dit idee is net zo slim als de beste sloten kopen en dan een kastje aan de muur hangen met een kopie sleutel en een sticker erop 'alleen voor de brandweer indien brand te gebruiken'....
Maar het idee kwam ook van mensen die india en bangkok hun security certificaten halen. waar je voor 200 euro zo'n cert kunt kopen.
Maar voor hackers is zo'n mapje met rechten waar je bestanden kunt dumpen voor een overflow erg handig..
Dus wanneer je op een host 400 applicaties draait, moet je 400 mapjes aanmaken.
Natuurlijk moeten de rechten goed staan en moet je de bestanden goed onderhouden, en bij elke edit kunnen de rechten weer fout gezet worden...
Dit idee is net zo slim als de beste sloten kopen en dan een kastje aan de muur hangen met een kopie sleutel en een sticker erop 'alleen voor de brandweer indien brand te gebruiken'....
Maar het idee kwam ook van mensen die india en bangkok hun security certificaten halen. waar je voor 200 euro zo'n cert kunt kopen.
Maar voor hackers is zo'n mapje met rechten waar je bestanden kunt dumpen voor een overflow erg handig..
Gewoon 1 bestand op https://www.example.nl/.well-known/security.txt, dat is genoeg.
En heb je subdomeinen? Dan kun je die naar dat bestand redirecten of een eventuele leverancier zijn eigen contactgegevens laten neerzetten.
Denk je nu: pfoe, 400 subdomeinen, veel werk: dan is het goede nieuws dat na je werk je mailbox een stuk rustiger is want nu komen meldingen over die 400 subdomeinen natuurlijk op willekeurige plekken binnen (of niet, en dan heb je het morgen nog veel drukker met incidenten omdat degene die de kwetsbaarheid zag hem niet kon melden en op social media postte uit frustratie).
Door spatieman: net zo iets als robots.txt dus waar veel zoekmachines zich de poepert mee afvegen.
Totaal ander doel, enigste overeenkomst is dat het een .txt bestandje is.
Door -Peter-:
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
Peter
Door Anoniem: Dit is misschien toch wel de meest zinloze uitvinding van de laatste 20 jaar... Sinds jaar en dag hebben we contactformulieren met captcha's en voor een goede reden. Wat je hiermee gaat krijgen is dat er allemaal geautomatiseerde scans voorbij komen die bij alles wat ook maar lijkt op een kwetsbaarheid automatisch gaat mailen in de hoop een bug bounty oid op te strijken.
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
Peter
Ah docent dus. Hier een stukje praktijkervaring. Ooit bij een SOC gezeten waar aan de lopende band de onzin meldingen binnen komen? Dan krijg je allemaal mensen in de mails die kali hebben ontdekt en zonder enige controle de metasplot scans opsturen in de hoop een bug bounty te ontvangen. Zonder de drempel iets hoger te leggen kun je daar een dagtaak van maken. Dus misschien toch die catchy opening eens heroverwegen.
Door Anoniem:
Ah docent dus. Hier een stukje praktijkervaring. Ooit bij een SOC gezeten waar aan de lopende band de onzin meldingen binnen komen?
Door -Peter-:
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
Peter
Door Anoniem: Dit is misschien toch wel de meest zinloze uitvinding van de laatste 20 jaar... Sinds jaar en dag hebben we contactformulieren met captcha's en voor een goede reden. Wat je hiermee gaat krijgen is dat er allemaal geautomatiseerde scans voorbij komen die bij alles wat ook maar lijkt op een kwetsbaarheid automatisch gaat mailen in de hoop een bug bounty oid op te strijken.
Bij iedere security cursus geef ik aan dat, als je geen meldingen wilt ontvangen, je het beste kunt werken met contactformulieren. Als je het nog moeilijker wilt maken, neem dan captchas op.
Peter
Ah docent dus. Hier een stukje praktijkervaring. Ooit bij een SOC gezeten waar aan de lopende band de onzin meldingen binnen komen?
Als je wat voorstelt in de praktijk kun je aardig raden welke Peter dit is , en dat z'n ervaring wat verder gaat dan een eerstelijns SOC beheerder.
Ook mensen met heel veel ervaring geven wel eens cursussen . Het wil niet zeggen dat dat altijd hun hoofdtaak is, of dat ze alleen maar theoretische lesboeren zijn.
Reageren
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.
