Testens egne risici: hvad ledelsen godkender, når der testes

En sikkerhedstest skal mindske virksomhedens risiko, men den indebærer også selv risici. Et system kan reagere uventet, en tester får adgang til fortrolige oplysninger, og en rapport beskriver præcist, hvor virksomheden er svag. Spørgsmålet for ledelsen er ikke, om de risici findes, men om de er kendt, begrænset og accepteret af en, der har mandat til det. Svaret hviler på en enkel præmis: den, der godkender testen, godkender også dens risici. Det bør ske bevidst og skriftligt.

Risikoen kan begrænses, ikke fjernes

Det amerikanske NIST skriver i sin vejledning om sikkerhedstest, at systemer kan blive beskadiget eller sat ud af drift under en penetrationstest, og at erfarne testere kan mindske den risiko, men aldrig helt fjerne den. Vejledningen anbefaler derfor, at testen kun gennemføres efter grundig overvejelse, varsling og planlægning.

Det er en ærlig beskrivelse, og den passer til ledelsens rolle. Ledelsen skal ikke vurdere, hvordan testeren arbejder. Den skal sikre, at de risici, testen bringer med sig, er afvejet mod det, virksomheden får ud af den. Forstyrrelse af driften er kun én af dem. → Forstyrrer testen forretningen?

Fem risici, ledelsen bør kende

Ud over forstyrrelser af driften er der andre risici, som ledelsen bør have på listen, før den siger ja.

Fortrolige oplysninger · testeren kan få adgang til kundedata, personaleoplysninger eller forretningshemmeligheder. Den amerikanske vejledning nævner, at nogle testmetoder kan føre til, at følsomme data bliver eksponeret.
Rapporten selv · den beskriver svaghederne præcist og er derfor værdifuld for andre end jer. Den skal behandles som et fortroligt dokument.
Rester efter testen · konti, adgange eller filer, der blev oprettet til testen, skal fjernes bagefter, ellers bliver de en ny svaghed.
Forveksling med et rigtigt angreb · hvis overvågningen eller driftsleverandøren ikke er orienteret, kan testen udløse alarmer og beredskab, der koster tid og tillid.
Andres systemer · testen kan berøre systemer, som tilhører leverandører eller kunder, og som virksomheden ikke selv kan give lov til at teste.

Den sidste risiko har en juridisk side. Tilladelse og aftale med testeren er beskrevet på https://penetrationtest.dk/, og spørgsmålet om andres systemer skal afklares, før testen går i gang. → IT-kontrakten og sikkerhedstesten

Hvad ledelsen godkender

Godkendelsen behøver ikke være lang, men den skal dække de beslutninger, der kun ledelsen kan træffe. Den amerikanske vejledning foreslår i sin skabelon til spillereglerne for en test, at testlederen og virksomhedens ledelse skriver under på, at de forstår testens omfang og grænser. For en dansk virksomhed kan godkendelsen dække fem punkter.

Omfanget · hvilke systemer testen omfatter, og hvilke den ikke må røre.
Tidspunktet · hvornår testen må foregå, set i forhold til forretningens kalender.
Stopreglerne · hvornår testeren skal stoppe og kontakte virksomheden, fx før et skridt, der kan skade.
Oplysningerne · hvad testeren må se og gemme, hvordan rapporten opbevares, og hvornår data fra testen slettes.
Kontakten · hvem der kan træffes under testen, og hvem der har mandat til at standse den.

Når de fem punkter er besluttet og skrevet ned, ved alle parter, hvad de har sagt ja til.

Det er også ledelsens opgave at afveje realisme og forsigtighed. En test, der må mindre, er mindre risikabel, men den siger også mindre om, hvordan forsvaret holder over for en rigtig angriber. Hvis de vigtigste systemer undtages af frygt for forstyrrelser, kan resultatet give en tryghed, der ikke er dækning for. Ledelsen kan i stedet vælge at teste dem på et roligt tidspunkt, med tydelige stopregler eller i en kopi, og skrive ned, hvad valget betyder for, hvad testen kan sige. → Ledelsens godkendelse

Når testen finder noget, ingen havde ventet

En særlig risiko er, at testen afslører tegn på, at nogen allerede har været inde. Vejledningen anbefaler, at testen stoppes, hvis der opstår en hændelse, og at de rette personer, herunder ledelsen, bliver orienteret. Testen genoptages først, når hændelsen er håndteret, og der er givet lov.

Det er en situation, ledelsen bør have tænkt igennem på forhånd. Hvem skal testeren ringe til? Hvem i ledelsen skal vide det med det samme? Og hvem tager stilling til, om der skal kaldes hjælp udefra? Hvis svarene først skal findes, når det sker, går der værdifuld tid tabt. Det kan også være klogt at aftale, hvordan der kommunikeres i en sådan situation, så oplysninger om en mulig hændelse ikke sendes ad kanaler, som en angriber kan følge med i. → Tegn på indbrud

Testeren er en del af risikobilledet

Når virksomheden lukker en ekstern person ind i sine systemer, er valget af den person en del af risikoen. Den amerikanske vejledning skriver også, at eksterne testere bør vurderes, så virksomheden sikrer sig, at de har de nødvendige færdigheder, erfaring og integritet, og at det er rimeligt at bede dem påtage sig en del af risikoen for skader.

For ledelsen betyder det tre spørgsmål til testeren: hvordan beskyttes de oplysninger, testeren får adgang til, hvem udfører arbejdet, og hvordan er ansvaret fordelt, hvis noget går galt? En fortrolighedsaftale er en naturlig del af det. → En tester, man kan stole på

Et tænkt eksempel

En virksomhed, der udlejer entreprenørmaskiner, skal have testet sin kundeportal. IT-chefen har aftalt tidspunktet med testeren, men ingen har tænkt på, at portalen drives af et softwarehus, og at maskinernes positionsdata hentes fra en anden leverandør.

Før direktøren skriver under, spørger bestyrelsesformanden, hvad testen kan ramme. Gennemgangen viser, at begge leverandører skal give lov og orienteres, og at testeren vil kunne se kundernes kontaktoplysninger. Godkendelsen bliver udvidet med leverandørernes accept, en aftale om, at rapporten kun indeholder de oplysninger, der er nødvendige, og en plan for at slette data fra testen. Testen begynder en uge senere end planlagt.

Det skal I lade være med

At tro, at testen er uden risiko · den kan begrænses, men ikke fjernes.
At lade IT godkende testen alene · risikoen for forretningen skal kendes af dem, der bærer den.
At glemme oprydningen · konti og adgange fra testen skal lukkes bagefter.
At sende rapporten rundt i almindelig mail · den beskriver præcist, hvor I er svage.
At teste systemer, I ikke ejer, uden afklaring · leverandørers og kunders systemer kræver deres samtykke.

Hvad kan og ikke kan konkluderes

En skriftlig godkendelse af testens omfang, tid, stopregler, oplysninger og kontakt gør testens egne risici kendte og begrænsede. Den kan ikke garantere, at intet går galt, og den kan ikke flytte ansvaret for en skade bort fra virksomheden eller testeren. Hvordan ansvaret fordeles, afhænger af aftalen. Teksten er ikke juridisk rådgivning.

Tjekliste før ledelsens ja

☐ Kender ledelsen de vigtigste risici ved testen, ikke kun forstyrrelser af driften?
☐ Er omfang, tidspunkt og stopregler skrevet ned?
☐ Er det aftalt, hvordan oplysninger fra testen behandles, opbevares og slettes?
☐ Er driftsleverandør og overvågning orienteret?
☐ Ved testeren, hvem der skal kontaktes, hvis der findes tegn på indbrud? → Kommunikation under testen

Kilder

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment: afsnittet om penetrationstest: at systemer kan blive beskadiget eller sat ud af drift, og at risikoen ikke kan fjernes helt; afsnit om valg af testmetoder (tab af tilgængelighed og eksponering af følsomme data); afsnit om eksterne testere (færdigheder, erfaring, integritet og ansvar for skader); hændelser under testen; bilag B om underskrift af spilleregler for testen.

Senest gennemgået: oktober 2026.