Schützen,Aktualisieren,Wiederherstellen

Die Bausteine für Cyberresilienz

16. August 2022, 10:52 Uhr | Nicholas (Nick) Grobelny, Jim Mann
Die Etablierung des IoTs steigert die Zahl der vernetzten und damit auch durch Cyberangriffe verwundbaren Geräte enorm. IoT-Geräte sollten sich daher vor Attacken über das Netzwerk selbst schützen können
© DIgilife/stock.adobe.com

Die Etablierung des IoT steigert die Zahl der vernetzten und damit auch durch Cyberangriffe verwundbaren Geräte enorm. IoT-Geräte sollten sich daher vor Attacken über das Netzwerk selbst schützen können. Die Trusted Computing Group hat dafür jetzt eine Spezifikation veröffentlicht.

Die Wiederherstellung eines stark beeinträchtigten Computing Device erfordert heutzutage meist manuelle Eingriffe. So muss beispielsweise eine neue Firmware oder ein neues Betriebssystem von einem externen Datenspeicher oder einem zweiten Computer geladen werden. Anschließend ist das Gerät mithilfe von Passwörtern oder anderen Anmeldedaten wieder mit dem Netzwerk zu verbinden, oft unter Bedingungen physischer Sicherheit.

Die IoT-Revolution lässt nun die Zahl der Computing Devices stark ansteigen. Die Geräte beruhen auf genau der nicht perfekten Software, die schon bislang verwendet wurde. Hinzu kommt: Eine manuelle Änderung ist meist noch weniger praktikabel oder sogar unmöglich, weil die Geräte zu zahlreich oder zu unzugänglich sind oder über keine geeignete Schnittstelle verfügen.

Alle mit dem Internet verbundenen Geräte sollten daher so konzipiert sein, dass sie sich gegen netzbasierte Angriffe selbst schützen können. Die Gerätehersteller setzen folglich eine breite Palette hardware- und softwarebasierter Schutztechnologien ein, um die Geräte sicher zu machen. Leider führen Bugs und Fehlkonfigurationen immer noch zu schädlichen Angriffen, sodass weitere Anstrengungen erforderlich sind, um sicherzustellen, dass Widerstandsfähigkeit gegen Cyberangriffe integriert ist. Die Trusted Computing Group (TCG) hat deshalb eine Spezifikation veröffentlicht, die System- und Geräteentwicklern dabei helfen soll, ihre Produkte mit Cyberresilienz auszustatten. Sie stützt sich dabei auf die Richtlinie SP 800-193 des NIST (National Institute of Standards and Technology), die drei grundlegende Aspekte für Cyberresilienz in Plattform-Firmware definiert: Schutz, Erkennung und Wiederherstellung.

Anbieter zum Thema

zu Matchmaker+

Implementierung von Cyberresilienz

Cyberresiliente Devices sind so konzipiert, dass sie netzwerkbasierten Angriffen widerstehen können. Einige benötigen externe Unterstützung, um Recovery-Maßnahmen einzuleiten, während andere die Wiederherstellung ohne Eingreifen von außen durchführen können. Geräte bestehen aus zahlreichen Komponenten und Layers, von denen jede und jeder einzelne gefährdet sein kann. Schutz, Erkennung, Aktualisierung und Wiederherstellung sind grundlegende Fähigkeiten eines resilienten Systems, die jetzt zu »Building Blocks« werden. Um die Implementierung von Cyberresilienz zu vereinfachen, kombiniert die jüngste Spezifikation »Cyber Resilient Module and Building Block Requirements« (CyRes) der TCG die Building Blocks zu einer abstrakten Computing-Komponente namens Cyber Resilient Module (CRM).

Die cyberresilienten Building Blocks werden in einem Modul verwendet, um Anwendungen oder Geschäftsmodellen eine sichere Basis zu bieten. In der CyRes-Spezifikation werden die Anwendungen oder Geschäftsmodelle als Resilience Targets (RT) bezeichnet. Im Grunde bedeutet dies, dass ein CRM die Building Blocks nutzt, um sich selbst und seine RT vor potenziell fehlerhaftem Code oder manipulierter Logik zu schützen und gegebenenfalls wiederherzustellen. Die CyRes-Spezifikation enthält eine Bibliothek von Building-Block-Stammfunktionen, die Ressourcen für den Lese- und Schreibschutz persistenter Speicher, die Einleitung von Recovery-Maßnahmen bei einem Ausfall oder einer Beeinträchtigung sowie die Isolation von Recovery-Funktionen potenziell beeinträchtigter RT bieten.

Widerstandsfähigkeit und Wiederherstellung
Ein einzelnes Cyber Resilient Device kann aus einem oder mehreren CRMs bestehen. Die Spezifikation ist daher für eine Vielzahl von Computing-Umgebungen relevant, etwa:

➔ CPUs, Mikrocontroller oder SoCs
➔  Speicher- und Peripherie-Device-Controller (sowohl diskret als auch integriert)
➔  Programmierbare Logikbausteine, programmierbare ASICs
➔  Sicherheits-Coprozessoren wie Trusted Platform Modules (TPMs)

Die CyRes-Spezifikation ermöglicht auch einen Lese- und Schreibschutz mit Building Blocks, die als Read Protection Latches (RPLs) und Write Protection Latches (WPLs) bezeichnet werden. Diese können weitgehend konfigurierbar sein oder so einfach und statisch sein, wie es zum Schutz von sensiblem Code und sensibler Daten innerhalb eines Moduls erforderlich ist. Zur Erkennung von Fehlern und zur Recovery-Automatisierung spezifiziert CyRes Watchdog-Fähigkeiten, genannt Watchdog Counters (WCs). Definiert sind verschiedene Formen von WCs, die je nach den spezifischen Anforderungen des Moduls ausgewählt werden können. Die besonderen Eigenschaften des »Latchable WC« und des »Authorized Deferral WC« ermöglichen es den Modulen, gegen gängige Angriffe auf herkömmliche Counters resistent zu sein, etwa Deaktivieren und Zurück- setzen sowie die Manipulation mit Counter Values, um die Recovery-Vorgänge zu stören.

Bei einem solchen Modul kann es sich um ein ganzes SoC handeln, das in ein IoT-Device integriert ist, oder um einen Mikrocontroller oder SoC-Baustein innerhalb einer Komponente, die dann in ein größeres, komplexeres Gerät eingebaut wird. Wenn der SoC-Baustein oder die Mikrocontroller mehrere Code- und Konfigurationsschichten aufweisen, könnten beispielsweise die erste und zweite Schicht ein CRM und die zweite und dritte Schicht ein weiteres Modul sein.

Aufrechterhaltung der Stabilität

Das Minimum an Fähigkeiten eines CRM hängt von den Bedrohungsannahmen und der geplanten Anwendung für ein bestimmtes Modul ab, wobei erwartet wird, dass Entwickler die zu implementierenden Building Blocks je nach den Anforderungen ihrer Architekturen auswählen. Die CyRes-Spezifikation definiert ein Minimum an Fähigkeiten oder Mechanismen, das es ermöglicht, selbst am untersten Ende des Kosten-/Leistungs-/Komplexitätsspektrums Cyber Resilient Devices zu bauen. Die Fähigkeiten sind so konzipiert, dass sie sowohl einfach zu implementieren als auch einfach zu nutzen sind. Die Einfachheit verringert dabei die Wahrscheinlichkeit, dass die sicherheitskritischen Komponenten der Cyber Resilient Devices angreifbar sind, während zugleich die Kosten, der Stromverbrauch und die Größe der Hardware minimiert werden.

In sehr einfachen Mikrocontroller-Architekturen mit geringer Komplexität benötigt ein Modul möglicherweise nur einen Schreibschutz für den Früh-Boot-Code und sonst nichts. Bei höherer Komplexität kann sich eine Architektur für die Nutzung eines per Fernzugriff aktualisierten Authorized Deferral WCs entscheiden. Dies würde es einer entfernten oder externen Instanz, die als Resilience Authority (RA) bezeichnet wird, ermöglichen, die Stabilität des Moduls von fern sicherzustellen, solange eine Verbindung aufrechterhalten werden kann, um zu verhindern, dass die Watchdog Counters ungültig werden und das Modul zurücksetzen.

Das Diagramm stellt den generellen Betriebsablauf der Architekturelemente dar, aus denen ein CRM besteht
Bild 1: Das Diagramm stellt den generellen Betriebsablauf der Architekturelemente dar, aus denen ein CRM besteht.
© Trusted Computing Group

Dies schließt IoT-Geräte und Mikrocontroller mit ein, die in einem breiten Spektrum von Anwendungen eingesetzt werden. Unterstützt werden auch komplexere Geräte, indem unabhängigen Subkomponenten von Geräten, die direkt oder indirekt mit einem Netzwerk verbunden sein können, Cyberresilienz verliehen wird. Um sich von einer Kompromittierung zu erholen, muss ein Gerät möglicherweise gewartet werden (durch Patches oder Wiederherstellung), was den Code und die Konfiguration einer oder mehrerer Komponenten und/oder Layers betrifft. Um die Wartungsmöglichkeiten so allgemein zu gestalten, dass sie auf viele verschiedene Komponenten und Layers anwendbar sind, definiert die CyRes-Spezifikation ein abstraktes CRM, das eine Reihe von Fähigkeiten bietet, die zusammenfassend als »Resilience Engine« (RE) bezeichnet werden. Die RE ist verantwortlich für die sichere Konfiguration der Building Blocks in einem CRM und für die Wartung (d. h. Reparatur oder Aktualisierung) des Resilience Targets. Der allgemeine Betriebsablauf der Architekturelemente, aus denen sich ein CRM zusammensetzt, ist in Bild 1 dargestellt.

 Das Diagramm zeigt, wie ein RA, ein RE und cyberresiliente Building Blocks zusammenarbeiten, um Stabilität für ein Resilience Target sicherzustellen
Bild 2: Das Diagramm zeigt, wie ein RA, ein RE und cyberresiliente Building Blocks zusammenarbeiten, um Stabilität für ein Resilience Target sicherzustellen.
© Trusted Computing Group

Die RE wird durch die Einrichtung eines Lese- und Schreibschutzes für empfindliche Codes oder Daten vervollständigt, während zugleich automatische Überwachungsfunktionen auf Counter-Basis eingerichtet werden, die das Zurücksetzen, die Wiederherstellung und die Rückkehr zu einem stabilen Betriebszustand unterstützen, falls das Resilience Target instabil wird oder nicht mehr reagiert. Die CyRes-Spezifikation definiert auch eine Vielzahl spezieller Typen von Counter-Building-Blocks, die zusätzlich an eine RA gekoppelt werden können und deren Hauptfunktion darin besteht, die Watchdogs aufrechtzuerhalten, solange das CRM stabil ist und normal funktioniert. Bild 2 ist eine abstrakte Darstellung, wie ein RA, ein RE und cyberresiliente Building Blocks zusammenarbeiten, um die Stabilität eines Resilience Targets sicherzustellen.

Aufbau eines widerstandsfähigen Systems

Nicholas Grobelny von Trusted Computing Group
Nicholas (Nick) Grobelny - Technical Staff, Engineering Technologist bei Dell Technologies & TCG CyRes Working Group.
© Trusted Computing Group

Die Vorgaben und Empfehlungen in der TCG-Spezifikation können dazu dienen, den untersten Layer zu schützen und dessen Fähigkeit zur Wiederherstellung des darüber liegenden Layers zu stärken. Das CRM-Konzept lässt sich für jeden nachfolgenden Layer und für Komponenten wiederholt anwenden, um die Wiederherstellung für fast jeden Layer und jede Komponente in einem Gerät (außer dem untersten Layer) zu unterstützen. Die Engine und die Resilience-Target-Architektur können aufeinanderfolgende Layers induktiv schützen und wiederherstellen.

Jim Mann von Trusted Computing Group
Jim Mann - TCG Invited Expert, TCG CyRes Working Group.
© Trusted Computing Group

Modulentwickler und -hersteller können sich die Spezifikation zunutze machen, indem sie die benötigten cyberresilienten Building Blocks auswählen, um ebenso leichte wie robuste Mikrocontroller-Designs zu erstellen. Die Spezifikation hilft bei der Identifizierung einer Reihe grundlegender Funktionen, die Systementwicklern eine stabile Plattform für die Entwicklung von Anwendungen und Geschäftsmodellen bieten und zugleich so oft wie nötig aktualisierbar sind. Indem Ingenieure die von der TCG definierten cyberresilienten Building Blocks einbeziehen, die auf die Erfordernisse und die Architektur ihrer Module und Geräte abgestimmt sind, können sie Systeme entwickeln, die gegen Angriffe auf Netzwerkbasis widerstandsfähiger sind.


Verwandte Artikel

WEKA FACHMEDIEN GmbH