# Incident ## Vad det är En incident är ett problem i ett system i drift som har blivit så allvarligt att folk lägger det planerade arbetet åt sidan och tar itu med det nu: en tjänst som har slutat svara, poster som har ändrats, en maskin som har fått slut på minne, ett konto som någon annan använder. Säkerhetsfolk talar om säkerhetsincidenter, driftfolk om driftincidenter eller helt enkelt avbrott, och de flesta organisationer sorterar sina incidenter i allvarlighetsnivåer. NIST:s vägledning för incidenthantering drar gränsen i tre steg, och de håller långt utanför säkerhetsarbetet. En händelse är allt observerbart som rör it-tillgångar: ett inloggningsförsök, en programuppdatering, en app som besvarar en begäran. En negativ händelse är en händelse med en skadlig följd, oavsett orsak, och vägledningen ställer naturkatastrofer och strömavbrott bredvid angrepp. En incident är en negativ händelse som någon har bedömt uppfyller organisationens kriterier, och vägledningens verb för den bedömningen är _declared_, deklarerad. Definitionen som den vilar på, hämtad ur amerikansk federal lag, omfattar det som faktiskt eller omedelbart sätter konfidentialitet, riktighet eller tillgänglighet hos information eller ett system på spel, eller som bryter mot en säkerhetspolicy. Säkerhet och drift använder ordet med olika tyngdpunkt. I säkerhetsarbete antyder en incident oftast en motståndare, ett policybrott eller data som kan ha lämnat huset. I drift betyder den varje oplanerat avbrott eller allvarlig försämring av en tjänst, utan någon angripare i historien. De två överlappar mer än orden antyder: en överbelastningsattack och en vanlig trafiktopp kan se likadana ut i en graf till en början, och en disk som blir full kan förlora data lika grundligt som en inkräktare. Grannorden är värda att hålla isär. En defekt är en brist i produkten; den kan ligga obemärkt i åratal och blir en del av en incident först när den börjar göra skada. Ett larm är ett meddelande om att något kan vara fel; många larm blir aldrig incidenter, och många incidenter rapporteras först av en kund. Inom tjänstehantering följs orsaken bakom en eller flera incidenter upp för sig, som ett problem. ## Varför det spelar roll Beslutet som gömmer sig i ordet är en tröskel. När slutar en långsam sida, en udda inloggning eller en växande kö att vara en enskild ingenjörs ärende och blir teamets första prioritet? Lägg ribban för högt, och ett intrång som sprider sig hanteras som rutinarbete av någon som inte kan se det växa. Lägg den för lågt, och folk dras bort från sitt arbete så ofta att en deklaration slutar betyda något. NIST:s svar är att komma överens om kriterierna innan de behövs: incidenter deklareras när negativa händelser uppfyller kriterier som organisationen redan har definierat, med kända falsklarm inräknade. Skrivna kriterier med exempel är betydligt billigare än en diskussion klockan två på natten. En deklaration ändrar vem som gör vad. En person leder och samordnar i stället för att felsöka, andra frigörs från sitt vanliga arbete, en kanal bär fakta och en logg med tidsstämplar startar. Utan det gör samma personer samma arbete parallellt, och det första tydliga beskedet om problemet blir det som en kund skriver. För en del företag finns också en klocka i lagen. EU:s NIS2-direktiv, direktiv (EU) 2022/2555, kräver att de organisationer som omfattas rapporterar en betydande incident till den nationella myndigheten: en tidig varning inom 24 timmar från att de fick kännedom om den, en rapport om incidenten inom 72 timmar och en slutrapport senast en månad efter den rapporten. Direktivets definition sträcker sig bortom angrepp till varje händelse som äventyrar tillgängligheten, autenticiteten, riktigheten eller konfidentialiteten hos data eller hos de tjänster som ett nätverks- och informationssystem erbjuder, så ett allvarligt driftstopp kan räknas. Ett team som börjar fråga ”är det här en incident?” på andra dagen har redan förbrukat det första fönstret. Den löpande kostnaden är människors tid, och den är större än den brukade vara. 2025 års revision av NIST:s vägledning konstaterar att incidenter numera inträffar ofta och att återhämtningen ofta tar veckor eller månader, medan föregångaren från 2012 utgick från att de var sällsynta och över inom en dag eller två. Att budgetera för incidenter betyder att budgetera för efterarbetet lika mycket som för själva natten. ## Så ser det ut i praktiken Den bäst uppmätta incidenten på den här webbplatsen inträffade i en skrivbordsapplikation för macOS. [Applikationen fyllde minnet med ungefär 41 MB i sekunden](/sv/portfolio/stopped-an-application-filling-memory-at-41mb-a-second-155/) tills operativsystemet dödade den; den registrerade incidenten nådde 111 GB komprimerade minnessidor på en maskin med 36 GB, och en enda kort session lämnade en loggfil på 610 996 rader. Arbetet hittade tre orsaker som multiplicerade varandra: en händelseström som konsumerades utan gräns, prenumeranter som var och en tog emot varje händelse, och loggning vars volym växte med felet den registrerade. Varje väg fick en gräns, ett regressionstest kontrollerar nu minnestaket under en hög händelsetakt, och samma session skriver 1 411 rader. Priset namnges också: taktbudgeten för loggningen kastar information, så spåren av nästa snabba fel blir medvetet ofullständiga. Andra incidenter är av det återkommande slaget. Åtta tunnlar med WireGuard och IPsec mellan Google Cloud och Linux-system var bräckliga och långsamma att diagnostisera, och en död tunnel kunde bryta kommunikationen mellan miljöerna. Arbetet standardiserade konfigurationen, övervakade tunnlarnas tillstånd och åtgärdade de återkommande problemen med routning och nyckelutbyte vid roten i stället för att starta om tunnlarna, och [de återkommande anslutningsincidenterna upphörde](/sv/portfolio/managed-and-troubleshooted-8-wireguard-vpn-and-ipsec-23/). När samma sak händer för tredje gången är orsaken själva incidenten. Och vissa incidenter börjar med att någon försöker hjälpa till. På en plattform utan administrationsverktyg hamnar det på en ingenjör med en databaskonsol att godkänna ett anspråk, dölja en recension eller rensa en cache, något som projektsidan kallar långsamt, ologgat och ett skrivfel från en incident. Det backoffice för operatörer som byggdes där, [ungefär 40 admin-routes byggda av 128 komponenter](/sv/portfolio/built-the-operator-back-office-for-the-platform-102/), lägger det arbetet bakom samma auktorisering och samma spår som resten av produkten, till den löpande kostnaden av en stor intern yta att hålla testad och tillgänglig. ## Var det går fel **Fem personer arbetar med den och ingen leder den.** Chattkanalen fylls av teorier, två ingenjörer rullar tillbaka olika saker, och kunderna hör ingenting på en timme, eftersom ingen deklarerade incidenten, och därmed fick ingen i uppdrag att samordna. Låt vem som helst i teamet deklarera, och gör det första steget i varje deklaration till att utse en ledare som håller helhetsbilden och loggen. **Samma incident kommer tillbaka med några veckors mellanrum.** Insatsen slutar när tjänsten är uppe igen, och en omstart räknas som lösningen. Behandla återställd tjänst och borttagen orsak som två uppgifter: stäng den första under natten, och ge den andra en ägare och ett datum innan någon går och lägger sig. **Verktygen gör incidenten större.** Loggning som skriver en rad per händelse ger en logg lika stor som felet, och larmregler skickar hundratals aviseringar för en enda orsak. Ge loggar och larm en budget i förväg, slå ihop upprepningar och testa rapporteringsvägen under lasten från det fel som den rapporterar. **Lagningen orsakar nästa incident.** En hastig ändring som skrivs för hand mot produktion lagar ett symtom, startar ett annat problem och lämnar ett hål i tidslinjen som genomgången senare behöver. Håll en kort lista med förhandsgodkända återställningsåtgärder som lämnar spår, och skriv ned varje ändring som görs under en incident. **Lärdomarna kommer månader för sent, eller kommer som skuld.** En genomgång som hålls efter veckor av återhämtning minns lite, och en som frågar vem som gjorde misstaget lär folk att dölja nästa. NIST:s reviderade vägledning säger att lärdomar ofta bör delas så snart de har identifierats, och dess vägledning för återhämtning slutar med en rapport efter insatsen om incidenten, de åtgärder som vidtogs och vad man lärde sig. Skriv ned vad som gjorde misstaget lätt att begå, och ändra det. ## Läs mer - [Incident](https://csrc.nist.gov/glossary/term/incident) — de definitioner som NIST:s publikationer använder, var och en med den lag eller standard den kommer från. - [SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) — NIST:s rekommendationer för incidenthantering från 2025, byggda kring funktionerna i CSF 2.0 i stället för en enda insatscykel. - [Cybersecurity Framework](https://www.nist.gov/cyberframework) — ramverket med funktionerna Govern, Identify, Protect, Detect, Respond och Recover, som incidentvägledningen bygger på. - [RFC 2350: Expectations for Computer Security Incident Response](https://www.rfc-editor.org/rfc/rfc2350) — IETF:s bästa praxis för vad ett incidentteam bör publicera om sig självt.