Opdager I et angreb? Hvad en test kan sige om logning og overvågning

En kunde, der bruger jeres system, vil ikke kun vide, om det kan angribes, men også om I opdager det, hvis nogen prøver. Spørgsmålet hører til NIS 2-lovens § 6, stk. 1, nr. 2, om håndtering af hændelser, og for visse digitale udbydere til punkt 3.2 i bilaget til gennemførelsesforordning 2024/2690 om overvågning og logning.

Kort sagt kan en almindelig penetrationstest give et første fingerpeg, hvis I bagefter sammenholder testens aktiviteter med det, jeres logning og overvågning registrerede. Et egentligt svar på, om I opdager og reagerer på et angreb, kræver en anden slags øvelse, hvor de, der overvåger, ikke ved besked på forhånd.

Hvor spørgsmålet kommer fra

Lovteksten nævner kun håndtering af hændelser. Det er lovbemærkningerne, gengivet i Styrelsen for Samfundssikkerheds vejledning om foranstaltninger fra juni 2025, afsnit 2, der siger, at enhederne i fornødent omfang skal implementere logning og overvågning af uregelmæssigheder for at kunne identificere hændelser, og at logdata skal sikres mod manipulation og uautoriseret adgang.

Forordning 2024/2690 gælder for bestemte digitale udbydere, bl.a. cloud, datacentre, udbydere af administrerede tjenester og administrerede sikkerhedstjenester. For dem kræver bilagets punkt 3.2.1 procedurer og værktøjer til at overvåge og logge aktiviteter for at opdage begivenheder, der kan være hændelser. Punkt 3.2.3 lister, hvad logfilerne hvor relevant skal omfatte, bl.a. adgang til systemer, autentificering og privilegeret adgang. Punkt 3.2.4 kræver, at logfilerne gennemgås, og at en alarm fører til en rettidig reaktion.

Hvorfor det angår jer som leverandør

Når kundens data eller drift ligger hos jer, er det jeres logning, der skal opdage et angreb på den del. Kunden har brug for at vide det hurtigt, fordi kunden selv har frister for at underrette myndighederne om væsentlige hændelser. → Kundens 24 timer

Forordningens punkt 3.3.1 nævner desuden en enkel mekanisme, så ansatte, leverandører og kunder kan indberette mistænkelige begivenheder. Kunden kan derfor også spørge, hvordan I tager imod en melding fra kunden, og hvordan I selv giver besked. → Besked om hændelser

Det, en almindelig test kan bidrage med

En penetrationstest kan være aftalt med jeres drift, så den ikke forveksles med et angreb. Den er derfor ikke en test af opdagelse. Men den efterlader spor, og de spor kan bruges:

Efterfølgende sammenligning · testeren leverer en tidslinje over sine aktiviteter, og I undersøger, hvilke af dem jeres logning registrerede.
Alarmerne · I kan se, om aktiviteter, der burde have udløst en alarm, gjorde det, og om nogen så alarmen.
Hullerne · systemer i leverancen, som slet ikke logger, bliver synlige, når der ikke findes spor fra testen.
Logfilernes beskyttelse · testen kan vise, om de adgange, den opnåede, rakte ind til logdata.

Bed testleverandøren om tidslinjen før testen, så den bliver en del af leverancen og ikke et ønske bagefter. → Bed testeren om det rigtige

Når kunden vil vide, om I reagerer

Spørger kunden, om I faktisk opdager og reagerer på et angreb, er det reaktionen, der skal afprøves. Bilagets punkt 3.5.5 siger, at procedurerne for reaktion på hændelser testes med planlagte mellemrum. Styrelsens vejledning nævner i afsnit 6.b red team-tests, der afprøver det samlede forsvar og evnen til at opdage, og blue team-aktiviteter med logovervågning og respons. ENISA’s tekniske vejledning fra juni 2025, som ikke er bindende, nævner til punkt 3.1.3 øvelser ved bordet, simulerede hændelser og red team/blue team-øvelser som måder at afprøve hændelseshåndteringen på.

Den slags øvelser er større end en penetrationstest og kræver en anden tilrettelæggelse, bl.a. en lille gruppe, der kender til øvelsen og kan stoppe den. Hvad det indebærer, er beskrevet på red-teaming.dk. Om det er det, kunden faktisk beder om, er et spørgsmål for sig. → Red teaming og NIS2

Når kunden øver sig med jer. Punkt 4.1.4 siger desuden, at driftskontinuitets- og katastrofeberedskabsplanen testes med planlagte mellemrum, og at erfaringerne indarbejdes i planerne. Er I en del af kundens beredskab, fx som driftsleverandør, kan kunden bede jer deltage i en øvelse. Det er ikke en penetrationstest, men en afprøvning af, om beskeder, kontaktpersoner og roller mellem jer og kunden virker. Aftal, hvem hos jer der deltager, om øvelsen må røre ved rigtige systemer, og hvem der får erfaringerne bagefter.

Overvågning, I køber af andre

Nogle leverandører har overvågningen hos en ekstern tjeneste. Så er det den tjeneste, der skal registrere og alarmere, og testen og den efterfølgende sammenligning skal aftales med den. Kundens spørgsmål om opdagelse besvares så af jer og tjenesten sammen. → Overvågning og SOC som tjeneste

Tjek også, hvad jeres aftale med tjenesten dækker. Overvåger den kun jeres kontornet, men ikke den platform, kunden bruger, opdager den ikke noget i det miljø, kunden spørger til. Det er bedre at skrive den begrænsning i svaret til kunden end at lade kunden gå ud fra, at alt er dækket. Aftal desuden, om tjenesten skal vide besked om testen på forhånd. Ved den besked, viser sammenligningen, hvad der blev registreret. Ved den det ikke, bliver testen et lille skridt i retning af en øvelse i reaktion, og så skal nogen kunne stoppe den, hvis den forveksles med en reel hændelse.

Et tænkt eksempel

En leverandør af et booking- og adgangssystem til en havn får spørgsmålet: Hvordan opdager leverandøren uautoriseret adgang til løsningen? Leverandøren har netop fået en penetrationstest og beder testeren om tidslinjen. Sammenligningen viser, at login med testerens konti blev registreret, men at to handlinger med administrative rettigheder ikke udløste nogen alarm. Svaret til havnen beskriver logningen, resultatet af sammenligningen og den ændring, der er sat i gang. Det siger ikke, at angreb altid bliver opdaget, og det angiver, hvilke dele af systemet sammenligningen dækkede.

Det skal I lade være med

At kalde en aftalt test for en test af opdagelse · driften vidste besked, så reaktionen er ikke afprøvet.
At bede driften slå overvågningen fra under testen uden at notere det · så kan sammenligningen ikke laves.
At glemme tidslinjen · uden den kan testens spor ikke findes i logfilerne.
At love kunden, at alle angreb opdages · ingen test kan vise det.
At udelade den eksterne overvågningstjeneste · den skal kende til testen og indgå i sammenligningen.

Hvad kan og ikke kan konkluderes

En aftalt test sammenholdt med jeres logfiler kan vise, hvilke af testens aktiviteter der blev registreret og alarmeret. Den kan ikke vise, hvordan I reagerer på et angreb, I ikke kender til på forhånd, og den siger kun noget om de systemer, testen omfattede. Teksten er ikke juridisk rådgivning.

Tjekliste til kundens spørgsmål om opdagelse

☐ Har I spurgt, om kunden vil vide, hvad der logges, eller om I reagerer?
☐ Leverer testeren en tidslinje over aktiviteterne?
☐ Er den eksterne overvågningstjeneste orienteret og med i sammenligningen?
☐ Er det aftalt, hvem hos jer der laver sammenligningen bagefter?
☐ Er huller i logningen ført ind i jeres plan for rettelser?
☐ Er svaret til kunden formuleret uden løfter om, at alt opdages?

Kilder

NIS 2-loven, lov nr. 434 af 6. maj 2025: § 6, stk. 1, nr. 2.
Gennemførelsesforordning (EU) 2024/2690: artikel 1 (hvem den gælder for) og bilagets punkt 3.2.1, 3.2.3, 3.2.4, 3.3.1 og 3.5.5.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 2 (lovbemærkningerne om logning og afsnit 2.b) og afsnit 6.b (red team-tests og blue team-aktiviteter).
ENISA, NIS2 Technical Implementation Guidance (juni 2025): vejledningen til punkt 3.1.3 om afprøvning af hændelseshåndtering. Ikke bindende.

Senest gennemgået: oktober 2026.