DSR ROUND TABLE

De grootste securityrisico’s zitten soms buiten je eigen infrastructuur

V.l.n.r. Vincent Thalen, Mark Kraakman, Sander Hulsman, Stef van der Ziel, Allain Silbernberg, Jeroen Meeter, Engelbert Pelster en Eric Luteijn. Bert Stam ontbreekt op deze groepsfoto.

Software supply chains, certificaten, logging, menselijke afhankelijkheden en leveranciers: tijdens een DSR Round Table bleek hoe moeilijk het is om zicht te houden op de volledige securityketen.

TEKST: Sander hulsman BEELD: eventshoot

Wie zijn security op orde wil hebben, kijkt al snel naar de eigen infrastructuur. Zijn systemen gepatcht? Staat de firewall goed ingesteld? Zijn back-ups beschikbaar? Is multifactor authentication ingevoerd? Maar tijdens een DSR Round Table over digitale resilience kwam een ongemakkelijke vraag steeds terug: hoeveel zicht heb je eigenlijk op alles wat achter je eigen infrastructuur zit?

De zeven deelnemers kwamen vanuit verschillende invalshoeken tot dezelfde conclusie: security is geen geïsoleerde technische discipline, de zwakke plek kan elders in de keten zitten.

“

Het probleem zit niet per se in de technologie zelf, maar in de manier waarop die is ingericht

Softwareketen als aanvalsvector

Vincent Thalen, CEO van Hardened, ziet dat in de praktijk regelmatig. Bij klanten die hun infrastructuur ogenschijnlijk goed hebben ingericht, blijkt bij nader onderzoek dat er verderop in de keten onverwachte afhankelijkheden zitten.

Een voorbeeld is een organisatie die haar infrastructuur vanuit een Git-omgeving aanstuurt en de code automatisch uitrolt. Op papier een moderne en efficiënte werkwijze. Maar als één ingehuurde maintainer alle noodzakelijke wijzigingen doorvoert, ontstaat een nieuw single point of failure.

“Je gaat upstream kijken en dan blijkt dat ze hun hele infrastructuur vanuit een Git-omgeving aansturen,” vertelt Thalen. “En daar zit dan één maintainer op.” Het probleem zit dan niet per se in de technologie zelf, maar in de manier waarop die technologie organisatorisch is ingericht.

Dat geldt ook voor softwarecomponenten. Een organisatie kan haar eigen applicatie zorgvuldig beveiligen, terwijl een kwetsbaarheid, wijziging of afhankelijkheid in een component verderop in de software supply chain grote gevolgen kan hebben.

Certificaat als securityrisico

Stef van der Ziel, oprichter/eigenaar van Jet-Stream, kent een ander voorbeeld, uit de wereld van live video. Daar is beschikbaarheid cruciaal, want als een uitzending uitvalt, merkt de gebruiker dat meteen. Jet-Stream past daarom redundantie en actieve load balancing toe in zijn platform.

Toch ging het een keer mis door iets dat veel minder spectaculair klinkt: een certificaat. Een software-update verstoorde het proces dat het certificaat automatisch vernieuwde. Daardoor werd het certificaat niet op tijd vernieuwd en moest midden in de nacht worden ingegrepen. “Dat zijn natuurlijk wel kritische dingen die je liever niet hebt,” zegt Van der Ziel.

Het voorbeeld laat zien hoe security en beschikbaarheid met elkaar verweven zijn. Encryptie en certificaten zijn securitymaatregelen, maar de processen eromheen kunnen tegelijkertijd een beschikbaarheidsrisico vormen.

Back-up terugzetten

Beveiligingsmaatregelen nemen is één ding, maar je mag er nooit van uitgaan dat het probleem daarmee is opgelost. Tijdens de round table kwam die gedachte meerdere keren terug. Het internet blijft een omgeving waarin anderen voortdurend kunnen proberen binnen te komen. Binnen Jet-Stream stellen engineers zich daarom voortdurend de vraag: wat als dit gebeurt? En wat als dat gebeurt? “Je zit op het open enge internet,” zegt Van der Ziel. “Dus iedereen kan proberen dingen te doen.”

“

Een concrete securityles uit de discussie: ken niet alleen je systemen, maar ook je afhankelijkheden

Jeroen Meeter, CEO van Blue Billywig, trekt die gedachte door naar herstel. Een back-up hebben is volgens hem niet voldoende. Je moet weten of je hem daadwerkelijk kunt terugzetten. “Als je het niet af en toe eens terugzet om te kijken hoe dat gaat, dan gaat het mis.”

Dat klinkt simpel, maar volgens Meeter is dit precies het verschil tussen security op papier en aantoonbare resilience. Een maatregel bestaat pas echt als je weet dat hij werkt.

Verborgen single points of failure

Bert Stam, managing director van Leaseweb Nederland, ziet hetzelfde probleem in de infrastructuur. Zijn organisatie heeft processen, runbooks en procedures voor incidenten. Toch leverde een recente brandoefening verrassende inzichten op. “Als je kijkt wat er dan gebeurt, dan zijn er best wat single points of failure,” vertelt Stam.

Bovendien zijn niet alle kwetsbaarheden zichtbaar als je alleen naar je eigen systemen kijkt. Stam spreekt over “verborgen single points of failure” die zich door de hele keten kunnen bevinden.

De kern is volgens hem dat organisaties vaak aannames maken. Ze gaan ervan uit dat een leverancier wel iets geregeld zal hebben, dat een proces werkt zoals gedacht of dat iemand bereikbaar zal zijn als dat nodig is. “Je weet gewoon niet wie wat waar doet en hoe het werkt,” zegt Stam. “Je maakt aannames.” Een concrete securityles uit de discussie: ken niet alleen je systemen, maar ook je afhankelijkheden.

Mensen als single point of failure

Technische redundantie lost bovendien niet alles op. Tijdens het gesprek kwam een voorbeeld voorbij van kennis die bij het vertrek van een medewerker verloren dreigde te gaan. Alles was volgens de organisatie gedocumenteerd, maar in de praktijk bleek dat niet volledig het geval. Daarmee ontstaat een securityvraagstuk dat zelden als zodanig wordt benoemd. Hoeveel van je securitykennis zit eigenlijk in het hoofd van één persoon?

“

Als een leverancier zijn dienstverlening verandert, kan dat  de continuïteit van de eigen organisatie raken

Ook bij Escrow4all komt dat probleem aan de orde. Marketingmanager Allain Silbernberg ziet bij organisaties en technologiepartners regelmatig single points of failure ontstaan rond mensen en bereikbaarheid. Escrow kan een deel daarvan contractueel opvangen. “Er zijn afspraken over. In de contracten staan de regels.”

Wanneer een afgesproken trigger optreedt en een partij niet meer reageert, kan het vastgelegde proces worden gestart om software of data beschikbaar te maken. Het is daarmee geen technische beveiligingsmaatregel, maar wel een manier om een afhankelijkheid beheersbaar te maken.

Leveranciersafhankelijkheid

Ook de keuze van leveranciers kan een securityvraagstuk worden. Mark Kraakman, co-founder van AhaSend, ziet dat organisaties voor veel digitale diensten afhankelijk zijn van grote Amerikaanse technologiebedrijven. Zijn eigen bedrijf probeert daar een Europees alternatief tegenover te zetten. “Koop bij je buurman. Koop dichter bij huis. Wees meer zelfstandig,” zegt Kraakman.

Dat gaat in zijn ogen niet alleen over geopolitiek. Afhankelijkheid van één technologieplatform kan ook operationele gevolgen hebben. Als een leverancier zijn voorwaarden, prijzen of dienstverlening verandert, kan dat uiteindelijk de continuïteit van de eigen organisatie raken.

“

Security betekent niet dat er niets misgaat, maar dat je weet wat je doet als het toch gebeurt

Engelbert Pelster, strategic growth executive & ecosystem lead bij DXC Technology, benadrukt vanuit een ander perspectief dat je het ecosysteem als geheel moet bekijken. “Uiteindelijk gaat het natuurlijk om partners,” zegt hij. “Op het moment dat je daar de zwakste schakel aan het identificeren bent, is het goed om te weten waar die is.” Een contractuele relatie alleen is volgens hem niet genoeg.

Logging

Ook bij incident response speelt dit. Tijdens de round table werd een incident besproken waarbij na een inbraak de logging van het betreffende apparaat al na twaalf uur werd overschreven. De securityles is duidelijk, want detectie zonder voldoende logretentie beperkt je vermogen om een incident achteraf te onderzoeken. Daarmee wordt logging onderdeel van dezelfde keten als preventie, detectie, response en recovery.

Weten wat te doen

De voorbeelden hebben iets gemeen. Een certificaat kan breken. Een maintainer kan vertrekken. Een leverancier kan uitvallen. Een softwarecomponent kan veranderen. Een back-up kan onbruikbaar blijken. Een logbestand kan te snel verdwijnen. Geen van die situaties hoeft op zichzelf een spectaculaire cyberaanval te zijn. Toch kunnen ze allemaal de beschikbaarheid, vertrouwelijkheid of integriteit van digitale dienstverlening aantasten. De vraag is dus niet alleen hoe goed je organisatie is beveiligd, maar vooral waarvan je afhankelijk bent, waar de single points of failure zitten en wat er gebeurt als een aanname niet klopt. Tooling alleen is niet genoeg. Je hebt inzicht nodig in de hele keten, geteste maatregelen, goede documentatie, duidelijke afspraken met leveranciers en vooral de bereidheid om regelmatig de ongemakkelijke vraag te stellen: wat als het toch misgaat? Security betekent niet dat er niets misgaat, maar dat je weet wat je doet als het toch gebeurt. 

Deelnemers

Aan de DSR Round Table met als thema ‘Hoe bouwen we resilience bij cyber-, energie- en geopolitieke verstoringen?’ (16 september 2026, brasserie Monsees, ’s-Graveland) deden mee:

Vincent Thalen, CEO Hardened

Stef van der Ziel, eigenaar van Jet-Stream

Jeroen Meeter, CEO van Blue Billywig

Bert Stam, managing director Leaseweb Nederland

Allain Silbernberg, Marketingmanager  Escrow4all

Mark Kraakman, co-founder AhaSend

Engelbert Pelster, strategic growth executive & ecosystem lead  DXC Technology