ENISA’s tekniske vejledning: hvad den siger om sikkerhedstest

Kundens kravbilag kan indeholde formuleringer som “test ved opsætning og efter væsentlige ændringer” eller en liste over testtyper fra sårbarhedsvurdering til red teaming. De kan komme fra ENISA’s NIS2 Technical Implementation Guidance fra juni 2025. Svaret på, hvad vejledningen siger om test, findes i dens afsnit 6.5, som forklarer punkt 6.5 i bilaget til gennemførelsesforordning (EU) 2024/2690. Det vigtigste at vide er dog, hvem den er skrevet til, og at den ikke er bindende.

ENISA er EU’s agentur for cybersikkerhed. Vejledningen er skrevet til de digitale udbydere, som forordningen gælder for, men ENISA skriver selv, at den kan være nyttig for andre. Derfor dukker den op i krav fra kunder, som forordningen slet ikke gælder for. Teksten er ikke juridisk rådgivning.

Hvad vejledningen er, og hvad den ikke er

Vejledningen gengiver forordningens krav punkt for punkt og tilføjer tre ting: vejledning, eksempler på dokumentation og tips. ENISA skriver udtrykkeligt, at dokumentet ikke er juridisk bindende og kun har rådgivende karakter. Den del, der følger efter hvert krav, er anbefalinger.

ENISA tilføjer et forbehold, der er nyttigt for en leverandør. Medlemsstaterne bestemmer selv, hvordan de fører tilsyn, og vejledningen kan derfor ikke afgøre, om en enhed skal have alle eller kun nogle af de eksempler på dokumentation, den nævner. ENISA kalder det en meget streng tilgang at kræve det hele. En kunde, der kopierer hele listen ind i et kravbilag til jer, går altså videre end vejledningen selv lægger op til. → Gennemførelsesforordning 2024/2690

Det, vejledningen siger om testtyper og tidspunkter

Til forordningens punkt 6.5.2 giver ENISA en række råd. De vigtigste for en leverandør er:

Bredden af testtyper · ENISA nævner blandt andet sårbarhedsvurderinger, penetrationstest, kodegennemgang, bug bounty-programmer, red teaming og øvelser i at reagere på angreb, og anbefaler at vælge den eller de typer, der passer til det, der skal afprøves.
Tidspunkter · test bør ske ved opsætning, efter væsentlige opgraderinger eller ændringer og efter vedligeholdelse.
Kontinuerlig test · særligt i miljøer, hvor ændringer rulles ud løbende.
Test af hele enheden · med planlagte mellemrum eller ved væsentlige hændelser og ændringer.

Listen er ikke et krav om, at alle typer skal bruges. Den er et katalog at vælge fra ud fra risikoen. → Sårbarhedsscanning eller penetrationstest

Det, vejledningen siger om dokumentation

ENISA anbefaler, at testens behov, omfang, hyppighed, type og resultater dokumenteres, så en sagkyndig tredjepart kan forstå dem. Resultaterne bør vurderes med kriterier svarende til dem, enheden bruger i sin risikovurdering, og fund med høj kritikalitet bør vurderes, følges op og afhjælpes.

Som eksempler på dokumentation nævner vejledningen bl.a. en testpolitik og procedurer, en beskrivelse af roller og ansvar, planer for kommende og gennemførte test og en liste over rapporter fra tidligere test. I tipsene nævnes, at en testpolitik kan angive godkendte parter, interne eller eksterne, og fortrolighedsniveauer. → Kunden vil se jeres testpolitik

Råd, der rammer leverandører direkte

Nogle af ENISA’s råd handler om forhold, som en leverandør kan stå for:

Eksterne integrationer · for systemer med integrationer uden for organisationens kontrol, fx cloudtjenester, anbefales det, at alle eksterne API-endepunkter testes grundigt.
Adskilte miljøer · udviklings- og testmiljøer bør være adskilt fra produktion.
Open source · når en test afslører en sikkerhedsfejl i en open source-komponent, skriver ENISA, at fundet skal deles med det pågældende projekt.
Politikken skal kendes · testpolitikken bør være godkendt og kommunikeret til relevante medarbejdere og tredjeparter.

Hvis kunden er en relevant enhed efter forordningen, kan I forvente spørgsmål om netop disse punkter. → API’et, kunden kalder

Et interval, der kan blive misforstået

Til punkt 6.5.3 anbefaler ENISA, at testpolitikken og procedurerne gennemgås mindst hvert andet år. Det handler om gennemgang af politikken, ikke om, hvor ofte der skal testes. Forordningen selv lægger hyppigheden af test ind under risikovurderingen. Hvis et kravbilag nævner hvert andet år som testinterval med henvisning til ENISA, er det værd at spørge, om kunden mener politikken eller testen. Svaret kan ændre aftalen betydeligt. En politik, der skal gennemgås hvert andet år, er en lille opgave, mens et fast testinterval binder jer til et forløb, uanset om leverancen har ændret sig eller ej. Bed kunden skrive det ind med den betydning, der er ment. → Testfrekvens efter risiko

Sådan bruger I vejledningen over for kunden

Vejledningen kan være et fælles referencepunkt, når et krav er uklart. Brug den sådan:

Find kildepunktet · sammenlign kravets ordlyd med ENISA’s afsnit 6.5 og forordningens bilag, så I ved, hvad der er krav, og hvad der er råd.
Skil krav fra eksempler · forordningens tekst står fremhævet i vejledningen; det, der følger efter, er anbefalinger.
Foreslå en udvælgelse · vælg de eksempler på dokumentation, der passer til jeres leverance, og forklar, hvorfor resten ikke er relevant.
Få det på skrift · en kort bekræftelse fra kunden gør det lettere at genbruge aftalen ved næste test.

En leverandør af et bookingsystem til en hospitalsafdeling kan på den måde ende med en aftale om en penetrationstest af løsningen og dens integrationer, en kort testpolitik og en liste over seneste rapporter, i stedet for hele ENISA’s katalog.

Det skal I lade være med

At behandle vejledningen som lov · den er rådgivende og ikke bindende.
At acceptere hele listen over dokumentation uden at spørge · ENISA kalder det selv en meget streng tilgang.
At forveksle gennemgang af politikken med testinterval · de to er forskellige.
At tro, at alle testtyper skal bruges · vejledningen anbefaler at vælge efter formålet.
At citere vejledningen over for en kunde uden at nævne, hvem den er skrevet til · den retter sig mod forordningens digitale udbydere.

Hvad kan og ikke kan konkluderes

Vejledningen giver et godt billede af, hvad en tilsynsførende eller en kunde med teknisk indsigt kan spørge om, når de vil vurdere sikkerhedstest. Den kan hjælpe jer med at forstå et kravbilag og strukturere jeres dokumentation. Den kan ikke sige, hvad en bestemt kunde må kræve af jer, og den fastsætter ingen pligt for virksomheder, der ikke er omfattet af forordningen. Følger I dens råd, er det god praksis, ikke et bevis for, at krav er opfyldt.

Tjekliste, når kravbilaget bygger på ENISA

☐ Har I fundet de afsnit i vejledningen, kravet stammer fra?
☐ Er det klart, om kunden er en relevant enhed efter forordningen?
☐ Er dokumentationslisten tilpasset jeres leverance?
☐ Er gennemgang af politik og testinterval holdt adskilt?
☐ Er integrationer og eksterne API-endepunkter med i testens omfang, hvis kunden er afhængig af dem?
☐ Er der aftalt, hvordan fund i open source-komponenter håndteres?