Skip to content

Krav på incidentrapportering enligt NIS2

Visste du att signifikanta incidenter mot nätverk och informationssystem ska rapporteras in centralt om din verksamhet träffas av det kommande NIS2-direktivet, och i vissa fall måste man även berätta för de som använder tjänsterna vad som hänt och hur de i sin tur kan skydda sig. Här får du reda på vilka incidenter som ska rapporteras, till vem, när, och vad de olika incidentrapporterna ska innehålla. 
 


Varför incidentrapportering? 

Europa behöver snabbt identifiera och hantera allvarliga incidenter mot nätverk och informationssystem. Genom snabb och genomtänkt rapportering som aggregeras uppåt först inom länderna och senare inom hela EU, så får vi data så vi kan bygga mer motståndskraftiga tjänster. Vi lär oss av incidenter som inträffat på ett ställe, så att vi kan täppa till hålen innan det sker igen på ett annat ställe.
 

Vilka incidenter ska rapporteras? 

Grundkravet för att en incident ska träffas av rapporteringskravet är att den kan anses ha en
signifikant påverkantillhandahållandet av de tjänster verksamheten levererar. För att avgöra ifall påverkan är signifikant eller inte tas två olika perspektiv – påverkan på verksamheten respektive påverkan på andra: 

  • Påverkan på verksamheten: Kan incidenten förmodas komma att, eller har den redan, orsakat en allvarlig störning avseende leverans av verksamhetens tjänst, eller finansiella förluster för verksamheten? eller

  • Påverkan på andra: Kan incidenten förmodas komma att, eller har den redan orsakat, avsevärd materiell eller icke-materiell förlust för andra fysiska (människor) eller juridiska personer (som bolag, myndigheter, etc.)

Om svaret på någon av dessa frågor är ”Ja”, så är det fråga om en sådan signifikant incident som ska rapporteras. 

En fråga som kan infinna sig är då vad som avses med ”allvarlig störning” respektive ”avsevärd förlust”. Flera olika faktorer behöver vägas samman för att avgöra ifall incidenten bör anses ha sådan påverkan, och därmed ska rapporteras. I förarbetet till NIS2-utkastet anges följande frågeställningar som relevanta i den bedömningen: 

  • Vilka är de påverkade nätverken och informationssystemen? 

  • Vilken betydelse har dessa gällande tillhandahållandet av tjänsterna? 

  • Hur allvarligt är hotet och vilka tekniska karaktärsdrag har det? 

  • Vilka underliggande sårbarheter exploateras genom hotet? 

  • Har vi tidigare erfarenhet av liknande händelser? 

  • I hur stor utsträckning har tjänsten vi levererar påverkats? 

  • Hur länge har incidenten pågått? 

  • Hur många tjänstekonsumenter är påverkade? 

Inom finanssektorn är en ny rättslig reglering på gång som heter DORA Digital Operational Resilience ACT. För de som träffas av DORA, så gäller i stället den incidentrapportering som beskrivs där istället för den i NIS2. 
 

Till vem ska incidenterna rapporteras? 

I Sverige har man beslutat att det är Myndigheten för Samhällsskydd och Beredskap MSB som tar emot incidentrapporterna oavsett bransch. Här följer fakta om incidentrapporteringen i Sverige:
 

  • I Sverige finns redans sedan tidigare en inarbetad rutin för incidentrapportering till MSB och CERT-SE. CERT-SE är Sveriges så kallade CSIRT (Computer Security Incident Response Team) inom EU-samarbetet.  

  • CSIRT tar emot incidentrapporterna från de olika verksamheterna som träffas av NIS2 men har inte tidigare förväntas agera operativt för att avhjälpa dem. I NIS2 skruvas ambitionen upp något då de kan komma att vara med i det operativa arbetet med incidenterna. 

  • För att tillsynsmyndigheterna inte skulle bli en flaskhals för det operativa arbetet vid incidenter i Sverige så meddelas tillsynsmyndigheterna av MSB parallellt med det operativa hanterandet hos CERT-SE, incidentrapporterna går dock direkt till CERT-SE. 

  • CERT-SE har numera också en ambition att vara behjälpliga med den operativa hanteringen samt med larmning inom berörd sektor och till behöriga/ansvariga sektorsmyndigheter. 

  • CSIRT-nätverket på EU-nivå har varit verksamt i många år, men NIS2 sätter ytterligare fokus på vikten av det europeiska samarbetet mellan nationella CSIRT, men även mellan andra CSIRT för sektorer och för större samhällsviktiga verksamheter. 

  • Att leverantörer av samhällsviktiga verksamheter nu även tvingas informera sina kunder och kanske allmänheten vid incidenter är väl rimligt, men detaljerna kring vad, hur och när, kommer troligen att förklaras mer i detalj genom instruktioner från Kommissionen och föreskrifter från MSB. 

  • Det är bra att incidentrapportering gällande informationssäkerhetsincidenter kommer att vara liknande för flera parallella EU-regleringar, exempelvis för verksamheter som träffas av CER-direktivet (Critical Entities Resilience) respektive DORA (Digital Operational Resilience Act) 

 
Incidentrapporten enligt NIS2 

Blogginlägg NIS2

Figur: NIS2 kräver incidentrapportering i flera steg 


I det fall verksamheten identifierat en incident vilken faller under NIS2s rapporteringskrav så tar en ambitiös flerstegsprocess vid. Processen består av fyra olika steg, som samtliga innebär att information om incidenten - vartefter det klarnar - ska skickas in till den nationella incidentmottagaren (MSBs CERT-SE i Sverige):
 

  • 24H Early Warning: Utan onödigt dröjsmål dock senast inom 24 timmar räknat från det att verksamheten blivit medveten om incidenten, ska ett meddelande kallat ”early warning” skickas in. Syftet är att incidentorganisationer i Sverige och Europa snabbt ska kunna reagera främst på sådant som påverkar fler än ett medlemsland eller är ett resultat av olagligt eller maliciöst handlande. Denna inledande incidentrapport ska således endast innehålla 

    • En övergripande beskrivning av vad som inträffat 

    • En bedömning huruvida incidenten är orsakat av olagligt eller maliciöst handlande 

    • En bedömning huruvida incidenten är eller kan förmodas bli av gränsöverskridande karaktär (landsgränser) 
       

  • 72H Incident Notification: Utan onödigt dröjsmål dock senast inom 72 timmar räknat från det att verksamheten blivit medveten om incidenten, ska ett meddelande kallat ”Incident notification” skickas. Detta är den egentliga incidentrapporten och den innefattar: 

    • En uppdatering av tidigare ”early warning”-information vid behov 

    • En initial bedömning av incidenten 

      • En bedömning av incidentens allvarlighetsgrad 

      • En uppskattning och beskrivning av incidentens påverkan / konsekvenser 

    • Så kallade Indicators of Compromise (IOCs), det vill säga ofta informationsteknisk information vilken kan hjälpa andra verksamheter att avgöra huruvida även de är utsatta för samma händelse. 
       

  • UR Status Update: Vid begäran av incidentrapportmottagaren ska en statusuppdatering avlämnas i tiden emellan den initiala incidentrapporten och den slutgiltiga rapporten. Statusuppdateringens innehåll beror på vad som framkommit och ändrats sedan förra rapporteringen. 
     

  • 1M Final Report: Inom en månad från det att ”incident notification” avlämnades ska en slutrapport skickas in. Det är liknande information som tidigare men här krävs mer detaljer och hotkategorin ska även anges: 

    • Detaljerad beskrivning av incidenten så som man känner till den nu 

    • En bedömning av incidentens allvarlighetsgrad 

    • En uppskattning och beskrivning av incidentens påverkan / konsekvenser 

    • Typ av hot eller grundorsak som förmodas ha orsakat incidenten. 

Tanken är att varje medlemsland ska se till så att det finns effektiva och ändamålsenliga metoder tillgängliga för inrapporteringen för alla dessa fyra steg. Förmodligen kommer man kunna genomföra alla fyra steg i rapporteringen i ett och samma säkra webbgränssnitt. 


Reflektioner
 

  • För att rapporteringen inte ska bli alltför betungande så krävs att MSB får igång sitt inrapporteringssystem och att tillsynsmyndigheterna snabbar på sin hantering av aktörernas anmälan och kontaktuppgifter. 

  • Redan idag så finns det i samhället en oroväckande trend av underlåtelse att rapportera signifikanta incidenter, både inom privat och offentlig sektor, och för att motverka