|
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.
|