Vrijwel elk incident dat in het NCSC-CSBN wordt beschreven heeft een ketencomponent. Een softwareleverancier met een gecompromitteerde build-pipeline, een managed service provider met onvoldoende gesegmenteerde klantomgevingen, een SaaS-dienst met een datalek — in alle gevallen bereikt de aanval tientallen tot honderden eindorganisaties via één toegangspunt. De keten is zo sterk als de zwakste schakel, en bij complexe supply chains heb je in de meeste gevallen geen volledig beeld van waar die zwakke schakels zitten.

De drie meest voorkomende ketenscenario’s

Het MSP-compromis is het meest impactvolle ketenscenario voor Nederlandse organisaties. Managed service providers beheren de infrastructuur van tientallen tot honderden klanten. Een aanvaller die landt in een MSP-omgeving — via gestolen beheerderscredentials, onvoldoende MFA of een kwetsbaar remote monitoring tool — heeft directe toegang tot alle klantomgevingen tenzij strikte scheiding is doorgevoerd.

Het SaaS-datalek treft organisaties die zakelijke applicaties afnemen van cloudaanbieders. Deze diensten verwerken gevoelige bedrijfsinformatie. Een datalek bij de aanbieder raakt alle klanten tegelijk. Organisaties zijn dan volledig afhankelijk van de aanbieder voor transparantie en meldtijden — wat een contractuele verplichting vereist.

De software build-chain aanval is de meest gevreesde variant: kwaadaardige code wordt geïnjecteerd in een softwareupdate van een legitieme leverancier. Elke organisatie die de update installeert is daarmee gecompromitteerd. Het SolarWinds-incident uit 2020 heeft dit type aanval op de kaart gezet, maar sindsdien zijn er vergelijkbare gevallen geweest.

Dependency map: hoe je inzicht krijgt in je keten

Een dependency map visualiseert alle externe afhankelijkheden van je organisatie. Dat begint met een inventarisatie in vier categorieën. Welke externe systemen ontvangen, verwerken of slaan bedrijfsdata op? Welke authenticatiediensten zijn in gebruik, zoals SSO-providers, MFA-diensten en certificaataanbieders? Welke SaaS-toepassingen worden gebruikt voor CRM, ERP, HR en communicatie? En welke managed service providers of IT-leveranciers hebben beheer- of administratieve toegang tot interne systemen?

Per leverancier classificeer je vervolgens op risico: welke data verwerkt de leverancier, welke toegang heeft die leverancier tot interne systemen, hoe afhankelijk ben je operationeel van die leverancier en wat is het dreigingsprofiel — is de leverancier zelf een bekend doelwit van gerichte aanvallen?

De dependency map moet machine-leesbaar zijn en actief worden onderhouden. Een eenmalige inventarisatie is onvoldoende; het landschap verandert voortdurend bij nieuwe SaaS-koppelingen, nieuwe leveranciers en nieuwe API-integraties.

Contractuele minimumvereisten

NIS2 Artikel 21 vereist dat entiteiten maatregelen nemen voor de veiligheid van de toeleveringsketen. In de praktijk betekent dit contractuele zekerstelling bij leveranciers met toegang tot gevoelige systemen of data.

De minimumvereisten zijn: een informatiebeveiligingsnorm met actueel certificaat of auditverklaring, een meldplicht bij incidenten met impact op de afnemer binnen vier uur na detectie, toegangsbeheer met logging van iedere toegangshandeling bewaard voor minimaal twaalf maanden, een flow-down clause voor subcontracting zodat de beveiligingseisen doorlopen in de hele keten, een recht op inzage in jaarlijkse penetratietestresultaten, en een procedure voor data-afgifte bij beëindiging waarbij gegevens worden opgeleverd in een standaard formaat en eigen kopieën binnen dertig dagen worden verwijderd.

Continue monitoring

Contractuele afspraken weerspiegelen slechts een momentopname. De beveiligingspositie van leveranciers verandert continu. Continue monitoring vereist abonnementen op CVE-notificaties voor software van leveranciers, gebruik van externe attack surface monitoring en bewaking van credential exposure via darkweb-monitors.

Vraag leveranciers jaarlijks om een self-assessment of auditverklaring op basis van een gestandaardiseerde vragenlijst. Vergelijk resultaten met voorgaande jaren. Stel leveranciers contractueel verplicht jou als eerste te informeren bij een incident — niet via een persbericht, maar direct.

Standpunt

Ketenrisico is het onderwerp waar ik professionals de meeste blinde vlekken zie hebben. Niet omdat ze het niet begrijpen — het concept is simpel — maar omdat de practische gevolgen enorme discipline vereisen die moeilijk in stand te houden is.

Het bijhouden van een dependency map klinkt als eenvoudig bureauwerk. In de praktijk is het een constante strijd tegen organisatorische entropie. Elke marketeer die een nieuw analytics-tool koppelt, elke ontwikkelaar die een API-integratie bouwt, elke inkoop die een SaaS-abonnement afsluit zonder IT erbij te betrekken — het zijn kleine stappen die samen de map onbetrouwbaar maken.

Wat me bij CyberSecurity AD altijd heeft gedreven is de overtuiging dat je keten maar zo sterk is als de aandacht die je eraan besteedt. We hebben onze eigen leveranciersketen kritisch beoordeeld en bewust klein gehouden. Minder afhankelijkheden betekent minder risico. Dat is een architectuurkeuze met directe gevolgen voor de veiligheidspositie.

Voor advocatenkantoren die AI-tools evalueren is het ketenperspectief ook relevant. Een AI-leverancier die data doorstopt naar subverwerkers die op hun beurt data doorsturen naar nog andere partijen, is een ketenrisico dat moeilijk te overzien en te beheersen is. CyberSecurity AD is bewust ontworpen als een gesloten verwerkingsketen: data gaat nergens naartoe. Dat is eenvoudiger te verifiëren en eenvoudiger te verdedigen tegenover een toezichthouder.