GGD-systemen: vernieuwen of oplappen?

Dit artikel delen:
Zoeken

Minister Hugo de Jonge (VWS) kreeg op zijn kop van de Tweede Kamer om zijn lakse reactie op het datalek bij de GGD. Hij beloofde ervoor te zorgen dat de persoonsgegevens van Nederlandse burgers beter beschermd zouden worden. Maar hoe dan? Moeten de GGD-systemen worden vervangen? Of is oplappen het devies?

De bewindsman kreeg gisteren in de Kamer veel kritiek op zijn volgens velen nonchalante reactie op het datalek bij de GGD. Vorige week bleek dat GGD-medewerkers toegang hadden tot privégegevens van burgers die zich hebben laten testen op het coronavirus. Een onbekend aantal gegevens is vervolgens te koop aangeboden. Hij beloofde beterschap en er voor te zorgen dat GGD-medewerkers niet meer zo maar bij persoonlijke gegevens van geteste burgers kunnen komen.

Maar wat is de beste oplossing, nu tevens is gebleken dat het GGD-landschap verouderd is en al maanden lek? Vernieuwen zoals de GGD wil, en specifiek het systeem HPZone Lite door een ander registratiesysteem. Dat vindt het RIVM (Rijkinstituut voor Volksgezondheid en Milieu) geen goed idee. Directeur Jaap van Dissel waarschuwt in een brandbrief dat een te snelle overstap op iets nieuws het zicht houden op en het inzicht hebben in de verspreiding van het coronavirus nadelig kan beïnvloeden. 

Of volstaat het doorvoeren van een aantal basale it-veiligheidsmaatregelen die volgens een opinie op Computable.nl niet of onvoldoende zijn genomen? Zoals het beperken van het aantal opvragen per dag, voorkomen van downloaden van complete lijsten, afschermen van een deel van het burgerservicenummer (bsn) en stevige monitoring op ongebruikelijk gedrag. Zaken die door ervaren it'ers in een paar weken zijn te realiseren.

Wat vindt u: vernieuwen of oplappen?

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

De vraag of er wel of niet nieuwe systemen moeten komen voor de GGD is ongetwijfeld een interessante. Maar dat midden in een Corona crisis voorstellen is bijzonder dom.
Wie van ons in ICT-land heeft een overheidsproject binnen 2 jaar, zonder incidenten en vertragingen zien lukken?
Dus constateren dat er straks iets moet gebeuren prima, maar nu even niet!

Wat je technisch met en procedureel rond HPZone Lite kan doen om de problemen op te lossen, dat weet ik niet. De voorstellen van Ap zijn wellicht voldoende. De makers en beheerders van het systeem kunnen dit het beste aangeven. De vraag is of het vervangen van systemen nu de beste oplossing is. Het is vanuit change management heel riskant om bij zo’n warrige klant in zo’n hectische tijd primaire systemen te gaan vervangen. Is er bijvoorbeeld genoeg tijd voor conversie en testen? De kans is groot dat ze uiteindelijk in een situatie komen waarbij ze een oud en een nieuw systeem in de lucht moeten houden met overlappende data en een extra database moeten beveiligen.
Het RIVM is terecht bang dat hun informatievoorziening door een nieuw GGD systeem in het geding komt. VWS zou de regie van het ketenmanagement op zich moeten nemen, dus ook moeten beslissen of ze de HPZone omgeving verder gaan aanpassen of vervangen.

Er zijn allerlei operationele en organisatoische risico's te bedenken als je tijdens een crisis veranderingen aan gaat brengen in je informatiesystemen. Eén van de risico's is dat je lekken dicht en daarmee ook bepaalde gebruikers afsluit van informatie. Als gevolg van exportfuncties staan persoonsgegevens op fileshares, USB disks en liggen uiteindelijk op straat want het is algemeen bekend dat onderzoekers individuele rechten zoals privacy en keuzevrijheid als sta-in-de-weg zien. De vraag of we individuele rechten laten vervallen als het algemene belang in gevaar komt is een lastige maar wel één waar we goed over moeten nadenken:

"In challenging times one must question the accepted reality because things are going wrong, rapid answers are needed and the solution may well be found outside the usual compass." - Winston Churchill

We gaan wellicht voorbij aan de essentie. Wat is er mis?
je mag aannemen dat er een architectuur is en een ontwerp.

Er zal destijds niet voldaan zijn aan de design principes zoals deze nu in de privacywetgeving zijn opgenomen. Maar er is natuurlijk wel een scan gedaan zodra deze wet in werking trad of de systemen daar nog aan voldoen. En er is natuurlijk ook een budgetaanvraag geweest om die aanpassingen door te voeren?
niet? Dat is dat een mooi startpunt.

Maar het is natuurlijk ook nog eens zo dat hier in een voor de overheid zeer korte tijd een compleet systeem is neergezet. Vanzelfsprekend zijn hier shortcuts genomen ook in ontwerpen, bouwen, testen en evaluatie. Daar zullen we mee moeten dealen en dat mag mijns inziens ook wel in een crisissituatie.

De misbruikers moeten wat mij betreft zwaar worden bestraft. Die hebben namelijk ernstig misbruik gemaakt van de situatie en het vertrouwen.

Churchill had wat mij betreft een punt.

Met Luuk eens dat je soms, in tijden van crisis, hazepaadjes moet nemen om snelheid te winnen. Wij hebben in de tijden van bestrijding van mond en klauwzeer en varkenspest ook snel, maar niet super afgeschermde systemen neergezet. In zo'n situatie, eigenlijk in alle gevallen, is screening van de medewerkers op betrouwbaarheid en chanteerbaarheid, dan ook zeker nodig.
Dat is op korte termijn overigens ook niet te regelen.
Ik zou in dit geval toegang tot de "export" functie hebben beperkt tot een paar betrouwbare en gescreende mensen. Laat onverlet dat iedereen achter een scherm ook gegeven kan overnemen door ze handmatig te kopieren. Het blijft altijd puzzelen.

Hoezo challenging times? De overgangsperiode naar de AVG was van 24 mei 2016 tot 24 mei 2018. Daarvoor gold de Wet bescherming persoonsgegevens inwerking getreden op 1 september 2001. Daarvoor gold al de Wet persoonsregistraties in werking getreden op 1 juli 1989. Als het in begin 2020 alsnog zo gigantisch mis gaat, dan is er geen sprake van “challenging times” maar van ernstige nalatigheid. En die kon je ook al voor 1 juli 1989. ook al aangerekend worden. De GGD GHOR heeft dit probleem geheel aan zichzelf te danken. Of mogen we ook een paar decennia langer 130 kmh op de snelweg blijven rijden?

Hier moet duidelijk snel "opgelapt" worden, waarna men zeker een nieuw (moderner, flexibeler en veiliger) systeem moet gaan bouwen. Na deze crisis komt er met de tijd ongetwijfeld weer een nieuwe situatie, waarin we als burgers er zeker van dienen te zijn dat een instantie als de GGD betrouwbaar en veilig met onze persoonlijke gegevens omgaat. Daarnaast is er heel wat te verbeteren aan de algehele informatievoorziening, gebruiksvriendelijkheid en flexibiliteit. Er zijn tegenwoordig prima technieken om snel en betrouwbaar "op te lappen" en te vernieuwen.
Dus Overheid: Kom in beweging! Immers, de hierboven ook reeds aangehaalde Winston Churchill wist het al ...: "Never waste a good crisis"

Ik ken dat HPzone Lite niet maar hopelijk is er een WebAPI waar de frontend UI mee praat en die helemaal los staat van de schermgeneratie of de Windows-applicatie. Zo niet hebben ze misschien - al of niet distributed - dynamic link libraries. Zo niet, hebben ze dan hopelijk in ieder geval 2-laags SQL client server direct vanuit de UI. Als dat laatste het geval is, moeten ze dus een WebAPI om die database heen bouwen waarbij ze met een beetje geluk in ieder geval de oude COM-libraries kunnen gebruiken. Zo niet, moeten ze eerst alle procesfunctionaliteit in stored procedures gaan herschrijven. Als het SQL Server is hebben ze geluk en kunnen ze COM en .Net Libraries redeployen als CLR Stored Procedures. Dat zou echt enorme mazzel zijn. Als ze meerdere database-instances hebben, moeten ze API multitenant naar de databases maken middels een reverse-proxy. Ik ga ervan uit dat er een genormaliseerd en goed relationeel datamodel achter zo'n applicatie zit. Als dat ook niet het geval is, moeten ze achter een nieuw te ontwikkelen database met de data van de oude omgeving gaan praten met een soort ad hoc gebouwde API met screen grabbers of zo. Maar zo gruwelijk zal het allemaal vast niet wezen.

"Never waste a good crisis", dat wisten die gasten die de exportfunctie gebruikten vast ook.
dan maar advertentie zetten, gezocht : "een paar betrouwbare en gescreende mensen" :-P

Je moet het natuurlijk niet oplappen noemen, zo onprofessioneel.
Continuous improvement, kortcyclisch waarde toevoegen.
Business as usual.

@Rob,
Ik vraag me af hoeverre het MVC model voldoende is doorgevoerd om de data mbv van microservices te kunnen ontsluiten.
Zeker wanneer de service mesh de CLR stored stored procedure API aanpak gewoonweg onmogelijk maakt.
Geen probleem als je het niet kunt volgen. Het klinkt tenslotte zeer interessant.

@Rob ... BINGO!

oh, dacht even dat het de meer technische variant van bullshit-bingo was

@Dino, ik kan het volgen en het klinkt niet interessant. Maar ook dat is geen probleem wmb.

Cynicus, we hebben alle gerefereerde concepten wel operationeel draaiend. Wil je het zien?

Wat mij betreft is dit vooral een organisatieprobleem. Als je doet wat je altijd deed, krijg je wat je altijd kreeg. De vraag of je een systeem opnieuw gaat bouwen of niet, lost het onderliggende probleem niet op. De afgelopen jaren is de focus bij de GGD gelegd op kostenbesparing en decentralisatie. Nu het alle hens aan dek is, wil het ministerie graag centraal de regie nemen, maar dat staan de decentrale it-systemen helemaal niet toe.

Daar komt bij dat privacybescherming in de jaren hiervoor niet voldoende een aandachtspunt is geweest. In de relatief kleine decentrale GGD-organisaties kenden ze al hun medewerkers goed en vertrouwden ze erop dat zij vertrouwelijk met de data omgingen die ze beheerden. Je kunt je dus afvragen of Privacy by design wel voldoende een uitgangspunt geweest is bij de bouw van de systemen.

Tot slot: ik kan me helemaal vinden in de quote van Winston Churchill. Je moet in tijden van crisis bepaalde risico’s durven toe te laten. Maar je moet dan wel heel duidelijk zijn in waar absoluut niet aan getornd mag worden, zoals integriteit en veiligheid. Nu ziet de gebruikers-kant er bijvoorbeeld netjes uit, maar liggen belangrijke kwetsbaarheden open.
Slimme organisaties wachten niet tot ze in een crisis zitten met bedenken welke risico's wel en niet toelaatbaar zijn, maar maken vooraf een risico-inventarisatie.

Hoi Hans,
Wel of niet opnieuw een systeem bouwen is in mijn ogen een schijndilemma: het leidt helemaal niet tot andere keuzen. Of en wanneer iemand als laatste het licht uitdoet in de huidige user interface (UI) is het sluitstuk van het hele traject. Voor hetzelfde geld kan de huidige UI gedurende het traject nog wel voldoende aangepast om tenminste nog deels te worden ingezet. Je zult het in ieder geval gedurende en na de hele transitiefase nog moeten kùnnen gebruiken. Niets is zo fnuikend als een 'overnacht'-migratie waarbij de volgende dag de oude omgeving passé is en die nieuwe omgeving na wat testjes de kar moet gaan trekken. Dat soort feestjes zullen ze toch hopelijk in 2021 een organisatie niet meer aandoen.

Rob Koelmans,
Misschien goed als je eerst het 13 pagina's tellende feitenrelaas dat naar de tweede kamer is gestuurd leest want ik vrees dat het toch vooral een organisatorisch probleem is als je overweegt dat een bron- en contactonderzoek per definitie een ferme inbreuk op het grondwettelijke recht om onbespied te mogen leven is. En uiteindelijk ben ik dan ook vooral verbaasd over het feit dat een it-systeem wat al 17 jaar operationeel is nog voor zoveel problemen kon zorgen want dat je operationeel op moet schalen bij een epidemie lijkt me logisch. Heeft iemand al vragen gesteld over de rechtmatigheid van gestructureerde en ongestructuurde gegevensverzamelingen als het om de bewaartermijnen gaat?

Een nieuw te ontwikkelen database betreft alleen de opslag van data middels een bepaalde structuur waarvan de controleur als een magazijnmeester de uitgifte regelt zonder te weten dat in moderne DIKW-model van datasynthese meerdere bronnen gecombineerd kunnen worden om zo een inzichtelijkheid te geven die veelal onwenselijk is. Het All People Seems To Need Data Processing middels alle exportfuncties in een meerlaagse architectuur lijkt me dan ook het meest prangende probleem. Uteindelijk wordt de UI steeds minder interessant in een wereld waarin 'redeneerstappen' zonder tussenkomst van mensen data verwerken.

@Oudlid. Afgaande op dat feitenrelaas, denk ik dat er een gigantisch it-architectonisch probleem achter dat organisatorisch probleem schuilgaat. En nog zorgwekkender is dat het nergens daarover gaat. Verder hoop ik dat die brandbrief van RIVM niet op een reële angst is gestoeld Ze gaan echt niet alle bestaande functionaliteit achterover trekken zoals die brief suggereert. Ervan uitgaande dat de her en der aanwezige functionaliteit wel aan de bestaande vraag voldoet, hoeft het reorganiseren van de architectuur misschien helemaal niet zoveel tijd te kosten. Ben benieuwd wat er allemaal instort als er nu ergens een verbinding wegvalt. Stageren dan nog werkende onderdelen in de keten alsnog? Is er dataverlies of vindt alles netjes uitgesteld plaats? Kan dat getest worden?

Rob Koelmans,
Zeker ligt er een gigantisch it-architectonisch probleem en niet alleen bij de GGD als we kijken naar alle organisatorische problemen in ketens die een breiwerk aan koppelvlakken blijken te zijn. Zo wordt het toezicht houden op geautoriseerde exportfuncties niet echt een succes als functionaris geen ballen en competenties heeft om het tot stand komen van onrechtmatige gegevensverzamelingen, al dan niet gestructureerd, te voorkomen. Er mist dan ook wel meer in het feitenrelaas als er vanuit de IT andere uitkomsten verwacht worden terwijl er organisatorisch niets gewijzigd wordt.

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2021-02-04T15:58:00.000Z Rik Sanders
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.