Beskyttelsesprogrammet på klienter og servere kan være det første, IT-afdelingen spørger til, når rapporten kommer: blev testeren stoppet? Både et ja og et nej kan let blive læst forkert. Et ja kan blive taget som bevis på, at beskyttelsen er god nok, og et nej som bevis på, at den ikke duer. Svaret hviler på, hvad testen var bygget til at måle. En penetrationstest leder efter svagheder i opsætning og adgang, ikke efter grænserne for et bestemt beskyttelsesprodukt, og resultatet skal læses i det lys.
Hvad endpoint-beskyttelse dækker
Ordet bruges om flere ting, og det er en hjælp at skelne, når resultatet skal forstås.
- Forebyggelse · programmer, der blokerer kendt skadelig kode og mistænkelig adfærd, før den når at gøre skade.
- Opdagelse · registrering af hændelser på maskinen, som sendes videre til en central konsol.
- Undersøgelse og reaktion · værktøjer til, at nogen kan se, hvad der skete, og isolere en maskine.
Microsoft beskriver fx sin platform til formålet som en hjælp til at forebygge, opdage, undersøge og reagere. Forebyggelse og registrering kan beskyttelsen klare selv. Undersøgelse og reaktion kræver, at der sidder nogen og kigger. En test kan berøre alle tre dele, men den måler dem ikke lige godt.
Før testen: beslut, hvad beskyttelsen skal gøre
Den vigtigste beslutning træffes før testen: skal beskyttelsen være slået til som i daglig drift, eller skal testeren undtages?
- Slået til · resultatet viser, hvad en angriber ville møde, men testeren kan bruge tid på at blive stoppet og nå mindre af resten.
- Undtaget for testeren · testen når længere ind i opsætningen og rettighederne, men siger intet om beskyttelsen.
- Delt op · en del af testen uden undtagelse og en del med, aftalt på forhånd.
Valget skal stå i aftalen, og en undtagelse skal være smal, tidsbegrænset og fjernes bagefter. → Midlertidige undtagelser under testen
Afklar også, hvem der ser alarmerne. Har I en ekstern overvågning, skal den vide, at testen foregår, og I skal aftale, hvordan den reagerer. Ellers kan en isoleret maskine stoppe testen midt i et forløb. → Alarmer under testen
Når testeren blev stoppet
At beskyttelsen reagerede er en god oplysning, men den skal læses præcist.
- Hvad blev stoppet · var det et bestemt program, en bestemt handling eller et forsøg på at nå et bestemt sted? Rapporten bør sige det.
- Hvad skete der bagefter · blev aktiviteten kun blokeret, eller blev den også opdaget og fulgt op af nogen?
- Hvad kunne ikke testes · blev testeren stoppet tidligt, er resten af opsætningen ikke undersøgt. Fravær af fund betyder så kun, at testen ikke nåede længere.
Det sidste punkt er vigtigt. Spørg testeren, hvad der ville have været undersøgt, hvis blokeringen ikke var sket, og overvej, om den del skal tages med undtagelse i en senere runde.
En rapport med få fund og en bemærkning om, at testeren blev blokeret, siger mere om beskyttelsen end om de svagheder, der kan ligge bagved. Hvis rettighederne bag beskyttelsen er for brede, står de tilbage den dag, beskyttelsen fejler eller bliver omgået.
Når testeren ikke blev stoppet
At beskyttelsen ikke reagerede, er heller ikke entydigt. Der kan være flere forklaringer.
- Undtagelsen virkede · testeren var undtaget, og der var ikke noget at reagere på.
- Aktiviteten lignede almindelig administration · meget af det, en tester gør, er handlinger, som administratorer også udfører. Det er ikke altid noget, et beskyttelsesprogram skal stoppe.
- Dækningen havde huller · nogle maskiner havde ikke beskyttelsen installeret, eller den var sat til kun at registrere.
- Opdaget, men ikke fulgt op · hændelsen blev registreret, men ingen så den.
De to sidste forklaringer er de egentlige fund. For en MSP, der driver beskyttelsen hos flere kunder, er de også et spørgsmål om, hvorvidt samme hul findes i den fælles opsætning, og om alarmer fra kunderne faktisk når frem til nogen, der reagerer. Bed testeren om at oplyse tidspunkterne for væsentlige handlinger, så I bagefter kan sammenholde dem med jeres egne logfiler. → Log over testperioden
Hvad resultatet kan bruges til
NCSC beskriver penetrationstest som en måde at få sikkerhed for, at jeres egne processer for sårbarheder virker. Testere kan godt have som mål at vurdere opdagelse og reaktion, men det kræver, at testen er bygget til det. En almindelig penetrationstest kan derfor give nogle indikationer om beskyttelsen.
- Dækning · fundne maskiner uden beskyttelse eller med beskyttelse i en svagere tilstand end planlagt.
- Opsætning · undtagelser i beskyttelsen, som er bredere end nødvendigt.
- Afhængighed · fund, hvor beskyttelsen var det eneste, der stod mellem testeren og et vigtigt mål.
Spørgsmålet om, hvor godt jeres samlede opdagelse og reaktion virker, kræver en anden type øvelse, hvor netop det er formålet. Den er beskrevet på red-teaming.dk. → Opdagelse og reaktion som spørgsmål
Sådan retter I på begrebsniveau
Rettelser efter et resultat om beskyttelsen handler ikke nødvendigvis om at skifte produkt. De kan handle om dækning, undtagelser og om, hvem der følger op.
- Luk dækningshullerne · alle klienter og servere, der skal have beskyttelse, har den, og den står i den tilstand, I har besluttet.
- Stram undtagelserne · mapper, programmer og maskiner, der er undtaget, gennemgås og begrænses.
- Gør opfølgningen tydelig · nogen skal have ansvaret for at se og reagere på alarmer, også uden for arbejdstid, hvis det er aftalen.
- Ret det bagved · fund om rettigheder og opsætning rettes, uanset om beskyttelsen stoppede testeren. → Klienttest for IT-afdelingen
Det skal I lade være med
- At læse et stop som en godkendelse. Det, der lå bag beskyttelsen, blev måske aldrig testet.
- At læse et manglende stop som en dom over produktet. Der kan være flere forklaringer.
- At slå beskyttelsen fra uden at skrive det i aftalen. Så ved ingen bagefter, hvad resultatet gælder.
- At glemme at fjerne undtagelser. En undtagelse for testeren må ikke blive stående.
- At sætte lighedstegn mellem registreret og opdaget. En hændelse, ingen så, var ikke opdaget.
Hvad kan og ikke kan konkluderes
Testen kan vise, om beskyttelsen reagerede på det, testeren gjorde, og om der var huller i dækning og opsætning på de maskiner, der var med. Den kan ikke vise, hvordan beskyttelsen vil reagere på andre metoder eller på en anden dag. Den kan heller ikke alene måle, hvor hurtigt jeres organisation reagerer.
Tjekliste til beskyttelsen og testen
- ☐ Er det besluttet og skrevet, om beskyttelsen er slået til eller undtaget?
- ☐ Ved overvågningen, at testen foregår, og hvordan den skal reagere?
- ☐ Har testeren lovet at oplyse tidspunkter for væsentlige handlinger?
- ☐ Er det kontrolleret, at alle relevante maskiner har beskyttelsen?
- ☐ Er undtagelser for testeren fjernet efter testen?
Kilder
- Microsoft Learn: Microsoft Defender for Endpoint: eksempel på en platform til endpoint-beskyttelse, beskrevet som hjælp til at forebygge, opdage, undersøge og reagere på trusler.
- NCSC: Penetration testing: penetrationstest som sikkerhed for egne processer for sårbarheder; scenariebaserede test kan også have til formål at vurdere opdagelse og reaktion.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Alarmer under testen · Driftsmonitorering under testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
