Hvilken rolle spiller logning i CIS-kontrollerne?

Vi sætter strøm til teorien, når vi stiller skarpt på, hvordan branchespecialister tænker it-sikkerhed. CIS-kontrollerne består af 20 praktiske og målbare kontroller, som tilsammen udgør et rammeværk for cybersikkerhed, og som har hjemme hos Center for Internet Security.

CIS-kontrollerne er nemme at anvende i praksis, fordi de kommer med direkte henvisninger til, hvordan de implementeres, og forslag til, hvilke KPI’er der bør opstilles for målinger. Det er også derfor, vi har valgt at udvikle en GAP-analyse, som bygger på selvsamme CIS-kontroller, kaldet IT-Sikkerhedsbarometeret. Over de næste måneder stiller vi derfor også skarpt på de 20 CIS-kontroller, hvordan de anvendes, og hvilke vigtige subkontroller de indeholder.

Logning og CIS-kontrollerne

Logning hjælper dig til hurtigere og mere effektivt at opdage og mitigere Indicators of Compromise (IOC) og bestemte angrebsmønstre, som beskrives i MITRE ATT&CK-databasen. Logning kan i og for sig hjælpe dig til at kunne spole tiden tilbage og dokumentere omstændighederne omkring et cyberangreb – både internt og eksternt.

Hvilke systemer logger hvad?

De fleste systemer logger noget som standardindstilling, men typisk relativt lidt, og det er derfor meget vigtigt, at du før implementeringen af et log management-system gør følgende:

1. Gennemgå alle organisationens systemer, og udvælg de systemer, som skal sende logge til log management-systemet – typisk baseret på risiko og compliance. Det vil som oftest være servere (fokus på domain controllere), databaser, webservere, antimalware/antivirus, IDS/IPS og netværksenheder som firewalls, WLC, routere, hypervisere og onlineplatforme som AWS og Azure, men dette er langt fra en udtømmende liste. Overvej også, om systemer, der ofte står i forreste række, når det gælder cyberangreb, fx arbejdsstationer og POS, skal logges. Et bestemt CIS-dokument har fokus på beskyttelse af cloudsystemer, læs mere her. 
2. Sørg for, at alle systemer har samme tidsstempel via en eller flere synkroniserede tidsservere (NTP). Ellers kan det blive meget svært at korrelere logge korrekt.
3. Sørg for, at audit-indstillinger er sat korrekt, således at hvert system og enhver enhedstype logger det, der er relevant. Der findes mange forskellige forslag til audit-indstillinger for eksempelvis domain controllere, member -ervere, IIS-servere, SQL-databaseservere og netværksenheder, som laver syslogge. Producenterne har deres egne forslag, men også tredjepartssoftware, som fx har gode input, læs mere her.
4. Vurder omfanget af de logge, der skal behandles. Det gælder både logge pr. sekund (EPS) og den samlede mængde af gemte logge. Der kan være tale om mange terabytes, afhængigt af den tid, du ønsker at gemme logge (”retention time”).

Indicators of Compromise (IOC)

Et logsystem fungerer lidt som edderkoppen i midten af et edderkoppespind. Det samler trådene fra en række udvalgte systemer, men kan kun reagere på logge, som opsamles, og derfor er det vigtigt, at de rigtige systemer sender advarsler (IOC) til logsystemet, så man kan overvåge advarsler fra mange systemet ét sted. Til gengæld kan systemet jo kun reagere på det, der sendes ind, så husk at konfigurere alle de kontrolsystemer, der kan opdage et cyberangreb, til at sende logge til log management-/SIEM-systemet (fx antimalware, application whitelisting, IPS/IDS, behaviour-systemer mv.). 

Det er log management-systemets opgave at samle alle advarsler og prioritere dem, således at de vigtigste tegn på, at noget er (eller er ved at være) galt – også kaldet Indicators of Compromise (IOC) – kan identificeres hurtigt og effektivt, så nogen kan iværksætte mitigerende tiltag. Der synes således at være en direkte sammenhæng mellem dwell time (en hackers tid til at foretage horisontal spredning/bevægelse) og succesen af et cyberangreb. Læs mere her.  

Tal fra Mandiant mTrends 2020-rapporten viser, at 31% af de kunder, som oplevede et cyberangreb, blev angrebet igen indenfor de følgende 12 måneder – både i 2019 og 2018. Dette understreger vigtigheden af at have kontinuerlig overvågning for cyberangreb og at implementere dette som en proces fremfor et projekt. 

Ved at koble CIS-kontrollerne til NIST Cyber Security Framework-funktionen opdag (”detect”) kan du se, hvilke kontroller og tiltag der i prioriteret rækkefølge er vigtigst ift. at kunne opdage en sikkerhedsbrist (find de specifikke beskrivelser af tiltag i CIS-dokumentet: (CIS-subkontroller pr. implementeringsgruppe [IGx]: 2 IG1, 27 IG2 og 7 IG3). Herunder finder du en liste over de enkelte (relevante) CIS-kontroller samt en optælling af, hvor mange subkontroller der er relevante for de forskellige implementeringsgrupper.

• CIS-kontrol nr. 3 – Sårbarhedshåndtering (3 IG2-kontroller)
• CIS-kontrol nr. 4 – Administrative rettigheder (2 IG2-kontroller)
• CIS-kontrol nr. 5 – Sikre indstillinger (1 IG2-kontrol)
• CIS-kontrol nr. 6 – Logning (1 IG1-kontrol, 6 IG2- kontroller og 1 IG3-kontrol)
• CIS-kontrol nr. 7 – Browser og e-mail (1 IG2-kontrol)
• CIS-kontrol nr. 8 – Anti-malware (1 IG1-kontrol og 3 IG2-kontroller)
• CIS-kontrol nr. 9 – Porte, protokoller og services (1 IG2-kontrol)
• CIS-kontrol nr. 11 – Sikre konfigurationer på netværk (1 IG2-kontrol)
• CIS-kontrol nr. 12 – Perimeterbeskyttelse (4 IG2-kontroller og 1 IG3-kontrol)
• CIS-kontrol nr. 13 – Datasikkerhed (1 IG3-kontrol)
• CIS-kontrol nr. 14 – Funktionsadskillelse (2 IG3-kontroller)
• CIS-kontrol nr. 15 – Wi-fi (1 IG2-kontrol)
• CIS-kontrol nr. 16 – Overvågning af rettigheder (1 IG2 og 1 IG3 kontrol)
• CIS-kontrol nr. 18 – Sikker softwareudvikling (1 IG2-kontrol)
• CIS-kontrol nr. 20 – Pentest (5 IG2-kontroller og 2 IG3-kontroller)

Da mange danske virksomheder naturligt tilhører CIS-implementeringsgruppe 2, er der således 29 subkontroller, de bør gennemgå ift. IOC til log management-/SIEM-systemet. Brug gerne listen herover og dokumentet om CIS-implementeringsgrupper til at finde nærmere oplysninger om de tiltag, der anbefales.

MITRE ATT&CK-rammeværket

De fleste cyberangreb gennemføres efter bestemte mønstre, og det er muligt at sikre, at standardmønstre kan opdages af logsystemet. Beskrivelsen af standardmønstre, som bygger på bestemte teknikker og taktikker, er beskrevet i MITRE ATT&CK-rammeværket, som er en open source-vidensdatabase for trusselsmodeller og metodikker for cyberangreb i både den private og offentlige sektor.

Databasen er opdelt i taktikker, teknikker og mitigerende tiltag, og det er isærinteressant at relatere CIS- kontrollernes forslag til mitigerende tiltag med MITRE ATT&CK-databasen. Relationen er beskrevet i Community Defence Model (CDM) her, som offentliggøres her. 

Et konkret eksempel er Privileged Account Management (PAM) (behandles i CIS-kontrol nr. 4, 14 og 16), der ligger under MITRE ATT&CK-reference M1026 her. Her beskrives 89 forskellige angrebsteknikker og de relevante mitigerende tiltag. Ved at gennemgå denne liste kan du se, om du har iværksat de relevante tiltag, og kan opdage bestemte typer af cyberangreb via logsystemet/SIEM.

Tal fra Mandiant mTrends kombineret med MITRE ATT&CK-databasen og Mandiant-angrebslivscyklus peger på, at følgende angrebsteknikker er de hyppigste:

• T1086 – Powershell 
• T1035 – Schedules Task/Job 
• T1153 – Source
• T1064 – Scripting
• T1027 – Obfuscated files and Information

Du kan læse mere om dette rammeværk her.

Fokus på specifikke CIS-kontroller

Audit-logge er grundlaget for mange CIS-subkontroller, hvoraf nedenstående er nogle af de vigtigste. Det er en god idé som udgangspunkt for implementeringen af et log management-/SIEM-system at vurdere, i hvilket omfang du ønsker at dække nedenstående CIS-kontroller.

• CIS-kontrol nr. 6 – Vedligehold, overvågning og analyse af audit-logge

 Fokuserer på opsamling og analyse af audit-logge, således at det bliver muligt hurtigt og effektivt at opdage et cyberangreb og retrospektivt dokumentere cyberangreb (og andre hændelser).

• CIS-kontrol nr. 13 – Databeskyttelse

 Er organisationens følsomme data (herunder personoplysninger af relevans for databeskyttelsesforordningen) identificeret og beskyttet tilstrækkeligt efter CIA-modellen (fortrolighed, integritet og tilgængelighed)? Dette inkluderer kontrolleret adgang, kryptering samt DLP-mekanismer (Data Loss Prevention), som kan medvirke til at forhindre og opdage en sikkerhedsbrist, der kan medføre tab af følsomme data. En rigtig god kilde til at vurdere, hvad datatab koster, er Ponemon Institutes årlige rapport, ”The Cost of a Data breach”.

• CIS-kontrol nr. 16 – Overvågning af og kontrol med konti

 Sørg for en aktiv livscyklus for alle typer konti (fx bruger-, administrative, service- og eksterne konti), herunder korrekte indstillinger af privilegier og muligheden for at opdage misbrug af administrative privilegier. Verizon DBIR anslår, at misbrug af administrative privilegier (i enhver form) udgør en central del af mange cyberangreb, og at 43% af de angrebne virksomheder er mindre virksomheder. Læs mere her og her.  

• CIS-kontrol nr. 19 – Hændelsessvar og -håndtering

 Implementer en Computer Security Incident Response Plan (CSIRP) og et Computer Security Incident Response Team (CSIRT) efter bedste praksis, hvilket sikrer tilstrækkelige ressourcer og orkestrering af hændelseshåndteringsfunktionen i virksomheden – evt. som en outsourcet funktion. Dette er et centralt punkt i overvejelserne omkring implementeringen af et log management-system/SIEM, fordi nogen jo skal forstå, vurdere og overvåge de IOC’er, som logsystemet viser.

• CIS-kontrol nr. 20 – Pentest

 En aktiv pentest (er ikke det samme som en sårbarhedsscanning) vil, hvis log management-systemet er opsat korrekt, kunne vise den form for hacking, som pentesten er et udtryk for, og give advarsler om et cyberangreb. Pentesten er således både et udtryk for, om de mitigerende tiltag er implementeret korrekt, og log management-systemets evne til at opdage og advare om de samme angreb.

CIS-kontroller kan hentes her, men fokuser også på implementeringsgrupper og på, hvordan de måles.

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