Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Incident response broodnodig

Gestructureerd omgaan met beveiligingsincidenten (deel 2)

 

In het eerste deel van dit artikel (vorige week in Computable) is toegelicht dat we verwachten dat de impact van ict-incidenten zal toenemen, ondanks alle voorzorgsmaatregelen. Aan de hand van een case (een mix van fictie en praktijk), belichten we in dit deel het nut van een Incident Response Team (IRT) en een incident response plan voor het oplossen van beveiligingsincidenten.

Vooral internetsystemen die geldstromen regelen mogen zich verheugen op een toenemende criminele belangstelling. Ook zien we steeds vaker dat ontevreden burgers overheidssystemen digitaal aanvallen. Zeker bij organisaties die sterk afhankelijk zijn van hun informatievoorziening, is een verdediging in de diepte nodig met meer aandacht voor het verhelpen van beveiligingsincidenten. In de figuur ‘Dreigingen versus maatregelen’ wordt de noodzaak en context van correctieve en repressieve maatregelen aangegeven.

Aanpak van het incident

Nadat een incident zich manifesteert, zoals in de case in het kader op pagina 25, wordt de aanloop naar de oplossing ervan vooral gekenmerkt door een lichte chaos. Een incident response plan vermindert de chaos als het de samenwerking (wie, wat, waar, wanneer, hoe en waarom) op de volgende punten regelt.

1. Om een incident zoals een virusuitbraak adequaat te kunnen aanpakken, dient het incident response plan aan te geven wanneer de helpdesk een beveiligingsincident moet escaleren naar het IRT. Meestal zal de helpdesk deze keuze maken op grond van het aantal openstaande meldingen, die gelijktijdig, soortgelijk of op dezelfde locatie gemeld zijn en waar de reguliere beheerprocessen niet tot een snelle oplossing leiden. De helpdesk moet hiervoor beschikken over de actuele bereikbaarheidsgegevens van de in- en externe IRT-leden, zowel binnen als buiten kantooruren.

2. De communicatie en samenwerking met de verschillende actoren moet voorbereid zijn. Denk bij communicatie aan de verschillende doelgroepen, zoals (gefrustreerde!) medewerkers, de ict-afdeling, management, externe deskundigen, leveranciers, ketenpartners en klanten, overheid en de pers.

3. Opstellen van het incidentdossier door het IRT. Het kunnen beheersen van een incident vergt minimaal een logboek met het resultaat van de uitgevoerde acties en de beschrijving van de verschijnselen in tijd en plaats. Uit de symptomen van de getroffen systeemdelen kan de (vermoedelijke) kwetsbaarheid worden afgeleid die de oorzaak van het incident vormde. De benodigde informatie kan uit de logs van beheersoftware en ingevulde checklijsten worden gehaald. Het kortetermijndoel van het incidentdossier is het vaststellen van de diagnose of een werkhypothese, zodat de gevolgen van het incident met (tijdelijke) maatregelen snel en gericht kunnen worden beperkt.

4. Het isoleren en markeren van getroffen systemen om verergeren van het probleem te voorkomen. Het moet vooraf duidelijk zijn wanneer de IRT-manager een beslissing moet escaleren naar het lijnmanagement om bepaalde ict-diensten buiten gebruik te mogen stellen. Tevens verifieert het IRT dat de isolatie effectief is, door vast te stellen dat de rest van de infrastructuur en de back-ups niet besmet zijn.

5. Het opsporen van de oorzaak van het incident om de gevolgen hiervan te elimineren is een lastig karwei, dat vaak onder hoge druk moet worden uitgevoerd. Tijdwinst is mogelijk door vooraf te inventariseren welke deskundigen hierbij een rol kunnen spelen en hun inschakeling voor te bereiden. Het opsporen van de oorzaak van een incident vergt een detailanalyse van de gecompromitteerde systemen of een onderzoek waarbij het profiel van het opgetreden incident vergeleken wordt met al bekende profielen. Als er een patch beschikbaar is, moet die bijvoorbeeld eerst worden geïnstalleerd om herbesmetting van geschoonde systemen te voorkomen.

6. Verifieer zorgvuldig de ontsmetting – een onzorgvuldige ontsmetting met een blended threat virus leidt tot een nieuwe uitbraak, waardoor men opnieuw kan beginnen. Daarna volgt herstel van de uitgevallen systemen met software en bedrijfsgegevens uit een gecontroleerde back-up; de inzet van eventueel aanwezige redundante apparatuur kan het herstel van de dienstverlening versnellen.

7. Als de normale situatie is hersteld, kan het management besluiten het IRT te demobiliseren. Standaard moeten de betrokkenen na het afsluiten van het incident verantwoording afleggen en de uitgevoerde acties evalueren. De reguliere beheerprocessen zijn dan op de hoogte van alle veranderingen die het IRT heeft uitgevoerd. Eventueel kan de organisatie aangifte doen, maar dan moet uit de loggings wel een bruikbaar bewijs gehaald kunnen worden. De bewijsketen moet dan bijvoorbeeld gegarandeerd zijn en het bewijsmateriaal moet dubbel gecontroleerd kunnen worden. Om er zorgvuldig mee om te kunnen gaan moet het bewijs worden gemarkeerd en tegen verlies in twee sets worden vervoerd en bewaard.

8. Door na het incident een rapportage van de lessons learned op te stellen – inclusief een inschatting van de kwantitatieve en kwalitatieve gevolgen van het incident, kan de organisatie de waakzaamheid van het personeel verbeteren, trends signaleren en verbeteringen doorvoeren om risico’s structureel te verminderen. De effectiviteit en efficiency van processen, middelen en maatregelen kan ermee worden verhoogd, ook die van het IRT zelf.



Wees voorbereid

Een incident response plan moet altijd op maat worden gesneden, omdat elke organisatie anders is qua bedrijfsprocessen, omgeving en ict-systemen. Waar precies welke bedrijfsgeheimen aanwezig zijn of privacygevoelige gegevens worden verwerkt, verschilt ook per organisatie. Het is zinvol om het management van de organisatie vooraf een prioriteitsvolgorde voor herstel te laten vaststellen, voor het geval dat meerdere systemen tegelijk uitvallen. Deze prioriteit hangt onder andere af van wetgeving, contractuele verplichtingen, het aantal getroffen gebruikers, het belang van de ondersteunde bedrijfsprocessen, het bedrijfsrisico bij uitval etcetera.

Leg alleen essentiële werkzaamheden in plannen vast. Elk incident is anders en te gedetailleerde draaiboeken beperken de creativiteit van het team tijdens de inzet.

Onder de voortdurende druk van budgetbeperkingen en reorganisaties die de ict-afdelingen tegenwoordig ervaren, zijn de ontwikkelingen op het vlak van ict-beveiliging nauwelijks bij te houden. Daarom zullen het in- en extern beschikbare kennisniveau en de efficiency en effectiviteit (inclusief bijwerkingen!) van de beveiligingsmaatregelen regelmatig in de praktijk getoetst moeten worden. Vooraf niet de moeite nemen om herstelplannen goed te testen, bijvoorbeeld met een simulatieoefening, laat ruimte voor verrassingen tijdens grimmige omstandigheden.

Met het voorbereiden van de inzet van een IRT is een organisatie er nog niet. De waakzaamheid en de betrokkenheid van de werkvloer is tijdens een incident van groot belang. Zorg voor vertrouwen en medewerking door het IRT te adverteren als oplosser van problemen, niet als rapporteur van persoonlijke tekortkomingen.

Het inrichten van en voorbereiden van een incident response plan is als het plannen van een project waarvan het doel bekend is, te weten het herstel van de uitgevallen voorzieningen, alleen de startdatum niet. Dát het IRT een keer nodig zal zijn, is volgens Murphy echter zeker…n


Henk-Jan van der Molen, adviseur informatiebeveiliging bij de Inspectie Verkeer en Waterstaat

Douwe Leguit, Erik de Jong en Christ Reniers, adviseurs bij GOVCERT.NL

Case overheid

In een overheidsorganisatie werd de helpdesk op een morgen gebeld door ongeduldige gebruikers die bepaalde bestanden niet meer konden vinden. In eerste instantie betrof het enkele meldingen, maar al snel groeide het aantal medewerkers met dezelfde klacht. Ondanks verwoede pogingen lukte het de helpdesk niet om deze bestanden terug te vinden, laat staan een oorzaak van de verdwijning te vinden.

Omdat de reguliere maatregelen niet werkten, werd de chaos en tijdsdruk steeds groter. De virusscanner die de organisatie gebruikte had geen alarm geslagen. Bij de helpdesk ontstond het vermoeden dat het incident een nieuwe trojan betrof die gebruik maakt van een zojuist bekend geworden kwetsbaarheid in de gebruikte programmatuur. Eén beheerder legde een verband met het ontslag van een ontevreden beheerder eerder die week.

Na wat wikken en wegen stelde de manager van de helpdesk een ad hoc IRT samen. Een voorlopige diagnose gaf aan dat de schade beperkt was tot een van de compartimenten in het netwerk. In overleg met het lijnmanagement isoleerde het IRT het geïnfecteerde compartiment van de rest van het netwerk om verdere verspreiding van het virus te voorkomen. De standaardmaatregelen om malware op te ruimen bleken echter onvoldoende, het virus verspreidde zich op andere manieren opnieuw in het geïsoleerde segment.

Omdat de trojan nog onbekend was, nam het IRT contact op met externe deskundigen om na te gaan hoe ze het incident konden oplossen. Uit navraag door GOVCERT.NL bij diverse antivirusleveranciers, bleek dat deze trojan inderdaad nieuw was en de systemen op verschillende manieren geïnfecteerd konden raken. Nadat de antivirusleveranciers hun virusdefinities hadden aangevuld met deze trojan, kon het IRT alle systemen schonen.

Uit deze case zien we dat de betrokkenen onder grote (tijds)druk een incident moeten oplossen. Dat kan alleen als vooraf een incident response plan is opgesteld dat in grote lijnen de incidentafhandeling ondersteunt en het IRT goed voorbereid is.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/1681909). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Deel 1 van dit artikel is te vinden op http://www.computable.nl/artikel/ict_topics/security/1681630/1276896/incident-management-broodnodig.html

Vacatures

Stuur door

Stuur dit artikel door

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

×
×