Door Ellen Wesselingh
Samenvatting
Dit artikel beschrijft een vervolgactiviteit voor de analyse die is beschreven in Eliminating the weakest link - Managing Supply Chain Cybersecurity Risk through Life Cycle Modelling (IB Magazine 2024#4): de analyse van onderdelen die cruciaal zijn voor de beveiliging en vervolgacties. Niet alle componenten in een systeem zijn kritisch voor de beveiliging, dus maatregelen in de toeleveringsketen kunnen variëren in strengheid. Een voorbeeld zijn de schroeven waarmee een omhulsel wordt gesloten, op voorwaarde dat het omhulsel niet essentieel is voor veiligheidsmaatregelen, zoals beveiliging tegen sabotage. Daarom moeten de veiligheidskritische functies, d.w.z. de functies die de veiligheid afdwingen en de functies die de veiligheid ondersteunen, worden geïdentificeerd. Nadat de toeleveringsketens voor een product zijn geïdentificeerd, kunnen maatregelen worden besproken met partners. Open-source projecten moeten mogelijk anders worden behandeld.
Context
In het vorige artikel werd een risicoanalysemodel voor de toeleveringsketen geïntroduceerd [1], gebaseerd op een MITRE-model uit 2013 [2]. De primaire focus was het ontwikkelen van een aanvalsraamwerk voor de toeleveringsketen dat zich richt op het primaire proces waarmee een product met IT-componenten wordt geproduceerd, en dit artikel bouwt voort op dat model om de risicoanalyse verder te verfijnen.
Bij het ontwikkelen van een systeem, of het nu een ingebed systeem is met hardware, firmware en softwarecomponenten, of een systeem dat alleen uit software bestaat, bestaan er vele toeleveringsketens. Randall Munroe (XKCD) liet dit zeer diepgaand zien voor Open Source Software (OSS), in een cartoon uit 2020. De afbeelding illustreert het probleem van veel toeleveringsketens. In zowel commerciële als open-source toeleveringsketens heeft de entiteit die uiteindelijk het product op de markt brengt weinig overzicht over en controle over de vele leveranciers.
Sommige leveranciers zijn grote bedrijven met de middelen om cyberbeveiligingsmaatregelen in al hun ontwikkelingsprocessen te implementeren. Andere leveranciers bevinden zich aan de andere kant van het spectrum: kleine gemeenschappen zonder de middelen of de kennis om cyberbeveiligingsmaatregelen te implementeren en te onderhouden. Er zijn er waarschijnlijk nog veel meer die zich tussen deze uiteinden van de schaal bevinden. De uitdaging is dat de entiteit die het product op de markt brengt, waarschijnlijk niet precies weet wat de status van elke leverancier is. Het is waarschijnlijk onmogelijk om alle componenten van een product en hun respectieve toeleveringsketens te analyseren. Daarom moet de omvang van de te analyseren componenten worden beperkt. Dit wordt gedaan door niet-veiligheidskritische componenten uit de analyse te verwijderen. Hoe dit kan worden gedaan, is het onderwerp van dit artikel. Secundaire diensten zoals de toeleveringsketen van andere kantoren of communicatieprocessen vallen buiten het bestek, maar kunnen in toekomstig werk aan de orde komen. Hetzelfde geldt voor toeleveringsketens van diensten die aan klanten worden geleverd.
Gebruikte methode
Het oorspronkelijke onderzoek werd geïnspireerd door een presentatie van Andrew Huang op een Blue Hat conferentie [4]. In zijn presentatie noemde Huang een aantal aanvallen. De artikelen die deze aanvallen beschreven, werden geanalyseerd op verdere ideeën en referenties (sneeuwbalmethode). Vervolgens werd er gezocht naar (hardware) aanvallen op de toeleveringsketen met meer algemene trefwoorden om andere aanvallen op de hardware van de toeleveringsketen te vinden. Deze aanvallen werden vervolgens geanalyseerd. Er werd in deze fase niet specifiek gezocht naar softwareproblemen vanwege de overweldigende hoeveelheid softwarematige beveiligingsproblemen.
Enkele baanbrekende softwareaanvallen werden bestudeerd ter illustratie van softwareaanvallen in de toeleveringsketen. In 2024 dook een nieuw type open source aanval op (XZ Utils): een combinatie van social engineering en het vergiftigen van open source bibliotheken met backdoors [5]. De aanval werd niet volledig uitgevoerd, maar was zeer dicht bij succes. Andere voorbeelden van ketenproblemen die opdoken in 2024 zijn de wereldwijde uitval van Windows-servers als gevolg van een CrowdStrike-update in juli, de tijdelijke uitschakeling van het Nederlandse high-security netwerk NAFIN in augustus en de pager/walkie-talkie-aanvallen op Hezbollah in september. De problemen met Windows en NAFIN waren waarschijnlijk niet het gevolg van een daad met kwade bedoelingen, maar de resulterende systeemuitval veroorzaakte desalniettemin wijdverspreide problemen voor de samenleving. Tot slot was de aanval op Hezbollah een uitgebreide supply chain aanval, waarbij een Advanced Persistent Threat (APT) in staat was om een complete supply chain te manipuleren.
De XZ Utils backdoor liet zien dat een kwaadwillende entiteit in staat was om een persona (of meerdere) aan te maken en vertrouwen op te bouwen met die willekeurige persoon die de library sinds 2003 ondankbaar onderhoudt. De kwaadwillende entiteit was uiteindelijk in staat om het project over te nemen en een backdoor te implanteren om beveiligingskritische software zoals OpenSSH aan te vallen. In dit geval was een applicatie die bovenop de core was gebouwd in staat om een andere component via die core te infecteren. Een van de grootste cyberincidenten in de geschiedenis werd voorkomen omdat een ontwikkelaar die Debian Sid Linux draaide merkte dat de SSH Daemon iets meer CPU-tijd gebruikte dan normaal terwijl hij iets compleet ongerelateerds aan het benchmarken was [3]. Dit soort aanvallen laat zien hoe belangrijk het is om je toeleveringsketens te kennen. Het laat ook zien hoe moeilijk het is om alle toeleveringsketens te beheren.
Het model zoals beschreven in het vorige artikel is het startpunt voor de volgende stap in het proces: het bepalen van veiligheidskritische componenten en een gedetailleerde analyse van de toeleveringsketens van deze componenten. Voor dit deel van het onderzoek wordt gebruik gemaakt van de Common Criteria [6]. Deze internationale standaard voor het beoordelen van de beveiliging van IT-producten definieert de begrippen functies die de beveiliging afdwingen, functies die de beveiliging ondersteunen en functies die de beveiliging niet verstoren.
Vorig model
Het model zoals beschreven in het vorige artikel maakt gebruik van de volgende stapsgewijze risicoanalyse van de toeleveringsketen:
1. Schets een levenscyclus en indien mogelijk een toeleveringsketenmodel.
2. Bepaal de van toepassing zijnde categorieën uit de categorieën van het aanvalsoppervlak: architectuur, standaard, hardware, firmware, besturingssysteem of software en ontwikkelomgeving.
3. Bepaal voor de hierboven bepaalde categorieën welke aanvallen van toepassing zijn.
4. Zet de aanvallen uit op het levenscyclusmodel.
5. Bespreek voor elke aanval met deskundige collega's welke tegenmaatregelen mogelijk zijn om de aanval tegen te gaan.
6. Bespreek voor alle tegenmaatregelen met de relevante partners in de toeleveringsketen wat mogelijk is. 7. Wanneer alle toe te passen tegenmaatregelen bekend zijn, identificeer dan het resterende risico. 8. Binnen een specifiek evaluatie-/certificatiekader kan het risico worden gekwantificeerd. In de Common Evaluation Methodology is er bijvoorbeeld een kwetsbaarheidsanalyse, waarvan de uitkomst de berekening is van het aanvalspotentieel dat nodig is om het te evalueren IT-product succesvol aan te vallen [7].
De hierboven beschreven stappen zijn de algemene stappen voor elke supply chain-analyse. Er zijn echter veel soorten producten met hun eigen supply chain-specifieke problemen. Daarom is voor een specifiek product een meer gedetailleerde analyse nodig. Deze analyse vereist een beperking van de reikwijdte om de werklast beheersbaar te houden. De eerste stap is om voor elk onderdeel te bepalen of het:
1. Beveiliging afdwingend: deze componenten implementeren direct een functionele beveiligingseis, bijvoorbeeld gebruikersidentificatie en authenticatie.
2. Beveiligingsondersteunende componenten: deze componenten implementeren niet direct een functionele beveiligingseis, maar moeten correct functioneren zodat de beveiligingsondersteunende componenten hun werk kunnen doen. Een typisch voorbeeld is de Human Machine Interface (HMI), die wordt gebruikt voor gebruikersidentificatie en authenticatie.
3. Security non-interfering: de beveiliging afdwingende en ondersteunende componenten vertrouwen niet op deze componenten voor hun correcte werking. Idealiter kunnen deze componenten de correcte werking van de beveiliging afdwingende en ondersteunende componenten helemaal niet beïnvloeden. De XZ Utils casus liet zien hoe moeilijk dit is. Voorbeelden zijn meestal de behuizing en de stroomaansluiting.
Volgende stappen in de analyse
De definitie van een component als beveiliging afdwingend, ondersteunend of niet-bemoeiend is afhankelijk van meerdere factoren. De eerste en belangrijkste input is de definitie van bedrijfsmiddelen in de beveiligingsclaim. Deze claim moet beschrijven wat het type bedrijfsmiddelen is, zoals (persoons)gegevens of operationele processen. Voor de gedefinieerde bedrijfsmiddelen moet duidelijk zijn welke bescherming moet worden geboden: vertrouwelijkheid, integriteitof beschikbaarheid. Voor (persoonlijke) gegevens is vertrouwelijkheid meestal het belangrijkste. Voor operationele processen is beschikbaarheid meestal het belangrijkste. Zowel vertrouwelijkheid als beschikbaarheid vereisen systeemintegriteit als basis.
De tweede en zeer belangrijke input is de beveiligingsfunctionaliteit die het product moet bieden. Het feit dat de beveiligingsclaim wordt gebruikt voor de analyse, betekent dat er bepaalde kwaliteitscriteria van toepassing zijn op die claim. Als een beschrijving van een beveiligingsclaim niet feitelijk of meetbaar is, dan is het niet mogelijk om de analyse op die claim te baseren. Common Criteria biedt een bibliotheek met gestandaardiseerde functionele beveiligingseisen ter ondersteuning van de ontwikkeling van een goed gedefinieerde beveiligingsclaim [8].
De experts bepalen voor alle componenten hun bijdrage aan de beveiligingsfuncties. Dit gebeurt meestal in de vorm van een vergadering met experts uit verschillende disciplines. Voor elke component wordt zijn functie besproken met betrekking tot de bedrijfsmiddelen zoals gedefinieerd in de beveiligingsclaim. Dit leidt tot een lijst van componenten die worden geclassificeerd als kritisch voor de beveiliging (afdwingend of ondersteunend), of als niet storend. Componenten die de beveiliging niet verstoren hoeven niet te worden onderworpen aan voorzorgsmaatregelen in de toeleveringsketen, componenten die de beveiliging wel verstoren wel.
Voor deze veiligheidskritische componenten worden de fabrikanten bepaald. Een fabrikant kan een commerciële entiteit zijn, gevestigd in de EU zelf of via een partner. Dit type leverancier kan worden aangesproken in een formele contractuele relatie. Een fabrikant kan ook een open-sourceproject zijn. Met dit type leverancier bestaat geen formele relatie. De gemeenschap die het open-sourceproject onderhoudt, kan zich zelfs niet bewust zijn van het feit dat specifieke bedrijven hun producten gebruiken. Daarom moet dit type toeleveringsketen anders behandeld worden.
Beheer van partners in de toeleveringsketen
Bij formeel gevestigde entiteiten kunnen maatregelen voor de beveiliging van de bevoorradingsketen worden overeengekomen en vastgelegd in het contract. Overeengekomen veiligheidsmaatregelen, vergelijkbaar met een Non-Disclosure Agreement (NDA), zouden helpen om de supply chain relatie tussen leverancier en koper te formaliseren. Als input voor deze contractuele overeenkomst kunnen de maatregelen worden gebruikt die zijn beschreven in de bijlage van het vorige artikel [1].
Wanneer je te maken hebt met een open source community kan het lastig zijn om een formele relatie op te bouwen. Fox-IT heeft ervaring met dit proces bij het bouwen van OpenVPN-NL bovenop OpenVPN. OpenVPN bestaat sinds 2001 en wordt onderhouden door een internationale gemeenschap [9]. OpenVPN-NL bestaat sinds 2011 en wordt onderhouden door Fox IT [10]. Het duurde enkele jaren om een vertrouwensrelatie tussen beide partijen op te bouwen. Er zijn andere voorbeelden van commerciële bedrijven die open source-projecten ondersteunen, bijvoorbeeld door medewerkers met specifieke expertise tijd te geven om een open source-project te onderhouden. Andere communities zijn zelf sterke gemeenschappen die in de loop van jaren zijn opgebouwd [11].
Sponsors zouden een rol kunnen spelen bij het opbouwen van sterkere OSS-gemeenschappen. Commerciële entiteiten kunnen bereid zijn om deel te nemen aan de ontwikkeling van open source-projecten onder de paraplu van maatschappelijk verantwoord ondernemen (MVO), maar het onderhouden van een groot open source-project is waarschijnlijk duurder dan het MVO-budget. Wanneer echter meerdere bedrijven doneren, wordt de last gedeeld. In 2011 publiceerde Fox-IT OpenVPN-NL open source, Fox Crypto onderhoudt het. In 2022 heeft Fox-IT zijn eigen toolset voor incident response analyse, Dissect, open source gemaakt. In 2023 heeft Fox Crypto een eigen implementatie van een Post Quantum Resilient XMSS-algoritme gebouwd en open source gepubliceerd. Delen van deze projecten zijn gesponsord door de Nederlandse overheid. Door deze sponsoring kunnen de Fox bedrijven, die middelgrote bedrijven zijn, meebouwen aan een (cyber)veiligere samenleving.
Hoe bouw je als bedrijf vertrouwen op in een open-sourcegemeenschap? Onze ervaring is dat communicatie en participatie cruciaal zijn. Vertrouwen moet wederzijds zijn. Bedrijven ondersteunen vaak technologie (code), maar kunnen een project ook helpen om hun ontwikkelprocessen volwassener te maken. Bijvoorbeeld door bij te dragen aan veilige ontwikkelprocessen of door infrastructuur of tools te leveren om de kwaliteit van de code te controleren. Vertrouwen opbouwen vereist meestal het tonen van capaciteiten en betrokkenheid op lange termijn. Na verloop van tijd zal een gemeenschap de bijdragen van het bedrijf op hun merites kunnen beoordelen en kan het bedrijf beoordelen of de stabiliteit en volwassenheid van de gemeenschap voldoen aan de eisen van de toeleveringsketen.
In principe is alles wat de aanvaller in de XZ Utils zaak deed ... Achteraf gezien is het enigszins vreemd om te zien dat een bedrijf dat vertrouwde systemen bouwt voor de high-assurance industrie met argwaan wordt bekeken, terwijl entiteiten die claimen individuen te zijn helemaal niet rigoureus worden gecontroleerd. Gezien de geschiedenis van overheidsbemoeienis met cryptografische zaken is het begrijpelijk [12]. Maar bedrijven worden meestal niet geleid door kwade bedoelingen als het gaat om het met opzet bouwen van backdoors, de problemen ontstaan waarschijnlijk eerder door incompetentie dan door kwaadwillendheid.
Wat moeten fabrikanten van samengestelde systemen doen wanneer ze open-source componenten in hun product opnemen? Ze zouden op zijn minst moeten beoordelen of deze componenten veiligheidskritisch zijn. Voor die componenten kunnen de volgende controles enige zekerheid bieden dat de componenten geschikt zijn voor het doel:
1. Of de gemeenschap robuust is, in de zin dat ze goed gevestigd is en onderhouden wordt door een voldoende grote groep beheerders. Met betrekking tot onderhoud kan actief onderhoud gemonitord worden met behulp van de volgende meetgegevens: de tijd die het kost om gerapporteerde problemen op te lossen, hoeveel pull requests er momenteel open staan en de gemiddelde tijd dat een pull request open blijft staan.
2. Ga indien mogelijk na waar de community gevestigd is en waar de beheerders wonen. Zoek uit welke organisatie de community onderhoudt, zijn er één of meerdere bedrijven of andere gevestigde organisaties bij betrokken, of wordt de community puur door vrijwilligers onderhouden. Hebben de organisaties die de community ondersteunen een goede reputatie? De grootte van het team is ook een indicator voor de stabiliteit van de gemeenschap. Gebruik geen open source software van gemeenschappen die gevestigd zijn in landen met een offensieve cyberstrategie.
3. Beoordeel de kwaliteit van het product, de begeleidende documentatie en de werkprocessen. Controleer of het product volledig is, zo niet, wat de status van het product is. Controleer of de documentatie beschikbaar, leesbaar en compleet is. Controleer of problemen worden gemeld en opgelost op bijvoorbeeld GitHub, en of de tijd tussen het melden van een probleem en het oplossen van het probleem in verhouding staat tot de functionaliteit van het product en de ernststatus van het probleem. Controleer of er actief over het product wordt gediscussieerd op platforms als Discord, Reddit en Stack Overflow. Als er een roadmap voor het product beschikbaar is, biedt dit zekerheid over de beschikbaarheid op de lange termijn.
4. Gebruik indien mogelijk extern geverifieerde componenten. Sommige OSS zijn geëvalueerd, wat enige zekerheid geeft over de kwaliteit. De OpenVPN-NL variant van OpenVPN is zo'n voorbeeld.
5. Als de technische expertise beschikbaar is, voer dan een review van de broncode uit. Aangezien het reviewen van broncode bewerkelijk is, moet je je richten op de onderdelen die cruciaal zijn voor de beveiliging, zoals invoervalidatie of cryptografische bewerkingen. Een andere optie is om te controleren of er publieke (hoogwaardige) code-reviews zijn gedaan. OpenVPN bijvoorbeeld wordt zo nu en dan extern gecontroleerd.
6. Controleer tot slot of de OSS-licentie geschikt is voor het doel. Er zijn licentietypen die bepaalde vormen van gebruik van het product verbieden, of die open source publicatie vereisen van alle wijzigingen aan het product. 7. Zodra een OSS-component is gekozen, neem dan het scannen op open-source kwetsbaarheden op in het werkproces voor het importeren ervan. Dit houdt zero-day aanvallen zoals de XZ Utils aanval niet tegen, maar het beperkt het potentiële aanvalsoppervlak.
Voor deze stappen zijn middelen nodig. Dit kan gezien worden als een kostenfactor, terwijl het gezien zou moeten worden als een investeringsfactor. Het begint met het besef dat een beveiligingslek zeker zal plaatsvinden als de beveiliging niet goed is bekeken tijdens het ontwikkelingsproces. Inbreuken op de beveiliging zijn vaak erg kostbaar (zie hieronder).
Laatste stappen
Als de onderdelen die cruciaal zijn voor de beveiliging zijn geïdentificeerd en de tegenmaatregelen die van toepassing zijn zijn overeengekomen met de partners in de toeleveringsketen of op een andere manier zijn aangepakt, kunnen de resterende risico's worden geïdentificeerd. Voor deze stap moet een geschikte risico-identificatiemethode voor de specifieke industrie worden gebruikt. De Common Evaluation Methodology (CEM) biedt een generieke methode voor producten, door het aanvalspotentieel te modelleren dat nodig is om een product succesvol aan te vallen [7]. Voor geïntegreerde schakelingen (IC's) en vergelijkbare apparaten is er een specifieke methode beschikbaar [13]. Deze methoden zijn echter bewerkelijk. Voor informatietechnologieproducten (IT) met een laag risico kan een methode die gebruikmaakt van integriteitsniveaus van beveiliging langs de assen van blootstelling en impact voldoende zijn. Voor Operationele Technologie (OT) moet een methode worden gebruikt die gebruikmaakt van blootstelling en schade in combinatie met beheersbaarheid. De veiligheidsnorm voor auto's ISO26262 gebruikt bijvoorbeeld het Automotive Safety Integrity Level (ASIL). Dit model kan worden toegepast op cyberbeveiliging [14].
Het resterende risico moet dan worden beoordeeld voor risicobeperking door de implementatie van aanvullende maatregelen, of risicoaanvaarding. Het risiconiveau moet worden afgewogen tegen de kosten van verdere risicobeperking. Het afwegen van risico tegen (verdere) risicobeperking is uiteindelijk een zakelijke beslissing. Dit vereist inzicht in de risico's van cyberbeveiliging door de business. Seminal cases, zoals Diginotar [15], Universiteit van Maastricht [16], en Maersk [17], die publiekelijk zijn besproken, kunnen het bedrijf helpen bij het inschatten van de potentiële kosten van een cyberbeveiligingsinbreuk.
In het geval van Maersk moest het hele wereldwijde interne netwerk opnieuw worden opgebouwd. Dit leidt niet alleen tot de kosten van het opnieuw moeten opbouwen van het netwerk, maar ook tot ernstige kosten door productiviteitsverlies. Dit laatste was in dit geval misschien wel de grootste factor in de totale kosten.
Discussie en conclusies
Aanvallen op de toeleveringsketen vormen een reëel risico en komen vaak in nieuwe vormen. Analyse van het aanvalsoppervlak, dat moet worden verkleind door tegenmaatregelen, is het startpunt voor mitigatie. In dit artikel zijn verdere stappen besproken in de analyse van componenten die worden geleverd door partners in de toeleveringsketen. Hoewel niet alle risico's in de toeleveringsketen kunnen worden beperkt, is nadenken over je toeleveringsketens en opties voor risicobeperking een belangrijke stap op weg naar een robuustere toeleveringsketen vanuit een beveiligingsperspectief.
Het gebruik van gevestigde normen en methoden helpt bij het vaststellen van een basislijn met betrekking tot cyberbeveiliging in de toeleveringsketen. Voor kleine bedrijven of bedrijven met weinig ervaring op het gebied van cyberbeveiliging zal dit een uitdaging zijn. Deze bedrijven kunnen beginnen met het gebruik van cyberbeveiligingsgecertificeerde producten, als die beschikbaar zijn. Deze producten zijn vaak duurder dan niet-gecertificeerde producten omdat certificering inspanning en dus een business case vereist. Een inbreuk op de beveiliging van een product kan echter zeer duur uitvallen. Een bekend voorbeeld van hoe duur een inbreuk kan zijn, is de Nederlandse Diginotar-zaak [15]. Het bedrijf hield uiteindelijk op te bestaan nadat het was gehackt. De inbreuk bij Maersk met NotPetya heeft naar schatting 300 miljoen dollar gekost, en dit bedrijf was niet het enige slachtoffer dat ernstige schade heeft geleden [18].
Het model en de volgende stappen, zoals beschreven in dit artikel, bieden een basis voor risicoanalyse en -beperking in de toeleveringsketen. Belangrijke stappen zijn het identificeren van de toeleveringsketens, het identificeren van de leveranciers van kritieke beveiligingscomponenten in de toeleveringsketen en het maken van formele afspraken met deze partners. De precieze implementatie van de tegenmaatregelen maakt geen deel uit van het model, omdat deze worden bepaald door de partners in de toeleveringsketen.