Security-Maßnahmen auf Feldbussen

Zuverlässige Kommunikation: Ein sicherer Kanal schützt die Daten­übertragung und beeinträchtigt nicht die Kommunikation von Drittgeräten.

© Infoteam Software

Zur Best Practice gehört es, ein System vor möglichem Bedrohungspotenzial innerhalb der Office-IT zu schützen. Das umfasst im Regelfall die Cloud- und Internetverbindungen. Doch wie sieht es mit der weiteren Umgebung im Bereich des Industrial Ethernets und damit den Feldbussen aus? Und wie lassen sich Feldgeräte beziehungsweise Sensoren in Industrieanlagen effektiv schützen? Ausgehend von der Norm IEC 62443, fordert die Strategie ‚Defence in Depth‘, alle Komponenten einzeln (und den Verbund) zu schützen.

Die Schutzstrategie für industrielle Steuerungen und deren gesteuerte Geräte zielt primär auf den Schutz der Identität ab. Man spricht von Authentifizierung, wenn neben der eindeutigen Identifizierung die Befugnisse des Partners geprüft werden. Jede Ausführung einer solchen Funktion benötigt allerdings zusätzliche Rechenzeit, wodurch die gesamte Kommunikation anspruchsvoller wird. Auf Effizienz optimierte Systeme haben wenig freie Kapazitäten, deshalb benötigen sie eine Methode, mit geringem Aufwand eine stabile Basis an Sicherheit zu ­ermöglichen.

Schnelle Reaktion auf Exploits und trotzdem zertifiziert funktional sicher. Dank Plug & Play sind Updates ohne Eingriffe in zertifizierte und geprüfte Sicherheitsfunktionen möglich.

© Infoteam Software

Eine Methode, die Anforderungen an die Hardware niedrig zu halten, besteht darin, in regelmäßigen Abständen eine Botschaft mit einer kurzen Zusammenfassung der bisherigen Kommunikation zu senden. Ein solches Secure-Heartbeat-Protokoll bestätigt in regelmäßigen Abständen die bisherige Kommunikation durch den Austausch einer ‚kryptografischen‘ CRC (Cyclic Redundancy Checksum). Bleibt diese Bestätigung aus, oder stimmt diese kryptografische CRC nicht mit der überein, die eigenständig über die geführten Kommunikationsdaten gebildet wurde, dann könnte damit eine Kommunikation mit einem ‚nichtbefugten Partner‘ aufgedeckt werden. Das Secure-Heartbeat-Protokoll verwendet kryptografisch verschlüsselte CRCs, sodass auf diese Weise eine Bestätigung der Rechtmäßigkeit der gesendeten Nachrichten gegeben ist. Durch geschickte Wahl der Abstände im Secure-Heartbeat, dem Zeittakt, kann der Aufwand für diese Maßnahme minimiert werden.

Ein ausreichend leistungsfähiges System ist in der Lage, diesen Vorgang nicht nur einmal pro Zeittakt, sondern für jede einzelne Nachricht durchzuführen. Diese sogenannte digitale Signatur ist bereits vom E-Mail-Verkehr bekannt und setzt eine kryptografische Unterschrift unter jede Botschaft. Neben einer schlichten Bestätigung des Gesendeten könnte im selben Vorgang die Botschaft verschlüsselt werden. Die entsprechenden Bibliotheken wurden ja bereits für die Hash-Funktion implementiert, der Aufwand ist ‚nur‘ die Kapazität zur Laufzeit.

Sollen nicht nur einzelne Botschaften, sondern die ganze Kommunikation in einem Kanal gesichert werden, helfen ebenfalls Techniken, die man aus dem Internet-Alltag kennt. 

Sicherer Kanal mit TLS

Ähnlich wie beim Online-Banking und anderen sicheren Webseiten kann mittels TLS ein gesicherter Kanal in Form einer verschlüsselten Sitzung aufgebaut werden. Die Sicherheit von kryptografischen Funktionen hängt von der effektiven Schlüssellänge ab. Diese Länge lässt sich in Rechenzeit übersetzen, die ein Angreifer benötigt, um Zugriff auf das gesicherte System zu erlangen. In kritischen Bereichen ist es üblich, diese so zu wählen, dass Angreifer theoretisch Jahrtausende brauchen würden, um diese zu berechnen. Das erhöht jedoch den Aufwand für die verschlüsselnde Partei und kann in auf Effizienz zielenden Segmenten weniger aufwendig (allerdings auch weniger sicher) gestaltet werden. Wird die Schlüssellänge reduziert, reduziert sich entsprechend der Aufwand. Um die Schlüssellänge bei funktional sicheren Methoden erfolgreich einsetzen zu können, sollte bereits bei der Architektur der Komponenten an eine Schlüssel-Infrastruktur gedacht werden. Hierbei erhält jedes Gerät ein eigenes Zertifikat, mit dem es sich authentifizieren kann und das dem jeweiligen Gerät  auch Verschlüsselung ermöglicht. Gleichzeitig wird jedes Gerät aufgrund von Maßnahmen befähigt, dieses Zertifikat zu schützen. 

Welche von den hier vorgestellten Maßnahmen, Secure-Heartbeat, digitale Signatur oder TLS, sinnvoll und notwendig ist, erschließt sich aus dem Ergebnis eines ‚Secure Software Development Process‘, da es dabei genau darum geht, Sicherheitsrisiken durch Cyber-Angriffe zu identifizieren und Anforderungen für passende Gegenmaßnahmen zu definieren. Effizient ist es dann entsprechend, diesen Secure-Software-Development-Prozess in den Prozess zur Umsetzung Funktionaler Sicherheit zu integrieren. 

Pflichten für Betreiber

Mittlerweile reagieren erste Software-Anbieter und -Betreiber von funktional sicheren Software­lösungen auf die immer präsenter werdende Gefahr und schenken der Security erhöhte Aufmerk­samkeit.

Im Fokus steht dabei auch, dass der Gesetz­geber die Pflichten für Betreiber kritischer Software-Infrastrukturen mit dem 2015 verabschiedeten „Gesetz zur Erhöhung der Sicherheit informa­tionstechnischer ­Systeme“ deutlich konkretisiert hat. ­Seitdem sind diese verpflichtet, die ­Security stets auf dem neuesten Stand der Technik zu halten. Security ist ein kon­tinuierlicher Prozess über den ge­samten Lebenszyklus der Software hinweg, um den stets aktuellen ­Bedrohungslagen gerecht zu werden. In der Praxis bedeutet das meist, dass auf den ersten Schritt der Software-Entwicklung ein zweiter Schritt folgt, indem die Software im Hinblick auf die grundlegende Angriffssicherheit zunächst ‚nachgerüstet‘ wird und dann aktuell gehalten werden kann. 

Deutlich effizienter hingegen ist der auch von der infoteam Software AG vor­geschlagene Entwicklungsprozess, bei dem die Anforderungen an die funk­tionale Sicherheit und an die Angriffs­sicherheit parallel zueinander betrachtet und implementiert werden. Diese ­Symbiose verhindert effizient kostenintensive Nach- und Zweitentwicklungen.

Autor: Max Perner ist Software-Entwickler bei ­Infoteam Software.