Rules of engagement: spillereglerne for testen forklaret

Udtrykket rules of engagement dukker op i tilbud og aftaler om penetrationstest, ofte uden forklaring. Det betegner det dokument, der fastlægger, hvad testeren må gøre, hvornår, fra hvilket udgangspunkt, og hvad der sker, hvis noget går anderledes end planlagt.

Dokumentet er bindeleddet mellem den kommercielle aftale og selve arbejdet. Kontrakten handler om leverance, pris og ansvar. Opgavebeskrivelsen handler om formål og omfang. Spillereglerne handler om udførelsen: de konkrete grænser og aftaler, som testeren skal kunne slå op i, mens arbejdet står på, og som virksomheden skal kunne henvise til bagefter.

Hvorfor spillereglerne skal stå på skrift

En penetrationstest indebærer handlinger, der uden tilladelse ville være ulovlige. Den skriftlige ramme er det, der gør arbejdet til en aftalt opgave. Den beskytter virksomheden, fordi grænserne er tydelige. Den beskytter testeren, fordi handlinger inden for rammen er dokumenteret godkendt. → Er en penetrationstest lovlig?

Skriftligheden gør det også muligt at afgøre tvivl. Hvis driftsleverandøren ser usædvanlig trafik en aften, kan dokumentet vise, om testen måtte foregå på det tidspunkt. Hvis en server går ned, kan det vise, hvad der var aftalt om den slags handlinger. Uden dokumentet bliver den slags spørgsmål til en diskussion om, hvad der blev sagt i et møde.

NIST SP 800-115 nævner rules of engagement som en del af planlægningen og indeholder et eksempel på, hvilke emner sådan et dokument kan dække. Eksemplet er en hjælp, ikke en fast skabelon, som alle opgaver skal følge.

Navnet varierer. Nogle leverandører kalder dokumentet testplan, testaftale eller bilag om udførelse. Det er indholdet, der tæller. Spørg, hvor de praktiske grænser står, hvis I ikke kan finde et afsnit med overskriften rules of engagement.

Giv dokumentet et versionsnummer og en dato. Ændres testperioden, eller kommer et system til, skal en ny version godkendes. Så kan begge parter altid se, hvilke regler der gjaldt på et bestemt tidspunkt. Det gør det også lettere for den, der senere læser rapporten, at forstå, hvorfor en del af kundeportalen blev testet en anden dag end resten.

Det bør dokumentet indeholde

Indholdet afhænger af opgaven, men visse emner går igen. Brug listen som et tjek af det udkast, I modtager.

Parter og godkendelse · hvem der bestiller, hvem der udfører, og hvem der har ret til at godkende test af de enkelte systemer.
Omfang · de systemer, adresser, funktioner og roller, der er med, og de dele, der udtrykkeligt er udelukket. → Scope i en penetrationstest
Udgangspunkt og adgang · hvorfra testen foregår, og hvilke konti eller oplysninger testeren får.
Tidsrum · datoer og klokkeslæt, hvor der må testes, og perioder, hvor der ikke må. → Testvindue i en penetrationstest
Tilladte og udelukkede handlinger · fx om handlinger, der kan påvirke driften, er tilladt, og om data må ændres.
Kontakt og eskalering · hvem der kontaktes hos begge parter, også uden for almindelig arbejdstid.
Stop og pause · hvem der kan stoppe testen, og hvordan den genoptages.
Melding af alvorlige fund · hvordan og hvor hurtigt et kritisk fund meldes, før rapporten foreligger.
Behandling af data · hvordan oplysninger, testeren møder, opbevares, beskyttes og slettes.
Oprydning · hvad testeren skal fjerne efter testen, fx testkonti eller filer.

Grænserne skal være til at forstå

Formuleringerne skal kunne forstås af både testeren og dem, der driver systemerne. En sætning som test af webshoppen inden for normal praksis giver ikke en klar grænse. Det gør en sætning, der siger, at betalingsløsningen er udelukket, og at der ikke må gennemføres handlinger, som kan lægge webshoppen ned i åbningstiden.

Grænser for data kræver særlig omtanke. Hvis testeren i ERP-systemet får adgang til lønoplysninger, skal det være aftalt, om testeren stopper, melder og venter, eller om arbejdet må fortsætte med at påvise konsekvensen uden at åbne flere oplysninger. Den slags aftaler skal stå i dokumentet, så testeren ikke skal træffe beslutningen alene.

Det samme gælder grænser for mennesker. Hvis opgaven omfatter kontakt til medarbejdere eller adgang til lokaler, skal det stå udtrykkeligt, hvem der må kontaktes, og hvilke steder der må besøges. En test af kontornettet giver ikke i sig selv lov til nogen af delene.

Hvad sker der, når noget uventet sker?

Den del af dokumentet, der handler om det uventede, er ofte den vigtigste. Tre situationer bør være beskrevet.

Et kritisk fund · Testeren finder en svaghed, der kræver handling med det samme. Dokumentet bør sige, hvem der skal have besked, og hvordan. → Kritisk fund under testen
Påvirkning af driften · Et system bliver ustabilt. Dokumentet bør sige, hvem der kontaktes, og om testen stopper. → Nedbrud under en penetrationstest
Tegn på en reel hændelse · Testeren ser spor efter, at andre har været i systemerne. Dokumentet bør sige, at testen stoppes, og hvem der overtager.

Beskriv også, hvem der kan godkende, at testen genoptages. Det er ikke nok, at nogen kan stoppe den.

Hvem skal godkende dokumentet?

Spillereglerne skal godkendes af en person hos virksomheden, der har ret til at give tilladelse til de systemer, der er med. Ligger kundeportalen hos et hostingfirma, eller drives kontornettet af en driftsleverandør, kan deres accept også være nødvendig. Godkendelsen bør gemmes sammen med dokumentet og opgavebeskrivelsen.

Ændringer undervejs skal gennem samme godkendelse. Hvis testeren vil udvide til et system, der ikke står i dokumentet, skal det godkendes skriftligt, før det sker. En mundtlig accept i et opstartsmøde er ikke nok. Den praktiske forberedelse af tilladelser, adgang og kontakter er beskrevet i → Før penetrationstesten.

Det skal I lade være med

At lade spillereglerne stå i kontrakten alene · De praktiske grænser skal kunne slås op under arbejdet.
At skrive uklare grænser · Ord som normal praksis eller forsigtigt hjælper ingen, når noget går galt.
At glemme kontakt uden for arbejdstid · Test om aftenen kræver nogen, der tager telefonen.
At udvide omfanget mundtligt · Nye systemer skal godkendes skriftligt.
At springe dataafsnittet over · Testeren kan møde oplysninger, som kræver en aftalt håndtering.

Hvad kan og ikke kan konkluderes

Et godkendt dokument med spilleregler viser, hvad testeren havde tilladelse til, og hvordan parterne havde aftalt at håndtere uventede situationer. Det er grundlaget for at læse rapporten korrekt.

Dokumentet kan ikke erstatte tilladelse fra en part, der råder over et system, men ikke har skrevet under. Det siger heller ikke noget om testens kvalitet eller resultat. Teksten er ikke juridisk rådgivning.

Tjekliste før dokumentet godkendes

☐ Er alle systemer i omfanget nævnt, og er udelukkede dele skrevet op?
☐ Har den, der godkender, ret til at give tilladelse til hvert system?
☐ Er tidsrum, udgangspunkt og adgang beskrevet?
☐ Er det klart, hvilke handlinger der ikke er tilladt?
☐ Er kontaktpersoner og stedfortrædere angivet med telefonnumre?
☐ Står det, hvordan kritiske fund og driftspåvirkning håndteres?
☐ Er håndtering af data og oprydning efter testen aftalt?

Kilder

NIST SP 800-115, kapitel 6 og bilag B: planlægning af test og eksempel på indholdet i rules of engagement.
NCSC (UK): Penetration testing: vejledning om at fastlægge omfang og rammer før en test.

Senest gennemgået: oktober 2026.