Flere systemer skal testes: hvilken rækkefølge giver mening?

Når listen over systemer er længere end budgettet og kalenderen, må nogen bestemme, hvad der kommer først. En holdbar prioritering bygger på tre forhold: hvor meget systemet betyder for virksomheden, hvor udsat det er, og hvor meget det har ændret sig siden sidste undersøgelse.

Svaret er sjældent, at det største eller dyreste system skal først. Et mindre system med kundedata og adgang fra internettet kan veje tungere end et stort internt system, som få bruger og ingen kan nå udefra. Rækkefølgen skal kunne begrundes, så ledelsen kan se, hvorfor noget venter.

Lav først en ærlig liste

Prioritering forudsætter, at alle kandidaterne står på samme liste. Det lyder enkelt, men systemer glemmes let: et gammelt kundeområde, et testmiljø, der aldrig blev lukket, eller en løsning, som en afdeling selv har købt. Spørg både IT, driftsleverandøren og de forretningsansvarlige, hvad der findes.

For hvert system noteres ejer, formål, brugere og om det kan nås fra internettet. Listen behøver ikke være teknisk. Den skal blot være så fuldstændig, at prioriteringen ikke bygger på det, der tilfældigvis blev husket på mødet. Hvad virksomheden viser udadtil, er et emne for sig. → Angrebsflade

Betydning: hvad sker der, hvis systemet svigter?

Det første spørgsmål handler om konsekvens. Hvad ville det betyde for virksomheden, hvis oplysningerne i systemet blev læst, ændret eller gjort utilgængelige af uvedkommende?

Kundedata · systemer med personoplysninger eller fortrolige kundeoplysninger.
Penge og ordrer · løsninger, der styrer betaling, fakturering eller bestillinger.
Drift · systemer, som virksomheden ikke kan arbejde uden.
Adgang videre · løsninger, der giver adgang til andre systemer, eksempelvis fjernadgang eller fælles login.

Webshoppen og ERP-systemet vil ofte score højt på flere punkter. Et intranet med kantinemenuer gør det sjældent. Vurderingen er virksomhedens egen og bør træffes af de forretningsansvarlige sammen med IT.

Brug gerne en enkel skala, eksempelvis høj, middel og lav, frem for point med decimaler. Formålet er at kunne sammenligne systemerne og forklare valget, ikke at skabe en præcision, som vurderingen ikke har. Hvis to personer giver samme system meget forskellig betydning, er det et tegn på, at formålet eller brugen ikke er beskrevet godt nok. Den uenighed er værd at afklare, før rækkefølgen lægges fast.

Husk også kravene udefra. En kunde, der forventer dokumentation for kundeportalen, eller en kontrakt, der nævner et bestemt system, kan give et system højere prioritet, end den interne vurdering alene ville. Notér i så fald, at prioriteringen skyldes kravet, så begrundelsen kan genfindes senere.

Eksponering: hvem kan nå systemet?

Det andet spørgsmål er, hvem der kan komme i kontakt med systemet. En løsning, som alle på internettet kan tilgå, har en anden udsathed end en, der kun kan nås fra kontornettet. En kundeportal, hvor tusindvis af brugere logger ind, har en anden flade end et internt værktøj for fem medarbejdere.

Eksponering afgør også, hvilket perspektiv testen skal have. Et system kan kræve både en undersøgelse udefra og en med medarbejderens adgang. Valget mellem de to perspektiver er beskrevet i → Ekstern eller intern penetrationstest.

Ændringer: hvad er nyt siden sidst?

Det tredje forhold er forandring. Et system, der er testet for nylig og ikke har ændret sig, kan ofte vente. Et system, der har fået nye funktioner, ny hosting eller nye integrationer, rejser nye spørgsmål, selv om det tidligere er undersøgt.

Notér for hvert system, hvornår det sidst blev undersøgt, og hvad der er sket siden. Det kan være en større opdatering, en ny leverandør eller en ny gruppe brugere. En test, der ligger tæt på en ændring, giver et mere brugbart svar end en, der ligger lang tid efter. → Efter en større opdatering af systemet

Fra vurdering til rækkefølge

Når de tre forhold er vurderet, kan systemerne placeres i grupper. En enkel model er at dele listen i tre: det, der skal undersøges nu, det, der planlægges senere, og det, der ikke vurderes at kræve en penetrationstest. Modellen er et forslag, ikke en standard.

Overvej også praktiske hensyn. Hvis webshoppen skal relanceres om tre måneder, kan det være klogt at lægge testen, så der er tid til rettelser bagefter. Hvis ERP-systemet og kundeportalen deler en integration, kan det give mening at undersøge dem i samme opgave eller tæt efter hinanden. Kendte afhængigheder bør påvirke rækkefølgen.

Når budgettet kun rækker til én opgave i år, bliver valget skarpere. Det er beskrevet nærmere i → Budgettet rækker til én test. Hvis flere test skal gennemføres over en periode med samme vilkår, kan en fast ramme lette arbejdet. → Rammeaftale om penetrationstest

Fravalg skal stå på skrift

Det, der ikke testes, er lige så vigtigt at dokumentere som det, der gør. Skriv for hvert udskudt system, hvorfor det venter, og hvornår det tages op igen. Så kan ledelsen se, at fravalget er en beslutning og ikke en forglemmelse.

Hvis en kunde eller revisor spørger, om et bestemt system er undersøgt, er det også nemmere at svare præcist. En rapport om webshoppen må ikke læses, som om kontornettet var med, blot fordi begge stod på den oprindelige liste.

Det skal I lade være med

At teste det, der er lettest at bestille. Rækkefølgen skal følge betydning og udsathed, ikke bekvemmelighed.
At lade sidste års liste styre. Nye systemer og ændringer kan have flyttet prioriteterne.
At glemme de løsninger, afdelingerne selv har købt. De står sjældent på IT-afdelingens oversigt.
At samle alt i én stor opgave uden fokus. En bred test med tynd dækning kan give svage svar på alle spørgsmål.
At skjule fravalg. Systemer, der venter, skal stå som åbne punkter i planen.

Hvad kan og ikke kan konkluderes

En prioriteret liste viser, hvordan virksomheden har vurderet sine systemer på et bestemt tidspunkt. Den viser ikke, at de systemer, der står længst nede, er sikre. Det betyder blot, at de er vurderet til at kunne vente.

Rækkefølgen bør tages op igen, når systemer ændrer sig, eller når en test giver nye oplysninger. Et fund i webshoppen kan pege på en fælles komponent, som gør det relevant at se på et andet system hurtigere end planlagt.