NIS2 og ISO 27001: genbrug kontroller, undersøg manglerne

Et ISO 27001-program kan give en stærk driftsstruktur for NIS2: risikovurdering, ansvarlige ejere, kontroller, evidens og forbedring. Det næste skridt er en vurdering, krav for krav, af hvad denne struktur faktisk dækker.

For en CTO er det nyttige spørgsmål ikke, om frameworkene overlapper. Det er, om en implementeret kontrol beskytter den relevante tjeneste, opfylder den gældende forpligtelse og frembringer evidens, der understøtter konklusionen. Genbrug implementeringen, hvor disse betingelser er opfyldt; bevar de juridiske og operationelle forskelle, hvor de ikke er.

Forstå, hvad hvert framework fastlægger

ISO/IEC 27001 specificerer krav til et afgrænset ledelsessystem for informationssikkerhed (ISMS). Afsnit 4–10 omhandler ledelsesstrukturen, herunder risikobehandling, evaluering af præstationer og forbedring. Annex A indeholder 93 referencekontroller fordelt på organisatoriske, personmæssige, fysiske og teknologiske kategorier. Kontrollernes anvendelighed er risikobaseret og ikke et krav om at implementere alle kontroller ens. ISO 27002 giver vejledning i implementeringen.

NIS2 er et EU-direktiv, der gennemføres i national lovgivning. Anvendeligheden afhænger af sektor, størrelse, tjeneste og specifikke regler for omfattethed. Bilag I og bilag II angiver relevante sektorer, men sektoren alene afgør ikke, om en organisation er en væsentlig eller vigtig enhed. Nogle enheder er omfattet uanset størrelse.

De praktiske forskelle er:

Certificering foretages af uafhængige certificeringsorganer, ikke af ISO. Den fastslår ikke overholdelse af NIS2, og NIS2 kræver generelt ikke ISO 27001-certificering. Håndhævelse kan omfatte tilsynsforanstaltninger og sanktioner; ISO-certificering har et andet assurance-formål.

Begynd med at afstemme afgrænsningerne

Sammenlign det certificerede ISMS-omfang med de juridiske enheder og tjenester, der er omfattet af NIS2. Et certifikat, der dækker et udviklingsteam, kan efterlade produktionsdriften, et andet datterselskab eller yderligere lokationer uden for afgrænsningen.

Udarbejd en sammenligning af omfang, der registrerer:

• Omfattede juridiske enheder, lande, tjenester og grundlaget for at de er omfattet.
• Relevante systemer, netværk, lokationer og understøttende leverandører.
• ISMS-omfanget, certifikatets omfang og undtagelser.
• Gældende nationale krav, sektorregler og ansvarlige myndigheder, herunder gældende registreringspligter, krævede oplysninger om enheden, indsendelseskanaler og opdateringspligter.
• Hvem der godkendte anvendelighedsvurderingen, og hvornår den skal tages op igen.

Skeln mellem en mangel i omfanget og en mangel i kontrollerne. Et produktionsmiljø uden for ISMS'et kan allerede have gode adgangskontroller, men disse kontroller kræver stadig ejerskab, vurdering og evidens inden for NIS2-arbejdet.

Kontrollér sektorspecifik lovgivning, før forpligtelser duplikeres. Artikel 4 omhandler forholdet til sektorspecifikke EU-retsakter. For finansielle enheder kræver forholdet til DORA en rollespecifik analyse. For aktiviteter i Tyskland bør I konsultere BSI's NIS2-information i stedet for at antage, at eksisterende KRITIS-pligter og NIS2-pligter er identiske.

Map implementerede kontroller, ikke ens etiketter

Artikel 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger. De ti minimumsområder for foranstaltninger giver et udgangspunkt for mapping, men lignende ordlyd er et nyttigt spor, ikke et bevis for ækvivalens.

Brug følgende som udgangspunkt for review, ikke som automatiske erklæringer om dækning:

Anvendelighedserklæringen (Statement of Applicability) registrerer nødvendige kontroller og begrundelsen for at medtage eller udelade dem. Den kan ikke udskiftes med risikobehandlingsplanen, fund fra interne audits eller registreringer fra ledelsens evaluering. Brug disse artefakter sammen til at forklare både design og drift.

En politik fastlægger forventninger. En konfigurationseksport kan vise implementeringen. Resultater af adgangsgennemgange, afhjælpningssager og testregistreringer kan vise driften. Genbrug kun evidens, hvor system, periode og vurderingsmål stemmer overens.

Undgå faste overlapsprocenter. Dækningen afhænger af implementering og juridisk omfang; et universelt tal kan ikke fastslå parathed.

Byg en vej til hændelsesrapportering, der kan fungere under pres

En ISO-tilpasset responsplan kan understøtte detektion, inddæmning, undersøgelse og genopretning uden at definere regulatorisk underretning. NIS2 artikel 23 tilføjer rapporteringsforpligtelser for væsentlige hændelser.

Direktivets rapporteringstrin omfatter generelt:

• En tidlig varsling uden unødig forsinkelse og senest 24 timer efter at være blevet bekendt med en væsentlig hændelse.
• En hændelsesunderretning uden unødig forsinkelse og senest 72 timer efter, som opdaterer den tidlige varsling og giver en indledende vurdering.
• En endelig rapport som udgangspunkt senest en måned efter indsendelsen af hændelsesunderretningen. Ved en igangværende hændelse kræves på dette tidspunkt en statusrapport, og den endelige rapport skal da indsendes senest en måned efter, at hændelsen er håndteret.

Der skal også indsendes en foreløbig rapport, hvis CSIRT'en eller den kompetente myndighed anmoder om det.

Kontrollér gældende nationale og sektorspecifikke regler: Direktivet indeholder en anden tidsfrist for underretning for udbydere af tillidstjenester. Brug ikke en generisk tærskel for nedbrud som erstatning for de gældende kriterier for væsentlighed.

Som en praktisk anbefaling til implementeringen bør I udarbejde en runbook for rapportering, der angiver ejeren af vurderingen, eskaleringsvejen, den bemyndigede indsender, backuppersonale, myndighedskanalen og de oplysninger, der kræves på hvert trin. Registrér tidsstempler for detektion, kendskab, vurdering af væsentlighed og indsendelse hver for sig.

Øv processen med ufuldstændige oplysninger. Teamet skal kunne indsende den krævede første rapport uden at vente på en afsluttet forensisk undersøgelse. Bevar indsendte versioner, kvitteringer, understøttende fakta og beslutninger om, hvorvidt en hændelse når tærsklen.

Hvor en anden rapporteringsordning også gælder, skal undersøgelsen koordineres, men hver underretningspligt vurderes separat. En fælles hændelsesregistrering gør ikke modtagere, udløsere eller frister identiske.

Gør governance og robusthed demonstrerbare

Artikel 20 kræver, at ledelsesorganer godkender foranstaltningerne til styring af cybersikkerhedsrisici og fører tilsyn med implementeringen. Den omhandler også træning af ledelsesorganet. En eksisterende ledelsesevaluering er nyttig evidens, men kontrollér, om den eksplicit registrerer de relevante godkendelser, tilsyn, beslutninger og opfølgning.

Giv ledelsen et beslutningsklart overblik: berørte tjenester, væsentlige risici, behandlingsmuligheder, uafklarede undtagelser og effektivitetsresultater. Mødereferater, der blot siger »sikkerhed drøftet«, er ringe evidens for et reelt tilsyn. Tildel hver godkendt handling en ejer og en reviewdato.

Kontinuitet kræver en tilsvarende konkret behandling. Artikel 21 omfatter backup, katastrofeberedskab og krisestyring; den pålægger ikke et universelt krav om ISO 22301-certificering. Fastlæg den nødvendige dybde ud fra tjenesten, risiciene og de gældende regler.

Test gendannelse og genopretning af tjenester, ikke kun at backupjob gennemføres. Medtag afhængigheder som identitetstjenester, DNS, leverandørsupport, privilegerede legitimationsoplysninger og kommunikation, når det normale miljø er utilgængeligt. Registrér opnåede genopretningsresultater og uløste blokeringer op mod de aftalte mål.

Vedligehold et synligt register over forskelle

Registrér for hvert krav dets kilde og version, mappede kontroller, omfang, henvisninger til evidens, reviewer og begrundelse for genbrug. Skeln mellem understøttet dækning, delvis dækning, manglende implementering, manglende evidens og en begrundet beslutning om manglende anvendelighed. Fravær af et dokument betyder ikke altid fravær af en kontrol, men det kræver en undersøgelse.

Hver mangel kræver en ejer, en nødvendig ændring, en forventning til evidens, en frist og en reviewer til lukning. Prioritér svigt, der truer tjenester eller forhindrer tidskritisk rapportering, i stedet for at behandle enhver dokumentationsopgave som lige presserende.

Typiske fejl er kun at mappe Annex A og overse governancekravene, at acceptere et leverandørcertifikat uden at kontrollere dets omfang, at behandle sidste års evidens som aktuel og at lukke en opgave, når en politik er offentliggjort, men processen forbliver utestet. Registrering eller certificering bør aldrig behandles som bevis for operationel implementering.

Gennemregnet eksempel: udvidelse af et eksisterende ISMS

Illustrative antagelser: En udbyder af administrerede tjenester har et ISO 27001-certificeret ISMS, der dækker dens primære driftsteam. Anvendelighedsvurderingen konkluderer, at en tjeneste, der drives gennem en yderligere juridisk enhed, er omfattet af NIS2. Denne enhed bruger den samme identitetsplatform og det samme hændelsesteam, men har separate genopretningsordninger.

Teamet sammenligner først tjenesternes afgrænsning. Eksisterende autentificeringskonfigurationer kan understøtte begge omfang, men revieweren kontrollerer, om den yderligere enheds administratorer, nødkonti og tjenestekonti er medtaget. En eksport fra en adgangsgennemgang, der kun dækker det oprindelige team, kan ikke bevise fuldstændig dækning.

Dernæst bevarer hændelsesejeren den etablerede responsprocedure og tilføjer en vurdering af væsentlige hændelser og en vej til underretning af myndigheden. En skrivebordsøvelse simulerer et leverandørnedbrud med usikker påvirkning af kunder. Deltagerne registrerer, hvornår de blev bekendt med relevante fakta, hvem der afgjorde væsentligheden, og hvordan en tidlig varsling ville blive indsendt.

Endelig gennemfører infrastrukturejeren en genopretningsøvelse for den yderligere enheds tjeneste. Testen afslører, at legitimationsoplysningerne til genopretning afhænger af den utilgængelige identitetsplatform. Registret over mangler tildeler en korrigerende handling og kræver en vellykket gentest før lukning.

De resulterende leverancer er en sammenligning af omfang, gennemgåede mappings, udvidet evidens fra adgangsgennemgange, registreringer fra rapporteringsøvelsen, genopretningsresultater og ledelsens godkendelse af udestående behandlingshandlinger. Fælles kontroller forbliver fælles; enhedsspecifik evidens og enhedsspecifikke beslutninger forbliver synlige.

Gør vurderingen til vedligeholdt arbejde

Secanis model med forbundne krav og evidens giver teams en struktur til at bevare fælles arbejde og frameworkspecifikke beslutninger. Modellér tjenesterne og afhængighederne, knyt eksisterende evidens til relevante kontroller, og gør manglende dækning til opgaver med en ejer. Hold den menneskelige godkendelse eksplicit for mappings og evidenskonklusioner, også for AI-assisterede forslag. Vores vejledning i sporbar mapping på tværs af frameworks forklarer, hvordan begrundelsen for genbrug bevares.

Begynd med én reguleret tjeneste. Saml dens omfang, risikobehandling, anvendelighedserklæring, hændelsesrunbook og nyere testevidens i et fælles teknisk og compliance-mæssigt review. Producér et gennemgået register over forskelle, og brug derefter de normale ISMS-reviewcyklusser til at vedligeholde det, efterhånden som tjenester, leverandører og krav ændrer sig.