Die früher separaten Systeme der Betriebstechnologie (OT) und der IT-Infrastruktur eines Unternehmens verschmelzen immer mehr. Diese Konnektivität bringt auch mehr Bedrohungen durch böswillige digitale Akteure mit sich. Daher wird neben der funktionalen Sicherheit (Safety) auch die IT-Sicherheit (IT-Security) zu einem zwingenden Schwerpunkt. Denn Safety und Security stehen in einer komplexen Wechselwirkung. Die grundlegendste Aussage ist, dass Safety nicht ohne Security hergestellt werden kann: Ein System, das unter der Kontrolle eines Angreifers steht, muss in Bezug auf die funktionale Sicherheit als gefährdet angesehen werden. Security ist daher dringend erforderlich, um die Integrität und Verfügbarkeit von Sicherheitssystemen zu gewährleisten. Darüber hinaus müssen sensible Daten geschützt werden, da ein Datenverlust oder eine Kompromittierung ein ernsthaftes Risiko für das Unternehmen darstellen könnte.
Für die Entwickler von Steuergeräten ergibt sich mit großer Wahrscheinlichkeit auch die Forderung nach einer Sicherheitszertifizierung, wie sie im Bereich der Safety längst etabliert ist. Neben Normen wie der IEC61508, die den Entwurf von funktional sicheren Steuerungssystemen regeln, taucht die Normenreihe IEC62443 auf. Diese Reihe deckt mehrere Aspekte ab, darunter die Sicherheit der Kommunikation von Gerät zu Gerät, den Schutz sensibler Daten, die Authentizität von Anweisungen und Verfahrensrichtlinien für Gerätehersteller.
Es ist eine schwierige Aufgabe, die ständig wachsende Systemkomplexität zu bewältigen, ohne die funktionale und IT-Sicherheit zu vernachlässigen. Ein Ansatz hierfür ist die Strategie des „Teile und Herrsche“. Dahinter steht das Konzept, bestehende Modulgrenzen mit losen Kopplungen zu identifizieren. Dies können beispielsweise einzelne Prozesse eines Betriebssystems (OS) oder Anwendungen sein, die auf verschiedenen Kernen desselben Prozessors laufen.
Strikte Partitionierung für mehr Sicherheit
Durch die Partitionierung der vorhandenen Software entlang festgelegter Grenzen und das Verschieben jedes Moduls in eine eigene Partition kann eine vollständige Isolierung in Bezug auf funktionale und IT-Sicherheit erreicht werden. In den meisten Fällen ist dies jedoch kein wünschenswerter Zustand, da die verschiedenen Anwendungen miteinander kommunizieren müssen. Separationskernel bieten daher Kommunikationsmöglichkeiten wie gemeinsame Speicherbereiche und IPC-Kanäle (Interpartition Communication), die bei Bedarf aktiviert werden können.
Durch die strikte Trennung in einzelne Partitionen können sich die Anwendungen nicht gegenseitig beeinflussen, es sei denn, dies wird vom Integrator bewusst ermöglicht. So können die Auswirkungen eines Fehlers auf die Partition beschränkt werden, in der er aufgetreten ist. Darüber hinaus ermöglicht die Partitionierung die Einführung von Sicherheitsdomänen, das heißt von Teilen des Systems mit unterschiedlichen Anforderungen an das Sicherheitsniveau. Separationskernel haben in der Regel eine sehr kleine Codebasis, was die Wahrscheinlichkeit von Programmier- oder Laufzeitfehlern verringert.
Aus der Sicherheitsperspektive sind Entwürfe auf der Grundlage von Separationskernen in der Regel einer Trennung auf der Grundlage von Containern vorzuziehen, da die Containerisierung nur eine schwache Isolierung bietet. Container sind in der Regel nicht darauf ausgelegt, die Ausweitung von Privilegien durch bösartige Anwendungen zu verhindern. Im Extremfall kann eine solche Anwendung dann bis in das Host-Betriebssystem vordringen. Über einen Separationskernel kann dies zuverlässig verhindert werden.
Gemischte Kritikalität
Bei der Entwicklung von Software gibt es zwangsläufig einen Kompromiss zwischen Funktionalität und Korrektheit: Software mit vielen Funktionen wird immer komplexer und damit anfälliger für Programmierfehler sein, was die Sicherheit beeinträchtigt. Ein Entwurf mit gemischter Kritikalität zielt darauf ab, beide Ziele gleichzeitig zu erreichen, indem mehrere Teilsysteme mit unterschiedlicher Kritikalität kombiniert werden.
Ein Beispiel hierfür ist eine SPS, die auch eine Anlagenverwaltungsschale (asset administration shell ASS) und eine Webschnittstelle für die Erstkonfiguration enthält. Sowohl die AAS als auch der Webserver sind weniger kritisch als die SPS, da die funktionalen Sicherheitseigenschaften des Geräts nicht beeinträchtigt werden, wenn eine der beiden Komponenten ausfällt. Die SPS befindet sich daher in einer anderen (kritischeren) Sicherheitsdomäne. Die Cloud-Kommunikation für die Datenaggregation und -analyse kann ebenfalls in einer separaten Partition implementiert werden, so dass Angreifer nicht in der Lage sind, das Gerät über Schwachstellen im Uplink zu gefährden.
Viele Kanäle sind prinzipiell angreifbar. Das gilt sowohl für die Mensch-Maschine-Schnittstelle (HMI) als auch für die Maschine-zu-Maschine-Kommunikation (M2M) über BaSyx, OPC UA, HTTP REST, MQTT, DDS, oneM2M. Netzwerkdienste und Server vergrößern die Angriffsfläche des Geräts direkt. Da die heutigen Protokolle so leistungsfähig und damit komplex sind, steigt das Risiko kritischer Schwachstellen entsprechend.
Selektive Neuzertifizierung
Designs, die auf einem separaten Kernel basieren, ermöglichen nicht nur ein sehr hohes Maß an Sicherheit, sondern können auch die Zertifizierung vereinfachen und damit Kosten einsparen. Gerade im Bereich der Security birgt die Änderung bestimmter Eigenschaften eines Systems das Risiko, dass die Sicherheitsannahmen außer Kraft gesetzt werden und das System unsicher wird. Bei einem Feldgerät ist dies der Fall, wenn durch ein Software-Upgrade ein zusätzlicher, von außen gesteuerter Dienst installiert wird. In der Regel muss in einem solchen Fall das gesamte Gerät neu zertifiziert werden, einschließlich der Teile, die sich nicht geändert haben. Diese Tatsache erschwert die Entwicklung flexibler Geräte, die sich wirtschaftlich an neue Fertigungsbedingungen anpassen lassen.
