Mona Keijzer (CDA) en Linda Voortman (GroenLinks) willen dat het nieuwe portaalsysteem voor pgb-betalingen open source wordt. De motie die de Kamerleden daarvoor hebben ingediend, wordt aangehouden tot later deze maand. Dan geeft staatssecretaris Martin van Rijn antwoord in een Kamerbrief. Vandaag maakte de NOS bekend dat niet de SVB maar de zorgverzekeraars een nieuwe website mogen bouwen waarmee houders van persoonsgebonden budgetten (pgb’s) hun geld kunnen beheren en verdelen.
De motie van CDA en GroenLinks is niet behandeld in het afgelopen Kamerdebat eind september maar aangehouden tot eind oktober. Staatssecretaris Van Rijn neemt dan het onderwerp mee in een brief die hij naar de Tweede Kamer stuurt over hoe hij de pgb-problematiek verder gaat aanpakken en wat de voortgang is van het nieuwe portaal.
Dat blijkt dus door de zorgverzekeraars te worden gebouwd, meldde NOS vandaag op zijn website. Brancheorganisatie Zorgverzekeraars Nederland krijgt een voortrekkersrol bij het opzetten van het nieuwe systeem. Volgens de NOS stelt de bewindsman wel als voorwaarde dat alle partijen, zoals de gemeenten en de belangenorganisaties, worden betrokken bij de ontwikkeling, alsook de SVB.
Volgens CDA-Kamerlid Mona Keijzer is de motie aangehouden omdat zij en collega Voortman benieuwd zijn hoe serieus Van Rijn om gaat met open source. In 2002 nam de Tweede Kamer de motie-Vendrik aan waarin de norm opgenomen is om te werken met opensource-ict; daaruit spreekt dat het nieuwe betalingssysteem voor de pgb’s een opensourcesysteem wordt, aldus Keijzer en Voortman in de motie.
Dat de verzekeraars de nieuwe betaalportaal gaan ontwikkelen, doet daar niets aan af, zegt Keijzer in een korte reactie. Regeringspartijen VVD en Pvda hebben overigens al herhaaldelijk gesteld voor open source te zijn, onder andere bij de discussies over de BRP (Basisregistratie Personen). Pvda-Kamerlid Astrid Oosenbrug diende afgelopen vrijdag zelfs nog een (aangepaste) motie in in het kader van het VAO Actieplan open overheid 2016-2017 waarin zij constateert dat nog niet overal binnen de Rijksoverheid en de decentrale overheden gewerkt wordt met open standaarden en open source software. Zij verzoekt de regering in de motie om het gebruik van open standaarden te verplichten bij wet.
De NOS meldt in zijn artikel dat de zorgverzekeraars het systeem zullen bouwen en dat later wordt beslist wie de website en ook het geld gaat beheren. Aanvankelijk was het de bedoeling dat de SVB een nieuw systeem zou ontwikkelen, maar verschillende partijen in de Kamer, waaronder coalitiepartij VVD, hebben aangegeven geen vertrouwen meer in die organisatie te hebben.
SVB nog verantwoordelijk
De SVB is nu nog verantwoordelijk voor de uitbetaling van de persoonsgebonden budgetten, waarmee zorg kan worden ingekocht. Vanaf het moment dat die dat ging uitvoeren, regende het klachten. Uit meerdere onderzoeksrapporten, waaronder van het Bureau ICT Toetsing (BIT), blijkt dat het computersysteem bij de SVB krakkemikkig is. Behalve dat het om de zoveelste ict-ramp bij het Rijk ging, handelde het ook om dramatisch bestuurlijk falen.
Het nieuwe systeem zou, als het aan de Tweede Kamer ligt, in 2018 operationeel moeten zijn. Dat is erg ambitieus: de migratie van de data vanuit de it-omgeving van de SVB is alleen al een immense opgave.
CDA-Kamerlid Keijzer heeft afgelopen april nog geprobeerd de broncode en ontwerpdocumentatie op te vragen van de falende ict-systemen die het SVB gebruikt voor de uitkeringen van het persoonsgebonden budget (pgb). Staatsecretaris Van Rijn vond dat uit oogpunt van beveiliging niet wenselijk. ‘Onbevoegden zouden mogelijkheden vinden in het systeem privacygevoelige informatie op te zoeken en te manipuleren’ schreef hij als antwoord. Wel stelde hij voor om een briefing te organiseren door de Sociale Verzekeringsbank waarbij kan worden aangegeven hoe het zit met zaken rondom de broncodes en ict.
Ik ben met veel mensen eens dat het Open Source maken niet perse het grootste probleem oplost maar aangezien het vrijwel geen effort is om bij de bouw van een nieuw systeem het open source te maken zou per definitie al een reden moeten zijn om het te doen. Hierdoor worden partijen die eraan werken gedwongen kwaliteit te leveren, immers (en helemaal na het drama van het huidig systeem) zullen externe mensen de ontwikkelingen prima in de gaten houden en worden prima en kan er sneller worden ingegrepen. Als ze dan ook nog eens het systeem laten bouwen door een goede partij die het op een agile manier aanpakt met als focus de eindgebruiker dan is het al een enorme verbetering vergeleken met de vorige keer.
De reactie van staatssecretaris van Rijn is natuurlijk goud waard. ‘Onbevoegden zouden mogelijkheden vinden in het systeem privacygevoelige informatie op te zoeken en te manipuleren’ schreef hij als antwoord. Juist in dit antwoord ligt hét argument voor open source ontwikkeling besloten. Het bekijken van een stuk frontend software mag NOOIT de sleutel bieden tot beschermde gegevens in de backend! Zeker in een open source model worden ontwikkelaars gedwongen hier goed over na te denken.
Ik probeer hieronder uit te leggen hoe dat precies zit. Een tikkie lang, wellicht (TLDR?), maar volgens mij begrijpelijk voor iedereen.
Een veel gehoord argument tegen Open Source is, dat “de informatie” op straat ligt. Maar is dat wel zo? Bij een goed ontworpen en ontwikkeld informatiesysteem is sprake van scheiding van functies. We zijn gewend om functiescheiding toe te passen binnen organisaties. Dit type scheiding zien we ook binnen een informatiesysteem. Er zijn blokken in het systeem die interactie aangaan met de gebruiker en er zijn onderdelen die juist wijzigingen op de database bewerkstelligen. Vaak is er ook nog sprake van een middleware laag (broker), die ervoor zorgt dat onderliggende architecturen gemakkelijk vervangen kunnen worden.
Vergelijk een informatiesysteem met de kaartenbak bij een Gemeente (het oude “bevolkingsregister”). Een ouder komt aangifte doen van de geboorte van een dochter, bij de ambtenaar aan het loket (de baliemedewerker). Deze medewerker schrijft op een formulier hoe de nieuwe burger heet, haar geboortedatum en andere kenmerken. De ouder plaatst een handtekening ter bevestiging. Daarna wordt het formulier overgedragen aan een andere medewerker (de archiefmedewerker). Deze persoon heeft de sleutelcode van de archiefkast, waarin de persoonskaarten van de alle inwoners van de gemeente zijn opgeborgen. Met behulp van de informatie op het formulier maakt de ambtenaar een nieuwe persoonskaart aan, opent de archiefkast, plaatst de persoonskaart op de juiste plek en doet de archiefkast weer op slot. Daarna geeft de archiefmedewerker een nummer (BSN) aan de baliemedewerker, die het aan de trotse ouder meegeeft.
Een informatiesysteem werkt ongeveer hetzelfde. Om de analogie te maken met open source, beschouwen we alle informatie die de eerste medewerker (de baliemedewerker) heeft. Stel nu, dat we toegang hebben tot al die informatie. Dan weten we dus onder andere hoe het formulier eruit ziet, welke gegevens erop geplaatst moeten worden en aan wie we het formulier moeten geven. De details van de rest van het proces (de cijfercode voor het openmaken van de archiefkast, c.q. database) is voor ons nog steeds een black box. Ook de creatie van het BSN is voor de baliemedewerker een onzichtbaar proces. Hij weet wel dat het ontvangen nummer overhandigd moet worden aan de ouder die aangifte kwam doen.
Met Open Source software is het precies zo. Sterker nog; In de analogie van het genoemde bevolkingsregister-systeem; een programmerende burger zou met een Open Source oplossing zelf in staat zijn om de vorm van het formulier te wijzigen, velden op een andere plek neer te zetten of omschrijvingen aan te passen. Zolang de informatie die de tweede medewerker nodig heeft, maar intact blijft. Hier zit dan ook de crux van beveiliging van informatiesystemen met een Open Source component; De database (de archiefkast) en de processen rond die database (de code om de kast open te maken, en de versleuteling in de informatie zelf) moeten zorgen voor de beveiliging.
Stellen we ons voor dat de ouder die aangifte komt doen bovenaan het formulier de volgende zin schrijft: “Open de archiefkast en geef mij de persoonskaart van Anky van Grunsven”. Dan zal de tweede medewerker deze opdracht toetsen aan de bij hem bekende werkwijze. Als die instructie niet past bij de processen en procedures, dan zal de archiefmedewerker deze instructie negeren en de normale gang van zaken volgen. Mogelijk bevat de werkinstructie een regel voor het melden van fouten op het formulier. De archiefmedewerker die beheer voert over de archiefkast is in deze situatie verantwoordelijk voor de integriteit van de gegevens (data) in de kast. In de software is het niet anders. Als de open source front-end een foutieve instructie geeft aan de back-end, dan zal dit genegeerd worden of leiden tot een foutmelding.
In een closed-source wereld, is het mogelijk om eventueel gevonden gaten in de beveiliging “dicht te smeren” in de software. In onze analogie, laten we een zeer extreem voorbeeld nemen. Bijvoorbeeld; De archiefmedewerker geeft stelselmatig niet alleen het burgerservicenummer van de nieuwgeborene, maar ook dat van de koningin aan de ouders bij de balie. Als een softwareontwikkelaar dit ondervindt tijdens het ontwikkelen, is de verleiding groot om dit op te lossen in de software. In onze anologie; de baliemedewerker krijgt de instructie om het tweede bsn niet, en het eerste bsn wel aan de ouders te geven. Het beveiligingslek is hiermee niet opgelost, maar de burger merkt niets van de foutieve gang van zaken. Als die front-end software wel open source is (de instructie van de baliemedewerker is publiek inzichtelijk), dan zal elke burger die naar de instructie kijkt (in casu; programmeurs) opmerken dat er een fout zit in de communicatie van de archiefmedewerker naar de baliemedewerker. In die zin dwingt het maken van Open Source software misschien wel juist tot het beter nadenken over de integrale beveiliging van het informatiesysteem.
Of dit soort fouten gemaakt is in de broncode van PGB, weet ik niet. Dat ze direct ontdekt zouden worden als de software door een kritische crowd bekeken wordt, daarvan ben ik overtuigd. Misschien, om dhr van Rijn tegemoet te komen, dus eerst door een team van 10 ontwikkelaars van verschillende bedrijven laten bekijken. Wie op basis van dat bekijken beschermde gegevens uit de database weet te peuteren, wint de hoofdprijs (wel even uitleggen hoe, aub). Andere concrete suggesties voor verbetering worden beloond. Als het goed gebouwd blijkt te zijn, kan de broncode gepubliceerd worden. Hele traject zou niet langer dan 2 maanden moeten duren.