Funktionella krav på loggning och spårbarhet

Loggsystemet ska stödja konfigurationer för hög tillgänglighet.

Hög tillgänglighet behövs för att minimera förlust av loggdata. Man vill att all loggdata som skickas verkligen sparas i loggsystemet och inte förloras på vägen. Loggsystemet är även en så stor investering i kunskap, så man kan inte enkelt byta ut det mot något annat. Därför ska hög tillgänglighet vara möjlig även om det inte krävs från början. Ta hjälp av BB Tillgänglighet.

Det ska vara möjligt att kryptera nätverkskommunikation.

För att säkerställa riktigheten och konfidentialiteten på data som skickas ska kryptering kunna användas.

Det bör vara möjligt att kryptera loggdata vid lagring.

För att säkerställa riktigheten och konfidentialiteten på data som lagras bör kryptering kunna användas.

Man bör kunna signera loggdata vid lagring eller skapa kontrollsumma vid lagring och skriva en gång men läsa flera.

Detta för att förhindra otillbörlig förändring av loggdata och skapa säkra bevis vid brottsutredningar.

Loggsystemet ska stödja kommunikation med REST API.

Ta hjälp av REST API-profilen https://dev.dataportal.se/rest-api-profil.

Single sign-on (SAML, OpenID Connect, Kerberos) bör vara möjligt.

Det är användarvänligt och stödjer även placering av proxies framför loggsystemet.

Larmfunktion ska finnas där man kan övervaka händelser och skicka meddelanden (mejl, SMS, webbtjänst och liknande) när vissa villkor uppfylls som stödjer behoven.

Man vill kunna skapa larm utifrån villkor, så att när något viktigt händer behöver man inte sitta framför loggsystemet, utan kan få larm skickat via mejl, SMS, webbtjänst och liknande.

Det ska vara möjligt att begränsa hur många larm som skickas under en viss tidsperiod (finjustering/strypning/throttling).

För att inte överösas med en massa larm om samma händelse som fortfarande existerar, ska man kunna begränsa antalet larm som skickas under en viss tidsperiod.

Utföra åtgärder vid larm enligt de behov som finns. Till exempel aktivera en accesslista, starta en nätverksspårning/Networktrace, kontrollera en uppgift.

När ett larm triggas ska man kunna utföra en åtgärd för att automatiskt undersöka, lösa/minimera eller kontrollera händelsen.

Man ska vid incidenter kunna skapa, tilldela och följa ärenden i loggsystemet.

Man ska få en incident dokumenterad och en logg på vem/vilka har undersökt incidenten, hur har arbetet fortskridit och vad har man kommit fram till.

Det bör vara möjligt att integrera med ett externt ärendehanteringssystem.

Om man redan har ett eget ärendehanteringssystem, är det smidigt att kunna använda detta även för incidenter som hittas vid analys av loggdata.

Loggsystemet skall ha stöd för maskininlärning (anomalier, träningsdata), eller liknande mönsterigenkänning och anomalidetektering.

Det kan vara extremt svårt att hitta hackeraktiviteter, intrång med mera vid analys av loggdata. Maskininlärning och liknande stöd är ett viktigt komplement till manuell logganalys för att få bättre kunskap om vilka aktiviteter som kan pågå inom organisationen.

Det ska finnas stöd för rätt språk i grafiskt gränssnitt enligt behoven.

Rätt språk ska användas i det grafiska gränssnittet, så att tänkta användare kan förstå och använda loggsystemet.

Det ska gå att visualisera data i tabeller och olika diagramtyper för de behov som finns och skapa rapporter.

Det är viktigt för att få en överblick och snabbt förstå vad loggdatat innebär att det går att använda tabeller och olika diagramtyper för att visualisera de frågeställningar som man är intresserad av.

Det ska vara möjligt att sammanställa och gruppera data för analyser och statistik, så att man kan se trender och förutse framtida incidenter.

Man kan vilja veta vilka tidpunkter då nätverket är hårdast belastat och jämföra detta med hårt belastade servrar, eller se trender på diskutnyttjande och kunna reagera innan disken blir full, eller se hur bokningarna hela tiden växer och växer så att snart måste något göras för att utöka kapaciteten etc.

Ska ha stöd för att ta emot loggdata från Microsoft Windows.

Det ska finnas stöd för vanliga operativsystem.

Ska ha stöd för att ta emot Syslog från de tillverkare som behov finns för.

Syslog används av de flesta loggkällorna, men behöver vara anpassade till respektive tillverkare.

Ska ha stöd för att ta emot SNMP med enligt de behov som finns.

Mätdata från CPU, diskanvändning, minne med mera kan ofta fås med SNMP.

Bör ha stöd för att ta emot loggdata från molntjänster enligt de behov som finns.

Det bör gå att integrera med Azure, AWS med flera för att ta del av loggdata, loggfiler med mera.

Bör ha stöd för att ta emot nätverksflöden/netflow/sflow enligt de behov som finns.

Det bör gå att skicka in nätverksflöden/netflow/sflow till loggsystemet för att kunna följa nätverkskommunikation.

Bör ha stöd för Elastic Common Schema.

Loggsystemet bör ha stöd för Elastic Common Schema, så att man kan återanvända sökfrågor från andra parter.

Det ska vara möjligt att exportera till textfiler efter de behov som finns för t.ex. arkivering enligt riksarkivets föreskrifter.

Det kan behövas om man inte längre kan använda loggsystemet för att läsa från arkivet.

Ska ha stöd för geografisk positionering av IP-adresser.

För att kunna verifiera vilka geografiska områden som använder olika tjänster för felsökning, säkerhetskontroller med mera.

Ska kunna installeras lokalt och inte vara en molntjänst.

För att inte läcka information utanför den egna organisationen.

Säkerhetsuppdateringar till loggsystemet kommer regelbundet.

För att säkerställa ett aktuellt skydd mot intrång och utnyttjande i otillbehörligt syfte.

Loggsystemet ska utvecklas kontinuerligt, så att nya funktioner kommer och eventuell maskininlärning förbättras.

Det ska vara ett uppdaterat och aktuellt loggsystem som fortfarande utvecklas för att stödja framtida behov.

Ska kunna synkronisera tid via NTP.

Detta för att samtliga loggkällor och loggsystemet använder samma aktuella tid.

Tidformatet ska stödja ISO 8601.

Detta för att jämförelser med andra loggsystem kan utföras enkelt.

Ska stödja tidzoner enligt IANA https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.

Detta för att jämförelser med andra tidzoner kan utföras enkelt.

Ska spara tid i UTC och göra det möjligt att visa tiden visuellt i aktuell tidzon.

För att inte vara beroende av sommar eller vintertid, ska tid alltid anges som UTC och visningen anpassas till aktuell tidzon.

Loggsystemet ska ha stöd för säker autentisering. Tvåfaktor, multifaktor eller liknande.

Ett loggsystem där man samlar in loggar från många loggkällor, blir en stor informationskälla och kommer med stor säkerhet att innehålla känslig information och behöver därför skyddas med en säker autentisering.

För att inte riskera att tappa nätverkspaket, ska TCP kunna användas istället för UDP vid skickande av loggdata.

Det ska finnas stöd för att t.ex. skicka Syslog med TCP-protokollet och inte bara UDP.