Whitepaper - Incident Response

of 14 /14
Whitepaper Toegepaste Incident Response

Embed Size (px)

description

Met informatiebeveiliging spannen wij ons in om incidenten te voorkomen. Dat lukt om verschillende redenen echter niet altijd. Bij voorkeur is dat het gevolg van een doelbewuste keuze om een bekend risico te accepteren, maar het kan net zo goed het gevolg zijn van een risico dat überhaupt nog onbekend was. De verzameling aan processen en procedures om controle te houden over de gaten die bewust of onbewust in de preventie worden gelaten, wordt samengevat onder de titel “Incident Response”. Daarbij draait het om het adequaat reageren op ontluikende incidenten. Dit deel van informatiebeveiliging is absoluut onmisbaar om de gevolgen van incidenten tot een acceptabel minimum te beperken. Dreigingen in het digitale domein zijn statistisch gezien razendsnel. Naast het inrichten van response processen is daarom ook de efficiënte uitvoering ervan van belang. Deze whitepaper behandelt de onderdelen van incident response en de praktische toepassing ervan.

Transcript of Whitepaper - Incident Response

  • 1. Whitepaper Toegepaste Incident Response
  • 2. Inhoud Onmisbaar onderdeel van 100% beveiliging 03 Incidenten 04 Het probleem 05 De oplossing 06 Voordelen 11 Belangrijke overwegingen 12 Wat nu? 13 02Whitepaper Toegepaste incident response
  • 3. Onmisbaar onderdeel van 100% beveiliging Met informatiebeveiliging spannen wij ons in om incidenten te voorkomen. Dat lukt om verschillende redenen echter niet altijd. Bij voorkeur is dat het gevolg van een doelbewuste keuze om een bekend risico te accepteren, maar het kan net zo goed het gevolg zijn van een risico dat berhaupt nog onbekend was. De verzameling aan processen en procedures om controle te houden over de gaten die bewust of onbewust in de preventie worden gelaten, wordt samengevat onder de titel Incident Response. Daarbij draait het om het adequaat reageren op ontluikende incidenten. Dit deel van informatiebeveiliging is absoluut onmisbaar om de gevolgen van incidenten tot een acceptabel minimum te beperken. Dreigingen in het digitale domein zijn statistisch gezien razendsnel. Naast het inrichten van response processen is daarom ook de efficinte uitvoering ervan van belang. Deze whitepaper behandelt de onderdelen van incident response en de praktische toepassing ervan. 03Whitepaper Toegepaste incident response
  • 4. Incidenten Een computer incident is een gebeurtenis (event) die zijn oorsprong vindt in een menselijke oorzaak. Een event is een waarneembare verandering van het gedrag van een systeem, omgeving, proces, workflow of persoon1. Door Verizon is in het kader van het Data Breach Investigation Report (DBIR) 20132 onderzoek gedaan naar de tijdlijn van computer incidenten. Daaruit blijkt dat organisaties doorgaans laat reageren op datalekken, lang nadat het kwaad geschied is. In 84% van datalekken slaagt de aanvaller erin binnen uren toegang te krijgen tot een informatiesysteem In 69% van de gevallen duurt het na de intile toegang nog eens uren voordat gevoelige informatie wordt gelekt In 66% van alle lekken wordt pas maanden na de initile toegang de aanval herkend. Maanden dus ook nadat de gevoelige data waarschijnlijk al gelekt is. Het aantal incidenten dat pas na maanden wordt ontdekt, neemt de laatste jaren toe. Na het herkennen van een lek, duurt het vervolgens in de meerderheid van de gevallen nog dagen tot maanden voordat het onder controle is; voordat het bloeden gestopt is. Het gevolg van late herkenning van lekken is dat de informatie in kwestie in de tussentijd vrijelijk kan worden gebruikt. De consequenties daarvan zullen per geval verschillen, maar zullen hoogstwaarschijnlijk onder aan de streep tot steeds meer schade leiden. 1 Wikipedia: http://en.wikipedia.org/wiki/ Computer_security_incident_management#Components_of_an_incident 2 Verizon DBIR 2013, p.50: http://www.verizonenterprise.com/DBIR/2013/ 04Whitepaper Toegepaste incident response
  • 5. Het probleem Incident Response is tot op heden vaak een onderbelicht onderdeel van informatiebeveiliging. Vaak is die beveiliging puur gericht op preventie. De nodige processen om tijdig incidenten te kunnen herkennen, worden niet geregeld. Het grootste gedeelte van computer incidenten, in 2012 nog 70%, wordt dan ook initieel niet herkend door het slachtoffer zelf, maar door een niet gerelateerde derde. Dit doet vermoeden dat interne detectiemiddelen onvoldoende zijn3. Hoog tijd dus om te beschrijven waaraan die interne detectiemiddelen moeten voldoen. En hoe die vervolgens gebruikt kunnen worden om de reactietijd na incidenten te minimaliseren. 3 Verizon DBIR 2013, p.53: http://www.verizonenterprise.com/DBIR/2013/ 05Whitepaper Toegepaste incident response
  • 6. De oplossing Het SANS instituut is een bekende en veel geraadpleegde Amerikaanse organisatie die zich richt op het trainen van security professionals in het beschermen van systemen en netwerken tegen digitale dreigingen. Zij hebben onder andere een stappenplan ontwikkeld voor incident response, ofwel incident handling. De 6 stappen volgens het Incident Handlers Handbook 4: 1) Preparation; voorbereiding 2) Identification; herkenning 3) Containment; insluiting 4) Eradication; verwijdering 5) Recovery; herstel 6) Lessons Learned; geleerde lessen Fase 1 en 6 worden goed beschreven door SANS en het verdient dan ook de aanbeveling om het Incident Handlers Handbook op die punten zonder meer te hanteren. In de voorbereiding moeten glasheldere afspraken op papier komen te staan als een incident response- en communicatieplan. Zonder die plannen ontstaat bij een incident hoogstwaarschijnlijk blinde paniek en grote chaos waarin noodzakelijke sporen vernietigd worden en tijdverspillende discussies worden gevoerd. En in de laatste fase wordt expliciet teruggekeken naar de behandeling van dit incident om daar waardevolle lessen uit te trekken voor toekomstige incidenten. Het zijn beide niet te missen stappen, ten einde het incident response proces efficint en kwalitatief te laten verlopen. In de tussenliggende stappen beschrijft SANS net zo goed waarmee moet worden rekening gehouden, maar daar ontbreken concrete voorbeelden voor de toepassing in de praktijk. Stap 2: Herkenning In de identification fase is het van belang om de manier waarop aanvallers te werk gaan, goed te begrijpen. Een aanval verloopt doorgaans in de volgende stappen: 1)Verkenning: het zoeken naar manieren om toegang te krijgen tot een informatiesysteem 2) Inbraak: de inbraak zelf 3)Controle: het instellen van mogelijkheden om het informatiesysteem onder controle van de aanvaller te brengen 4)Uitvoeren: het uitvoeren van het doel waarmee op het informatiesysteem is ingebroken, doorgaans het lekken van gevoelige informatie In al deze fasen zijn signalen waarneembaar die duiden op het incident. Hoe eerder deze in het proces kunnen worden herkend, des te groter de kans dat het daadwerkelijk lekken van informatie kan worden voorkomen. IDS & IPS Zoals gesteld moet het herkennen van signalen zo efficint mogelijk verlopen. Daarin speelt automatisering een belangrijke rol. Om die reden zijn dan ook Intrusion Detection Systemen (IDS) op de markt gebracht. Deze IDS technologie is voorzien van 4 SANS Institute Incident Handlers Handbook: http://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901 06Whitepaper Toegepaste incident response
  • 7. lange lijsten van patronen waarmee inbraken kunnen worden herkend. De meeste IDS oplossingen zijn tegenwoordig bovendien in staat om dezelfde patronen te gebruiken om ongewenst verkeer ook direct te blokkeren, in dat geval wordt gesproken van Intrusion Prevention Systemen (IPS). In de praktijk wordt een IPS echter vaak deels of geheel in detectie modus geplaatst omdat het tot false-positives, onterechte blokkades, kan leiden en daarmee vitaal netwerkverkeer kan blokkeren. Dat betekent dat ook de signalen in een IPS in elk geval voor een deel nog opvolging behoeven, het verkeer is tenslotte niet geblokkeerd. IDS of IPS wordt bij veel organisaties toegepast in de internet verbinding: de perimeter. Ten einde netwerkbrede incident detectie te kunnen bereiken, is het van wezenlijk belang om dit soort herkenning op meerdere plaatsen in het netwerk in te zetten. Het ontwerpen van een IDS of IPS opstelling die de nodige plaatsen in het netwerk kan overzien is zeer kritisch voor het slagen ervan en kan daarom het best worden uitgevoerd door een ervaren specialist. NBA Network Behavior Analyses (NBA) kijkt op een andere manier naar netwerkverkeer dan een IDS. Het is niet genteresseerd in individuele netwerkpakketten, maar in hoeverre die pakketten afwijken van het netwerkverkeer dat gebruikelijk is. Een NBA oplossing bereikt dan ook pas, na een tijdje het netwerkverkeer geanalyseerd te hebben, zijn doel. Het leert de normale patronen en zal een signaal afgeven simpelweg wanneer netwerkverkeer gezien wordt dat buiten die normale patronen valt. SIEM Naast IDS en IPS bestaat een computernetwerk uit tal van componenten die elk zinvolle signalen kunnen bevatten ten behoeve van detectie. Switches, routers, firewalls, (database) servers, enzovoorts. Elk van deze apparaten bevat log informatie die van wezenlijk belang is voor incident response. Het analyseren van al deze log informatie is tijdrovend, bovendien complex om tot conclusies te komen in het kader van incident response. Om die reden is Security Incident and Event Management (SIEM) technologie ontwikkeld. Dit komt de efficintie van detectie ten goede, door log informatie vanuit relevante bronnen in het netwerk op n plek te verzamelen en te correleren. Door aan een SIEM oplossing de nodige intelligentie toe te voegen, kan in die correlatie verdacht gedrag worden herkend. En deze constatering kan vervolgens gebruikt worden om een afgesproken workflow te starten. 07Whitepaper Toegepaste incident response
  • 8. SIEM wordt vaak ten behoeve van compliance ingezet, omdat het de verzameling en opslag van log informatie aantoonbaar regelt. Maar het is dus tegelijk een zeer waardevol onderdeel voor incident response. Stap 3: Insluiting In de containment fase is het de bedoeling om de schade als gevolg van het incident te beperken en om verdere schade te voorkomen. Allereerst betekent dit doorgaans dat een systeem of netwerksegment waarop het incident is geconstateerd, wordt gesoleerd. Dus het verbreken van verbindingen vanuit de rest van het netwerk en daarnaartoe. Dit worden wel de korte termijn maatregelen genoemd, en kan vergeleken worden met een in quarantaine plaatsing bij infecties. Belangrijk om op voorhand in te zien, is wat de consequenties per systeem of netwerksegment zijn als deze maatregelen genomen zouden moeten worden. En om failover mogelijkheden in te richten daar waar systemen en netwerken een vitale functie voor de organisatie vervullen. Dit soort beslissingen zouden in de voorbereidingsfase aan de orde moeten komen. Na de isolering is het een essentile stap om een forensisch image te maken van de systemen die getroffen zijn. In de praktijk, wanneer een incidente response plan ontbreekt, wordt dit vaak overgeslagen zodatin een later stadium de mogelijkheid ontnomen wordt om root cause analysis uit te voeren. En daardoor antwoorden op vragen van wie, waarom, wanneer en wat, onbeantwoord blijven. In de hectiek van een incident kan het beantwoorden van die vragen in eerste instantie irrelevant lijken, maar naderhand is de kans groot dat daar anders over wordt gedacht, bijvoorbeeld door hoger management. Tenslotte wordt in deze fase, indien nodig, al de nodige stappen gezet om getroffen systemen weer terug te laten keren in productie. Het verwijderen van backdoors, installeren van patches op deze systemen en hun omgeving, enzovoorts, zijn stappen die ervoor kunnen zorgen dat de verdere escalatie van het probleem kan worden gestopt en productie dus weer kan worden hersteld. Hier heeft een opschoonfunctie van een anti-malware product een belangrijke waarde, waarvoor gebruik gemaakt kan worden van de aanwezige software of juist van breed beschikbare tools, zoals USB sticks met speciaal voor dit doel ontwikkelde opschoonfunctionaliteit. In de volgende fase wordt pas echt aan de slag gegaan met de volledige schoning en het herstel van getroffen systemen. 08Whitepaper Toegepaste incident response
  • 9. Automatisering Het ligt voor de hand om juist de insluiting van een incident zo snel mogelijk te laten plaats vinden na detectie ervan. Daarom is juist hier de grootste tijdwinst te halen door stappen te automatiseren. Gericht zou kunnen worden op het geautomatiseerd in quarantaine plaatsen van een systeem dat verdacht gedrag vertoont. Een dergelijke maatregel zal met de nodige zekerheden moeten worden omgekleed om onnodige downtime van vitale onderdelen te voorkomen. Maar als die waarborgen zijn ingebouwd, kan het gevolg zijn dat seconden tot minuten na het (automatisch) herkennen van bijvoorbeeld de aanvalfase van een indringing, een systeem wordt afgesloten. Dus nog voordat de aanvaller in staat is om daadwerkelijk data te stelen. De negatieve effecten van downtime van een systeem kunnen dan verbleken bij de schade die voorkomen wordt. Om een dergelijke vorm van automatisering te bereiken, is een koppeling nodig tussen een systeem dat verdacht gedrag signaleert en een systeem dat een quarantaine modus kan afdwingen. Dus bijvoorbeeld op het niveau van een IDS of beter: dat van een SIEM. Quarantaine kan toegepast worden op netwerkniveau, door middel van een switchconfiguratie bijvoorbeeld via 802.1x of een firewall tussen segmenten in, of op systeemniveau door middel van een softwarematige firewall oplossing. De beheeromgevingen van het detectiemiddel enerzijds en de quarantainefunctie anderzijds moeten derhalve aan elkaar verbonden kunnen worden om dit niveau van automatisering te bereiken. Ten einde versnelling te bereiken in incident response verdient het dus de aanbeveling om beveiligingsoplossingen niet individueel te bezien, maar vooral ook na te denken over het geheel aan technologie en de integratie tussen de componenten. Stap 4: Verwijdering Een systeem dat getroffen is door malware, of anderszins is misbruikt, is per definitie onbetrouwbaar geworden. De breed gedragen mening van security experts is dat de enige optie om de integriteit van een dergelijk systeem werkelijk te herstellen, een herinstallatie ervan is. Anti-malware producten zullen tot een bepaalde hoogte in staat zijn om herstelacties uit te voeren, maar het is nooit met zekerheid te zeggen of alle data op een systeem daarmee goed hersteld is. En of alle heimelijk genstalleerde onderdelen die tot herinfectie kunnen leiden ook verwijderd zijn. 09Whitepaper Toegepaste incident response
  • 10. Soms is het herinstalleren van een systeem dermate complex dat toch getracht wordt om middels anti-malware technieken de verwijdering uit te voeren. Maar dit is dus een suboptimale werkwijze en het verdient de voorkeur om in de voorbereidingsfase ook rekening te houden met beschikbare, goed bijgehouden systeem images om deze stap goed en snel te kunnen uitvoeren. Met de opkomst van virtualisering is dit steeds makkelijker geworden, maar ook voor fysieke systemen zijn tal van imaging oplossingen beschikbaar. Stap 5: Herstel In de herstelfase wordt in kleine, goed controleerbare stappen de normale productie hersteld. Allereerst moet daarvoor met enige zekerheid kunnen worden vastgesteld dat de getroffen systemen schoon en volledig functioneel zijn. Zeker wanneer om welke reden dan ook het herinstalleren van een systeem niet mogelijk was en gekozen is voor een opschoonfunctie door middel van een anti-malware product. Bij het vervolgens terug aansluiten van systemen op het netwerk is het heel belangrijk om extra goed te letten op herinfectie van systemen of anderszins verdacht gedrag. Monitoring zal daarom in deze fase nog intensiever worden uitgevoerd dan in normale omstandigheden. En belangrijk om daarom ook vast te stellen is hoe lang die intensieve monitoring moet worden toegepast alvorens in gebruikelijke modus kan worden teruggevallen. 10Whitepaper Toegepaste incident response
  • 11. Voordelen Door incident response in te richten conform de SANS richtlijnen, en daarbij in te zetten op automatisering van stappen, wordt de reactietijd op incidenten tot het minimum beperkt. Zelfs zo ver dat daarmee voorkomen kan worden dat een inbraak leidt tot datalekken. Of dat anderszins in elk geval snel na een datalek kan worden vastgesteld dat dit heeft plaatsgevonden en dat bovendien de wie, wat, wanneer, waar, waarom en hoe vragen, die onherroepelijk worden gesteld, beantwoord kunnen worden. Het voorkomen van incidenten is nooit helemaal mogelijk. Een incident response proces is dan ook een kernonderdeel van informatiebeveiliging. Onmisbaar om de gewenste controle te hebben en houden over de omgeving. Anti-malware past niet in een doos 11Whitepaper Toegepaste incident response
  • 12. Belangrijke overwegingen Wacht niet tot het volgende incident om erachter te komen dat een incident response proces een absolute vereiste is. Zie incident response ook niet als een sluitstuk, maar een cruciaal onderdeel van het totale beleid ten aanzien van informatiebeveiliging. Zorg er dus voor dat de aanbevolen stappen ter voorbereiding getroffen zijn. Hiervoor kan de checklist gebruikt worden die aanwezig is in de Incident Handlers Guide van SANS. Automatisering is in principe geen noodzaak, maar verdient wel de aanbeveling. Sterker nog: door de security industrie wordt fors genvesteerd in die automatisering. Omdat men weet dat de compleet handmatige afhandeling van taken te lang duurt en dat die aanpak onhoudbaar is met de tegenwoordige dreigingen. Menselijke logica en interpretatie blijft natuurlijk onmisbaar in het incident response proces, maar wanneer simpele, terugkerende handelingen kunnen worden geautomatiseerd, dan pas is het proces opgewassen tegen de snelheid van dreigingen. Het realiseren van automatisering is vrijwel altijd mogelijk door maatwerk koppelingen te ontwikkelen. De meeste beheertechnologie is tenslotte voorzien van APIs waardoor via scripts verschillende tools aan elkaar verbonden kunnen worden. Nadeel van deze aanpak is wel dat kennis nodig is van die APIs en het ontwikkelen van scripts, en dat voor het doorlopend onderhoud en borging van de automatisering die kennis dan ook continu aanwezig moet zijn. Om die reden verdient het de aanbeveling om te zoeken naar integratiemogelijkheden tussen technologien die zonder maatwerk en scripts te realiseren zijn. 12Whitepaper Toegepaste incident response
  • 13. Wat nu? Ga nu aan de slag met de voorbereidingsfase van incident response. Schakel de hulp in van een professional op dit vlak indien nodig. De beschreven tools: SIEM, IPS, NBA vormen samen met Vulnerability Management de fundering van security technologie die DearBytes adviseert om tot real-time inzicht en controle te komen over de beveiliging van dierbare informatie. Om de aanbevolen automatisering mogelijk te maken, is een hoge mate van integratie tussen de componenten in deze cyberfundering een van de grote voordelen ervan. Zonder noodzakelijke scripts en programmeerkennis biedt dit de mogelijkheid om incident response zo efficint mogelijk te laten verlopen. Het resultaat: betere veiligheid en operationele winst. Neem contact op met ons voor meer informatie. 13Whitepaper Toegepaste incident response
  • 14. DearBytes B.V. Postbus 42 1940 AA Beverwijk T +31 (0)251 750 250 [email protected] www.dearbytes.nl