CVD voor NIS2 en DORA: ISO 27001-bewijsmatrix

Om 08:17 op een dinsdag ontvangt de beveiligingsmailbox een bericht van een onafhankelijke onderzoeker. De onderwerpregel is rustig, bijna beleefd: “Mogelijke accountovername in uw klantportaal.” De inhoud is minder geruststellend. De onderzoeker stelt dat een keten van kwetsbaarheden in uw SaaS-applicatie ervoor zorgt dat één tenant toegang kan krijgen tot factuurregistraties van een andere tenant. Een proof of concept is bijgevoegd, versleuteld met uw gepubliceerde PGP-sleutel.

Voor Maria, de nieuwe CISO bij FinanTechSaaS, had de timing nauwelijks slechter kunnen zijn. Haar organisatie heeft net een groot contract getekend met een vooraanstaande EU-bank. Het due-diligenceteam van de klant heeft al gevraagd om een “beleid voor gecoördineerde openbaarmaking van kwetsbaarheden” en bewijs van implementatie, met expliciete verwijzing naar NIS2 en DORA. De organisatie heeft een security@-e-mailadres, maar dat wordt bewaakt door één ontwikkelaar. Er is geen formeel intakeregister, geen vastgestelde validatie-SLA, geen escalatiepad naar het management en geen audittrail.

Drie klokken beginnen tegelijk te lopen.

De eerste klok is operationeel. Is de kwetsbaarheid echt? Is deze in productie te misbruiken? Wordt zij al actief misbruikt?

De tweede klok is regelgevend. Als klantgegevens zijn blootgesteld, begint de GDPR-beoordeling van het datalek. Als de dienstverlening wordt geraakt voor een essentiële of belangrijke entiteit onder NIS2, kunnen drempels voor incidentmelding worden geactiveerd. Als de organisatie een financiële entiteit is of een ICT-aanbieder die financiële diensten ondersteunt, kunnen de DORA-regels voor incidentbeheer, classificatie, escalatie en klantcommunicatie relevant worden.

De derde klok betreft bewijsmateriaal. Zes maanden later kan een ISO/IEC 27001:2022-auditor, toezichthouder in de financiële sector, klantassuranceteam of interne auditcommissie vragen: “Laat zien hoe deze kwetsbaarheid is afgehandeld.”

Op dat punt ontdekken veel organisaties dat gecoördineerde openbaarmaking van kwetsbaarheden niet slechts een beveiligingsmailbox is. Het is een governancesysteem. Het vereist beleidseigenaarschap, een publiek meldkanaal, een triageworkflow, SLA’s voor herstelmaatregelen, leveranciersescalatie, besluitlogica voor incidenten, privacybeoordeling, managementrapportage en verdedigbaar bewijsmateriaal.

Clarysec behandelt CVD als een geïntegreerd patroon van beheersmaatregelen, niet als een losse inbox. In Zenith Blueprint: een 30-stappenroadmap voor auditors Zenith Blueprint komt kwetsbaarhedenafhandeling terug in de fase Beheersmaatregelen in de praktijk, stap 19: Technologische beheersmaatregelen I. De richtlijn is duidelijk: organisaties moeten kwetsbaarheidsbevindingen niet passief archiveren, maar triëren, toewijzen en volgen tot afsluiting. Dezelfde norm geldt voor externe openbaarmakingen. Als iemand u vertelt hoe uw dienst kan falen, wordt de echte vraag: kunt u aantonen dat u de melding hebt ontvangen, beoordeeld, geprioriteerd, verholpen, gecommuniceerd en ervan geleerd?

Waarom CVD onder NIS2 en DORA nu een bestuurskwestie is

Jarenlang nodigden beveiligingsbewuste organisaties ethische hackers uit om kwetsbaarheden te melden omdat dit een goede praktijk was. Onder NIS2 en DORA is die praktijk onderdeel geworden van gereguleerde digitale weerbaarheid.

NIS2 is van toepassing op veel middelgrote en grotere entiteiten in zeer kritieke en andere kritieke sectoren, waaronder aanbieders van digitale infrastructuur, cloudserviceproviders (CSP’s), datacenteraanbieders, aanbieders van managed services (MSP’s), aanbieders van managed security services en bepaalde digitale aanbieders zoals online marktplaatsen, zoekmachines en sociale-netwerkplatformen. NIS2 kan ook ongeacht omvang van toepassing zijn op categorieën zoals aanbieders van vertrouwensdiensten, DNS-dienstverleners, TLD-registers en aanbieders van openbare elektronische communicatienetwerken of -diensten.

NIS2 Article 21 vereist dat essentiële en belangrijke entiteiten passende en evenredige technische, operationele en organisatorische maatregelen voor cyberbeveiligingsrisicobeheer implementeren op basis van een all-hazardsbenadering. Eén van de minimumgebieden is beveiliging bij de verwerving, ontwikkeling en het onderhoud van netwerk- en informatiesystemen, inclusief kwetsbaarhedenafhandeling en openbaarmaking. Dezelfde baseline omvat ook incidentenafhandeling, beveiliging van de toeleveringsketen, bedrijfscontinuïteit, toegangscontrole, beheer van bedrijfsmiddelen, training, cryptografie en procedures om de doeltreffendheid van beheersmaatregelen te beoordelen.

NIS2 Article 20 maakt ook de verantwoordingsplicht van het management expliciet. Bestuursorganen moeten maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren, toezicht houden op de implementatie en training volgen. Voor een CVD-programma betekent dit dat de raad van bestuur of het topmanagement inzicht moet hebben in het meldkanaal, het kwetsbaarheidsresponsteam (VRT), validatietermijnen, verwachtingen voor herstelmaatregelen, leveranciersafhankelijkheden en triggers voor incidentmelding.

DORA creëert vanaf 17 januari 2025 een sectorspecifiek regime voor financiële entiteiten. Het omvat ICT-risicobeheer, rapportage van ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid, informatie-uitwisseling, risico’s van ICT-derden, contractuele eisen, toezicht op kritieke ICT-dienstverleners van derde partijen en samenwerking met toezichthouders. Voor financiële entiteiten die onder DORA vallen, heeft DORA in het algemeen voorrang op NIS2 voor ICT-risicobeheer en incidentrapportage, omdat het de sectorspecifieke rechtshandeling van de Unie is. De praktische eis blijft echter dezelfde: financiële entiteiten en ICT-aanbieders die hen bedienen, moeten een gestructureerd, gedocumenteerd en testbaar proces uitvoeren voor het identificeren, analyseren, classificeren, escaleren, remediëren en leren van ICT-zwaktes.

Een kwetsbaarheidsmelding kan beginnen als een technische bevinding, uitgroeien tot een beveiligingsgebeurtenis, escaleren naar een incident, een beoordeling van een GDPR-datalek met persoonsgegevens activeren, leveranciersactie vereisen en later terugkomen in de ISO/IEC 27001:2022 Verklaring van Toepasselijkheid. Daarom moet CVD worden ontworpen als één operationeel model voor beveiliging, compliance, engineering, juridische zaken, privacy, inkoop en management.

De ISO 27001-basis: van openbaarmaking naar ISMS-bewijsmateriaal

ISO/IEC 27001:2022 biedt CISO’s en complianceverantwoordelijken het managementsysteem dat CVD auditeerbaar maakt.

Clausules 4.1 tot en met 4.4 vereisen dat de organisatie interne en externe kwesties, eisen van belanghebbenden, ISMS-grenzen en afhankelijkheden met andere organisaties begrijpt. Hier komen NIS2, DORA, GDPR, klantcontracten, leveranciersverplichtingen en toezeggingen voor kwetsbaarhedenopenbaarmaking het ISMS binnen.

Clausules 5.1 tot en met 5.3 creëren verantwoordingsplicht voor leiderschap. Topmanagement moet informatiebeveiliging afstemmen op de strategische richting, middelen beschikbaar stellen, verantwoordelijkheden toewijzen en borgen dat het ISMS de beoogde resultaten behaalt. Voor CVD betekent dit het aanstellen van een kwetsbaarheidsresponsteam (VRT), het vastleggen van de bevoegdheid om restrisico te accepteren en het escaleren van kwetsbaarheden met hoge impact naar het management.

Clausules 6.1.1 tot en met 6.1.3 vormen de risicomotor. De organisatie moet risicocriteria vaststellen, informatiebeveiligingsrisico’s beoordelen, risico-eigenaren aanwijzen, opties voor risicobehandeling selecteren, beheersmaatregelen toetsen aan Annex A, een Verklaring van Toepasselijkheid opstellen en goedkeuring verkrijgen voor restrisico. Clausules 8.1 tot en met 8.3 vereisen vervolgens operationele beheersing, geplande wijzigingen, beheersing van extern geleverde processen, risicobeoordelingen op geplande momenten of na significante wijzigingen, en bewijsmateriaal van behandelresultaten.

In Zenith Blueprint, fase Risicobeheer, stap 13, wordt de Verklaring van Toepasselijkheid omschreven als meer dan een spreadsheet voor compliance:

“De SoA is in feite een brugdocument: het koppelt uw risicobeoordeling/-behandeling aan de daadwerkelijke beheersmaatregelen die u hebt.”
Bron: Zenith Blueprint: een 30-stappenroadmap voor auditors, fase Risicobeheer, stap 13: Planning van risicobehandeling en Verklaring van Toepasselijkheid (SoA) Zenith Blueprint

Voor gecoördineerde openbaarmaking van kwetsbaarheden moet de SoA regelgevende verplichtingen, bedrijfsrisico, Annex A-beheersmaatregelen, beleidsclausules en operationeel bewijsmateriaal met elkaar verbinden.

Het doel is niet om parallelle compliancesilo’s te creëren. Het CVD-beleid moet een beheerst ISMS-proces zijn dat tegelijk ISO/IEC 27001:2022-certificering, naleving van NIS2, DORA-gereedheid, klantassurance en beveiligingsoperaties ondersteunt.

De beleidsbaseline: wat uw CVD-beleid moet zeggen

De eerste zichtbare beheersmaatregel is het publieke openbaarmakingskanaal. Onderzoekers, klanten, leveranciers en partners moeten weten waar zij kwetsbaarheden kunnen melden en hoe zij gevoelig bewijsmateriaal kunnen beschermen.

Clarysec’s Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden biedt de enterprise-baseline:

“Publieke openbaarmakingskanalen: De organisatie moet een duidelijk kanaal voor kwetsbaarheidsmeldingen onderhouden, zoals een speciaal beveiligingscontactadres per e-mail (bijvoorbeeld security@company.com) of een webformulier. Deze informatie moet worden gepubliceerd op de beveiligingspagina van de bedrijfswebsite, samen met de publieke PGP-sleutel van de organisatie om versleutelde indieningen mogelijk te maken.”
Bron: Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden, implementatievereisten, clausule 6.1

Deze clausule verhelpt een veelvoorkomende audittekortkoming. Veel organisaties stellen dat zij meldingen accepteren, maar het meldkanaal is verborgen, onversleuteld of belegd bij het verkeerde team. Een volwassen kanaal is publiek, veilig, bewaakt en toegewezen aan een verantwoordelijke functie.

De volgende beheersmaatregel is responsdiscipline. Een kritieke melding gevolgd door stilte veroorzaakt openbaarmakingsrisico, reputatierisico en exploitatierisico. Het Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden stelt een concrete verwachting voor bevestiging en validatie:

“Triage en bevestiging: Na ontvangst van een melding moet het VRT deze registreren en binnen 2 werkdagen een bevestiging naar de melder sturen, met toewijzing van een volgreferentie. Het VRT moet een voorlopige ernstbeoordeling uitvoeren, bijvoorbeeld met CVSS-scoring, en het probleem valideren, waar nodig met ondersteuning van IT- en ontwikkelteams, binnen een streeftermijn van 5 werkdagen. Kritieke kwetsbaarheden, zoals kwetsbaarheden die remote code execution of een grootschalig datalek mogelijk maken, moeten versneld worden afgehandeld.”
Bron: Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden, implementatievereisten, clausule 6.4

Deze formulering creëert directe bewijsposities: ontvangsttijd, bevestigingstijd, volgreferentie, voorlopige ernst, validatieresultaat en besluit over versnelde afhandeling.

Voor mkb-organisaties hanteert Clarysec dezelfde logica met evenredige implementatie. Het Beleid inzake vereisten voor applicatiebeveiliging-sme Beleid inzake vereisten voor applicatiebeveiliging - SME vereist dat organisaties:

“verplichtingen specificeren voor openbaarmaking van kwetsbaarheden, responstijden en patching.”
Bron: Beleid inzake vereisten voor applicatiebeveiliging-sme, governancevereisten, clausule 5.3.2

U hebt geen groot productbeveiligingsteam nodig om verantwoordbaar te zijn. U hebt expliciete verplichtingen, realistische termijnen, aangewezen eigenaren en bewijsmateriaal nodig dat aantoont dat het proces werkt.

De CVD-intakeworkflow: van e-mail van onderzoeker naar besluitregistratie

Een goede intakeworkflow is eenvoudig genoeg om onder druk uit te voeren en volledig genoeg om een auditor tevreden te stellen. De workflow moet beginnen met een eigen kanaal zoals security@[company], een webformulier of een gepubliceerd security.txt-bestand. Het indieningskanaal moet versleuteld bewijsmateriaal, het getroffen product of endpoint, reproductiestappen, contactgegevens van de melder, gewenste timing van openbaarmaking en elke aanwijzing voor gegevensblootstelling of actieve exploitatie kunnen verwerken.

Na ontvangst moet het kwetsbaarheidsresponsteam (VRT) een registratie aanmaken in een GRC-tool, ticketsysteem, systeem voor kwetsbaarhedenbeheer of beheerst register. Het hulpmiddel is minder belangrijk dan consistentie en kwaliteit van bewijsmateriaal.

De workflow moet vervolgens zeven operationele stappen doorlopen.

1. Intake: de melding wordt ontvangen via het publieke kanaal en automatisch of handmatig gelogd.
2. Bevestiging: het VRT reageert binnen 2 werkdagen en wijst een volgreferentie toe.
3. Validatie: het technische team reproduceert het probleem, bevestigt de getroffen systemen en voert een voorlopige ernstscore uit.
4. Gebeurtenisbeoordeling: het VRT bepaalt of de kwetsbaarheid alleen een zwakte, een informatiebeveiligingsgebeurtenis of een incident is.
5. Escalatie: hoge of kritieke kwesties worden waar nodig doorgezet naar systeemeigenaren, de CISO, privacy, juridische zaken, leveranciers en management.
6. Herstelmaatregelen: het verantwoordelijke team past een fix, mitigerende maatregel, compenserende beheersmaatregel of tijdelijke beperking toe.
7. Afsluiting: het VRT verifieert de fix, communiceert met de melder, werkt het bewijsdossier bij en registreert geleerde lessen.

Clarysec mapt deze operationele stap naar ISO/IEC 27002:2022 beheersmaatregel A.5.25, Beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen, en beheersmaatregel A.8.8, Beheer van technische kwetsbaarheden, via Zenith Controls: de cross-compliancegids Zenith Controls. Voor A.5.25 legt Zenith Controls uit dat gebeurtenisbeoordeling de triagefunctie is tussen ruwe monitoringwaarschuwingen en formele incidentenafhandeling, waarbij logboeken, drempelwaarden en besluitcriteria worden gebruikt om escalatie te bepalen. Voor A.8.8 verbindt Zenith Controls technisch kwetsbaarhedenbeheer met malwarebescherming, configuratiebeheer, wijzigingsbeheer, endpointbeveiliging, dreigingsinformatie, monitoring, veilige ontwikkeling, gebeurtenisbeoordeling en incidentrespons.

Eén passage uit Zenith Controls is bijzonder nuttig wanneer actieve exploitatie wordt vermoed:

“Dreigingsinformatie geeft aan welke kwetsbaarheden actief worden misbruikt en stuurt daarmee de prioritering van patches.”
Bron: Zenith Controls: de cross-compliancegids, ISO/IEC 27002:2022 control 8.8, koppeling met control 5.7 Threat Intelligence Zenith Controls

Dit is een belangrijk governancepunt. Ernst is niet alleen CVSS. Een kwetsbaarheid met een gemiddelde score die actief tegen uw sector wordt misbruikt, kan voorrang krijgen boven een theoretisch kritieke kwestie op een niet-blootgesteld testsysteem.

Wanneer een kwetsbaarheid een incident wordt

Niet elke kwetsbaarheidsmelding is een incident. Een ontbrekende beveiligingsheader op een stagingomgeving is niet hetzelfde als een misbruikte autorisatiebypass die klantfacturen blootlegt. Maar elke geloofwaardige kwetsbaarheidsmelding moet door een besluitpoort voor incidenten gaan.

NIS2 Article 23 vereist dat essentiële en belangrijke entiteiten hun CSIRT of bevoegde autoriteit zonder onnodige vertraging informeren over incidenten die de dienstverlening aanzienlijk beïnvloeden. Een significant incident is een incident dat ernstige operationele verstoring of financieel verlies heeft veroorzaakt of kan veroorzaken, of dat anderen heeft getroffen of kan treffen door aanzienlijke materiële of immateriële schade te veroorzaken. De meldvolgorde omvat een vroege waarschuwing binnen 24 uur nadat men zich bewust is geworden, een incidentmelding binnen 72 uur, tussentijdse rapportages wanneer daarom wordt verzocht, en een eindrapport binnen één maand na de 72-uursmelding.

DORA Articles 17 to 20 vereisen dat financiële entiteiten ICT-gerelateerde incidenten en significante cyberdreigingen detecteren, beheren, registreren, classificeren, escaleren, melden en communiceren. Majeure ICT-gerelateerde incidenten moeten worden geëscaleerd naar het hoger management en het bestuursorgaan. Klantcommunicatie kan vereist zijn wanneer financiële belangen worden geraakt.

Voor mkb-organisaties moet de meldcultuur even duidelijk zijn. Clarysec’s Incidentresponsbeleid-sme Incidentresponsbeleid - SME stelt:

“Personeel moet elke verdachte activiteit of elk bevestigd incident melden aan incident@[company] of mondeling aan de algemeen directeur (GM) of IT-provider.”
Bron: Incidentresponsbeleid-sme, vereisten voor beleidsimplementatie, clausule 6.2.1

In Zenith Blueprint, fase Beheersmaatregelen in de praktijk, stap 16: People Controls II, is het principe nog eenvoudiger:

“Bij twijfel: melden.”
Bron: Zenith Blueprint: een 30-stappenroadmap voor auditors, fase Beheersmaatregelen in de praktijk, stap 16: People Controls II (A.6.5 tot A.6.8)

Die zin moet gelden voor ontwikkelaars, supportteams, leveranciersmanagers, privacyverantwoordelijken, leidinggevenden en uitbestede dienstverleners. Een kwetsbaarheid die vertrouwelijkheid, integriteit, beschikbaarheid, klantvertrouwen, regelgevende rapportage of financiële operaties kan raken, moet worden geregistreerd en beoordeeld, niet informeel in chat worden afgehandeld.

Herstelmaatregelen, patching en compenserende beheersmaatregelen

Zodra een kwetsbaarheid is gevalideerd, moet deze worden behandeld. De behandeling moet risicogebaseerd, onderbouwd met bewijsmateriaal en tijdgebonden zijn.

Het Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden stelt de enterprise-verwachting:

“Plan voor herstelmaatregelen: Voor alle bevestigde kwetsbaarheden moet een herstel- of mitigatieplan worden opgesteld. De implementatie van de fix moet worden geprioriteerd op basis van ernst. Kritieke kwetsbaarheden moeten bijvoorbeeld waar haalbaar binnen 14 dagen worden verholpen of gemitigeerd, of eerder wanneer actieve exploitatie wordt vastgesteld, terwijl kwesties met lagere ernst binnen een redelijke termijn moeten worden aangepakt. Wanneer een volledige fix wordt vertraagd, moeten compenserende beheersmaatregelen of tijdelijke mitigerende maatregelen worden geïmplementeerd, zoals het uitschakelen van kwetsbare functionaliteit of het verhogen van monitoring.”
Bron: Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden, implementatievereisten, clausule 6.6

Voor mkb-discipline rond patching stelt het Beleid inzake kwetsbaarheden- en patchbeheer-sme Beleid inzake kwetsbaarheden- en patchbeheer - SME:

“Kritieke patches moeten binnen 3 dagen na vrijgave worden toegepast, vooral voor systemen die vanaf internet bereikbaar zijn”
Bron: Beleid inzake kwetsbaarheden- en patchbeheer-sme, vereisten voor beleidsimplementatie, clausule 6.1.1

Deze termijnen spreken elkaar niet tegen. Een leverancierspatch voor een systeem dat vanaf internet bereikbaar is, kan een zeer snelle uitrol vereisen. Een productkwetsbaarheid waarvoor codewijzigingen, regressietests, klantcoördinatie en gefaseerde release nodig zijn, kan een plan voor herstelmaatregelen met tussentijdse mitigaties vereisen. De kern is dat het besluit is gedocumenteerd, een risico-eigenaar heeft en is goedgekeurd waar restrisico blijft bestaan.

Een praktische casusflow ziet er als volgt uit:

1. Een onderzoeker meldt een autorisatiebypass in de klantfacturatie-API.
2. Het VRT logt CVD-2026-014 met een tijdstempel en bevestigt binnen 2 werkdagen.
3. Productbeveiliging valideert de fout binnen 24 uur en kent de ernst High toe vanwege toegang tot gegevens over tenants heen.
4. Privacy voert een GDPR-beoordeling van een datalek uit omdat factuurregistraties persoonsgegevens kunnen bevatten.
5. De incidentmanager opent een gebeurtenisbeoordeling onder ISO/IEC 27002:2022 control A.5.25.
6. De systeemeigenaar schakelt het kwetsbare endpoint uit via een tijdelijke featureflag.
7. Engineering maakt een hotfix aan onder ISO/IEC 27002:2022 control A.8.32, Wijzigingsbeheer.
8. Monitoringregels worden toegevoegd voor indicatoren van exploitatie, gekoppeld aan A.8.15, Logging, en A.8.16, Monitoringactiviteiten.
9. De CISO informeert het hoger management omdat het een hoogrisicokwestie betreft.
10. Het VRT stemt met de onderzoeker af over hertesten en timing van openbaarmaking.
11. De risico-eigenaar keurt afsluiting pas goed na verificatietests en beoordeling van klantimpact.
12. De SoA, het risicoregister, het ticket, de logboeken, de managementmelding en de geleerde lessen worden bijgewerkt.

Dat is het verschil tussen “we hebben het gepatcht” en “we kunnen aantonen dat we het hebben bestuurd.”

Leveranciers- en cloudafhankelijkheden: het verborgen faalpunt

Veel CVD-faalgevallen zijn in feite leveranciersfalen. De kwetsbaarheid kan betrekking hebben op een SaaS-component, clouddienst, managed security provider, betaalgateway, authenticatiebroker, open-sourcebibliotheek, uitbesteed ontwikkelteam of onderaannemer.

NIS2 Article 21 vereist beveiliging van de toeleveringsketen, inclusief relaties met directe leveranciers en dienstverleners. Maatregelen voor de toeleveringsketen moeten rekening houden met kwetsbaarheden bij leveranciers, productkwaliteit, cyberbeveiligingspraktijken en procedures voor veilige ontwikkeling.

DORA Articles 28 to 30 gaan verder voor financiële entiteiten. Zij vereisen dat risico’s van ICT-derden worden beheerd als onderdeel van het ICT-risicokader, met registers van ICT-dienstverleningscontracten, onderscheid tussen kritieke of belangrijke functies, due diligence vóór contractering, contractuele beveiligingseisen, incidentondersteuning, samenwerking met autoriteiten, auditrechten, beëindigingsrechten en exitstrategieën. Financiële entiteiten blijven volledig verantwoordelijk voor DORA-naleving, ook wanneer zij ICT-dienstverleners van derde partijen gebruiken.

Clarysec’s Beleid inzake beveiliging van derden en leveranciers-sme Beleid inzake beveiliging van derden en leveranciers - SME bevat een eenvoudige escalatieregel:

“Moet de GM onmiddellijk op de hoogte stellen van elke beveiligingsinbreuk, wijziging of elk incident”
Bron: Beleid inzake beveiliging van derden en leveranciers-sme, Rollen en verantwoordelijkheden, clausule 4.4.3

Voor leverancierscontracten op enterprise-niveau adviseert Zenith Blueprint, fase Beheersmaatregelen in de praktijk, stap 23, om vertrouwelijkheidsverplichtingen, verantwoordelijkheden voor toegangscontrole, technische en organisatorische maatregelen, meldtermijnen voor incidenten, auditrechten, beheersmaatregelen voor onderaannemers en bepalingen voor het einde van het contract op te nemen. Het stelt:

“Waar het om gaat is dat ze bestaan, en dat ze door beide partijen worden begrepen en aanvaard.”
Bron: Zenith Blueprint: een 30-stappenroadmap voor auditors, fase Beheersmaatregelen in de praktijk, stap 23: Organisatorische beheersmaatregelen (5.19 tot 5.37)

CVD-gereedheid bij leveranciers moet deze vragen beantwoorden:

• Publiceert de leverancier een meldkanaal voor kwetsbaarheden?
• Zijn meldtermijnen voor kwetsbaarheden in het contract vastgelegd?
• Worden kritieke leverancierskwetsbaarheden zonder onnodige vertraging gemeld?
• Zijn zwaktes met klantimpact gekoppeld aan verplichtingen voor incidentondersteuning?
• Kan de leverancier bewijsmateriaal van herstelmaatregelen of beveiligingsadviezen leveren?
• Worden kwetsbaarheidsverplichtingen doorgelegd naar onderaannemers?
• Is er een exitstrategie als herstelmaatregelen ontoereikend zijn?

Hier komen NIS2, DORA en ISO/IEC 27001:2022 samen. Kwetsbaarhedenbeheer bij leveranciers is geen inkoopvinkje. Het maakt deel uit van operationele weerbaarheid.

Bewijsmapping voor ISO 27001, NIS2, DORA, GDPR en COBIT

De sterkste CVD-programma’s beginnen bij bewijsmateriaal. Zij gaan ervan uit dat elke significante melding later kan worden beoordeeld door interne audit, certificeringsauditors, toezichthouders, klanten, verzekeraars of een risicocomité van de raad van bestuur.

Clarysec’s Beleid voor audit en toezicht op naleving-sme Beleid voor audit en toezicht op naleving - SME legt een detail vast dat veel teams missen:

“Metadata (bijv. wie deze heeft verzameld, wanneer en uit welk systeem) moet worden gedocumenteerd.”
Bron: Beleid voor audit en toezicht op naleving-sme, vereisten voor beleidsimplementatie, clausule 6.2.3

Een screenshot van een gepatchte server is zwak als niemand weet wie deze heeft vastgelegd, wanneer, uit welk systeem en hoe deze aan de kwetsbaarheid is gekoppeld. Een ticket met tijdstempels, scanneruitvoer, pull request, wijzigingsgoedkeuring, uitrollogboeken, monitoringquery, bevestiging van hertest en metadata is veel sterker.

Een meer gedetailleerde traceerbaarheidsmatrix helpt tijdens klant-due diligence en interne audit.

Verschillende auditors toetsen hetzelfde proces vanuit verschillende invalshoeken.

Een ISO/IEC 27001:2022-auditor begint bij het ISMS. Hij of zij vraagt of verplichtingen voor kwetsbaarhedenopenbaarmaking zijn opgenomen in de eisen van belanghebbenden, of risico’s consistent worden beoordeeld, of beheersmaatregelen in de SoA staan, of operationeel bewijsmateriaal bestaat en of het management trends en achterstallige punten beoordeelt.

Een DORA- of financiële-dienstverleningsreviewer richt zich op operationele weerbaarheid. Deze beoordeelt integratie van ICT-risico’s, incidentclassificatie, escalatie naar het hoger management, klantcommunicatie, afhankelijkheden van derden, testen en geleerde lessen. Als de kwetsbaarheid een kritieke of belangrijke functie raakt, verwacht men een sterke koppeling tussen het technische ticket, de bedrijfsimpact, continuïteitsimplicaties en leveranciersverplichtingen.

Een GDPR-reviewer richt zich op persoonsgegevens. Waren persoonsgegevens betrokken? Was er ongeautoriseerde toegang, verlies, wijziging of openbaarmaking? Waren de rollen van verwerkingsverantwoordelijke en verwerker duidelijk? Is de drempel voor een datalek beoordeeld? Waren waarborgen zoals encryptie, toegangscontrole, logging en gegevensminimalisatie relevant?

Een COBIT 2019- of ISACA-auditor richt zich op governance, verantwoordingsplicht, prestaties en assurance. Deze zoekt naar gedefinieerd eigenaarschap, metrieken, escalatie, beheersdoelstellingen, managementtoezicht en opvolging van uitzonderingen. Een achterstallige kritieke kwetsbaarheid is niet alleen een technisch probleem. Het is een governancekwestie tenzij deze formeel is geëscaleerd en als risico is geaccepteerd.

Een NIST-georiënteerde beoordelaar denkt in termen van Identify, Protect, Detect, Respond en Recover. Deze verwacht eigenaarschap van bedrijfsmiddelen, identificatie van kwetsbaarheden, prioritering, beschermende wijziging, detectie van exploitatie, responscoördinatie en herstelvalidatie.

Het voordeel van een geïntegreerd CVD-model is dat dezelfde bewijsketen al deze beoordelingen kan ondersteunen.

De maandelijkse beheerslus: metrieken die management kan gebruiken

CVD eindigt niet wanneer het ticket wordt gesloten. Het Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden vereist doorlopende beoordeling van het logboek:

“Het VRT moet een logboek voor openbaarmaking van kwetsbaarheden bijhouden waarin elke melding vanaf ontvangst tot en met afsluiting wordt gevolgd. Het logboek moet maandelijks worden beoordeeld om tijdige voortgang van openstaande punten te borgen. Achterstallige punten moeten worden geëscaleerd.”
Bron: Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden, monitoring en audit, clausule 9.1

Deze maandelijkse beoordeling maakt van kwetsbaarhedenopenbaarmaking governance die geschikt is voor de raad van bestuur. Management heeft niet elk technisch detail nodig. Het heeft trend, blootstelling, verantwoordingsplicht en achterstallig risico nodig.

In een volwassen Clarysec-implementatie voedt deze maandelijkse logboekbeoordeling het risicoregister, de Verklaring van Toepasselijkheid, de backlog voor veilige ontwikkeling, leveranciersbeoordelingen, geleerde lessen uit incidenten, het interne auditplan en het pakket voor managementrapportage.

Bouw het proces voordat de ernstige melding binnenkomt

Het slechtste moment om gecoördineerde openbaarmaking van kwetsbaarheden te ontwerpen is nadat een onderzoeker uw zwakte publiek heeft gemaakt of een kritieke bankklant de onboarding heeft bevroren. NIS2, DORA, GDPR, ISO/IEC 27001:2022, weerbaarheidsverwachtingen in NIST-stijl en COBIT 2019-governance wijzen allemaal in dezelfde richting: kwetsbaarhedenopenbaarmaking moet worden gepland, belegd, getest, onderbouwd met bewijsmateriaal en verbeterd.

Begin met deze vijf acties:

1. Adopteer of pas het Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden aan.
2. Bouw de intake- en triageworkflow met Zenith Blueprint, met name stap 13 voor SoA-traceerbaarheid, stap 16 voor meldcultuur, stap 19 voor technisch kwetsbaarhedenbeheer en stap 23 voor leveranciersovereenkomsten.
3. Map de workflow via Zenith Controls, met focus op 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 en A.8.32.
4. Voeg mkb-klare clausules toe uit Incidentresponsbeleid-sme, Beleid inzake kwetsbaarheden- en patchbeheer-sme, Beleid inzake beveiliging van derden en leveranciers-sme, Beleid inzake vereisten voor applicatiebeveiliging-sme en Beleid voor audit en toezicht op naleving-sme waar proportionaliteit van belang is.
5. Voer een tabletop-oefening uit die een melding van een onderzoeker simuleert die persoonsgegevens en een door een leverancier gehost component raakt, en test vervolgens bevestiging, triage, incidentclassificatie, patching, klantcommunicatie, vastlegging van bewijsmateriaal en managementescalatie.

Clarysec kan u helpen dit om te zetten in een werkend CVD-beleid, intakeregister, ISO/IEC 27001:2022-bewijsmatrix, NIS2- en DORA-beslisboom, model voor leveranciersescalatie en auditgereed pakket met beheersmaatregelen. Het doel is eenvoudig: wanneer de volgende kwetsbaarheidsmelding binnenkomt, moet uw team niet improviseren. Het moet met vertrouwen, bewijsmateriaal en beheersing handelen.