Verander risico: Weinig gebruik maken van kennis van eerdere projecten

Vandaag gaan we in op het risico: Weinig gebruik maken van kennis van eerdere projecten

De “lessons learned” uit eerdere projecten kunnen we hergebruiken in de toekomstige projecten. Fouten die we in het verleden gemaakt hebben voorkomen we hier (voor een groot deel) mee. We zien vaak dat er na de oplevering van een project een uitgebreide evaluatie wordt uitgevoerd. Dit zou de basis moeten zijn voor verbeteringen in toekomstige projecten.

Toch zien we dat deze geleerde lessen te weinig worden hergebruikt. De evaluatie wordt uitgevoerd, de resultaten daarvan op papier gezet maar dan verdwijnt het al snel in een la waar het ligt weg te stoffen.

Natuurlijk zijn er hele specifieke leerpunten die nauwelijks her te gebruiken zijn. Maar er zijn veel meer punten die we wel kunnen gebruiken voor toekomstige projecten. Doen we dat op de juiste manier dan levert dat veel tijdswinst op omdat we niet steeds dezelfde fouten blijven maken.

Tapes met data 800.000 mensen verloren tijdens oefening

In de Verenigde Staten zijn tijdens een “disaster recovery” oefening verschillende back-up tapes met de gegevens van 800.000 burgers kwijtgeraakt. Na de oefening door IBM werden de tapes naar Iron Mountain gestuurd, maar kwamen daar niet aan. Op de tapes stonden namen, adresgegevens, social security nummers, rijbewijs- of identificatienummers, zorgverzekering en informatie van de werkgever (bron).

Een opmerkelijk bericht, als je het mij vraagt. Is de basis van een oefening niet dat het wel eens verkeerd zou kunnen gaan en dat je juist oefent om in geval van echte nood over de juiste “disaster recovery” maatregelen te beschikken? We analyseren de oefening en trekken de “lessons learned” zodat we goed voorbereid zijn.

Een basis principe daarbij is dat je een dergelijke oefening nooit uitvoert met daadwerkelijke gegevens. Nee, voor de oefening maak je gebruik van fictieve gegevens (of op zijn minst zorg je ervoor dat de gegevens versleuteld zijn…hoewel dat zeker niet de voorkeur heeft, fictief is in dit geval toch echt beter).

Maar goed, de tapes zijn opgestuurd en onderweg kwijt geraakt. We kunnen in ieder geval de les trekken dat we dergelijke gegevens of tapes niet zomaar versturen. Ik stel me zo voor dat ze gewoon in een doosje zijn gestopt met een adressticker erop. Ja ja. Mooie “disaster recovery” strategie is dat. In geval van nood wil je toch zeker weten dat de gegevens op een andere plek nog voorhanden zijn. Verzending via een reguliere poststroom lijkt me dan niet de veiligste oplossing.

Al snel zullen we denken dat we natuurlijk ook gewoon lege tapes zouden kunnen versturen om helemaal geen risico te lopen. Maar dat werkt niet. Nee, we willen juist testen of we nog bij de gegevens kunnen na een incident. We willen dus wel degelijk dezelfde hoeveelheid gegevens hebben, maar dan wel gerandomiseerd (zie ook de opmerking daarover op Security.nl).

Een positief aspect is dat men in ieder geval oefent. Er zijn nog genoeg organisaties die de op papier geweldige “disaster recovery” strategie nooit in de praktijk testen en dan na een incident de deksel lelijk op de neus krijgen. Daarbij kunnen we dan weer onderscheid maken in organisaties die helemaal niet stil staan bij dat testen (ze weten het gewoon niet) of die organisaties die weten dat ze moeten testen maar daarvoor niet goed zijn ingericht.

Er wordt nog wel eens te makkelijk gedacht over de “disaster recovery”. Het proces staat op papier, de plannen staan in de kast en klaar zijn we. Helaas wijkt de test omgeving totaal af van de productie omgeving en echt testen kunnen we dus niet. Jammer, want er wordt veel geld aan uit gegeven zonder dat we enige zekerheid hebben.

Het is nu maar te hopen dat de gegevens van de 800.000 mensen ook echt verloren is geraakt en niet in verkeerde handen is gekomen. Op de tapes stonden immers namen, adresgegevens, social security nummers, rijbewijs- of identificatienummers, zorgverzekering en informatie van de werkgever. Gegevens waarmee identiteitsdiefstal een peulenschil wordt.