CVD for NIS2 og DORA: ISO 27001-kortlægning af revisionsbevis

Kl. 08:17 en tirsdag modtager sikkerhedspostkassen en besked fra en uafhængig sikkerhedsforsker. Emnelinjen er rolig, næsten høflig: “Potentiel kontoover­tagelse i jeres kundeportal.” Indholdet er mindre behageligt. Sikkerhedsforskeren hævder, at en kædet sårbarhed i jeres SaaS-applikation gør det muligt for én tenant at få adgang til en anden tenants fakturaregistre. Et proof of concept er vedhæftet, krypteret med jeres offentliggjorte PGP-nøgle.

For Maria, den nye CISO hos FinanTechSaaS, kunne timingen næppe være dårligere. Hendes virksomhed har netop underskrevet en stor kontrakt med en førende EU-bank. Kundens due diligence-team har allerede bedt om en “politik for koordineret offentliggørelse af sårbarheder” og bevis for implementering med eksplicit henvisning til NIS2 og DORA. Virksomheden har en security@-e-mailadresse, men den overvåges af én udvikler. Der findes intet formelt indrapporteringsregister, ingen defineret SLA for validering, ingen eskalationsvej til ledelsen og intet revisionsspor.

Tre ure begynder at tikke samtidig.

Det første ur er driftsmæssigt. Er sårbarheden reel? Kan den udnyttes i produktion? Bliver den aktivt misbrugt?

Det andet ur er regulatorisk. Hvis kundedata er eksponeret, begynder GDPR-vurderingen af brud på persondatasikkerheden. Hvis levering af tjenesten er påvirket for en væsentlig eller vigtig enhed efter NIS2, kan tærskler for hændelsesrapportering blive udløst. Hvis virksomheden er en finansiel enhed eller en IKT-udbyder, der understøtter finansielle tjenester, kan DORA’s regler om hændelsesstyring, klassificering, eskalering og kundekommunikation blive relevante.

Det tredje ur handler om revisionsbevis. Seks måneder senere kan en ISO/IEC 27001:2022-revisor, en finansiel tilsynsmyndighed, et kunde-assurance-team eller et internt revisionsudvalg spørge: “Vis os, hvordan denne sårbarhed blev håndteret.”

Det spørgsmål er ofte det punkt, hvor organisationer opdager, at koordineret offentliggørelse af sårbarheder ikke blot er en sikkerhedspostkasse. Det er et styringssystem. Det kræver politikejerskab, en offentlig rapporteringskanal, en triageproces, SLA’er for afhjælpning, leverandøreskalering, beslutningslogik for hændelser, databeskyttelsesvurdering, ledelsesrapportering og juridisk robust revisionsbevis.

Clarysec behandler CVD som et integreret kontrolmønster, ikke som en enkeltstående indbakke. I Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint indgår håndtering af sårbarheder i fasen kontroller i praksis, trin 19: teknologiske kontroller I, hvor vejledningen er klar: Organisationer bør ikke arkivere sårbarhedsfund passivt, men triagere dem, tildele ansvar og følge dem frem til lukning. Den samme standard gælder for eksterne offentliggørelser. Hvis nogen fortæller jer, hvordan jeres tjeneste kan svigte, bliver det reelle spørgsmål: Kan I dokumentere, at I modtog, vurderede, prioriterede, afhjalp, kommunikerede og lærte af det?

Hvorfor CVD nu er et bestyrelsesanliggende efter NIS2 og DORA

I årevis har sikkerhedsbevidste organisationer opfordret etiske hackere til at rapportere sårbarheder, fordi det var god praksis. Efter NIS2 og DORA er denne praksis blevet en del af reguleret digital robusthed.

NIS2 gælder for mange mellemstore og større enheder i sektorer med høj kritikalitet og andre kritiske sektorer, herunder udbydere af digital infrastruktur, cloud computing-tjenester, datacentertjenester, managed service providers, managed security service providers og visse digitale udbydere såsom online-markedspladser, søgemaskiner og sociale netværksplatforme. Den kan også gælde uanset størrelse for kategorier som tillidstjenesteudbydere, DNS-tjenesteudbydere, TLD-registre og udbydere af offentlige elektroniske kommunikationsnet eller -tjenester.

NIS2 Article 21 kræver, at væsentlige og vigtige enheder implementerer passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger til styring af cybersikkerhedsrisici ud fra en all-hazards-tilgang. Et af minimumsområderne er sikkerhed ved anskaffelse, udvikling og vedligeholdelse af net- og informationssystemer, herunder håndtering og offentliggørelse af sårbarheder. Den samme baseline omfatter også hændelseshåndtering, forsyningskædesikkerhed, forretningskontinuitet, adgangsstyring, politik for aktivstyring, træning, kryptografi og procedurer til vurdering af kontroleffektivitet.

NIS2 Article 20 gør også ledelsens ansvar eksplicit. Ledelsesorganer skal godkende foranstaltninger til styring af cybersikkerhedsrisici, føre tilsyn med implementeringen og gennemføre træning. For et CVD-program betyder det, at bestyrelsen eller den øverste ledelse skal forstå rapporteringskanalen, sårbarhedsberedskabsteamet (VRT), valideringsfrister, forventninger til afhjælpning, leverandørafhængigheder og udløsende kriterier for hændelsesrapportering.

DORA etablerer et sektorspecifikt regime for finansielle enheder fra 17. januar 2025. Det omfatter styring af IKT-risiko, rapportering af IKT-relaterede hændelser, test af digital operationel robusthed, informationsdeling, IKT-tredjepartsrisiko, kontraktlige krav, tilsyn med kritiske IKT-tredjepartsudbydere og tilsynssamarbejde. For finansielle enheder omfattet af DORA har DORA generelt forrang for NIS2 vedrørende styring af IKT-risiko og hændelsesrapportering, fordi den er den sektorspecifikke EU-retsakt. Men det praktiske krav er det samme: Finansielle enheder og IKT-udbydere, der leverer til dem, skal drive en struktureret, dokumenteret og testbar proces til at identificere, analysere, klassificere, eskalere, afhjælpe og lære af IKT-svagheder.

En sårbarhedsrapport kan begynde som et teknisk fund, blive til en informationssikkerhedshændelse, eskalere til en hændelse, udløse en GDPR-vurdering af brud på persondatasikkerheden, kræve leverandørhandling og senere optræde i ISO/IEC 27001:2022-erklæringen om anvendelighed. Derfor bør CVD udformes som én samlet driftsmodel på tværs af sikkerhed, compliance, engineering, jura, databeskyttelse, indkøb og ledelse.

ISO 27001-fundamentet: fra offentliggørelse til ISMS-revisionsbevis

ISO/IEC 27001:2022 giver CISO’er og compliance-ansvarlige det ledelsessystem, der gør CVD revisionsbar.

Klausul 4.1 til 4.4 kræver, at organisationen forstår interne og eksterne forhold, interessenters krav, ISMS-afgrænsning og afhængigheder til andre organisationer. Det er her NIS2, DORA, GDPR, kundekontrakter, leverandørforpligtelser og forpligtelser vedrørende offentliggørelse af sårbarheder indgår i ISMS.

Klausul 5.1 til 5.3 etablerer ledelsens ansvar. Øverste ledelse skal tilpasse informationssikkerhed til den strategiske retning, stille ressourcer til rådighed, tildele ansvar og sikre, at ISMS opnår de tilsigtede resultater. For CVD betyder det at udpege et sårbarhedsberedskabsteam, definere bemyndigelse til at acceptere restrisiko og eskalere sårbarheder med høj påvirkning til ledelsen.

Klausul 6.1.1 til 6.1.3 udgør risikomotoren. Organisationen skal definere risikokriterier, vurdere informationssikkerhedsrisici, tildele risikoejere, vælge muligheder for risikobehandling, sammenholde kontroller med Anneks A, udarbejde en erklæring om anvendelighed og opnå godkendelse af restrisiko. Klausul 8.1 til 8.3 kræver derefter operationel styring, planlagte ændringer, styring af eksternt leverede processer, risikovurderinger med planlagte intervaller eller efter væsentlige ændringer samt bevis for behandlingsresultater.

I Zenith Blueprint, risikostyringsfasen, trin 13, beskrives erklæringen om anvendelighed som mere end et regneark til compliance:

“SoA’en er reelt et brodokument: Den forbinder jeres risikovurdering/-behandling med de faktiske kontroller, I har.”
Kilde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, risikostyringsfasen, trin 13: planlægning af risikobehandling og Statement of Applicability (SoA) Zenith Blueprint

For koordineret offentliggørelse af sårbarheder bør SoA’en forbinde regulatoriske forpligtelser, forretningsrisiko, Anneks A-kontroller, politikklausuler og driftsmæssigt revisionsbevis.

Målet er ikke at skabe parallelle compliance-siloer. CVD-politikken bør være en kontrolleret ISMS-proces, der samtidig understøtter ISO/IEC 27001:2022-certificering, NIS2-efterlevelse, DORA-beredskab, kundedokumentation og sikkerhedsdrift.

Politikbaseline: hvad jeres CVD-politik skal fastsætte

Den første synlige kontrol er den offentlige rapporteringskanal. Sikkerhedsforskere, kunder, leverandører og partnere skal vide, hvor de skal rapportere sårbarheder, og hvordan de skal beskytte følsomt bevismateriale.

Clarysecs Politik for koordineret offentliggørelse af sårbarheder Politik for koordineret offentliggørelse af sårbarheder leverer organisationens baseline:

“Offentlige kanaler for offentliggørelse: Organisationen skal opretholde en tydelig kanal til rapportering af sårbarheder, såsom en særskilt e-mailadresse til sikkerhedskontakt (f.eks. security@company.com) eller en webformular. Disse oplysninger skal offentliggøres på virksomhedens sikkerhedsside sammen med organisationens offentlige PGP-nøgle for at muliggøre krypterede indsendelser.”
Kilde: Politik for koordineret offentliggørelse af sårbarheder, implementeringskrav, klausul 6.1

Denne klausul løser en almindelig revisionsmangel. Mange organisationer hævder, at de modtager rapporter, men rapporteringsvejen er skjult, ukrypteret eller ejet af det forkerte team. En moden kanal er offentlig, sikker, overvåget og tildelt en ansvarlig funktion.

Den næste kontrol er disciplin i responsen. En kritisk rapport efterfulgt af tavshed skaber offentliggørelsesrisiko, omdømmerisiko og udnyttelsesrisiko. Politik for koordineret offentliggørelse af sårbarheder fastsætter en konkret forventning til bekræftelse og validering:

“Triage og bekræftelse: Ved modtagelse af en rapport skal VRT registrere den og sende en bekræftelse til rapportøren inden for 2 arbejdsdage med tildeling af en sporingsreference. VRT skal foretage en foreløbig alvorlighedsvurdering, f.eks. ved brug af CVSS-scoring, og validere forholdet, herunder med støtte fra IT- og udviklingsteams, hvor det er nødvendigt, inden for en fastsat tidsramme på 5 arbejdsdage. Kritiske sårbarheder, såsom sårbarheder der muliggør fjernudførelse af kode eller et større brud på persondatasikkerheden, skal fremskyndes.”
Kilde: Politik for koordineret offentliggørelse af sårbarheder, implementeringskrav, klausul 6.4

Denne formulering skaber umiddelbare bevispunkter: modtagelsestidspunkt, bekræftelsestidspunkt, sporingsreference, foreløbig alvorlighed, valideringsresultat og beslutning om fremskyndet håndtering.

For SMV’er anvender Clarysec den samme logik med forholdsmæssig implementering. Politik for krav til applikationssikkerhed - SME Politik for krav til applikationssikkerhed - SME kræver, at organisationer:

“angiver forpligtelser for offentliggørelse af sårbarheder, responstider og patchning.”
Kilde: Politik for krav til applikationssikkerhed - SME, styringskrav, klausul 5.3.2

I behøver ikke et stort produktsikkerhedsteam for at være ansvarlige. I har brug for eksplicitte forpligtelser, realistiske tidsfrister, navngivne ejere og bevis for, at processen fungerer.

CVD-indrapporteringsprocessen: fra researcher-e-mail til beslutningsregistrering

En god indrapporteringsproces er enkel nok til at fungere under pres og fuldstændig nok til at tilfredsstille en revisor. Den bør begynde med en særskilt kanal såsom security@[company], en webformular eller en offentliggjort security.txt-fil. Indsendelsesvejen bør muliggøre krypteret bevismateriale, angivelse af berørt produkt eller endpoint, reproduktionstrin, kontaktoplysninger på rapportøren, foretrukken timing for offentliggørelse og eventuel indikation af dataeksponering eller aktiv udnyttelse.

Når rapporten er modtaget, bør sårbarhedsberedskabsteamet oprette en registrering i et GRC-værktøj, en ticketingplatform, et system til sårbarhedsstyring eller et kontrolleret register. Værktøjet er mindre vigtigt end konsistens og kvaliteten af bevismaterialet.

Processen bør derefter gennemløbe syv operationelle trin.

1. Indrapportering: Rapporten modtages via den offentlige kanal og logges automatisk eller manuelt.
2. Bekræftelse: VRT svarer inden for 2 arbejdsdage og tildeler en sporingsreference.
3. Validering: Det tekniske team reproducerer forholdet, bekræfter berørte systemer og foretager foreløbig alvorlighedsscoring.
4. Hændelsesvurdering: VRT afgør, om sårbarheden alene er en svaghed, en informationssikkerhedshændelse eller en hændelse.
5. Eskalering: Høje eller kritiske forhold sendes til systemejere, CISO, databeskyttelse, jura, leverandører og ledelse efter behov.
6. Afhjælpning: Det ansvarlige team implementerer en rettelse, risikobegrænsende foranstaltning, kompenserende kontrol eller midlertidig begrænsning.
7. Lukning: VRT verificerer rettelsen, kommunikerer med rapportøren, opdaterer bevisfilen og registrerer læringspunkter.

Clarysec kortlægger dette operationelle trin til ISO/IEC 27002:2022 control A.5.25, vurdering af og beslutning om informationssikkerhedshændelser, og control A.8.8, styring af tekniske sårbarheder, gennem Zenith Controls: The Cross-Compliance Guide Zenith Controls. For A.5.25 forklarer Zenith Controls, at hændelsesvurdering er triagefunktionen mellem rå overvågningsalarmer og formel hændelseshåndtering, hvor logfiler, tærskler og beslutningskriterier anvendes til at afgøre eskalering. For A.8.8 forbinder Zenith Controls teknisk sårbarhedsstyring med malwarebeskyttelse, konfigurationsstyring, ændringsstyring, endpointsikkerhed, trusselsinformation, overvågning, sikker udvikling, hændelsesvurdering og hændelseshåndtering.

Ét afsnit fra Zenith Controls er særligt nyttigt, når der er mistanke om aktiv udnyttelse:

“Trusselsinformation viser, hvilke sårbarheder der udnyttes aktivt, og styrer prioriteringen af patchning.”
Kilde: Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022 control 8.8, kobling til control 5.7 Threat Intelligence Zenith Controls

Dette er et vigtigt styringspunkt. Alvorlighed er ikke kun CVSS. En sårbarhed med middel score, som aktivt udnyttes mod jeres sektor, kan have højere prioritet end et teoretisk kritisk forhold på et ikke-eksponeret testsystem.

Når en sårbarhed bliver til en hændelse

Ikke alle sårbarhedsrapporter er hændelser. En manglende sikkerhedsheader i et stagingmiljø er ikke det samme som en udnyttet omgåelse af autorisation, der eksponerer kundefakturaer. Men enhver troværdig sårbarhedsrapport bør passere gennem en beslutningsport for hændelser.

NIS2 Article 23 kræver, at væsentlige og vigtige enheder uden unødig forsinkelse underretter deres CSIRT eller kompetente myndighed om hændelser, der væsentligt påvirker levering af tjenester. En væsentlig hændelse er en hændelse, der har forårsaget eller kan forårsage alvorlige driftsafbrydelser eller økonomisk tab, eller som har påvirket eller kan påvirke andre ved at forårsage betydelig materiel eller immateriel skade. Rapporteringssekvensen omfatter en tidlig advarsel inden for 24 timer efter, at man er blevet bekendt med hændelsen, en hændelsesunderretning inden for 72 timer, mellemliggende rapporter efter anmodning og en endelig rapport inden for én måned efter 72-timers-underretningen.

DORA Articles 17 to 20 kræver, at finansielle enheder detekterer, håndterer, registrerer, klassificerer, eskalerer, underretter om og kommunikerer IKT-relaterede hændelser og væsentlige cybertrusler. Større IKT-relaterede hændelser skal eskaleres til øverste ledelse og ledelsesorganet. Kundekommunikation kan være påkrævet, når finansielle interesser påvirkes.

For SMV’er skal rapporteringskulturen være lige så klar. Clarysecs Politik for hændelseshåndtering - SME Politik for hændelseshåndtering - SME fastslår:

“Medarbejdere skal rapportere enhver mistænkelig aktivitet eller bekræftet hændelse til incident@[company] eller mundtligt til direktøren eller IT-leverandøren.”
Kilde: Politik for hændelseshåndtering - SME, krav til implementering af politikken, klausul 6.2.1

I Zenith Blueprint, fasen kontroller i praksis, trin 16: personrelaterede kontroller II, er princippet endnu enklere:

“Ved tvivl: rapportér.”
Kilde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fasen kontroller i praksis, trin 16: personrelaterede kontroller II (A.6.5 to A.6.8)

Denne sætning bør gælde for udviklere, supportteams, leverandøransvarlige, databeskyttelsesansvarlige, topledere og outsourcede udbydere. En sårbarhed, der kan påvirke fortrolighed, integritet, tilgængelighed, kundetillid, regulatorisk rapportering eller finansielle aktiviteter, skal registreres og vurderes — ikke håndteres uformelt i chat.

Afhjælpning, patchning og kompenserende kontroller

Når en sårbarhed er valideret, skal den behandles. Behandlingen bør være risikobaseret, understøttet af bevismateriale og tidsafgrænset.

Politik for koordineret offentliggørelse af sårbarheder fastsætter organisationens forventning:

“Afhjælpningsplan: Der skal udarbejdes en afhjælpnings- eller risikobegrænsningsplan for alle bekræftede sårbarheder. Implementering af rettelsen skal prioriteres på grundlag af alvorlighed. Eksempelvis skal kritiske sårbarheder rettes eller begrænses inden for 14 dage, hvor det er muligt, eller hurtigere hvor aktiv udnyttelse detekteres, mens forhold med lavere alvorlighed skal håndteres inden for en rimelig tidsramme. Hvor en fuld rettelse forsinkes, skal kompenserende kontroller eller midlertidige risikobegrænsende foranstaltninger, såsom deaktivering af sårbar funktionalitet eller øget overvågning, implementeres.”
Kilde: Politik for koordineret offentliggørelse af sårbarheder, implementeringskrav, klausul 6.6

For SMV’ers patchdisciplin fastslår Politik for sårbarheds- og patchstyring - SME Politik for sårbarheds- og patchstyring - SME:

“Kritiske patches skal anvendes inden for 3 dage efter frigivelse, særligt for internetvendte systemer”
Kilde: Politik for sårbarheds- og patchstyring - SME, krav til implementering af politikken, klausul 6.1.1

Disse tidsfrister er ikke modstridende. En leverandørpatch til et internetvendt system kan kræve meget hurtig udrulning. En produktsårbarhed, der kræver kodeændringer, regressionstest, kundekoordinering og trinvis release, kan kræve en afhjælpningsplan med midlertidige risikobegrænsninger. Det centrale er, at beslutningen dokumenteres, ejes som risiko og godkendes, hvor restrisiko består.

Et praktisk sagsforløb kan se sådan ud:

1. En sikkerhedsforsker rapporterer en omgåelse af autorisation i kundernes fakturerings-API.
2. VRT logger CVD-2026-014 med tidsstempel og bekræfter modtagelsen inden for 2 arbejdsdage.
3. Produktsikkerhed validerer fejlen inden for 24 timer og tildeler høj alvorlighed på grund af adgang til data på tværs af tenants.
4. Databeskyttelsesfunktionen gennemfører en GDPR-vurdering af brud på persondatasikkerheden, fordi fakturaregistre kan indeholde personoplysninger.
5. Hændelsesansvarlig åbner en hændelsesvurdering efter ISO/IEC 27002:2022 control A.5.25.
6. Systemejeren deaktiverer det sårbare endpoint via et midlertidigt feature flag.
7. Engineering opretter et hotfix efter ISO/IEC 27002:2022 control A.8.32, ændringsstyring.
8. Overvågningsregler tilføjes for indikatorer på udnyttelse og kobles til A.8.15, logning, og A.8.16, overvågningsaktiviteter.
9. CISO orienterer øverste ledelse, fordi forholdet er højrisiko.
10. VRT koordinerer med sikkerhedsforskeren om gentest og timing for offentliggørelse.
11. Risikoejeren godkender først lukning efter verifikationstest og gennemgang af kundepåvirkning.
12. SoA, risikoregister, ticket, logfiler, ledelsesunderretning og læringspunkter opdateres.

Det er forskellen mellem “vi patchede det” og “vi kan dokumentere, at vi styrede det.”

Leverandør- og cloudafhængigheder: det skjulte fejlpunkt

Mange CVD-svigt er i realiteten leverandørsvigt. Sårbarheden kan påvirke en SaaS-komponent, cloudtjeneste, managed security provider, betalingsgateway, autentifikationsbroker, open source-bibliotek, outsourcet udviklingsteam eller underleverandør.

NIS2 Article 21 kræver forsyningskædesikkerhed, herunder relationer til direkte leverandører og tjenesteudbydere. Foranstaltninger i forsyningskæden bør tage højde for leverandørsårbarheder, produktkvalitet, cybersikkerhedspraksis og procedurer for sikker udvikling.

DORA Articles 28 to 30 går dybere for finansielle enheder. De kræver, at IKT-tredjepartsrisiko styres som en del af rammeværket for IKT-risiko med registre over IKT-servicekontrakter, sondring mellem kritiske og vigtige funktioner, due diligence før kontraktindgåelse, kontraktlige sikkerhedskrav, hændelsesbistand, samarbejde med myndigheder, revisionsrettigheder, ophørsrettigheder og exitstrategier. Finansielle enheder forbliver fuldt ansvarlige for DORA-efterlevelse, selv når de anvender IKT-tredjepartsudbydere.

Clarysecs Politik for tredjeparts- og leverandørsikkerhed - SME Politik for tredjeparts- og leverandørsikkerhed - SME indeholder en enkel eskaleringsregel:

“Skal straks underrette direktøren om ethvert sikkerhedsbrud, enhver ændring eller enhver hændelse”
Kilde: Politik for tredjeparts- og leverandørsikkerhed - SME, roller og ansvar, klausul 4.4.3

For leverandørkontrakter i større organisationer anbefaler Zenith Blueprint, fasen kontroller i praksis, trin 23, at der medtages fortrolighedsforpligtelser, ansvar for adgangsstyring, tekniske og organisatoriske foranstaltninger, tidsfrister for hændelsesrapportering, revisionsret, kontroller for underleverandører og bestemmelser ved kontraktophør. Den fastslår:

“Det afgørende er, at de findes, og at de forstås og accepteres af begge parter.”
Kilde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fasen kontroller i praksis, trin 23: organisatoriske kontroller (5.19 to 5.37)

CVD-beredskab hos leverandører bør kunne besvare disse spørgsmål:

• Offentliggør leverandøren en kanal til rapportering af sårbarheder?
• Er tidsfrister for underretning om sårbarheder defineret i kontrakten?
• Rapporteres kritiske leverandørsårbarheder uden unødig forsinkelse?
• Er kundepåvirkende svagheder koblet til forpligtelser om hændelsesbistand?
• Kan leverandøren levere bevismateriale for afhjælpning eller sikkerhedsmeddelelser?
• Videreføres leverandørens sårbarhedsforpligtelser til underleverandører?
• Findes der en exitstrategi, hvis afhjælpningen er utilstrækkelig?

Det er her NIS2, DORA og ISO/IEC 27001:2022 mødes. Styring af leverandørsårbarheder er ikke et afkrydsningsfelt i indkøb. Det er en del af operationel robusthed.

Kortlægning af revisionsbevis for ISO 27001, NIS2, DORA, GDPR og COBIT

De stærkeste CVD-programmer er designet med revisionsbevis først. De antager, at enhver væsentlig rapport senere kan blive gennemgået af intern revision, certificeringsrevisorer, regulatorer, kunder, forsikringsselskaber eller et bestyrelsesrisikoudvalg.

Clarysecs Politik for audit- og efterlevelsesovervågning - SME Politik for audit- og efterlevelsesovervågning - SME fremhæver en detalje, mange teams overser:

“Metadata (f.eks. hvem der indsamlede det, hvornår og fra hvilket system) skal dokumenteres.”
Kilde: Politik for audit- og efterlevelsesovervågning - SME, krav til implementering af politikken, klausul 6.2.3

Et screenshot af en patchet server er svagt, hvis ingen ved, hvem der tog det, hvornår, fra hvilket system, og hvordan det knytter sig til sårbarheden. En ticket med tidsstempler, scanner-output, pull request, ændringsgodkendelse, udrulningslogfiler, overvågningsforespørgsel, bekræftelse fra gentest og metadata er langt stærkere.

En mere detaljeret sporbarhedsmatrix hjælper ved kunders due diligence og intern revision.

Forskellige revisorer vil teste den samme proces gennem forskellige perspektiver.

En ISO/IEC 27001:2022-revisor vil begynde med ISMS. Revisoren vil spørge, om forpligtelser vedrørende offentliggørelse af sårbarheder er medtaget i interessentkrav, om risici vurderes konsistent, om kontroller fremgår af SoA, om der findes driftsmæssigt bevis, og om ledelsen gennemgår tendenser og forfaldne forhold.

En DORA- eller finansiel reviewer vil fokusere på operationel robusthed. Vedkommende vil undersøge integration af IKT-risiko, hændelsesklassificering, eskalering til øverste ledelse, kundekommunikation, tredjepartsafhængigheder, test og læringspunkter. Hvis sårbarheden påvirker en kritisk eller vigtig funktion, forventes der tæt sammenhæng mellem den tekniske ticket, forretningspåvirkning, konsekvenser for kontinuitet og leverandørforpligtelser.

En GDPR-reviewer vil fokusere på personoplysninger. Var personoplysninger involveret? Var der uautoriseret adgang, tab, ændring eller offentliggørelse? Var rollerne som dataansvarlig og databehandler klare? Blev tærsklen for brud på persondatasikkerheden vurderet? Var sikkerhedsforanstaltninger som kryptering, adgangsstyring, logning og dataminimering relevante?

En COBIT 2019- eller ISACA-revisor vil fokusere på governance, ansvar, performance og assurance. De vil se efter defineret ejerskab, metrikker, eskalering, kontrolmål, ledelsestilsyn og sporing af undtagelser. En forfalden kritisk sårbarhed er ikke kun et teknisk problem. Det er et styringsproblem, medmindre det formelt eskaleres og risikoaccepteres.

En NIST-orienteret assessor vil tænke i Identify, Protect, Detect, Respond og Recover. Vedkommende vil forvente aktivejerskab, identifikation af sårbarheder, prioritering, beskyttende ændring, detektion af udnyttelse, responskoordinering og validering af genopretning.

Fordelen ved en integreret CVD-model er, at den samme rygrad af revisionsbevis kan understøtte alle disse gennemgange.

Den månedlige kontrolsløjfe: metrikker ledelsen kan bruge

CVD slutter ikke, når ticketen lukkes. Politik for koordineret offentliggørelse af sårbarheder kræver løbende loggennemgang:

“VRT skal vedligeholde en log for offentliggørelse af sårbarheder, der følger hver rapport fra modtagelse til lukning. Loggen skal gennemgås månedligt for at sikre rettidig fremdrift for åbne forhold. Forfaldne forhold skal eskaleres.”
Kilde: Politik for koordineret offentliggørelse af sårbarheder, overvågning og revision, klausul 9.1

Denne månedlige gennemgang gør offentliggørelse af sårbarheder til styring, der kan anvendes i bestyrelsesrapportering. Ledelsen har ikke brug for alle tekniske detaljer. Den har brug for trend, eksponering, ansvar og forfalden risiko.

I en moden Clarysec-implementering indgår denne månedlige loggennemgang i risikoregistret, erklæringen om anvendelighed, backloggen for sikker udvikling, leverandørgennemgange, læringspunkter fra hændelser, intern revisionsplan og ledelsesrapporteringspakke.

Byg processen, før den alvorlige rapport ankommer

Det værste tidspunkt at designe koordineret offentliggørelse af sårbarheder på er, efter at en sikkerhedsforsker har offentliggjort jeres svaghed, eller en kritisk bankkunde har sat onboarding i bero. NIS2, DORA, GDPR, ISO/IEC 27001:2022, NIST-lignende forventninger til robusthed og COBIT 2019-styring peger alle i samme retning: Offentliggørelse af sårbarheder skal planlægges, ejes, testes, dokumenteres og forbedres.

Start med disse fem handlinger:

1. Vedtag eller tilpas Politik for koordineret offentliggørelse af sårbarheder.
2. Opbyg indrapporterings- og triageprocessen med Zenith Blueprint, især trin 13 for SoA-sporbarhed, trin 16 for rapporteringskultur, trin 19 for teknisk sårbarhedsstyring og trin 23 for leverandøraftaler.
3. Kortlæg processen gennem Zenith Controls med fokus på ISO/IEC 27002:2022 controls A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 og A.8.32.
4. Tilføj SMV-egnede klausuler fra Politik for hændelseshåndtering - SME, Politik for sårbarheds- og patchstyring - SME, Politik for tredjeparts- og leverandørsikkerhed - SME, Politik for krav til applikationssikkerhed - SME og Politik for audit- og efterlevelsesovervågning - SME, hvor proportionalitet er vigtig.
5. Gennemfør en tabletop-øvelse, der simulerer en researcher-rapport, som påvirker personoplysninger og en leverandørhostet komponent, og test derefter bekræftelse, triage, hændelsesklassificering, patchning, kundekommunikation, indsamling af revisionsbevis og eskalering til ledelsen.

Clarysec kan hjælpe jer med at omsætte dette til en fungerende CVD-politik, et indrapporteringsregister, en ISO/IEC 27001:2022-kortlægning af revisionsbevis, et NIS2- og DORA-beslutningstræ, en model for leverandøreskalering og en revisionsklar kontrolpakke. Målet er enkelt: Når den næste sårbarhedsrapport ankommer, skal jeres team ikke improvisere. Det skal eksekvere med sikkerhed, revisionsbevis og kontrol.