Die richtige Vorgehensweise
Alexander Matt, Product Manager Prime Cube bei Schubert System Elektronik: „Man sollte den CRA nicht nur als Belastung betrachten, sondern als Chance sehen, um Security strukturiert zu verbessern und damit langfristig bessere, robustere Produkte in den Markt zu bringen.“ (Quelle: Schubert System Elektronik)
Und wie sollte man nun konkret in der Praxis vorgehen, um Risiken realistisch zu bewerten? A. Matt: „Am besten startet man mit einem sauber definierten Intended Use. Dieser zeigt auf, in welcher Anwendung und in welcher Einsatzumgebung das Produkt betrieben wird.“ Dazu gehören nicht nur technische Rahmenbedingungen, sondern auch, wer Zugriff hat, also IT-Rollen, OT-Rollen oder externe Servicepartner. Aus diesen Punkten ergibt sich die Systemgrenze: Was gehört dazu, was liegt außerhalb und an welchen Übergängen entstehen Angriffsflächen? „Die IEC 62443 liefert gute Definitionen, zum Beispiel für einen bestimmungsgemäßen Gebrauch, also den Intended Use“, gibt er an.
Im zweiten Block geht es dann um die Systemarchitektur. Dazu werden ein Blockdiagramm erstellt, Kommunikationsbeziehungen erfasst und die relevanten Komponenten identifiziert, zum Beispiel Hardware, Software, Schnittstellen, Ports, Protokolle usw. Damit wird aus dem abstrakten „System“ eine prüfbare Struktur: „Das sind die Assets, die später geschützt und überwacht werden müssen“, so A. Matt.
Darauf aufbauend folgt die eigentliche Risikobewertung: Welche Angriffsvektoren sind plausibel, welche Eintrittswahrscheinlichkeit und welche Auswirkung sind realistisch, welche Maßnahmen sind daraus abzuleiten? „Dafür gibt es etablierte Methoden, beispielsweise STRIDE (Bedrohungsmodellierung) oder FMEA/FMECA (Fehler-/Auswirkungsanalyse). Ergänzend helfen Angriffs- und Schwachstellenkataloge, um typische Vektoren systematisch zu prüfen“, erklärt der Securityexperte. Entscheidend sei allerdings, aus der Bewertung konkrete Schutzmaßnahmen abzuleiten. Technisch können das Härtung, Segmentierung oder Zugriffskontrolle sein, organisatorisch beispielsweise Prozesse, Rollen, Reviews und im Lebenszyklus unter anderem Updates, Monitoring sowie Incident Response. „Und natürlich kann man deutlich tiefer gehen, indem man zum Beispiel die Lieferkette und Fertigung einbezieht. Je nach Kritikalität des Produkts und Einsatzumfelds erwächst daraus eine umfassende Security-Betrachtung über den gesamten Lebenszyklus“, sagt A. Matt.
Er weist aber auch darauf hin, dass trotz aller noch so guter Vorbereitung Sicherheitslücken unvermeidbar sind. „Das ist einfach Physik, denn neue Sicherheitslücken entstehen automatisch mit der Laufzeit. Beispiele hatte ich bereits genannt. Aus diesem Grund sind Security-Updates unverzichtbar, um Produkte und Anlagen über ihren Lebenszyklus sicher zu betreiben.“
Secure Boot und Secure OTA Updates
Zu den weiteren Anforderungen, die der CRA mit sich bringt, zählen Secure Boot und Secure OTA-Updates. Was hat es nun damit auf sich? A. Matt erläutert: „Der Boot-Prozess stellt die erste Sicherheitslinie dar. Mit Secure Boot bzw. Trusted Boot wird gewährleistet, dass nur autorisierte Software auf dem System startet.“ Die Voraussetzung dafür sei ein Trusted Platform Module. „Das TPM dient als geschützter Anker für Schlüsselmaterial sowie Integritätsmessungen und somit für die sichere Verwaltung der kryptografischen Grundlagen, auf denen Secure/Trusted Boot aufbaut.“ Er verweist darauf, dass häufig „TPM 2.0“ zu lesen sei, das allein jedoch noch keine Garantie für Sicherheit ist. Entscheidend seien Implementierung, Konfiguration und Firmwarestand. „Man muss sich vergewissern, dass der TPM-Chip und sein Set-up tatsächlich die Sicherheitsanforderungen erfüllen, die für belastbare Schlüsselverwaltung und Integritätsprüfungen benötigt werden.“
Im Alltag entsteht der Nutzen vor allem dann, wenn Secure bzw.Trusted Boot in eine durchgehende Schutzkette eingebettet ist. „Ein gehärteter Startvorgang allein reicht nicht, wenn Daten und Systemzustand danach ungeschützt sind. Deshalb wird Secure Boot häufig mit Datenträger- bzw. Laufwerksverschlüsselung kombiniert, zum Beispiel BitLocker. Damit ist dann nicht nur der Start vertrauenswürdig, sondern es bleiben auch Daten und Schlüsselmaterial während Betrieb und Neustart geschützt“, so A. Matt.
Security – ein fortwährender Prozess
Nach den wichtigsten Maßnahmen gefragt, die in der Praxis den entscheidenden Security-Unterschied machen, antwortet A. Matt: „Das lässt sich nicht auf eine einzelne Maßnahme reduzieren. Der größte Sicherheitsgewinn entsteht durch die Schutzkette, also das Zusammenspiel mehrerer Bausteine, die sich gegenseitig absichern.“ Die Basis bilde aber ganz klar die Update-Fähigkeit. Denn ohne Patch- und Update-Prozesse fehle die Voraussetzung, um auf neue Schwachstellen überhaupt reagieren zu können.
Darauf baut dann die Identitäts- und Rechteebene auf, inklusive sicherer Authentifizierung, sauber getrennter Nutzerrollen und eines konsequenten Berechtigungsmanagements für unterschiedliche Benutzergruppen.
Außerdem müssen Unternehmen den Spagat zwischen Absicherung und Offenheit meistern. „Daten sollen verfügbar sein und geteilt werden können, aber kontrolliert und nachvollziehbar“, sagt A. Matt und nennt als Stichwort den EU Data Act. Genau deshalb gehörten verschlüsselte Kommunikation und je nach Bedrohungsmodell auch der Schutz gegen physische Zugriffe dazu, beispielsweise über Datenträger- bzw. Speicherverschlüsselung.
In der Praxis mache außerdem die konsequente Systemhärtung einen großen Unterschied. „Angriffsflächen reduzieren, nur notwendige Dienste aktivieren, nicht benötigte Ports schließen, Schnittstellen sauber absichern. Und auch die ,einfachen‘ Dinge zählen: physische Zugänge, Einbau- und Zugriffsschutz im Schaltschrank, klare Betriebs- und Wartungsregeln“, bringt er es auf den Punkt.
Als weiteren Schlüssel führt A. Matt Logging an, um Auffälligkeiten überhaupt erkennen, nachvollziehen und bewerten zu können. „Ohne belastbare Logs bleibt Incident Response im Ernstfall blind“, meint er und fügt zusammenfassend an: „Cybersecurity ist nicht nur ein Produktmerkmal. Es umfasst immer auch Organisation, Prozesse und Menschen, und damit das Gesamtsystem im Unternehmen. Deshalb sollte man regulatorische Anforderungen wie den CRA nicht nur als Belastung betrachten. Stattdessen sollte man sie als Chance sehen, um Security strukturiert zu verbessern und damit langfristig bessere, robustere Produkte in den Markt zu bringen."