Efter en større opdatering: hvornår skal systemet testes igen?

En opdatering kan være en rutinemæssig rettelse, eller den kan ændre, hvordan systemet fungerer, hvem der kan hvad, og hvad der er synligt udefra. Om der skal testes igen, hviler på én vurdering: har opdateringen ændret de forhold, som den seneste test byggede sine konklusioner på?

Er svaret ja, er den seneste rapport ikke længere et dækkende billede af systemet, og en afgrænset test af det ændrede giver mening. Retter opdateringen kun fejl uden at ændre funktioner, roller eller adgangsveje, er en ny test sjældent nødvendig.

Opdatering og ændring er ikke det samme

Ordet opdatering dækker meget forskelligt. En sikkerhedsrettelse fra leverandøren lukker typisk et kendt problem uden at ændre systemets opbygning. En ny hovedversion kan derimod bringe nye moduler, en ny måde at logge ind på, nye integrationer eller en ny model for rettigheder.

Den første slags hører til den løbende vedligeholdelse. Den erstatter ikke en penetrationstest, og testen erstatter heller ikke den. → Opdateringer og penetrationstest

Den anden slags er en ændring af selve det system, der blev testet. Det er den slags opdatering, der kan gøre en eksisterende rapport forældet, også selv om den er af ny dato.

Grænsen mellem de to er ikke altid skarp. En sikkerhedsrettelse kan ændre en indstilling, som påvirker login, og en lille funktionsopdatering kan åbne en ny vej for data ud af systemet. Spørg derfor leverandøren, hvad opdateringen ændrer, og læs udgivelsesnoterne med testens spørgsmål i baghovedet frem for kun at se på, om det er en stor eller lille version.

Spørgsmål, der afslører en væsentlig ændring

Der findes ingen fast grænse for, hvornår en ændring er væsentlig. Men en række spørgsmål kan bruges til vurderingen, og jo flere af dem der besvares med ja, jo stærkere er grunden til en ny test.

Nye funktioner · kan brugerne gøre noget, de ikke kunne før, især med kundedata eller betalinger?
Nyt login eller nye roller · er måden at logge ind på, rettighederne eller rollemodellen ændret?
Nye forbindelser · taler systemet med nye systemer, eller er det åbnet for nye brugergrupper?
Ny synlighed · kan dele af systemet nu nås fra internettet, som ikke kunne før?
Ny platform · er systemet flyttet, eller er den underliggende teknik udskiftet?

I et tænkt eksempel får kundeportalen en ny version med selvbetjening af abonnementer og et nyt fælles login. Begge ændringer berører netop det, en tidligere test af portalen undersøgte. En opdatering, der kun ændrer farver og tekster, gør ikke.

Et andet tænkt eksempel er ERP-systemet, der får et nyt modul til leverandørbetalinger. Selv om resten af systemet er uændret, er der nu en funktion, som håndterer penge, nye roller til godkendelse og måske en ny forbindelse til banken. Det er netop den slags ændring, der bør vurderes.

PCI DSS bruger begrebet væsentlige ændringer i kravene om penetrationstest af miljøer med betalingskortdata. Standarden gælder ikke for alle, men tankegangen kan låne: en test knyttes ikke kun til kalenderen, men også til ændringer i systemet. → Hvor ofte skal I teste?

Afgræns testen til det, der er ændret

En test efter en opdatering behøver ikke gentage hele den oprindelige opgave. Scope kan bygges op omkring de nye funktioner, de ændrede roller og de nye forbindelser, med den tidligere rapport som baggrund. → Scope i en penetrationstest

Skriv tydeligt, hvad der er ændret, og hvad der ikke er. Testeren skal kunne se forskellen, og rapporten skal kunne læses sammen med den forrige. Er kundeportalens nye selvbetjening det eneste i scope, kan rapporten ikke bruges som en samlet vurdering af portalen.

Pas på med at bruge den forrige opgavebeskrivelse uændret. Den beskriver systemet, som det så ud før opdateringen, og kan få testen til at kigge de forkerte steder. → At genbruge sidste års opgave

Før eller efter udrulningen?

Det mest nyttige tidspunkt er ofte, før opdateringen når alle brugere, i et miljø, der svarer til driften. Så kan fund rettes, før de får betydning. Det kræver, at leverandøren eller udviklerne leverer en version, der kan testes i god tid, og at projektplanen har plads til rettelser. → Testen ligger lige før lanceringen

Er opdateringen allerede rullet ud, kan testen ligge efter. Så er det den faktiske drift, der testes, og fund skal håndteres i den løbende drift. Begge dele kan være rigtige, men valget skal træffes bevidst og fremgå af bestillingen.

Test efter udrulningen kræver lidt mere omtanke om tidspunktet. Hvis testen kan påvirke brugerne, skal testvinduet aftales med systemejeren og driftsleverandøren. Det er en praktisk overvejelse, som hører til forberedelsen og ikke ændrer på, hvad testen skal svare på.

Retest af gamle fund er en anden opgave. Indeholder opdateringen også rettelser fra en tidligere rapport, kan de efterprøves i samme forløb, men det skal stå særskilt i aftalen og i rapporten. → Retest efter penetrationstest

Hvem opdager, at der er sket noget væsentligt?

Vurderingen kræver, at nogen får besked. En systemleverandør udsender en ny version, og driftsleverandøren installerer den, uden at IT-chefen nødvendigvis ser indholdet. Aftal derfor, at væsentlige ændringer i forretningskritiske systemer meldes til den, der har ansvaret for testplanen. Et kort spørgsmål i ændringsprocessen er nok: berører ændringen login, roller, forbindelser eller det, der er synligt udefra?

Spørgsmålet kan med fordel stå i kontrakten med systemleverandøren og i aftalen med driftsleverandøren. Så bliver det deres opgave at gøre opmærksom på ændringer, der kan påvirke testplanen, og ikke kun virksomhedens opgave at opdage dem.

Det skal I lade være med

At teste efter hver eneste rettelse · løbende sikkerhedsrettelser hører til vedligeholdelsen.
At lade versionsnummeret afgøre sagen · det er ændringens indhold, der tæller.
At bruge den gamle rapport som dokumentation · efter en væsentlig ændring beskriver den et andet system.
At udelade de nye integrationer · det er ofte dem, opdateringen tilføjede.
At kalde en delvis test for en samlet vurdering · en afgrænset test dækker det afgrænsede.

Hvad kan og ikke kan konkluderes

En test af det ændrede kan vise, om de nye funktioner, roller og forbindelser havde de undersøgte svagheder. Sammen med den tidligere rapport kan den give et rimeligt billede af systemet, så længe resten faktisk er uændret.

Den kan ikke vise, at opdateringen har ladet dele uden for scope uberørt. Var ændringen mere gennemgribende end antaget, holder kombinationen af gammel og ny rapport ikke. → Rapportens alder

Tjekliste efter en opdatering

☐ Er det klart, hvad opdateringen ændrer i funktioner, roller og forbindelser?
☐ Er det vurderet, om ændringen berører det, den seneste test undersøgte?
☐ Er scope afgrænset til det ændrede og beskrevet i forhold til den forrige rapport?
☐ Er testen placeret, så der er tid til rettelser før fuld udrulning?
☐ Står eventuel retest af gamle fund særskilt?
☐ Meldes væsentlige ændringer fremover til den, der ejer testplanen?