Systemintegrität als Kernelement der Industrial Security

Bei der Auswahl und der Konfiguration von geeigneten Schutzmechanismen und -maßnahmen, die zur Gewährleistung der Systemintegrität im Kontext der Industrial Security beitragen sollen, ist es wichtig sicherzustellen, dass diese Mechanismen und Maßnahmen (nachweisbar) zu keinen Nebeneffekten führen, d.h. rückwirkungsfrei sind. In der Namur-Empfehlung NE-153 sind die entsprechenden Anforderungen in Abschnitt 2.2 ‚Definition der Nutzfunktionen für den bestimmungsgemäßen Gebrauch, Rückwirkungsfreiheit von Zusatzfunktion‘ wie folgt formuliert:

• „1. Bei der Integration von Komponenten in eine Automatisierungslösung ist sicherzustellen, dass die Anwendung aller aktivierten Nutzfunktionen dieser Komponenten nur in der für die geplante Anwendung vorgesehenen Kombination möglich ist.
• 2. Durch die Nutzung zulässiger Optionen dürfen keine nicht spezifizierten Funktionsänderungen ausgelöst werden. In jeder Kombination der verfügbaren Optionen muss ein nachvollziehbares deterministisches Verhalten der Nutzfunktionen der Automatisierungskomponente gewährleistet sein.“

Im Kontext des Industry SIEM bedeutet dies, dass ein (beispielsweise in einer Anlage) installiertes SIEM-System ausschließlich seine primären Aufgaben erfüllt, d.h. die Erfassung, Auswertung, Anzeige, langfristige Speicherung der Security-Logs/-Events sowie gegebenenfalls die Bereitstellung der Security-Logs und -Events für weitergehende Auswertung durch weitere überlagerte Werkzeuge. Dadurch darf jedoch keine (negative) Rückwirkung auf die Verfügbarkeit und die Performance des zur Übertragung des Events verwendeten Netzwerks sowie auf die einzelnen Anlagenkomponenten, -systeme und die Gesamtanlage entstehen. Bei der Auswahl der zur Erfassung und Übertragung von Security-Logs und -Events zu verwendenden Transportwege sollte man beispielsweise darauf achten, dass für die Nutzung der Transportwege entweder kein oder ein gut kontrollierbarer und transparenter Zugriff auf die Anlagenkomponenten erforderlich ist. Hierzu ist zu beachten, dass unterschiedliche Transportwege unterschiedlichen Konfigurationsaufwand und unterschiedlich komplexe Kontrollmechanismen erfordern. Beispielsweise erfordert die Nutzung des Syslog- bzw. Secure-Syslog-Protokolls als Transportweg zur Übertragung von Security-Logs und -Events keine vorkonfigurierten Zugriffsberechtigungen, während der Zugriff auf eine Datenbank, in der Security-Events abgelegt sind, ohne vorkonfigurierte Zugriffsberechtigungen nicht möglich ist. Um so wichtiger ist es dabei, die Berechtigungen möglichst sorgfältig und genau zu definieren: Ein SIEM-Connector, der die Security-Events aus einer Datenbank oder dem Windows Event Log liest, darf keine System- bzw. Administrator-Rechte erfordern bzw. bekommen. Ein weiterer wichtiger Aspekt im Hinblick auf die Rückwirkungsfreiheit im Kontext des Industry SIEM besteht darin, dass die durch die Übertragung der Events gegebenenfalls gestiegene Kommunikationslast die Performance und Verfügbarkeit des Netzwerks und der Anlage nicht negativ beeinflussen darf. Im Kontext des angestrebten automatisierten Managements von Zertifikaten bedeutet die Rückwirkungsfreiheit insbesondere, dass die Verfügbarkeit der einzelnen Anlagenkomponenten und der Gesamtanlage stets gewährleistet ist, auch wenn ein von einem Gerät oder einer Applikation (beispielsweise für die verschlüsselte Kommunikation oder Authentifizierung) verwendetes Zertifikat für ungültig erklärt wird bzw. erneuert werden muss. Es darf also nicht vorkommen, dass ein Gerät auf eine Anfrage nicht reagiert, bzw. einen erwarteten Messwert nicht liefert, weil sein Zertifikat gerade abgelaufen ist und noch nicht erneuert wurde. Dies setzt voraus, dass alle Szenarien, die sich im Anlagenkontext ereignen können (insbesondere Ausrollen, Erneuerung und Revokation von Zertifikaten, sowie der Gerätetausch), beim Design der adäquaten in Automatisierungsgeräten und -applikationen zu implementierenden Mechanismen genau berücksichtigt werden müssen. Dies impliziert wiederum, dass der Hersteller, der derartige Mechanismen für Automatisierungsgeräte und -applikationen spezifiziert, die Sicht eines Integrators, Servicetechnikers bzw. des Kunden, der diese im Anlagenkontext in Betrieb nimmt bzw. nutzt, möglichst gut kennen muss. Dies verdeutlicht nochmals die Aussage, dass die Sicherstellung der Systemintegrität genauso wie weitere Aufgaben im Kontext der Industrial Security eine enge Zusammenarbeit zwischen Hersteller, Systemintegrator und Anwender erfordert. Zur Gewährleistung der Rückwirkungsfreiheit wird durch die genaue Spezifikation, Dokumentation, Umsetzung und Konfiguration der primären Funktionalitäten der für den Einsatz im industriellen Umfeld anvisierten integrierten und kommerziellen Werkzeuge sowie durch die fundierten, im Vorfeld durchgeführten Verträglichkeitstests beigetragen.

Ausblick, Schutzlevels

Im Hinblick auf die Anforderungen von Industrie 4.0, insbesondere auf die Megatrends Digitalisierung, Dezentralisierung, Big Data, Cloud-Computing und das ‚Internet der Dinge und Dienste‘ sowie auf die damit verbundene, zunehmende Verteilung und Intelligenz von Komponenten und Systemen wird die Systemintegrität weiterhin an Bedeutung gewinnen. Dies macht die weitere Etablierung und Weiterentwicklung von adäquaten funktionalen Mechanismen und Maßnahmen erforderlich. Ferner ist es wichtig zu beachten, dass zur nachweisbaren Sicherstellung und Aufrechterhaltung der Systemintegrität im Anlagenkontext neben technischen, funktionalen Maßnahmen und Mechanismen auch weitere Maßnahmen, die eher organisatorischen Charakter haben, unabdingbar sind. Diese Aussage wird durch die nachfolgenden Ausführungen erläutert. Die technische Realisierung der Mechanismen und Maßnahmen, die den in Teil 1 aufgeführten Security Levels nach IEC62443 zuordenbar sind, liegt im Verantwortungsbereich des Herstellers in den Fähigkeiten der Produkte, und des Systemintegrators in den umgesetzten technischen Fähigkeiten der Automatisierungslösung. Der Systemintegrator und der Anlagenbetreiber müssen darüber hinaus durch die Festlegung und Aufrechterhaltung der notwendigen, auf die Anlage zugeschnittenen Prozesse ebenfalls zur Sicherstellung der Systemintegrität beitragen. In dem Sinne müssen die Definitionen des SL als ‚Fähigkeit zum Schutz‘ verstanden werden. Der Schutz wird erst dann erreichen, wenn ergänzend zu den technischen Maßnahmen die dazugehörigen Betriebs- und Wartungsprozesse beschrieben und umgesetzt werden. Hinsichtlich der Prozesse als wesentliche Bestandteile eines ganzheitlichen Schutzkonzepts ist dabei insbesondere Folgendes zu beachten: Es ist detailliert erläutert, ist es für organisatorische Maßnahmen wichtig, dass die Umsetzung durch das Personal sichergestellt sein muss. Das setzt voraus, dass die Prozesse dokumentiert sind und das Personal informiert bzw. geschult ist. Eine Kontrolle der Umsetzung ist oft sehr sinnvoll. Nur wenn dieser Zustand erreicht ist, können organisatorische Maßnahmen ihren Beitrag im Rahmen eines ganzheitlichen Schutzkonzepts leisten. Man bewertet in der Regel die Fähigkeit einer Organisation, Prozesse aktiv zu ‚leben‘, mit dem Reifegrad nach dem sogenannten ‚Capability Maturity Model Integration (CMMI)‘. Das Modell unterscheidet fünf Reifegrade, die wir im Weiteren mit der Abkürzung ML (Maturity Level) bezeichnen werden:

• 1. Initial: Keine Anforderungen an die Organisation. Diesen Reifegrad hat jede Organisation automatisch.
• 2. Managed: Die Projekte werden durch Prozesse geführt. Ein ähnliches Projekt kann erfolgreich wiederholt werden.
• 3. Defined: Die Projekte werden nach einem angepassten Standardprozess durchgeführt und es gibt eine organisationsweite Kontrolle der Umsetzung der Prozesse.
• 4. Quantitatively Managed: Es wird eine statistische Prozesskontrolle durchgeführt.
• 5. Optimizing: Arbeit und Arbeitsweise werden mit Hilfe einer statistischen Prozesskontrolle verbessert.

In der Norm 62443 hat man in Anlehnung an das CMMI-Modell vier Reifegrade definiert. Man hat dabei im Wesentlichen die Levels vier und fünf zusammengefasst:

• 1. ML 1, Initial: Die Prozesse sind ad-hoc, schwach kontrolliert und nicht voraussagbar.
• 2. ML 2, Managed: Es werden Prozesse reaktiv gelebt.
• 3. ML 3, Defined: Die Prozesse sind beschrieben und werden proaktiv umgesetzt.
• 4. ML 4, Optimized: Die Prozesse werden bewertet, kontrolliert und kontinuierlich verbessert.

Kombiniert man die Bewertung der umgesetzten funktionalen Maßnahmen der Automatisierungslösung nach Security Level (SL 1 bis SL 4) und den Reifegrad bei der Umsetzung der dazugehörigen organisatorischen Maßnahmen (ML 1 bis ML 4) in einer zweidimensionalen Matrix, dann kann man jedem Feld der Matrix einen Schutzlevel zuordnen. Die Fähigkeit zum Schutz der Security Levels entspricht bei den Schutzlevels einem tatsächlichen Schutz, der durch die Ergänzung der funktionalen Maßnahmen durch die dazugehörigen organisatorischen Maßnahmen erreicht werden kann. Daher kann man für die Schutzlevels (engl. Protection Levels), für die im Weiteren die Abkürzung PL verwendet wird, die in der Norm enthaltene Definition der Security Levels übernehmen:

• • PL 1: Schutz gegen ungewollten, zufälligen Missbrauch,
• • PL 2: Schutz gegen gewollten Missbrauch unter Verwendung von einfachen Mitteln, mit niedrigem Aufwand, allgemeinen Kompetenzen und niedriger Motivation,
• • PL 3: Schutz gegen gewollten Missbrauch unter Verwendung von technisch ausgefeilten Mitteln, mit moderatem Aufwand, automatisierungstechnisch spezifischen Kompetenzen und moderater Motivation,
• • PL 4: Schutz gegen gewollten Missbrauch unter Verwendung von technisch ausgefeilten Mitteln, mit erheblichem Aufwand, automatisierungstechnisch spezifischen Kompetenzen und hoher Motivation.

Das skizzierte Konzept der Schutzlevels bildet eine Basis für die Aktivitäten einer neu gegründeten Standardisierungs-Arbeitsgruppe. Der aktuelle vorliegende, mit den Prinzipien der Defense-in-Depth-Strategie in Einklang stehende Vorschlag für die Zuordnung der Schutzlevels zu den Kombinationen Reifegrad/Security-Level ist in der Abbildung veranschaulicht. Der oben erwähnte Vorschlag für die Zuordnung basiert auf der wichtigen, in den letzten Jahren gewonnenen Erkenntnis, dass technische Schutzmaßnahmen allein nicht alle Schutzziele abdecken können, so dass begleitende und unterstützende organisatorische Maßnahmen unerlässlich sind. Somit kann nur ein Gesamtkonzept alle Risiken minimieren und wirkungsvollen Schutz bieten. Auch für den Hersteller ist das Konzept der Protection Levels relevant. Auf der einen Seite hat er für die Qualität seiner Produkte zu sorgen, indem er die Security in dem Entwicklungsprozess integriert und fortschrittliche Fähigkeiten bietet. Auf der anderen Seite hat er für die Integrität der Produkte zu sorgen. Und hier ist er in der Rolle des Betreibers der Anlagen in denen die Produkte gefertigt werden. Das Ziel muss sein, dass die Firmware, die in der Produktionsumgebung in die Produkte heruntergeladen nicht ungewollt verändert wird. Siemens verfolgt diese Konzepte mit dem sog. Holistic Security Concept, das den gesamten Lebenszyklus der Produkte, Systeme und Anlagen mitberücksichtigt. Die Automatisierungsanlagen sowie die Entwicklungsumgebungen sollen optimal gegen unberechtigte Veränderungen geschützt werden. Holistic Security Concept setzt alle in diesem Beitrag beschriebenen Konzepte und Maßnahmen um.

Literaturhinweise