Knappe klus van Kees (maar..)

Laat ik beginnen met een compliment: Kees “BIO” Hintzbergen heeft met de PDCS Leveranciersmatrix iets heel nuttigs gebouwd: een gestructureerd, actueel overzicht van wat je als organisatie aan je softwareleveranciers mag en moet vragen op het gebied van informatiebeveiliging. Het probleem signaleren is één, maar het (helpen) oplossen bleef niet achterwege. Knap werk van Kees!

Mijn eigen poging

Daterend uit 2022

In december 2022 schreef ik zelf met enkele collega’s van mijn toenmalige opdrachtgever een handreiking met precies datzelfde doel: informatiebeveiliging borgen bij inkoop en aanbesteding zónder gemakzuchtig de gehele BIO op te leggen. Dat was een poging leverancierseisen te vertalen naar iets bruikbaars voor aanbestedingen in de praktijk — geschiktheidseisen, gunningseisen, knock-outcriteria, etc. Gelijktijdig schreef ik er ook deze blog over. Overigens weten mensen die weleens een training van mij gevolgd hebben hoeveel hekel ik heb aan ‘de BIO’ opleggen aan leveranciers. Niet één slide bevat zoveel uitroeptekens als deze.

Terug naar de handreiking: volgens mij zijn we er destijds aardig in geslaagd een bruikbaar instrument op te stellen. Nu, drie jaar later, leg ik die handreiking naast de matrix van Kees. Omdat ik wil weten of ikzelf wat mis(te) en ook of Kees wat mist (zou het?). En vanzelfsprekend is er nogal wat veranderd in die periode. Overigens deel ik mijn handreiking niet. Allereerst is die gedateerd en daarnaast is de handreiking niet mijn eigendom.

"Overigens weten mensen die weleens een training van mij gevolgd hebben hoeveel hekel ik heb aan ‘de BIO’ opleggen aan leveranciers. Niet één slide bevat zoveel uitroeptekens als deze."

Zoek de verschillen

CRA/Cbw/Cbb

Ik heb de twee documenten naast elkaar gelegd en door Claude een GAP-analyse laten uitvoeren. Claude is ook wat Kees gebruikte bij zijn analysewerk. Wat valt op?

De CRA introduceert drie eisen die in 2022 simpelweg niet bestonden. Een Software Bill of Materials (SBOM) was in de Nederlandse overheidsinkoop geen begrip. Een gedocumenteerde ondersteuningsperiode van minimaal vijf jaar ook niet. En patchingstermijnen met harde grenzen — kritieke kwetsbaarheden binnen zeven dagen, hoge binnen dertig — stonden niet in aanbestedingsdocumenten. Dat laatste is nu wettelijk verankerd.

De Cbw/Cbb voegt organisatorische eisen toe aan leveranciers. Een benoemde contactpersoon informatiebeveiliging bij de leverancier. Een aantoonbaar kwetsbaarheidsbeheerproces met gedocumenteerde termijnen. Screening van personeel met toegang tot systemen. Transparantie over wijzigingen in de dienst vooraf. In de handreiking stond daar niets over — (meestal) niet omdat we het niet belangrijk vonden, maar omdat we er ofwel niet in slaagden een goede eis te formuleren ofwel geen goede basis vonden om het als knock-outcriterium op te nemen. Die basis is er nu (praktisch) wel.

Het mag duidelijk zijn dat ik in 2022 nog geen aandacht had voor veel van de zaken die nu onder de (concept) Cbw, Cbb, Cbr en CRA een verplichting zijn. Nee, denk niet dat ik mezelf zie als visionair 😉

GAP-analyse maatregelen

Inzicht in de implementatie(status) van beveiligings-maatregelen uit normenkaders, zoals de BIO2. Een dienst van qeep IT safe.

Lees er meer over ↗

Wat ontbreekt in de matrix

De matrix mist een aantal specifieke eisen die ik wel in de handreiking opnam. De expliciete inhoudseisen aan logregels — wat er minimaal in moet staan, en wat er juist niet in mag — worden door de matrix niet gesteld. Er staat dat logging SIEM-integreerbaar moet zijn; over de inhoud van de logregel wordt niet gesproken. Dat is mogelijk een tekortkoming voor organisaties die in het kader van de Cbw ook de meldplicht voor incidenten volgen: je kunt een incident alleen herleiden als je weet wat er überhaupt wordt gelogd. Tegelijk is het een nogal operationele opendeur, omdat ‘SIEM-integreerbaar’ impliciet dezelfde eis oplegt.

Dan de multitenant-cloudscheiding. De handreiking stelde expliciet dat gebruikers van verschillende organisaties niet bij elkaars gegevens mogen kunnen en geen wederzijdse verstoring mogen veroorzaken. In de matrix staat omgevingsscheiding (OTAP), maar de specifieke multitenant-cloudscheiding ontbreekt. Nu kun je je afvragen of dat nog een reële eis is. Het lijkt me (inmiddels) naïef om dat op te leggen, omdat een leverancier dit niet gaat (wil) bieden in verreweg de meeste situaties. In bijv. een militaire context is dat anders.

Het grootste verschil is het ontbreken van een equivalent van de BBN2+-tabel in de matrix. Onder F beantwoord je de vraag “Risicoprofiel van de leverancier/opdracht” en het antwoord laag, midden of hoog risico levert een steeds ruimere set eisen op onder D2 en D3 (visueel gemaakt in de kolom ‘Status’). De handreiking had voor hooggeclassificeerde processen een aparte set op BBN2+ gebaseerde aanvullende eisen op vijf domeinen: toegangsbeveiliging, cryptografie, back-up, logging/monitoring en netwerkbeveiliging. De matrix kent dus het concept ‘risicoprofiel’ als invoerparameter, maar differentieert niet naar een aanvullende maatregelenset voor de leverancier (D2) of het product/de dienst (D3) bovenop wat wet- en regelgeving eist.

Doorontwikkeling matrix (?)

Een vraagteken, omdat er ook nadelen aan kleven

Op de PDCS-website staat het volgende geschreven over de aanleiding en achtergrond bij de Leveranciersmatrix:

Veel organisaties worstelen met de vraag welke beveiligings- en leveranciersaspecten nu echt relevant zijn bij een beoordeling of inkooptraject. Daarom hebben wij een interactieve leveranciersmatrix ontwikkeld.

Met deze wizard doorloop je stapsgewijs de belangrijkste keuzes en aandachtspunten. Zo krijg je snel een praktisch overzicht dat helpt bij voorbereiding, beoordeling en gesprek met leveranciers.

De matrix lijkt daarbij duidelijk te kiezen voor de compliance-insteek: waar moet je vanuit wet- en regelgeving aan voldoen en wat moet je derhalve minimaal opnemen als eisen richting de softwareleveranciers, rekening houdend met het risicoprofiel van de leverancier/opdracht? Maar wat ‘relevant’ is voor een organisatie kan deze ondergrens (die al moeilijk genoeg is) overstijgen. Op basis van een risicoanalyse kan een organisatie komen tot aanvullende eisen. Daar wordt in de afbeelding ook melding van gemaakt: “De risicoanalyse ex. Cbb art. 7 is altijd leidend – gebruik dit hulpmiddel als handreiking, niet als vervanging.” Overigens gaat dit artikel niet specifiek over risicoanalyse in de context van leveranciers(eisen).

Niettemin zou dat wat mij betreft een mooie aanvulling kunnen zijn: dat de matrix ook aanvullende suggesties op basis van best practices doet (bij D2 en D3) wanneer er sprake is van een hoog risicoprofiel. Dan combineer je de compliance-insteek (wet- en regelgeving) met de risicomanagement-insteek. Wat toch iets anders is dan 'risicogebaseerd voldoen aan wet- en regelgeving'. Valkuil is dat gebruikers dan stoppen met zelf nadenken, terwijl je dát wilt (juist) bij hoge risicoprofielen. En dan ben ik terug bij de bekende spanning tussen compliance en risicomanagement. Tja, daar valt m.i. geen algemeen advies over te geven: de ene organisatie bereikt meer via de risicomanagement- en ISMS-route, terwijl de andere organisatie succesvol(ler) is via de complianceroute.

"De matrix lijkt daarbij duidelijk te kiezen voor de compliance-insteek: waar moet je vanuit wet- en regelgeving aan voldoen en wat moet je derhalve minimaal opnemen als eisen richting de softwareleveranciers, rekening houdend met het risicoprofiel van de leverancier/opdracht?"

En nu wachten

Omdat Kees zeker zal reageren

Tot slot wil ik graag nogmaals opmerken dat Kees erg knap werk heeft geleverd met de matrix. Ik doe het hem niet na. Eindelijk een concreet instrument dat vrij te gebruiken is en voorkomt dat veel organisaties dat allemaal zelf gaan uitvogelen (zoals ik poogde in 2022). Zeker met nieuwe wetten en verplichte normenkaders is het moeilijk bij te blijven. Ik hoop dan ook dat Kees deze tool zal blijven onderhouden. Hij kan mij rekenen tot een van de gebruikers.

En over Kees gesproken; ik hoop en verwacht dat deze opinie een reactie van hem uitlokt. Hem kennende ligt onder iedere keuze een goede overdenking. De balans die hij vond tussen compliance en risicomanagement door gebruik te maken van risicoprofielen is pragmatisch en daar houd ik van. En toch 😄. We gaan er binnenkort maar eens over podcasten.

p.s. podcastuitsmijter: je mag geen ISO 27001-certificaat eisen (als knock-outcriteria) bij een aanbesteding zonder daar aan toe te voegen 'of vergelijkbaar'. Welke evidence vraag je uit bij de (beoogde) leverancier om vast te stellen of wordt voldaan aan 'of vergelijkbaar' indien de leverancier geen ISO 27001-certificaat heeft? En wat vraag je waar in het aanbestedingsproces uit en op welk moment vindt de beoordeling van evidence plaats?