Testdata management: Hoe kun je datalekken voorkomen? [deel 1]

Wie kent er geen geval van concurrentie- of privacygevoelige gegevens die onbedoeld openbaar zijn geworden? (Zwart-)spaardergegevens van een Zwitserse bank die werden verkocht op een CD’tje. Inloggegevens van LinkedIn-gebruikers die je op internet kon vinden. De NSA die haar Top Secret-gegevens niet voor de buitenwereld geheim kon houden. Veel bedrijven hebben hun informatiebeveiliging nog niet op orde. Recent heeft zich dichtbij huis, in Nederland, een voorbeeld van falend beveiligingsbeleid voorgedaan. In de zomer van dit jaar bracht een zorgverzekeraar een persbericht uit, waarin het bedrijf vertelt dat er vertrouwelijke informatie is gelekt en verdere aanscherping van de procedures aankondigt. Wat is de voornaamste oorzaak van deze zogenoemde datalekken? En wat kunnen we eraan doen? Laten we dat eens nader bekijken.

Door een fout van een tester zijn de gegevens van verzekerden op een onbeveiligde server terecht gekomen. Jarenlang hebben de gegevens daar gestaan. Er zijn geen aanwijzingen dat onbevoegden toegang hebben gehad tot de gegevens, maar de interne procedures zijn wel onmiddellijk aangescherpt. Als je dit leest, kan ik me voorstellen dat de procedures zijn aangescherpt! Want dit incident kent alleen maar verliezers. Allereerst de zorgverzekeraar die ernstige reputatieschade oploopt en een zware boete riskeert. Ten tweede: de verzekerden. Mogelijk zijn hun privacygevoelige, vaak medische gegevens in handen gekomen van mensen die daartoe helemaal niet bevoegd zijn. En als laatste verliest op zijn minst één medewerker van de zorgverzekeraar. Die zal slecht slapen, want een ogenschijnlijk goedbedoelde actie om het werk efficiënter in te richten leidde tot dit incident Ik moet zeggen dat ik vind dat de zorgverzekeraar goed heeft gehandeld. De zorgverzekeraar is transparant over de oorzaak van het incident, kondigt maatregelen aan en beseft dat ze menselijke fouten nooit helemaal kan voorkomen. Het persbericht is leerzaam voor andere organisaties. Ik zal uitleggen waarom

De P-omgeving is wel veilig, maar hoe zit het met O,T en A? Organisaties richten productieomgevingen in met over het algemeen doordachte autorisatiemodellen, zware firewalls en betonnen bunkers om hun data te beschermen tegen computercriminelen, bomaanslagen, aardbevingen en ander onheil. Naast de productieomgeving richten diezelfde organisaties ook een Ontwikkel- Test- en Acceptatieomgeving in, waarmee ze de bekende OTAP-architectuur realiseren. Veel organisaties vinden het echter te omslachtig en te duur om de O-, de T- en de A-omgevingen op dezelfde wijze in te richten en te beschermen. De meeste organisaties kiezen daarom voor lichtere hardware. Om het voor de tester makkelijk te maken zetten ze de firewall ‘even’ uit, terwijl het autorisatiemodel bestaat uit testuser1, testuser2 en testuser3 met als wachtwoord WELKOM. Komt je dat bekend voor? Ervaringsdeskundigen zullen beamen dat ik niet overdrijf, ook niet als ik vertel dat diezelfde organisaties in de O-, T- en A-omgeving doodleuk kopieën van de productiebestanden neerzetten. Uit een Gartner onderzoek uit 2011 blijkt dat 80 procent van alle organisaties wereldwijd productiedata gebruiken voor het testen van software. En daar hebben we meteen de oorzaak van de meeste datalekken: in omgevingen die - en nu overdrijf ik misschien wel - zo lek zijn als een mandje worden databases neergezet met gegevens die nooit openbaar mogen worden. Wat kunnen we hier aan doen? Simpel, zou je zeggen. Bescherm je O-, T- en A-omgeving op dezelfde wijze als de productieomgeving. Of zet geen productiedata in de minder beschermde omgevingen. Maar ja, het ene is te duur en het andere is complex en gaat ten koste van de doorlooptijd en kwaliteit van het testproces. Of is dat laatste eigenlijk helemaal niet het geval? Met een combinatie van de benodigde kennis, de juiste organisatorische keuzes en eventueel de inzet van de huidige intelligente tooling voor het anonimiseren en subsetten van productiedata, is het mogelijk om representatieve, anonieme en dus veilige data in de O-, T- en A-omgeving te zetten. Als je het testdata managementproces goed inricht, zullen persberichten zoals hierboven uitblijven. De genoemde medewerker van de zorgverzekeraar zal weer lekker slapen, want op zijn privé-server staan alleen data die niet herleidbaar zijn naar échte personen.

Dit is deel 1 van een serie blogartikelen over testdata management. In de komende artikelen ga ik in op welke kennis benodigd is, hoe je de juiste organisatorische keuzes kunt maken en wat de huidige intelligente tooling voor het anonimiseren en subsetten van productiedata daadwerkelijk kan.

Interessant voor jou? Handige SmarTEST tools Valori onderkent vijf - door een rode draad verbonden - handvatten die je nodig hebt voor de regie op het totale test- en acceptatieproces. Deze zijn gebaseerd op erkende ‘best practices’ en hebben hun waarde in de praktijk van complexe ICT implementaties bewezen. Klik op de button hieronder voor de tools:

Auteur: Boris de Hingh