Gå til indhold
atlas

Minimumskrav (NIS2)

Også kendt som: NIS2-minimumskrav, artikel 21-krav

Den grundliste af sikkerhedstiltag, som alle organisationer under NIS2 skal have på plads.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

De ti områder af tiltag i NIS2 artikel 21, stk. 2 - blandt andet risikoanalyse, hændelseshåndtering, beredskab for at holde driften i gang, sikkerhed i forsyningskæden, uddannelse, kryptering og multifaktorgodkendelse - som skal stå i forhold til enhedens størrelse og risiko.

Forklaret enkelt

Som det udstyr, enhver bil skal have, før den må køre på vejen - lys, bremser, seler - uanset hvor stor eller lille bilen er.

I praksis

Driftschefen for IT i en dansk fragtvirksomhed holder hvert punkt på listen op mod det, virksomheden allerede gør, og opdager, at der tages backup, men at den aldrig er blevet gendannet i en test.

Hvorfor det betyder noget

En bred pligt til at “styre cyberrisici” er let at påstå og svær at kontrollere; listen giver myndigheden konkrete punkter at efterprøve, og et manglende punkt kan give krav om at rette op eller bøder.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. Når I ved, at I er en væsentlig eller vigtig enhed, så læs de ti områder i § 6 i NIS 2-loven (artikel 21, stk. 2, i direktivet); udbydere af cloud, datacentre, managed services og andre digitale tjenester skal også følge det detaljerede bilag til gennemførelsesforordning (EU) 2024/2690.
  2. Gennemfør en risikovurdering, der dækker alle farer, fra angreb til brand, oversvømmelse og strømsvigt, og brug den til at afgøre, hvor langt hvert tiltag skal gå i forhold til jeres størrelse og risiko.
  3. Hold hvert af de ti områder op mod det, I allerede gør, fx med SAMSIK's vejledning om implementering af foranstaltningerne eller de tilsvarende kontroller i ISO 27002, og skriv hullerne ind i et gap-register med en ejer og en frist for hvert.
  4. Skriv de politikker, listen kræver - risikoanalyse og informationssystemers sikkerhed, hændelseshåndtering, driftskontinuitet med backup og krisestyring, forsyningskædesikkerhed og adgangskontrol - og få ledelsen til at godkende dem.
  5. Indfør de tekniske tiltag, fx testet backup, håndtering af sårbarheder, kryptografi, styring af aktiver samt MFA eller kontinuerlig autentificering og sikret nødkommunikation, hvor risikoen kræver det.
  6. Stil sikkerhedskrav til hver direkte leverandør ud fra dens sårbarheder, produktkvalitet og praksis for sikker udvikling, og uddan ledelse og medarbejdere i grundlæggende cyberhygiejne.
  7. Skriv en risikobaseret begrundelse ned for hvert tiltag, I undlader eller skalerer ned, især hvor loven siger "hvor det er relevant".
  8. Vurdér med test, audits eller nøgletal, om tiltagene virker (område f), ret mangler uden unødigt ophold, og hav dokumentationen klar til den sektoransvarlige myndighed.
  9. Gentag vurderingen mindst en gang om året og efter større ændringer eller hændelser, og rapportér status til ledelsen.

Typiske faldgruber

  • At læse "minimum" som let, selv om hvert af de ti områder skal adresseres, og en nedskaleret indsats skal begrundes i risiko og størrelse.
  • At bruge "hvor det er relevant" som et fravalg af MFA eller kryptering i stedet for at dokumentere, hvorfor et tiltag ikke bruges på et bestemt system.
  • At have backup, der aldrig er blevet gendannet i en test, så driftskontinuiteten kun findes på papiret.
  • At stoppe ved skrevne politikker uden at tjekke, om de virker, selv om vurdering af effektiviteten i sig selv er et af de ti områder.

Gode vejledninger

Teknisk uddybning

Artikel 21, stk. 1, fastlægger den generelle pligt: passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger til at styre risici for de net- og informationssystemer, der bruges til driften eller til at levere tjenester, og til at forebygge eller begrænse virkningen af hændelser. Foranstaltningerne skal tage højde for det aktuelle tekniske niveau, relevante europæiske og internationale standarder og omkostningerne, og proportionaliteten vurderes ud fra enhedens risikoeksponering, størrelse og sandsynligheden for og alvoren af hændelser, herunder deres samfundsmæssige og økonomiske virkning. Artikel 21, stk. 2, kræver derefter en tilgang, der dækker alle farer, altså fysiske hændelser som brand, oversvømmelse og strømsvigt lige så vel som angreb, og opregner ti områder, litra a til j, som foranstaltningerne mindst skal omfatte.

Listen er lige så meget organisatorisk som teknisk: a) politikker for risikoanalyse og informationssystemers sikkerhed; b) hændelseshåndtering; c) driftskontinuitet, herunder backupstyring, reetablering efter katastrofer og krisestyring; d) forsyningskædesikkerhed; e) sikkerhed ved erhvervelse, udvikling og vedligeholdelse, herunder håndtering og offentliggørelse af sårbarheder; f) politikker og procedurer til at vurdere foranstaltningernes effektivitet; g) grundlæggende cyberhygiejne og uddannelse; h) kryptografi og, hvor det er relevant, kryptering; i) personalesikkerhed, adgangskontrol og forvaltning af aktiver; og j) multifaktorautentificering eller kontinuerlig autentificering, sikret tale-, video- og tekstkommunikation og sikrede nødkommunikationssystemer, hvor det er relevant. Artikel 21, stk. 3, tilføjer, at foranstaltningerne i forsyningskæden skal tage højde for hver direkte leverandørs særlige sårbarheder, produktkvalitet og praksis for sikker udvikling, og stk. 4 kræver, at manglende overholdelse rettes uden unødigt ophold.

For udbydere af DNS, topdomæner, cloud, datacentre, CDN, managed services og managed security services, online markedspladser, søgemaskiner, sociale netværk og tillidstjenester omsætter Kommissionens gennemførelsesforordning (EU) 2024/2690 de ti områder til detaljerede tekniske og metodiske krav i sit bilag. For alle andre enheder gengiver den nationale gennemførelse, i Danmark § 6 i NIS2-loven, listen næsten ordret, og detaljerne overlades til vejledninger og anerkendte standarder.

I praksis kan de ti områder kobles tæt til ISO/IEC 27002:2022: hændelseshåndtering til kontrol 5.24-5.28, kontinuitet til 5.29-5.30 og backup til 8.13, leverandører til 5.19-5.22, sikker udvikling og sårbarheder til 8.8 og 8.25-8.28, effektivitet til 5.35 og ISO 27001 afsnit 9, awareness til 6.3, kryptografi til 8.24, adgangskontrol til 5.15-5.18 og autentificering til 8.5. To fejllæsninger går igen. "Minimum" betyder ikke let, for hvert område skal adresseres, og en nedskaleret indsats skal begrundes i risiko og størrelse; og "hvor det er relevant" i litra h og j er ikke et fravalg; i praksis betyder det, at man med en dokumenteret risikobegrundelse skal kunne vise, hvorfor fx MFA ikke bruges på et bestemt system.

Relationer

Krævet af
NIS2-loven

Kilder og videre læsning

Standarder og officielle tekster

Kursusmateriale

  • Cyber Security Fast Track - Ordliste

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.