Computer Forensics.DK Sidste opdatering: 22.maj 2007
hjem | computer forensics | incident response | electronic discovery | programmer | knowledge base | links | rootkits | mig | sitemap | kontakt

                             Incident response, incident handling og incident management


               "En af de vigtigste sikkerhedsfaktorer er forebyggelse"
                                                       Politiinspektør Kai Vittrup

I nogle tilfælde er der ingen tvivl om et system er blevet angrebet, men hvordan finder man ud af, om en mistænkelig hændelse skyldes et angreb eller 'bare' et teknisk problem på systemet? Og hvad gør man når et sikkerhedsproblem bliver opdaget? Incident response kan give en plan for hvad der skal gøres før, under og efter et angreb.

Vær beredt
Man sammenligner nogen gange incident response, planlægning og forberedelser med brandplanlægning, og incident response med brandslukning. Man installere ikke en brandalarm fordi man forventer der vil opstå brande, men fordi man ønsker at være i stand til at reagere hurtigt, begrænse skaden og hurtigt komme tilbage til normale omstændigheder hvis der skulle opstå brænd. Incident planning og response har fuldstændig samme formål for computer systemer.

Af hensyn til planlægningen kan man vælge at opdele incident response i tre trin: 1) incident planning - planlægning og forberedelse, allerede inden en hændelse finder sted. 2) incident response, der er opstået mistanke om "noget er galt" og den efterfølgende udrykning. 3) incident handling - løsning så problemet ikke spreder sig yderligere (containment). Incident handling omfatter også at finde ud af hvad der er sket, så hændelsen ikke gentager sig.

1) Planlægning: Planlægning af hvordan man ønsker at reagere på en sikkerhedsrelateret hændelse kan være nyttig på mange niveauer. Selve planlægningen kan ofte afdække potentielle problemer, der således kan forebygges inden de opstår. Med en klar incident plan vil virksomheden/organisationen spare tid, fordi det allerede ér identificeret hvem der kan tage stilling til vigtige spørgsmål (f.eks. hvem skal kontaktes og hvem skal rykke ud. Hvem har ansvar for hvilke områder, og hvem skal indblandes i sagen på hvilke tidspunkter). Endelig giver planlægning mulighed for at indsamle information, udstyr og programmer på forhånd.
Informationen og erfaringerne der indsamles under planlægningsfasen kan i mange tilfælde bruges til yderligere at sikre systemerne og yderligere hjælpe med at forebygge sikkerhedsbrister opstår.

2) Udrykning: hvordan opdages - og anmeldes - et potentielt problem til rette vedkommende i organisationen, så problemet kan løses hurtigt og effektivt før det spredes til andre dele af netværket og inden potentielt bevismateriale ødelægges.
I store organisationer kan risiko vurdering bruges til at identificere og vurdere risici indenfor IT-sikkerhed. Incident response sørger derefter for, at udgifterne ikke bliver for høje, når en sikkerhedsrelateret hændelse alligevel finder sted. Da hovedparten af planlægningen allerede ér foretaget under trin 1, bør udstyr og programmer være klar og udrykningsholdet kan hurtigt komme til stedet hvor der er brug for assistance.

3) Undersøgelse og løsning af problem: Det er nu forhåbentligt muligt for udrykningsholdet at ankomme velforberedt, inden problemet har spredt sig. Efterfølgende kan undersøgelsen foretages for at finde ud af om noget er galt, uden samtidigt at ødelægge muligheden for en evt. senere fuld forensics undersøgelse.    

Derudover er det vigtigt at etablere en process til at gennemgå hændelser internt efter de er afsluttet for at sikre man høster erfaringer, både gode og dårlige. Det sikre forhåbenligvis, at man kan reagere mere effektivt og ikke gentager de same fejl ved efterfølgede hændelser.

Hvad kan man selv gøre?
Hvis der er mistanke om sikkerheden på et system kan være kompromitteret, kan typiske indledende undersøgelser f.eks. være:

1) Gennemgang af logfiler
2) Check af åbne porte og aktive filer på systemet vha. programmer som OpenPorts, fport, netstat eller lsof.
3) Overvågning af maskinens netværksaktivitet, samt undersøgelser af generel netværksaktivitet
4) Søgninger efter skjulte filer, biblioteker og mistænkelige brugere
5) Fulde scanninger med opdateret antivirus software og Spyware scannere
6) Osv, osv.

Husk stadig på, at undersøgelserne i større eller mindre grad altid vil ødelægge potentielt bevismateriale. Det er derfor vigtigt at overgive undersøgelsen til trænet personel så hurtigt som muligt, hvis man ikke selv er trænet i incident response eller computer forensics.

Se et eksempel på en grundlæggende undersøgelse af et Windows system med en række forskellige gratis programmer.
Tom Engly Henriksen, tidligere Rigspolitiets Kriminaltekniske Afdeling IT-sektionen, har skrevet en god guide til hvordan efterforskningsmulighederne ved datakriminalitet optimeres. Guiden er skrevet igennem Dansk-IT og er også nyttig for IT-chefer og andre med ledelsesansvar for IT-sikkerhed.
Cert har en udmærket liste over ting man selv kan starte med at undersøge hvis man har mistanke om et Windows system har været udsat for en sikkerhedshændelse. Den samme type information lister Cert her for Unix systemer. Sans har en checkliste med en række ting en administrator kan checke ved mistanke om sikkerhedsproblemer på et Windows system og et Linux system. First har en god liste over kommandoer og programmer der kan bruges ved en online undersøgelse af et Windows system.

Pas på
Det er vigtigt at være klar over, at man ikke umiddelbart kan stole på output fra programmer der er installeret på maskinen der undersøges. Det er ikke ualmindeligt for angribere at benytte rootkits (specialiserede programmer hackere bruger til at skjule sine spor efter at have opnået adgang til et system), også på Windows systemer. Derfor bør programmerne der skal benyttes til den indledende undersøgelse altid først downloades til et sikkert system og derefter gemmes på en skrivebeskyttet diskette, brændes til CD eller eksekveres over netværket fra en anden maskine. Man bør aldrig eksekvere programmerne direkte fra den mistænkte computers harddisk. Risikoen for rootkits er uddybet på siden om rootkits. Læg også mærke til, at i eksemplet på en grundlæggende undersøgelse af et Windows system eksekveres alle programmer fra A:\ drevet (skrivebeskyttet diskette).

Standarder
Incident response - effektiv håndtering af sikkerhedsrelaterede hændelser - er en del af almen IT-sikkerhed og er naturligvis også en del af både ISO 17799:2005, den internationale standard for IT-sikkerhed og DS484:2005, den danske standard for IT-sikkerhed. I begge 2005 versioner er håndtering af sikkerhedsbrud koncentreret i kapitel 13.
ISO TR 18044 "Information Security Incident Management" fokuserer på håndtering af sikkerhedsrelaterede hændelser.

Meget mere information om bl.a. incident response politikker og incident teams er planlagt.

 
Copyright © 2004-2008 Computerforensics.DK