Von Heiko Adamczyk, Mario Wolframm

Die Kommunikation über private, öffentliche beziehungsweise auch drahtlose Netzwerke ist im Sinne von Security im Allgemeinen nicht vertrauenswürdig. Daher ist davon auszugehen, dass auch safety-relevante Daten – sofern ihr Transport über diese Kommunikationswege erfolgt – den vorherrschenden IT-Angriffen ausgesetzt sind. Angesichts der drohenden Gefährdung wurde im Rahmen des VAN-Projektes ein Konzept zur Lösung der damit einher gehenden Sicherheits-Problematik erarbeitet. Die hierbei diskutierten Anforderungen an die funktionale Sicherheit beziehen sich ausschließlich auf die VAN-spezifische Kommunikation – also auf die Sicherheitsbetrachtung des Kommunikationskanals.

Aufteilung der mittleren Wahrscheinlichkeit gefahrbringender Ausfälle eines sicherheitsbezogenen Systems mit den Teilsystemen Sensor, Logikeinheit (Controller) und Aktor. Innerhalb dieser typischen Sicherheitskette macht der gesamte Kommunikationsanteil, welcher der Logikeinheit (Controller) zugeordnet wird, rund 1% aus.

Eine Kommunikation ist grundsätzlich fehlerbehaftet – zum Beispiel aufgrund von EMV-Störungen oder aufgrund von systematischen Fehlern wie Softwarefehler im Kommunikationsstack beziehungsweise stochastischer Fehler wie etwa ein Bauteile-Ausfall. Neben Informationsverfälschung, -verlust oder unerwünschter Informationseinfügung kann es zu Verzögerung, Wiederholung sowie Vertauschen der Reihenfolge oder gar zu Informationsfehlleitungen kommen. Über eine Sicherheitsbetrachtung gemäß der einschlägigen Safety-Normen, wie zum Beispiel der IEC 61508, lässt sich zunächst ermitteln, ob derartige Kommunikationsfehler zu einem kritischen Zustand im Sinne der Maschinen- und Anlagensicherheit führen können. Besteht diese Möglichkeit, sind für ein Kommunikationssystem beziehungsweise für die darin auftretenden Kommunikationsfehler entsprechende fehlererkennende Maßnahmen zu definieren. Diese Maßnahmen müssen die Safety-Anwendung in einen sicheren Zustand überführen, sobald eine bestimmte Fehlerwahrscheinlichkeit innerhalb des Kommunikationssystems überschritten wird. Da der Kommunikationsanteil einer typischen Sicherheitskette bei 1% liegt, wie es unter anderem im Profisafe-Profil V2.0 definiert ist, hat die Kommunikation bei einem geforderten Sicherheitsintegritätslevel 3 (SIL3) nach IEC 61508 und der Betriebsart mit hoher beziehungsweise kontinuierlicher Anforderungsrate eine Fehlerwahrscheinlichkeit von <10-9/h zu gewährleisten.

Eine solche Fehlerbetrachtung geht meist von einem geschlossenen System aus. Bei einer Kommunikation über inhomogene Netze ist diese Annahme nicht mehr gültig. Zur Wiederherstellung eines „geschlossenen Safety-Systems“ leitet VAN IT-qualitative Security-Anforderungen ab, welche einen in sich geschlossenen Kommunikationskanal erfordern. Dieser muss die Eigenschaft besitzen, zwei vertrauenswürdige Netzwerke (high trust zones) über ein nicht-vertrauenswürdiges Netz (low trust zone) zu verbinden. Dabei gilt die Annahme, dass innerhalb des nicht-vertrauenswürdiges Netzes letztendlich nicht-authorisierte Nutzer auf safety-relevante Daten zugreifen und diese manipulieren können. Zwar sind geeignete Maßnahmen zur Sicherherstellung der IT-Security-Anforderung nicht safetyrelevant und damit keinem Zertifizierungsprozess unterworfen; nichtsdestotrotz können im Rahmen einer Abnahme einer safety-relevanten Anwendung unter Umständen Nachweise zu erbringen sein, die diese Eigenschaft belegen.

Realisierungsaspekte am Beispiel Profinet

Eine Safety-Layer-Technologie, die weitgehend alle VAN-Safety-Anforderungen erfüllt, ist beispielsweise das Profisafe-Protokoll. Profisafe betrachtet den (VAN-) Kommunikationskanal als „Black Channel“ und definiert einen Safety-Layer (Failsafe-Layer), der oberhalb des Black Channel sitzt. In diesem F-Layer sind Maßnahmen zur Beherrschung der vorab genannten Kommunikationsfehler definiert. Anforderungen, die Profisafe ebenso wie alle anderen im Projekt evaluierten Technologien nicht erfüllen, betreffen unter anderem die Kompatibilität zu anderen Safety-Layer-Technologien.

Darüber hinaus gibt es Anforderungen, die Profisafe selbst an die Kommunikation stellt. Das sind zum einen eine zyklische Kommunikation und zum anderen systemweit eindeutige 1:1-Kommunikationsbeziehungen. Bei Verwendung von Profinet als Kommunikationssystem wird die erste Anforderung durch den zyklischen Kanal erfüllt (Runtime Channel), die Umsetzung der zweiten Anforderung erfolgt durch das VAN-Adressierungs-Schema. Da VAN für Geräte eine namensbasierte Adressierung verwendet, bedeutet dies für die verbundenen Applikationsobjekte, dass diesen die IP- und MAC-Adressen verborgen bleiben. Hierbei ist zu berücksichtigen, das Profisafe selbst Adressen definiert (Sender/ Empfänger mit je 16 Bit Länge), die unabhängig vom unterlagerten Kommunikationskanal beziehungsweise -system sind. Diese Profisafe- oder kurz F-Adressen müssen im gesamten safety-relevanten System bekannt und vor allem eindeutig sein. Die Adressierung obliegt der VAN-Infrastruktur. Zur Sicherstellung der F-Adressierung sind safety-relevante Teile unter anderem in das VAN-Engineering einzubetten, welches bereits dann aktiv werden muss, wenn eine VAN-Domain aus zwei schon bestehenden industriellen Anwendungsdomänen besteht und zwischen ihnen safety-relevante Daten auszutauschen sind. In diesem einfachen Verbindungsszenario ist unter allen Umständen die Eindeutigkeit der F-Adressierung zwingend zu gewährleisten.

Fehler-erkennende Maßnahmen bei Profisafe

Eine weitere entscheidende Rolle spielt bei Profisafe die Verfügbarkeit. Profisafe adressiert mit ausreichender Verfügbarkeit die Zuverlässigkeit des Black Channel, welche einerseits durch Conformanceund Profiltests der akkreditierten PNOPrüflabors sicherzustellen ist; andererseits existieren Installationsrichtlinien, die einen zuverlässigen Aufbau eines Profinet-Netzwerkes erlauben. Was zum Beispiel die elektrische Verbindung betrifft, wird innerhalb industrieller und damit stark gestörter Umgebungen die Verwendung abgeschirmter Kabel empfohlen. Natürlich stellt dies keine Safety-Anforderungen dar; es lassen sich jedoch Zusammenhänge zwischen Nichtverfügbarkeit und Anlagensicherheit herleiten: Nicht verfügbare Anlagen sind weniger produktiv, was letztendlich zu der Situation führen kann, dass Anlagenbetreiber die in der Anlage vorhandenen Safety-Funktionen nicht in vollem Umfang nutzen oder sogar abschalten.

VAN definiert zur Erhöhung der Verfügbarkeit ein Verfahren zum Erreichen eines definierten Quality of Service (QoS). Grundlage des QoS ist das Service Level Agreement (SLA) mit dem Netzprovider. Hierin wird die Verfügbarkeit quantifiziert, die der Provider garantieren muss. In der Regel ist die Verfügbarkeit des Übertragungskanals kleiner 100 %. Die Down-Zeiten (Dauer/Zeitpunkte) sind dabei genau festgelegt. Neben dem SLA wurden Prioritätsklassen für die zu übertragenden Daten definiert. Die Zuordnung der jeweiligen Priorität obliegt der Anwendung. Der Service Provider transferiert die Daten anhand dieser Prioritäten und so erfolgt beispielsweise eine unterschiedliche Behandlung von zyklischen Daten (zum Beispiel Prozessdaten) und azyklischen Daten (zum Beispiel Daten für den Verbindungsaufbau).

Die Aspekte der Informationssicherheit

Das Vorgehensmodell der VDI/VDE 2182 definiert acht Prozessschritte, um eine dem Bedarf angemessene und damit wirtschaftliche IT-Security-Lösung erarbeiten und betreiben zu können.

Neben der geschilderten Sicherheitsbetrachtung macht die Nutzung von VANs in Safety-Anwendungen eine IT-Security-Analyse zwingend notwendig. Das Problem dabei: Im Gegensatz zu den etablierten Standards im Safety-Bereich, gibt es für IT-Security in der Automatisierung keine entsprechenden Standards. Einschlägige Richtlinien wie die ISO/IEC 13335 oder die ISO/IEC 17799, ISO/IEC 27001 (Kompass der IT-Sicherheitsstandards) beziehen sich auf das IT-Sicherheits- und Risikomanagement eines Unternehmens und lassen sich schwer auf eine Anwendung innerhalb des VAN-Projektes zuschneiden. Als zweckmäßig für die Nutzung im Projekt erwies sich hingegen die kürzlich erschienene VDI/VDE-Richtlinie 2182 „IT-Security in der industriellen Automation“. Sie schlägt zwar keine konkreten Verfahren, Methoden und Lösungen vor; jedoch resultiert aus der Nutzung des in der Richtlinie definierten Vorgehensmodells eine strukturierte und vor allem planbare Arbeitsweise.

Auf der Grundlage der gemäß VDI/VDE 2182 durchgeführten Infrastruktur-, Gefahren- und Risiko-Analyse hat das VAN-Konsortium folgenden Maßnahmen zur Sicherstellung der IT-Security in einem Virtual Automation Network festgelegt:

• Die Verwaltung der Security Policy erfolgt über einen getrennten Kanal (eigener Container, so genannte Security-Application-Service-Elemente) und ist daher über den Abfragekanal nicht manipulierbar.
• Der Schutz der Anwendungsobjekte vor DoS-Angriffen kann bereits in den vorgelagerten Kommunikationsblöcken geschehen – also primär im Broker –, was die jeweils separat zu implementierenden und oft auch nicht vorab eingeplanten Schutzmechanismen in den Anwendungen reduziert oder eliminiert.
• Die Abfrage der Berechtigungen verzichtet auf sämtliche Schreibvorgänge (reentrante Programmierung); mehrfach anliegende Anfragen lassen somit keinerlei Seitenwirkungen entstehen, was zu potenziellen Sicherheitslöchern führen könnte.

Für die Entscheidung, ob ein Web-Service akzeptiert oder zurückgewiesen wird, zieht die ACL-Attribute heran wie die aufgerufene Methode (Lesen der Diagnose/ Schreiben der Konfiguration), das innerhalb des Gerätes adressierte Objekt, das adressierte Ziel-Gerät oder den Namen des Quell-Rechners.

Paket-Filter

Wie im Zusammenhang mit ACL beschrieben, werden alle VAN-spezifischen, web-service-basierten Requests auf Anwendungsebene überprüft. Dieser Test kann bei komplexeren Strukturen substanzielle Verzögerungen hervorrufen und ist damit für zeitempfindliche Daten der Feldbus-Ebene nicht anwendbar. Daher erlauben definierte VAN-Netzwerk-Infrastruktur-Geräte die Aktivierung von Filter-Regeln auf Netzwerk-Ebene. Diese VAN-spezifischen Firewalls/Packet-Filter können auf der Ebene von IP-Adressen und auch auf der Ebene von Layer-2-MAC-Adressen Datenpakete weiterleiten oder blockieren.

Von der Philosophie einer Whitelist ausgehend – was akzeptiert werden soll, muss explizit erlaubt sein; die Standardreaktion ist zu blockieren – wird dabei konsequent das Regelwerk aufgebaut. Werden entsprechend bestimmter Regeln schwere Verstöße identifiziert, so ist auch die Weitergabe eines zugehörigen Alarms zu einer zentralen Melde-Instanz spezifiziert. Die Definition des Regelsatzes erfolgt dabei in einer geräte-unabhängigen XML-Beschreibung, die folgende Überführung in die firewall-spezifische Konfiguration geschieht mittels eines Transformationsprogramms. Die Definition des „Melde-Interface“ erfolgte unter Berücksichtigung des RFC4765 (Intrusion Detection Message Exchange Format – IDMEF) und RFC4766 (requirements for this communication mechanism).

Autoren

Heiko Adamczyk ist Leiter des Forschungsschwerpunktes Sichere Industrielle Kommunikation am ifak, Magdeburg.

Mario Wolframm ist tätig für die Firma Teleport Sachsen-Anhalt Service, Magdeburg.