I dag er alle virksomheter mer eller mindre på nett, og er dermed utsatt for et bredt trusselbilde og mange generelle angrep mot sine systemer. Vi er vant til en mengde feilsituasjoner på IT-systemene våre, og at ansatte bruker systemene forskjellig. I dette bildet kan det være vanskelig å skille eventuelle “farlige” angrep fra de mer eller mindre dagligdagse angrep og feilsituasjoner.
ISO-standarden for hendelseshåndtering, ISO/IEC 27035, deler hendelseshåndteringen inn i fem ulike faser hvorav den ene fasen dekker deteksjon og rapportering av en hendelse. Viktige aktiviteter som listes opp for denne fasen er:
- Deteksjon av sårbarheter og hendelser
- Innsamling av informasjon om sårbarheter og hendelser som detekteres
- Rapportering av sårbarheter og hendelser
Standarden er klar på at alt dette kan skje enten manuelt eller automatisk. Det blir imidlertid brukt mest tekst til å beskrive ulike monitoreringssystemer man kan få varsler fra, og mindre på manuelle kilder som brukere og eksterne. Vi har gjennomgått flere studier (se liste under) som ser på deteksjon av uønskede IT-hendelser og hvordan dette blir gjort i praksis. I de studiene vi har sett på er det også helt klart mest fokus på de tekniske mekanismene. Det er imidlertid interessant å merke seg at manuelle varsler fremheves av flere som en svært viktig kilde – kanskje til og med den viktigste.
I en kanadisk intervjustudie [1] fant forskerne flere utfordringer knyttet til det å detektere hendelser. Spesielt så de at IT-folk og de som jobber med IT-sikkerhet var avhengig av taus/implisitt kunnskap for å oppdage sikkerhetsbrudd. Effektiv deteksjon var blant annet avhengig av kunnskap om hvordan systemene vanligvis brukes, en type kunnskap som sjelden var dokumentert. På grunn av stor kompleksitet i systemene og mangel på ressurser var man derfor ofte avhengig av manuelle varsler for å oppdage hendelser. Slike varsler kan komme fra ulike grupper, inkludert brukere og andre IT-profesjonelle.
I en finsk studie [2] studerte forskere et sett av hendelser i arkivet til CERT-FI (det finske nasjonale IT-hendelseshåndteringsteamet). I de hendelsene de studerte så det ut til at ingen av ofrene for hendelsene ville ha vært i stand til å oppdage hendelsen selv. Eksterne rapporter var helt nødvendige for å få informasjon om at det kunne ha skjedd en hendelse eller for å utfylle den begrensede kunnskapen offeret hadde slik at de kunne forstå omfanget av hva som var i gang. I hvert av tilfellene de studerte ble hendelsen oppdaget av noen som ikke hadde noen klar link til offeret. Det var behov for mellomledd i kommunikasjonen som kunne bringe informasjon nærmere de som hadde behov for den, og ofte ble ikke alle berørte parter inkludert i informasjonsdelingen. Basert på dette kommer de med uttalelsen at ofre for internettrusler er blant de siste som får vite om informasjonssikkerhetshendelser som berører dem.
Det å få tak i og håndtere varsler kan imidlertid være utfordrende for organisasjoner. Det kan være vanskelig å effektivt legge til rette for varsling, både eksternt og internt, særlig siden man ikke alltid kan forutse hvor slike varsler kan komme fra. Det å håndtere varslene som kommer kan også være krevende, siden det øker krav til kommunikasjon i hendelseshåndteringsprosessen. Det å involvere aktører som kan være viktige varslere kan også være utfordrende. I en studie for noen år tilbake i petroleumssektoren [3] fant vi at leverandører ofte var lite involvert i arbeidet med å oppdage og håndtere informasjonssikkerhetshendelser. Det å skape en kultur internt der varsling er ok er også viktig, men krevende. Et tysk CERT-team ansvarlig for et universitetsnettverk [4] har gjort seg den erfaringen at noen av deres lokale administratorer ikke rapporterer hendelser slik de burde – enten fordi de ikke vet at de skal rapportere eller fordi de forventer at en slik rapportering vil medføre konsekvenser for dem siden de er ansvarlige for systemet.
Basert på tilgjengelige studier kan man klart se at dagens situasjon gir utfordringer i å effektivt oppdage uønskede IT-hendelser. Noe av dette er knyttet til for dårlige verktøy [1][4]. Disse har ofte utfordringer når det gjelder falske-positive, har i mange tilfeller dårlig brukervennlighet, og mange team opplever at de må lage egne verktøy eller gjøre tilpasninger av verktøy for å få den verktøystøtten de har behov for innenfor de ressurser de har tilgjengelig. Dette krever dyp teknisk kompetanse, og god kunnskap om den organisasjonen, det nettverket og de systemer man jobber med. Men uansett hvor gode verktøy man måtte ha så er det begrenset hva man kan oppdage med lokale verktøy. Man kan bare logge det som skjer innenfor sitt eget kontrolldomene. Man får derfor uansett ikke med seg hendelser som finner sted hos andre, og som kan gi tidlige varsler om angrep som utnytter lignende systemer. Man kan også i begrenset grad oppdage og håndtere hendelser der informasjon stjålet i ett system blir spredt eller utnyttet i andre systemer. [2]
I dagens situasjon viser tilgjengelige studier at man langt på veg er avhengig av varsler fra interne og eksterne for å oppdage enkelte angrep. Slik vil det også være i fremtiden, i alle fall dersom man antar at angrep vil bli enda mer komplekse fremover. Det er derfor viktig å ikke kun fokusere på teknisk kompetanse for å detektere angrep. Viktige tiltak for å bli bedre på å motta varsler og varsle andre er:
- Bevisstgjøre ansatte, slik at de kan kjenne igjen informasjonssikkerhetsbrudd og vet at de skal varsle
- Bygge av en intern kultur hvor det er trygt å varsle og de ansatte føler at varsling verdsettes
- Ta opp deteksjon av hendelser med leverandører og andre samarbeidspartnere
- Kontaktinformasjon lett tilgjengelig
- Fokus også på kommunikasjonsegenskaper hos de som jobber med IT-hendelseshåndtering, og ikke bare på det tekniske
- Ha rutiner for hvordan håndtere varsler
- Delta i fora der man blir kjent med relevante personer i andre virksomheter og kan utveksle erfaringer
[1] R. Werlinger, K. Muldner, K. Hawkey, and K. Beznosov, “Preparation, detection, and analysis: the diagnostic work of IT security incident response,” Information Management & Computer Security, vol. 18, pp. 26 – 42, 2010.
[2] E. Koivunen, “Why Wasn’t I Notified”: Information Security Incident Reporting Demystified,” 15th Nordic Conference in Secure IT Systems (Nordsec 2010), 2010.
[3] M. G. Jaatun, E. Albrechtsen, M. B. Line, I. A. Tøndel, and O. H. Longva, “A framework for incident response management in the petroleum industry,” International Journal of Critical Infrastructure Protection, vol. 2, pp. 26-37, February 2009.
[4] S. Metzger, W. Hommel, and H. Reiser, “Integrated Security Incident Management – Concepts and Real-World Experiences,” 2011 Sixth International Conference on IT Security Incident Management and ICT Forensics, pp. 107-121, 2011.