Konceptuell beskrivning

Förstora bilden Egencentralicerat loggsystem

Konceptuell bild av process/flöde för en egen Centraliserad loggsystem med flera loggenererade enheter. Den innersta rutan visar huvuddelarna av processmodellen som omfattar denna kravspecifikation

”Processbeskrivningen ska ses som ett medel för att underlätta Enas vision för logghantering och spårbarhet samt för att beskriva vilken funktionalitet som en egen centraliserad loggtjänst förväntas innehålla.”

Loggenererande enheter

Olika system, applikationer eller enheter som genererar loggdata. Det kan inkludera datorer, servrar, nätverksenheter, databaser, applikationer och annan infrastruktur.
Det viktigt är att man tänker på vilka loggar man vill skicka till ett loggsystem. Formatet på loggen och med vilken teknik/protokoll den skickas med, så att mottagande system kan tolka loggdata rätt och mappa/parsa varje del i loggen till rätt fält i databasschemat. Det kan vara en utmaning att tolka en logg som inte har något stöd i loggsystemet. Risken är att tolkningen inte är felfria och viss loggdata missas. Alla tolkningsregler behöver testas utförligt.

Valet av vad som ska loggas och vad som inte ska loggas är viktigt och behöver dokumenteras. Informationsklassning och en rättslig analys behöver utföras. Detta gäller speciellt om personuppgifter ska behandlas. Se Ramverk Loggning och Spårbarhet.

Man behöver även uppskatta hur mycket utrymme som kommer att behövas och hur mycket prestanda som kommer att krävas. Speciellt om inget loggsystem ännu är inköpt. En viktig del i ett loggsystem är skalbarheten, eftersom det kan vara svårt att uppskatta resursutnyttjandet i förväg.

Rutiner för uppsättning av nya loggenererande enheter behöver utformas.

Transformation, Aggregering och Tolkning

Uppsamling av loggar från loggenererande enheter. Detta kan t.ex. gälla systemloggar, applikationsloggar, brandväggar, nätverksloggar eller loggar som redan samlats direkt från den loggenererande enheten eller från en så kallad aggregeringspunkt. Funktionen för insamling skall kunna samla in loggdata från fil, databas, tjänst och liknande.

• Konfigurera autentiseringsuppgifter, DNS-namn, kommunikationsportar om loggar ska hämtas in.
  

• Välj om/hur aggregering ska användas. T.ex. spara alla logghändelser med samma IP-adresser i både källan och destinationen inom en kort tidsperiod.
  

• Aggregering kanske inte ska användas på data i närtid, så att alla händelser kan spåras. Utred om både korttidslagring och långtidslagring behövs.
  

• Mappa/parsa inkommande loggar till rätt fält i databasschemat. Alla tolkningsregler behöver testas utförligt.
  

Det är även viktigt att säkerställa robustheten i uppsamlingen. Flödet för det som skickas in eller hämtas, måste vara robust så att ingen loggdata försvinner på vägen. Möjliga vägval:

• Nätverksprotokollet TCP istället för UDP.

• Apache Kafkateknik för insamling av loggdata.

• Lastbalansering och redundans för att säkerställa tillgänglighet.

Logganalysverktyg

En egen Centraliserad loggning per myndighet/organisation innebär att alla logghändelser från olika instanser av applikationer och system som används av en specifik offentlig aktör skrivs till en gemensam lagringsplats inom den egna organisationen. Den centrala lagringsplatsen är en databas som är optimerad för lagring och sökning.

Denna egen centrala loggning bör läggas utanför det vanliga datacentret, för att kunna fortsätta att ta emot loggdata, även om vissa delar av datacentret är nere. Detta möjliggör felsökning och analyser vid problem. Skulle den egna Centrala loggningen sluta fungera, finns loggarna fortfarande kvar ett tag hos källorna.

Lagring och indexering

• Lagra och indexera upp fälten som ska kunna sökas.
  

• För att öka bevisvärdet, använd eventuellt signering/kontrollsummor och lagra skriv en gång läs flera, så att till exempel Ransomware inte kan kryptera datat.
  

• Installera lastbalansering och redundans för att undvika att tjänsten går ner om en enda komponent slutar att fungera.
  

• Utför informationsklassning på korrelerade data och utred om lagrade data behöver vara krypterad. Se MSB

Analys och konfiguration

Det ska finnas möjligheter till analys av loggdata, inklusive mönsterigenkänning, anomalidetektering och korrelation av händelser för att identifiera trender, hot och mönster.

Viktiga funktioner som sök- och filtreringsmöjligheter för att kunna söka efter specifika händelser eller loggposter baserat på olika kriterier, såsom tid, källa, händelsetyp, användare etc.

För att inbyggda regler, tabeller och diagram ska fungera som det är tänkt, behöver man ofta ställa in olika parametrar som t.ex. vilka DNS-servrar, DHCP-servrar, Databasservrar med mera som man har, vilka IP-nät som man har och liknande.

Säkerhetskopiering och återställningsfunktioner behöver ställas in och behörigheter behöver sättas upp för att motsvara behoven.

Det är bra om man kan integrera ett befintligt behörighetssystem, som till exempel Active Directory.

Rutiner för spårningsärenden, logganalyser, loggutdrag, export av loggdata, informationsutbyten med mera behöver utformas.

Dokumentation behöver upprättas över hur systemet är uppsatt, vilka konfigurationer som är gjorda och varför.

Larmsättning

Larmsättning av händelser är viktigt för att kunna övervaka applikationer och system. Man ska enkelt kunna skapa larm i ett grafiskt webbgränssnitt som skickar händelser till övervakningssystem, mejl, SMS och liknande.

Det finns ofta möjlighet att i loggsystemet skapa ärenden och tilldela personer dessa ärenden, så att man får en spårbarhet på vem som blev tilldelad och vad som hände med ärendet.

En del loggsystem har även möjlighet att integreras med ärendehanterings¬system, så att larmsatta händelser automatiskt skapar ärenden i dessa system.

Arkivering

Loggdata från applikationer, system och nätverkskomponenter som är anslutna till logghanteringssystemet skall arkiveras. Det skall finnas möjligheter att läsa ut och göra analyser på loggdata från arkivet.

Loggsystemet behöver vara produktionssatt under hela arkivets livslängd, för att säkerställa läsning av arkivdata. I annat fall måste arkivdata exporteras ut till rekommenderat format enligt riksarkivets föreskrifter om format på elektroniska handlingar (RAFS RA-FS 2009–02).

För att underlätta arkivering behöver loggsystemet ha funktioner för automatisk arkivering.

Gallring

Gallring kräver författningsstöd, dvs gallringsbestämmelser i lag, förordning eller myndighetsföreskrifter, för att gallringen ska få kunna genomföras. Gallring av loggdata är en viktig del av hanteringen av loggar. Det innebär att man tar bort loggar som inte längre är relevanta eller nödvändiga för att frigöra lagringsutrymme och förbättra prestanda.

För att underlätta gallring behöver loggsystemet stödja uppsättning av automatiska gallringsregler.