Home Magazine

De Cyber Resilience Act: Hardware hacking en product security

28 november, 2024
De Cyber Resilience Act: Hardware hacking en product security voor producten in industriële omgevingen
Dit artikel verkent de implicaties van de Cyber Resilience Act voor netwerk verbonden industriële producten en onderzoekt of het voldoen aan de CRA door middel van de IEC-standaard ook de meest recente hardware-aanvallen zou mitigeren, en schetst een aantal strategische dilemma’s. 
Inleiding
Auteur: ir. Jeroen Slobbe MBA

De NIS2-richtlijn beoogt de cyberweerbaarheid van essentiële diensten te verbeteren [DIGI24]. Door het introduceren van managementverantwoordelijkheid, risico-assessments, een zorgplicht en een meldplicht, worden grote stappen gezet om cyberrisico's terug te dwingen. Tegelijkertijd zal ook een aanzienlijke beweging in de keten noodzakelijk zijn om de cybersecurity van onze infrastructuur te versterken, om de kwetsbaarheden aan de ‘voorkant’ te verminderen. Een deel van de essentiële diensten maakt gebruik van Operationele Technologie (OT). OT-systemen zijn systemen die onder andere kritieke processen beheersen. Denk hierbij aan een Programmable Logic Controller (PLC) die de motor van een brug of pomp aanstuurt, de slimme sensor die de druk op een pijpleiding meet, of de Human Machine Interface (HMI) waarmee de snelheid van een lopende band kan worden bediend.

De NIS2 bevat een zorgplicht voor essentiële dienstverleners, waardoor deze een risicobeoordeling moeten uitvoeren en passende maatregelen moeten nemen. Om ervoor te zorgen dat ook de beveiliging van netwerk verbonden producten die op de Europese markt worden verkocht, wordt verbeterd, is de Cyber Resilience Act (CRA) geïntroduceerd [EC23]. Deze wet is breed, heeft verschillende categorieën en geldt voor zowel software (browsers, besturingssystemen, etc.) als hardware (routers, switches, etc.) [CH22].

Dit artikel verkent de implicaties van de CRA voor netwerk verbonden industriële producten, onderzoekt of het voldoen aan de CRA door middel van de IEC standaard ook de meest recente hardware-aanvallen zou mitigeren, en schetst een aantal strategische dilemma’s die internal auditors, OT-security officers, CISOs, product owners en engineers kunnen gebruiken om diepgang te geven aan product security controles.

Wat houdt de Cyber Resilience Act in?
Met 517 stemmen voor en 12 stemmen tegen heeft het Europese parlement ingestemd met de Cyber Resilience Act [EUN24] en op 10 oktober 2024, heeft ook de Europese Raad de nieuwe wet goedgekeurd [EC24]. De CRA [ELE22] heeft twee hoofddoelstellingen:
  •  voorwaarden scheppen voor de ontwikkeling van veilige producten met digitale elementen zo dat hardware- en softwareproducten met minder kwetsbaarheden op de markt worden gebracht. Tevens wil de CRA ervoor zorgen dat fabrikanten veiligheid gedurende de hele levenscyclus van een product borgen;
  • Voorwaarden creëren waardoor gebruikers rekening kunnen houden met cybersecurity bij het selecteren en gebruiken van producten met digitale elementen.
Daarnaast zijn er vier specifieke doelstellingen gedefinieerd:
  • Veilige levenscyclus: borgen dat fabrikanten de veiligheid van producten met digitale elementen borgen vanaf de ontwerp- en ontwikkelingsfase en gedurende de hele levenscyclus;
  • Cybersecuritynormen: zorgen voor een coherent cybersecuritykader, zodat naleving voor hardware- en softwareproducenten wordt vergemakkelijkt;
  • Transparantie: de transparantie van beveiligingseigenschappen van producten met digitale elementen verbeteren;
  • Consumer enablement: bedrijven en consumenten in staat stellen producten met digitale elementen veilig te gebruiken.
Deze doelstellingen worden vervolgend concreet gemaakt met een aantal belangrijke eisen:
  • Essentiele security eisen: onder deze eisen vallen onder meer het risico-gebaseerd ontwerpen, ontwikkelen en produceren van producten (procesgericht, bij de maker) die vrij moeten zijn van exploiteerbare kwetsbaarheden met minimalisering van het aanvalsoppervlak (productgericht), geleverd met configuraties die standaard veilig is (productgericht, bij de leverancier!), en de gebruikelijke toegangscontroles, versleuteling etc. mogelijk maken (procesgericht, bij de klant).
  • Vulnerability management: het inrichten van de juiste vulnerability dislosure-processen (inclusief een meldplicht richting de overheid en klanten), het zonder extra kosten leveren van security patches, het bijhouden van een software-bill of materials (SBOM) (een gedetailleerde lijst met alle onderdelen, versienummers en componenten waaruit de hardware c.q. software is opgebouwd) en het actief monitoren op en patchen van later ontdekte kwetsbaarheden.
  • Update verplichting: het op een veilige manier en zonder vertraging beschikbaarstelling van security updates voor een periode van tenminste 5 jaar, of langer als de levensduur van het product langer is.
  • Documentatie- & risicomanagementplicht: onder deze verplichting worden verschillende vormen van documentatie vereist, zo wordt het noodzakelijk om instructies voor veilig gebruik voor de eindgebruiker te documenteren, moet er technische documentatie voor de toezichthouders voorhanden zijn, is het noodzakelijk om documentatie aan te maken voor de conformiteitsverklaringen en moet een uitgebreide risico assessment gedocumenteerd worden.
  • Conformiteitsverklaring: Afhankelijk van het belang en risico van het product, mogen organisaties steunen op het interne beheersingssysteem voor het aantoonbaar naleven van de conformiteit, of (in het strengste geval) moet het product een audit ondergaan door een externe gekwalificeerde partij.
 Standaarden voor industriële producten en hun productieprocessen
Het is belangrijk onderscheid te maken tussen eisen die aan het product gesteld worden, en de eisen die gesteld worden ten aanzien van processen en documentatie aan de kant van de producent.

ENISA [ENISA24] heeft een vergelijking gemaakt van verschillende product security ontwikkelstandaarden: ISO 27002:2022, 27005:2022, IEC 62443-3-2:2020, IEC 62443-4-1:2018, ETSI EN 303 645 v2.1.1 (2020-06). Voor elk standaard werden gaps geïdentificeerd, variërend van: het niet adressen van security architectuur tot het ontbreken van concrete maatregelen of gebonden zijn aan een type systeem. Alhoewel alle standaarden nuttige en gedeeltelijk de eisen van de CRA afdekten, concludeerde ENISA dat geen van de standaarden alle eisen van de CRA afdekte. Door meerdere standaarden te combineren, kunnen uiteindelijk wel alle eisen uit de CRA worden afgedekt. ENISA concludeert dat de ETSI EN 303 645 [ETSI2020] de meest complete standaard is rondom de product security requirements uit de CRA Annex 1. Daarnaast wordt de IEC 62443 als goed beoordeeld, met de voetnoot dat deze speciaal voor industriële automatisering is ontwikkeld.

Een mooie toevoeging aan de ENISA-mapping zou de IEC 62443 3-3 zijn. De IEC 62443-3-3 onderscheid vier Security Levels (SL 1 tot SL 4) met in totaal 100 requirements voor producten. De SL-definitie is gebaseerd op de motivatie, competentie en middelen van de aanvaller. Daarmee leent de 3-3 SL definitie zich goed om in workshops mogelijke top-level events, aanvalspaden en dreigingsactoren te verkennen en vervolg heel concreet af te sluiten met een geschikte set aan eisen die geïmplementeerd moeten worden. Een besluit van een bevoegde EU-brede instantie over welk SL-level als ondergrens geldt voor de CRA-eisen aan producten zou nuttig zijn. Ook een meer gedifferentieerd besluit dat een SL-level als ondergrens geldt, categorisch of voor gespecificeerde productcategorieën of -toepassingen, mits er nog aan een aantal extra requirements (bijvoorbeeld de eis dat producten een resetfunctie moeten hebben die het product naar de originele staat terugbrengen) zou van waarde zijn.
Begin bij het begin: Risicobeoordelingen
Een stap terug! Om de risico assessment op een product goed uit te kunnen voeren is het belangrijk om – naast zicht op de context en intended use – systematisch het aanvalsoppervlak te verkennen. MITRE heeft begin dit jaar een dreigingsmodel voor (embedded) devices gepubliceerd: EMB3D [ME24]. Dit model en de bijgevoegde paper [AHJCDK24] beschrijven een systematisch proces om:
  1. De eigenschappen en het aanvalsoppervlak van een ‘device’ (apparaat of systeemonderdeel) in kaart te brengen;
  2. Deze eigenschappen (in de categorieën hardware, software, applicaties en netwerken) te mappen naar een specifieke database met bekende bedreigingen;
  3. Deze dreigingen te koppelen aan specifieke kwetsbaarheid- en zwakheid- informatie van het device;
  4. Deze informatie te gebruiken om het risico te bepalen en compenserende maatregelen te (kunnen) nemen.
De combinatie van de IEC 62443-3-3 SL-requirements, met extra maatregelen op basis van de EMB3D dreigingen, geeft organisaties traceerbaarheid en verdedigbaarheid (wat we implementeren komt uit een internationaal erkend standaard) en flexibiliteit (om bijvoorbeeld hardware specifieke cyberrisico’s te mitigeren). Vanuit een compliance perspectief blijft het van belang dat alle eisen uit de CRA geïmplementeerd worden en dus dat het product vrij is van exploiteerbare kwetsbaarheden. Hiermee dient dus een redelijkerwijs maximale vermindering van de risico’s te worden nagestreefd. Dit verandert niets aan het feit dat er altijd een restrisico blijft door nieuwe ontwikkelingen (zie de volgende sectie), en dat de CRA in Annex I benadrukt dat het beveiligingsniveau van een product passend moet zijn bij het risico dat het apparaat met zich meebrengt.

Naast product specifieke eisen, zijn er ook normen voor het productieproces van apparatuur en software. De IEC 62443 heeft hier een specifieke ‘body’ (onderdeel) voor: de 4-1. De IEC 62443-4-1 bestaat uit 47 requirements verdeeld over 8 practises. Deze requirements voorzien in zaken als het trainen van ontwikkelaars, requirement engineering en -verificatie, security testing, secure-by-design principles, hardening-richtlijnen en nog zaken die het ontwikkelproces versterken ten aanzien van realiseerbare security in de op te leveren producten.
Beyond compliance: geavanceerde hardware-aanvallen op producten
Als we al deze standaarden geheel implementeren, zijn we dan veilig? Binnen product security is, veel meer dan bij reguliere IT-inzet, de context van het productgebruik belangrijk. Waar het voor een server soms nog een redelijke aanname is dat de fysieke beveiliging goed geregeld is, zie je bij laadpalen, zonnepanelen en consumenten elektronica dat deze toegankelijk zijn vanuit de publieke ruimte. Dit betekent dat een aanvaller soms dichtbij kan komen en in sommige gevallen maandenlang onbelemmerd fysieke toegang kan hebben tot het apparaat. Wat is hiervan de consequentie? Aanvallen die vroeger als onwaarschijnlijk werden afgedaan, of ‘gemitigeerd door fysieke maatregelen’, kunnen nu zwaarder gaan wegen in de risico-assessments.
 
Daarnaast is er nog een andere trend gaande. Tien jaar geleden was apparatuur om geavanceerde hardware- en radioaanvallen mee uit te voeren duur en daarmee voor hobbyhackers niet toegankelijk. Inmiddels zien we dat apparatuur om radioaanvallen of hardware aanvallen mee te kunnen uit te voeren, betaalbaar is geworden. Zo betaal je tussen de €165 en €280 voor de HackRF of FlipperZero (gericht op o.a. radioaanvallen), of $250 voor de randapparatuur om clock glitching- of voltage-glitching aanvallen mee uit te voeren [CW24]. Onderzoek van afgelopen zomer laat zelfs zien dat laser-based fault injection op termijn betaalbaar kan worden [SBLT2024].

Leuk voor de hobbyhacker, maar wat is de impact van een hardware hacker die, om wat te noemen, de EEPROM dumpt of zich toegang verschaft tot het apparaat via een hardware debugging poort [COFJW21]? Een apparaat moet toch ergens zijn applicaties en stuurprogramma’s kwijt (in de zogenaamde firmware). Een aanvaller met toegang tot het geheugen kan een firmware-image uit het apparaat peuteren en vervolgens op zoek gaan naar geheimen. Potentiële impacts voor de organisatie kunnen dan zijn:
  • Toegang tot (hardcoded) keys die gebruikt kunnen worden om de hele batch aan apparatuur over te nemen;
  • Toegang tot achterliggende beheernetwerken (wat zeker in het geval van de kritieke infrastructuur vergaande gevolgen kan hebben);
  • Toegang tot intellectueel eigendom dat in het apparaat zit (een specifiek algoritme);
  • Of de mogelijkheid de firmware te manipuleren om die op een later moment te misbruiken.
Genoeg reden dus om hardware-aanvallen mee te wegen in de product-securityrisico-analyses die conform CRA-vereisten verplicht moeten worden gedaan. Maar als we inzoomen op de standaard is de vraag of deze nieuwe aanvallen goed geborgd worden. De IEC 62443-4-2: Technical security requirements for IACS-components, adresseert hardware security met één requirement: “Use of physical diagnostics and test interfaces”, waarin specifiek aandacht wordt gevraagd voor het afschermen van hardware debug poorten: “Embedded devices shall protect against unauthorized use of the physical factory diagnostic and test interfaces (e.g. JTAG debugging)”. De andere nieuwe aanvallen, zoals fault-injection, glock glitching of voltage glitching worden niet in deze standaard geadresseerd. Terwijl er recentelijk wel een toename is van onderzoekers die dit type aanvallen rapporteren, specifiek voor OT componenten [CISA23, CISA22, CISA20].

Om de vraag te beantwoorden: als we al deze standaarden geheel implementeren, zijn we dan veilig? Kunnen we concluderen dat er altijd scenario’s overblijven waar nog geen requirements voor zijn opgesteld, dat het van belang is deze risico’s in een risicoworkshop goed mee te wegen, en daar waar noodzakelijk extra requirements toe te voegen als het risico daar om vraagt. Het implementeren van de requirements uit de standaarden resulteert dus niet in een 100% veilig product (als dit überhaupt al mogelijk is), maar het zorgt wel dat er een goede basis wordt neergezet, die voor producten met een specifiek risicoprofiel verder kan worden uitgebreid.
Aanbevelingen
Organisaties krijgen veel technische regelgeving op zich af. Gelukkig is er nog een flinke periode voordat de CRA-handhaving begint, maar er zijn een aantal strategische dilemma’s en aandachtspunten waarmee producenten, als ze hun aandacht erop richten, hun voordeel kunnen doen:
  • Identificeer in een vroeg stadium welke technologie gebruikt gaat worden tijdens de lifecycle support en standaardiseer waar mogelijk over verschillende ontwikkelgroepen. Het beschikbaar zijn en blijven van de build-omgeving van een product is noodzakelijk om te borgen dat een nieuwe versie / patch uitgegeven kan worden. Het valt aan te bevelen om vooraf te bepalen op welke manier bijvoorbeeld de SBOM zal worden gemonitord, welke standaard gebruikt gaat worden in de rapportage [NCSC23] en hoe kwetsbare libraries te vervangen. Gaan developers met plugins aan de slag om te zorgen dat het product bij het releasen vrij is van exploiteerbare kwetsbaarheden, of kies je er vanaf het begin voor third-party libraries geautomatiseerd en los van de ontwikkelaars te monitoren, om makkelijker aan de verplichtingen te doen? Is het nodig om abstracties voor sommige meer gevoelige libraries te maken? Dat laatste is een van de oplossing die geopperd worden in het PQC-migratiehandboek van TNO, CWI en de AIVD-NBV [TCA23] ten aanzien van cryptografie.

    Tot slot valt het aan te bevelen om van tevoren te bepalen hoe om te gaan met open-source libraries (die niet beperkt worden voor commercieel gebruik). Het zou zomaar kunnen dat de commerciële integrator van het open-sourcepakket een aanzienlijke hoeveelheid acties moet ondernemen om het pakket compliant te krijgen en compliant te houden [BH23].

  • Zorg voor een intern raamwerk met het juiste abstractie niveau: zeker als er meerdere product ontwikkelteams (met verschillende ontwikkeltalen) in uw organisatie werken is het van belang om voor het CRA-toezichtraamwerk op het juiste abstractieniveau vast te stellen. Controls en requirements die teveel ingaan op een specifieke taal of omstandigheid zijn niet toetsbaar voor alle projecten (en resulteren in onnodige discussies), terwijl een te abstracte versie (te) veel ruimte voor interpretatie kan laten. Voor hele specifieke securityeisen (bijvoorbeeld het gebruik van cryptografie) valt het aan te bevelen om te refereren naar specifieke implementatierichtlijnen op projectniveau.

  • Neem een strategisch besluit over legacy code en de levensduur van het product: een andere complexiteit die organisaties moeten overbruggen als onderdeel van CRA-compliance is het gebruik van legacy besturingssystemen (een besturingssysteem waar de leverancier geen ondersteuning meer voor biedt) en legacy code. Om met de legacy besturingssystemen te beginnen: In de beginfase van een product ontwikkeltraject wordt veelal een keuze gemaakt op welk besturingssysteem het product gaat worden ontwikkeld. Zeker als er specifieke hardware-stuurprogramma’s worden ontwikkeld die op een unieke manier samenwerken met de lagere lagen in het besturingssysteem, kan het zijn dat het product “vast” komt te zitten aan een specifieke versie van het besturingssysteem. Echter, besturingssystemen worden niet oneindig ondersteund. Microsoft houdt bijvoorbeeld netjes een tabel bij [MS24] waarin af te lezen is wanneer het product niet meer wordt ondersteund en wanneer er geen patches meer voor zullen worden gemaakt. Een strategische keuze die moet worden gemaakt, is de tijd die een product in de portfolio van een organisatie zit, en als de ontwikkeltijd plus de tijd dat het in de portfolio zit langer is dan het support van het gekozen OS, zal moeten worden bepaald hoe daar mee om te gaan.

    Een tweede dilemma zit hem in legacy code. Sommige producten hebben een lange geschiedenis van productontwikkeling en kunnen uit wel miljoenen regels aan code bestaan. Het herschrijven van deze code kan een dure exercitie zijn, zeker als deze niet ontworpen is om op een makkelijke manier kwetsbare libraries te kunnen updaten of kwetsbare functies te kunnen vervangen. Ook het behouden van backward compatibiliteit is een discussie die beter op beleidsniveau dan voor elke individuele implementatie apart kan worden gevoerd.

  • Werk met een multidisciplinair team: een team samengesteld uit engineers, compliance experts, IT-auditors, en juristen helpt om CRA-compliance efficiënt in te richten. Door het combineren van expertises, kan een gezamenlijke positie worden neergezet. Vragen als Wat betekent het op de markt van een product eigenlijk? Wat is exploiteerbaar? Hoe tonen we conformiteit aan? kunnen door deze groep worden beantwoord.
Conclusie
De Cyber Resilience Act zet een belangrijke stap in het afdwingen van betere beveiliging van producten die een cruciale rol spelen in industriële. Gaat het alle mogelijke product kwetsbaarheden die de meest geavanceerde hackers kunnen bedenken voorkomen? Dat niet, maar de CRA gaat zorgen voor een significante verbetering van de cyberveiligheid van producten die op de Europese markt worden toegelaten.

Alhoewel er na ingang van de wetgeving een overgangsperiode is, zal het een flinke uitdaging worden voor organisaties om tijdig aan de nieuwe regelgeving te gaan voldoen. Het valt daarom aan te bevelen om niet te lang te wachten met de implementatie van de nieuwe bedrijfsprocessen en product eisen.

ir. Jeroen Slobbe MBA
Jeroen is een cybersecurity professional met een passie voor cybersecurity van Operationele Technologie. Hij combineert technische expertise met bedrijfskundige inzichten en helpt klanten cybersecurity risico’s te reduceren. Met meer dan 12 jaar ervaring is hij een vertrouwde sparringpartner voor bestuurders, CISOs en technische professionals. Momenteel werkt hij als director cyber security advisory bij BDO.
Begrippenlijst
SBOM: een overzicht van alle software onderdelen die het product bevat. Vergelijk dit bijvoorbeeld met een pakbon, waarin de losse onderdelen beschreven staan maar dan voor software. Zo weet je wat er in de doos zou moeten zitten en geeft de gebruiker de mogelijkheid -als bijvoorbeeld bekend wordt dat een onderdeel met een specifiek serienummer slecht werkt of giftige stoffen bevat- te controleren of zijn product aangetast is of niet.

PQC: Post Quantum Cryptografie is een set aan algoritmes gebaseerd op wiskundige problemen die niet makkelijk door een kwantum computer opgelost kunnen worden. Alhoewel het nog jaren kan duren voordat er krachtige kwantum computers zijn die klassieke asymmetrische versleuteling kunnen breken, zullen we een keer de transitie door moeten.

Software abstractie: is een extra laag in software, welke de precisie werking van de software voor een programmeur verstopt. Dit maakt het mogelijk om onderdelen wat makkelijker in een software product te wisselen. Heel concreet, als je in een software product hashDataWithMD5(…){} gebruikt, en je wil het algoritme vervangen, dan moet je al je code herzien om de functie te vervangen. Als je een abstractie gebruikt hashData(…){} en deze functie vervolgens het daadwerkelijke algoritme en parameters laat bepalen, dan hoef je enkel deze functie aan te passen. In de context van cryptografie wordt dit concept ook wel crypt-agility genoemd.