Wie vertrouwt op leveranciers, deelt verantwoordelijkheid voor beveiliging, ook als die buiten de organisatie ligt. Met strengere eisen vanuit NIS2 groeit de druk om zicht te krijgen op risico’s in de keten en daar ook op te handelen. Tegelijk verschuiven hacking-technieken richting minder zichtbare plekken, zoals software-updates en embedded systemen. Hoe krijgt een organisatie grip op wat buiten het directe bereik gebeurt, zonder de samenwerking met leveranciers te blokkeren?
1. Wat supply chain attacks zijn
Een supply chain attack richt zich niet op het einddoel zelf, maar op een zwakkere schakel in het netwerk van leveranciers, dienstverleners of softwareleveranciers waarmee dat doel verbonden is. Aanvallers zoeken toegang via externe partijen om zo indirect, maar effectief, een primaire organisatie binnen te dringen. Die ketenbenadering maakt supply chain attacks bijzonder effectief en lastig te detecteren. Het vertrouwen in bestaande samenwerkingen, gedeelde infrastructuur en automatisering maakt deze aanvalsvorm aantrekkelijk voor aanvallers met strategische motieven.
Hoewel hacking vaak geassocieerd wordt met directe inbraak op een netwerk, verschuift de tactiek steeds vaker naar indirecte paden. Dit dwingt organisaties om niet alleen hun interne beveiliging onder de loep te nemen, maar ook die van alle partners, leveranciers en integraties binnen het IT-ecosysteem.
Het ketenmodel in IT-context
Een moderne organisatie werkt vrijwel nooit volledig geïsoleerd. ERP-systemen worden geïntegreerd met externe HR-tools, klantdata loopt via cloudapplicaties van derden, en updates voor software of hardware worden automatisch doorgevoerd door leveranciers. Elk van die verbindingen is onderdeel van een keten die door een kwaadwillende als toegangspoort kan worden benut.
Kenmerkend voor supply chain attacks is dat de initiële aanval plaatsvindt buiten het directe gezichtsveld van het slachtoffer. Pas wanneer systemen afwijkend gedrag vertonen, gegevens lekken of ransomware actief wordt, komt de aanval aan het licht.
Belangrijke kenmerken van een digitale ketenaanval:
- De aanval vindt plaats via een vertrouwde externe partij
- De aanvaller gebruikt bestaande toegangsrechten of software
- Detectie wordt bemoeilijkt doordat gedrag initieel legitiem lijkt
- Impact reikt vaak verder dan één organisatie
De afhankelijkheid van externe diensten maakt het voor organisaties noodzakelijk om verder te kijken dan alleen de eigen netwerken of systemen. Beveiliging stopt niet bij de firewall.
Vertrouwen als kwetsbaarheid
Veel ketenaanvallen slagen omdat leveranciers of partners automatisch als ‘veilig’ worden beschouwd. Toegangsrechten zijn vaak ruim, software-updates worden zonder extra validatie geïnstalleerd, en netwerktoegang is meestal permanent ingesteld. Dit impliciete vertrouwen vormt een zwak punt in het beveiligingsmodel van veel organisaties.
Beveiligingsteams zijn geneigd om risico’s in te schatten op basis van directe dreigingen. Leverancierscontracten, automatische updates en externe plug-ins worden daardoor niet altijd opgenomen in het formele risicobeheerproces. Dit creëert blinde vlekken die moeilijk met technische detectie alleen zijn af te vangen.
Voorbeelden van veelvoorkomende vertrouwensrisico’s:
- Onbeperkte API-toegang voor externe tools
- Gedeelde credentials tussen organisaties
- Geen segmentatie tussen leveranciersverkeer en interne systemen
- Afwezigheid van logging op integratiepunten
Een risicogericht beleid, zoals voorgeschreven in ISO 27001, vereist dat deze integraties structureel worden opgenomen in de risicoanalyse. Niet alleen de technologie, maar ook de governance rondom leveranciersbeveiliging is bepalend voor weerbaarheid.
Shadow connections en onzichtbare afhankelijkheden
Een groot probleem bij supply chain risico’s is dat veel verbindingen niet zichtbaar zijn voor de IT-afdeling of het management. Applicaties installeren zelf afhankelijkheden (zoals npm-packages of plug-ins), medewerkers nemen zelf diensten af via SaaS-modellen, en tijdelijke partners krijgen blijvende toegang tot systemen. Deze shadow connections ontsnappen vaak aan monitoring en beheer.
Zonder volledig overzicht is het onmogelijk om de werkelijke aanvalsvectoren te beheersen. Dit maakt supply chain attacks onvoorspelbaar: de kwetsbaarheid kan zich bevinden in een dependency die door geen enkele partij actief wordt beheerd of geëvalueerd.
Voorbeelden van onzichtbare afhankelijkheden:
- Een CMS-plug-in die automatisch updates uitvoert vanuit een onbekende bron
- Software die open source componenten gebruikt die indirect afhankelijk zijn van andere repositories
- Werknemers die projecttools koppelen aan bedrijfsaccounts zonder validatie
- Legacy-integraties die nooit zijn afgesloten na beëindiging van een samenwerking
Organisaties die NEN7510 of ISO 27001 hanteren, worden gestimuleerd om configuratiebeheer, assetmanagement en leveranciersbeoordeling structureel op te nemen in het Information Security Management System (ISMS).
Software als toegangspoort
Softwareleveranciers vormen een risicocategorie op zichzelf. Elke update, patch of configuratie die zij uitvoeren, beïnvloedt direct de systemen van hun klanten. Omdat deze updates vaak via geautomatiseerde processen verlopen, is de controle op de inhoud beperkt. Aanvallers die weten door te dringen tot de softwarebuild van een leverancier, kunnen via legitieme distributiekanalen malware verspreiden.
Belangrijke aandachtspunten bij softwareleveranciers:
- Automatische updates zonder validatie
- Gebrek aan code signing of integriteitscontrole
- Ontbreken van update logging op endpoint-niveau
- Verouderde versies in productie die niet worden gepatcht
Bij supply chain attacks is de keten dus niet alleen organisatorisch, maar ook technisch opgebouwd. Elke softwarelaag of updatekanaal kan een zwak punt vormen. Zonder een goed ingericht updatebeleid, inclusief validatie en rollback-mechanismen, wordt elke update een potentiële aanvalsvector.
Softwareketens in open source
Veel moderne software is opgebouwd uit tientallen of zelfs honderden open source componenten. Dit versnelt ontwikkeling, maar introduceert ook risico’s. Niet alle componenten zijn actief onderhouden, en afhankelijkheden tussen libraries kunnen onbedoeld leiden tot kwetsbaarheden.
Aanvallers misbruiken dit door bijvoorbeeld een package te kapen, kwaadaardige code toe te voegen en te wachten tot deze automatisch wordt geïnstalleerd in productieomgevingen. Omdat het gedrag van de code vaak nauwelijks afwijkt van het origineel, wordt deze vorm van supply chain attack zelden herkend.
Risico’s in open source-ketens:
- Projecten zonder actieve beheerder
- Bibliotheken die afhankelijk zijn van onveilige submodules
- Onvoldoende validatie van broncode bij CI/CD pipelines
- Afwezigheid van Software Bill of Materials (SBOM)
De inzet van SBOM’s en geautomatiseerde dependency scanning is een belangrijke stap om grip te krijgen op de softwareketen. Zowel ISO 27001 als het NIST Cybersecurity Framework adviseren het vastleggen van softwarecomponenten als onderdeel van configuratiebeheer.
2. Hoe supply chain attacks werken
Een supply chain attack is geen simpele inbraak. De aanval is strategisch opgebouwd, vaak langdurig voorbereid en specifiek afgestemd op de structuur van de keten. Aanvallers zoeken zwakke plekken bij leveranciers, softwarepartners of externe dienstverleners, waarbij de aanval zich pas later richting het uiteindelijke doel beweegt. Dat maakt de aanval niet alleen lastig te detecteren, maar ook lastig te stoppen zodra deze in gang is gezet. Begrijpen hoe deze aanvallen technisch en tactisch verlopen is noodzakelijk om risico’s tijdig te signaleren en ketenverdediging in te richten.
Aanvalsfasering in supply chain aanvallen
Een typische supply chain aanval bestaat uit meerdere fases. Deze fases kunnen zich over weken of zelfs maanden uitstrekken. Elke stap wordt zorgvuldig gekozen, zodat de aanval onopgemerkt blijft en maximale impact kan veroorzaken.
- Toegang verkrijgen tot de leverancier: vaak via phishing, misbruik van kwetsbaarheden of gestolen credentials.
- Aanval voorbereiden binnen het leverancierssysteem: bijvoorbeeld door toegang tot softwarebuilds of updatekanalen te krijgen.
- Infectie van de klantomgeving via een vertrouwd kanaal: zoals een software-update, API-verbinding of beheerdersinterface.
- Laterale beweging en escalatie binnen het doelwitnetwerk: zodra de payload is afgeleverd, wordt deze geactiveerd om dieper toegang te verkrijgen.
- Exfiltratie of verstoring: bijvoorbeeld door het stelen van data, installeren van ransomware of verstoren van productieprocessen.
Anders dan bij directe aanvallen, is de initiële aanval vaak moeilijk te herkennen als kwaadaardig gedrag. Er is sprake van legitieme toegang en bekende software, waardoor traditionele detectiemethoden tekortschieten.
Misbruik van legitieme infrastructuur
Een van de belangrijkste kenmerken van supply chain attacks is het misbruik van systemen die normaal als vertrouwd worden beschouwd. Dit kan zich uiten in:
- Het aanpassen van softwarepakketten vóór distributie
- Het toevoegen van kwaadaardige code aan scripts of libraries
- Het manipuleren van configuratiebestanden of policies
- Het versturen van malafide updates via automatische systemen
Aanvallers maken hier slim gebruik van bestaande processen. Beheerders en IT-teams hebben vaak geen reden om extra controles uit te voeren, omdat de updates vanuit een vertrouwde bron lijken te komen. Vooral in DevOps-omgevingen, waar snelheid belangrijk is, wordt security soms uitgesteld of genegeerd.
Softwareontwikkeling als aanvalsvector
Supply chain aanvallen richten zich regelmatig op het softwareontwikkelproces. Softwarebouwsystemen (CI/CD-pijplijnen), package managers en versiebeheer vormen aantrekkelijke doelwitten, omdat een succesvolle infectie in de ontwikkelfase automatisch leidt tot besmetting van alle afgeleverde software.
Kwetsbare punten in softwareontwikkeling:
- CI/CD-omgevingen zonder toegangscontrole
- Onbeveiligde build agents of runners
- Ongetekende packages of updates
- Automatische afhankelijkheden vanuit externe repositories
Een supply chain aanval kan beginnen met een minimale wijziging in een veelgebruikte open source library. Wanneer deze code vervolgens in duizenden applicaties wordt geïntegreerd, heeft de aanvaller een directe ingang in honderden omgevingen. Dit maakt supply chain attacks zeer schaalbaar én effectief.
Toegang via IT-dienstverleners
IT-leveranciers en serviceproviders vormen een ander risicoprofiel. Zij hebben vaak directe toegang tot systemen, via remote beheeroplossingen of VPN’s. Aanvallers die via een IT-dienstverlener toegang krijgen, kunnen met één geslaagde aanval meerdere klanten tegelijk infecteren.
Voorbeelden van misbruik via IT-dienstverleners:
- Remote monitoring and management (RMM) tools die worden misbruikt
- IT-beheerdersaccounts die breed zijn uitgerold bij klanten
- Gedeelde wachtwoorden of SSH-sleutels zonder rotatiebeleid
- Externe scripts of updates die direct op klantomgevingen draaien
De impact van zo’n aanval is vaak veel groter dan bij één-op-één aanvallen. Omdat een dienstverlener tientallen of honderden omgevingen beheert, verspreidt de infectie zich razendsnel. Bovendien is de initiële toegang technisch legitiem, wat detectie nog moeilijker maakt.
Leveranciers met permanente netwerktoegang
Veel bedrijven geven leveranciers structurele toegang tot delen van hun netwerk. Denk aan integraties met ERP-systemen, API-verbindingen met logistieke ketens of partners die via SFTP toegang hebben tot gevoelige gegevens. Deze verbindingen blijven vaak langdurig actief, ook als de samenwerking is gewijzigd of beëindigd.
Risico’s bij langdurige externe toegang:
- Verouderde inloggegevens worden niet ingetrokken
- Logging ontbreekt of is beperkt op deze verbindingen
- API-keys blijven actief zonder vervaldatum
- Toegang tot testomgevingen biedt ook toegang tot productie
Een aanvaller die toegang heeft tot de systemen van een leverancier, kan via deze verbinding direct binnendringen in het netwerk van het doelwit. Vooral als netwerksegmentatie ontbreekt of standaardconfiguraties worden gebruikt, is deze stap eenvoudig uit te voeren.
Manipulatie van updates en packages
Een veelgebruikte methode in supply chain attacks is het injecteren van kwaadaardige code in software-updates of packages. Zodra klanten de update installeren, wordt de malware geactiveerd. Dit is effectief omdat updates vaak automatisch verlopen en zelden handmatig gecontroleerd worden.
Kernproblemen:
- Geen controle op de inhoud van updates
- Geen controle op wie wijzigingen in packages mag uitvoeren
- Geen rollback-mogelijkheid bij besmette updates
- Onvoldoende validatie van digitale handtekeningen
Beveiligingsmaatregelen zoals code signing, update-validatie en integriteitscontrole worden nog niet overal toegepast. Hierdoor kunnen aanvallers ongemerkt malware verspreiden onder legitieme vlag.
Kwetsbaarheden in build- en deployprocessen
CI/CD-processen die onvoldoende zijn afgeschermd, vormen een direct doelwit. Aanvallers injecteren code in het buildproces, bijvoorbeeld via onbeveiligde scripts, kwetsbare plug-ins of misbruik van toegangsrechten. De resulterende software lijkt legitiem, maar bevat backdoors, exfiltratiecode of ransomwarecomponenten.
Aandachtspunten:
- Beveilig de toegang tot CI/CD-platforms
- Gebruik secrets management om credentials te beschermen
- Implementeer automatische scanning op packages
- Monitor wijzigingen in scripts en buildconfiguraties
ISO 27001 stelt dat alle fasen van softwareontwikkeling, inclusief deployment, moeten worden opgenomen in het information security management system. Toch blijkt in de praktijk dat vooral open source en extern beheerde CI/CD-omgevingen vaak buiten scope vallen.
3. Voorbeelden van supply chain aanvallen
Supply chain aanvallen vallen op doordat ze vaak grote aantallen slachtoffers treffen via één geïnfecteerde bron. De impact is zelden beperkt tot één organisatie, omdat de aanvaller zich toegang verschaft tot een platform, dienst of leverancier die meerdere klanten tegelijk bedient. De bekendste aanvallen van de afgelopen jaren laten zien hoe geraffineerd, langdurig en schaalbaar deze methoden zijn. Tegelijk laten ze zien hoe belangrijk het is om ketenafhankelijkheden inzichtelijk te hebben en processen zoals software-integratie en leveranciersbeheer beter te beveiligen.
De voorbeelden hieronder illustreren hoe divers supply chain attacks kunnen zijn. De aanvallen richten zich niet alleen op software, maar ook op diensten, hardware en zelfs menselijke processen.
SolarWinds en de infectie van Orion
Eén van de bekendste supply chain aanvallen vond plaats via het IT-beheerplatform SolarWinds Orion. Aanvallers wisten via de ontwikkelomgeving van SolarWinds kwaadaardige code in een reguliere update van de Orion-software te injecteren. Deze update werd vervolgens uitgerold naar duizenden klanten, waaronder overheidsinstellingen, multinationals en IT-providers.
Kenmerken van de aanval:
- Kwaadaardige code werd toegevoegd vóór het buildproces, waardoor deze in officiële distributie terechtkwam
- De malware bleef maandenlang onopgemerkt actief binnen netwerken
- De aanval was gericht op spionage en gegevensdiefstal
- Detectie werd bemoeilijkt doordat alles via legitieme updatekanalen verliep
SolarWinds kreeg een boete van ruim 26 miljoen dollar opgelegd door de SEC vanwege misleiding over hun beveiligingsbeleid. De zaak wordt internationaal gezien als kantelpunt in de verantwoordelijkheid van leveranciers binnen de softwareketen.
Kaseya en RMM-misbruik
Kaseya, een leverancier van RMM-software (Remote Monitoring & Management) voor IT-dienstverleners, werd doelwit van een ransomwarecampagne. Aanvallers misbruikten kwetsbaarheden in de software om ransomware uit te rollen via beheerde IT-omgevingen van dienstverleners. Hierdoor raakten honderden bedrijven wereldwijd in één aanval geïnfecteerd.
Bijzonder aan deze aanval:
- Aanvallers misbruikten de vertrouwde positie van Kaseya binnen klantomgevingen
- Klanten waren vaak kleine tot middelgrote bedrijven met beperkte beveiligingscapaciteit
- Updates werden automatisch geïnstalleerd, wat de verspreiding versnelde
- De aanval vond plaats rond een feestdag, wat de respons vertraagde
De impact van deze aanval onderstreept het belang van segmentatie, patchbeheer en validatie van automatische software-updates.
NotPetya via boekhoudsoftware
In 2017 werd Oekraïense boekhoudsoftware gebruikt als aanvalskanaal voor de NotPetya-malware. De softwareleverancier werd geïnfecteerd en rolde ongemerkt de malware uit via een reguliere software-update. Hoewel de aanval ogenschijnlijk gericht was op Oekraïense systemen, verspreidde de malware zich wereldwijd, mede doordat internationale bedrijven dezelfde software gebruikten voor lokale compliance.
Bijzonderheden:
- Malware verspreidde zich snel via laterale beweging binnen netwerken
- Het ging niet alleen om dataversleuteling, maar ook om permanente verstoring
- Systemen waren na infectie niet herstelbaar zonder volledige herinstallatie
- Bedrijven zoals Maersk en Merck leden enorme schade
De NotPetya-case toont hoe een relatief lokaal softwarebedrijf als onbedoeld wereldwijd aanvalskanaal kan functioneren.
Code-injectie in npm-pakketten
Open source libraries vormen een minder zichtbare, maar veelgebruikte schakel in softwareketens. Er zijn meerdere incidenten geweest waarbij kwaadwillenden packages op npm (de package manager voor JavaScript) manipuleerden. Soms gebeurde dit via overname van verwaarloosde projecten, soms via identiek ogende packages met een subtiel andere naam (typosquatting).
Kenmerken van deze vorm van aanval:
- Automatische installatie tijdens buildprocessen zonder menselijke tussenkomst
- Verspreiding naar duizenden applicaties via dependency chains
- Kwaadaardige functies die pas in productie worden geactiveerd
- Moeilijk te traceren, omdat de malware in legitieme projecten verborgen zit
Voor ontwikkelteams zonder SBOM en monitoring is dit type infectie vrijwel onzichtbaar.
Aanval op hardware-leverancier Supermicro
Hoewel minder vaak besproken, zijn ook hardwareleveranciers doelwit van supply chain aanvallen. Een voorbeeld hiervan is de bewering dat servers van Supermicro, gebruikt door grote techbedrijven, tijdens productie zouden zijn voorzien van extra chips voor afluisterdoeleinden. Hoewel deze specifieke claim publiekelijk nooit is bewezen, toont het scenario wel hoe supply chain-aanvallen zich ook kunnen richten op hardware-niveau.
Risico’s bij hardware supply chains:
- Manipulatie van componenten in de productie- of assemblagefase
- Fysieke aanpassingen die moeilijk te detecteren zijn zonder reverse engineering
- Afluisterchips of backdoors die pas bij activatie worden zichtbaar
Deze aanvalsvorm is zeldzamer, maar relevant bij gevoelige infrastructuren zoals datacenters, overheidsnetwerken of militaire systemen.
Nederlandse context: aanvallen op IT-partners
In Nederland zijn er meerdere meldingen geweest van ketenaanvallen via IT-dienstverleners. In sommige gevallen ging het om remote beheersystemen die werden misbruikt, in andere gevallen om updates die door dienstverleners aan meerdere klanten tegelijk werden uitgerold.
Kenmerkende zwaktes in deze gevallen:
- Geen logging op externe verbindingen
- Onvoldoende controle op rechtenstructuren van externe partijen
- Gebrek aan patchbeheer of segmentatie
- Aannames over betrouwbaarheid van partners zonder formele beoordeling
Vooral in het mkb ontbreekt vaak de capaciteit om leveranciersrisico’s structureel te managen.
Wat deze aanvallen met elkaar gemeen hebben
Hoewel de sectoren, technologieën en aanvalsmethoden verschillen, hebben deze supply chain aanvallen een aantal overeenkomstige kenmerken:
- Misbruik van vertrouwen: De aanvallen gebruiken legitieme kanalen of bekende software.
- Schaalbaarheid: Eén succesvolle aanval levert toegang op tot honderden of duizenden systemen.
- Lage zichtbaarheid: Detectie is lastig omdat er weinig afwijkend gedrag is in het beginstadium.
- Langdurige voorbereiding: De aanvallen worden strategisch gepland en blijven lang onder de radar.
- Indirecte schade: Naast de directe slachtoffers worden vaak ook eindklanten geraakt.
Deze combinatie maakt supply chain attacks aantrekkelijk voor statelijke actoren, cybercriminele groepen en ransomwarebendes die op zoek zijn naar maximale impact met minimale inspanning.
4. Gevolgen van een supply chain attack
Een supply chain attack raakt zelden één organisatie. De effecten verspreiden zich via verbonden systemen, gedeelde software, externe leveranciers en geïntegreerde diensten. De gevolgen zijn daarom vaak breder, langduriger en moeilijker te beheersen dan bij directe aanvallen. Waar traditionele aanvallen vooral interne schade veroorzaken, brengen supply chain aanvallen risico’s met zich mee op het gebied van vertrouwen, reputatie, aansprakelijkheid en compliance in de hele keten. Organisaties krijgen te maken met complexe herstelprocessen die niet eindigen bij hun eigen netwerkgrenzen.
De gevolgen van een dergelijke aanval verschillen per sector en type dienst, maar volgen meestal een vergelijkbaar patroon: van verstoring naar schade, en van herstel naar structurele aanpassing van het beleid.
Vertrouwen in de keten verdwijnt snel
Een van de meest onderschatte gevolgen van een supply chain attack is het verlies van vertrouwen. Zowel klanten als samenwerkingspartners verwachten dat externe leveranciers veilig opereren. Zodra blijkt dat een derde partij als ingang voor een aanval is gebruikt, komt niet alleen de leverancier onder druk te staan, maar ook alle afnemers.
Verlies van vertrouwen uit zich op meerdere niveaus:
- Klanten kunnen dienstverlening tijdelijk of permanent stopzetten
- Partners eisen aanvullende contractuele en technische garanties
- Bevoegde toezichthouders stellen kritische vragen over due diligence en leveranciersbeoordeling
- Reputatieschade maakt het aantrekken van nieuwe klanten of investeerders lastiger
Het herstellen van vertrouwen vereist meer dan technische herstelmaatregelen. Transparantie, communicatie en zichtbare actie richting interne én externe stakeholders zijn essentieel.
Juridische en contractuele gevolgen
Bij supply chain aanvallen is vaak sprake van onduidelijkheid over de aansprakelijkheid. In veel gevallen blijkt de juridische dekking in bestaande contracten onvoldoende om de gevolgen af te dekken. Dit leidt tot conflicten tussen klant en leverancier, en mogelijk zelfs tot juridische procedures.
Mogelijke juridische complicaties:
- Schadeclaims van klanten voor gemiste omzet of reputatieschade
- Inbreuk op contractuele verplichtingen rond beschikbaarheid of integriteit van data
- Onvoldoende afspraken over incidentrespons en meldplicht
- Interpretatieverschillen over ‘best practices’ en wat als nalatig wordt gezien
Zeker wanneer persoonsgegevens betrokken zijn, ontstaat daarnaast het risico op boetes onder de AVG. Organisaties die via een derde partij betrokken raken bij een datalek moeten nog steeds voldoen aan meldplichten en risicobeoordelingen.
Verstoring van primaire processen
Wanneer een aanval zich via een leverancier verspreidt, worden vaak ook essentiële processen geraakt. Denk aan zorginstellingen die niet meer bij patiëntgegevens kunnen, productiebedrijven waarvan de planningssystemen offline zijn of gemeenten die geen burgerzaken kunnen afhandelen.
De impact op bedrijfscontinuïteit uit zich onder andere in:
- Uitval van bedrijfskritische software of infrastructuur
- Vertragingen in dienstverlening of levering
- Aanzienlijke kosten voor tijdelijke alternatieve processen
- Verminderde veiligheid in fysieke en digitale omgevingen
Het uitvallen van een systeem dat via een externe partij wordt beheerd, zorgt er bovendien voor dat organisaties afhankelijk zijn van de snelheid en kwaliteit van de respons van die partij. Dat maakt eigen crisismanagement complexer en minder voorspelbaar.
Complexiteit van herstel
Herstellen van een supply chain aanval is vrijwel nooit een puur technische kwestie. De aanvaller zit vaak niet alleen in het netwerk van één organisatie, maar beweegt zich tussen systemen van verschillende partijen. Bovendien is er meestal sprake van langdurige, stille aanwezigheid voordat de aanval wordt ontdekt.
Herstel wordt bemoeilijkt door:
- Onvoldoende logging bij externe partijen of integraties
- Beperkt zicht op afhankelijkheden in de keten
- Gebrek aan eenduidige communicatieprotocollen bij incidenten
- Verschillende securityniveaus bij partners, waardoor synchronisatie ontbreekt
Voor organisaties die ISO 27001 of NEN 7510 toepassen, is dit een argument om ketenmonitoring, leveranciersaudits en incidentafspraken structureel onderdeel te maken van het Information Security Management System (ISMS).
Gevolgen voor informatiebeveiligingsbeleid
Een geslaagde ketenaanval leidt bijna altijd tot herziening van het informatiebeveiligingsbeleid. Vaak wordt de zwakke schakel gevonden in onvoldoende leveranciersbeheer, gebrekkige onboardingprocedures of een te groot vertrouwen in derde partijen. Dit dwingt organisaties tot structurele aanpassingen.
Typische beleidsmatige gevolgen:
- Aanscherping van due diligence-procedures bij nieuwe leveranciers
- Verplichte security-audits en documentatie van externe software
- Invoering van Software Bill of Materials (SBOM) bij alle kritieke applicaties
- Contractuele eisen aan logging, monitoring en respons-capaciteit van leveranciers
- Aanpassing van risicoanalyse-methodes om ook ketenrisico’s beter te modelleren
Ook het mandaat van de Information Security Officer (ISO) wordt vaak versterkt na een incident, inclusief meer betrokkenheid bij inkoop, leveranciersselectie en architectuurbesluiten.
Reputatieschade en publieke impact
Als een organisatie publiekelijk betrokken raakt bij een supply chain incident, kan de schade zich snel uitbreiden naar reputatie en klantvertrouwen. Zeker als persoonsgegevens of vertrouwelijke klantdata in het geding zijn, groeit de druk vanuit media, klanten en toezichthouders.
Reputatieschade uit zich bijvoorbeeld in:
- Verlies van klanten of deals
- Negatieve berichtgeving en publieke afkeuring
- Afnemende aantrekkingskracht als werkgever
- Twijfels bij toezichthouders of investeerders over beheersing
Vooral organisaties in vitale sectoren zoals zorg, energie of overheid moeten rekening houden met maatschappelijke gevolgen, inclusief politieke aandacht of kamervragen.
Indirecte verspreiding van risico
Een minder zichtbaar gevolg van supply chain aanvallen is het risico dat de aanvaller via één partij toegang krijgt tot andere netwerken. Denk aan beheerders met toegang tot meerdere klanten, of softwarecomponenten die in meerdere applicaties worden hergebruikt.
Indirecte risico’s zijn onder meer:
- Laterale beweging naar verbonden organisaties
- Infectie van andere leveranciers via gedeelde componenten
- Hergebruik van gelekte credentials in andere systemen (credential stuffing)
- Structurele ondermijning van de software-integriteit in CI/CD-ketens
5. Verantwoordelijkheid en toezicht in de keten
Verantwoordelijkheid voor informatiebeveiliging ligt allang niet meer uitsluitend bij de interne IT-afdeling. In een tijd waarin organisaties afhankelijk zijn van tientallen externe leveranciers, softwarediensten en IT-partners, verschuift de verantwoordelijkheid naar de volledige keten. Daarbij komt steeds vaker de vraag: wie is aanspreekbaar als er iets misgaat? En hoe wordt toezicht gehouden op partijen die buiten het directe gezag van de organisatie vallen?
Wet- en regelgeving zoals NIS2 verplicht organisaties niet alleen om hun eigen beveiliging op orde te hebben, maar ook om toezicht te houden op hun toeleveranciers. Dat vraagt om duidelijke afspraken, gestructureerde processen en aantoonbaar beleid. Zonder inzicht in verantwoordelijkheden en toezichtmechanismen blijft ketenbeveiliging een zwakke schakel.
Toezicht begint bij rolverdeling
Een effectief toezichtmodel begint met het vastleggen van wie waarvoor verantwoordelijk is, zowel binnen de eigen organisatie als richting leveranciers. Te vaak wordt vertrouwd op impliciete aannames of verouderde contracten. Dit leidt tot gaten in de monitoring, onduidelijkheid bij incidenten en trage respons.
Belangrijke stappen:
- Benoem wie verantwoordelijk is voor leveranciersbeheer binnen informatiebeveiliging
- Leg bij elk type leverancier vast wie de security owner is (vaak niet alleen IT)
- Documenteer wie eindverantwoordelijk is voor rapportage aan directie en toezichthouders
- Breng afhankelijkheden tussen leveranciers (bijv. hosting via subpartij) expliciet in kaart
Een formele rol voor een Information Security Officer (ISO of CISO) is hierin essentieel. Die moet niet alleen intern mandaat hebben, maar ook invloed uitoefenen op de keuzes die gemaakt worden bij externe contracten, aanbestedingen en software-integratie.
Verantwoordelijkheid bij softwareleveranciers
Softwareleveranciers leveren vaak updates, patches en plugins waar klanten geen directe controle over hebben. Toch blijven klanten verantwoordelijk voor de gevolgen van een inbraak via deze wegen. Bij supply chain attacks zoals bij SolarWinds of 3CX blijkt hoe belangrijk het is dat leveranciers niet blind worden vertrouwd, ook niet als ze jarenlang betrouwbaar zijn gebleken.
Praktische richtlijnen:
- Vraag actief om inzicht in het ontwikkelproces, CI/CD-keten en security testing
- Eis bij kritieke leveranciers een Software Bill of Materials (SBOM)
- Leg in het contract vast wie aansprakelijk is bij kwetsbaarheden in geleverde software
- Controleer of leveranciers op eigen initiatief kwetsbaarheden melden
Zonder duidelijke afspraken blijft het risico bestaan dat leveranciers beveiliging als bijzaak behandelen. En dat kan leiden tot situaties waarin de klant opdraait voor schade die buiten de eigen controle is ontstaan.
Contractuele vastlegging van toezicht
Toezicht is niet vrijblijvend. Het moet onderdeel zijn van elke samenwerking met externe partijen. Dat betekent dat al tijdens het contractproces beveiligingseisen besproken en vastgelegd moeten worden. Idealiter gebeurt dit op basis van een standaard risicobeoordeling, afhankelijk van de aard en impact van de dienst.
Onderwerpen die contractueel vastgelegd moeten worden:
- Beveiligingsnormen die de leverancier moet volgen (bijv. ISO 27001, NEN 7510)
- Frequentie van audits of bewijsvoering (SOC 2-rapport, pentests)
- Incidentmeldplicht (tijd, vorm en inhoud)
- Rechten voor inspectie of controle door klant of derde partij
- Afspraken over subverwerking en ketenverantwoordelijkheid
Bij kritieke diensten is het verstandig om een auditrecht op te nemen: het recht om zelf of via een derde partij de securityprocessen van de leverancier te controleren.
Interne governance en compliance
Toezicht op leveranciers vereist intern governance: processen, rollen en rapportagelijnen die zorgen dat risico’s tijdig worden gesignaleerd en besproken. Daarbij hoort een vaste cyclus van leveranciersbeoordeling, waarin beveiliging een vast onderdeel is.
Aanbevelingen:
- Integreer leveranciersbeoordeling in het ISMS (Information Security Management System)
- Zorg voor security input bij inkoopbeslissingen en contractverlengingen
- Leg leveranciersrisico’s vast in het risicoregister en behandel deze in directierapportages
- Zorg dat compliance-afdelingen betrokken zijn bij toetsing van externe partijen
- Gebruik een leveranciersscorekaart waarin security meetbaar en vergelijkbaar wordt
Voor organisaties die onder NIS2 vallen, zijn deze maatregelen niet optioneel. De wet verplicht tot zorgvuldige ketenbeheersing, waarbij ook derden onder toezicht vallen wanneer hun dienst impact heeft op de continuïteit of integriteit van systemen.
Incidentverantwoordelijkheid in de keten
Bij incidenten is snel duidelijkheid nodig over wie wat moet doen. Toch blijkt in de praktijk dat incidentverantwoordelijkheid zelden goed vastligt. Hierdoor ontstaan vertragingen, incomplete meldingen en onduidelijke communicatie naar toezichthouders of klanten.
Essentiële afspraken:
- Wie meldt een incident als het ontstaat bij een leverancier?
- Hoe snel moet dat, en via welk kanaal?
- Wat moet de leverancier minimaal aan informatie aanleveren?
- Wie bepaalt of de klant melding moet doen bij toezichthouders?
- Hoe wordt informatie gedeeld met andere ketenpartners?
Deze afspraken moeten niet alleen op papier staan, maar ook getest worden. Bijvoorbeeld via gezamenlijke tabletop-oefeningen met leveranciers, waarbij scenario’s worden doorgelopen zoals bij hacking via embedded software of besmette updates.
Audit en controle
Toezicht is meer dan monitoring. Het vraagt om gestructureerde controlemechanismen die aantonen dat afspraken worden nageleefd. Daarbij is een combinatie van interne en externe audits nodig, afgestemd op de risicoklasse van de leverancier.
Effectieve controlemiddelen:
- Periodieke interne review van leveranciersdossiers
- Verplichte aanlevering van externe auditrapporten door leveranciers
- Technische controles, zoals vulnerability scans op shared environments
- Beoordeling van logging en monitoring binnen integratiepunten
- Validatie van responseprocessen bij incidentmeldingen
Auditresultaten moeten vervolgens leiden tot actie: bijsturing, waarschuwing of in het uiterste geval heroverweging van de samenwerking. Het is aan de CISO of verantwoordelijke informatiebeveiligingsfunctie om dit gestructureerd en zakelijk te begeleiden.
De rol van NIS2 in toezicht
De Europese NIS2-richtlijn maakt toezicht op ketenbeveiliging een wettelijke verplichting voor duizenden organisaties in Nederland. Dit geldt niet alleen voor vitale infrastructuur, maar ook voor middelgrote dienstverleners in sectoren als energie, zorg, logistiek, digitale diensten en maakindustrie.
Wat NIS2 eist van toezicht:
- Risicobeoordeling inclusief ketenafhankelijkheden
- Verantwoordingsplicht over beveiligingsmaatregelen bij derden
- Verplichte documentatie van incidenten en responscapaciteit
- Toezichtbevoegdheid van nationale toezichthouders zoals Agentschap Telecom
- Handhavingsmogelijkheden bij onvoldoende naleving, inclusief boetes
Organisaties moeten dus actief kunnen aantonen dat ze hun leveranciers hebben beoordeeld, eisen hebben gesteld én controlemechanismen hanteren. Zonder die basis ontstaat bij een incident al snel een handhavingsrisico.
Transparantie versterkt toezicht
Toezicht werkt alleen als er transparantie is. Dat betekent dat leveranciers duidelijk moeten zijn over hun beveiligingsniveau, incidenten direct melden en bereid zijn tot samenwerking. Andersom moeten organisaties open zijn over hun verwachtingen, risico’s en eisen.
Transparantie bevorderen:
- Vraag leveranciers expliciet om security roadmaps of verbeterplannen
- Deel eigen beleidskaders zodat verwachtingen helder zijn
- Wees duidelijk over meldprocedures, contactpersonen en escalatiepunten
- Bouw vertrouwen op door gezamenlijk beveiligingsdoelen te formuleren
Een cultuur van transparantie en samenwerking maakt het mogelijk om incidenten sneller te detecteren, beter te begrijpen en effectiever op te lossen — nog voordat ze uitgroeien tot grootschalige ketenbreuken.
De 5 belangrijkste takeaways
Supply chain attacks raken steeds vaker het hart van de organisatie, zonder dat daar direct technische schuld ligt bij het slachtoffer. De kwetsbaarheid zit in de onzichtbare schakels: softwarecomponenten, leveranciersprocessen en indirecte toegang tot systemen. Wie denkt dat risico’s alleen binnen de eigen IT-omgeving spelen, loopt achter de feiten aan.
1. Leveranciers zijn een verlengstuk van het eigen beveiligingsbeleid
Zodra externe partijen toegang hebben tot systemen, code of infrastructuur, vormen zij een directe factor in het eigen risicoprofiel. Ketenbeveiliging moet daarom integraal onderdeel zijn van het informatiebeveiligingsbeleid.
2. Hacking via de keten is moeilijker te detecteren dan directe aanvallen
Aanvallen verschuilen zich in legitieme software-updates, plugins of API-koppelingen. Zonder actieve monitoring en duidelijke verantwoordelijkheid blijven deze vaak maandenlang onopgemerkt.
3. NIS2 vereist aantoonbaar toezicht op ketenrisico’s
Niet alleen de interne beveiliging telt, maar ook hoe leveranciers geselecteerd, beoordeeld en gecontroleerd worden. Organisaties moeten kunnen laten zien dat zij ketenrisico’s kennen én beheersen.
4. Transparantie weegt zwaarder dan certificering alleen
ISO 27001 of NEN 7510-certificering is waardevol, maar zegt weinig zonder inzicht in hoe leveranciers omgaan met kwetsbaarheden, updates en incidenten. Vertrouwen moet gebaseerd zijn op continu inzicht, niet op eenmalige audits.
5. Incidentrespons stopt niet bij de voordeur
Een aanval op een toeleverancier kan directe impact hebben op processen, klantdata of reputatie. Voorbereid zijn betekent ook afspraken hebben met leveranciers over meldplicht, respons en herstelacties binnen de keten.
