Virksomheder uden lovkrav om sikkerhedstest vælger i nogle tilfælde selv en ramme at styre efter, og CIS Controls og Cybersecurity Framework 2.0 er to af de kendte. Spørgsmålet er, hvor penetrationstesten hører hjemme i dem, og hvornår den giver mening. Kort sagt har CIS Controls en selvstændig kontrol om penetrationstest, som rammen placerer efter de grundlæggende kontroller, mens CSF 2.0 ikke nævner penetrationstest ved navn, men beskriver test og øvelser som kilde til forbedring.
Begge rammer er frivillige. De giver en struktur at arbejde i, men en henvisning til dem gør ikke i sig selv en test påkrævet eller tilstrækkelig.
To rammer med forskellig opbygning
CIS Controls udgives af Center for Internet Security og består af 18 kontroller, som hver er delt op i konkrete sikkerhedstiltag. Tiltagene er fordelt på tre implementeringsgrupper, som bygger oven på hinanden, så en organisation kan begynde med den første gruppe og udvide derfra. Den aktuelle udgave er 8.1.
Cybersecurity Framework 2.0 er udgivet af det amerikanske standardiseringsinstitut i februar 2024. Den beskriver seks funktioner: styring, identifikation, beskyttelse, opdagelse, reaktion og genopretning, og under dem en række resultater, organisationen kan stræbe efter. Rammen skriver selv, at den ikke foreskriver, hvordan resultaterne skal nås.
Forskellen har betydning for køberen. CIS Controls siger noget konkret om test. CSF 2.0 siger, hvad der skal opnås, og overlader valget af metode til jer.
Kontrol 18 i CIS Controls
Kontrol 18 hedder Penetration Testing og har fem tiltag:
- 18.1 · et program for penetrationstest, der passer til organisationens størrelse, kompleksitet, branche og modenhed.
- 18.2 · periodisk ekstern penetrationstest ud fra programmets krav, mindst én gang om året.
- 18.3 · rettelse af fundene efter organisationens dokumenterede proces for håndtering af sårbarheder.
- 18.4 · kontrol af sikkerhedsforanstaltningerne efter hver test.
- 18.5 · periodisk intern penetrationstest ud fra programmets krav, mindst én gang om året.
Programmet i 18.1 er det første, en køber kan tage fat på. Det handler om at beslutte, hvad der skal testes, med hvilken hyppighed og af hvem, før den enkelte test bestilles. CIS nævner selv, at programmet blandt andet skal beskrive omfang, hyppighed, begrænsninger, kontaktpersoner og hvordan fund sendes videre til rettelse. Et sådant program kan være en kort side, men det gør de enkelte bestillinger sammenhængende og lettere at forklare over for ledelsen. Forskellen mellem den eksterne og den interne test er beskrevet i → Ekstern eller intern penetrationstest
Grundkontrollerne kommer først
Ifølge CIS’ egen oversigt hører alle tiltag i kontrol 18 til implementeringsgruppe 2 og 3, og 18.4 og 18.5 kun til gruppe 3. Ingen af dem hører til gruppe 1. Rammen placerer altså penetrationstest efter de grundlæggende kontroller, som oversigt over udstyr og software, sikker opsætning og håndtering af sårbarheder.
For en virksomhed, der styrer efter CIS Controls, er det et argument for at have styr på grundlaget, før testen bestilles. En test af kontornettet, hvor ingen ved, hvilke servere der findes, giver fund, som nogen alligevel skulle have fundet ved en almindelig gennemgang. → Sårbarhedsstyring og penetrationstest
Det betyder ikke, at en mindre virksomhed aldrig skal teste. Hvis webshoppen er forretningens vigtigste system, kan en afgrænset test være relevant, selv om rammen ikke kræver det i den første gruppe. Begrund i så fald valget i jeres egen oversigt, så det er tydeligt, hvorfor testen kommer før andre tiltag, og hvilke grundlæggende kontroller der stadig mangler.
CSF 2.0: test som kilde til forbedring
CSF 2.0 bruger ikke ordet penetrationstest i sine resultater. Under funktionen identifikation står i stedet, at forbedringer identificeres ud fra sikkerhedstest og øvelser, også dem, der gennemføres sammen med leverandører og andre tredjeparter (ID.IM-02). Et andet resultat siger, at sårbarheder i aktiver identificeres, valideres og registreres (ID.RA-01).
En penetrationstest kan bidrage til begge resultater. Den kan bekræfte, at en svaghed findes og kan udnyttes, og den kan give input til forbedringer. Men rammen lader det være op til jer, om penetrationstest er den rette metode, eller om en anden type afprøvning svarer bedre på jeres spørgsmål. Øvelser med et bredere sigte, som red teaming, er beskrevet på red-teaming.dk.
CSF 2.0 lægger desuden vægt på styring. Funktionen styring handler om roller, ansvar, politik og leverandører. For testen betyder det, at nogen skal eje beslutningen om at teste, og at aftaler med driftsleverandøren eller hostingfirmaet bør tage højde for, at deres systemer kan indgå i en test.
Rapporten som dokumentation
En testrapport kan bruges til at vise, at et tiltag eller et resultat i rammen er fulgt op. Det kræver, at koblingen er tydelig. Skriv i jeres egen oversigt, hvilket tiltag eller resultat testen understøtter, hvilket område den dækkede, og hvornår den blev udført.
Tiltag 18.3 og 18.4 handler om det, der sker efter testen. Rapporten alene viser kun, at der blev testet. Handlingsplanen og status på rettelserne viser, at fundene blev behandlet. → Fra rapport til handlingsplan
Kræver en kunde eller en samarbejdspartner dokumentation efter ISO 27001, PCI DSS eller NIS2, gælder andre krav, og de er beskrevet i → Penetrationstest og standarder
Det skal I lade være med
- At teste før grundlaget er på plads · CIS Controls placerer test efter de grundlæggende kontroller.
- At læse CSF 2.0 som et krav om penetrationstest · rammen beskriver resultater, ikke metoder.
- At springe programmet over · 18.1 handler om at planlægge, før den enkelte test bestilles.
- At stoppe ved rapporten · rettelse og efterfølgende kontrol er selvstændige tiltag.
- At henvise til rammen uden kobling · skriv, hvilket tiltag eller resultat testen understøtter.
Hvad kan og ikke kan konkluderes
En penetrationstest kan dokumentere, at tiltag 18.2 eller 18.5 er gennemført for et bestemt område på et bestemt tidspunkt, og den kan være input til resultaterne om sårbarheder og forbedring i CSF 2.0. Sammen med en handlingsplan kan den vise, at fundene er behandlet.
Testen kan ikke vise, at hele rammen er fulgt, eller at grundkontrollerne virker uden for det testede område. En frivillig ramme giver heller ingen formel godkendelse. → Penetrationstest er ingen garanti
Tjekliste, når testen skal passe ind i rammen
- ☐ Er det besluttet, hvilken ramme virksomheden styrer efter?
- ☐ Er de grundlæggende kontroller på plads, før testen bestilles?
- ☐ Er der et program, der beskriver, hvad der testes, med hvilken hyppighed og af hvem?
- ☐ Er det skrevet ned, hvilket tiltag eller resultat testen skal understøtte?
- ☐ Er der en plan for rettelser og efterfølgende kontrol?
- ☐ Er det afklaret, om kunder eller partnere kræver en anden standard?
Kilder
- CIS Controls: Penetration Testing: formålet med kontrol 18.
- CIS Controls Assessment Specification, kontrol 18: tiltag 18.1 til 18.5 og deres implementeringsgrupper.
- CIS Controls v8.1: udgaven som opdatering af version 8.
- Cybersecurity Framework (CSF) 2.0, CSWP 29: de seks funktioner, forbeholdet om metode og resultaterne ID.RA-01 og ID.IM-02.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: ISO 27001-certificering og penetrationstest · Metoden i tilbuddet
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
