Naar aanleiding van een discussie met een hacker die de zoveelste simpele beveiligingsfout in een overheidswebsite had ontdekt (jawel, een SQL-injectie) verwonderde ik me er over dat er geen enkele controle is op systemen die grootschalig persoonsgegevens verwerken of opslaan. Dat is eigenlijk raar, en geeft aan dat het besef van risico’s op het gebied van ICT bijzonder laag is bij de overheid. Ik was dan ook blij verrast een uitnodiging voor een ‘open koffie’ in mijn mailbox te vinden voor maandag 9 mei a.s. waarin dit onderwerp aan bod komt, georganiseerd door ambtenaar 2.0. Ik ben daarbij, om te pleiten voor een verplichte controle door een onafhankelijke partij die verstand heeft van beveiliging wanneer een systeem wordt opgeleverd, en deze partij al bij het opstellen van de eisen ind de aanbesteding te betrekken.

Het is niet de eerste keer, en zeker niet de laatste, dat een overheidssite slecht in elkaar blijkt te zitten. Vorig jaar al kondigde een andere bevriende hacker de ‘mogbug’ (‘month of government bugs’) aan. Hij/zij had in maar liefst 30 verschillende overheidssites lekken gevonden die toegang gaven tot persoonsgegevens of mogelijk gebruikt konden worden om bezoekers te misleiden en hun gegevens prijs te geven. Het gaat dan om elementaire fouten zoals SQL-injectie of cross-site scripting (XSS). Dit zijn fouten die een beginnend programmeur nog mag maken, maar bij een professioneel ICT-bedrijf simpelweg niet mogen voorkomen. En al helemaal niet bij een bedrijf dat door de overheid wordt betaald om systemen te ontwikkelen.

Dat deze fouten toch keer op keer de kop op steken heeft een aantal redenen. Om te beginnen is er bij de gemiddelde ‘brood-programmeur’ weinig besef van beveiliging. Er wordt gekeken naar de functionele eisen aan het systeem, en wanneer het geschreven programma daar aan voldoet is het ‘af”. De functionele eisen worden oogkleppen, de programmeurs bezien hun noeste arbeid slechts in het licht van normaal gebruik. Voer het systeem onverwachte input, en er gebeuren ineens vreemde dingen.

Er zijn enkele basis-principes die een programmeur kan aanhouden om dit soort voor de hand liggende maar verstrekkende fouten te voorkomen. De principes zijn geen goed bewaard geheim, wie een simpele google query doet naar “how to build secure web applications” is al een heel eind. Het hoeft niet meer dan een half uur te kosten om programmeurs bewust te maken van de meest voor de hand liggende risico’s. Wie dan ook nog eens een paar uurtjes steekt in het lezen van bijvoorbeeld de vrij beschikbare OWASP development guide zal niet snel meer met open ogen in de oude valkuilen lopen.

Kortom, met een kleine hoeveelheid basis-kennis en een dosis gezond verstand kunnen de keer op keer weer gemaakte beginnersfouten worden voorkomen. Echter, er is meer nodig. Veiligheid is niet iets dat achteraf aan een systeem kan worden toegevoegd. Voor een veilig systeem is het nodig reeds in de beginfase al na te denken over mogelijke aanvallen op het systeem. ‘Security by design’ moet het uitgangsprincipe zijn. Wanneer het systeem ontworpen wordt, moeten de architecten en ontwikkelaars al nadenken over de risico’s en hoe deze zo klein mogelijk te maken.

Een goed ontwerp maken dat ook rekening houdt met alle mogelijke aanvallen die het systeem kunnen breken kost natuurlijk wel wat meer tijd dan wanneer men uitsluitend let op de functionele eisen. Een gebrek aan inzicht in beveiliging leidt er toe dat overheidsinstellingen dit niet voldoende meenemen in aanbestedingen van grote software-projecten. Hierdoor zal, bij gelijke aandacht voor de functionele eisen, de partij die wel ‘security by design’ toepast duurder uitpakken dan de partij die dit onder het tapijt schuift.

Tot slot is het belangrijk dat een opgeleverd systeem door een derde, onafhankelijke partij wordt getoetst. Het is eigenlijk niet zo heel ongewoon. Wanneer de overheid een pand laat bouwen, wordt na oplevering een bouwkundige inspectie uitgevoerd. Een opgeleverd ICT-systeem wordt echter klakkeloos in bedrijf genomen. De partij die het systeem heeft ontwikkeld mag het ook installeren en uitrollen. Er is geen inspecteur, die kijkt of het systeem veilig is gebouwd. Er is niemand die kijkt of niet weer de gebruikelijke fouten zijn gemaakt.

Gelukkig beschikt Nederland over een gezonde en bloeiende hacker-community, mensen met een idealistische drijfveer. Mensen zoals in mijn inleiding al genoemd. Zij kijken ongevraagd met een kritische blik naar alle systemen die de overheid uitrolt. Zij vinden de voor de hand liggende, en minder voor de hand liggende fouten. En rapporteren het resultaat van hun onderzoek onbetaald aan de overheid. Jammer genoeg is dat vaak aan dovemansoren gericht, en worden de bezwaren onder het tapijt of in de doofpot geveegd. “We willen niet de indruk geven dat we onzorgvuldig met gegevens van burgers omgaan”, “er is al zoveel geld uitgegeven, we kunnen dit nu niet meer terugdraaien”, en andere excuses om het eigen falen te verbloemen zijn niet van de lucht. In uitzonderlijke gevallen kreeg de goedbedoelende klokkenluider zelfs te maken met juridische intimidatie om toch vooral stil te houden dat er iets fundamenteel niet deugt.

Ik denk dat de privacy van burgers gebaat is bij het structureel toepassen van controle door ter zake kundige beveiligingsexperts. Huur hiervoor een gerenommeerd ICT beveiligingsbedrijf in, of beter nog zorg voor een eigen overheidsdienst met mensen die snappen waar het over gaat. Zorg dat elk systeem eerst aan een uitgebreide controle wordt onderworpen, waardoor de elementaire vergissingen nog voor ingebruikname worden gesignaleerd. Betrek deze controleurs al vroeg bij het bedenken, uitwerken, implementeren en uitrollen van systemen zodat zij ook mee kunnen denken over de aanbesteding en al tijdens het uitvoeringstraject aan de bel kunnen trekken.

Het frappante is, er bestaan al een aantal organen die deze rol zouden kunnen (of moeten) vervullen. Enerzijds is er GOVCERT. Deze overheidsorganisatie heeft als missie ‘het voorkomen en afhandelen van ICT-veiligheidsincidenten’. In de praktijk blijkt dit een papieren tijger. Het team wordt niet tijdig bij grote aanbestedingen betrokken. Maar ook wanneer ze worden geconfronteerd met lekken in bestaande systemen, staan ze met de handen op de rug gebonden. Ze hebben geen macht, maar kunnen slechts advies geven.

Hetzelfde geld eigenlijk voor het College Bescherming Persoonsgegevens (CBP). Zij is ingesteld om toe te zien op de naleving van de wet bescherming persoonsgegevens. Hoewel ze advies kunnen geven, is het niet verplicht bij de implementatie van een systeem om ook de veiligheid hiervan te laten toetsen door het CBP (dit even los van de vraag of het CBP uberhaupt over de technische know-how beschikt om hier een deskundig oordeel over te kunnen vormen).

Dus zowel de officiele instanties zoals GOVCERT en het CBP alsmede de hacker-community lopen voortdurend achter de feiten aan. Pas als het eigenlijk al te laat is, krijgen zij de kans om lekken in de software te onderzoeken en te signaleren.

Ik pleit er daarom voor dat beveiliging van systemen een principieel uitgangspunt wordt bij de start van een nieuw groot overheidsproject. GOVCERT moet hierin een belangrijke rol krijgen. Dit betekent ook dat zij vooraanstaande experts op het vakgebied meer moeten betrekken, of wellicht zelfs in dienst moeten nemen. Ook moeten de bevoegdheden worden uitgebreid. Van vrijblijvend advies moet een fiat van GOVCERT een vereiste worden bij aanbestedingsprojecten en uitrol van nieuwe systemen.

En blijft de overheid falen? Dan is het aan ons, hackers van Nederland, om ons nog meer dan voorheen in te zetten om het falen aan de kaak te stellen. WOB de ontwikkeltrajecten, stel lijsten op van software-huizen die keer op keer onveilige systemen hebben afgeleverd, spreek top-ambtenaren publiekelijk aan op hun verantwoordelijkheid voor onze privacy, leg de zaken uit aan politici, benader de pers en blijf de overheid hacken. Wij zijn het technologisch geweten van de samenleving.

This entry was posted on Tuesday, May 3rd, 2011 at 10:30 and is filed under Dutch, Nationaal, Science 'n stuff. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.