Een voorstel voor een praktische aanpak voor data breach preparedness

Ik schreef dit stuk ongeveer drie jaar geleden voor het Cqure kennisplatform. Oordeel zelf hoe actueel dit nog is. Het is voor veel organisaties eigenlijk niet meer de vraag ‘of’ maar meer ‘wanneer’ het gaat gebeuren: Hackers verschaffen zich toegang tot het bedrijfsnetwerk en de systemen. Het is daarom van belang om je op een dergelijk incident voor te bereiden.

Experian en het Ponemon Institute hebben onderzoek gedaan naar dergelijke ‘data breach preparedness’ plannen. Uit hun onderzoek getiteld “Is Your Company Ready for a Big Data Breach?” blijkt dat 39% van de 1000 respondenten aangaf dat hun organisatie geen formeel plan heeft opgesteld. 

Een plan voor compliancy of een écht goed plan?

In mijn rol als forensisch IT onderzoeker heb ik vele incidenten mogen onderzoeken. Wat mij opviel is dat wanneer er wél een plan was opgesteld, dit plan in de praktijk eigenlijk nooit gevolgd werd. Meestal herkende ik het plan, omdat het een 1 op 1 kopie was van een plan dat als voorbeeld plan op het internet te vinden is. Soms was zelfs de tekst ‘[insert company name here]’ nog aanwezig. Waarschijnlijk werd een dergelijk plan ooit ingevoerd bijvoorbeeld PCI-DSS, requirement 12.9 omdat dit vanwege compliancy redenen verplicht is. Maar na het downloaden heeft naar alle waarschijnlijkheid niemand het document ooit nog bekeken.
Bij de bedrijven waar wel een eigen plan is opgesteld, is het plan vaak door een groot advocatenkantoor geschreven. Inhoudelijk is het plan juist. Door de gedetailleerde beschrijving van een pagina of 20 of meer, is het plan vaak onpraktisch in gebruik.

Zelf doen of uitbesteden?

Het kan ook anders, bijvoorbeeld  met een meer praktische benadering van het voorbereiden op een dergelijk incident. De eerste vraag die je zou moeten stellen is, of de organisatie waarin je werkt, zelf in staat is om dergelijke complexe en uitdagende onderzoeken uit te voeren. De benodigde kennis veroudert immers snel en is duur om te onderhouden. Daarnaast is een incident per definitie geen core business en komt niet op regelmatige basis voor. Het onderzoeken van het incident ideaal om te outsourcen naar een specialist. Mocht je hiervan gebruik maken:

• Kies dan voordat een incident plaatsvindt een goede leverancier uit.
• Stem de verkoop- en inkoopvoorwaarden af en sluit eventueel een SLA af.
• Nodig de leverancier vervolgens uit, licht toe hoe de eigen IT infrastructuur opgebouwd is.
• Stel de eigen medewerkers voor.

Deze toelichting hoef je dan niet meer te geven als er een incident plaatsvindt en tijd kostbaar is.

Organiseer een Mock Incident Testing workshop

De volgende stap is het organiseren van een of meerdere ‘mock incident testing’ workshops. Oefening baart kunst en alleen met het oefenen van incident afhandeling kom je er achter wat wellicht voor verbetering vatbaar is. Bijvoorbeeld log bestanden die niet gedetailleerd genoeg zijn, of iets eenvoudigs als telefoonnummers die nog niet uitgewisseld zijn.

Mock incident testing is droog oefenen. Het is niet noodzakelijk om daadwerkelijk systemen te hacken en te kijken hoe de organisatie reageert. Beter kan bijvoorbeeld het Verizon Data Breach Investigations Report gebruikt worden ter inspiratie. Dit rapport bevat feiten over onderzochte hack incidenten en statistieken over de gehanteerde modus operandi. Tijdens de workshop kunnen de volgende vragen gesteld worden bij elk type hack: ‘Zou dit ook bij ons kunnen gebeuren?’, ‘Zo ja, hoe zouden wij dit merken?’, ‘Wat zouden we moeten doen als we dit bemerken?’ Uiteraard is het goede advies om na afloop van een deze workshop wel de eigen systemen en logbestanden te bekijken of een degelijke hack niet al heeft plaatsgevonden.

Deelnemers aan de workshop zijn alle medewerkers die met een onderzoek naar een hack te maken krijgen. Dat zijn naast de afdeling IT, ook bijvoorbeeld de afdelingen PR & Communicatie, Juridische Zaken, en indien klanten bellen met vragen, Customer Service. Een groot voordeel van de workshop is dat de medewerkers elkaar in ieder geval gezien hebben, elkaars rol beseffen en er daardoor wellicht wat minder vrees bestaat om elkaar op de hoogte te houden.

Maak een Red Binder en schrijf je custom policy

Na de workshop kan een ‘Red Binder’ samengesteld worden. Een map met hierin alle mogelijke informatie die kan helpen bij het onderzoeken van een hack. Denk hierbij bijvoorbeeld aan een telefoonlijst, netwerk tekeningen, systeem beschrijvingen, voorbeeld persberichten en een communicatie plan. Deze map moet voor alle betrokken medewerkers beschikbaar zijn.

De laatste stap is het schrijven van een data breach preparedness policy. Deze policy kan heel praktisch beperkt blijven tot het bepalen dat bijvoorbeeld de Chief Security Officer verantwoordelijk is voor het organiseren van minimaal 2 mock incident testing workshops per jaar, en dat de uitkomsten en evaluatie van de workshops gedeeld  worden met de CIO, CFO en CEO. Daarnaast kan de Chief Security Officer verantwoordelijk gesteld worden voor het up to date (laten) houden van de Red Binder, bijvoorbeeld minimaal 1 maal per kwartaal, en voor het bepalen van de onderwerpen die in de Red Binder moeten voorkomen.

Door deze stappen te hanteren kan een organisatie zich op praktische wijze goed voorbereiden op een hack incident, zonder dat een policy geschreven wordt die uiteindelijk niemand hanteert.

Door: Matthijs van der Wel, Director Forensic Technology Solutions bij PwC Nederland in samenwerking met cqure.nl kennisplatform