Je weerbaarheid hangt af van een leverancier die je niet beheerst

De meeste continuïteitsplannen gaan over wat er in je eigen omgeving misgaat: een server die uitvalt, ransomware, een datacenter zonder stroom. Dat is nuttig, en het is niet waar het de laatste jaren het vaakst misgaat.

Steeds vaker ligt een organisatie stil doordat er ergens anders iets gebeurde. Bij een softwareleverancier, een logistieke partner, een clouddienst, een onderhoudsbedrijf. Er komt niemand jouw netwerk binnen. Er hoeft bij jou niets besmet te raken. En toch staat de lijn stil.

Dat is geen netwerkvraag. Dat is een continuïteitsvraag, en hij hoort thuis bij iemand die kan besluiten.

Zes soorten afhankelijkheid, en ze vragen om verschillende maatregelen

“Leveranciersrisico” is één woord voor heel verschillende dingen. Het loont om ze uit elkaar te trekken, want de maatregel verschilt per soort.

• Support op afstand. Een storing die je zelf niet kunt verhelpen, en de engineer die dat wel kan zit bij een partij die er even niet is.
• Licentieserver. Software die periodiek valideert en stopt als er geen antwoord komt. Dit is de stilste van de zes: alles doet het, tot het opeens niet meer doet.
• Reserveonderdelen. Eén leverancier, levertijd in weken, en een onderdeel dat je niet ergens anders koopt.
• Datastroom. Prijzen, planning, metingen of certificaten die van buiten komen en waar een proces op wacht.
• Documentatie. De actuele tekeningen en configuratie staan bij hen, niet bij jou. Zonder die informatie is herstellen gokken.
• Specialistische kennis. Twee mensen ter wereld kennen dit systeem echt, en ze werken allebei daar.

De laatste twee worden bijna nooit als leveranciersrisico geteld, en ze zijn in de praktijk het lastigst op te lossen. Een onderdeel kun je op voorraad leggen. Kennis niet.

De vraag die het concreet maakt

Niet “hoe veilig is deze leverancier”, want dat weet je toch niet en het is niet de vraag die je kunt beantwoorden. Wel:

Hoe lang kunnen we door als deze partij er morgen niet is, en wat doen we dan?

Die vraag dwingt tot een getal, en een getal dwingt tot een besluit. Twee uur is een ander gesprek dan twee weken. Als niemand het getal kent, is dat je eerste bevinding.

Wat je per leverancier wilt vastleggen

Dertien punten, en ze passen op één pagina. Het gaat niet om volledigheid maar om de punten die het besluit veranderen:

1. leverancier en de contactpersoon die je 's nachts kunt bereiken;
2. component of dienst die zij leveren;
3. kritiek proces dat daarvan afhangt;
4. toegang op afstand: hebben zij een pad naar binnen, en welk;
5. data-afhankelijkheid: welke stroom komt van hen;
6. tolerabele onderbreking: hoe lang kun je door;
7. alternatieven: is er een tweede partij, en is dat ooit getest;
8. voorraad: heb je onderdelen liggen, en voor hoe lang;
9. documentatie: heb jij de actuele versie, of alleen zij;
10. kennisafhankelijkheid: kun je het zonder hun mensen;
11. terugvalscenario: wat doe je concreet, vandaag, zonder hen;
12. noodcontact: hoe bereik je hen buiten kantooruren;
13. eigenaar: wie draagt dit risico, met naam.

Begin niet met alle leveranciers. Begin met de vijf waarvan je vermoedt dat het misgaat als ze wegvallen. Meestal blijkt er één bij te zitten waar niemand ooit over heeft nagedacht.

Wat NIS2 hier wel en niet over zegt

NIS2 noemt in artikel 21 de beveiliging van de toeleveringsketen expliciet als onderdeel van de maatregelen die een organisatie moet nemen, samen met bedrijfscontinuïteit en crisisbeheer. In Nederland is dat uitgewerkt in de Cyberbeveiligingswet.

Wat er niet staat, en wat je dus ook niet moet beweren:

• Er staat geen methode voorgeschreven. Deze lijst is een werkwijze van CyberBusters en geen wettelijke eis.
• Het geldt niet voor elke organisatie. Of je onder NIS2 of de Cyberbeveiligingswet valt hangt af van sector en omvang, en dat is een juridische beoordeling.
• Het gaat niet alleen om de beveiliging van je leverancier, maar ook om jouw afhankelijkheid van hem. Dat tweede wordt vaak overgeslagen omdat het minder op een securityvraag lijkt.

Voor de continuïteitskant is ISO 22301 het gangbare kader. Dat is geen vereiste onder NIS2, maar het geeft wel de begrippen waarmee je dit gesprek gestructureerd voert.

Dezelfde vraag bij een PLC-leverancier, een SaaS-partij en een AI-model

Dit is waar het interessant wordt, en waarom dit artikel niet alleen over NIS2 gaat.

Een leverancier van besturingssystemen, een SaaS-aanbieder en de partij achter je AI-model lijken drie verschillende gesprekken. De vragen zijn identiek: waar hangen we van af, wat kunnen zij bij ons, wat kan er bij hen veranderen zonder dat wij het merken, wat gebeurt er als ze er niet zijn, wie draagt die afhankelijkheid, en waar staat dat opgeschreven.

Bij een AI-model komt daar één ding bij dat bij een PLC niet speelt: het kan veranderen zonder dat jij iets doet. Een modelversie wordt bijgewerkt, het gedrag schuift, en jouw proces krijgt andere uitkomsten dan vorige week. Dat is geen storing en het valt niet op in een monitoringdashboard.

Dat is hetzelfde patroon als bij een besluit over een kwetsbaarheid en bij toezicht op een AI-toepassing. Waarom die drie dezelfde vraag zijn, staat in het besluitpatroon achter OT, AI en NIS2.

Veelgestelde vragen

Is dit niet gewoon business continuity management?

Voor een groot deel wel, en dat is precies het punt. Wat er in de praktijk misgaat is dat leveranciersrisico bij security ligt en continuïteit bij een andere afdeling, waardoor de vraag “hoe lang kunnen we door zonder hen” nergens wordt gesteld. Het onderwerp is niet nieuw; de plek waar het valt wel.

Moeten we dit voor al onze leveranciers doen?

Nee. Begin bij de leveranciers waar een kritiek proces van afhangt, en dat zijn er meestal minder dan tien. Een lijst van tweehonderd ingevulde formulieren is geen beheersing maar administratie.

Wat als een leverancier geen informatie wil geven?

Dan is dat zelf een bevinding, en een bruikbare. Je hoeft niet te weten hoe hun beveiliging in elkaar zit om te bepalen hoe lang jij zonder hen kunt. Dat tweede kun je zelf uitzoeken en het bepaalt je maatregel.

Telt een clouddienst als leverancier?

Ja, en meestal als een van de belangrijkste. De vraag verandert niet: welk proces hangt eraan, hoe lang kun je zonder, wat is het alternatief, en wie draagt dat. Dat de dienst zelden uitvalt maakt de vraag niet minder relevant; het maakt het antwoord alleen minder geoefend.

Wat is een redelijke tolerabele onderbreking?

Die bepaal je niet met een norm maar met het proces. Vraag wat er gebeurt na een uur, na een dag, na een week: wanneer levert het schade op die je niet meer inhaalt. Dat moment is je grens, en die verschilt per proces binnen dezelfde organisatie.

Toont een ingevulde sheet aan dat we aan NIS2 voldoen?

Nee. Hij helpt je het gesprek voeren en het besluit vastleggen, en dat maakt aantonen makkelijker. Maar conformiteit toon je aan tegen de eisen zoals ze op jouw organisatie van toepassing zijn, met bewijs dat een toezichthouder beoordeelt.

Verder lezen

• EUR-Lex: Richtlijn (EU) 2022/2555 (NIS2)
• NCSC: Nationaal Cyber Security Centrum
• ISO: ISO 22301: Business continuity management systems
• CyberBusters: het besluitpatroon achter OT, AI en NIS2
• CyberBusters: OT vulnerability management is geen IT patch management
• CyberBusters: menselijk toezicht is een maatregel, geen leus

Wil je dit met je eigen team scherp krijgen, dan gaat de PECB NIS 2 Lead Implementer-opleiding in op de maatregelen waar dit onder valt.