Door Ellen Wesselingh
Samenvatting
In de afgelopen jaren is het aantal problemen met de toeleveringsketen van producten met digitale elementen toegenomen, wat een probleem vormt voor het waarborgen van de integriteit van deze producten en de vertrouwelijkheid van de gegevens in deze producten. Om het probleem te illustreren, geeft dit artikel een aantal voorbeelden van aanvallen op de toeleveringsketen die de afgelopen jaren hebben plaatsgevonden. Het artikel geeft ook een model voor risicoanalyse van de toeleveringsketen. Dit model is gebaseerd op een bestaand model uit 2013, dat is aangepast met een abstractieniveau om het model zo volledig mogelijk te maken. Een risicoanalyse die is uitgevoerd met behulp van dit model, aangevuld met een extra analyse van het resterende risico, zou voldoende argumentatie moeten opleveren dat de toeleveringsketen veilig genoeg is voor zijn doel.
Context
Dit artikel bespreekt recente ontwikkelingen in producten met digitale elementen, die kunnen leiden tot beveiligingsproblemen wanneer systemen met deze elementen worden ingezet. Ook worden mogelijke oplossingen besproken. Eén probleem wordt niet behandeld: verkeerde informatie. Hoewel dit een groot probleem is, maakt verkeerde informatie het product minder betrouwbaar in de ogen van de toeschouwer. Dat betekent dat het niet het doel is van dit model, omdat het de veiligheid van het systeem niet aanpakt. Verkeerde informatie kan gebruikers van het systeem echter wel tot minder veilige keuzes leiden [1].
Het wordt aanbevolen om (internationaal erkende) standaarden te gebruiken voor interoperabiliteit, industriestandaard ontwikkeltools voor kwaliteitsborging en om architectuur, ontwerpen, firmware en software te hergebruiken om redenen van kostenefficiëntie en ontwikkelingstijd [2]. Aangezien het (her)gebruik van deze componenten de toeleveringsketen echter sterk uitbreidt, leidt dit tot een grotere kans op aanvallen op de toeleveringsketen.
In de afgelopen tien jaar zijn de problemen in de toeleveringsketen duidelijker geworden. Dit blijkt uit voorbeelden zoals Meltdown en Spectre [3] [4], die hebben aangetoond dat hardware-architectuurkeuzes de mogelijkheid van geavanceerde hardware-aanvallen kunnen introduceren. Kaseya en Solarwinds hebben een vergelijkbare introductie van aanvalsmogelijkheden via ondersteunende diensten laten zien [5] [6]. Een ander baanbrekend voorbeeld is het Nederlandse geval van Diginotar, waarbij een certificaatuitgevende dienst werd gehackt [7]. Deze voorbeelden hebben duidelijk gemaakt dat hackers potentieel interessante doelwitten kunnen aanvallen via hun toeleveringsketens. Dit geldt vooral voor producten met een hoge betrouwbaarheid die potentieel interessante doelwitten zijn voor Advanced Persistent Threats (APT's), ook bekend als statelijke actoren. Dergelijke doelwitten met veel blootstelling zijn onder andere de energiesector, de financiële sector en de militaire sector.
Aanvallen op de hardwareleveringsketen kunnen worden onderverdeeld in twee categorieën. De directe hardware supply chain aanvallen worden uitgevoerd door actief backdoors en/of trojans in hardware in te bouwen [8] [9], terwijl de indirecte hardware supply chain aanvallen, zoals Meltdown en Spectre, het gevolg zijn van echte ontwerpbeslissingen met nadelige gevolgen voor de beveiliging [3] [4]. Soortgelijke overwegingen moeten worden gemaakt voor firmware en software, met het onderscheid dat deze kunnen worden bijgewerkt op productiesystemen, terwijl dat meestal niet mogelijk is voor pure hardwaresystemen zoals IC's en ASIC's.
Een doelwit kan de toeleveringsketen voor directe organisatorische activiteiten zijn, zoals de productieketen. Maar ook indirecte toeleveringsketens kunnen het doelwit zijn, zoals diensten die een organisatie gebruikt voor marketingonderzoek [10]. Andere, eveneens indirecte operaties, zoals een financiële backend of een HRM-systeem (Human Resources Management) kunnen net zo kwetsbaar zijn. Het komt erop neer dat organisaties zich bewust moeten zijn van al hun toeleveringsketens en de manier waarop deze elementen kritieke bedrijfsactiviteiten kunnen verstoren, zelfs als ze worden gezien als afgelegen elementen van de complete operatie met al haar toeleveringsketens.
De primaire focus van dit artikel is het ontwikkelen van een aanvalskader voor de toeleveringsketen dat zich richt op het primaire proces waarin een product met IT-componenten wordt geproduceerd. Dergelijke producten kunnen bestaan uit hardware, firmware, software, een combinatie van deze drie, of (ontwikkelings)systeeminformatie of andere productgegevens. Problemen in de toeleveringsketen die van invloed zijn op de systemen die de ontwikkelomgeving ondersteunen, komen ook aan bod.
Secundaire diensten zoals de toeleveringsketen van andere kantoorprocessen of communicatieprocessen vallen buiten het bestek, maar kunnen in toekomstig werk aan bod komen. Hetzelfde geldt voor toeleveringsketens van diensten die aan klanten worden geleverd.
Gebruikte methode
Het onderzoek werd geïnspireerd door een presentatie van Andrew Huang op een Blue Hat conferentie [11]. In zijn presentatie noemde Huang een aantal aanvallen [8] [9] waarvoor 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.
Nadat er een lijst met relevante aanvallen op de toeleveringsketen van hardware was samengesteld, werd er gezocht naar bestaande raamwerken voor levenscycli en toeleveringsketens. Deze zoektocht leverde een lijst op met mogelijk relevante raamwerken van geloofwaardige instellingen zoals ISO, MITRE, NATO, NIST [12] [13] [14] [15] [16]. Nadat de lijst was samengesteld, werd het meest relevante bestaande raamwerk gekozen. Het ISO-, NAVO- en NIST-raamwerk richten zich voornamelijk op afzonderlijke organisaties en vertellen hoe problemen op een gestandaardiseerde manier kunnen worden opgelost. Het MITRE-raamwerk laat zien wat er mis kan gaan en wat de mogelijke oplossingen kunnen zijn [13].
Het bestaande raamwerk gebruikte een ander levenscyclusmodel en werd daarom omgezet naar het levenscyclusmodel dat bij dit bedrijf in gebruik is. Het gekozen raamwerk leverde een lijst met aanvallen in de verschillende levenscyclusfasen en een lijst met tegenmaatregelen die tegen de aanvallen genomen kunnen worden. Het nieuwe model werd aangepast met een aanval in de pensioenfase, het nieuwe levenscyclusmodel wordt weergegeven in de onderstaande figuur.
Het model werd vervolgens gevalideerd op bruikbaarheid door het toe te passen op een werkelijke supply chain-situatie van de belanghebbende. Na de toepassing werden verschillende nieuwe tegenmaatregelen toegevoegd en werd het model aan collega's geïntroduceerd. Sindsdien is het meerdere keren gebruikt in echte supply chain-situaties.
Dit artikel beschrijft hoe het model is herwerkt door de aanvallen en tegenmaatregelen opnieuw te rangschikken. Het raamwerk werd in verschillende fasen ontwikkeld. In elke fase werd het model gevalideerd door peer review met deskundige collega's intern. Tussen deze fasen werd het raamwerk toegepast op actuele projectvragen, wat leidde tot de validatie van het model.
Tijdens het schrijven van dit artikel werd informatie gezocht over aanvallen en kwetsbaarheden in de toeleveringsketen voor firmware en software. Een van de voorbeelden die werd gevonden is Log4J, een Open Source Software (OSS) component die veel wordt gebruikt in veel IT-systemen, waarvan de beheerders en gebruikers vaak niet wisten dat het werd gebruikt in hun applicaties [17].
Verder werd een overkoepelende abstractielaag toegevoegd om de volledigheid van het model overtuigender te laten zien. Tot slot werd het model gevalideerd door presentaties te geven aan vakgenoten, wat leidde tot nuttige feedback.
Resultaten
De resultaten van het project zijn drieledig:
- Een herwerkt aanvalskader voor de toeleveringsketen en analysemodel voor risico's in de toeleveringsketen (dit artikel)
- Een presentatie over het model: Een eerdere versie van het model werd gepresenteerd op de International Common Criteria Conference 2023, november 2023.
- Een cursus over het gebruik van het model in combinatie met levenscyclusanalyse om problemen in de toeleveringsketen aan te pakken: Een conceptcursus is ontwikkeld en klaar voor herziening.
Bijgewerkt model
De onderstaande figuur toont de hoogste abstractielaag van het model. Het model bevat verschillende abstractielagen van het product. De ontwikkelomgeving wordt gemodelleerd als relevant voor alle stadia van ontwikkeling: standaard, architectuur, hardware, firmware en software.
Figuur 2: Aanvalvlakcategorieën definiëren de aanvalscategorieën waarin verschillende aanvalstypen kunnen worden geïdentificeerd. Ze geven ook specifieke voorbeelden van zulke aanvalstypen. Hieronder staat een lijst met aanvalstypen en voorbeelden in elke categorie:
- Architectuur: Aanvallen als gevolg van architecturale ontwerpkeuzes. Voorbeelden zijn Meltdown en Spectre, die kunnen worden gecategoriseerd als architectuur of hardware [3] [4].
- Standaard: Aanvallen als gevolg van kwetsbaarheden in de gebruikte standaard. Een voorbeeld is Terrestrial Trunked Radio (TETRA). Delen van het gestandaardiseerde TETRA-protocol bevatten kwetsbaarheden als gevolg van overheidsbeperkingen op de gebruikte cryptografie [18].
- Hardware: Aanvallen gebaseerd op echte ontwerpkeuzes zoals Meltdown en Spectre. Andere voorbeelden zijn aanvallen gebaseerd op kwaadaardige toevoegingen aan het ontwerp in pre-concept, concept, ontwikkeling en productiefasen zoals beschreven in [3] [4] [8] [9] [19].
- Firmware: Aanvallen gebaseerd op echte ontwerpproblemen, zoals de JTAG-interface (Joint Test Action Group). Deze interface is nodig voor testen tijdens ontwikkeling en productie, en om updates te leveren tijdens ondersteuning [20] [21]. Andere voorbeelden zijn aanvallen gebaseerd op kwaadaardige toevoegingen aan het firmwareontwerp in concept-, ontwikkelings-, productie- of gebruiks-/ondersteuningsfasen, waarvan Stuxnet een voorbeeld is [22].
- Software: Aanvallen gebaseerd op echte ontwerpproblemen zoals Log4J, een OSS Java-gebaseerd logging hulpprogramma dat vaak gebruikt wordt in webapplicaties, dat meerdere kwetsbaarheden had door programmeerproblemen. Andere voorbeelden zijn aanvallen gebaseerd op kwaadaardige toevoegingen aan het ontwerp in pre-concept, concept, ontwikkeling, productie en gebruik/ondersteuningsfasen, zoals typosquatting of verwarring van afhankelijkheden [23].
- Ontwikkelomgeving: Aanvallen op gegevens en/of systemen, gebaseerd op echte ontwerpproblemen in de geleverde systemen zoals Kaseya en Solarwinds. Andere voorbeelden zijn aanvallen op basis van kwaadaardige toevoegingen in de geleverde systemen (backdoors, ransomware, trojans, virussen). Deze problemen kunnen zich ook voordoen in de productieomgeving. Op 29 maart 2024 dook een nieuwe aanvalsvector in de ontwikkelomgeving op: de menselijke factor [24].
De categorieën, inclusief aanvalstypen, worden gecombineerd met het gekozen levenscyclusmodel [15]. Dit levenscyclusmodel heeft zeven stadia, die hieronder worden beschreven. Het is belangrijk op te merken dat de stadia niet lineair zijn.
1. Pre-concept, waarbij generiek (markt)onderzoek wordt uitgevoerd om de behoeften, eisen en wensen van de klant te achterhalen.
2. Concept, waarbij een Proof Of Concept (POC) wordt ontwikkeld om de resultaten van het pre-concept onderzoek te valideren.
3. Ontwikkeling, waarbij de POC wordt ontwikkeld tot een Technological Readiness Level (TRL) voor productie.
4. Productie, waarbij het ontwikkelde systeem wordt geproduceerd en geleverd aan de klant.
5. Gebruik, waarin het systeem wordt ingezet, deze fase omvat de acceptatie en installatie.
6. Ondersteuning, waarbij het ingezette systeem in een operationele en veilige staat wordt gehouden.
7. Terugtrekking, waarbij het ingezette systeem veilig wordt vernietigd om blijvende gegevenslekkage te voorkomen.
Opmerking: de ontwikkelings- en productiefasen lopen deels parallel, en de gebruiks- en ondersteuningsfasen lopen grotendeels parallel. In de definitie van de Common Criteria standaard wordt de productiefase beschouwd als onderdeel van de familie Development Security (ALC_DVS) [12].
Voor elk aanvalstype in de lijst worden ze geprojecteerd op de levenscyclusfasen. Vervolgens worden de bijbehorende tegenmaatregelen voor elke aanval aan het model toegevoegd. Alle tegenmaatregelen worden gecategoriseerd op basis van hun toepasbaarheid op de verschillende aanvalstypen.
De combinatie van aanvallen en tegenmaatregelen levert een model op dat kan worden gebruikt voor risicoanalyse van aanvallen op de toeleveringsketen. Deze methode is een kwalitatieve methode, wat betekent dat het risico dat een aanval uitvoerbaar is niet wordt berekend. Het toont echter wel het resterende risico in de toeleveringsketen dat kan worden aanvaard of beperkt met maatregelen zoals verzekeringen. Een vereenvoudigd model wordt gepresenteerd in Figuur 3: Levenscyclus met categorieën van aanvalstypes. Deze figuur gaat uit van een ideale wereld waarin hardware eerst wordt ontwikkeld en geproduceerd. Het volledige model met de details van aanvalstypen en tegenmaatregelen is te vinden in de bijlage.
Het model werd in meerdere stappen verder uitgewerkt:
1. De oorspronkelijke lijst met aanvallen opnieuw ingedeeld in de nieuw gedefinieerde categorieën Architectuur, Standaard, Hardware, Firmware, Software, Ontwikkelomgeving. 2. De lijst met aanvallen besproken met deskundige collega's. Elke aanval geanalyseerd op essentie, zoals de entiteit die de controle heeft wanneer de aanval wordt geënsceneerd, of de aanval wordt geënsceneerd bij de controleoverdracht in de levenscyclus of toeleveringsketen (wat een kwetsbaar punt is en vaak wordt gebruikt voor het ensceneren van aanvallen).
2. De oorspronkelijke lijst met aanvallen opnieuw gecategoriseerd, gecombineerd en herschreven tot abstracte overkoepelende aanvallen in de nieuw gedefinieerde categorieën, waardoor het aantal aanvalsbeschrijvingen werd teruggebracht van 42 naar 19. Specifiekere voorbeelden beschreven van subcategorieën van aanvallen binnen de meest abstracte categorieën en deze toegeschreven aan drie verschillende probleemdomeinen die werden gedefinieerd:
1. Goedaardige (ontwerp)beslissingen die leiden tot toekomstige problemen als gevolg van onvoldoende aandacht voor, of inzicht in of kennis van mogelijke cyberbeveiligingsproblemen die voortvloeien uit die beslissingen; 2. Echte fouten in ontwerp of implementatie als gevolg van onvoldoende beveiligingsbewustzijn, gebrek aan beveiligingsexpertise of -training;
3. Kwaadaardige fouten of wijzigingen om de bedoelde functionaliteit van componenten, systemen of oplossingen te veranderen.
De aanvallen werden vervolgens in kaart gebracht in het levenscyclusmodel, zoals weergegeven in de onderstaande figuur.
Hieronder volgt een korte beschrijving van de gedefinieerde aanvallen. Het volledige model staat in de bijlage.
A01. Standaard introduceert een suboptimaal voorstel voor het item dat gestandaardiseerd wordt, wat leidt tot kwetsbaarheden die misbruikt kunnen worden.
A02. Beschrijvingen in een architectuurdocument zijn slecht uitgelegd of voor meerdere uitleg vatbaar, wat leidt tot kwetsbaarheden die verderop in de ontwikkelingsketen kunnen worden misbruikt.
A03. In een van de fasen concept, ontwikkeling, productie, gebruik, ondersteuning wordt een echt onderdeel vervangen door een nagemaakt onderdeel. Namaakonderdelen zijn doorgaans van mindere kwaliteit en kunnen dus veiligheidsproblemen veroorzaken, maar ze zijn niet noodzakelijk kwaadaardig.
A04. In een van de fasen concept, ontwikkeling, productie, gebruik, ondersteuning wordt een echt hardwareonderdeel vervangen door een kwaadwillig gewijzigd onderdeel.
A05. Tijdens de buitengebruikstelling wordt het systeem buiten gebruik gesteld op een manier die kan leiden tot het uitlekken van kritieke gegevens, architectuur of ontwerpinformatie.
A06. In een van de fasen concept, ontwikkeling, productie, gebruik, ondersteuning wordt een echt onderdeel vervangen door een vervalst onderdeel. Voor firmware is dit meestal in combinatie met vervalste hardware.
A07. In een van de fasen concept, ontwikkeling, productie, gebruik, ondersteuning wordt een authentiek firmwareonderdeel vervangen door een kwaadwillig gewijzigd onderdeel.
A08. In een van de fasen concept, ontwikkeling, productie, gebruik, ondersteuning worden een of meer echte softwarecomponenten vervangen door kwaadwillig gewijzigde componenten.
A09. Agenten met kwade bedoelingen maken gebruik van een zwakke plek in een van de ontwikkelingssystemen of subsystemen die niet op tijd is gepatcht.
A010. Kwaadaardige componenten (hardware, firmware of software) worden in de ontwikkelingssystemen geïntroduceerd.
De volgende stap was het maken van een complete set van mogelijke tegenmaatregelen. De lijst met tegenmaatregelen uit [13] werd herschikt en er werden meer tegenmaatregelen toegevoegd. Met name de maatregel van veilige vernietiging werd toegevoegd, omdat het oorspronkelijke model de uittredingsfase niet omvatte. Een voorbeeld van zo'n veilige vernietiging is data sanitization, zoals beschreven in NIST special publication SP800-88 [25].
Een aantal tegenmaatregelen werd gegroepeerd in een nieuwe generieke categorie met de naam Ontwikkelingsbeveiliging. Common Criteria definieert Development Security (ALC_DVS) als volgt [12]: "[...] alle fysieke, procedurele, personele en andere beveiligingsmaatregelen die nodig zijn om de vertrouwelijkheid en integriteit van het ontwerp en de implementatie van het [Target of Evaluation (TOE)] in zijn ontwikkelomgeving te beschermen ."
Deze definitie maakt het mogelijk om zeer concrete maatregelen te groeperen, zoals de toepassing van cryptografische technieken, netwerktoegang/verkeersbeperkingen, vertrouwd personeel en veilige opslag.
Een daadwerkelijke risicoanalyse van de levenscyclus begint met het identificeren van de levenscyclusfasen die van toepassing zijn en de aanvallen die in die fasen van toepassing zijn. Zodra de typen aanvallen en de aanvallen in detail zijn geïdentificeerd, kunnen de mogelijke tegenmaatregelen worden geïdentificeerd. Uit de mogelijke tegenmaatregelen kan een selectie worden gemaakt van realistische opties om te implementeren. De gecombineerde set van tegenmaatregelen moet in verhouding staan tot het beschermingsniveau dat nodig is. Dit niveau kan variëren naargelang de kriticiteit van de toepassing waarvoor het product is ontwikkeld.
In het nieuwe model zijn de tegenmaatregelen gekoppeld aan de fasen van de levenscyclus en aan de toepasbaarheid om een of meer specifieke aanvallen tegen te gaan. Dit wordt weergegeven in de onderstaande figuur.
Een korte beschrijving van de gedefinieerde tegenmaatregelen wordt gegeven in de onderstaande lijst. Het volledige model staat in de bijlage.
CM01. Ontwikkelingsbeveiliging: Alle fysieke, procedurele, personele en andere veiligheidsmaatregelen die nodig zijn om de Vertrouwelijkheid en Integriteit van het Ontwerp en de Implementatie van het Evaluatiedoel (TOE) in zijn ontwikkelingsomgeving te beschermen.
CM02. Visuele inspectie tijdens ontwikkeling en productie: Visuele inspectie gebruiken om vervalste onderdelen en manipulatie te detecteren in hardware, firmware, software en documentatie. CM03. Tegenmaatregelen voor de toeleveringsketen: Alle maatregelen die de toeleveringsketen zichtbaar maken en zwakke plekken en aanvalspunten in de toeleveringsketen identificeren.
CM04. Prototyping en productie: Alle maatregelen om de integriteit van TOE-onderdelen te waarborgen die worden genomen tijdens het productieproces van prototypen of definitieve TOE's.
CM05. Leveringsbeveiliging, inclusief updates tijdens ondersteuning: Alle procedures die nodig zijn om de beveiliging te handhaven bij het distribueren van versies van het TOE naar de consument.
CM06. Veilige vernietiging: Alle procedures en technieken voor de vernietiging van restinformatie. Dit kan intern gebeuren, of via een contractuele overeenkomst met gecertificeerde kennisgeving.
De tegenmaatregelen zijn input voor een stapsgewijze risicoanalyse van de toeleveringsketen:
1. Schets een levenscyclus en indien mogelijk een toeleveringsketenmodel.
2. Bepaal de van toepassing zijnde categorieën uit Figuur 2: Categorieën aanvalsoppervlak.
3. Bepaal voor de hierboven bepaalde van toepassing zijnde categorieën welke aanvallen van toepassing zijn uit de lijst in deze bijlage.
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/certificeringskader 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 TOE succesvol aan te vallen [26].
De manier waarop een tegenmaatregel wordt geïmplementeerd maakt geen deel uit van het model, aangezien dit de discretie is van de ontwikkelaar en zijn ketenpartners. Aan de tegenmaatregel Meerdere leveranciers (zie het volledige model in de bijlage) kan bijvoorbeeld worden voldaan door meerdere leveranciers te gebruiken voor één en hetzelfde component, wat de standaardoptie is in grote data- en energienetwerken. Er kan echter ook aan worden voldaan door verschillende leveranciers te kiezen voor verschillende onderdelen die cruciaal zijn voor de veiligheid.
Uit de risicoanalyse van de toeleveringsketen kan blijken dat er restrisico's overblijven, zelfs na de toepassing van alle realistische tegenmaatregelen. In dat geval moeten de belanghebbenden of de klant beslissen wat ze met het restrisico doen: risicoaanvaarding, of risicovermindering door middel van bedrijfsprocessen, in het milieu, of andere maatregelen.
Discussie en conclusies
Aanvallen in de toeleveringsketen zijn een reëel risico, vooral voor producten met een hoge betrouwbaarheid. Er zijn meerdere soorten aanvallen die in de toeleveringsketen kunnen worden geënsceneerd. Om dit probleem tegen te gaan, is risicovermindering noodzakelijk. Dit begint met een risicoanalyse, waarvoor een model voor risicoanalyse van de toeleveringsketen is ontwikkeld. Het ontwikkelde model is gebaseerd op een aantal gevestigde normen en kennisbronnen, die samen hebben geleid tot een nieuw model zoals gepresenteerd in dit artikel. Tijdens het bijwerken van het oorspronkelijke model is het nieuwe model in verschillende fasen en met verschillende groepen met expertise op dit gebied gevalideerd.
Het model biedt een basis voor risicoanalyse van de toeleveringsketen die geschikt is om mogelijke aanvallen te identificeren en kan laten zien hoe deze aanvallen met tegenmaatregelen kunnen worden beperkt. De exacte implementatie van de tegenmaatregelen maakt geen deel uit van het model.
Bijdragen
NLNCSA heeft het onderzoek gesponsord. Een aantal collega's heeft een grote bijdrage geleverd door nuttige discussies en inzichten te geven. Onze technische schrijver heeft fantastisch werk geleverd door het taalgebruik in het artikel te verbeteren.
Vind alle bronnen en de bijlage in de uitgebreide PDF-versie.