Straße mit Autos vor Stadt, NOA rechts

(Bild: Phoenix Contact)

Die Namur Open Architecture (NOA) beschreibt einen Ansatz zur Erweiterung von Prozessanlagen um Monitoring-Funktionen. Details sind in der Namur-Empfehlung NE 175 (1) aufgeführt, die im Oktober 2020 veröffentlicht worden ist. Auf Basis der so gewonnenen Daten lassen sich Maßnahmen zur Steigerung der Anlageneffizienz ableiten. Die in der NE 175 vorgestellten Konzepte richten sich sowohl an Neu- als auch Bestandsanlagen. Prozessanlagen weisen eine lange Lebensdauer auf und ihr Betrieb ist teilweise mit Risiken verbunden, zum Beispiel im Hinblick auf die Umwelt. Daher erweist es sich als wichtig, dass durch die vorgesehenen Erweiterungen keine negativen Auswirkungen auf den Kernbereich der Prozessautomation (Core Process Control, CPC) entstehen.

Konzept der Namur Open Architecture mit Zonen für Core Process Control sowie Monitoring & Optimization
Bild 1: Konzept der Namur Open Architecture mit Zonen für Core Process Control sowie Monitoring & Optimization (Bild: Phoenix Contact)

Für den Übergang vom Bereich der Kernprozesse auf die neuen Überwachungsbereiche (Monitoring & Optimization, M&O) muss die Rückwirkungsfreiheit gegen Bedrohungen – egal ob Fahrlässigkeit oder Vorsatz – auf dem notwendigen Sicherheitsniveau umgesetzt werden. Die Security-Konzeption wird federführend in der Namur entwickelt und als Namur-Empfehlung 177 „NOA Security Zones and Security Gateway“ (2) publiziert werden (Bild 1). In diesem Zusammenhang ist gemäß der IEC 62443 „Security for industrial automation and control systems“ (4) eine Aufteilung des Prozessautomationsnetzwerks in Zonen vorgenommen worden, um den Security-Anforderungen zu entsprechen. Darüber hinaus wurden Bedingungen für die Übergänge zwischen den Zonen formuliert, damit die Schutzziele erreicht werden können (Bild 2).

Darstellung der geschachtelten Security-Zonen im NOA-Konzept mit Übergangspunkt NOA Security Gatway
Bild 2: Darstellung der geschachtelten Security-Zonen im NOA-Konzept mit Übergangspunkt NOA Security Gateway (Bild: Phoenix Contact)

Zwei Security-Profile verfügbar

Die NE 177 legt fest, dass am Übergang zwischen dem Kernprozessbereich und den Überwachungsbereichen ein Security Gateway installiert sein muss, welches die Rückwirkungsfreiheit sicherstellt. Hierzu werden funktionale Anforderungen beschrieben, die sich auf die Teile „System security requirements and security levels“ (IEC 62443-3-3) sowie „Technical security requirements for IACS components“ (IEC 62443-4-2) beziehen und sich vom Benutzermanagement über die Kommunikation bis zur Aufzeichnung von Ereignissen erstrecken. Außerdem erfolgt eine Definition der erforderlichen Module, die innerhalb des NOA Security Gateways realisiert sein müssen. Die Module dienen der Datenerfassung (Modul 1), dem sicheren Schutz vor Rückwirkungen (Modul 2) und der Bereitstellung der Daten für die M&O-Systeme (Modul 3). Die NE 177 umfasst ferner die beiden Security-Profile „Basic“ und „Extended“ für unterschiedliche Security-Anforderungen. Eine Entwicklung nach dem sicheren Entwicklungsprozess gemäß der IEC 62443-4-1 wird vorausgesetzt (Bild 3).

Hier finden Sie weitere Informationen

Drei funktionale Module des NOA Security Gateways
Bild 3: Drei funktionale Module des NOA Security Gateways (Bild: Phoenix Contact)

Zusammenspiel von drei Modulen

Zur Umsetzung des NOA-Konzepts hat Phoenix Contact bereits verschiedentlich eine Kombination aus HART-Gateway und Industriesteuerung vorgeschlagen, die gemeinsam als Security-Gateway fungieren. Dabei werden die drei von der NE 177 verlangten Module im Zusammenwirken abgebildet (Bild 4). Der diskutierte Lösungsvorschlag des Unternehmens erhebt noch nicht den Anspruch, schon vollständig NE 177-konform zu sein. Die folgende Betrachtung zeigt jedoch die Eignung des Vorschlags für NOA-Anwendungen und potenzielle Weiterentwicklungen.

Exemplarische Einbettung der PLCnext-Steuerung und des HART Gateways in die Namur Open Architecture
Bild 4: Exemplarische Einbettung der PLCnext-Steuerung und des HART Gateways in die Namur Open Architecture (Bild: Phoenix Contact)

Passives Lesen der Daten

Zur Realisierung von Modul 1 sind zwei Optionen erlaubt: das aktive Abfragen oder das rein passive Lesen der Daten aus dem Kernprozess-Bereich. In der unterbreiteten Konfiguration wird das HART-Gateway von Phoenix Contact rein passiv eingesetzt, indem es die Informationen der bereits vorhandenen HART-Verbindungen, bei denen die Daten huckepack auf der 4…20mA-Schnittstelle transportiert werden, mitliest. Eine Rückwirkung ist insofern unmöglich, solange das HART-Interface nicht selbst aktiv wird. Um dies zu verhindern, ist die Parametrierung des HART-Gateways zu schützen. Das HART-Gateway von Phoenix Contact erfüllt also die technischen Anforderungen an ein „Listening Module“.

Schutz der Einbahnstraßen-Kommunikation durch PLCnext-Steuerung

Das Gerät, das eine unabhängige Parametrierung beinhaltet, koppelt sich über das Ethernet-Protokoll an die PLCnext Steuerung des Unternehmens an. Deshalb erweist sich die Netzwerkverbindung zwischen dem HART-Gateway und der PLCnext-Steuerung als sicherheitsrelevant. Beide Komponenten sowie die Verbindungsleitung müssen daher in einem geschützten Bereich installiert sein. In einer zukünftigen Ausprägung wird das HART-Gateway als anreihbares Modul über das Bussystem direkt mit der PLCnext-Steuerung verbunden. In diesem Fall kann nur dann direkt in die Kommunikation zwischen dem HART-Gateway und der Steuerung eingegriffen werden, wenn ein physikalischer Zugriff auf das System besteht. Der Schutz der geforderten Einbahnstraßen-Funktion obliegt damit der PLCnext-Steuerung. Grundsätzlich sind hier zwei Herausforderungen zu bedenken:

  • Die Parametrierung des HART-Gateways geschieht über die PLCnext-Steuerung. Entsprechend muss die Zugangssteuerung so ausgelegt sein, dass eine Umschaltung vom reinen Lese- in den Schreibzugriff unterbunden wird. Bei der Lösung von Phoenix Contact kommt dazu ein interner OPC UA-Server zur Anwendung, der Schreibzugriffe technisch nicht unterstützt.  
  • Ein zweiter möglicher Weg, um das HART-Gateway zum Schreiben zu bringen, wäre die Manipulation der PLCnext-Steuerung und des von ihr verwendeten Betriebssystems. Das zu verhindert ist die Aufgabe der Zugriffssteuerung im Zusammenhang mit der Härtung der Software durch den dahinterliegenden sicheren Entwicklungsprozess. In einem solchen Entwicklungsprozess, der von der NE 177 ausdrücklich verlangt wird, werden Risiken – beispielsweise eine Manipulation – berücksichtigt und durch geeignete Security-Maßnahmen aufgefangen.

Die PLCnext-Steuerung kann also in Kombination mit dem HART-Gateway als „Data Transfer – One Way Interface“-Modul funktionieren. Hierbei wirken beide Geräte gemeinsam, damit die Anforderungen an die Module 1 und 2 erfüllt werden.

Security im kompletten Lebenszyklus verankert

Phoenix Contact gehört zu den ersten Unternehmen weltweit, die einen sicheren Lebenszyklus gemäß IEC 62443-4-1 realisiert haben. Dies wurde durch den TÜV Süd zertifiziert. Vom sicheren Entwicklungsprozess bis zum kontinuierlichen Schwachstellenmanagement des Phoenix Contact PSIRT (Product Security Incident Response Team) ist Security dabei im kompletten Lebenszyklus der Produkte und Lösungen verankert. Erfahrung und Wertschöpfungstiefe unterstützen die Anwender außerdem bei der Erreichung ihrer Security-Qualitätsziele.

 

Für die sichere Gestaltung von Lösungen und Dienstleistungen hat Phoenix Contact - ebenfalls als eines der ersten Unternehmen weltweit - einen sicheren Prozess nach IEC 62443-2-4 (Anforderungen an das Sicherheitsprogramm) umgesetzt und sich zertifizieren lassen. Entsprechend ist die Security auch im Zusammenwirken der Komponenten und der Integration in den Betrieb sichergestellt.

Abbildung der Daten im PA-DIM-Modell

Schließlich müssen der M&O-Domäne die Daten zur Verfügung gestellt werden. Zu diesem Zweck wird der NOA Aggregating Server genutzt, der auf der PLCnext-Steuerung läuft. Der Aggregating Server bildet die Daten im Informationsmodell PA-DIM (Process Automation–Device Information Model) ab, das von den M&O-Systemen erwartet wird. Die Security-Eigenschaften hängen hier ebenfalls wesentlich von der Qualität der Implementierung und folglich dem sicheren Entwicklungsprozess ab. Im Kontext der Gesamtfunktion stehen dabei die Integrität und Vertraulichkeit der Informationen im Mittelpunkt. Die Rückwirkungsfreiheit ist bereits durch die Module 1 und 2 realisiert, die keinen Zugriff auf die kritischen Bereiche der Kernprozesse erlauben.   

Praktische Anwendung möglich 

Die von Phoenix Contact vorgeschlagene Lösung setzt Funktionen um, die dem Konzept des NOA Security Gateways entsprechen, ohne schon den Anspruch zu erheben, der NE 177 vollumfänglich gerecht zu werden. Insofern ist eine praktische Anwendung unter Beachtung einer Risikoanalyse jederzeit möglich.

Offene Steuerungsplattform auf Basis des Security-by-Design-Konzepts

Der weltweite Security-Standard IEC 62443 zielt auf eine ganzheitliche Betrachtung der Cybersicherheit in der Automatisierungstechnik ab. Dabei kommt dem Security-by-Design-Konzept eine wesentliche Bedeutung zu. Bei der Entwicklung der PLCnext Technology als offener Steuerungsplattform war Security-by-Design daher eine wichtige Rahmenbedingung des Architekturdesigns. Daraus ergaben sich unter anderem folgende Maßnahmen:

  • Verwendung von Trusted Platform Modules (TPM) als Hardwareschutz für die privaten Geräteschlüssel
  • Nutzung eines konfigurierbaren Linux-Kerns, der gezielt im Hinblick auf die Security abgesichert und gewartet werden kann
  • Authentisierung und Autorisierung von menschlichen Nutzern und Softwareprozessen auf allen Kommunikationskanälen
  • Implementierung eines Crypto Stores für Zertifikate, Schlüssel und Identitäten von Systemintegratoren und Betreibern
  • Verwendung und Konfiguration der VPN-Kommunikationen (Virtual Private Network)
  • Unterstützung der OPC UA-Schnittstelle mit Security-Profilen, einem UA-Rollen- und –Rechtesystem, x.509-Zertifikaten sowie einer Schnittstelle zum Global Discovery Server zwecks Zertifikatsverteilung
  • programmierbare TLS-Kommunikation (Transport Layer Security) für anwendungsspezifische Lösungen, beispielsweise als Funktionsbausteine gemäß IEC 61131 oder Hochsprachen-Schnittstelle
  • Einsatz und Konfiguration der Linux-Firewall
  • Nutzung und Konfiguration der Logging-Mechanismen mit einer synchronisierten Zeitbasis
  • Device Management-Schnittstelle für das Update von Firmware-Komponenten.

Hier finden Sie weitere Informationen

 


Literaturverzeichnis:

(1) NE 175: NAMUR Open Architecture - NOA Concept. Leverkusen : NAMUR, 2020.

(2) NE 177: NAMUR Open Architecture - NOA Security Zones and Secu-. Leverkusen : NAMUR, 2021.

(3) Runde, Markus, et al. Security für die NAMUR Open Architecture. atp magazin. 1/2, 2021.

(4) Security for industrial automation and control systems. IEC 62443.

Kostenlose Registrierung

Der Eintrag "freemium_overlay_form_cte" existiert leider nicht.

*) Pflichtfeld

Sie sind bereits registriert?