Et system bliver langsomt, en tjeneste svarer ikke, eller overvågningen melder noget, ingen havde ventet, og det sker midt i en testuge. I det øjeblik skal driften ikke diskutere, hvem der har ansvaret, men følge en plan, der allerede er aftalt. Planen hviler på fire skridt: opdag, vurder, stop og genopret, og notér undervejs. Den er IT-afdelingens egen og supplerer aftalen med testeren. At testen kan stoppes, og under hvilke betingelser, hører til aftalen, og køberens side af det står på penetrationtest.dk. Her handler det om, hvad driften selv gør.
Tre forklaringer på det samme symptom
Når noget opfører sig mærkeligt under en test, er der tre muligheder, og planen skal kunne håndtere dem alle.
- Testen · testerens aktivitet har påvirket et system mere end forventet.
- Almindelig drift · en fejl, en opdatering eller et backupjob, der tilfældigvis falder i testperioden.
- En rigtig hændelse · en anden end testeren er aktiv i miljøet.
Den tredje mulighed er grunden til, at et beredskab under testen ikke må være en afslappet version af det normale. Den amerikanske standardorganisation NIST skriver i sin vejledning om sikkerhedstest, at en hændelse under en test kan skyldes testerne selv eller en rigtig angriber, der tilfældigvis er aktiv samtidig, og at den, der opdager den, bør følge organisationens normale eskalering. → Alarmer under testen
Roller i planen
Planen behøver ikke mange roller, men hver rolle skal have et navn og en stedfortræder.
- Kontaktpersonen · er bindeled til testeren og kan bede om stop. → Kontaktpersonen i IT under testen
- Vagten i driften · ser symptomerne først, især uden for arbejdstid.
- Systemets ejer · afgør, hvad der skal ske med det berørte system.
- Den, der leder hændelser · overtager, hvis der er tegn på en rigtig hændelse.
- Opgavens ejer · træffer beslutning om at genoptage testen.
I en lille IT-afdeling kan flere roller ligge hos samme person. Det vigtige er, at alle ved, hvem der har hvilken, før noget sker.
Drives dele af miljøet af en driftsleverandør, skal leverandørens vagt med i planen. Den skal kende testens periode og vide, at den skal ringe til jeres kontaktperson, før den reagerer på egen hånd. Ellers kan to beredskaber gå i gang samtidig uden at kende hinanden. Saml navne, numre og roller på én side, som både vagten, servicedesken og kontaktpersonen har adgang til, også uden for arbejdstid og uden adgang til de systemer, der måske er påvirket.
Første skridt: stop aktiviteten, før årsagen findes
Når et system påvirkes, er det første at bede testeren om at stoppe aktiviteten mod det. Det sker gennem kontaktpersonen og bekræftes, så begge parter ved, at testen står stille på det område. Først derefter begynder fejlsøgningen.
Den samme vejledning anbefaler, at aktiviteterne standses, indtil en hændelse er håndteret, og at testerne først genoptager med godkendelse. Vejledningen tilføjer, at det ofte kun er aktiviteter mod de direkte berørte systemer, der standses. Det er en god tommelfingerregel for driften: stop det berørte, ikke nødvendigvis hele testen.
Bed testeren om at oplyse, hvad der blev gjort mod systemet i tiden op til symptomet. Det er den hurtigste vej til at afgøre, om testen er årsagen.
Vurdering: testen, driften eller noget andet
Sammenhold det, testeren oplyser, med det, driften ser. Passer tidspunkt, system og afsender med testens aktivitet, er testen den sandsynlige forklaring. Passer det ikke, skal de to andre muligheder undersøges.
- Tidspunkt · skete symptomet, mens testeren arbejdede på systemet?
- Afsender · kommer trafikken fra testerens aftalte adresser og konti?
- Mønster · ligner det noget, testeren har beskrevet, eller noget helt andet?
- Planlagt drift · kørte der et job, en opdatering eller en ændring på samme tid?
Er der tvivl, behandles det som en rigtig hændelse, indtil det modsatte er vist. Det er billigere at have håndteret en test som en hændelse end omvendt.
Sæt en grænse for, hvor længe vurderingen må tage, før sagen går videre til den, der leder hændelser. En vurdering, der trækker ud, fordi alle venter på testerens svar, er selv en risiko. Kan testeren ikke nås, er det i sig selv en grund til at eskalere.
Genopretning følger jeres egne procedurer
Når aktiviteten er stoppet, og årsagen er nogenlunde kendt, genopretter driften systemet på samme måde som ved enhver anden fejl. Testeren reparerer ikke og har heller ikke rettighederne til det. Er gendannelse fra backup nødvendig, træffes beslutningen af systemets ejer. → Backup og gendannelsespunkt før testen
Bevar spor, før der gendannes, hvis der er den mindste mistanke om, at en anden end testeren er involveret. En gendannelse kan slette netop det, der skulle forklare forløbet.
Genoptagelse
Testen genoptages først, når systemet kører igen, årsagen er forstået, og det er besluttet, om noget skal gøres anderledes. Vejledningens skabelon til rules of engagement har et afsnit om, hvordan testholdet genindsættes, og testen fortsættes, og det afsnit bør have en modpart i jeres egen plan. Den beslutning ligger hos opgavens ejer, ikke hos testeren eller vagten.
Overvej, om systemet skal behandles mere forsigtigt resten af perioden, eller om det skal tages ud af testen. Begge dele skal fremgå af rapporten, fordi de ændrer, hvad testen kan sige om systemet. Aftal også, hvordan den tabte testtid håndteres, så den ikke stille går fra de øvrige områder. → Skrøbelige systemer
Det skal I lade være med
- At lade planen ligge i testerens aftale alene. Driften skal have sin egen version med navne og numre.
- At begynde fejlsøgningen, mens testen kører. Stop først, så symptomerne ikke ændrer sig undervejs.
- At afskrive en alarm som testen uden at kontrollere. En rigtig angriber kan være aktiv i samme uge.
- At gendanne uden at tænke på spor. Det kan fjerne det, der skulle forklare hændelsen.
- At genoptage uden beslutning. Så kan det samme ske igen på samme system.
Hvad kan og ikke kan konkluderes
En plan, der virker i testugen, er en god indikation af, at driften kan handle på et uventet symptom, men den er ikke en øvelse af jeres beredskab. En penetrationstest er ikke bygget til at måle opdagelse og reaktion, og et roligt forløb siger ikke, at jeres hændelseshåndtering holder. Notér hver episode i driftsloggen, så den kan sammenholdes med rapporten. → Driftslog over testperioden
Tjekliste til beredskabet
- ☐ Har hver rolle et navn og en stedfortræder?
- ☐ Kender vagten testens periode, afsenderadresser og systemer?
- ☐ Ved alle, at stop kommer før fejlsøgning?
- ☐ Er det aftalt, hvem der beslutter gendannelse?
- ☐ Er der en kort vej fra testen til jeres normale hændelseshåndtering?
- ☐ Er det besluttet, hvem der godkender genoptagelse?
- ☐ Bliver hver episode skrevet i driftsloggen?
Kilder
- NIST SP 800-115: hændelser under en test kan skyldes testerne eller en rigtig angriber; aktiviteter standses, indtil hændelsen er håndteret, ofte kun mod de berørte systemer; skabelonen til rules of engagement indeholder opkaldsliste og proces for genoptagelse.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Kontaktpersonen i IT under testen · Beredskabsplanen efter testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
