Den svåraste delen av en säkerhetsincident inträffar vanligtvis efter att själva incidenten är över: när verksamheten måste förklara vad som hände, när den upptäcktes, vilka data som berördes, vem som påverkades och varför vissa beslut fattades.
För många små och medelstora företag finns inte dessa register i fullständig form. Detaljer kan vara utspridda i chattmeddelanden, inkorgar, supportärenden, skärmdumpar och i teammedlemmars minnen. Verksamheter håller sig flytande under en incident med dessa lappade register, men de blir ett problem när tillsynsmyndigheter, ett försäkringsbolag, en kund eller en styrelseledamot begär en tydlig tidslinje.
Verksamheter av alla storlekar behöver en grundlig säkerhetsincidentlogg. Den bör vara en enda källa till sanning för att dokumentera vad som hände, hur incidenten hanterades och vilka bevis som stöder de beslut som fattades under vägen.
Registret är värdefullt även när du inte behöver rapportera en incident. Här förklaras varför säkerhetsincidentloggar är användbara för din verksamhet och hur du skapar dina egna.
Varför säkerhetsincidentloggar är viktiga
Incidentloggar kontra planer för incidenthantering
Vad en säkerhetsincidentlogg bör innehålla
En enkel mall för incidentlogg för små och medelstora företag
Så dokumenterar du beslut om avisering
Vad tillsynsmyndigheter förväntar sig av säkerhetsincidentloggar
Åtkomstloggen för inloggningsuppgifter
Varför säkerhetsincidentloggar är viktiga
Säkerhetsincidentloggar skapar ansvarsskyldighet i det ögonblick då en verksamhet är mest benägen att tappa bort detaljer. Under en incident sker åtgärder snabbt: lösenord återställs, konton inaktiveras, IT-leverantörer kontaktas, kunddata kontrolleras och ledningen informeras. Dessa steg kan vara precis vad verksamheten behöver i stunden, men de blir mycket svårare att förklara senare om ingen dokumenterar när varje åtgärd inträffade, vem som godkände den och vilka bevis som stödde beslutet.
För verksamheter baserade i Europa är detta inte bara god praxis. Enligt dataskyddsförordningen (GDPR), både i Storbritannien och EU, måste personuppgiftsincidenter bedömas, och vissa måste rapporteras till motsvarande tillsynsmyndighet.
I Storbritannien förklarar ICO:s anmäl en incident(nytt fönster) vägledning att organisationer måste bedöma den sannolika risken för människors rättigheter och friheter och underrätta ICO när risken är sannolik. Artikel 33 kräver också att personuppgiftsansvariga dokumenterar personuppgiftsincidenter, inklusive omständigheterna kring incidenten, dess effekter och de avhjälpande åtgärder som vidtagits. Samma krav gäller enligt EU:s GDPR.
ICO förväntar sig till exempel inte att alla små och medelstora företag har system i företagsklass, men väl lämpliga register. ICO:s ramverk för incidenthantering och övervakning säger att organisationer bör ha rutiner för att säkerställa att personuppgiftsincidenter och intrång upptäcks, hanteras och dokumenteras på lämpligt sätt. Det innebär att en incidentlogg inte bör skapas först när ett allvarligt intrång redan har inträffat. Den bör ingå i den normala incidenthanteringsprocessen.
Goda register stöder också försäkringsanspråk. Cyberförsäkringsbolag kan begära bevis för när incidenten upptäcktes, vilka begränsningsåtgärder som vidtogs, vilka konton som påverkades och om verksamheten följde sin incidenthanteringsprocess. En välskött logg kan visa att verksamheten agerade snabbt och konsekvent.
Det hjälper också företaget att lära sig. Minnen och muntliga register är inte tillförlitliga, men ett register som visar att incidenten började med ett återanvänt lösenord, saknad multifaktorautentisering (MFA), leverantörsåtkomst eller försenad avveckling ger verksamheten något konkret att åtgärda och en tydligare riktning för att stärka säkerheten över tid.
Incidentloggar kontra planer för incidenthantering
En säkerhetsincidentlogg och en plan för incidenthantering hänger samman, men de är inte samma dokument.
En plan för incidenthantering förklarar vad verksamheten bör göra när något går fel. Den tilldelar roller, eskaleringsvägar, begränsningsåtgärder, kommunikationsansvar och återställningsrutiner. Incidentloggen dokumenterar vad som faktiskt hände. Den är tidslinjen, beviskedjan, beslutsprotokollet och uppföljningsfilen för en specifik händelse.
Den distinktionen är viktig eftersom även en bra plan kan misslyckas utan dokumentation. En verksamhet kan följa rätt steg men ändå ha svårt att bevisa det senare. Loggen bör göra det möjligt att besvara praktiska frågor: när fick vi veta, vem agerade, vad begränsade vi, vilka data var i riskzonen, vad beslutade vi och vad förändrades efteråt?
| Plan för incidenthantering: Vad din verksamhet bör göra | Säkerhetsincidentlogg: Vad som faktiskt hände |
| Vem leder insatsen Vem kontaktar IT, juridik, försäkringsbolag eller tillsynsmyndigheter Hur man begränsar, återställer och kommunicerar | När incidenten upptäcktes Vilka system och data som påverkades Vilka åtgärder som vidtogs, av vem och när |
Vad en säkerhetsincidentlogg bör innehålla
En användbar incidentlogg behöver vara tillräckligt konsekvent för att en verksamhet ska kunna rekonstruera händelsen senare och förklara de beslut som fattades under insatsen.
Datum och tid för upptäckt
Dokumentera när verksamheten först fick kännedom om incidenten, vem som upptäckte den och hur den upptäcktes. Om tiden är ungefärlig, markera den som ungefärlig. Upptäcktstiden är viktig eftersom GDPR:s rapporteringstider och försäkringskrav ofta beror på när verksamheten fick kännedom om problemet.
Typ av incident
Beskriv vad som hände med enkla ord. Undvik vaga etiketter som ”säkerhetsproblem” eller ”möjligt intrång” utan sammanhang. Loggen bör förklara vilka system som påverkades och om incidenten involverade inloggningsuppgifter, e-post, filer, kunddata, betalsystem, slutpunkter eller åtkomst från tredje part.
Berörda data
Om personuppgifter kan ha påverkats, dokumentera vilken typ av data som berördes: namn, e-postadresser, telefonnummer, adresser, kontouppgifter, finansiell information, personalregister, kundkommunikation, inloggningsuppgifter eller någon annan relevant kategori. Uppskatta hur många individer som kan påverkas och tydliggör om antalet är bekräftat eller fortfarande under utredning.
Trolig orsak
Dokumentera den kända eller misstänkta orsaken, även om utredningen fortfarande pågår. När nya detaljer framkommer kan loggen uppdateras från ”orsak okänd” till ”nätfiskemejl ledde till kompromettering av inloggningsuppgifter” eller ”tidigare entreprenörskonto förblev aktivt”. Loggen bör visa hur verksamhetens förståelse förändrades över tid.
Omedelbara begränsningsåtgärder
Dokumentera vad som gjordes för att begränsa skadan. Det kan omfatta återställning av lösenord, återkallande av sessioner, tvingande MFA, avstängning av konton, borttagning av brevlåderegler, isolering av enheter, borttagning av leverantörsåtkomst, brandväggsändringar eller tillfälliga avstängningar av tjänster. Inkludera om möjligt ansvarig och tidsstämpel för varje åtgärd.
Beslut om avisering
Dokumentera om verksamheten underrättade den relevanta tillsynsmyndigheten (ICO i Storbritannien, eller den nationella dataskyddsmyndigheten någon annanstans i EU påverkade individer, kunder, leverantörer, försäkringsbolag, juridiska rådgivare eller brottsbekämpande myndigheter. Om beslutet var att inte underrätta, dokumentera resonemanget. Den förklaringen är ofta lika viktig som själva aviseringen.
Åtgärdssteg och tidslinje
Begränsning hanterar den omedelbara incidenten. Åtgärder minskar risken för att samma problem inträffar igen. Dokumentera uppföljande åtgärder som att tvinga MFA, ta bort delade inloggningsuppgifter, uppdatera åtkomstpolicyer, förbättra avveckling, åtgärda en felkonfiguration eller ändra hur säkerhetskopior skyddas.
Lärdomar
Avsluta med vad verksamheten lärde sig och vad som kommer att förändras. Detta bör inte skrivas som skuldbeläggning. Det bör identifiera svagheten, förbättringen som behövs och vem som ansvarar för uppföljningen.
En enkel mall för incidentlogg för små och medelstora företag
Specialiserad mjukvara är inte nödvändig för att dokumentera incidenter. Ett kalkylblad, ett säkert internt formulär, ett ärendesystem eller ett delat register kan fungera om åtkomsten kontrolleras och posterna hålls konsekventa.
En effektiv incidentlogg bör innehålla följande fält:
- Incident-ID: Ett unikt referensnummer.
- Datum och tid för upptäckt: När verksamheten fick kännedom om incidenten.
- Rapporterat av: Anställd, tjänsteleverantör, kund, leverantör, övervakningslarm eller extern part.
- Typ av incident: Nätfiske, skadlig kod, komprometterade inloggningsuppgifter, dataförlust, obehörig åtkomst, utpressningsprogram, leverantörsincident, förlorad enhet, feladresserat e-postmeddelande eller annat.
- Sammanfattning: Vad som hände, skrivet i klarspråk.
- Berörda system: Applikationer, konton, enheter, databaser, inkorgar eller tjänster från tredje part som var inblandade.
- Berörda data: Om personuppgifter påverkades, vilken typ och hur många personer som kan vara drabbade.
- Trolig orsak: Känd, misstänkt eller under utredning.
- Begränsningsåtgärder: Vad som gjordes omedelbart.
- Beslut om avisering: Tillsynsmyndighet, enskilda personer, kunder, försäkringsbolag eller ingen avisering med motivering.
- Länkar till bevis: Skärmdumpar, ärenden, loggar, e-postmeddelanden, åtkomstregister, exportfiler eller leverantörsrapporter.
- Avhjälpande åtgärder: Åtgärder som vidtogs efter begränsningen.
- Ansvarig: Person med ansvar för uppföljning.
- Status: Öppen, övervakning, begränsad, löst, stängd.
- Lärdomar: Vad som bör förändras.
Så här dokumenterar du beslut om avisering
Beslut om avisering förtjänar en egen plats i loggen över säkerhetsincidenter eftersom de ofta granskas efter incidenten.
Enligt både brittiska och EU:s GDPR måste organisationer bedöma den sannolika risken för människors rättigheter och friheter när ett intrång i personuppgifter inträffar. Om risken är sannolik måste tillsynsmyndigheten aviseras så snart som möjligt och, där det är möjligt, inom 72 timmar, ICO(nytt fönster) i Storbritannien, den nationella dataskyddsmyndigheten i varje EU-medlemsstat. Om risken är hög måste även drabbade personer aviseras utan onödigt dröjsmål. Tröskelvärdena och tidsfristen är desamma på båda sidor; det är bara myndigheten som skiljer sig.
En bra incidentlogg bör visa att verksamheten gjorde denna bedömning. Den bör dokumentera om personuppgifter var inblandade, vilken typ av skada som kunde uppstå, vilka skyddsåtgärder som fanns på plats och varför verksamheten beslutade att rapportera eller inte rapportera.
Exempelvis kan en incident med ett exponerat adminlösenord inte omedelbart avslöja om personuppgifter har varit åtkomliga. Loggen bör återspegla den osäkerheten. Den kan dokumentera den initiala oron, utredningsstegen, granskningen av kontots aktivitet och den slutliga slutsatsen när bevis finns tillgängliga.
I detta skede av processen fokuserar många verksamheter på att organisera den tekniska lösningen och glömmer att dokumentera resonemanget kring regelefterlevnad. Lösenord återställs, konton säkras och verksamheten fortsätter. Veckor senare kan verksamheten inte förklara varför den ansåg att incidenten inte behövde rapporteras.
Vad tillsynsmyndigheter förväntar sig av dokumentationen
Tillsynsmyndigheter tittar inte bara på om ett intrång rapporterades. De kan också fråga hur verksamheten:
- Identifierade incidenten
- Bedömde risken
- Beslutade om avisering krävdes
- Dokumenterade vidtagna åtgärder
En bra dokumentation bör göra incidentens händelseförlopp tydligt från början till slut. Den bör visa vad som hände, vilka personuppgifter som var inblandade, vilken skada som kunde uppstå, vad verksamheten gjorde för att begränsa problemet och varför man rapporterade eller inte rapporterade intrånget.
Detaljnivån bör matcha incidentens allvar. Ett feladresserat e-postmeddelande behöver inte samma dokumentation som en utpressningsattack, men det behöver ändå dokumenteras för att visa att verksamheten bedömde det korrekt.
Denna dokumentation bör också lagras säkert. Incidentloggar kan innehålla känsliga detaljer om drabbade personer, exponerade system, anställdas åtgärder, skärmdumpar, åtkomstloggar eller avhjälpande åtgärder. Åtkomsten bör begränsas till de personer som behöver den, och lagringstiden bör följa företagets övergripande policy för datalagring.
Loggen över åtkomst till inloggningsuppgifter
Många incidenter involverar inloggningsuppgifter: de kan utlösas av ett återanvänt lösenord, ett delat konto, en komprometterad inkorg, en exponerad admininloggning, en misstänkt MFA-förfrågan eller en anställd vars åtkomst inte avslutades korrekt.
Av den anledningen kan register över åtkomst till inloggningsuppgifter bli ett direkt underlag för dokumentation av cybersäkerhetsincidenter. När en incident involverar en delad inloggning eller ett känsligt konto behöver verksamheten veta vem som hade åtkomst, hur åtkomsten delades, om behörigheter ändrades och om inloggningsuppgiften roterades efter incidenten.
En lösenordshanterare för företag som Proton Pass for Business hjälper team att hantera inloggningsuppgifter i krypterade valv, generera unika lösenord, använda autofyll, dela inloggningsuppgifter säkert, hantera passnycklar och använda inbyggd tvåfaktorsautentisering. För incidendokumentation är det största värdet åtkomstspåret kring inloggningsuppgifter: vem som hade åtkomst till delade valv/konton, hur åtkomsten hanterades och vem som använde den, och vad som förändrades efter incidenten.
En lösenordshanterare för IT-team tillför adminfunktioner som policyer, rapportering, loggar, rollbaserad åtkomstkontroll, SCIM-provisionering och SSO-integrering. Dessa funktioner kan hjälpa verksamheter att visa hur åtkomst till inloggningsuppgifter kontrolleras och tillhandahålla bevis när en incident kopplad till inloggningsuppgifter utreds.
En lösenordshanterare kan inte ersätta en incidentlogg, en juridisk bedömning, en process för myndighetsavisering eller en plan för incidenthantering. Men den tillhandahåller bevis kring inloggningsuppgifter som kan bli underlag för dessa processer.
Håll ett komplett granskningsspår över åtkomst till inloggningsuppgifter med en lösenordshanterare för företag.
