Opdateringer og penetrationstest: hvorfor patching ikke gør testen overflødig

Hvis alle systemer er opdaterede, er der så noget tilbage at teste? Ja, fordi opdateringer kun retter de fejl, som producenten kender og har lavet en rettelse til, mens mange svagheder opstår i den måde, systemerne er sat op og brugt på.

Patchstyring er den løbende disciplin, der sørger for, at rettelser fra producenterne bliver installeret i tide. Den er vigtig, og en penetrationstest kan ikke erstatte den. Men de to besvarer forskellige spørgsmål. Opdateringer spørger, om de kendte fejl er lukket. Testen spørger, hvad der kan opnås i jeres konkrete løsning, som den ser ud nu.

Hvad en opdatering faktisk retter

En opdatering er producentens rettelse til en fejl i deres eget produkt. Når den er installeret, er netop den fejl lukket i netop det produkt. Det gælder operativsystemer, programmer, tilføjelser til webshoppen og komponenter i kundeportalen.

Opdateringen ved derimod intet om, hvordan produktet er taget i brug hos jer. Den ændrer ikke de rettigheder, I har givet brugerne i ERP-systemet. Den lukker ikke en funktion, der er slået til, fordi nogen havde brug for den under opsætningen. Den retter ikke en fejl i den kode, jeres egen leverandør har skrevet.

Der kan også gå tid, fra en fejl bliver kendt, til producenten har en rettelse klar. I den periode hjælper opdateringer ikke, uanset hvor hurtigt de installeres. Det er en af grundene til, at andre forsvarslag også skal holde: adskillelse mellem systemer, begrænset adgang og overvågning. En penetrationstest kan give et indtryk af, om de lag virker i det testede område. → Sårbarhedsstyring og penetrationstest

Svagheder, som ingen opdatering lukker

Der er flere slags forhold, der ligger uden for producentens rettelser. De er ofte det, en penetrationstest bruger tiden på.

Opsætning · indstillinger, der er valgt lokalt, fx en administrativ side, der er tilgængelig fra internettet, eller standardindstillinger, der aldrig er ændret.
Rettigheder · brugere og roller med mere adgang end deres arbejde kræver, fx i ERP-systemet eller på fildrevet på kontornettet.
Forretningslogik · funktioner, der virker som programmeret, men kan bruges på en måde, ingen havde tænkt sig, fx når en kunde i kundeportalen kan se en anden kundes ordrer.
Sammenhænge · forbindelser mellem systemer, fx en integration mellem webshoppen og lageret, hvor den ene part stoler for meget på den anden.
Egenudviklet kode · fejl i det, jeres leverandør har bygget, som ingen ekstern producent udsender rettelser til.

OWASP Top 10 er en oversigt over risikoområder i webapplikationer. Den rummer både et område om forældede og sårbare komponenter og områder om fx adgangskontrol og fejlkonfiguration. Det illustrerer, at opdatering kun dækker en del af billedet. → Kunders data holdt adskilt

Når opdateringen ikke kan installeres

Ikke alle systemer kan opdateres med det samme. Et ERP-system kan kræve, at leverandøren først godkender en ny udgave. Et produktionsanlæg kan være bundet til en bestemt version. En tilføjelse til webshoppen kan være forladt af den oprindelige udvikler, så der ikke kommer flere rettelser.

I de situationer bliver testen ekstra relevant. Den kan vise, om de andre forsvarslag holder, når en kendt fejl ikke er lukket. Er systemet adskilt fra resten af nettet, så fejlen ikke kan udnyttes udefra? Er adgangen begrænset til de personer, der har brug for den? Svaret hjælper virksomheden med at beslutte, om situationen kan accepteres i en periode, eller om der skal findes en anden løsning. → Plugins og tredjepartskode

Gem beslutningen om at vente med en opdatering. Skriv, hvem der traf den, hvorfor, og hvornår den skal tages op igen. Ellers bliver en midlertidig undtagelse let permanent uden, at nogen har besluttet det.

Testen siger også noget om opdateringerne

En penetrationstest kan bruges som en stikprøve på patchstyringen. Finder testeren en kendt fejl, som der har været en rettelse til længe, er det en oplysning om processen og ikke kun om det enkelte system.

Spørg i den situation, hvorfor rettelsen manglede. Var systemet glemt i oversigten? Troede I, at driftsleverandøren tog sig af det, mens leverandøren troede det modsatte? Var rettelsen installeret på én af to servere? Svaret peger på, hvad der skal ændres, så det samme ikke sker med næste rettelse. → Driftsleverandøren og penetrationstest

Det modsatte gælder også. Hvis testen ikke finder manglende opdateringer i det testede område, er det en indikation af, at processen virker der. Det er ikke et bevis for, at alle systemer uden for scope er opdaterede.

Læg testen, så den passer til opdateringerne

Det har betydning for resultatet, hvornår testen gennemføres i forhold til opdateringerne. En test lige efter en stor opdateringsrunde viser, hvordan løsningen ser ud med de nyeste rettelser. En test før kan give fund, der allerede var planlagt rettet.

Begge dele kan være fornuftige. Det vigtige er, at I ved, hvilken situation rapporten beskriver. Fortæl testeren, hvis store opdateringer er planlagt i testperioden, så begge parter kan tage højde for det. En ændring midt i testen kan gøre det svært at sammenligne resultater fra før og efter. → Penetrationstest efter en opdatering

Det skal I lade være med

At sætte lighedstegn mellem opdateret og sikker · Opsætning, rettigheder og logik ændres ikke af en rettelse fra producenten.
At fjerne testen fra budgettet, fordi opdateringerne kører · De to opgaver besvarer forskellige spørgsmål.
At lade undtagelser leve uden ejer · Et system, der ikke kan opdateres, kræver en skriftlig beslutning og en dato.
At overse egenudviklet kode · Ingen producent udsender rettelser til det, jeres leverandør har bygget.
At ignorere et gammelt fund i rapporten · En manglende rettelse er også en oplysning om processen.
At opdatere midt i testen uden at sige det · Fortæl testeren om planlagte ændringer i perioden.

Hvad kan og ikke kan konkluderes

En velfungerende patchstyring gør det mindre sandsynligt, at kendte fejl med færdige rettelser står åbne i de systemer, processen dækker. Den kan ikke sige noget om fejl i opsætning, rettigheder, sammenhænge eller egenudviklet kode.

En penetrationstest kan vise, hvad der kunne opnås i det testede område på testtidspunktet, også når systemerne er opdaterede. Den kan ikke vise, at fremtidige rettelser bliver installeret, og den kan ikke tale for systemer, den ikke omfattede. → Automatisk eller manuel penetrationstest