Wat is Secure Boot?
Secure Boot is een beveiligingsmechanisme waarbij een apparaat bij elke start de digitale handtekening van firmware, bootloader en besturingssysteem controleert en alleen code uitvoert die is ondertekend door een vertrouwde partij. Zo kan gemanipuleerde of kwaadaardige code zich niet nestelen vóórdat het besturingssysteem of de besturingssoftware draait, het moment waarop antivirus en monitoring nog niets zien. In OT-omgevingen beschermt Secure Boot PLC’s, HMI’s, industriële pc’s (IPC) en embedded apparaten tegen persistente malware via opstartbare media of aangepaste firmware.
🧠 Hoe werkt Secure Boot?
Secure Boot bouwt een keten van vertrouwen (chain of trust). Elke schakel controleert de volgende voordat die mag starten:
- Root of trust - een onveranderlijk startpunt, bijvoorbeeld boot-ROM-code in de processor met een hash van de publieke sleutel in eenmalig programmeerbare fuses, of een secure element.
- Firmware of UEFI - de root of trust verifieert de handtekening van de platformfirmware.
- Bootloader - de firmware controleert de bootloader tegen een lijst met toegestane sleutels.
- Kernel en drivers - de bootloader laadt alleen een ondertekende kernel; het besturingssysteem kan daarna eisen dat drivers ook ondertekend zijn.
- Weigering - faalt een controle, dan stopt het apparaat of valt het terug op een herstelimage. Er draait geen ongeautoriseerde code.
Secure Boot zelf houdt geen logboek bij van wat er is gestart. Dat doet measured boot: elke stap wordt gehasht en vastgelegd in een Trusted Platform Module (TPM), zodat een server later kan controleren of het apparaat schoon is opgestart.
🔧 Hoe werkt UEFI Secure Boot op industriële pc’s?
Op x86-systemen zoals engineering stations, SCADA-servers en panel-pc’s is Secure Boot vastgelegd in de UEFI-specificatie (sinds versie 2.3.1). De firmware beheert vier sleuteldatabases:
| Database | Inhoud | Wie mag wijzigen |
|---|---|---|
| PK (Platform Key) | De eigenaarssleutel van het platform | Alleen de houder van de PK |
| KEK (Key Exchange Key) | Sleutels die db en dbx mogen bijwerken | Houder van de PK |
| db | Toegestane certificaten en hashes van bootloaders | Houder van een KEK |
| dbx | Ingetrokken certificaten en hashes (blokkeerlijst) | Houder van een KEK |
Een image start alleen als het in db staat en niet in dbx. Op de meeste pc’s staan Microsoft-certificaten in KEK en db. Linux start via een door Microsoft ondertekende shim, die eigen sleutels (Machine Owner Keys) kan toevoegen. Windows 11 vereist een pc die UEFI Secure Boot ondersteunt, naast TPM 2.0.
Actueel aandachtspunt: de Microsoft-certificaten uit 2011 verlopen in 2026. De KEK CA 2011 verliep op 24 juni 2026, de UEFI CA 2011 op 27 juni 2026 en de Windows Production PCA 2011 verloopt op 19 oktober 2026. Apparaten zonder de opvolgers uit 2023 blijven opstarten, maar krijgen geen nieuwe dbx-updates en boot-beveiligingsupdates meer. Voor OT-pc’s die zelden een firmware-update krijgen, is dat een concreet patchmanagement-punt.
🏭 Waar is Secure Boot relevant in OT?
| Component | Secure Boot-toepassing | Praktijkpunt |
|---|---|---|
| PLC / RTU | Alleen originele, gevalideerde firmware start | Vaak afhankelijk van hardwareversie, niet van firmware |
| HMI / panel-pc | Voorkomt rootkits of gemanipuleerde OS-images | Controleer of Secure Boot in de UEFI aanstaat |
| Engineering Station | Beschermt tegen besmette opstartmedia en onbetrouwbare drivers | Combineer met BitLocker en TPM |
| Historian / SCADA-server | UEFI Secure Boot en TPM in Windows- of Linux-omgevingen | Let op certificaatvernieuwing en virtualisatie |
| Edge devices / IIoT | Verificatie van firmware bij elke herstart of update op afstand | Vraag de leverancier naar de root of trust |
Een praktijkvoorbeeld: in januari 2023 meldde Siemens (advisory SSA-482757, CVE-2022-38773) dat bepaalde S7-1500-CPU’s geen onveranderlijke hardware-root-of-trust hebben. Iemand met fysieke toegang kon het boot-image vervangen. Een softwarepatch kon dat niet oplossen. Siemens bracht nieuwe hardwareversies uit met een nieuw secure-boot-mechanisme en adviseerde voor oudere exemplaren om fysieke toegang te beperken.
🔄 Wat is het verschil met Firmware Signing en Code Signing?
| Maatregel | Wanneer gecontroleerd | Wat het tegenhoudt |
|---|---|---|
| Firmware Signing | Bij installatie of update | Ongeautoriseerde firmware die wordt geïnstalleerd |
| Code Signing | Bij installatie of uitvoering van software | Gemanipuleerde applicaties en drivers |
| Secure Boot | Bij elke start | Gewijzigde code die al op het apparaat staat |
| Measured boot + TPM | Bij elke start, achteraf te controleren | Niets zelf, maar maakt afwijkingen aantoonbaar |
De maatregelen zijn complementair: signing bepaalt wat geïnstalleerd mag worden, Secure Boot bepaalt wat uitgevoerd mag worden. Zonder Secure Boot kan een aanvaller met schrijftoegang tot het opslagmedium een ondertekende update omzeilen door de bestanden direct te vervangen.
🔐 Wat zeggen IEC 62443 en de Cyber Resilience Act?
- IEC 62443-4-2 - componenteis CR 3.14 Integrity of the boot process vraagt dat een apparaat de integriteit van firmware en software tijdens het opstarten controleert; de versterking RE(1) vraagt ook de authenticiteit te verifiëren. CR 3.12 en CR 3.13 gaan over het veilig inrichten van de roots of trust van leverancier en eigenaar.
- IEC 62443-3-3 - op systeemniveau valt dit onder SR 3.4 Software and information integrity, binnen FR 3 Systeemintegriteit.
- Cyber Resilience Act - bijlage I vraagt fabrikanten de integriteit van programma’s, opdrachten en configuratie te beschermen tegen ongeautoriseerde wijziging en producten secure by default te leveren. De meldplicht geldt vanaf 11 september 2026, volledige toepassing vanaf 11 december 2027.
- NIST SP 800-193 - de Amerikaanse richtlijn voor Platform Firmware Resiliency (2018) gaat verder dan Secure Boot: beschermen, detecteren en herstellen van firmware.
Binnen het CSIR-model valt Secure Boot primair onder VSE (systeemtechnische maatregel op firmwareniveau), met VSP als ondersteunend beleid voor firmware-integriteit.
⚠️ Welke beperkingen en aanvallen moet u kennen?
- Alleen opstartmoment - Secure Boot controleert code bij het laden, niet tijdens bedrijf. Een implantaat dat in het geheugen van een draaiende controller wordt geladen, zoals bij TRITON in 2017, ontsnapt eraan.
- Gepatcht maar niet ingetrokken - de BlackLotus-bootkit misbruikte in 2022 en 2023 de kwetsbaarheid CVE-2022-21894 in oude Windows-bootmanagers die al gepatcht waren, maar nog niet in de dbx stonden. Microsoft volgde in mei 2023 met CVE-2023-24932, waarvan de intrekking aanvankelijk handmatig moest worden geactiveerd.
- Zwakke sleutels - bij PKfail (2024) bleken veel UEFI-apparaten nog een AMI-testsleutel met het label “DO NOT TRUST” als Platform Key te gebruiken.
- Oudere apparatuur - veel bestaande PLC’s en panel-pc’s ondersteunen geen Secure Boot; dan helpen alleen compenserende maatregelen.
- Foutieve configuratie - een verkeerd toegepaste dbx-update of sleutelwijziging kan ook legitieme bootloaders en updates blokkeren. Bovendien werkt Secure Boot alleen als de leverancier zijn firmware en software daadwerkelijk cryptografisch ondertekent.
- Uitgeschakeld voor gemak - Secure Boot staat op industriële pc’s soms uit vanwege oude drivers of USB-opstartmedia van leveranciers.
🎯 Hoe voert u Secure Boot in een OT-omgeving in?
- Inventariseer - leg per apparaat in de asset inventory vast of Secure Boot wordt ondersteund en aanstaat, en welke hardwareversie het heeft.
- Test vooraf - schakel Secure Boot eerst in op een testsysteem; oude drivers en vendor-tools kunnen weigeren te starten.
- Beheer sleutels en certificaten - houd de Microsoft-certificaatvernieuwing en dbx-updates bij via change management.
- Combineer met TPM en schijfversleuteling - measured boot maakt afwijkingen zichtbaar, versleuteling beschermt tegen uitlezen.
- Stel eisen aan leveranciers - neem CR 3.14 op in de inkoopeisen en vraag naar de root of trust en het sleutelbeheer (leveranciersbeveiliging).
- Vergrendel de UEFI - zet een UEFI-wachtwoord en schakel opstarten vanaf USB uit als onderdeel van hardening.
Secure Boot is zo één laag binnen defense in depth, naast segmentatie, toegangsbeheer en security by design.
❓ Veelgestelde vragen
Is Secure Boot hetzelfde als een TPM?
Nee, Secure Boot en een TPM vullen elkaar aan. Secure Boot blokkeert het starten van niet-ondertekende code, terwijl een Trusted Platform Module vastlegt wat er is gestart (measured boot) en sleutels alleen vrijgeeft bij een schone opstart.
Beschermt Secure Boot tegen ransomware?
Secure Boot beschermt alleen tegen code die zich in de opstartketen nestelt, zoals bootkits en rootkits. Ransomware die na het opstarten als gewone applicatie draait, wordt niet door Secure Boot tegengehouden; daarvoor zijn patching, segmentatie en back-ups nodig.
Wat gebeurt er als de Microsoft Secure Boot-certificaten uit 2011 verlopen?
Pc’s met alleen de 2011-certificaten blijven gewoon opstarten. Ze kunnen echter geen nieuwe dbx-intrekkingen en boot-beveiligingsupdates meer ontvangen, waardoor nieuw ontdekte bootkits niet meer worden geblokkeerd.
Kan ik Secure Boot achteraf op een bestaande PLC inschakelen?
Meestal niet, omdat Secure Boot op een PLC een hardwarematige root of trust vereist. Bij de Siemens S7-1500 loste alleen een nieuwe hardwareversie het ontbreken van die root of trust op; voor oudere apparaten blijven fysieke afscherming en netwerksegmentatie de belangrijkste maatregelen.
Welke IEC 62443-eis gaat over Secure Boot?
In IEC 62443-4-2 gaat componenteis CR 3.14 over de integriteit van het opstartproces, met RE(1) voor de authenticiteit ervan. Op systeemniveau sluit Secure Boot aan op SR 3.4 uit IEC 62443-3-3, software- en informatie-integriteit.
Werkt Secure Boot op virtuele machines?
Ja, moderne hypervisors bieden UEFI-firmware met Secure Boot en een virtuele TPM voor virtuele machines. Voor gevirtualiseerde SCADA- en historian-servers moet u de certificaatvernieuwing dan op hypervisor- én VM-niveau controleren.
📌 Samengevat
Secure Boot zorgt dat een apparaat bij elke start alleen ondertekende, vertrouwde firmware en software uitvoert, en vormt daarmee de basis onder de integriteit van PLC’s, HMI’s en industriële pc’s.
Het werkt via een keten van vertrouwen vanaf een onveranderlijke root of trust. Combineer het met firmware signing, een TPM, actueel certificaatbeheer en patchmanagement. Secure Boot stopt geen aanvallen tijdens bedrijf, en apparaten met fysieke of externe toegang hebben aanvullende maatregelen nodig. Het blijft dus één laag in een bredere OT-verdediging.