Hvis noget går ned under penetrationstesten: forebyg, stop og følg op

En penetrationstest påvirker de systemer, den undersøger, og selv en omhyggelig test kan få et skrøbeligt system til at gå i stå. Hvordan forløbet ender, afhænger mest af det, der er aftalt før start: hvilke systemer der kræver særlige hensyn, hvem der kan stoppe arbejdet, og hvordan parterne finder ud af, om testen overhovedet var årsagen.

Hvis noget går ned, er rækkefølgen enkel. Stop den del af testen, der kan have betydning. Genopret driften efter jeres normale procedurer. Find ud af, hvad der skete, før arbejdet genoptages. Og sørg for, at forløbet fremgår af rapporten, fordi et system, der ikke tåler en test, også er en oplysning om systemet.

Hvorfor en test kan påvirke driften

En test afprøver, hvordan systemer reagerer på henvendelser, de ikke er bygget til at forvente. Det kan et system ofte håndtere uden problemer. Andre gange ikke, fx ældre udstyr, systemer med begrænset kapacitet eller løsninger med fejl, som ingen har opdaget, fordi ingen har belastet dem på den måde før.

Risikoen er ikke den samme i alle miljøer. Valget mellem produktion og testmiljø er en selvstændig beslutning med betydning for, hvad resultatet kan bruges til, og den er behandlet i → Penetrationstest i produktion eller testmiljø. Her er udgangspunktet, at testen rører systemer, som forretningen er afhængig af.

NIST SP 800-115 påpeger, at visse testaktiviteter kan påvirke de systemer, der vurderes, og at det bør indgå i planlægningen. For køberen betyder det, at risikoen skal håndteres i bestillingen og ikke afvises med, at testeren nok er forsigtig.

Forebyggelse før start

Lav en kort liste over systemer, der kræver særlige hensyn. Det kan være ERP-systemet i en periode med månedsafslutning, en gammel server, som ingen tør genstarte, eller udstyr i et produktionsanlæg. Listen kan føre til, at et system holdes ude, testes i et bestemt tidsrum eller kun undersøges med skånsomme metoder. → Produktionsanlæg og OT

Aftal testvinduer, der passer til forretningen. En test af webshoppen midt i en kampagne er en anden risiko end en test en stille formiddag. → Test i arbejdstiden eller uden for?

Kontrollér, at der findes en gendannelse, som er afprøvet for de vigtigste systemer. Det er jeres normale driftsberedskab og ikke en del af testen, men det er værd at vide, at det fungerer, før nogen bevidst udfordrer systemerne.

Orientér driften. Driftsleverandøren skal vide, at der testes, hvornår, og hvem de skal kontakte, hvis noget opfører sig anderledes. → Driftsleverandøren og testen

Stop først, forklar bagefter

Når et system opfører sig mærkeligt under en test, er det første skridt at stoppe den del af arbejdet, der kan have betydning. Diskussionen om årsagen kan vente, til driften er genoprettet.

Aftal på forhånd, hvem der kan kræve stop. Det bør være muligt for både virksomheden, driftsleverandøren og testeren selv. Testeren bør stoppe af egen drift, hvis et system holder op med at svare, og melde det med det samme. Virksomheden bør kunne nå testeren hurtigt ad en kendt kanal.

Genopretningen følger jeres egne procedurer. Testeren kan bidrage med oplysninger om, hvad der blev gjort lige før, men bør ikke selv forsøge at reparere systemer, medmindre det udtrykkeligt er aftalt.

Var det testen?

Et nedbrud under en test er ikke nødvendigvis forårsaget af testen. Systemer går også ned af andre grunde, og en tilfældig samtidighed kan føre til en forkert konklusion i begge retninger.

Sammenhold testerens oplysninger om, hvad der blev udført og hvornår, med driftens logning af, hvad der skete på systemet. Det kræver, at testeren fører notater med tidspunkter, og at driften har logning, der kan bruges. Aftal derfor i forvejen, at testeren kan redegøre for sine aktiviteter, hvis der opstår behov.

Hvis årsagen viser sig at være en anden, er det også en vigtig oplysning. Så er der et driftsproblem, som skal løses uanset testen. Pas også på den modsatte fejl: at et nedbrud forklares med testen, fordi det er den nemmeste forklaring, selv om tidspunkterne ikke passer.

Genoptagelse og hvad der skal ændres

Arbejdet bør først genoptages, når parterne ved nok om årsagen til at undgå en gentagelse. Det kan betyde, at det berørte system holdes ude af resten af testen, at det kun testes i et særligt vindue, eller at bestemte aktiviteter udelades. Hvis testperioden er ved at løbe ud, skal der også tages stilling til, om den forlænges, eller om de manglende dele flyttes til en senere test.

Informér de samme personer, som blev informeret om stoppet, når arbejdet genoptages. Driften skal vide, at aktiviteten er i gang igen, så en ny afvigelse kan kobles til testen hurtigt.

Sådanne valg ændrer opgaven og skal behandles som en ændring med godkendelse og notering. → Ændringer i opgaven undervejs

Opfølgning og rapporten

Rapporten bør beskrive hændelsen: hvad der skete, hvornår, hvad testen var i gang med, og hvad der blev besluttet. Den bør også vise, hvilke dele der ikke blev testet som planlagt som følge af forløbet.

Et system, der går ned under en test, har en svaghed i robusthed. Det kan være et fund i sig selv eller i hvert fald en observation, som systemejeren skal tage stilling til. Systemejeren bør overveje, hvad det betyder, at systemet kunne sættes ud af drift på den måde, og om det samme kunne ske uden for en aftalt test. Spørgsmål om ansvar for følgerne hører til i aftalen. → Ansvar og forsikring før start

Det skal I lade være med

At gå ud fra, at intet kan gå galt · En test kan påvirke systemer, uanset hvor omhyggeligt den udføres.
At glemme de skrøbelige systemer · Udpeg dem, før testen begynder.
At diskutere årsagen, før driften er tilbage · Stop og genopret først.
At lade testeren reparere · Genopretning følger jeres egne procedurer.
At genoptage uden at kende årsagen · Så kan det samme ske igen.
At udelade forløbet af rapporten · Det, der ikke blev testet, skal kunne ses.

Hvad kan og ikke kan konkluderes

Et nedbrud under en test viser, at systemet ikke tålte den påvirkning, det blev udsat for under de givne forhold. Det viser ikke i sig selv, at testen blev udført forkert, og heller ikke, at systemet er usikkert på andre måder. Omvendt dokumenterer en test uden driftsforstyrrelser ikke, at systemet er robust over for alle påvirkninger.