CIS kontrollerne giver dig svar på de grundlæggende IR tiltag

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.

IR er kun så effektivt som de indikatorer, der føder IR med Indicators of Compromise (IOC) og Taktikker, Teknikker og Procedurer (TTP) fra MITRE ATT&CK-databasen. Så før du starter med at tænke på IR, er det en god idé at gøre følgende:

1. Sørg for, at data fra dine antimalwaresystemer opsamles og sendes til et centralt log- og alarmeringssystem. Det kan fx være data fra antimalware (CIS-kontrol nr. 8), data fra din firewall (CIS-kontrol nr. 13) og dit Intrusion Detection/Prevention System (IPS/HIPS) (CIS-kontrol nr. 12).
2. Hvis systemerne afgiver alarmer, skal disse alarmer opsamles og håndteres centralt (se fx ManageEngine Alarmsone). Det nytter ikke, at der er for mange og ukorrekte alarmer (”støj”), eller at der ikke er en robust proces, som sørger for, at alarmerne håndteres rettidigt.
3. Hvis du har forebyggende systemer, så sørg for at sætte dem i ”beskyttelsestilstand”. Det er ingen reel beskyttelse, hvis du har dem i ”opdag, men reager ikke"-tilstand.
4. Vi har tidligere lavet en video med en gennemgang af, hvilke IOC’er der er vigtige, og denne video kan du finde på vores webinarportal under Trykpøvning og SIEM.

CIS-kontrol nr. 19 omhandler Incident Response, og i denne kontrol er der kun tiltag fra implementeringsgruppe 1 og 2, hvilket betyder, at stort set alle virksomheder skal efterleve alle tiltag fra CIS-kontrol nr. 19. Kontrollerne kan oversættes til følgende:

Grundlæggende tiltag

1. Sørg for at have en indøvet IR-plan (kaldet Computer Security Incident Response Plan/ Team – CSIRP og CSIRT). Dette er ikke det samme som en beredskabsplan, da det fx i CSIRP er vigtigt, at du har beviset for, hvad der udløste angrebet. Denne sårbarhed skal mitigeres, for at sikre, at virksomheden ikke bliver offer for samme type angreb, så snart systemet sættes tilbage i drift. Dette tiltag går forud for genetablering af normal drift.
2. Sørg for at have de rette ressourcer til IR-processen – både hos ledelsen og de udførende medarbejdere. Ledelsen kan med fordel læse ”Cybersikkerhed for bestyrelser”, og udførende medarbejdere kan med fordel søge inspiration i Incident Response Playbooks. Udarbejdelsen af CSIRP og CSIRP er nærmere beskrevet i ”Computer Security Incident Handling Guide” og i SANS’ ”Incident Handlers Handbook”, men det kan være svært at omsætte anbefalingerne fra disse dokumenter i praksis. Red Canary har også en udmærket vejledning, som er ganske teknisk, men meget værdifuld.
3. Sørg for at samle informationen om tredjepart i en særskilt dokumentation, og hav både CSIRP og CSIRT offline og gerne på tryk.
4. Sørg for at inkludere processen omkring IR i awareness-programmet for hele organisationen, så alle ved, hvordan de skal reagere i tilfælde af en cyber-hændelse.

Yderligere tiltag (implementeringsgruppe 2)

1. Sørg for, at jobtitler og ansvar matcher de medarbejdere, der skal deltage i IR.
2. Indfør en SLA for den maksimale tid, det skal tage at indberette en cyberhændelse til IR-teamet. Gør denne indberetning standardiseret og robust, så den indeholder de nødvendige oplysninger, som gør IR mulig og effektiv. Det kan fx være brugerkonto, ip-adresse, observation, tidsstempel, screenshot, allerede indførte tiltag osv.
3. Gennemfør IR-øvelser, og opdater IR-planerne med erfaringerne fra disse øvelser – det svarer til at sætte redningsbåde i vandet og observere, hvordan det går.
4. Indfør et scoringssystem, som gør det muligt at måle effektiviteten af IR over tid, så en forbedrings-/læringsproces kan tilsikres.

Blandt de mange observationer jeg har gjort mig ved interaktion med kunder, hvor IR kommer på tale, har jeg observeret følgende som værende de største faldgruber:

1. Der er ikke afsat tilstrækkeligt med manpower til at håndtere alarmer, som derfor håndteres for sent eller slet ikke.
2. Alarmerne er ikke centraliseret og tunet, og indeholder derfor for meget støj til egentligt at kunne bruges i praksis.
3. En CSIRP forveksles med en beredskabsplan og indeholder derfor ikke den nødvendige information til at sikre et robust IR.
4. ”IR-planen” er ikke specifik og kan derfor ikke bruges i praksis ved en større cyber-hændelse.
5. ”IR-planen” er ikke indøvet i praksis, men forbliver et skuffedokument uden den nødvendige revisions cyklus. Den er derfor heller ikke ledelsespåtegnet, hvilket gør IR til en opgave der udelukkende er forankret i IT.

Overvej at få outsourcet IR og SOC til en tredje part der har ekspertisen og manpower til at håndtere dette rigtigt og effektivt. Kontakt gerne Christian Schmidt, hvis du gerne vil vide hvad vi kan tilbyde i relation til IR og SOC.

CIS-anbefaling af målinger til IR kan du finde i dokumentet ”Measures and Metrics”, og her er der tale om Ja-/Nej-kontroller i Sigma Level 4.

Vil du høre mere om, hvordan Deloitte kan hjælpe dig med SOC-funktionen, så er du velkommen til at kontakte Christian Schmidt på mail eller telefon: +45 3093 6009. Se evt. mere på vores hjemmeside.