Säkerhetsloggning ska göra det möjligt att upptäcka oönskade händelser och förstå vad som har hänt. Bestäm vilka frågor loggarna ska besvara innan ni samlar in fler uppgifter. Ett system som sparar varje meddelande men inte visar vem som ändrade en behörighet kan samtidigt vara integritetskänsligt och oanvändbart vid en incident.
Den här guiden hjälper IT- och säkerhetsansvariga att ta fram en loggkatalog, välja åtkomst och lagring samt kontrollera hela vägen från händelse till ansvarig person. Den skiljer generell säkerhetsloggning från särskilda sektorskrav, till exempel vårdens kontroll av åtkomst till patientuppgifter.
Börja med ändamål och systemkällor
Beskriv varför varje kategori av loggar behövs. Ett ändamål kan vara att upptäcka obehörig inloggning, ett annat att utreda ändringar i ett känsligt register. Felsökning av prestanda kan kräva annan information och kortare lagring än en säkerhetsutredning. Lägg inte alla användningar i samma obegränsade kategori ”drift”.
IMY:s vägledning om säkerhetsloggning och logganalys betonar riktlinjer, insamling, lagring, analys och behörighetsstyrning. Valen ska knytas till behov, riskanalys och kontinuitetsplan. Vägledningen ger inte en enda generell lagringstid för alla svenska verksamheter.
Utgå från kartan över IT-system och dataflöden. Ange vilka identitetstjänster, applikationer, databaser, nätverksenheter och säkerhetsverktyg som behöver bidra. Kontrollera även externa tjänster: ett avtal om säker drift visar inte att organisationen faktiskt kan få ut de loggar som behövs.
Välj händelser som svarar på ett säkerhetsbehov
En första genomgång kan omfatta inloggningar, misslyckade åtkomstförsök, ändringar av behörighet, administrativa åtgärder, större exporter och avstängning av säkerhetsfunktioner. Välj därefter vilka händelser som behövs i den aktuella miljön. En lista med tekniska händelsekoder är meningsfull först när rätt loggkategori verkligen är aktiverad.
För varje händelse behövs vanligtvis tidpunkt, källa, aktör eller teknisk identitet, åtgärd och resultat. Koppla också händelsen till ett relevant objekt, exempelvis ett konto eller en registerpost, utan att kopiera hela innehållet. Fältens betydelse ska vara dokumenterad så att den som utreder inte behöver gissa om ett nummer avser användare, session eller ärende.
| Källa i ett konstruerat företag | Händelse | Fråga som ska kunna besvaras |
|---|---|---|
| Identitetstjänst | Misslyckad och lyckad inloggning | Följdes många misslyckade försök av åtkomst? |
| Kundsystem | Tilldelad exportbehörighet | Vem gav rättigheten och när? |
| Kundsystem | Genomförd export | Vilken användare exporterade vilken kategori och omfattning? |
| Administration | Ändrad loggkonfiguration | Stängdes en viktig källa av före incidenten? |
| Loggplattform | Läsning och export av loggar | Vem tog del av utredningsunderlaget? |
Tabellen är ett ifyllt planeringsexempel, inte en lista över obligatoriska händelser för varje verksamhet. Använd verksamhetens egna scenarier för att avgöra vad som ska läggas till eller tas bort.
Samla inte hemligheter och innehåll av bekvämlighet
Loggar bör inte innehålla lösenord, återställningskoder, fullständiga sessionsnycklar eller andra hemligheter som kan användas för att få åtkomst. Ett inloggningsfel ska beskriva händelsen, inte den text användaren råkade skriva. Även felplacerade inmatningar kan annars bli en källa till klartextlösenord.
Undvik att automatiskt kopiera meddelanden, bilagor och kompletta formulärsvar till driftloggen. En teknisk objektreferens och relevant åtgärdsinformation är ofta mer ändamålsenlig. Uppgiftsminimeringens fältmatris hjälper teamet att motivera varje fält och upptäcka uppgifter som bara följt med standardinställningen.
Detaljerad felsökning kan i vissa situationer behövas under en avgränsad tid. Dokumentera då vad som samlas in, varför, vilka som får se materialet och hur insamlingen stoppas. En tillfällig felsökningsinställning ska inte bli permanent för att supportärendet stängdes innan någon återställde konfigurationen.
Säkerställ tid och överföring
Händelser från olika system behöver kunna placeras i rätt ordning. Kontrollera tidszon, klockavvikelse och hur systemet hanterar sommartid. En logg som visar lokal tid utan tidszon kan bli svårtolkad när den jämförs med en molntjänst som använder UTC.
Granska vad som händer när en källa tappar anslutningen till insamlingen. Buffras händelser, förloras de eller skrivs de över? Finns ett larm när källan blir tyst? Ett tomt sökresultat får inte automatiskt tolkas som att inget hände; det kan också betyda att loggningen varit avstängd.
Central insamling kan minska beroendet av den drabbade datorn och underlätta analys. Den behöver samtidigt skyddade överföringar, avgränsade skrivmöjligheter och tydliga åtkomster. Välj arkitektur efter behovet. GDPR innebär inte i sig ett krav på att köpa en produkt som kallas SIEM.
Skydda loggarna och skilj på roller
Den som administrerar ett övervakat system bör inte utan kontroll kunna ändra både systemet och alla spår efter åtgärden. Bedöm hur insamling, läsning, export och radering kan separeras. I en mindre organisation kan kompletterande granskning behövas när full organisatorisk separation inte är möjlig.
Begränsa åtkomst till dem som behöver loggarna för en bestämd uppgift. En chef som vill följa teamets arbetstakt ska inte automatiskt få säkerhetsanalytikerns vy. Administrativa rättigheter till loggplattformen bör vara personliga och omfattas av lösenordspolicyn och autentiseringskraven.
Skydd mot ändring är viktigt, men gör inte loggar till ett ofelbart bevis. Felaktiga klockor, delade konton och ofullständig insamling kan påverka tolkningen. Utredningen behöver dokumentera hur materialet samlades in och vilka begränsningar som finns. Använd inte uttryck som ”bevisar säkert” när loggen bara visar en del av händelseförloppet.
Bestäm lagringstid per ändamål
Lagringsbegränsning och säkerhet ska bedömas tillsammans enligt dataskyddsförordningens artiklar 5 och 32. Fråga hur lång tid som behövs för upptäckt, utredning och eventuella tillämpliga skyldigheter. Den lagringsvolym som ingår i ett abonnemang är ingen självständig rättslig motivering.
I ett konstruerat exempel väljer företaget 30 dagar för en begränsad teknisk felsökningslogg eftersom fel normalt följs upp under den perioden. Behörighetsändringar får en separat bedömning utifrån hur granskningen och incidentutredningen fungerar. Trettio dagar är här ett lokalt exempel, inte en svensk standardfrist eller en rekommendation för alla säkerhetsloggar.
När en konkret incident utreds kan ett nödvändigt utdrag behöva sparas separat. Avgränsa berörda system, tidsperiod och händelser. Ange vem som beslutar om fortsatt bevarande och när behovet ska omprövas. Stoppa inte gallringen av samtliga loggar på obestämd tid för att ett enskilt konto undersöks.
Koppla besluten till gallringsplanen. Kontrollera även exporter, supportbilagor och säkerhetskopior. Att den centrala plattformen har en gallringsinställning visar inte vad som fortfarande finns i utredarens nedladdningsmapp.
För patientjournaler gäller särskilda svenska krav som en generell säkerhetslogg inte ersätter. Följ rutinen för patientjournalens loggkontroll när ni behöver fastställa obligatoriska logguppgifter, återkommande kontroller och minsta bevarandetid i vården.
Beskriv personuppgiftsbehandlingen och informera
Användaridentiteter, IP-adresser och händelser kan vara personuppgifter. Loggningen behöver därför ett tydligt ändamål, rättslig grund och lämplig information till berörda. Bedömningen av IP-adresser kan hjälpa när tekniska team betraktar nätverksuppgifter som automatiskt anonyma.
Säkerhetsloggar ska inte utan en separat bedömning återanvändas för att mäta produktivitet eller kartlägga privata vanor. En sådan förändring kan påverka ändamål, proportionalitet och arbetsrättsliga frågor. Beskriv i informationen vad som registreras och varför, i stället för att ge ett obegränsat förbehåll om att arbetsgivaren kan övervaka allt.
Rättighetsbegäranden kan också omfatta logguppgifter. Planera hur en persons uppgifter kan hittas och lämnas på ett begripligt sätt utan att röja andra personers information eller obehörigen exponera säkerhetsdetaljer. Eventuella begränsningar behöver bedömas konkret.
Följ ett larm hela vägen till åtgärd
Bestäm mottagare, första kontroll och eskalering för varje prioriterat larmscenario. Ange en ersättare vid frånvaro. Om en extern tjänst övervakar miljön måste avtalet klargöra om leverantören bara skickar larm eller även får vidta åtgärder.
I ett ifyllt övningsexempel utför teamet överenskomna misslyckade inloggningar på ett särskilt demonstrationskonto. Händelserna finns i källan och når plattformen, men larmet skickas till en gammal e-postadress. Kontrollen upptäcker alltså en brist i mottagningen trots att själva insamlingen fungerar.
Teamet rättar adressen, anger en ersättare och provar igen. Protokollet innehåller händelsereferens, tidsstämplar, mottagare och resultat. Det innehåller inga lösenord eller riktiga kunduppgifter. Nästa kontroll kan undersöka att en tystnad i loggkällan också upptäcks.
Knyt driften till policy och incidentrutin
Låt informationssäkerhetspolicyn ange ägarskap och övergripande regler. Loggkatalogen beskriver de faktiska källorna och kontrollplanen visar hur funktion och gallring följs upp. Vid bekräftad avvikelse ska analysen kunna lämnas vidare till incidentrutinen med relevanta fakta och tydlig osäkerhet.
Slutkontrollen bör besvara fyra frågor: kommer rätt händelser fram, går de att tolka, agerar en ansvarig person och försvinner uppgifterna enligt planen? När alla fyra delarna kan visas fungerar loggningen som en praktisk säkerhetsåtgärd som går att granska och förbättra.