20 gode råd om implementering af Log Management

Du læser måske producenternes lovprisning af deres egne løsninger og har muligvis hørt om mange forskellige termer, buzz-ord og begreber. Men det kan godt være svært at finde rundt i junglen, når det kommer til, hvilke tiltag og prioriteringer der er vigtigst at gennemtænke, før du implementerer et log management-/SIEM-system – eller skal rette op på en knap så vellykket igangværende implementering.

Nedenfor er pragmatiske gode råd, som vi har lagt i vores Cybersnack til webinaret om log management og SIEM, der afholdes den 21. januar kl. 10-11.30. Læs mere om webinaret og tilmeld dig her.

1. Hvorfor vil du implementere systemet?
   Hvis du ikke ved præcist, hvorfor der er brug for et log-/SIEM-system, er der næsten en garanti for, at det ikke bliver en vellykket implementering.
   
2. Har tiltaget ledelsens opbakning i form af de nødvendige ressourcer?
   At implementere et log-/SIEM-system kræver så mange ressourcer, at disse næsten aldrig er til stede i it-afdelingen uden at være tildelt specifikt til formålet af ledelsen.
   
3. Skal det være et log management-/SIEM-system, eller kan du nøjes med audit-systemer?
   Nogle opgaver løses mindst lige så godt af et audit-system som er billigere, nemmere og hurtigere at implementere. Måske behøver organisationen heller ikke et SIEM-system, men kan nøjes med et log management-system, der er billigere og hurtigere at implementere.
   
4. Vil det være en fordel at implementere log management først og SIEM efterfølgende?
   At dele implementeringen op i to trin giver en større succesrate og et bedre fundament for SIEM.
   
5. Skal det være en on-prem eller en cloudplatform?
   Har virksomheden interne ressourcer til at implementere og drifte et SIEM-system.
   
6. Hvilken form for licens ønskes (eje/leje)?
   Da der ofte er tale om en større investering, typisk med en 5-årig horisont, er dette et vigtigt spørgsmål at få afklaret. Det er muligt at skifte fra en leje- til en ejelicens, men ikke omvendt.
   
7. Hvem skal implementere og navnlig vedligeholde og udvikle systemet?
   Der skal ligge en plan for de roller og personer, som skal implementere, drifte og udvide systemet. Har organisationen ikke de nødvendige ressourcer, skal dette outsources. Husk, at et logsystem, som ikke vedligeholdes, regelmæssigt ”sander til” med garanti.
   
8. Hvor kommer supporten til systemet fra?
   Kommer supporten fra USA i en anden tidszone direkte fra producenten eller fra en lokal partner?
   
9. Hvilke enheder/systemer skal vi logge fra?
   Dette skal fastlægges på forhånd, da det vil medvirke til at dimensionere log-/SIEM-systemet til det rigtige antal EPS og data storage til data retention. Kan systemet skalere til det ønskede antal EPS?
   
10. Hvem laver parserne til logge, der ikke forstås af systemet pr. default?
    Når ukendte systemer skal logge, kræver det en ny parser skrevet i RegEx og nye korrelationsregler. Det kan være kompliceret at skrive disse, og derfor er det en fordel, hvis de håndteres af producenten og/eller outsourcingpartneren. Og hvem skal betale for disse, eller er de gratis?
    
11. Hvad er den ønskede retention på disse logge?
    Længere retentiontid kræver større diskplads – her er ofte tale om terabytes.
    
12. Hvad er den ønskede søgetid på logge?
    Fungerer indeksering tilstrækkeligt til, at logge kan søges frem på den ønskede tid? Der er typisk tale om rene I/O-operationer, så det kræver store mængder af hurtig (SSD?) disk. Der er typisk tale om en del logge, som ikke er komprimerede, og som derfor kan gennemsøges hurtigt, men resten ligger komprimeret og er derfor langsommere at søge i.
    
13. Hvis systemet er fordelt på flere servere (oftest on-prem), skal man så kunne søge på tværs af alle servere?
    Kan man søge efter logge på tværs af hele log-/SIEM-infrastrukturen fra et samlet interface?
    
14. Hvilke use-cases skal vi implementere og efterprøve?
    Bestem dig for, hvilke use-cases systemet som minimum skal kunne håndtere, og test disse. Ofte med udgangspunkt i angrebsmønstre defineret i MITRE ATT&CK-databasen.
    
15. Hvem skal bruge log management-systemet?
    Resultatet af log-/SIEM-systemet kan vises for specifikke teknikere, men bør også gøres tilgængeligt for andre funktioner i virksomheden som fx servicedesk og compliance-teamet.
    
16. Hvem skal overvåge log management-systemet?
    Det hjælper ikke, at logsystemer udpeger en vigtig IOC, hvis der ikke er ressourcer til at mitigere problemet – typisk 24/7/365. Dette kan med fordel outsources, selvom systemet driftes internt i virksomheden.
    
17. Sæt præcise mål og milepæle for at kunne måle, at implementeringen skrider frem efter tidsplanen.
    Uden målbare milepæle er der risiko for, at projektet kører af sporet og aldrig bliver helt færdigt. Der kan også diskuteres om noget egentlig er færdigimplementeret med en ekstern leverandør.
    
18. Implementer på baggrund af log management og derefter på de use-cases, som testes.
    Få først log management til at virke gnidningsfrit, og implementer derefter SIEM og use-cases. De bygger på log management, og virker det ikke, så virker SIEM-systemet heller ikke.
    
19. Beslut, hvilke hændelser organisationen vil fokusere særligt på i form af rapporter, dashboards og alarmer.
    Definer disse på forhånd, så de bliver implementeret efter ønsker og behov og ikke efter producentens standard.
    
20. Overvej, om hændelser skal håndteres i log management-/SIEM-systemet eller sendes videre til et ITSM-system.
    Et ITSM-system er ofte bedre indarbejdet i organisationens workflows og derfor bedre til at håndtere denne opgave – især hvis der skal koordineres mellem forskellige teams.

Hovedårsager til, at et log management-projekt fejler

Der kan være mange årsager til, at et log management- og måske især et SIEM-projekt aldrig bliver den ønskede succes eller ligefrem fejler. Nedenstående ses i ikke-prioriteret rækkefølge nogle triste, men typiske eksempler. Idéen med at nævne dem her er at fokusere på dem som noget, der specifikt skal undgås:

• Det er ikke på forhånd afklaret, hvorfor organisationen skal have et log management-/SIEM-system.
  Derfor er der ikke et projekt med et klart mål, og derfor fejler projektet.
  
• Projektet har ikke ledelsens fulde opbakning/forståelse/ejerskab/sponsorship.
  Derfor tildeles projektet ikke de nødvendige ressourcer i form af budget og medarbejdere.
  
• Der er ikke afsat de nødvendige ressourcer i form af budget, manpower og hardware (on-prem).
  Projektet kan ikke gennemføres pga. manglende ressourcer.
  
• Der er ikke fastlagt målbare milepæle for implementeringen.
  Det er uvidst, hvornår projektets delmål bliver nået, og derfor kan fremskridt ikke med sikkerhed måles.
  
• KPI, der dokumenterer systemets effektivitet, er ikke en del af ledelseskommunikationen.
  Projektet har ikke ledelsens bevågenhed, fordi det lever som en teknisk del af it-afdelingen.
  
• Valg af forkert log management-/SIEM-system
  Systemet er ofte for avanceret, og derfor har organisationen ikke interne ressourcer til at implementere det effektivt.
  
• Implementering af SIEM som første mål uden log management som første trin og derefter SIEM
  Da SIEM bygger på effektiv log management, er det en forudsætning for, at SIEM-systemet kommer til at fungere. Det kan være for meget at ”gabe” over SIEM fra starten, og derfor fejler projektet.
  
• Utilstrækkelige interne ressourcer til at overvåge log management-/SIEM-systemet.
  Systemet fungerer udmærket med de hændelser/IOC’er, som systemet bringer frem, men de bliver ikke varetaget pga. manglende interne ressourcer til at håndtere opgaven. Derfor sander systemet til.

Få svar på de mange spørgsmål om log management og SIEM på vores webinar, som afholdes den 21. januar kl. 10-11.30. Læs mere og tilmeld dig her.