Multiprotokoll-SoCs als Security-Basis

Cybersecurity schon im Netzwerk-Controller

14. Juli 2022, 15:41 Uhr | Dirk Fischer
Dirk Fischer, Product Manager Software bei Hilscher
Dirk Fischer ist Product Manager Software bei Hilscher.
© Hilscher

Die Verknüpfung von IT- und OT-Netzen macht eine lückenlose Cybersecurity-Strategie für den Factory Floor immer dringlicher. Als deren Basis können mittlerweile SoCs wie etwa der Kommunikations-Controller netX 90 von Hilscher dienen. Doch welche Rolle spielen und welche Aufgaben erfüllen sie dabei?

Es begann mit harmlosen E-Mails, die an ausgewählte Mitarbeiterinnen und Mitarbeiter eines Stahlwerks gesendet wurden. Die E-Mails waren mit konkreten Informationen zu Arbeitsumfeld oder -inhalten perfekt auf die jeweiligen Empfänger abgestimmt, wodurch sie im normalen Arbeitsalltag kaum auffielen. Doch die E-Mails waren Teil eines perfiden Angriffsplans auf ein deutsches Industrieunternehmen.

Im Falle des Angriffs auf das betroffene Stahlwerk »erlangten Angreifer initialen Zugriff auf das Büronetz« mithilfe eines Spear-Phishing-Angriffs, schrieb das Bundesamt für Sicherheit in der Informationstechnik (BSI) in seinem Jahresbericht von 2014. Von dort arbeiteten sich die Angreifer »sukzessive bis in die Produktionsnetze« vor. Als Folge konnte ein Hochofen der Anlage nicht ordnungsgemäß heruntergefahren werden, was zu »massiven Beschädigungen« führte.

Der Vorfall ist acht Jahre her; in der Zwischenzeit dürfte sich die Bedrohungslage allerdings weiter verschärft haben. Hauptgrund dafür ist die mit der fortschreitenden Digitalisierung von Anlagen zunehmende Konvergenz von Informations- und Betriebstechnologie.

Reine Abschottung von Systemen reicht nicht aus

Die Informationstechnologie (IT) ließ sich lange Zeit klar von der Betriebstechnologie (OT) abgrenzen. Während auf der IT-Seite gängige Sicherheitskonzepte und Werkzeuge angewandt werden, fehlen solche auf OT-Seite weitestgehend. Gründe dafür sind die heterogene Natur der Anlagen, eingebettete Systeme mit stark limitierten Ressourcen sowie lange Wartungsintervalle. Man setzte hier auf Abschottung durch Firewalls und eine möglichst kleine Anzahl von Schnittstellen. Der Zugriff auf Daten der Betriebsebene war vom Firmennetz aus üblicherweise nicht möglich und schon gar nicht von außerhalb, etwa über das Internet.

Doch hilft Abschottung zwar dabei, Risiken zu reduzieren, löst das Problem aber nicht grundlegend. Denn sie schützt beispielsweise nicht vor der Installation kompromittierter Geräte durch Mitarbeiter oder der unabsichtlichen Nutzung von USB-Sticks mit versteckter Schadsoftware hinter der Firewall.

Konvergenz bringt Vorteile, birgt aber auch Risiken

Die verschwimmende Grenze zwischen IT- und OT-Netz sowie die Schaffung neuer Schnittstellen und Zugänge zur Feldebene erhöhen die Transparenz und Sichtbarkeit der Fertigungsprozesse. Dadurch ermöglichen neue Technologien unter anderem eine größere Produktivität und neue Geschäftsmodelle, wenn Applikationen in der Cloud direkt auf die Feldebene zugreifen können.

Anlagenbetreiber wollen diese Vorteile nutzen, müssen dabei aber die Risiken beachten und minimieren, die damit einhergehen. Die Betriebstechnologie muss sicher werden, um zu verhindern, dass Betrüger transparente Prozesse und den besseren Zugriff darauf ausnutzen. Damit steigt der Druck auf Anbieter von Feldgeräten, ihre Produkte mit Cybersecurity-Funktionen auszustatten.

Standards helfen bei neuen Herausforderungen

Um die Cybersecurity-Anforderungen an Feldgeräte zu vereinheitlichen, wurde in den letzten Jahren der Standard IEC 62443 entwickelt. Es handelt sich um ein aus 14 Teilen bestehendes Werk, das Automatisierungsanlagen umfassend betrachtet. Hierbei werden die verschiedenen Rollen, darunter Betreiber, Systemintegratoren und Komponentenhersteller, sowie der gesamte Lebenszyklus von Automatisierungssystemen berücksichtigt. Sowohl Entwicklungsprozesse als auch technische Funktionen sind in dem Standard definiert.

Anlagenbetreiber werden zunehmend die Erfüllung der im IEC-62443-Standard definierten Anforderungen von Komponentenherstellern einfordern. Diese müssen ihre Geräte entsprechend entwickeln und ausstatten.

Sichere Hardware ist die Basis

Blockschaltbild des netX 90 mit Hervorhebung von Cryptocore
Blockschaltbild des netX 90 mit Hervorhebung von Cryptocore
© Hilscher

Eine Voraussetzung dafür ist geeignete Hardware. Beim Kommunikations-Controller netX 90 von Hilscher wurden solche Anforderungen bereits in der Konzeptphase berücksichtigt und entsprechende Funktionen implementiert.

Die netX-Familie und der netX 90 als neuestes Mitglied dienen dazu, Geräte an industrielles Echtzeit-Ethernet und traditionelle Feldbusse anzubinden. Die Kommunikations-Ports der netX-SoCs lassen sich flexibel für jedes relevante Industrieprotokoll konfigurieren; ein einfaches Umladen der Protokoll-Firmware reicht dabei aus. Neben der netX-Hardware liefert Hilscher die Protokoll-Firmware in unterschiedlichsten Varianten, sowohl als Master- als auch als Slave-Version. Dazu zählen Profinet, EtherNet/IP und EtherCAT, aber auch weniger verbreitete Systeme wie Modbus TCP, CC-Link IE Field, Sercos III und auch Feldbusse wie Profibus oder DeviceNet.

Wie eingangs beschrieben, reicht es aber nicht mehr aus, die Prozessdaten zwischen Gerät und Steuerung zuverlässig zu übertragen. Die Daten sind auch geschützt auszutauschen, also sicher vor Manipulation und vor Mitlesen durch Dritte. Zudem müssen Geräte selbst vor Manipulation, etwa der unautorisierten Installation von Firmware, geschützt werden und sich gegenüber anderen Teilnehmern als vertrauenswürdiges Gerät ausweisen.

Cryptocore beschleunigt sicherheitsrelevante Algorithmen

Herzstück der Sicherheitsfunktionen des netX 90 ist der Cryptocore. Hierbei handelt es sich um einen Hardwareblock, der kryptografische Algorithmen signifikant beschleunigt. Besonders bei der Ver- und Entschlüsselung zyklischer Prozessdaten ist eine Hardwarebeschleunigung obligatorisch, um die negativen Auswirkungen auf die Performance, in diesem Fall die Zykluszeit, klein zu halten. Die Verschlüsselung größerer Datenmengen erfolgt üblicherweise mit symmetrischen Blockchiffre-Verfahren wie Advanced Encryption Standard (AES). Bei Schlüssellängen von 256 Bit beschleunigt die Hardware diesen Algorithmus mindestens um den Faktor 15 gegenüber einer reinen Berechnung durch die CPU. Für die Authentifizierung von Teilnehmern, Signierung von Nachrichten und Etablierung einer sicheren Verbindung werden asymmetrische Verschlüsselungsverfahren verwendet. Anstatt eines gemeinsamen Sicherheitsschlüssels, wie er bei symmetrischen Verfahren genutzt wird, kommt hier ein Schlüsselpaar aus privatem und öffentlichem Schlüssel zum Einsatz. Solche Verfahren sind noch rechenaufwendiger. Der Cryptocore des netX 90 bietet Unterstützung für die verbreiteten Verfahren RSA (Rivest-Shamir-Adleman) und ECC (Elliptic Curve Cryptography). Daneben gibt es weitere Hilfsfunktionen wie einen True-Random-Number-Generator und SHA sowie MD5-Hash-Wert-Berechnung in der Hardware.

Damit steht der Software zunächst ein Hardware-Funktions-Baukasten zur Verfügung, der noch in konkrete Sicherheitsmerkmale umgesetzt werden muss.

Zielgerichteter Einsatz von Hard- und Software

Blockdiagramm der ladbaren Firmware
Blockdiagramm der ladbaren Firmware
© Hilscher

Secure Boot ist ein solches Merkmal; es wird vom ROM-Code gewährleistet und gehört damit zu den hardwarenahen Funktionen. Nach einem Power-On oder Reset übernimmt zunächst der fest eingebaute, unveränderliche ROM-Code die Kontrolle. Er überprüft die Integrität der Firmware aus dem internen Flash-Speicher, bevor die Firmware gestartet wird. Als Vertrauensanker (root of trust) dient dabei ein öffentlicher Schlüssel (public key), der vom Gerätehersteller in einem sicheren, geschützten Bereich des Flash-Speichers installiert wird. Die Firmware wird mittels eines privaten Schlüssels (private key) des Geräteherstellers signiert. Während des Bootvorgangs nutzt der ROM-Code den öffentlichen Schlüssel und die Signatur der Firmware, um deren Authentizität und Integrität zu prüfen.

Die Absicherung der Kommunikation auf der Feldebene erfolgt mittels bewährter Verfahren aus der Informationstechnologie. Transport Layer Security (TLS) etwa kommt bei fast allen Webservern zum Einsatz, um per HTTPS verschlüsselte Kommunikation zwischen dem Client, in diesem Fall einem Webbrowser, und einer Website zu ermöglichen. Genau die gleiche Technologie wird auch bei der Kommunikation über EtherNet/IP zwischen Feldgeräten und der Steuerung genutzt.

Hilscher verwendet in seiner EtherNet/IP-CIP-Security-Protokoll-Firmware die mbed-TLS-Implementierung. Diese lässt sich als Security-Software-Baukasten betrachten, der über dem TCP/IP-Stack platziert ist und Hardware-Funktionen des Cryptocores nutzt.

Im Wesentlichen werden mit Hilfe dieser zentralen Software-Komponente drei Aspekte sichergestellt:

• Der Verbindungsaufbau erfolgt nur mit vertrauenswürdigen Geräten. Geräte müssen sich gegenseitig authentifizieren.

• Die Integrität der ausgetauschten Daten wird sichergestellt. Manipulation von Daten wird somit erkannt, und Gegenmaßnahmen lassen sich ergreifen.

• Daten können bei Bedarf verschlüsselt werden. Somit lassen sich auch vertrauliche, geheime Informationen auf Feldebene austauschen.

All diese Aufgaben übernimmt dabei die Protokoll-Firmware. Anwender müssen sich auf der Applikationsseite nicht darum kümmern.

Die oben genannten Merkmale setzen das Vorhandensein digitaler Sicherheits-Zertifikate voraus. In ihnen sind unter anderem hinterlegt: die Identität eines Geräts oder Nutzers, ein öffentlicher Schlüssel und eine Signatur, die die Authentizität des Zertifikats sicherstellt.

Zertifikatverwaltung per Authentication Manager

Die Verwaltung der Zertifikate übernimmt eine eigene Software-Komponente innerhalb der Protokoll-Firmware, der Authentication Manager. Über die Nutzerschnittstelle lassen sich Zertifikate und private Schlüssel von außen in das Gerät übertragen oder direkt im Gerät erzeugen. Einfache Anwendungsfälle wie die Nutzung von Self-Signed-Zertifikaten oder die Einbindung in eine externe Public-Key-Infrastruktur (PKI) sind somit realisierbar. Außerdem werden die protokollspezifischen Zertifikat-Deployment-Mechanismen unterstützt.

Ein zweiter Funktionsbereich des Authentication Managers ist eine rollenbasierte Nutzerverwaltung. Sie kann beispielsweise vom Webserver benutzt werden, um den Zugriff auf einzelne Seiten für bestimmte Nutzergruppen einzuschränken.

Sicher mit dem netX 90

Die Implementierung von Sicherheitsmerkmalen ist mit Aufwand und damit Kosten verbunden, ohne dabei neue, produktive Funktionen zu realisieren. Viele Gerätehersteller scheuen deshalb noch den Einstieg in das Thema. Doch sie werden umdenken müssen. In Anbetracht der hohen Risiken und Kosten, die bei Vorfällen wie dem eingangs beschriebenen Hacker-Angriff auf ein Stahlwerk auftreten, fordern Anlagenbetreiber zunehmend die Erfüllung von IEC-62443-Anforderungen. Der netX 90 mit seiner Security-Firmware ist angetreten, um die Hürden für Gerätehersteller aus dem Weg zu räumen.

 

Der Autor:
Dirk Fischer ist Product Manager Software bei Hilscher.


Verwandte Artikel

HILSCHER Ges. für Systemautomation mbH

Safety & Security