Penetrationtest

Fund, der kræver en ny proces: når årsagen er organisatorisk

Penetrationtest: opslagsværk om penetrationstest på dansk

Nogle fund i en penetrationstest kan rettes på en eftermiddag og dukker alligevel op igen ved næste test. Forklaringen kan ligge uden for teknikken: der mangler en fast rutine, en ansvarlig eller en beslutning om, hvordan noget skal gøres hver gang.

Når årsagen er organisatorisk, løser en enkelt rettelse kun symptomet. Det, der skal til, er en proces, der forhindrer, at samme type fejl opstår på ny. Testen kan pege på problemet, men det er virksomheden, der skal finde årsagen og beslutte, hvordan den håndteres.

Teknisk symptom, organisatorisk årsag

Et fund beskrives i rapporten som en konkret svaghed i et bestemt system. Det er symptomet. Bag det kan der ligge en manglende rutine, som testeren ikke kan se, fordi den handler om, hvordan arbejdet er organiseret, og ikke om, hvordan systemet er sat op.

Et eksempel: rapporten nævner en brugerkonto i ERP-systemet, som tilhører en medarbejder, der er stoppet. Kontoen kan lukkes med det samme. Men hvis der ikke findes en fast procedure for at lukke adgange ved fratrædelse, vil der igen være glemte konti ved næste test, blot nogle andre.

Det samme mønster kan ses ved fund, der går igen fra test til test. Gentagelsen peger på, at måden at arbejde på har et hul. → Fund, der går igen fra test til test

Spørgsmål, der afslører årsagen

Stil nogle enkle spørgsmål til hvert fund, før opgaven skrives. De kan stilles af den IT-ansvarlige sammen med den, der skal rette.

  1. Hvordan opstod forholdet? Var det en enkelt fejl, eller er det sådan, opgaven normalt løses?
  2. Hvem har ansvaret for området i hverdagen, og ved den person, at ansvaret er deres?
  3. Findes der en beskrevet fremgangsmåde, og bliver den fulgt?
  4. Kan det samme forhold findes i andre systemer, som ikke var med i testen?

Hvis svaret på det første spørgsmål er, at det er sådan, opgaven normalt løses, er der tale om en proces og ikke om en enkeltstående fejl. Det fjerde spørgsmål er vigtigt, fordi testen kun dækkede et afgrænset område. En manglende rutine i webshoppen gælder måske også kundeportalen.

Eksempler på manglende rutiner

Nogle typer fund kan pege på en manglende proces. Listen er ikke udtømmende, men giver et billede af, hvor årsagen kan ligge, og hvilke spørgsmål der er værd at stille.

  • Forældede komponenter · der mangler en fast rutine for opdateringer eller en oversigt over, hvad der skal opdateres. → Opdateringer og penetrationstest
  • Glemte konti og adgange · der mangler en procedure ved fratrædelse eller ved afslutning af en leverandøraftale.
  • Glemte testmiljøer · der mangler en oversigt over, hvilke systemer virksomheden har kørende, og hvem der ejer dem. → Glemte testmiljøer på internettet
  • Svag standardopsætning · nye systemer sættes op uden en fast liste over, hvad der skal ændres fra leverandørens udgangspunkt.
  • Leverandøradgang uden udløb · adgange gives til en opgave, men ingen har ansvaret for at fjerne dem igen.

Fælles for dem er, at rettelsen af det enkelte fund er enkel, mens den varige løsning kræver, at nogen gør noget på en bestemt måde hver gang.

Hvad en proces skal indeholde

En proces behøver ikke være et langt dokument. Den skal svare på fire spørgsmål: hvad der udløser den, hvem der gør hvad, hvordan det dokumenteres, og hvordan det kontrolleres, at den bliver fulgt.

For glemte konti kan det se sådan ud. Udløseren er, at en medarbejder stopper eller en leverandøraftale ophører. HR eller den, der styrer aftalen, giver besked til IT. IT lukker adgangene og noterer det. En gang imellem gennemgås kontolisten for at fange det, der er smuttet. Hver del har en navngiven ejer.

Beskriv også, hvad der sker, når processen ikke bliver fulgt. Hvis en adgang ikke er lukket ved næste gennemgang, skal det være klart, hvem der får besked, og hvem der rydder op. En proces uden opfølgning glider ud, så snart travlheden tager over, og så står de samme fund i næste rapport. Gør gennemgangen til et fast punkt i kalenderen hos den, der ejer processen, så den ikke afhænger af, at nogen husker den.

Hvis virksomheden arbejder efter et ledelsessystem som ISO/IEC 27001, kan den nye proces indgå i det. Standarden beskriver krav til et ledelsessystem for informationssikkerhed, men den fortæller ikke, hvordan den enkelte rutine skal se ud. Det må virksomheden selv afgøre. → ISO 27001 og penetrationstest

Gør processen lille nok til at blive brugt

En ny proces, der kræver meget af travle medarbejdere, bliver nemt sprunget over. Start med det mindste, der løser problemet, og byg videre, hvis det viser sig nødvendigt. En kort tjekliste ved oprettelse af nye systemer kan gøre mere end en omfattende politik, ingen læser.

Placér processen, hvor arbejdet allerede foregår. Hvis driftsleverandøren opretter nye servere, skal tjeklisten være en del af leverandørens opgave og stå i aftalen. Hvis HR håndterer fratrædelser, skal beskeden til IT være et fast punkt i HR’s egen liste. → Hvem retter? Ansvar mellem virksomhed og leverandør

Før processen ind i handlingsplanen som en selvstændig opgave med ejer og frist, ved siden af de tekniske rettelser. Ellers bliver den let glemt, når de konkrete fund er lukket. → Fra rapport til handlingsplan

Det skal I lade være med

  • At rette symptomet og stoppe dér · spørg, hvorfor forholdet opstod, før opgaven lukkes.
  • At skrive en politik, ingen bruger · en kort rutine i det daglige arbejde virker bedre end et langt dokument.
  • At lægge processen hos en, der ikke har mandat · ejeren skal kunne kræve, at andre gør deres del.
  • At antage, at problemet kun findes i det testede system · en manglende rutine gælder sjældent kun ét sted.
  • At glemme leverandørerne · rutiner, der udføres af driftsleverandøren eller hostingfirmaet, skal stå i aftalen.

Hvad kan og ikke kan konkluderes

En penetrationstest kan vise symptomer, der tyder på en manglende rutine. Den kan ikke alene fastslå årsagen, fordi testeren ikke ser, hvordan arbejdet er organiseret. Den vurdering må virksomheden selv foretage.

En ny proces kan mindske risikoen for, at samme type fejl opstår igen. Om den virker, viser sig først over tid, fx ved at næste test ikke finder de samme forhold, eller ved at jeres egen kontrol fanger dem først.

Tjekliste til en ny proces

  • ☐ Er det afklaret, om fundet skyldes en enkelt fejl eller en fast måde at arbejde på?
  • ☐ Er det undersøgt, om samme forhold findes i andre systemer?
  • ☐ Er udløseren for processen beskrevet?
  • ☐ Har hvert trin en navngiven ejer?
  • ☐ Er det beskrevet, hvordan processen dokumenteres og kontrolleres?
  • ☐ Er leverandørernes del skrevet ind i aftalerne?
  • ☐ Står processen i handlingsplanen med frist?

Kilder

  • ISO/IEC 27001: krav til et ledelsessystem for informationssikkerhed.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om penetrationstest

Læs også: Sårbarhedsstyring og penetrationstest · At glemme testkonti og adgange efter testen

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal I have testet noget?

Fortæl kort, hvad I vil have testet, og hvornår I skal bruge resultatet. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.