Overvågningen slår ud på en mistænkelig login eller trafik mod en server, og det sker i den uge, hvor testeren arbejder i miljøet. Det nærliggende svar er, at det må være testen, men det er netop den antagelse, en rigtig angriber vil have glæde af. At skelne de to hviler på tre ting: kendetegn, som er aftalt før testen, en bekræftelse fra testeren ad en kendt kanal, og en regel om, at alt, der ikke kan bekræftes, behandles som en rigtig hændelse. Den amerikanske standardorganisation NIST anbefaler i sin vejledning om sikkerhedstest, at testerens afsenderadresser står i planen, netop så administratorer kan skelne testen fra ondsindet aktivitet.
Kendetegn, der aftales før testen
En alarm kan kun sammenholdes med testen, hvis driften ved, hvordan testen ser ud. Saml kendetegnene på én side, som overvågningen og vagten har adgang til.
- Afsendere · de adresser og enheder, testeren arbejder fra, både udefra og indefra.
- Konti · testkontiene med navn og de roller, de har fået.
- Tidsrum · testperioden og de tidspunkter på døgnet, testeren arbejder.
- Systemer · de systemer og segmenter, testen dækker.
- Kontakt · testerens telefonnummer og IT’s kontaktperson.
Kendetegnene er et udgangspunkt, ikke et bevis. En alarm, der passer på alle fem punkter, er sandsynligvis testen. En alarm, der kun passer på ét eller to, kræver en nærmere kontrol.
Overvåges miljøet af en ekstern SOC eller af driftsleverandøren, skal kendetegnene også derhen, og det skal være aftalt, hvem de ringer til. En ekstern overvågning har sine egne regler for, hvornår den blokerer, eskalerer eller underretter andre, og de regler gælder også i testugen, medmindre andet er aftalt. Opdatér siden, hvis testeren skifter adresse eller får en ny konto undervejs, og send ændringen samme vej som den første udgave.
Hvorfor kendetegn ikke er nok alene
En angriber, der er i miljøet, ved ikke nødvendigvis, at der er en test i gang, men kan lige så godt være aktiv i samme uge. Aktivitet på de samme systemer og i det samme tidsrum kan derfor have to kilder samtidig. Hertil kommer, at en testkonto er en rigtig konto, og hvis den bliver misbrugt, ligner aktiviteten testerens. Testkonti med brede rettigheder er derfor værd at holde ekstra øje med i hele perioden, og de skal lukkes, så snart testen er slut.
Vejledningen beskriver begge muligheder: en hændelse under en test kan skyldes testerne eller en rigtig angriber, og den, der opdager hændelsen, bør følge organisationens normale eskalering. Driftens opgave er derfor ikke at afgøre, at det er testen, men at få det bekræftet.
Bekræftelse fra testeren
Når en alarm ser ud til at stamme fra testen, kontakter overvågningen eller vagten IT’s kontaktperson, som spørger testeren. Spørgsmålet er konkret: arbejdede I på dette system, fra denne adresse, med denne konto, på dette tidspunkt? → Kontaktpersonen i IT under testen
- Ja, og det passer · alarmen noteres som testaktivitet, og sagen lukkes med en henvisning til testen.
- Ja, men noget passer ikke · fx en anden konto eller et andet system end det aftalte. Testeren stopper aktiviteten, indtil det er afklaret.
- Nej · alarmen behandles som en rigtig hændelse, og testen mod de berørte systemer stopper.
- Intet svar · alarmen behandles som en rigtig hændelse, indtil testeren kan bekræfte.
Kontakten skal gå ad den kanal, der står i aftalen. Et svar fra en ukendt adresse eller et nummer, der ikke står på listen, er ikke en bekræftelse. Notér i alle fire tilfælde, hvornår alarmen kom, hvornår testeren blev spurgt, og hvad svaret var. Tidspunkterne bliver nyttige, når forløbet senere skal sammenholdes med rapporten, og de viser, hvor lang tid en afklaring faktisk tager.
Når svaret er nej
Bekræfter testeren ikke aktiviteten, overgår sagen til jeres normale hændelseshåndtering med det samme. Testen mod de berørte systemer stopper, så testerens aktivitet ikke blander sig med den, der skal undersøges. Den anbefaler også, at testerne stopper arbejdet mod systemerne i en hændelse, mens organisationen reagerer. → Beredskab under testen
Testeren kan stadig være til nytte. Spørg, om testeren har set noget, der kan hjælpe undersøgelsen, fx spor efter en anden aktør eller ændringer, der ikke var testerens. Det skal ske efter jeres hændelsesplan og ikke ved, at testeren begynder at undersøge på egen hånd.
Uanmeldte test og en orienteret kerne
Er testen aftalt uden at overvågningen er orienteret, fordi det skal vise, hvad den opdager, gælder de samme regler, men med en mindre kreds. Nogen skal kende testen og kunne bekræfte den hurtigt, ellers kan en alarm sætte et fuldt beredskab i gang eller føre til, at eksterne parter bliver underrettet. Den kreds skal være kendt af den, der leder hændelser. Hvis formålet er at måle opdagelse og reaktion, er det en anden type opgave, og den behandles på red-teaming.dk. → Opdagelse og reaktion
Alarmerne er også et resultat
Hver alarm, der blev udløst af testen, er en oplysning om, hvad jeres overvågning kan se. Hver aktivitet, der ikke gav en alarm, er det også. Gem alarmerne fra testperioden, og notér, hvordan de blev håndteret. Når rapporten kommer med testerens tidslinje, kan de to holdes op mod hinanden. → Logning under den interne test
Sammenligningen viser ikke, hvor godt jeres beredskab virker, men den kan vise, hvor overvågningen har blinde punkter, og hvor håndteringen af en alarm tog lang tid.
Det skal I lade være med
- At lukke en alarm som testen uden at spørge. Bekræftelsen er hele pointen.
- At slå overvågningen fra i testperioden. Så kan en rigtig angriber arbejde i ly af testen.
- At acceptere en bekræftelse ad en ukendt kanal. En angriber kan også ringe og sige, at det er testen.
- At lade testeren undersøge en hændelse på egen hånd. Hændelser følger jeres egen plan.
- At slette alarmerne efter testen. De er en del af resultatet.
Hvad kan og ikke kan konkluderes
En alarm, der passer på kendetegnene og er bekræftet af testeren, er med stor sandsynlighed testen. Det udelukker ikke, at anden aktivitet har fundet sted i samme periode. At testen gav få alarmer, siger heller ikke i sig selv, at overvågningen er dårlig. Det afhænger af, hvad testen var bygget til, og om dele af overvågningen var undtaget. → Midlertidige undtagelser til testen
Tjekliste til alarmer i testperioden
- ☐ Har overvågningen og vagten testens kendetegn på én side?
- ☐ Er der en aftalt kanal til at få testeren til at bekræfte?
- ☐ Ved alle, at manglende svar betyder rigtig hændelse?
- ☐ Er det aftalt, hvem der stopper testen ved en mistanke?
- ☐ Er der en orienteret kerne, hvis overvågningen ikke er orienteret?
- ☐ Gemmes alarmerne fra testperioden?
Kilder
- NIST SP 800-115: afsenderadresser i planen, så testen kan skelnes fra angreb; hændelser under test kan skyldes testere eller en rigtig angriber; normal eskalering, og testerne stopper arbejdet mod berørte systemer; regler for uanmeldte test.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Servicedesken under testen · Testkonti under opsyn
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
