Supply chain attacks. Breached through someone we trust. Supply chain-aanvallen. Gehackt via iemand die we vertrouwen.

We tell staff to install updates promptly, and rightly so. But an update is code we run with full privileges, on the vendor's word alone. When an attacker gets inside the vendor's build process, the poisoned version is signed with the vendor's real certificate, delivered through the real update channel and installed by our own systems on schedule. Nothing we own was attacked. We invited it in.

Business impact: one compromised vendor reaches every customer at once, so we become collateral in someone else's breach — yet the clean-up, the downtime and the notifications are ours. The tools most likely to be abused are the ones with the deepest access: monitoring, remote management, backup, security software.

We zeggen tegen medewerkers dat ze updates snel moeten installeren, en terecht. Maar een update is code die we met volledige rechten draaien, alleen op het woord van de leverancier. Als een aanvaller binnenkomt in het bouwproces van die leverancier, wordt de besmette versie ondertekend met het echte certificaat, geleverd via het echte updatekanaal en op schema geïnstalleerd door onze eigen systemen. Niets van ons is aangevallen. We hebben het zelf binnengelaten.

Bedrijfsimpact: één gecompromitteerde leverancier raakt al zijn klanten tegelijk, waardoor wij bijvangst worden in het datalek van een ander — maar het opruimen, de stilstand en de meldingen zijn voor ons. De software die het vaakst wordt misbruikt, is juist die met de diepste toegang: monitoring, beheer op afstand, back-up, beveiligingssoftware.

Our IT partner, our payroll provider, the firm that maintains the building systems — each holds a standing login into our environment. Often it is one shared account, used by a rotating team, valid around the clock, with more rights than the job needs. Attackers know this. Breaking into one supplier hands them the front-door keys of dozens of companies, and every login looks like routine maintenance.

Business impact: we cannot see how that supplier protects our key, and we rarely ask. When it is stolen, the intruder arrives with administrator rights, no alarm, and a perfect excuse in the logs. Every supplier login is an employee we never interviewed.

Onze IT-partner, onze salarisverwerker, het bedrijf dat de gebouwinstallaties onderhoudt — elk heeft een permanente inlog in onze omgeving. Vaak is het één gedeeld account, gebruikt door een wisselend team, dag en nacht geldig, met meer rechten dan het werk vereist. Aanvallers weten dat. Inbreken bij één leverancier levert ze de voordeursleutels van tientallen bedrijven op, en elke inlog lijkt op routineonderhoud.

Bedrijfsimpact: we kunnen niet zien hoe die leverancier onze sleutel beschermt, en we vragen het zelden. Wordt hij gestolen, dan komt de indringer binnen met beheerdersrechten, zonder alarm en met een perfect excuus in de logboeken. Elke leveranciersinlog is een medewerker die we nooit hebben gesproken.

Modern software is assembled, not written. Our customer portal, our app, our internal tools: each is a thin layer of our own code on top of hundreds of open-source components, written and maintained by people we have never met. When one of those maintainers is tricked, bought or simply hands the project to a stranger, the next version can carry code that steals whatever our application touches. Our developers pull it in with a routine build.

Business impact: the malicious code runs inside our product, under our name, with access to our customers' data. Contractually and legally it is our breach. And if we cannot list which components are inside our software, we cannot answer the first question a regulator or customer will ask: “are you affected?”

Moderne software wordt samengesteld, niet geschreven. Ons klantportaal, onze app, onze interne tools: elk is een dun laagje eigen code bovenop honderden open-sourcecomponenten, geschreven en onderhouden door mensen die we nooit hebben ontmoet. Wordt zo'n beheerder misleid, omgekocht of geeft hij het project simpelweg aan een vreemde, dan kan de volgende versie code bevatten die steelt wat onze applicatie aanraakt. Onze ontwikkelaars halen die binnen met een routinematige build.

Bedrijfsimpact: de kwaadaardige code draait in ons product, onder onze naam, met toegang tot de gegevens van onze klanten. Contractueel en juridisch is het ons datalek. En als we niet kunnen opsommen welke componenten in onze software zitten, kunnen we de eerste vraag van een toezichthouder of klant niet beantwoorden: “zijn jullie getroffen?”

Our HR records live with a payroll service. Our customer list lives in a marketing tool. Our contracts live in an e-signing platform. Each of those vendors runs on other vendors in turn. When any of them is breached, our data is exposed without a single packet touching our network — and we may only learn about it from the news, or from a customer.

Business impact: under GDPR we remain the controller. The 72-hour notification clock, the regulator and the customer communication are ours, regardless of whose servers leaked. The practical questions are simple and usually unanswered: which vendors hold what data, how fast are they obliged to tell us, and how do we get our data back if we walk away?

Onze personeelsdossiers staan bij een salarisdienst. Onze klantenlijst staat in een marketingtool. Onze contracten staan op een platform voor digitaal ondertekenen. Elk van die leveranciers draait op zijn beurt weer op andere leveranciers. Wordt een van hen gehackt, dan liggen onze gegevens op straat zonder dat één pakketje ons netwerk heeft aangeraakt — en soms horen we het pas via het nieuws, of van een klant.

Bedrijfsimpact: onder de AVG blijven wij de verwerkingsverantwoordelijke. De 72-uursmelding, de toezichthouder en de communicatie naar klanten zijn voor ons, ongeacht wiens servers lekten. De praktische vragen zijn simpel en meestal onbeantwoord: welke leveranciers hebben welke gegevens, hoe snel moeten ze ons informeren, en hoe krijgen we onze gegevens terug als we weglopen?