EU CRA-sikkerhedssupportperioder med ISO 27001-styring

Klokken er 08:20 en tirsdag, og produktejeren for en forbundet B2B-gateway modtager en besked fra en reguleret kunde: “Bekræft venligst sikkerhedssupportperioden for firmwareversion 4.6, SLA’en for sårbarhedsrespons, og om enheden fortsat vil være berettiget til sikkerhedsopdateringer i vores femårige servicekontrakt.”

Klokken 09:00 har indkøb videresendt et DORA-spørgeskema om due diligence. Klokken 10:15 spørger juridisk afdeling, om den annoncerede supportperiode er i overensstemmelse med kundekontrakterne. Klokken 11:00 bliver CISO’en inddraget i en NIS2-gennemgang af leverandørrisiko, fordi produktet anvendes af en MSP i EU. Efter frokost spørger databeskyttelsesfunktionen, om et ikke-understøttet API-bibliotek i produktet kan påvirke sikkerheden for personoplysninger efter GDPR.

Den ubehagelige sandhed viser sig hurtigt. Virksomheden har en roadmap, en patchproces, en releasekalender og en kundesupportportal, men den har ikke styret bevismateriale for sikkerhedssupportperioder.

Det hul har betydning. Efter EU’s forordning om cyberrobusthed er sikkerhedssupportperioden ikke blot en produktmærkning. Den er en livscyklusforpligtelse, der påvirker sårbarhedshåndtering, tilgængelighed af opdateringer, styring af leverandørafhængigheder, kundekommunikation, kontraktlige tilkendegivelser og markedsovervågning efter markedsføring. For SaaS-leverandører, enhedsproducenter, softwareudgivere, cloudleverandører og IKT-tjenesteudbydere bliver supportperioden et efterlevelsesobjekt, som revisorer og regulerede købere vil teste.

Det praktiske svar er ikke endnu et løsrevet compliance-regneark. Svaret er at styre sikkerhedssupportperioden i et ISO/IEC 27001:2022-ledelsessystem for informationssikkerhed og derefter kortlægge det samme bevismateriale til NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT-lignende revisionsforventninger.

Det er Clarysecs driftsmodel: brug ISMS som motor for bevismateriale, brug håndhævelige politikker til at definere ansvar, brug Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint til at opbygge sporbarhed, og brug Zenith Controls: The Cross-Compliance Guide Zenith Controls som kompas for kortlægning på tværs af efterlevelseskrav.

Hvorfor sikkerhedssupportperioden nu er et revisionsobjekt

En sikkerhedssupportperiode besvarer ét enkelt spørgsmål: Hvor længe vil producenten levere sikkerhedsopdateringer, sårbarhedsafhjælpning, vejledning om afbødning og tilknyttet kundesupport for et produkt eller en produktversion?

I praksis afhænger svaret af mange bevægelige dele:

• Produktarkitektur og vedligeholdbarhed
• Support for tredjepartskomponenter og open source-afhængigheder
• Forpligtelser fra leverandører og cloudtjenester
• Processer for modtagelse, triage, afhjælpning og offentliggørelse af sårbarheder
• Kapacitet til release engineering og test
• Kundekontraktvilkår og regulatoriske forpligtelser
• Hændelseshåndtering og underretningsveje til tjenestemodtagere
• Opbevaring af bevismateriale og godkendelsesregistreringer

Hvis en producent lover fem års sikkerhedssupport, men et kritisk kryptografisk bibliotek ikke længere understøttes efter tre år, bliver supportperioden en risikobeslutning. Hvis en kunde er en finansiel enhed omfattet af DORA, bliver den samme supportperiode en del af assurance vedrørende IKT-tredjeparter. Hvis produktet behandler personoplysninger, kan ikke-understøttet software blive en del af ansvarligheden for behandlingssikkerhed efter GDPR. Hvis produktet understøtter en væsentlig eller vigtig enhed efter NIS2, bliver livscyklussikkerhed et spørgsmål om sikkerhed i forsyningskæden.

NIS2 gør denne styringsvinkel eksplicit. Article 20 kræver, at ledelsesorganer i væsentlige og vigtige enheder godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og modtager uddannelse. Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse, sikker udvikling og vedligeholdelse, sårbarhedshåndtering og offentliggørelse, vurdering af effektivitet, cyberhygiejne, kryptografi, adgangsstyring, styring af aktiver og autentifikation. Article 23 tilføjer trinvise rapporteringsforpligtelser for væsentlige hændelser.

DORA skaber et tilsvarende pres for finansielle enheder. DORA kræver styring af IKT-risiko, test af digital operationel robusthed, hændelsesstyring og styring af IKT-tredjepartsrisiko. DORA Article 28 dækker principper for styring af IKT-tredjepartsrisiko, og Article 30 kræver skriftlige kontraktlige ordninger med klare tjenestebeskrivelser, sikkerhedsforanstaltninger, hændelsesbistand, revisionsrettigheder, opsigelsesrettigheder og exitordninger.

GDPR tilføjer databeskyttelseslaget. Hvis produktet behandler personoplysninger, har dataansvarlige og databehandlere behov for passende tekniske og organisatoriske foranstaltninger efter Article 32, kontraktlig klarhed efter Article 28 samt beredskab til vurdering af brud og anmeldelse/underretning efter Articles 33 og 34.

Derfor skal CRA-sikkerhedssupportperioden styres som en ISMS-kontrolfamilie og ikke håndteres som et isoleret produktstyringsfelt.

ISO 27001 som kontrolrygrad for CRA-sikkerhedssupportperioder

ISO/IEC 27001:2022 er værdifuld, fordi standarden er skalerbar, risikobaseret og orienteret mod ledelsessystemer. Den kræver, at organisationen definerer kontekst, interessenter, omfang og interagerende processer og derefter omsætter juridiske, regulatoriske og kontraktlige krav til risikovurdering, risikobehandling, operationelle kontroller og bevismateriale ISO/IEC 27001:2022.

For styring af sikkerhedssupportperioder betyder det, at organisationen skal:

1. Identificere produkter, versioner, moduler, cloudtjenester og afhængigheder inden for omfanget.
2. Identificere interessenter, herunder kunder, tilsynsmyndigheder, distributører, importører, systemintegratorer, databehandlere, underdatabehandlere, partnere inden for hændelseshåndtering og leverandører.
3. Registrere juridiske, regulatoriske og kontraktlige supportforpligtelser.
4. Vurdere risici, der kan forhindre, at supportforpligtelser opfyldes.
5. Udvælge kontroller for sårbarhedsstyring, sikker udvikling, assurance vedrørende leverandører, hændelsesstyring, forretningskontinuitet, databeskyttelse og dokumenterede oplysninger.
6. Oprette noter til anvendelighedserklæringen, der forklarer, hvorfor kontrollerne finder anvendelse.
7. Gennemgå supportperioden, når arkitektur, leverandørafhængigheder, trusselseksponering eller kundeforpligtelser ændrer sig.

Zenith Controls identificerer tre emnerelaterede ISO/IEC 27002:2022-kontroller som centrale ankre for dette styringsproblem: 5.31 juridiske, lovbestemte, regulatoriske og kontraktlige krav, 8.8 styring af tekniske sårbarheder og 8.25 sikker udviklingslivscyklus. De er ikke de eneste involverede kontroller, men de udgør styringsrygraden.

Det centrale er sporbarhed. En produktsupportperiode skal kunne spores fra forpligtelse til risikoscenarie, fra risikoscenarie til udvalgte kontroller, fra kontroller til politikkrav og fra politikkrav til bevismateriale.

Zenith Blueprint, risikostyringsfasen, Step 13, beskriver denne sporbarhedsdisciplin direkte:

“Krydshenvis regler: Hvis bestemte kontroller implementeres specifikt for at efterleve GDPR, NIS2 eller DORA, kan du notere det enten i risikoregisteret (som en del af begrundelsen for risikokonsekvens) eller i SoA-noterne.”

Kilde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, risikostyringsfasen, Step 13: Risikobehandlingsplanlægning og anvendelighedserklæring Zenith Blueprint

For en CRA-sikkerhedssupportperiode bør anvendelighedserklæringen ikke blot sige “sårbarhedsstyring finder anvendelse”. Den bør forklare, at sårbarhedsstyring finder anvendelse, fordi virksomheden har CRA-livscyklusforpligtelser, NIS2-forventninger til sikker udvikling og forsyningskæde, DORA-krav fra kunder om due diligence, GDPR-sikkerhedsforpligtelser, hvor personoplysninger behandles, og kontraktlige supportløfter.

Fra supportløfte til styret livscyklus

En producentdefineret sikkerhedssupportperiode bør bestå seks styringstest.

For det første skal den defineres. Organisationen har behov for en standardtaksonomi, f.eks. aktiv support, kun sikkerhedssupport, udvidet support, begrænset support og ikke-understøttet. Hver status bør forklare tilgængelighed af opdateringer, sårbarhedshåndtering, kundekommunikation og eskalationsveje.

For det andet skal den risikovurderes. Fem års support for et cloudadministreret SaaS-produkt med kontrollerede opdateringskanaler er noget andet end fem år for en indlejret enhed med feltmæssige begrænsninger, tredjepartsafhængigheder til chips og kundestyrede udrulningsvinduer.

For det tredje skal den godkendes. Produkt, sikkerhed, juridisk afdeling, databeskyttelse, kundesupport og ansvarlig ledelse bør godkende baselineperioden og undtagelser.

For det fjerde skal den kommunikeres. Kunderne bør forstå supportens startdato, slutdato, opdateringsmetode, kanal til indberetning af sårbarheder, forventninger til afhjælpning, konsekvenser ved supportophør og tilgængelige muligheder for forlængelse.

For det femte skal den overvåges. Afhængigheder ændrer sig. Leverandører udfaser biblioteker. Sårbarheder opstår. Kundemiljøer ændrer sig. Styring af supportperioder skal omfatte overvågning af komponenters livscyklus, leverandørgennemgang, sårbarhedsfeeds, patchlogs, release-test og læringspunkter fra hændelser.

For det sjette skal den dokumenteres med bevismateriale. Hvis en revisor, tilsynsmyndighed eller reguleret kunde beder om dokumentation, bør organisationen kunne fremvise efterlevelsesregisteret, produktsupportregisteret, risikovurderingen, SoA-kortlægningen, sårbarhedsregisteret, patchregistreringer, leverandørgennemgange, release-godkendelser og kundemeddelelser.

Clarysec-politikker gør dette praktisk. Enterprise Politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse kræver:

“Alle juridiske og regulatoriske forpligtelser skal kortlægges til specifikke politikker, kontroller og ejere i ledelsessystemet for informationssikkerhed (ISMS).”

Kilde: Politik for juridisk og regulatorisk efterlevelse, krav til implementering af politikken, punkt 6.2.1 Politik for juridisk og regulatorisk efterlevelse

For SMV’er starter den tilsvarende disciplin med et enklere register. SMV-udgaven Politik for juridisk og regulatorisk efterlevelse-sme Politik for juridisk og regulatorisk efterlevelse - SME fastslår:

“Direktøren skal vedligeholde et enkelt, struktureret efterlevelsesregister, der angiver:”

Kilde: Politik for juridisk og regulatorisk efterlevelse-sme, styringskrav, punkt 5.1.1 Politik for juridisk og regulatorisk efterlevelse - SME

En forpligtelse vedrørende supportperiode bør fremgå af efterlevelsesregisteret, hvis den følger af lovgivning, kundekontrakt, sektorregulering eller forventninger fra en reguleret køber. Den bør ikke kun ligge i release notes eller markedsføringsmateriale.

Opbyg et CRA-register over sikkerhedssupportperioder på én workshop

Forestil dig en SaaS-leverandør, der sælger en forbundet analyseenhed til EU-logistikudbydere og kunder i den finansielle sektor. Produktet omfatter en indlejret agent, en cloud-API, en mobil administratorapp og flere open source-biblioteker. Salg ønsker at love fem års sikkerhedssupport for hver større version af enheden.

CISO’en kan gennemføre en fokuseret workshop med produkt, engineering, juridisk afdeling, databeskyttelse og leverandørstyring.

Trin 1: Opret registeret over supportperioder

Opret én række pr. produktversion, og medtag:

• Produkt og version
• Releasedato
• Startdato for support
• Standard slutdato for sikkerhedssupport
• Mulighed for udvidet support
• Leveringsmetode for opdateringer
• Kanal til indberetning af sårbarheder
• Mål for kritisk patching
• Rolle ved databehandling, f.eks. dataansvarlig, databehandler eller begge
• Kritiske leverandører og komponenter
• Berørte kundesektorer
• Risikoejer
• Godkendelsesdato
• Placering af bevismateriale

Dette register bliver dokumenterede oplysninger i ISMS. Zenith Blueprint, ISMS Foundation and Leadership-fasen, Step 6, angiver forventningen til dokumentstyring:

“Dokumenter bør have korrekt identifikation (en titel, eventuelt et dokumentnummer eller en unik identifikator, en forfatter), et passende format samt gennemgang og godkendelse af egnethed før brug.”

Kilde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, ISMS Foundation and Leadership-fasen, Step 6: Dokumenterede oplysninger og opbygning af ISMS-biblioteket Zenith Blueprint

Clarysecs Enterprise PIMS-politik for dokumenterede oplysninger og styring af bevismateriale PIMS-politik for dokumenterede oplysninger og styring af bevismateriale anvender tilsvarende bevisprincipper på databeskyttelsesdokumentation:

“[Alle] Den databeskyttelsesansvarlige / PIMS-ansvarlige SKAL tildele en dokumentidentifikator, ejer, versionsnummer, godkendelsesstatus, ikrafttrædelsesdato og gennemgangsdato i REG12, før PIMS-dokumenterede oplysninger offentliggøres.”

Kilde: PIMS-politik for dokumenterede oplysninger og styring af bevismateriale, oprettelse, godkendelse, versionering og offentliggørelse, punkt 4.2.1 PIMS-politik for dokumenterede oplysninger og styring af bevismateriale

Selv hvis registeret over supportperioder ikke som udgangspunkt er et databeskyttelsesdokument, gælder samme disciplin: ejer, version, godkendelse, ikrafttrædelsesdato og gennemgangsdato.

Trin 2: Knyt supportløfter til risikobehandling

For hver produktversion oprettes risikoscenarier såsom:

• En kritisk sårbarhed opdages i en understøttet version, men engineering-kapacitet er ikke tilgængelig.
• En tredjepartskomponent bliver ikke-understøttet, før den erklærede sikkerhedssupportperiode udløber.
• En leverandør ændrer hostinglokation eller underleverandør og påvirker levering af opdateringer.
• En sårbarhed påvirker personoplysninger og udløser vurdering af brud på persondatasikkerheden.
• En reguleret finansiel kunde kræver dokumentation for IKT-tredjepartsrobusthed.

ISO/IEC 27001:2022 clauses 6.1.1 to 6.1.3 udgør planlægningsmotoren: identificér risici, vurder sandsynlighed og konsekvenser, tildel risikoejere, vælg behandlinger, sammenlign udvalgte kontroller med Annex A, udarbejd anvendelighedserklæringen og indhent godkendelse af restrisiko.

For risikoen “ikke-understøttet komponent før supportens slutdato” bør risikoregistreringen omfatte ISO/IEC 27002:2022-kontrollerne 5.31, 8.8 og 8.25 samt leverandørkontroller såsom 5.19 Informationssikkerhed i leverandørrelationer, 5.20 Håndtering af informationssikkerhed i leverandøraftaler, 5.21 Styring af informationssikkerhed i IKT-forsyningskæden og 5.22 Overvågning, gennemgang og ændringsstyring af leverandørtjenester.

Trin 3: Fastlæg regler for bevismateriale om sårbarheder og patching

En supportperiode er kun troværdig, hvis sårbarhedsstyring fungerer i perioden.

SMV-udgaven Politik for sårbarheds- og patchstyring-sme Politik for sårbarheds- og patchstyring - SME fastsætter et skærpet krav ved akut eksponering:

“Kritiske patches skal anvendes senest 3 dage efter frigivelse, især for internetvendte systemer”

Kilde: Politik for sårbarheds- og patchstyring-sme, krav til implementering af politikken, punkt 6.1.1 Politik for sårbarheds- og patchstyring - SME

Den kræver også revisionsklare registreringer:

“En patchlog skal vedligeholdes og gennemgås under revisioner og hændelseshåndteringsaktiviteter”

Kilde: Politik for sårbarheds- og patchstyring-sme, styringskrav, punkt 5.4.1 Politik for sårbarheds- og patchstyring - SME

For enterprise-miljøer kræver Enterprise Politik for sårbarheds- og patchstyring Politik for sårbarheds- og patchstyring:

“Et centralt register for sårbarhedsstyring skal vedligeholdes af Security Operations Team og gennemgås månedligt af CISO’en eller delegeret myndighed.”

Kilde: Politik for sårbarheds- og patchstyring, styringskrav, punkt 5.1 Politik for sårbarheds- og patchstyring

Zenith Blueprint, Controls in Action-fasen, Step 19, forklarer den operationelle forventning bag ISO/IEC 27002:2022-kontrol 8.8:

“Hold dig orienteret om nye sikkerhedsfejl (via leverandørvarsler, CVE-feeds osv.) for din software og hardware. Vurdér, hvilke der er relevante (bruger vi denne software? hvor kritisk er fejlen?), og anvend rettelser eller afbødninger hurtigt.”

Kilde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action-fasen, Step 19: Teknologiske kontroller I Zenith Blueprint

Hver understøttet produktversion har behov for et sårbarhedsspor med bevismateriale: modtagelse, relevansanalyse, alvorlighed, berørte versioner, afhjælpningsplan, rettelsesrelease, vejledning om afbødning, kundekommunikation og lukningsgodkendelse.

Trin 4: Knyt sikker udvikling til supportvarighed

Sikkerhedssupport starter før release. Den afhænger af udviklingspraksis, der gør produktet vedligeholdbart.

SMV-udgaven Politik for sikker udvikling-sme Politik for sikker udvikling - SME fastslår:

“Komponenter skal opdateres regelmæssigt, når sikkerhedsrettelser frigives. Hvis en kritisk sårbarhed identificeres, skal komponenten opgraderes eller udskiftes straks.”

Kilde: Politik for sikker udvikling-sme, krav til implementering af politikken, punkt 6.6.3 Politik for sikker udvikling - SME

SMV-udgaven Politik for krav til applikationssikkerhed-sme Politik for krav til applikationssikkerhed - SME kræver, at kontrakter og krav:

“angiver forpligtelser vedrørende offentliggørelse af sårbarheder, svartider og patching.”

Kilde: Politik for krav til applikationssikkerhed-sme, styringskrav, punkt 5.3.2 Politik for krav til applikationssikkerhed - SME

Hvis virksomheden lover support indtil 2031, skal arkitekturen understøtte vedligeholdbare opdateringer, udskiftning af afhængigheder, sikre build-pipelines, regressionstest og nødrettelser. ISO/IEC 27002:2022-kontroller for sikker udvikling, sikker arkitektur, sikker kodning, sikkerhedstest, outsourcet udvikling, adskillelse af miljøer og ændringsstyring bliver forudsætninger for supportperioden.

Ét sæt bevismateriale til CRA, NIS2, DORA og GDPR

Det samme bevismateriale for supportperioder kan opfylde forskellige regulatoriske dialoger, men hvert rammeværk stiller spørgsmålet på sin egen måde.

Leverandørafhængighed er ofte dér, supportforpligtelser svigter. Enterprise Politik for risikostyring af leverandørafhængigheder Politik for risikostyring af leverandørafhængigheder kræver:

“Register over leverandørafhængigheder: VMO skal vedligeholde et ajourført register over alle kritiske leverandører, herunder oplysninger såsom leverede tjenester/produkter; om leverandøren er eneleverandør; tilgængelige alternative leverandører eller substitutionsmulighed; aktuelle kontraktvilkår; og en vurdering af konsekvensen, hvis leverandøren skulle svigte eller blive kompromitteret.”

Kilde: Politik for risikostyring af leverandørafhængigheder, implementeringskrav, punkt 6.1 Politik for risikostyring af leverandørafhængigheder

Zenith Blueprint, Controls in Action-fasen, Step 23, advarer om, at revisorer vil gennemgå leverandøraftaler og bevismateriale for leverandørovervågning:

“Revisorer vil gennemgå stikprøver af kontrakter eller serviceaftaler. De leder efter eksplicitte informationssikkerhedsklausuler, f.eks. frister for underretning ved brud, adgangsbegrænsninger, databehandlingsforpligtelser, krypteringskrav eller revisionsrettigheder.”

Kilde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action-fasen, Step 23: Organisatoriske kontroller Zenith Blueprint

For DORA-kunder er dette kritisk. Kontrakter om IKT-tjenester, der understøtter kritiske eller vigtige funktioner, skal have klare tjenestebeskrivelser, betingelser for underleverandører, sikkerhedsforanstaltninger, hændelsesbistand, revisions- og inspektionsrettigheder, opsigelsesrettigheder og overgangsordninger. En leverandør, der ikke kan understøtte disse forpligtelser, kan forhindre producenten i at afgive et troværdigt løfte om supportperiode.

Kontrolkortlægning for revisionsklar styring af supportperioder

Denne kortlægning gør det muligt for sikkerhed, juridisk afdeling, produkt og salg at tale ét sprog. Registeret over supportperioder er ikke kun CRA-bevismateriale. Det er leverandørassurance for NIS2, tredjepartsassurance for DORA, støtte til behandlingssikkerhed efter GDPR og et styringsartefakt til ISO 27001-certificering.

Databeskyttelsesvinklen: når ikke-understøttet bliver usikkert

Styring af sikkerhedssupportperioder er ikke kun et cybersikkerhedsspørgsmål. Hvis produktet lagrer, transmitterer eller behandler personoplysninger, kan ikke-understøttet software blive en databeskyttelsesrisiko.

GDPR gælder for behandling i forbindelse med en etablering i EU og kan også gælde for organisationer uden for EU, der tilbyder varer eller tjenester til personer i EU eller overvåger deres adfærd. GDPR definerer personoplysninger bredt og behandler et brud på persondatasikkerheden som et sikkerhedsbrud, der fører til hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til behandlede personoplysninger.

For styring af supportperioder har databeskyttelsesteams behov for at vide, hvilke produktversioner der behandler PII, hvilke systemer der stadig understøttes, og om sårbarheder påvirker fortrolighed, integritet eller tilgængelighed af personoplysninger.

Clarysecs Enterprise PII-politik for sikkerhed og adgangsstyring PII-politik for sikkerhed og adgangsstyring kræver:

“[Begge] Systemejeren / Applikationsejeren SKAL registrere dækningen af sårbarhedsvurdering for systemer, der behandler PII, i REG12 mindst kvartalsvist og efter væsentlige tekniske ændringer.”

Kilde: PII-politik for sikkerhed og adgangsstyring, sikker konfiguration og sårbarhedsstyring, punkt 4.7.4 PII-politik for sikkerhed og adgangsstyring

Enterprise Politik for styring af databehandlere, underdatabehandlere og tredjeparter vedrørende databeskyttelse Politik for styring af databehandlere, underdatabehandlere og tredjeparter vedrørende databeskyttelse tilføjer løbende overvågning for højrisikorelationer vedrørende databeskyttelse:

“[Alle] Leverandør-/indkøbsansvarlig SKAL overvåge aktive højrisikorelationer med databehandlere og underdatabehandlere kvartalsvist og andre aktive PII-relationer med databehandlere og underdatabehandlere årligt i forhold til due diligence-betingelser, kontraktstatus, assurancestatus, åbne forhold og gennemgangsdatoer i REG08.”

Kilde: Politik for styring af databehandlere, underdatabehandlere og tredjeparter vedrørende databeskyttelse, løbende overvågning, bistand, grænseflade for videregivelse og exit, punkt 4.5.1 Politik for styring af databehandlere, underdatabehandlere og tredjeparter vedrørende databeskyttelse

Når en sårbarhed bliver til en hændelse, kræver Enterprise PII-politik for hændelser og brud PII-politik for hændelser og brud vurdering af udløsere på tværs af rammeværker:

“[Betinget] Den databeskyttelsesansvarlige / PIMS-ansvarlige SKAL evaluere relevante juridiske, sektorbestemte, finanssektorrelaterede, cybersikkerhedsmæssige, kontraktlige, kunde- og tjenestemodtagerrelaterede rapporteringsudløsere for hver PII-hændelse med højt konsekvensniveau og registrere resultatet af anvendelighedsvurderingen i REG01, REG08 og REG10.”

Kilde: PII-politik for hændelser og brud, klassificering og vurdering af brud, punkt 4.2.6 PII-politik for hændelser og brud

Dette er det praktiske overlap mellem CRA-supportforpligtelser, NIS2-hændelseskommunikation, DORA-håndtering af større IKT-hændelser og GDPR-ansvarlighed ved brud.

Hvordan revisorer tester den samme supportperiodeproces

En stærk styringsproces for supportperioder bør kunne modstå flere revisionsstile. Bevismaterialet ændrer sig ikke meget, men revisors perspektiv gør.

NIST CSF 2.0 er nyttig som kommunikationslag, fordi dens GOVERN Function omfatter juridiske, regulatoriske, kontraktlige og databeskyttelsesrelaterede forpligtelser, mål for risikostyring, risikovillighed, roller, politikker og tilsyn. Dens resultater for forsyningskæden dækker leverandørstrategi, kritikalitet, kontrakter, due diligence, overvågning, hændelseskoordinering og bestemmelser ved ophør af relationen.

COBIT- og ISACA-lignende revisorer fokuserer ofte på styringsdesign: hvem ejer beslutningen, hvilken proces er defineret, hvilke metrikker viser performance, hvordan godkendes undtagelser, og hvordan håndteres løbende forbedring.

Clarysecs Enterprise Informationssikkerhedspolitik Informationssikkerhedspolitik indfanger princippet om revisionsbarhed:

“Alle implementerede kontroller skal være revisionsbare, understøttet af dokumenterede procedurer og opbevaret bevismateriale for drift.”

Kilde: Informationssikkerhedspolitik, krav til implementering af politikken, punkt 6.6.1 Informationssikkerhedspolitik

Det er den sætning, hver sikkerhedssupportperiode bør kunne opfylde.

Forlæng, forkort eller afslut support uden at skabe falsk assurance

De sværeste styringsøjeblikke opstår ikke ved produktlancering. De opstår, når virkeligheden ændrer sig.

Det kan være nødvendigt at forlænge support, fordi regulerede kunder er afhængige af produktet, migrering ikke er mulig, eller en sektorkunde har kontraktlige kontinuitetsbehov. Det kan være nødvendigt at forkorte eller begrænse support, fordi en leverandør ophører med sikkerhedsvedligeholdelse, en komponent bliver umulig at patche, en platform når tekniske begrænsninger, eller produktarkitekturen ikke sikkert kan understøtte en sårbarhedsklasse.

En kontrolleret ændring af supportperioden bør omfatte:

• Ændringsudløser, f.eks. leverandørs end-of-life, kritisk sårbarhed, kundekontrakt eller regulatorisk ændring
• Berørte produkter, versioner, kunder og sektorer
• Konsekvensanalyse for personoplysninger og kritiske tjenester
• Gennemgang af gennemførlighed for leverandører og komponenter
• Risikovurdering og beslutning om restrisiko
• Opdateret register over supportperioder
• Opdateret kundemeddelelse og kontraktlig position
• Opdaterede SoA-noter, hvor kontroller eller forpligtelser ændrer sig
• Ledelsesgodkendelse og gennemgangsdato

Enterprise Politik for koordineret offentliggørelse af sårbarheder Politik for koordineret offentliggørelse af sårbarheder er nyttig, når ændringen er sårbarhedsdrevet:

“Der skal udarbejdes en afhjælpnings- eller afbødningsplan for alle bekræftede sårbarheder. Implementering af rettelsen skal prioriteres ud fra alvorlighed. Kritiske sårbarheder skal f.eks. rettes eller afbødes 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.”

Kilde: Politik for koordineret offentliggørelse af sårbarheder, implementeringskrav, punkt 6.6 Politik for koordineret offentliggørelse af sårbarheder

Hvis en fuld rettelse ikke kan leveres med det samme, kan kompenserende kontroller, deaktiveret funktionalitet, øget overvågning eller vejledning til kundekonfiguration være midlertidigt acceptabelt, men beslutningen skal dokumenteres og kommunikeres.

Praktisk Clarysec-tjekliste for parathed ved supportperioder

Brug denne tjekliste, før en forpligtelse om CRA-sikkerhedssupportperiode offentliggøres eller fornyes.

• Er produktet og versionen anført i registeret over supportperioder?
• Er supportens slutdato godkendt af produkt, sikkerhed og ansvarlig ledelse?
• Er juridiske, regulatoriske og kontraktlige drivere kortlagt i efterlevelsesregisteret?
• Er risikoscenariet for supportperioden medtaget i risikoregisteret?
• Er kontroller kortlagt i anvendelighedserklæringen, herunder 5.31, 8.8 og 8.25, hvor relevant?
• Er kritiske leverandører og komponenter kortlagt i registeret over leverandørafhængigheder?
• Findes der bevismateriale for, at komponenter kan patches eller udskiftes i supportperioden?
• Er ansvar for modtagelse, triage, afhjælpning og offentliggørelse af sårbarheder defineret?
• Er SLA’er for kritisk patching afstemt med politik og kundekontrakter?
• Opbevares patchlogs, release-registreringer og sårbarhedsbeslutninger?
• Er systemer med personoplysninger dækket af bevismateriale for sårbarhedsvurdering, hvor PII behandles?
• Er kundemeddelelser, supporterklæringer og kontraktvilkår konsistente?
• Findes der en proces til at forlænge, forkorte eller afslutte support med risikogodkendelse?
• Modtager ledelsens gennemgang input om supportperioderisiko, leverandører, sårbarheder og hændelser?
• Kan bevismateriale fremskaffes inden for 48 timer til en kunderevision eller forespørgsel fra tilsynsmyndighed?

Enterprise PIMS-politik for overvågning, revision og forbedring PIMS-politik for overvågning, revision og forbedring styrker disciplinen for ledelsens gennemgang i databeskyttelsesprogrammer:

“[Begge] Øverste ledelse SKAL gennemgå input om PIMS-afvigelser, korrigerende handlinger, overvågningsresultater, revisionsresultater, databeskyttelsesrisici, assurance vedrørende leverandører og ændringer hos interessenter i REG12 under hver ledelsens gennemgang.”

Kilde: PIMS-politik for overvågning, revision og forbedring, PIMS-ledelsens gennemgang, punkt 4.3.5 PIMS-politik for overvågning, revision og forbedring

For styring af sikkerhedssupportperioder bør den samme gennemgangsrytme gælde på tværs af ISMS: sårbarheder, patchperformance, leverandørassurance, kundeforpligtelser, hændelser, supportundtagelser og korrigerende handlinger bør indgå i ledelsens gennemgang.

Gør sikkerhedssupportperioden forsvarlig

EU’s forordning om cyberrobusthed ændrer produktsikkerhedens logik. Den presser producenter og softwareudbydere til at tænke længere end releasedagen. Sikkerhedssupportperioden bliver et livscyklusløfte, der skal konstrueres, styres, overvåges og dokumenteres.

For CISO’er er læringen klar: Lad ikke supportperioden kun ligge i produktmarkedsføring. For compliance managers: opbyg ikke en separat CRA-silo for bevismateriale. For revisorer: test, om supportforpligtelser kan spores til risiko, kontroller, leverandører, hændelser og dokumenterede godkendelser. For virksomhedsejere: husk, at en troværdig supportperiode kan blive en markedsfordel, især ved salg til NIS2-regulerede sektorer, DORA-finansielle enheder og kunder med høje krav til databeskyttelse.

Clarysec hjælper organisationer med at operationalisere dette gennem:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint til opbygning af ISMS-sporbarhed, dokumenterede oplysninger, SoA-kortlægning og revisionsberedskab
• Zenith Controls: The Cross-Compliance Guide Zenith Controls til kortlægning af ISO/IEC 27002:2022-kontroller til NIS2, DORA, GDPR, NIST CSF 2.0 og revisionsforventninger
• Enterprise- og SMV-politikpakker til sårbarhedsstyring, sikker udvikling, juridisk efterlevelse, leverandørafhængighed, databeskyttelsesbevismateriale og hændelseshåndtering
• Praktiske registre og arbejdsgange for bevismateriale, der omsætter supportperiodeløfter til revisionsbar styring

Dit næste skridt er enkelt: Vælg én flagskibsproduktversion, og opbyg dens dokumentationsfil for sikkerhedssupportperioden. Kortlæg forpligtelsen, godkend supportperioden, test sårbarhedsprocessen, validér leverandørafhængigheder, bekræft kundekommunikation og opbevar registreringerne.

Hvis du kan forsvare ét produkt, kan du skalere modellen. Hvis du ikke kan forsvare ét produkt, er hullet ikke dokumentation. Det er styring.

Download Zenith Blueprint, brug Zenith Controls til at kortlægge dit bevismateriale, eller anmod om en Clarysec-parathedsvurdering for at omsætte CRA-sikkerhedssupportperioder til revisionsklar ISO 27001-styring.