Overvågning og SOC som tjeneste: hvad en test kan vise kunden om tjenesten

Sælger I overvågning eller en SOC som tjeneste, køber jeres kunder en evne til at opdage og reagere. En NIS2-kunde vil på et tidspunkt spørge, hvordan den evne er dokumenteret. En almindelig penetrationstest af jeres egne systemer svarer ikke på det spørgsmål. Svaret hviler på to forskellige ting: en test af selve tjenestens platform, som er jeres systemer, og en afprøvning af, om tjenesten opdager det, den skal, hos kunden.

Begge dele kan dokumenteres, men på hver sin måde, og ingen af dem kan love, at alt bliver opdaget. Teksten er ikke juridisk rådgivning.

Hvad kunden selv skal kunne vise

NIS 2-lovens § 6, stk. 1, nr. 2, nævner håndtering af hændelser blandt de foranstaltninger, en omfattet enhed skal have. Har kunden lagt overvågningen hos jer, er det jeres tjeneste, der bærer en del af den foranstaltning. Kunden har samtidig en frist for tidlig varsling om væsentlige hændelser efter lovens § 13, stk. 1, nr. 1, og den regnes fra det tidspunkt, hvor kunden har fået kendskab til hændelsen. Hvor hurtigt jeres tjeneste giver kunden besked, har derfor betydning for kundens egne frister, selv om det er kunden, der underretter myndigheden. → Kundens 24 timer

Gennemførelsesforordning (EU) 2024/2690, som gælder bestemte digitale udbydere, beskriver i bilagets punkt 3.2 overvågning og logning. Punkt 3.2.2 siger, at overvågning så vidt muligt automatiseres og udføres på en måde, der minimerer falske positive og falske negative resultater. Punkt 3.2.4 siger, at der ved alarmer rettidigt iværksættes en kvalificeret og passende reaktion. Kunder uden for forordningens kreds kan bruge samme sprog i deres krav til jer.

Er I selv en udbyder af administrerede sikkerhedstjenester?

NIS 2-lovens § 3, nr. 33, definerer en udbyder af administrerede sikkerhedstjenester som en udbyder af administrerede tjenester, der udfører eller yder assistance til aktiviteter vedrørende styring af cybersikkerhedsrisici. En SOC-tjeneste kan falde ind under definitionen. Er I omfattet af loven, har I egne pligter, herunder sikkerhedstest af jeres egne systemer. Vurderingen af, om I er omfattet, er en sag for sig. → Udbyder af administrerede sikkerhedstjenester

Første del: test af tjenestens platform

Jeres SOC-platform er et attraktivt mål. Den modtager logdata fra mange kunder, kan have forbindelser ind til dem og kan i nogle tjenester udføre handlinger, fx isolere en maskine. En penetrationstest af platformen kan belyse:

Adskillelse mellem kunder · kan en kundes data eller alarmer ses af en anden kunde?
Adgang til platformen · hvem kan logge ind, og hvordan er administrative konti beskyttet?
Forbindelser til kunderne · hvad kan platformens forbindelser bruges til, hvis de misbruges? → Delte platforme hos MSP’en
Handlinger hos kunden · hvem kan udløse dem, og hvordan er det sikret?

Det er en test af jeres systemer, og resultatet deles med kunderne på samme måde som en test af andre fælles systemer. Glem ikke de konti, jeres analytikere bruger. Har en analytiker adgang til alle kunders data fra samme konto, rækker en misbrugt konto lige så langt, og kunden vil vide, hvordan den adgang er beskyttet og logget.

Anden del: opdager tjenesten noget?

Kundens egentlige spørgsmål er, om tjenesten virker. Det kan belyses, når kunden alligevel får lavet en penetrationstest af sit eget miljø. Testeren fører en tidslinje over sine handlinger, og bagefter sammenlignes den med tjenestens alarmer. Sammenligningen viser, hvilke handlinger der blev set, hvilke der udløste en alarm, hvor hurtigt kunden fik besked, og hvilke der gik forbi. → Test af opdagelse

Sammenligningen er ikke en test af SOC’en alene. Den afprøver hele kæden fra kundens systemer, der skal sende logdata, over tjenestens regler for alarmer til den person hos kunden, der skal modtage beskeden. Et hul kan ligge et hvilket som helst sted i kæden, og resultatet skal derfor læses af jer og kunden sammen.

For at sammenligningen kan bruges, skal I og kunden aftale på forhånd:

Om SOC’en skal vide besked · en orienteret SOC kan ikke vise, om den selv havde opdaget testen; en uorienteret SOC kan alarmere kunden unødigt.
Hvilke kilder der er tilsluttet · tjenesten kan kun opdage det, den modtager data fra.
Hvordan alarmer skal håndteres · så en reaktion på testen ikke forstyrrer kundens drift.
Hvem der får resultatet · kunden, jer og testeren.

Grænsen til angrebssimulering

En sammenligning efter en penetrationstest giver et billede af enkeltstående handlinger. Vil kunden vide, om tjenesten og kundens egne folk opdager og stopper et sammenhængende angreb over tid, er det en anden og større øvelse, en red team- eller purple team-øvelse. Den er beskrevet for sikkerhedsfunktioner på red-teaming.dk (https://red-teaming.dk/). → Red teaming og NIS2

Et tænkt eksempel

En leverandør af SOC som tjeneste overvåger en virksomhed inden for affaldshåndtering. Kunden får lavet en intern penetrationstest og aftaler med leverandøren, at SOC’en ikke orienteres om detaljerne, men at en kontaktperson hos leverandøren kender tidsrummet og kan stoppe en eskalering. Efter testen sammenligner testeren, kunden og leverandøren tidslinjen med alarmerne. Resultatet viser, at login-aktiviteter blev set, men at en del af testerens handlinger på servere ikke gav alarmer, fordi to servere ikke sendte logdata. Leverandøren og kunden tilslutter serverne og aftaler en ny sammenligning ved næste test.

Det skal I lade være med

At svare med en test af jeres platform på et spørgsmål om opdagelse · det er to forskellige ting.
At love, at tjenesten opdager alt · ingen test kan vise det.
At lade sammenligningen ske uden aftale · så kan resultatet ikke bruges.
At glemme kilderne · manglende logdata er et fund om opsætningen, ikke om SOC’en alene.
At kalde en sammenligning efter en pentest for en red team-øvelse · det er den ikke.

Hvad kan og ikke kan konkluderes

En test af tjenestens platform kan vise, hvordan jeres systemer og adskillelsen mellem kunder modstod testen. En sammenligning af tidslinje og alarmer kan vise, hvad tjenesten så og ikke så under en bestemt test. Ingen af dem kan vise, at tjenesten opdager et virkeligt angreb, der bruger andre metoder eller sker på et andet tidspunkt. Kunden vurderer ud fra aftalen, hvad der skal til.