Som du ser är vår webbplats inte anpassad för äldre webbläsare. Vi rekommenderar att du uppgraderar till en nyare webbläsare.
!!

Vi söker en verksamhetschef till CERT-SE, en viktig roll i arbetet med att utveckla Sveriges förmåga att förebygga och hantera it-incidenter. Sista ansökningsdag är den 14 april.

Publicerad

Steg 5 - Erfarenheter - Vad har vi lärt oss av incidenten?

Den här delprocessen behandlar hur man kan ta tillvara de lärdomar och erfarenheter som hanteringen av incidenter har gett.

Följande punkter behandlas:

Lärdomar och erfarenheter

Det sista steget i incidenthanteringsprocessen är att avsluta incidenten genom att samla in de lärdomar och erfarenheter som hanteringen av incidenten har gett. Det är också vanligt att man i det här skedet sammanställer en incidentrapport.

En metod som brukar fungera bra vid större incidenter är att samla in synpunkter och erfarenheter från de som deltagit i incidenthanteringen, sammanställa dessa och sedan presentera dem vid ett uppföljningsmöte där samtliga deltagare har möjlighet att diskutera rapporten. Rör det sig om mindre incidenter, med ett fåtal inblandade, kan synpunkter och erfarenheter samlas in direkt på uppföljningsmötet.

Vad kan CERT-SE bidra med?

  • Rådgivning

Uppföljningsmöte

Tips inför uppföljningsmötet.

  • Det är viktigt att inte utse någon syndabock. Se till att kommunicera ut detta till mötesdeltagarna. Syftet med uppföljningsmötet är att öka organisationens förmåga att bemöta nya incidenter.

Allmänna frågor som kan användas inför eller under uppföljningsmötet.

  • Vad var det som hände och när?

  • Hur klarade vi av att hantera incidenten?

  • Fungerade vår incidenthanteringsprocess? Vilka delar fungerade bäst och vilka delar kan förbättras?

  • Följdes våra eskaleringsrutiner? Fungerade rutinerna?

  • Hur fungerade kommunikationen mellan inblandade parter?

  • Hade vi tillgång till tillräcklig information för att analysera incidenten? Fanns det information vi hade behövt få tillgång till tidigare?

  • Vad kan vi göra annorlunda nästa gång en liknande incident inträffar?

  • Vad kan vi göra för att förhindra att en liknande incident inträffar i framtiden?

  • Bör vi rapportera incidenten till någon tredje part, t.ex. programvaruleverantör?

Incidentrapport

Om det inte finns rutiner och mallar inom organisationen för vad en incidentrapport ska innehålla kan följande fungera som en utgångspunkt.

  • Drabbad organisation/avdelning/enhet

  • Kontaktperson

  • När, hur och av vem upptäcktes incidenten?

  • När inträffade incidenten? (tidpunkt, datum, tidszon)

  • Vilka av organisationens system var utsatta och vad hade de för funktion?

  • Vilken typ av incident? (DoS, intrång, mask/virus/bot)?

  • Vilken attackvektor utnyttjades och hur?

  • Vilka har arbetat med att lösa incidenten och hur mycket?

  • Vad fick incidenten för konsekvenser?

  • Finns det en kostnadskalkyl för incidenten?

  • Är incidenten polisanmäld eller kommer den att polisanmälas?

  • Hur löstes incidenten?

  • Vilka åtgärder har vidtagits för att förhindra att en liknande incident inträffar igen

  • Vilka ytterligare åtgärder kan behöva vidtas

  • Vilka erfarenheter och lärdomar har incidenten gett oss?

Genomgång av rutiner och policy

Rutiner och policies

  • Behöver existerande rutiner ses över och förändras?
  • Kan incidenten leda till att organisationens informationssäkerhetspolicy behöver ses över?

Kontakter och samarbete

  • Fanns det etablerade kontakter med myndigheter och polis innan incidenten? Fungerade kontakterna som avsett?
  • Hur sköttes kontakter med media?

Långsiktiga systemförändringar

  • Medför incidenten att större systemförändringar bör genomföras?

Skalskyddsförändringar

  • Medför incidenten att förändringar bör göras i skalskyddet?

  • Brandväggar

  • IDS/IPS-system

  • ACL-listor i routrar

  • DMZ

Länkar

NIST SP 800-61