“Vi tester, når vi får tid”

Penetrationtest: opslagsværk om penetrationstest på dansk

En penetrationstest uden dato ender med at konkurrere med alt det, der haster i driften, og den taber let. Spørgsmålet om hvornår afgøres derfor ikke af, hvornår der bliver tid, men af om testen er planlagt med dato, ejer og plads til opfølgning.

Påstanden lyder fornuftig. Ingen vil sætte en test i gang midt i en systemopgradering eller lige før sæsonens travleste uger. Men ledig tid opstår ikke af sig selv i en IT-afdeling eller hos en driftsleverandør. Der kommer en ny opgave, og en test, der ikke har en dato, er den nemmeste at flytte.

Hvorfor ledig tid ikke kommer

Testen kræver ikke kun testerens tid. Den kræver, at nogen internt beskriver opgaven, skaffer tilladelser, opretter testkonti og er til at få fat på i testperioden. Bagefter skal fundene læses, fordeles og rettes. Alle tre faser trækker på de samme personer, som også holder driften kørende.

Når testen står som et ønske uden dato, bliver den vurderet mod de opgaver, der har en frist. En opdatering af ERP-systemet har en leverandør, der venter. En fejl i webshoppen har kunder, der klager. En test har ingen, der rykker, før en kunde eller en revisor spørger. Når det sker, er der ikke længere tid til at gøre det ordentligt.

Hvad en udskudt test betyder

Den mest direkte følge er, at beslutninger bliver taget uden det grundlag, testen skulle give. Kundeportalen kan få nye funktioner, kontornettet kan få nye forbindelser, og fjernadgangen kan blive udvidet, uden at nogen har set på, hvad ændringerne betyder.

Den anden følge er, at testen til sidst bliver bestilt under pres. Hvis en kunde beder om dokumentation, eller et kontraktkrav skal opfyldes, er der ikke længere tid til at vælge omfang med omtanke. Testen bliver lagt, hvor der er plads hos testeren, og rettelserne må vente til bagefter. → Kunden beder om en pentestrapport

Den tredje følge er sværere at se. Uden en fast rytme bliver det svært at sammenligne resultater over tid og at se, om de samme typer fund går igen. Hver test bliver en enkeltstående begivenhed, og den viden, der blev opbygget sidst, er glemt, når den næste bestilles. Systemejerne skal sætte sig ind i forløbet forfra, og de beslutninger, der blev truffet om gamle fund, er svære at finde igen.

En test er tre perioder

Planlægningen bliver mere realistisk, når testen ses som tre perioder og ikke som en uge i kalenderen.

Forberedelse · opgavebeskrivelse, tilladelser fra hosting og drift, testkonti og kontaktpersoner.
Selve testen · den aftalte periode, hvor testeren arbejder, og hvor jeres kontakt skal kunne træffes.
Opfølgning · gennemgang af rapporten, rettelser, efterprøvning og beslutninger om det, der ikke rettes.

Det er især opfølgningen, der bliver klemt, når testen lægges, hvor der lige er et hul. Rapporten kommer, men de personer, der skal rette, er allerede optaget af den næste opgave. Planlæg derfor de tre perioder samlet, så rettelserne har en plads, før testen begynder.

Hver periode har sine egne personer og sin egen længde. Hvor lang tid de tager, afhænger af systemerne og omfanget, og det bør afklares med testeren. → Hvor lang tid tager en penetrationstest?

Giv testen en fast plads

Der er to måder at sikre, at testen faktisk bliver til noget. Den ene er en fast plads i årshjulet, så testen ligger på et bestemt tidspunkt, der passer til budget, ferier og forretningens travle perioder. → Hvornår på året skal testen ligge?

Den anden er at knytte testen til de ændringer, der udløser den. En ny webshop, et skifte af hostingfirma, en flytning til cloud eller en ny fjernadgang er anledninger, hvor testen bør stå i projektplanen fra start og ikke tilføjes, når projektet er ved at være færdigt.

De to måder udelukker ikke hinanden. Et fast interval sikrer, at der sker noget, mens anledningerne fanger de ændringer, der ikke kan vente til næste gang. → Hvor ofte skal I teste?

Én person skal eje datoen

En dato i en kalender holder kun, hvis nogen forsvarer den. Udpeg én person, der har ansvaret for, at testen bliver bestilt, forberedt og fulgt op. Det kan være IT-chefen, en projektleder eller den, der har ansvaret for sikkerheden. Det vigtige er, at det er en navngiven person og ikke en afdeling.

Den person skal også have mandat til at sige nej, når testen foreslås flyttet uden god grund. Hvis den flyttes, skal den have en ny dato med det samme. → Hvem skal involveres internt?

Afsæt også budget til både test og rettelser i samme ombæring. En test, der er bestilt uden penge til at rette fundene, bliver en rapport, der venter på næste budgetår. → Budgettet rækker til én test

En plan behøver ikke være stor for at virke. For en mindre virksomhed kan det være nok at give det system, der betyder mest, en fast plads i årshjulet og at skrive i projektplanerne, at større ændringer udløser en vurdering af, om der skal testes ekstra. Det afgørende er, at beslutningen er truffet på forhånd.

Det skal I lade være med

At vente på en rolig periode · den rolige periode kommer ikke af sig selv, den skal planlægges.
At lade testen stå som et ønske uden dato · en opgave uden dato er den første, der bliver flyttet.
At planlægge testugen og glemme resten · forberedelse og opfølgning kræver også tid og personer.
At lade en kunde eller en revisor sætte tidspunktet · så bliver testen bestilt under pres og med for lidt omtanke.
At flytte testen uden ny dato · en udskydelse uden ny aftale er i praksis en aflysning.
At bestille uden penge til rettelser · rapporten bliver liggende, til der er budget.

Hvad kan og ikke kan konkluderes

En plan med dato, ejer og budget gør det sandsynligt, at testen bliver gennemført, og at resultatet bliver brugt. Den kan ikke i sig selv sige, hvad testen skal dække, eller hvor ofte der skal testes. Det afhænger af systemerne, ændringerne og de krav, virksomheden møder.

Det kan heller ikke udledes, at en virksomhed, der ikke har testet længe, har særlige svagheder. Det eneste, der kan siges, er, at den ikke ved det. Det er netop det, en planlagt test skal ændre på.