Når rapporten kommer et par uger efter testen, er det svært at huske, hvorfor en server var langsom tirsdag eftermiddag, eller hvem der godkendte en ekstra undtagelse torsdag. En driftslog over testperioden løser det. Den hviler på en enkel regel: alt, der sker i driften, og som kan hænge sammen med testen, skrives ned med tidspunkt, hvad der skete, og hvem der handlede. Loggen er IT-afdelingens egen og supplerer det, testeren selv noterer.
Hvorfor en egen log er værd at føre
Testeren fører sin egen log over aktiviteterne. Den amerikanske standardorganisation NIST skriver i sin vejledning om sikkerhedstest, at testerne bør føre en log med et trin for trin-forløb af deres aktiviteter, og at den gør det muligt for organisationen at skelne testerens handlinger fra en rigtig angribers. Testerens log viser, hvad testeren gjorde. Den viser ikke, hvad driften så, hvad brugerne mærkede, eller hvilke beslutninger der blev truffet hos jer.
Driftsloggen udfylder netop det hul. Sammen giver de to logge et billede af testperioden fra begge sider, og det er det billede, der gør det muligt at forstå både fund og hændelser bagefter.
Hvad der skal i loggen
Hold loggen til det, der kan bruges. Følgende punkter dækker det væsentlige.
- Start og stop · hvornår testeren begyndte og sluttede hver dag, og pauser, hvis de var aftalt.
- Symptomer · langsomhed, fejl, nedbrud eller usædvanlig opførsel, med tidspunkt og system.
- Alarmer · hvad overvågningen meldte, og hvad der blev konkluderet. → Alarmer under testen
- Henvendelser · sager fra servicedesken, der kan have med testen at gøre. → Servicedesken under testen
- Ændringer · ændringer i miljøet i perioden, også dem, der ikke har med testen at gøre.
- Undtagelser og konti · oprettelse, ændring og fjernelse af undtagelser og testkonti. → Midlertidige undtagelser til testen
- Beslutninger · stop, genoptagelse, udvidelse eller begrænsning af testen, og hvem der traf dem.
- Kontakt med testeren · status, spørgsmål og meldinger om alvorlige fund.
Ændringer, der ikke har med testen at gøre, hører med, fordi de kan forklare symptomer, som ellers ville blive tilskrevet testen. Et backupjob, en opdatering eller en ny regel i firewallen samme dag kan være den rigtige forklaring.
Skriv også det ned, der ikke skete. Hvis testeren meldte, at en bestemt aktivitet ville blive udført på et bestemt tidspunkt, og overvågningen var tavs, er det en oplysning, der er værd at have, når I bagefter skal vurdere, hvad jeres overvågning fanger.
Et tænkt eksempel fra en testuge
Forestil jer en intern test af kontornettet, hvor driftsleverandøren står for serverne. Onsdag formiddag melder tre brugere i økonomi, at regnskabssystemet hakker. Servicedesken registrerer sagerne med testmarkering, og kontaktpersonen skriver i loggen, at testeren arbejdede i et andet netsegment på det tidspunkt. Leverandøren noterer samme dag, at et indeks i databasen blev genopbygget planmæssigt.
Uden loggen ville episoden sandsynligvis blive husket som testens skyld. Med loggen står det klart, at forklaringen lå i driften, og at testen ikke påvirkede regnskabssystemet. Den slags afklaring sparer tid, når rapporten gennemgås, og den forhindrer, at et system fejlagtigt bliver betegnet som skrøbeligt. → Skrøbelige systemer
Form: enkel og fælles
Loggen behøver ikke et særligt system. Et fælles dokument eller en sag i jeres opgavesystem, som alle relevante kan skrive i, er nok. Det vigtige er, at alle bruger den samme.
- Én log for hele testen · ikke en for hver person eller afdeling.
- Tidspunkt på hver linje · med dato og klokkeslæt.
- Navn på hver linje · så det er tydeligt, hvem der har set eller gjort noget.
- Kort tekst · en eller to sætninger. Detaljer kan ligge i den sag eller den alarm, linjen henviser til.
- Adgang begrænset · loggen kan indeholde oplysninger om svagheder og bør behandles fortroligt.
Udpeg én ejer af loggen, fx kontaktpersonen. Ejeren sørger for, at den bliver ført, og at det, der kommer ind via telefon eller chat, også bliver skrevet ned. → Kontaktpersonen i IT under testen
Kommer der en driftsleverandør ind i billedet, skal leverandøren enten skrive i den samme log eller sende sine notater til ejeren dagligt. Ellers mangler halvdelen af billedet, når loggen skal bruges. Det samme gælder systemejere i andre afdelinger, der administrerer deres egne forretningssystemer. Giv dem en nem måde at melde ind på, fx en fast mailadresse eller en kanal, som ejeren af loggen holder øje med.
Når loggen skal bruges
Loggen har tre anvendelser efter testen.
- Læsning af rapporten · når et fund nævner et tidspunkt, kan I se, hvad driften så samtidig.
- Afklaring af hændelser · hvis noget i perioden ikke kan forklares af testen, er loggen udgangspunktet for at undersøge det.
- Læring · hvilke alarmer kom, hvilke kom ikke, hvor lang tid tog det at reagere, og hvor gik kommunikationen trægt. → Læring for driften efter testen
Bed testeren om at sammenholde tidspunkter, hvis der er episoder, der ikke kan forklares. Testerens aktivitetslog og jeres driftslog kan tilsammen vise, om en episode skyldtes testen eller noget andet. Hvis testerens log ikke kan dække et tidspunkt, hvor driften så aktivitet, er det et spørgsmål, der skal undersøges, ikke afskrives.
Gem loggen sammen med rapporten
Når testen er afsluttet, arkiveres loggen sammen med rapporten og den liste over undtagelser og konti, der blev brugt. Næste gang en test planlægges, er loggen et godt sted at begynde: den viser, hvor testen påvirkede driften, og hvor forberedelsen kan forbedres.
Loggen kan også bruges som dokumentation for, at testen blev gennemført efter aftalen, fx hvis nogen senere spørger, hvorfor et system var nede, eller hvem der godkendte en ændring. → Logning efter testen
Det skal I lade være med
- At skrive loggen bagefter. Hukommelsen er upræcis efter få dage.
- At notere kun det, der gik galt. Rolige dage og planlagte ændringer giver også sammenhæng.
- At lade loggen være åben for alle. Den kan beskrive svagheder.
- At føre flere logge side om side. Saml det i én.
- At glemme leverandørens notater. De hører med.
Hvad kan og ikke kan konkluderes
En grundig driftslog gør det lettere at forstå rapporten og at skelne testen fra andre hændelser i perioden. Den er ikke en sikkerhedslog og erstatter ikke den logning, systemerne selv foretager. Den siger heller ikke noget om, hvor godt jeres overvågning opdager angreb. Den viser, hvad driften lagde mærke til og gjorde, og det er netop det, ingen anden kilde om testperioden kan vise.
Tjekliste til driftsloggen
- ☐ Er der én fælles log med en ejer?
- ☐ Har hver linje tidspunkt og navn?
- ☐ Kommer start, stop, symptomer, alarmer og beslutninger med?
- ☐ Bliver ændringer uden for testen også noteret?
- ☐ Er adgangen til loggen begrænset?
- ☐ Er loggen gemt sammen med rapporten?
Kilder
- NIST SP 800-115: testerne bør føre en log over deres aktiviteter trin for trin, så organisationen kan skelne testerens handlinger fra en rigtig angribers.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Beredskab under testen · Daglig status under testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
