Cyberrisicobeoordeling van producten: waarom is het merendeel van de veiligheidsanalyses schijnbaar correct, maar in de praktijk onbruikbaar?

In de overgrote meerderheid van technologiebedrijven bestaat het proces dat bekendstaat als cyberrisicobeoordeling al. Meestal heeft het de vorm van een uitgebreide tabel, een ingewikkelde matrix of een spreadsheet waarin de waarden “low”, “medium” en “high” domineren. Dit document bevat een lange lijst met generieke dreigingen, korte beschrijvingen van mogelijke kwetsbaarheden en een set standaardbeheersmaatregelen. Formeel klopt het allemaal: het document is compleet, door het bestuur ondertekend en veilig gearchiveerd.

Het probleem is dat dit document in de engineeringpraktijk helemaal niets verandert.

Het beïnvloedt de architectuur van het ontworpen apparaat niet. Het bepaalt niet hoe updates worden geleverd. Het verandert het aftersales-supportmodel niet en herijkt de relatie met leveranciers van componenten niet. Het is een document dat vanuit compliance-oogpunt klopt, maar volledig irrelevant is voor de daadwerkelijke cybersecurity van producten. Dat ligt niet aan een gebrek aan competenties in engineering- of securityteams. Het probleem is een fundamenteel verkeerd vertrekpunt.

De meeste traditionele risicoanalyses beginnen met de vraag: “Welke dreigingen kunnen optreden?”. Het nieuwe, regulatoire perspectief van de Europese Unie – duidelijk zichtbaar in regelgeving zoals de Cyber Resilience Act (CRA), medische richtlijnen (MDR) of de nieuwe machineverordening 2023/1230 – dwingt tot een totaal andere invalshoek. Die start met de vraag:

Onder welke gebruiksomstandigheden kan een product een drager van risico worden voor de gebruiker, het systeem of de markt – en is de fabrikant in staat dat risico gedurende de volledige levenscyclus te beheersen?

Dat is een fundamentele paradigmaverschuiving. Cyberrisicobeoordeling in productcontext is niet simpelweg nog een dreigingsanalyse van IT-infrastructuur. Het is ook geen penetratietest en evenmin een mechanische implementatie van de richtlijnen uit ISO 27001. Het is een diepgaande analyse van het vermogen van zowel het product als de fabrikant om veiligheid in de tijd te borgen, in een reële operationele omgeving.

Technische kwetsbaarheid versus productrisico – het onderscheid binnen cybersecurity

Om ervoor te zorgen dat een risicobeoordeling niet slechts een ambtelijke tabel blijft maar een engineeringmatig beslisinstrument wordt, moeten we twee begrippen scherp uit elkaar trekken die in de markt vaak door elkaar worden gehaald. Onthoud: een kwetsbaarheid is niet hetzelfde als productrisico.

• Technische kwetsbaarheid is een concrete, identificeerbare fout in software, hardwareconfiguratie of het ontwerp zelf. Denk aan onjuiste datavalidatie, een verouderde programmeerbibliotheek of een lek in het authenticatiemechanisme. Zulke fouten worden geregistreerd in databases zoals het CVE-systeem (Common Vulnerabilities and Exposures). Dit blijft echter een beoordeling op puur technisch niveau.
• Productrisico ontstaat pas wanneer die kwetsbaarheid (of zelfs het tijdelijke ontbreken ervan) wordt geplaatst in de harde realiteit van het gebruik.

Die context omvat een reeks variabelen: de werkomgeving (open netwerk of geïsoleerd), de manier van integratie met andere systemen, gebruikersgedrag, de beschikbaarheid van beveiligingsupdates (zogeheten patch management) en het organisatorische vermogen van de fabrikant om op incidenten te reageren.

Een product kan op de lanceringsdag geen enkele bekende kwetsbaarheid hebben en toch een kritisch risico veroorzaken als de maker geen processen heeft voor langetermijnondersteuning. Het begrijpen van dit verschil ordent het volledige engineeringwerk. Hierop is de risicogebaseerde aanpak (risk-based approach) gebaseerd. Beveiligingsmaatregelen moeten proportioneel zijn aan voorspelbare misbruikscenario’s, niet aan een abstracte lijst van internet.

De beveiligingsparadox: wanneer bescherming het risico vergroot in IT en OT

Bij het ontwerpen van cybersecurity wordt vaak aangenomen dat het toevoegen van een nieuw “slot” het risico altijd verlaagt. De praktijk laat zien dat het soms precies andersom werkt. Een maatregel die wordt ingevoerd zonder begrip van de context, creëert nieuwe aanvalsvectoren.

1. Sterke authenticatie in een industriële omgeving (OT)

Stel je voor dat je multifactorauthenticatie (MFA) invoert op een industriële machine. Vanuit IT-perspectief is dat een voorbeeldige stap, maar cybersecurity in industriële automatisering is een totaal andere realiteit. In een fabrieksomgeving draait het apparaat 24/7 en vinden service-interventies plaats onder tijdsdruk. Als het netwerk uitvalt, kan de technicus de token niet online autoriseren. De productie ligt stil. Het effect? Een gefrustreerde klant schakelt dit mechanisme permanent uit en omzeilt de beveiliging volledig. Een maatregel die moest beschermen, heeft een groot operationeel risico gecreëerd.

2. Automatische updates in medische apparaten (IoMT)

Het snel dichten van kwetsbaarheden beperkt de blootstelling aan aanvallen; in de IT-wereld is dat de norm. In de wereld van medische apparatuur kan een afgedwongen update tijdens een lopende procedure echter het gedrag van het systeem veranderen of de communicatie met het ziekenhuisnetwerk verstoren. In zo’n geval creëert technologische bescherming een kritisch klinisch en regulatoir risico (schending van de MDR-certificering).

3. Interfaces afsluiten in consumentenelektronica (IoT)

De fabrikant verwijdert lokale diagnosepoorten fysiek uit een smart-homeapparaat om hackers de toegang te bemoeilijken. In de praktijk gaan geautoriseerde servicepartijen storingen diagnosticeren via instabiele interfaces, buiten versleuteling om, en installeren gevorderde gebruikers massaal aangepaste software (custom firmware). Het resultaat is dat de fabrikant de controle over zijn eigen ecosysteem volledig verliest.

Een echte cyberrisicoanalyse stelt de vraag: “Hoe veranderen de stabiliteit, bruikbaarheid en veiligheid van het hele ecosysteem door het toevoegen van dit specifieke mechanisme?”.

5 meest voorkomende fouten in de risicoanalyse van technologische producten

Bij het beoordelen van processen in bedrijven die elektronica en software op de markt brengen, zien cybersecurity-experts terugkerende patronen.

1. Het kopiëren van het corporate IT-model naar de productwereld. Een product is geen datacenter. Het werkt in een onbekende omgeving, vaak offline, en wordt geconfigureerd door leken. IT-tools toepassen op productanalyse eindigt ermee dat cruciale problemen worden genegeerd: de levenscyclus van het apparaat en het ontbreken van afgedwongen updates.
2. Analyse van abstracte dreigingen in plaats van realistische scenario’s. Trefwoorden als “ongeautoriseerde toegang” in een tabel zetten is analytisch waardeloos. De analyse moet op concrete zaken steunen: Wie? Via welke interface? Met welk doel? Met welk effect?
3. Het negeren van de productlevenscyclus (End-of-Life). De risicoanalyse gaat meestal over het moment van lancering. Intussen neemt het risico met de tijd toe: open-sourcebibliotheken verouderen en componentleveranciers stoppen met ondersteuning. Zonder een onderhoudsmodel is de analyse onjuist.
4. Isolatie van het ontwerpteam (R&D). Risicobeoordeling behandelen als een checklist vlak voor een audit is een recept voor een ramp. De resultaten moeten terug naar de engineers als harde architectuureisen (Secure by Design).
5. Technologiefetisjisme ten koste van procedures. Bedrijven investeren een fortuin in geavanceerde cryptografie, maar weten niet wie binnen de organisatie verantwoordelijk is voor het uitbrengen van een beveiligingspatch na melding van een kwetsbaarheid door een onderzoeker (Vulnerability Disclosure Program).

Hoe voer je een analyse uit die in lijn is met de Cyber Resilience Act? 7 technische stappen

Cyberrisicobeoordeling moet ophouden een bureaucratische last te zijn. Hieronder staat een marktconform operationeel model dat aansluit op de EU-aanpak (o.a. de CRA-eisen).

1. Definieer de productgrenzen. Een product is niet alleen hardware. Het omvat ook de mobiele app, de cloud, OTA-servers en API-interfaces.
2. Beschrijf de harde realiteit van de gebruiksomgeving. Beschrijf niet de laboratoriumomgeving. Beantwoord vragen over de feitelijke internetconnectiviteit, de competenties van gebruikers en de mogelijkheden voor fysieke toegang tot het apparaat.
3. Identificeer misbruikscenario’s (Threat Modeling). Laat generieke lijsten los. Gebruik beproefde, technische methoden en tools voor risicoschatting om je te richten op precieze aanvalsvectoren die passen bij jouw sector.
4. Kwantificeer niet-financiële gevolgen. Beoordeel het risico op productiestilstand, gevaar voor de gezondheid of het niet naleven van regulatoire verplichtingen.
5. Stel de vraag naar beheersing. Kun je als fabrikant het geïdentificeerde misbruikscenario voorkomen, detecteren en er snel op reageren?
6. Ontwerp proportionele beschermingsmechanismen. Beslissingen over versleuteling of netwerksegmentatie moeten rechtstreeks voortkomen uit de antwoorden uit de vorige stappen.
7. Ontwerp het onderhoudsproces (Lifecycle). Documenteer het beleid voor het leveren van beveiligingspatches, de ondersteuningsperiode en de communicatiekanalen met de klant.

Samenvatting: Wat moet er overblijven na een degelijke risicobeoordeling?

De afronding van een correcte risicobeoordeling van de cybersecurity van een product mag nooit een tekstueel dichtgeslibd gedicht voor de auditor zijn. Uit dit werk moeten tastbare artefacten volgen: een duidelijke kaart van de systeemgrenzen, harde architectuurbeslissingen in R&D, een goedgekeurd budget voor het updatebeleid en een consistente audittrail die de naleving van EU-richtlijnen aantoont.

Een technologisch volwassen organisatie vraagt niet langer: “Zijn we 100% veilig?”. In plaats daarvan vraagt zij: “Waar zijn we precies kwetsbaar en kunnen we dat in de tijd beheersen?”.

Is jouw product klaar voor de nieuwe regelgeving?

Veiligheid is een proces, geen eenmalig certificaat. Als je niet wilt dat de risicobeoordeling in jouw bedrijf slechts “papieren rompslomp” is, loont het om proactief te handelen. Bekijk hoe je je product in de praktijk kunt voorbereiden op de Cyber Resilience Act (CRA) in de jaren 2026-2027, nog voordat de officiële geharmoniseerde normen verschijnen.