Verplichte maatregelen en richtlijnen - 5.14.02

[RoelBrandDeurne]

Beschrijf de bug

• De term webverkeer is vaag. Beter is de term publiek toegankelijke websites uit 5.14.05.
• Schrijf de richtlijn net zoals alle andere op in stellende vorm ("er wordt"), niets als opdracht ("maak gebruik van ...").

Voorgestelde wijziging Bij publiek toegankelijke websites wordt gebruik gemaakt van ten minste publiek vertrouwde Organization Validated-certificaten, tenzij uit een risicoanalyse, aansluitvoorwaarden of wetgeving blijkt dat een hogere eis nodig is of met een lagere eis kan worden volstaan.

Impact van de wijziging Verduidelijking.

Aanvullende informatie NVT

[PSSkyu]

Ik zou deze nog verder willen aanscherpen.

Voorgestelde wijziging Bij publiek toegankelijke websites wordt gebruik gemaakt van ten minste publiek vertrouwde Organization Validated-certificaten.

Impact van de wijziging

1. Je blijft als BIO puur bij een eigen eis die je stelt en beschrijft niet heel de wereld aan opties.
2. Het statement; tenzij uit een risicoanalyse, blijkt dat een hogere eis nodig is of met een lagere eis kan worden volstaan. erg gek is. Als de BIO het minimum is kan je in essentie niet lager vereisen. Natuurlijk wel hoger maar dat hoeft niet echt meer benoemd te worden omdat risicomanagement BIO/NIS breed afgedwongen wordt.
3. Het statement; aansluitvoorwaarden of wetgeving verwijst naar wettelijke kaders en contractuele verplichtingen die vertaalt moeten worden naar het ISMS. Maar geen onderdeel zijn van de BIO zelf.

Aanvullende informatie NVT

[JdeBest-s-Hertogenbosch]

Ik zou de wijziging van Roel opnemen, zodat duidelijk is dat je aan de hand van risico's nog vrijheid hebt om een bijpassend certificaat te kiezen wat bij het niveau past. Anders heb je alleen de keuze OV of hoger en niks lagers terwijl dat in bepaalde gevallen mogelijk ook kan voorkomen.

Een voorbeeld: je hebt een arsenaal van domeinnamen waar je niets mee doet maar je toch niet weg wil doen om een of ander reden. Deze wil je laten doorverwijzen naar je hoofdwebsite. Dan zou dat betekenen dat je overal een OV-certificaat dient te hebben terwijl dit naar mijn inziens ook met een DV-certificaat zou kunnen afhankelijk van domein en risico. Wel dien je ervoor te zorgen dat alleen de betreffende organisatie of het domein dat betreffende certificaat mag aanvragen en niemand anders. Zodat je als organisatie zelf de controle blijft houden.

Nu ga ik misschien vloeken maar Let's Encrypt heeft zo'n mogelijkheid om in het CAA record (DNS) een ID op te nemen welke ervoor zorgt dat alleen het specifieke domein het certificaat kan aanvragen en niemand anders. Waardoor je toch de waarborging hebt dat niemand anders het betreffende certificaat mag aanvragen waardoor je minder risico loopt.

In het andere geval heb je alleen OV-certificaten of hoger terwijl er mogelijk ook websites/domeinen zijn welke een laag risico hebben en waar je dan toch verplicht een OV-certificaat dient te plaatsen als je het aanscherpt. Ik zou de risico beoordeling bij de organisatie laten waarbij je wel gaat voor standaard OV-certificaat maar dat je daar in bepaalde gevallen van kan afwijken afhankelijk van het risico.

[bwbroersma]

Waar komt het OV-niveau eigenlijk vandaan, vertaling van PKI-overheid, of is er een directe NIS2 vertaling? Het lijkt me zeer onwenselijk om het zo op te nemen, let ook wel dat dit een dode letter gaat zijn, 95+% gaat afwijken. Voorstel is OV naar DV wijzigen.

Voor gebruikers is de OV-info in browsers nauwelijks meer te bereiken, voordelen zijn er m.i. dan ook niet meer. Voor API endpoints wordt DANE geadviseerd om certificate pinning te bewerkstelligen (zie TLS richtlijnen "Certificate pinning en DANE").

[JdeBest-s-Hertogenbosch]

OV is niet alleen met betrekking vanuit browser kant, maar ook de uitgifte kant. (betrouwbare overheid). DV kun je ook maatregelen voornemen zoals eerder zei, maar je zou dat moeten afwegen wat je gebruikt m.b.t. het risico OV standaard en indien DV kan op basis van je risico doe je dat.

[bwbroersma]

Nogmaals, het lijkt mij zeer onverstandig een maatregel op te nemen die:

1. geen wezenlijk bewezen veiligheid geeft;
2. hoger risico op verstoringen in beschikbaarheid geeft (zie hieronder);
3. in zeer grote aantallen niet aan gaat worden voldaan.

OV certificaten hebben het risico meer 'handmatig' aangevraagd te worden, met alle risico's van dien m.b.t. totale onbeschikbaarheid (door HSTS kan je een expired certificaat niet meer 'bypassen', zie bijv: ), daarbij zeker gelet op:

• mogelijk verkorten van maximale periode van 398 dagen naar 90 dagen, zie Chrome Root Program - Moving Forward, Together.
• distrust van partij (zoals Entrust, Chrome Root Program - Entrust Certificate Distrust), of fouten in uitgifte (zoals DigiCert, zie BugZilla #1910322), in geval van het laatste moet een certificaat binnen 24 uur worden ingetrokken.

DV met ACME verdient m.i. de voorkeur (in een dual RSA/EC certificate setup van 2 verschillende root CA's en versprongen in expire).

Het is wél belangrijker dat:

• [in geval van Rijksoverheid] de domeinnaam is geregistreerd via DPC / Rijksoverheid registrar;
• de domeinnaam is in ieder geval opgenomen in het Register Internetdomeinen Overheid.

Dit laatste zou wel ergens in de BIO kunnen landen.