En organisation kan idag drabbas av en rad olika IT-säkerhetsincidenter – allt från riktade angrepp till helautomatiserade intrång eller enskilda anställda som stjäl information eller saboterar.

Många organisationer är helt oförberedda när en säkerhetsincident inträffar. Bristen på incidenthanteringsrutiner leder ofta till stressade beslut som kan orsaka omfattande konsekvenser vad gäller minimering av skada och möjligheten att utreda den faktiska incidenten.
– Vi upplever att antalet incidenter i Sverige ökar dramatiskt, och av erfarenhet vet vi att många organisationer är helt oförberedda när det väl händer. Bristen på incidenthanteringsrutiner innebär ofta att det initiala arbetet blir kaosartat, ostrukturerat och stressat, vilket i sin tur kan leda till att hela situationen förvärras, säger Hanna Eldmar, SOC-chef på Sentor.

För att minimera skadorna är det viktigt med tydliga rutiner och nedan finns en checklista på sju steg Hanna Eldmar tycker organisationer ska följa vid en säkerhetsincident.

1. Livskritiska och farliga system
Första rådet vid en incident är att utgå från att en angripare har fri tillgång till hela den drabbade miljön. Finns det komponenter eller system i miljön som kan orsaka personskador, hälsoproblem eller annan permanent förstörelse – till exempel ödeläggelse? Om ja, koppla bort dessa system omedelbart, eller säkerställ att systemen är obrukbara, exempelvis genom att fysiskt koppla ur elsladden.

2. Rör inte miljön i onödan
Varje gång den drabbade miljön förändras på något sätt riskerar man att värdefulla ledtrådar förstörs, men också att man röjer för angriparen att intrånget upptäckts. Ibland måste man dock genomföra ändringar på kort varsel, men det är viktigt att detta sker på ett strukturerat, medvetet och dokumenterat sätt. Även enklare saker såsom att logga in på ett system kan räcka för att röja viktiga spår, så undvik onödiga förändringar och aktiviteter.

3. Worst-case scenario
Reflektera över det värsta som kan hända med en angripare vid spakarna. Väg sedan dessa konsekvenser mot konsekvenserna av att vidta åtgärder för att säkerställa att “värsta fallet” inte kan inträffa – exempelvis genom att stänga ner all it.

Ofta finns det billiga, mindre, åtgärder som kan vidtas för att reducera risken för totalt haveri – exempelvis genom att säkra fysiska offline-kopior av alla säkerhetskopior, för att säkerställa att oavsett vad som händer så finns affärskritisk data kvar. Andra exempel på åtgärder som kan vara bra att vidta är att separera den interna miljön från internet för att förhindra att information fortsätter att läcka ut.

Det är viktigt att notera att alla ändringar riskerar att röja för angriparen att intrånget har upptäckts, men ifall informationen inte under några omständigheter får läcka så kan det vara värt konsekvenserna.

4. Säkra informationstillgångar
Ifall det finns ett behov av att utreda händelsen djupare bör man vidta åtgärder för att se till att så mycket värdefull information som möjligt bevaras. Ofta finns viktig information i till exempel minnet på en drabbad dator, men även i loggfiler som kanske skrivs över regelbundet. Klockan tickar, och ifall den informationen behövs i ett senare skede är det viktigt att den bevaras på ett korrekt sätt.

5. Etablera en loggbok
I ett tidigt skede av en incidenthantering är det ofta kaotiskt – folk vill vidta åtgärder, och

risken är att det snabbt blir svårt att avgöra vad som gjorts av en administratör och vad som gjorts av angriparen. Genom att etablera en loggbok så tidigt som möjligt där allt

incidentarbete antecknas får man möjligheten att i ett senare skede dra slutsatser om vad som gjorts, vid vilken tidpunkt och av vem. Efter nio dagar av tolvtimmars arbetsdagar är det ofta svårt att minnas vem som gjort vad och med vilket system.

6. Informationsflöden
Samtidigt som tekniska resurser arbetar på ovanstående steg så bör organisationens administrativa del mobiliseras för att utröna hur händelsen bör hanteras bäst juridiskt, medialt och internt. Exempel på frågor som bör besvaras är:

  • Hur hanterar vi informationsspridning internt? Ofta vill man hålla mängden
    informerade individer till ett minimum för att se till att händelsen inte läcker, eller att angriparen får reda på att det pågår ett incidentarbete.
  • Hur kommunicerar vi händelsen till den yttre världen? Ofta vill man avvakta med detta tills man har mer information om situationen, vilket kan dröja. Oavsett bör man ta fram en kommunikationsstrategi för hur man hanterar situationer som kan uppstå -angriparen kan till exempel välja att publicera intern data på Internet – då är det bra att ha ett färdigt, koncist, och informerat svar till media.
  • Har vi några skyldigheter att informera interna parter? Det kan finnas krav på att informera ledning, styrelse eller ansvarigt dataskyddsombud.
  • Har vi några skyldigheter att informera externa parter? Arbete med offentlig sektor omfattas ofta av någon sorts krav på att anmäla it-incidenter – antingen till samarbetspartner, till Myndigheten för Samhällsskydd och Beredskap (MSB), eller till andra myndigheter. Utöver detta medför GDPR vissa rapporteringsskyldigheter, och även andra avtal kan även innehålla liknande krav.

7. Ta ett djupt andetag, och slappna av
I nio fall av tio så har angriparen varit i nätverket under ett antal månader och har haft god tid på sig att göra vad man vill, utan att bli motarbetad. Det är inte ovanligt att organisationen drabbas av panik, och att it-avdelningen börjar arbeta långa övertidstimmar över flera månader för att försöka göra så mycket som möjligt på så kort tid som möjligt.

Långsiktigt är detta sällan optimalt, och man bör alltid ha i åtanke att även en mindre incident kan leda till ett incidenthanteringsprojekt som pågår i månader, eller till och med år. En it-avdelning som är utbränd efter två veckor tjänar ingen utom angriparen på.

Läs mer om hur ni vässar er incidenthantering