'Nederlandse overheid voldoet pas in 2030 aan verplichte websecuritystandaarden'

Nederlandse overheidswebsites voldoen mogelijk pas in 2030 aan de securitystandaarden van het Forum Standaardisatie. Dat inventariseerde overheidsdomeinen en zegt dat die in een te traag tempo van de juiste beveiliging worden voorzien.

Het Forum Standaardisatie schrijft in een rapport dat de Nederlandse overheid nog lang niet voldoet aan de beveiligingsstandaarden voor haar websites. Het gaat om websites van zowel de Rijksoverheid als die van gemeenten, waterschappen, provincies en verwante instellingen. Volgens het Forum voldoen momenteel slechts vier op de tien domeinen aan alle veiligheidseisen. "Zonder aanvullende actie voldoen alle overheidswebsites in het huidige groeitempo pas in 2030 aan de afspraken", waarschuwt het Forum.

Het Forum kijkt naar de eisen die worden gesteld onder de Wet Digitale Overheid, die sinds begin deze maand van kracht is. Die wet schrijft voor welke minimale beveiligingseisen er kunnen worden opgelegd aan websites- en e-maildomeinen van de overheid. Het gaat dan onder andere om de toepassing van Https en Dnssec voor websites en Dkim of Dmarc voor e-mail om spoofing tegen te gaan. Het Forum kijkt naar de toepassing daarvan op domeinen die zijn opgenomen in het websiteregister van de Rijksoverheid en het Register van Overheidsorganisaties. Ook de adoptie van IPv6 bij overheidsdomeinen staat in de wet beschreven, maar die wordt in de rapportage van het Forum Standaardisatie niet meegenomen. Sommige maatregelen uit de wet worden verplicht, andere worden aanbevolen. Bij een handvol gemeenten in Nederland zijn ook de niet-verplichte standaarden toegepast.

Bij 56 procent van de onderzochte overheidswebsites worden alle standaarden succesvol toegepast, zegt het Forum. De hoogste adoptiegraad ligt bij de waterschappen en bij gemeenten, waar 90 en 86 procent van de domeinen volledig voldoen aan de standaarden. Bij de centrale overheid en provincies schommelt dat percentage op iets meer dan de helft. Het grootste gat ligt bij 'gemeenschappelijke regelingen', ofwel samenwerkingsverbanden en uitvoeringsorganisaties van gemeenten. Daar voldoet slechts 26 procent aan alle maatregelen.

Het Forum ziet vooral bij sommige ministeries een grote verbeterslag. Onder andere het ministerie van Binnenlandse Zaken en dat van Economische Zaken hebben het afgelopen jaar een 'gerichte aanpak' opgezet waardoor zij in toenemende mate aan de eisen voldoen.

Het Forum Standaardisatie denkt dat de toepassing van standaarden sneller achterblijft omdat overheden gebruikmaken van externe leveranciers. Het Forum waarschuwt dan ook voor die afhankelijkheid, bijvoorbeeld omdat overheden Microsoft 365 gebruiken waarbij Dnssec niet standaard geconfigureerd zijn. "De beweging naar cloudoplossingen van deze leveranciers kan daarom leiden tot een afname in adoptiegraad, aangezien deze cloudoplossingen de verplichte standaarden niet volledig ondersteunen", schrijft het forum. Daarom zou er bij de aanbesteding van zulke diensten moeten worden opgenomen dat bepaalde standaarden ondersteund moeten worden, adviseert het Forum. "Gebruik daarnaast de collectieve slagkracht van de overheid om grotere leveranciers en techgiganten te bewegen naar adoptie van alle verplichte standaarden", raadt het Forum aan.

Reacties (89)

[djiwie]

Echt storend dat Microsoft en Google zo traag en laks zijn met adoptie van een (inmiddels vrij elementaire) standaard als DNSSEC voor de mail. Los van de overheid zou ook in de private sector de veiligheid een stuk beter worden wanneer MS en Google DNSSEC en IPv6 standaard zouden ondersteunen.

(Voor IPv6 kun je trouwens contact opnemen met de support van Office 365 en het aan laten zetten, maar persoonlijke ervaring was dat niet iedere supportmedewerker begrijpt wat je wilt...)

[Kees]

DNSSEC is voor dns, voor mail heb je DKIM/DMARC. En dnssec is niet triviaal als je bijvoorbeeld split-dns hebt, wat (wellicht uit legacy) veel bedrijven hebben.

DKIM en DMARC zijn ook niet perse triviaal, zo ben ik met dkim al tegen google aangelopen die wat bugs in hun systemen hebben waardoor mail niet gesigned word.

IPv6 is ook niet triviaal als je veel legacy systemen hebt, er hoeft maar 1 systeem tussen te zitten die IP adressen perse nodig heeft en ze als varchar(15) opslaat om ervoor te zorgen dat je voor dat systeem geen ipv6 kan aanzetten en dat eerst moet aanpassen of er omheen werken.

[CAPSLOCK2000]

DNSSEC is voor dns, voor mail heb je DKIM/DMARC. En dnssec is niet triviaal als je bijvoorbeeld split-dns hebt, wat (wellicht uit legacy) veel bedrijven hebben.

Gelukkig zijn er de laatste jaren flinke stappen gemaakt. Waar we in het verleden alle data vooraf genereerde is het tegenwoordig steeds populairder om DNSSEC on-the-fly te doen. Daarmee zijn de meeste problemen met split-dns verdwenen.

IPv6 is ook niet triviaal als je veel legacy systemen hebt, er hoeft maar 1 systeem tussen te zitten die IP adressen perse nodig heeft en ze als varchar(15) opslaat om ervoor te zorgen dat je voor dat systeem geen ipv6 kan aanzetten en dat eerst moet aanpassen of er omheen werken.

Het hebben van veel legacy systemen is natuurlijk ook niet bevorderlijk voor de veiligheid. Ik weet dat je het in praktijk niet altijd vrij kan kiezen maar eigenlijk is het idioot dat er na 25 jaar nog steeds software op de markt is die geen IPv6 ondersteunt.

[Kees]

Laatst nog een nieuw kubernetes cluster opgezet, als je de default installatie volgt krijg je geen ipv6 in je containers....

[Verwijderd]

Wat echt idioot is dat veel (zo niet de meeste) ambtenaren niet weten dat ze aan deze standaarden moeten voldoen. En zo wordt er weer apparatuur aangekocht die niet voldoet aan IPv6....

[Ozzy]

Het overgrote deel van ambtenaren zijn gewoon werknemers, waarbij de werkgever toevallig de overheid is. Het is aan IT-ers of "experts in Beveiliging en antivirus" om ze daarbij te helpen, het uit te leggen en het simpel te maken.

De meeste mensen weten ook niet hoe een verbrandingsmotor precies werkt, toch kunnen de meesten er redelijk veilig met aan auto overweg. Dat komt omdat er regels zijn: je moet een rijbewijs hebben, tanken is een standaard, vangrails, verkeerslichten, strepen, borden en talloze hulpjes in auto's zorgen er voor dat normale mensen met zo'n complex apparaat in een complex systeem om kunnen gaan.

Dus nee, het is niet idioot dat ambtenaren (of welke werknemer dan ook) dat niet weten.

[Verwijderd]

De meeste mensen weten ook niet hoe een verbrandingsmotor precies werkt,
Dit argument wordt heel vaak opgehaald. Een manager hoeft ook geen verstand van IT te hebben, die moet managen en hoeft niet aan de knoppen te zitten.
Maar het is een foute aanname. Iemand met een rijbewijs zal niet de kennis hebben om het meest geschikte voertuig te kiezen (we zien daar dagelijks voorbeelden van op de weg). Daarnaast kijgen ambtenaren allemaal een computer cursus (digitaal rijbewijs) maar dat wil niet zeggen dat daarmee de kennis hebben om beslissingen te nemen. Om het schip in de juiste richting te sturen. Er zijn gradaties van kennis en daar mist het bij de overheid aan.

De 'expert' zijn, op een uitzondering na, veelal extern en dat is vragen om de slager zijn eigen vlees te laten keuren. Ambtenaren zweren trouw aan de burger maar de externe consultant heeft die verplichtingen niet.

Dat komt omdat er regels zijn
De regels zijn er nu ook al. Daar gaat dit artikel over

Dus nee, het is niet idioot dat ambtenaren (of welke werknemer dan ook) dat niet weten.
Dus de regels zijn er en ze voldoen er niet aan. Het lukt de overheid niet om te voldoen aan de regels maar daar is niemand schuldig aan.. Klinkt als een antwoord van een ambtenaar

[djiwie]

Dat klopt, maar eigenlijk kun je DKIM en DMARC niet vertrouwen als je de DNS lookup niet kunt verifieren (waar je DNSSEC voor nodig hebt). En het klopt dat DKIM niet altijd triviaal is maar gelukkig hebben de grote cloudaanbieders dat wel opgepakt. DMARC is vooral lastig als je geen goed beeld hebt wie er allemaal mail namens jouw domein mogen versturen (zelfde met SPF overigens), waardoor je nog vaak erg relaxte policies ziet. Tegelijkertijd heeft DMARC daarom ook een reporting functie ingebouwd die erg nuttig is.

Voor mail is IPv6 overigens niet vreselijk ingewikkeld IMHO. Alleen de edge hoeft met IPv6 om te kunnen gaan, wat daarna in je netwerk zit kan gewoon over IPv4. Het gekke is dus dat MS dit wel support maar niet standaard aanzet.

[segil]

Voor mail heb je DANE en daarbij wordt gebruik gemaakt van DNSSEC. Microsoft is bezig de implementatie uit te rollen.

[HKLM_]

Adding Inbound Support for DNSSEC/DANE for SMTP to Exchange Online Staat op de roadmap als preview December 2023 en GA Maart 2024.

[djiwie]

Dat is dan flink naar achter verschoven. Als ik me niet vergis was de deadline in eerste instantie 2022 (of misschien zelfs al '21).

[HKLM_]

Ja klopt, (ik wacht er zelf ook op) de planning was volgens mij midden 2022.

Deze huidige planning schuift ook nog op verwacht ik.

[CAPSLOCK2000]

Adding Inbound Support for DNSSEC/DANE for SMTP to Exchange Online Staat op de roadmap als preview December 2023 en GA Maart 2024.

Dat staat er al jaren op en wordt steeds weer vooruit geschoven. Ik zou er niet op gaan zitten wachten.

2020: https://www.security.nl/p...E-support+Exchange+Online
2022: https://techcommunity.mic...-with-dnssec/ba-p/3100920
2023: https://practical365.com/exchange-online-dnssec-dane/

Er is nog onderscheid tussen inbound en outbound maar beiden zijn al een paar keer aangekondigd en uitgesteld. Ik verwacht dat als puntje bij paaltje komt het ook deze keer weer geen volledige ondersteuning gaat zijn.

[baknu]

Ter info: Microsoft ondersteunt sinds voorjaar 2022 op Exchange Online wel outbound DANE (validatie van certificaat-fingerprints door verzendende mailserver):
- https://learn.microsoft.c...works?view=o365-worldwide
- https://www.sidn.nl/nieuw...-uitgaande-dane-validatie

In de recente brief van de NL overheid aan Microsoft staat dat ondersteuning van inbound DANE (publicatie van certificaat-fingerprint van ontvangende mailserver) inderdaad meermaals door Microsoft is uitgesteld van oorspronkelijk eind 2021 naar nu maart 2024. Zie: https://www.forumstandaar...ter-to-Microsoft-DANE.pdf

[Reactie gewijzigd door baknu op 22 juli 2024 13:53]

[mocem]

Een Nederlandse overheid zou geen DNS moeten afnemen bij een Amerikaanse partij. Lekker zelf doen.

[Yodocus]

Het probleem dat @djiwie noemt is vooral dat de overheid diensten van Amerikaanse aanbieders afneemt die standaard geen DNSSEC of IPv6 ondersteunen. Dat staat los van je eigen domeinen of websites.

[CAPSLOCK2000]

Echt storend dat Microsoft en Google zo traag en laks zijn met adoptie van een (inmiddels vrij elementaire) standaard als DNSSEC voor de mail. Los van de overheid zou ook in de private sector de veiligheid een stuk beter worden wanneer MS en Google DNSSEC en IPv6 standaard zouden ondersteunen.

Het zegt veel over de verhoudingen op de markt dat we steeds weer kiezen voor partijen die niet voldoen. Het is geen vrije markt en zelfs de overheid kan haast niet om de IT-molochen heen.
Overigens zie ik dat wel als keuze, er zijn weinig technische redenen om niet te voldoen, zo ingewikkeld zijn de meeste van die standaarden niet.

[bzzzt]

[...]
zo ingewikkeld zijn de meeste van die standaarden niet.

Lees je eens in in de hierboven genoemde DNSSEC/DANE standaard. Als zelfs de mensen van Microsoft Azure er jaren langer dan gepland over doen zie ik het donker in voor de meeste beheerders van lokale mailservers. (en dat gaat de marktwerking ook flink verstoren - zelf je mail hosten is vrijwel niet meer te doen als je compliant wil zijn).

[CAPSLOCK2000]

Lees je eens in in de hierboven genoemde DNSSEC/DANE standaard. Als zelfs de mensen van Microsoft Azure er jaren langer dan gepland over doen zie ik het donker in voor de meeste beheerders van lokale mailservers. (en dat gaat de marktwerking ook flink verstoren - zelf je mail hosten is vrijwel niet meer te doen als je compliant wil zijn).

Je hebt misschien gelijk maar je zegt het tegen de verkeerde Ik ben goed op de hoogte van die standaarden en werk er al mee sinds voor het officiele standaarden waren.
DNSSEC lijkt veel lastiger dan het is. Helaas volgen veel mensen nog best-practices van 15 jaar geleden die het allemaal veel complexer maken dan nodig (alles rond KSKs, ZSKs en sleutelrotatie is bv enorm archaisch en eigenlijk niet nodig).

DANE is eigenlijk een heel eenvoudige standaard. Wat DANE lastig maakt is dat je je SSL-certifcaten en DNS synchroon moet houden en je nieuwe SSL-certs eerst in DNS moet publiceren als de private key veranderd. Nu zou het veranderen van de private key zeldzaam moeten zijn (net als het roteren van een DNSSEC-sleutel of het veranderen van je SSH-key) maar in praktijk is het dat niet. Velen hebben de gewoonte om bij ieder nieuw certificaat ook de private key te vervangen. In de meeste gevallen is dat een slechte gewoonte waarbij je onnodige risico's neemt.
Zelfs als je een nieuwe key nodig hebt zou dat geen probleem moeten zijn als je de uitrol netjes automatiseert in je management systeem. Maar ja, veel kleine organisatie werken wel met computers maar doen niet aan automatisering en klikken alles met de hand bij elkaar. Dan gaat het snel fout.

In praktijk klopt het dus dat DANE en DNSSEC lastig zijn maar eigenlijk is dat vooral een gevolg van slecht beheer en gebrek aan kennis. Daardoor lijken deze standaarden veel lastiger dan ze echt zijn.

Dat Microsoft er lang over doet zegt meer of dat bedrijf dan over de standaarden.

[bzzzt]

In praktijk klopt het dus dat DANE en DNSSEC lastig zijn maar eigenlijk is dat vooral een gevolg van slecht beheer en gebrek aan kennis. Daardoor lijken deze standaarden veel lastiger dan ze echt zijn.

Je bedoelt slecht beheer en kennisgebrek door het missen van goede mensen waar ieder bedrijf op dit moment mee worstelt? Dat is gewoon de realiteit. Je kan wel standaard op standaard afstempelen en zeggen dat het moet gebeuren, maar op een bepaald moment kan het gewoon niet meer.

https://www.mattb.net.nz/...2/calling-time-on-dnssec/

[CAPSLOCK2000]

Je bedoelt slecht beheer en kennisgebrek door het missen van goede mensen waar ieder bedrijf op dit moment mee worstelt? Dat is gewoon de realiteit. Je kan wel standaard op standaard afstempelen en zeggen dat het moet gebeuren, maar op een bepaald moment kan het gewoon niet meer.

Als je stopt met eisen stellen weet je zeker dat het niet beter wordt. Natuurlijk is niet voor iedereen DNSSEC de grootste prioriteit en is er nog een hoop laaghangend fruit waar ook iets mee moet gebeuren.
Gebrek aan kennis en slecht beheer los je niet op door niks te doen maar door eisen te stellen. Hoe dwingender de eisen hoe meer geld bedrijven bereid zijn om te investeren in goed personeel en hoe meer mensen het dus interessant vinden om een bepaalde studie te gaan doen. Precies wat de overheid doet.

Dat gaat de situatie niet morgen veranderen en is vooral iets voor de lange termijn maar je moet ergens beginnen.

[bzzzt]

Je kan een miljoen per jaar bieden, maar als de mensen die je nodig hebt er op dit moment gewoon niet zijn (en/of beter betaald worden) ga je gewoon niemand krijgen.
Het gaat hier dan ook nog eens over de overheid waar lonen e.d. behoorlijk star geregeld zijn.
Leuk dat mensen iets willen gaan studeren, maar tegen de tijd dat ze klaar zijn en wat echte werkervaring hebben ben je 10 jaar verder.
Het probleem met onwerkbare standaarden opleggen in plaats van naar de werkelijkheid te kijken is dat getouwtrek over de haalbaarheid het uitvoeren van haalbare zaken in de weg kan zitten.

[CAPSLOCK2000]

Zo werkt de overheid. Als je volgend jaar resultaat wil moet je elders zijn. Als je wil dat het land over 10 jaar anders is dan komt de overheid om de hoek die moeilijke eisen stelt.

Dat de overheid (te) weinig betaalt hoort er ook bij maar het probleem is groter. Ook het Nederlandse bedrijfsleven betaalt relatief weinig voor IT'ers. Ik ken er verschillende die in Duitsland zijn gaan werken omdat ze daar veel meer krijgen voor hetzelfde werk. Zo houden wij nog minder goede IT'ers over.
Het lijdt er vanzelf toe dat wij onze IT'ers van nog verder moeten halen en dat heeft weer zo z'n eigen nadelen.

[moredruid]

Nou loop ik al een tijdje mee in de IT maar ik kan mezelf echt geen DNS/mail specialist noemen. Nochtans is het mij gelukt om DNSSEC,DMARC/DKIM en SPF op te zetten voor 2 van m'n (voormalige) domeintjes. Ik heb wel wat dingen moeten opzoeken/onderzoeken en het ging met vallen en opstaan maar dat hoort erbij.

Dat een partij als Microsoft (waar zo'n beetje de hele wereld klant van is op de ene of andere manier) het niet voor elkaar heeft vind ik diep triest. Er werken genoeg slimme mensen (die zelfs mee schrijven aan deze standaarden!) maar kennelijk ontbreekt de wil/gevoel van noodzaak en urgentie om dit in de praktijk toe te passen.

[bzzzt]

En wat gebeurt er als een sleutel van een van die domeintjes vervangen moet worden? En als jij er niet meer werkt? En alle corner cases waarbij een sleutel of z'n revocation status niet gevalideerd kan worden? Is er nagedacht of het belangrijker is bereikbaar te zijn dan 100% 'veilig'? Hoe is je organisatie ingericht op vertrekkende mensen? Zijn al je vertrouwelijke sleutels voldoende beschermd?

Ik kan in mijn eentje met een paar openssl scriptjes ook een CA opzetten. In de basis is dat ook gewoon een certificaat ondertekenen. Dat het organisatorisch lastig is dat op een nette manier te doen bewees bijvoorbeeld Diginotar in het verleden.

Daarnaast is het nog het levensgrote probleem dat het zwaar beveiligen van dingen het risico op mindere beschikbaarheid veel groter wordt (zie het down gaan van het hele Nieuw-Zeeland top-level domein vorige week). Je kan een algoritme niet vragen een uitzondering te maken vanwege een noodgeval...

[moredruid]

Bij mij gebeurt er dan niet veel (ik was de SPOF voor die domeinen), maar ik mag hopen dat Microsoft (en andere grote partijen) dit beter hebben geregeld. Daar worden ze wel voor betaald. Voor kleine organisaties is dit inderdaad moeilijk; zij of hun IT-partner moeten er überhaupt al weet van hebben en het dan ook nog goed regelen (hoewel chatGPT volgens mij zo de commando's/menukliks kan genereren). Voor bedrijven met een eigen security afdeling vind ik dat er in ieder geval over nagedacht moet zijn (risicoanalyse en afweging van kosten/baten).

Uitzonderingen zullen er altijd zijn, en ik vermoed dat ze in NZ wel een RCA/risk analyse gaan doen naar aanleiding van dat incident.

[bzzzt]

(hoewel chatGPT volgens mij zo de commando's/menukliks kan genereren).

Dat is hoe je downtime krijgt

Voor bedrijven met een eigen security afdeling vind ik dat er in ieder geval over nagedacht moet zijn (risicoanalyse en afweging van kosten/baten).

Zeker als je een serieus proces in moet richten zijn de kosten hoog en de baten? DNSSEC voorkomt dat er aan de DNS records wordt gerommeld, maar met TLS heb je ook al vastgesteld dat een server de juiste is...

[BvdW1978]

Zelf mail hosten is prima te doen. Je moet het alleen willen doen, en dat draagvlak is zo langamerhand wel weg. Ik kom het nog steeds tegen in referentie-architecturen: Microsoft tenzij! De vendor-lockin verheven tot beleid.. bezopen als je het mij vraagt.

Het probleem voor partijen als MS is dan weer dat ze het meteen op megaschaal voor miljoenen klanten tegelijk in alle denkbare TLD's moeten kunnen inclusief alle denkbare migratiescenario's en tussenvormen. Als je het over een handjevol domeinen hebt in een enkele organisatie, is het allemaal niet zo vreselijk ingewikkeld. Je doet het inderdaad niet even op een vrijdagmiddag tussen het bier en de nootjes door, maar het is ook echt weer geen hogere raketchirurgie. Die mythe mag ook wel eens verdwijnen.

[CAPSLOCK2000]

Het probleem voor partijen als MS is dan weer dat ze het meteen op megaschaal voor miljoenen klanten tegelijk in alle denkbare TLD's moeten kunnen inclusief alle denkbare migratiescenario's en tussenvormen. Als je het over een handjevol domeinen hebt in een enkele organisatie, is het allemaal niet zo vreselijk ingewikkeld. Je doet het inderdaad niet even op een vrijdagmiddag tussen het bier en de nootjes door, maar het is ook echt weer geen hogere raketchirurgie. Die mythe mag ook wel eens verdwijnen.

Ik denk ook dat als MS (of vergelijkbare partij) 10 jaar geleden was begonnen om actief DNSSEC te stimuleren dat alle belangrijke TLDs dan nu wel zouden meewerken. Er zijn ook verschillende standaarden in de omloop om het hele proces verder te automatiseren. Dat hadden we wellicht eerder moeten doen maar het is een beetje een kip-ei verhaal. Als DNSSEC nauwelijks gebruikt wordt is het moeilijk om te vragen om nog een extra DNSSEC-gerelateerde standaard toe te voegen.
Technisch gezien is het voor de TLD's niks bijzonders, niet veel meer dan een extra regeltje in de database die ze toch al hebben. De uitdaging zit in het toegang geven aan de juiste partijen zodat dit ene regeltje kan worden toegevoegd. Het is eigenlijk niet anders dan je naam of je creditcard nummer doorgeven. De moelijkheid zit in het aanpassen van de processen, niet de processen zelf.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 13:53]

[GertMenkel]

Technisch gezien is het voor de TLD's niks bijzonders, niet veel meer dan een extra regeltje in de database die ze toch al hebben.

De software is er wellicht al jaren klaar voor, maar je moet ook de kennis hebben om met dingen als key rollovers om te gaan.

Hier kun je zien hoeveel TLD's er wel niet storingen hebben door fouten met DNSSEC. De site is weliswaar opgezet door iemand die duidelijk een hekel heeft aan DNSSEC als een protocol, maar zonder het zoutige commentaar liegt de lijst met storingen er ook niet om. Hele TLD's gaan voor uren tot dagen offline, of nog veel langer in extreme gevallen (.мон is een jaar lang niet bereikbaar geweest).

[CAPSLOCK2000]

Hier kun je zien hoeveel TLD's er wel niet storingen hebben door fouten met DNSSEC. De site is weliswaar opgezet door iemand die duidelijk een hekel heeft aan DNSSEC als een protocol, maar zonder het zoutige commentaar liegt de lijst met storingen er ook niet om. Hele TLD's gaan voor uren tot dagen offline, of nog veel langer in extreme gevallen (.мон is een jaar lang niet bereikbaar geweest).

Ik ken de lijst maar trek andere conclusies. Er zijn 3 incidenten geregistreerd voor heel 2023, dat vind ik niet veel. De meeste van die storingen zijn vrij kort (minuten tot uren). Tien jaar geleden lag het anders, toen waren er veel meer storingen en duurde het langer om ze op te lossen, maar toen werd het ook alleen gebruikt door nerds en techneuten. Ik zeg wel eens dat je maar beter early adopter kan zijn zodat je fouten kan maken op een moment dat er nog (bijna) niemand last van heeft. Fouten maken doe je toch dus leer je lessen als dat nog pijnloos kan.

Af en toe een storing is onvermijdelijk, overal gaat wel eens iets mis. Iedere vorm van (goede) beveiliging zal problemen versterken doordat de beveiliging alarm slaat terwijl het probleem eigenlijk elders zit. Dat gaat niet anders, in geval van twijfel moet beveiliging alarm slaan.

In praktijk zie ik veel meer websites met verlopen/ongeldige SSL-certificaten dan DNSSEC-fouten.

[GertMenkel]

Heel .nz een dag of langer down vind ik geen kleine storing, al is het maar voor een dag. Gelukkig voor de Nieuw-Zeelanders doen de meeste ISP-DNS-servers nog niet zoveel met DNSSEC en clients al helemaal niet.

Iemand die een keer zijn Let's Encrypt verpest, dat is één ding. Een TLD-beheerder die zijn hele TLD per ongeluk offline gooit, dat zou gewoon niet moeten gebeuren. Juist vanwege die enorme impact is het belangrijk om dit goed te krijgen. Vergelijk het met een CA als Let's Encrypt die in één keer al hun certificaten offline gooit (corrupte ).

Tot er een jaar lang geen TLD-brede DNSSEC-storingen zijn, ga ik op mijn servers in elk geval DNSSEC-validatie nog even uit laten staan. Ik heb geen zin om mail te missen vanwege zoiets, helemaal als je er als domein niks aan kan doen als je TLD hun zaken niet op orde heeft (ja, SMTP zou moeten retryen na een tijd, maar alleen competente mailservers doen dat en TLS 1.1 uit hebben staan doet je ook al mail missen dus competentie en mailservers is lastig te verwachten).

Op mijn Pi-hole staat het ook uit sinds ik ontdekte dat het de reden is dat ik de websites van europa.eu niet kan benaderen als die verifieert. De technische dienst van de EU geeft aan dat het niet aan hun kant ligt (volgens mij snappen ze het zelf ook niet helemaal) en ik weet niet of het een bug in de resolver of aan hun kant is. Ik weet het niet zeker en wil wel graag wetgeving en dergelijke kunnen opzoeken dus dat blijft nog even uit.

Ik vind het erg jammer, maar zoals het er nu voor staat is er nog aardig wat werk aan de winkel eer het wijdverspreid aan kan worden gezet. Wat er in mijn ogen vooral mis gaat is dat weinig websites het aanzetten; zolang DNSSEC niet de norm is, is de "oplossing" van veel beheerders die hun zaken niet op orde hebben "zet DNSSEC uit op de client, hier doet hij het wel". Al mijn websites hebben het in elk geval!

Als mainstream maken een keer lukt, kunnen ideeën als DANE eindelijk worden geprobeerd, dat zou helemaal perfect zijn.

[Verwijderd]

Vergeet ook niet het gebrek aan wil... Als iemand niets anders dan Microsoft wil, dan is het de overheid wel.
Het zit er een beetje ingebakken, die jarenlange vendor-lockin laat tot de dag van vandaag nog sporen na. En gezien heel veel uitbesteed wordt, zullen die Microsoft 'partners' echt niet van koers veranderen. Die willen hun kickback.

[Frame164]

Je kan er prima omheen maar dan moeten we niet gaan klagen dat het allemaal duurder wordt

[GertMenkel]

Helaas is DNSSEC buiten Nederland en een paar andere kleinere landen niet echt populair. Na .com is .nl wereldleider in domeinen met DNSSEC, met veel meer dan de helft van de domeinen ondertekent tegenover rond een vijfde van de .com-domeinen. Dat komt mede doordat Amazon het lange tijd niet eens aanbood en slechtbeheerde TLD's regelmatig volledig offline gaan zoals .nz recentelijk.

Als domeinbeheerder is het niet zo'n probleem om aan te zetten in de meeste software (magisch gegenereerde domeinen van een in-house DNS cluster daargelaten) maar onder water is het een draak van een protocol. Het is gemaakt in de tijd dat van eindapparaten niet kon worden verwacht dat ze hamdtekenimgen konden verifiëren, dus de server (of een tussenserver zoals je router/modemcombo) doet de verificatie en zet naar clients een vlaggetje aan dat zegt "is veilig".

Ik ben groot voorstander van het idee achter DNSSEC, maar wil het ooit een succes worden dan zal er eerst een versimpelde versie van het protocol moeten komen. Wat betere documentatie zou ook helpen trouwens, maar die ontbreekt vooral omdat er zo weinig domeinen zijn die het aan hebben staan.

[2020Media]

"Het Forum kijkt naar de eisen die worden gesteld onder de Wet Digitale Overheid".
Is er ergens een lijst beschikbaar met alle eisen die worden gesteld onder de Wet Digitale Overheid?

[Martinspire]

En de lijst van sites die wel en die niet voldoen?

[JaDatIsPeter]

https://basisbeveiliging.nl/ voor overheidssites. Niet-overheden gebruiken https://internet.nl

[ocn]

https://www.forumstandaar...veiligheidstandaarden.pdf

[XelaRetak]

Zeker. Je moet er maar zin in hebben om daar doorheen te lezen

https://zoek.officielebekendmakingen.nl/kst-34972-A.html

Hoofdstuk 1 tm 5 zijn de eisen, daarna is het meer over de naleving e.d.

[Reactie gewijzigd door XelaRetak op 22 juli 2024 13:53]

[Verwijderd]

Pfff, zelf een AI Chatbot loopt vast op die invoer... Echt, ik heb het geprobeerd....

[elmuerte]

Dat is slechts de wet. Niet de concrete eisen. Neem bijvoorbeeld Hoofdstuk 3, artikel 4, lid 1

Bestuursorganen en aangewezen organisaties voldoen aan bij of krachtens algemene maatregel van bestuur te stellen regels met betrekking tot de werking, betrouwbaarheid en beveiliging van de toegang tot elektronische diensten op verschillende betrouwbaarheidsniveaus.

[Frame164]

Mwah, de RFC's waar het uiteindelijk om gaat zijn nog veel uitgebreider.

[JaDatIsPeter]

https://www.forumstandaardisatie.nl/open-standaarden/verplicht
Werkt makkelijker, en checkt https://internet.nl (deels) op.

[Reactie gewijzigd door JaDatIsPeter op 22 juli 2024 13:53]

[Newbey]

Wat let je om even op het internet te kijken?

[krflyer]

Ik vind dit een zeer hoog persbericht gehalte hebben met bierviltje berekeningen. Totaal aantal sites, percentage dat nu voldoet, dus dan duurt het nog zo lang. Wat een flauwe kul.

[CAPSLOCK2000]

Als je een beetje tussen de regels doorleest gaat het niet om het jaar 2030. De echte boodschap is dat veel overheidssites nog steeds niet voldoen aan de basismaatregelen en dat verbetering (te) traag gaat. Ze hadden twee jaar geleden helemaal klaar moeten zijn.

Een nauwkeurige berekening is niet nodig en zou misschien zelfs afleiden van de echte conclusie: die schiet niet op, het moet sneller.

[ReTechNL]

Op de website https://basisbeveiliging.nl/ kan gezien worden hoever de webbeveiliging van (alle) nederlandse overheden en gemeentes zijn verdeelt over de verschillende sectoren. Daar schrik je wel van. Aan de andere kant zie je ook dat veel gemeentes echt hun best doen om alles op oorde te krijgen.

[Reactie gewijzigd door ReTechNL op 22 juli 2024 13:53]

[segil]

kijk ook eens op https://internet.nl/halloffame/. Daar zie je welke organisaties en bedrijven voldoen aan de standaarden.

[Reactie gewijzigd door segil op 22 juli 2024 13:53]

[stefanass]

Aan de andere kant zie je ook dat veel gemeentes echt hun best doen om alles op oorde te krijgen.

Gelukkig doen die wel hun best en dat is maar goed ook, want de gemeentes beheren de Basis Registratie Persoonsgegevens. Daar moet de beveiliging gewoon 100% op orde zijn. Dat dergelijke systemen dan voorrang krijgen bij het op orde brengen boven de Gemeentelijke regelingen is alleen maar goed, al moeten ze daar natuurlijk óók de boel op orde brengen.

[Frame164]

En wat zijn de cijfers van bedrijven en andere niet-overheidsorganisaties?

[The Zep Man]

Als je een beetje tussen de regels doorleest gaat het niet om het jaar 2030. De echte boodschap is dat veel overheidssites nog steeds niet voldoen aan de basismaatregelen en dat verbetering (te) traag gaat. Ze hadden twee jaar geleden helemaal klaar moeten zijn.

Als je verder tussen de regels leest, is een belangrijke boodschap dat de overheid nooit aan de 'huidige' verplichte websecuritystandaarden kan voldoen. Standaarden staan niet stil. Een overheid die (bijvoorbeeld) in 2030 voldoet aan de standaarden van 2023 loopt nog steeds achter.

[CAPSLOCK2000]

Als je verder tussen de regels leest, is een belangrijke boodschap dat de overheid nooit aan de 'huidige' verplichte websecuritystandaarden kan voldoen. Standaarden staan niet stil. Een overheid die (bijvoorbeeld) in 2030 voldoet aan de standaarden van 2023 loopt nog steeds achter.

Niet op de huidige manier. Een deel van de overheid voldoet wel degelijk aan de standaarden (en meer), het kan dus wel. Ik heb een flink aantal van die standaarden uitgerold in een middelgrote organisatie en het meeste is goed te doen. Het is wel zo'n echte 80/20 situatie waarbij de laaste 20% van het werk meer dan 80% van de moeite kost.

Het helpt enorm als je zo'n verandering kan meenemen op het moment dat je toch al aan het upgraden of migreren bent. Met wat lange termijnplanning kun je veel bereiken maar dan moet je het wel structureel aanpakken. Helaas is in veel organisaties veiligheid nog steeds iets dat ze achteraf proberen toe te voegen aan een bestaand systeem in plaats van het mee te nemen als eis bij het opzetten van een nieuw systeem.

[The Zep Man]

Een deel van de overheid voldoet wel degelijk aan de standaarden (en meer), het kan dus wel.

Dat deel is insignificant (linkje overgenomen van @ReTechNL).

Ik heb een flink aantal van die standaarden uitgerold in een middelgrote organisatie en het meeste is goed te doen. Het is wel zo'n echte 80/20 situatie waarbij de laaste 20% van het werk meer dan 80% van de moeite kost.

Dat is geen excuus voor organisaties die het beleid bepalen en die een voorbeeldfunctie hebben. Als je zelf al niet eens aan je eigen verplichtingen kan voldoen, waarom zouden anderen dan daaraan voldoen?

In de financiële wereld wordt gesproken over de toon van de top en het gedrag van de top, en dat is ook toe te passen op voorbeeldgedrag buiten de financiële wereld. Je kan slecht gedrag op lagere niveaus verwachten als de top zich niet naar de toon gedraagt. Het is niet alleen zeggen dat het juiste gedaan moet worden. Het is ook het juiste doen. Als je altijd achterloopt, dan doe je niet het juiste. De overheid zal dan diens toon moeten aanpassen, of diens gedrag.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 13:53]

[CAPSLOCK2000]

Dat is geen excuus voor organisaties die het beleid bepalen en die een voorbeeldfunctie hebben. Als je zelf al niet eens aan je eigen verplichtingen kan voldoen, waarom zouden anderen dan daaraan voldoen?

Helemaal mee eens hoor. Ik bedoel het niet als excuus maar als verwijt naar de overheid(sdelen). De overheid zou voorop moeten lopen en alle regels tot in de puntjes uitvoeren.

Dit speelt overigens niet alleen in de IT maar overal. Uiteindelijk is de overheid ook maar een organisatie waar mensen werken die dus fouten maken. Helaas is het niet voor het eerst de overheid niet aan de eigen regels voldoet, maar de overheid is ook niet één organisatie maar een hele lappendeken aan organisaties. We zien hier het interne controleproces van de overheid aan het werk.

[bzzzt]

Als je een beetje tussen de regels doorleest gaat het niet om het jaar 2030. De echte boodschap is dat veel overheidssites nog steeds niet voldoen aan de basismaatregelen en dat verbetering (te) traag gaat. Ze hadden twee jaar geleden helemaal klaar moeten zijn.

De echte boodschap kan ook zijn dat de overheid zoveel regeltjes opgelegd heeft dat er menselijkerwijs niet meer aan valt te voldoen.

[CAPSLOCK2000]

Dat zou kunnen maar is hier niet het geval. De eisen zijn echt niet heel gek of groot. Tal van partijen voldoen er aan, en meer.

[djiwie]

Waarom zou de adoptie spontaan sneller gaan vanaf nu? Ze schrijven toch dat aanvullende acties nodig zijn? Lijkt me geen gekke conclusie als bijna de helft van de sites/domeinen nu niet alle verplichte standaarden implementeert?

[Triblade_8472]

Niet. De hoop is dat iemand van de nationale kranten of televisie ermee aan de haal gaan en zij vragen gaan stellen aan politici. Zij gaan dit dan weer intern beleggen en hopelijk kan dít de boel wel versnellen.

[NoSugar]

Ik denk dat het grootste probleem is de wildgroei aan websites van onze overheid. En de overbetaalde IT-bedrijfjes die er stinkend rijk mee worden. Het ministerie heeft vast wat bevriende websitebouwers die graag een extra website maken voor een hoog bedrag op kosten van de belastingbetaler.

https://www.youtube.com/w...showmetArjenLubach%7CVPRO

[Skip Tracer]

Ik weet niet hoe dit werkt bij gemeentelijke- en provinciale overheid maar bij de rijksoverheid zijn er inkoop procedures (die ook onderhevig zijn aan audits) die voorkomen dat je zomaar bij iedereen een website kan laten bouwen.

Daarnaast is er Platform Rijksoverheid Online (https://www.platformrijksoverheidonline.nl/) waar je als organisatie binnen de rijksoverheid je website kwijt kunt en waar zaken als toegankelijkheid, web archivering etc. zijn geborgd en je als organisatie ontzorgd kan worden. De teller bij PRO staat momenteel op 314 websites staat op hun eigen website (https://www.platformrijks...-websites/websites-op-pro).

Er kunnen natuurlijk omstandigheden zijn waardoor je een website misschien beter elders kwijt kan dan bij PRO maar je moet wel stevig in je schoenen staan om dat te kunnen verantwoorden. Of moet je jezelf beter laten informeren over de mogelijkheden of het bestaan van PRO...

[ocn]

Het websiteregister van diezelfde Rijksoverheid telt meer dan 1800 websites, dus blijkbaar draait slechts een fractie op dat Platform Rijksoverheid Online. Zo stevig staan ze blijkbaar niet in hun schoenen.

[Skip Tracer]

Er zijn binnen de rijksoverheid meer goede keuzes voor nieuwe websites. Echter, Platform Rijksoverheid Online is meestal de meest voor de hand liggende keuze als alternatief voor een website door een externe websitebouwer laten bouwen omdat dat je daar ontzorgd wordt m.b.t. de onderwerpen die ik noemde.

Als je punt is dat er nog genoeg ruimte is voor verbetering binnen de (rijks)overheid: ik denk dat de cijfers uit het artikel je gelijk geven

[ocn]

Punt is vooral dat de inkoopprocedures helaas niet voorkomen dat iedereen een website kan laten bouwen. Het is niet voor niets dat de vorige staatssecretaris zelfs sprak van wildgroei: https://www.agconnect.nl/...internetdomeinen-overheid

[Skip Tracer]

Domeinen zijn niet hetzelfde als websites. Een domeinnaam is snel aangevraagd en het punt van de wildgroei is valide wat mij betreft. Het laten bouwen van een website en laten landen op een web platform is wat anders en beter gereguleerd via inkoop procedures.

[ocn]

Dat valt vies tegen, er worden veel rijkswebsites ontwikkeld door kleine bedrijfjes die gewoon via TransIP WordPress hosting inkopen. Eén van de problemen is namelijk dat vaak niet een website wordt ingekocht, maar een dienst of ondersteuning voor een breder beleidsinitiatief, en de kosten die gemaakt worden voor een website niet apart worden gespecificeerd. Misschien dat het toevallig bij jouw organisatieonderdeel goed geregeld is, maar dat is helaas de uitzondering op de regel.

[Skip Tracer]

Als er gekozen wordt voor een externe leverancier voor het bouwen en hosten van een website door een leverancier kan ik me voorstellen dat de ondersteuning een onderdeel uit maakt van de inkoop overeenkomst. De inkoop procedures voorkomen echter wel dat je boven een bepaald bedrag daar zelf de vrije keuze in hebt en het onderscheid tussen ontwikkeling en beheer wordt daar niet in gemaakt; de totale kosten (ontwikkeling + beheer) worden meegenomen. Dat geldt voor de hele rijksoverheid.

Je zegt "dat is helaas de uitzondering op de regel". Kan je aangeven hoe je tot deze conclusie komt? Mijn ervaring is anders en ik ben oprecht benieuwd of ik een verkeerd beeld hiervan heb.

edit: typo

[Reactie gewijzigd door Skip Tracer op 22 juli 2024 13:53]

[JaDatIsPeter]

Je zegt "dat is helaas de uitzondering op de regel". Kan je aangeven hoe je tot deze conclusie komt?

De Rijkssites in het item van Lubach zullen vast niet allen via PRO lopen.

Waarom heeft de overheid zoveel websites?
besteedde Arjen Lubach in de Avondshow aandacht aan de enorme hoeveelheid websites van de overheid. Samen met Tex de Wit fileerde hij het doolhof dat op deze manier wordt gecreëerd. Hoe komt dat nou? Ik denk dat er drie dingen een rol spelen: luiheid, onbekwaamheid en gebrek aan sturing.

Naast het filmpje van Lubach waarnaar ze linken ook een leuk artikel an sich.

[ocn]

Ik kom tot die conclusie na jarenlange praktijkervaring binnen het Rijk. Check voor de grap eens dit webinar: https://ibestuur.nl/artik...weilen-met-de-kraan-open/

[CAPSLOCK2000]

Ik denk dat het grootste probleem is de wildgroei aan websites van onze overheid.

Dat heeft er mee te maken maar het echte probleem zit volgens mij dieper. De meeste mensen snappen niet genoeg van IT om goede keuzes te maken. Toch bestaat het beeld dat iedereen het kan en je met een paar klikjes een nieuwe website bouwt waar je dan nooit meer naar om hoeft te kijken. Daar handelen mensen naar. Die betalen een paar honderd euro voor een website en denken dat ze klaar zijn. Het is goed bedoelt maar incompetent. (En niet alleen bij de overheid, zo gaat het bijna overal).

[Transferno]

Ik weet niet hoe het bij de overheid gaat, maar de eisen die bedrijven stelden in het verleden zijn nu niet meer voldoende. Aanvallen worden steeds slimmer, dus bestaande IT moet ook continue beter beveiligd worden.
Voor elk nieuw ontwerp zou je al nieuwe cyber-security eisen kunnen stellen. Maar het continue bijwerken van alle bestaande infra, is ook een enorme (tijd+kosten) klus.

[Frame164]

Ja, er zijn heel veel overheidswebsites. Maar de overheid doet ook heel veel. En er zit veel te veel verschil tussen de websites om het allemaal op enkele sites te gooien. Een loket voor ondernemers is iets totaal anders dan een loket om een rijbewijs aan te vragen of je belastingaangifte te doen. Dat wil je niet centraal bouwen en onderhouden.

[vanviegen]

De frontends van de voorbeelden die je noemt bestaan allemaal uit wat informatie en een door de burger in te vullen formulier. Dat zou toch centraal moeten kunnen?

[Drucchi]

Tegen die tijd zijn de eisen en voorwaarden al lang verder aangescherpt. Op deze manier zullen ze nooit voldoen aan de voorwaarden van dat moment.

[Cergorach]

3030 is een stuk later dan de genoemde 2e helft van 2026...

4. Hoe en wanneer sluiten publieke dienstverleners zich aan op het stelsel?
De Eerste Kamer heeft de Wdo op 21 maart 2023 aangenomen. De wet treedt op 1 juli 2023 gefaseerd in werking. De techniek (ICT) en de organisatie achter het stelsel Toegang zijn naar verwachting in 2024 klaar. Dat betekent dat het stelsel toegankelijk is voor dienstverleners en dat inlogmiddelen erkend kunnen worden. Alle dienstverleners sluiten zich in de komende 3 jaar aan op het stelsel. Het is de bedoeling dat alle overheidsorganisaties in de tweede helft van 2026 op het nieuwe stelsel over zijn.

Bron:
https://www.digitaleoverh...erkingtreding-van-de-wdo/

[sOid]

Het grootste probleem die ik in onze overheidsorganisatie ervaar zit bij externe leveranciers. Het gebeurt regelmatig dat bijvoorbeeld een aannemer een website de lucht in slingert als onderdeel van een groot project.

Praktisch voor de interne projectgroep want er wordt ze veel werk uit handen genomen, maar er wordt vaak totaal geen rekening gehouden met beveiligingsstandaarden of digitoegankelijkheid (WCAG).

Dit is ook van de redenen dat het een flinke uitdaging is om iets als security.txt op alle servers te implementeren.

Daarom zou er bij de aanbesteding van zulke diensten moeten worden opgenomen dat bepaalde standaarden ondersteund moeten worden, adviseert het Forum.

Helemaal mee eens. Zou gewoon onderdeel van de BIO danwel GIBIT moeten zijn. Máár het komt zo vaak voor dat leveranciers bij aanbestedingen zeggen aan iets te kunnen voldoen, maar dat in de praktijk niet zo blijkt te zijn. Zo'n leverancier wordt dan weer in gebreke gesteld omdat ze niet leveren wat ze hebben afgesproken, maar de implementatie is dan al aan de gang. Gedoe allemaal...

[Verwijderd]

Plus dat er ook nooit een eind evaluatie plaats vindt of het geleverde wel voldoet aan initieel opgestelde eisen.

[sOid]

Da's inderdaad ook problematisch. Wij hebben sinds kort een contractbeheerder in dienst genomen om dit juist wel te controleren.

[CAPSLOCK2000]

Helemaal mee eens. Zou gewoon onderdeel van de BIO danwel GIBIT moeten zijn. Máár het komt zo vaak voor dat leveranciers bij aanbestedingen zeggen aan iets te kunnen voldoen, maar dat in de praktijk niet zo blijkt te zijn. Zo'n leverancier wordt dan weer in gebreke gesteld omdat ze niet leveren wat ze hebben afgesproken, maar de implementatie is dan al aan de gang. Gedoe allemaal...

Heel herkenbaar. Vervolgens wordt er naar de IT-afdeling gekeken om een juridisch gevecht aan te gaan met een leverancier, alsof IT daar op zit te wachten.
Ik neem zelf geen genoegen met verklaringen van de leverancier want het is helemaal standaard dat ze op alles "ja" zeggen om de opdracht maar te krijgen. Ik wil bewijs zien, maar dat is vaak makkelijker gezegd dan gedaan. Zeker als een andere afdeling de rekening al heeft betaalt en we dus vast zitten aan zo'n leverancier.

[sOid]

Ja precies dat. Wij zijn, als informatiebeveiligingsteam, ook bezig om aanvullende vragen op te stellen voor er iets getekend wordt. Even heel platgeslagen: Als een leverancier zegt een ISO 27001 of ISAE 3402 type 2-certificaat te hebben, dan willen we dat ook zien.

Niet dat die certificaten per definitie iets zeggen (maar dat is weer een heel ander verhaal ), maar als ze zelfs dat al niet zonder morren kunnen overhandigen dan is het helemaal een slecht teken en voor ons aanleiding om verdere vragen te stellen.

[CAPSLOCK2000]

Het grootste gat ligt bij 'gemeentelijke regelingen', ofwel samenwerkingsverbanden en uitvoeringsorganisaties van gemeenten.
(...)
Het Forum Standaardisatie denkt dat de toepassing van standaarden sneller achterblijft omdat overheden gebruikmaken van externe leveranciers.

Hoe groter de afstand tussen klant en dienstverlener, hoe slechter de kwaliteit. In theorie zou het omgekeerd moeten zijn en zouden gespecialiseerde bedrijven hogere kwaliteit moeten kunnen leveren.

Helaas wordt het inkopen van dat soort diensten typisch gedaan door mensen die er zelf geen verstand van hebben en alleen naar features en prijs kijken. Die mensen met harde technische kennis die wel zelf kunnen oordelen hebben typisch echter geen zin in een rol als inkoper.

Iedere volgende tussenpartij is een punt waarop wensen en eisen kunnen sneuvelen. De minst zichtbare eisen sneuvelen het eerste. Aangezien security altijd op de achtergond werkt en haast niet te beoordelen is voor leken raak je die al snel kwijt.

[Verwijderd]

Eerst een paar jaar overleggen, iets bouwen wat niet werkt, nog meer overleggen, weer wat bouwen. etc Welkom bij de overheid.

[stefanass]

achterblijft omdat overheden gebruikmaken van externe leveranciers

Ligt dus niet zo zeer aan de overheid zelf, maar aan de software leveranciers die ze gebruiken. Deels zal dat ook komen doordat voldoen aan deze regels niet of niet voldoende in de opdrachten/contracten staat.

[Frame164]

Bij veel overheidsorganisaties heerst een cultuur van geen fouten maken i.p.v. dingen opleveren. En zolang je praat maak je geen fouten. En tegen de tijd dat de fouten gemaakt gaan worden werkt iedereen uit de eerdere discussies al op een andere afdeling.

[HansvDr]

Creëer gewoon 1 systeem beste overheid. Alle departementen, gemeentes, provincies enz. dezelfde website. Zorg dat dat voldoet aan de eisen. Geld ook voor mail.

Klaar.

[Frame164]

Dan krijg je een onwerkbaar gedrocht. En ik neem dat je niet bedoelt dat je geld voor email krijgt....

[Reactie gewijzigd door Frame164 op 22 juli 2024 13:53]

[HansvDr]

Allemaal hetzelfde design en techniek uiteraard. Niet allemaal zelf het wiel uitvinden. E-mail allemaal dezelfde configuratie