Europa streeft naar digitale soevereiniteit in 2035. Dat is goed, maar laten we die ambitie gebruiken om ook iets fundamentelers aan te pakken: de manier waarop we omgaan met cyberbeveiliging. Want die houdt geen stand.
Auto’s verongelukken. Daarom hebben we airbags. Schepen zinken. Daarom hebben we waterdichte schotten. Gebouwen branden af. Daarom hebben we brandmuren. Al die noodvoorzieningen zijn automatisch, getest en gecertificeerd. De airbag wacht niet op een managementvergadering. De branddeur gaat dicht zodra de rookmelder afgaat. In de ICT kennen we dit fenomeen echter niet.
Bij sommige organisaties bestaan noodplannen, maar ze liggen doorgaans in een kast. Een handvol organisaties in Nederland test ze regelmatig, en dan vaak nog onder toezicht van een intern team. De slager keurt zijn eigen vlees. Wat we niet hebben, zijn noodplannen die zichzelf activeren: automatisch, zonder menselijke beslissing, getest en gecertificeerd zoals een airbag. Dat verschil tussen automatisch en handmatig, en getest versus aangenomen, is de kern van het probleem.
De paradox van beveiligingssoftware
De gangbare aanpak in cybersecurity is software inzetten om softwareproblemen op te lossen: firewalls, zero-trust oplossingen, endpoint security. Dat doen we al meer dan twintig jaar, en de problemen worden groter, niet kleiner. Waarom? Omdat de software die ons moet beschermen zelf ook kwetsbaarheden bevat.
Zero-day exploits zijn geen randverschijnsel meer, maar ze zijn structureel. Commerciële fabrikanten bouwen hun producten op een fundament van open-sourcecomponenten, onder druk van aandeelhouders die snelle marktintroductie willen. De opensource-community is toegankelijk voor iedereen, ook voor wie er bewust een achterdeur in wil bouwen. Het is verre van eenvoudig om die achterdeur te vinden en te verwijderen tijdens de productontwikkeling.
Daar komt nog iets anders bij. Meerdere landen eisen van cybersecurityfabrikanten op hun grondgebied dat er een verborgen toegangspoort beschikbaar is voor de overheid. Honderd procent zekerheid dat een beveiligingsproduct vrij is van dergelijke achterdeuren bestaat simpelweg niet.
De EU Cyber Resilience Act is een stap in de goede richting: hij dwingt transparantie af over kwetsbaarheden. Maar het onderliggende probleem lost hij niet op. We maken steeds zichtbaarder hoe lek de emmer is, zonder de emmer te vervangen omdat we er impliciet op vertrouwen dat de emmer doet wat hij hoort te doen. Professor Dr. Marieke Huisman van de Universiteit Twente legt in haar recente publicaties precies uit waarom Software Reliability zo moeilijk is.
Als klant word je intussen steeds meer gedwongen om zelf te pentesten, zero-days te zoeken, en kwaliteitscontrole te doen op het product dat je hebt aangeschaft. De fabrikant levert een zwak product; de klant krijgt de rol van kwaliteitscontroleur en betaalt daarvoor zelf.
Patchen als verdienmodel
Vroeger gold een patchcyclus van drie tot zes maanden als industriestandaard. Nu updaten sommige fabrikanten hun klanten dagelijks. Dat klinkt als toewijding aan kwaliteit. De realiteit is een andere: het is een stille erkenning dat producten structureel onvoldoende zijn zonder dagelijkse reparatie.
En het heeft een interessante bijwerking. Aan de kant van integrators en serviceproviders is patching een aanzienlijk verdienmodel geworden. Volledig geautomatiseerd patchen wordt soms actief vertraagd, want handmatig werk genereert factureerbare uren. Twee FTE voor patchbeheer à 45.000 euro per maand is eenvoudiger uit te leggen aan een budgethouder dan een geautomatiseerde dienst voor 20.000 euro per maand die het beter en sneller doet. Het uurtje-factuurtje-model wint van de efficiëntie.
Kortom: de klant betaalt twee keer; voor het kwetsbare product, en voor het continu repareren ervan. Dit dreigt neer te komen op een perpetuum mobile: ontdekken, patchen, testen, opnieuw beginnen; 24/7, dus structureel onuitvoerbaar.
De echte vraag
De EU zet terecht in op digitale soevereiniteit. Maar als die transitie alleen gaat over het vervangen van Amerikaanse cloudproviders door Europese, lossen we het architectuurprobleem niet op.
De echte vraag is niet: welke software vertrouwen we? De vraag is: hoe ontwerpen we systemen die blijven functioneren als die software tekortschiet? In de twee volgende delen die online verschijnen op InfoSecurityMagazine.nl ga ik in op wat dat concreet betekent. Qua architectuur, organisatie, en de rol van het Security Operations Centre.
Wim Horseling is Sales Director Europa bij Goldilock. Je komt met hem in contact via wimhorseling@goldilock.com of bel 0653 870 105.
(dit artikel verscheen eerder in het e-Magazine)
