Evolution der Werkzeugkiste - Der Reifegrad der Methoden in der Industrial Security

Timo Kob, David Fuhr

Nach einem Spätstart hat die OT-Security in den letzten Jahren bedeutend gegenüber der IT-Security aufgeholt. Viele technische IT-Sicherheitsmaßnahmen sind auch für Maschinen und Anlagen verfügbar. Das Bild des Security-Reifegrads im OT-Feld ist jedoch komplexer und bruchstückhafter, wie der vorliegende Beitrag zu zeigen versucht. Bestimmte Grundfragen und Widersprüche der IT-Security werden hier besonders deutlich und müssen daher möglicherweise in der OT-Security selbst gelöst werden.

Wie sicher ist meine Fabrik, Anlage oder Maschine vor Hackerangriffen und anderen IT-Sicherheitsvorfällen? Wie ist es in dieser Hinsicht um meine Supply-Chain bestellt, also die Produkte, Prozesse und Systeme meiner Zulieferer und Dienstleister? In Zeiten voranschreitender Arbeitsteilung und immer weiter zunehmender Vernetzung stellen sich diese Fragen immer drängender. Zu ihrer Beantwortung existiert nicht ein, sondern eine Vielzahl von Vorgehen. Manche davon sind in Standards beschrieben – etwa unter der Überschrift „Reifegrad(Modell)“ – andere sind Eigenentwicklungen bestimmter Betreiber oder auch Beratungshäuser. Die Fragen der Vergleichbarkeit und des Ziels von „Benchmarks“, „Self Assessments“ und „Health Checks“ sind komplex und sollen an anderer Stelle behandelt werden.
Dieser Beitrag möchte stattdessen die Frage andersherum stellen: Wie reif, wie weit fortgeschritten, wie angemessen, wie erfolgsversprechend ist die Werkzeugkiste, die uns heute – Anfang 2018 – zur Verfügung steht, um die Fabrik-IT tatsächlich effektiv abzusichern? Versuchen wir uns also an einem Benchmark der Industrial Security. Als Vergleichsgrößen sollen dabei dienen:
1. Security-Toolboxen, wie sie in anderen, ebenfalls großen Angriffsrisiken ausgesetzten Anwendungsszenarien von IT zum Einsatz kommen, und
2. das Schutzniveau, das heute realistisch tatsächlich benötigt wird, um einem ernsthaften Angriffsversuch standzuhalten.

Benötigtes Security-Niveau

Beginnend mit der letzten Frage: Was ist das Niveau eines Angriffs, den ich mit nicht zu vernachlässigender Wahrscheinlichkeit erwarten sollte? Was ist die maximale Angriffsstärke, gegen die es sich zu verteidigen gerade noch lohnt? Diese Fragen lassen sich schwer losgelöst vom konkreten Einzelfall beantworten. Andererseits ist es nicht realistisch, von Unternehmen des produzierenden Gewerbes unabhängig von ihrer Größe zu verlangen, sich mit der momentanen Cyber-Bedrohungslage, den aktuell aktiven Akteuren und neusten Angriffskampagnen ständig perfekt auszukennen. Wie sieht hier also ein sinnvolles und wirtschaftliches Vorgehen aus? Grundsätzlich gibt es drei Herangehensweisen an das Problem:
• Mindestanforderungen
• Risikoanalyse
• Security Levels
 


Bild 1: Security Level nach IEC/TS 62443-1-1 [8].

Methode 1: Mindestanforderungen

Mindestanforderungen gibt es, seit es Compliance gibt – also beinahe seit Anbeginn der Marktwirtschaft. So wie Compliance allerdings damals noch nicht Compliance genannt wurde, werden Mindestanforderungen erst als solche bezeichnet, seitdem sich die Erkenntnis durchgesetzt hat, dass erstens eine allgemeine Anhebung eines qualitativen Niveaus dem Gesamtmarkt nützen kann und zweitens auch höhere Anforderungen unter bestimmten Voraussetzungen sinnvoll und wichtig sein können. Ähnlich wie es bei der Maschinenrichtlinie darum geht, ob ich bestätige, die Anforderungen der CE-Kennzeichnung zu erfüllen, setzen Mindestanforderungen einen kleinsten gemeinsamen Nenner fest, den alle Marktteilnehmer einhalten sollten, unabhängig von der spezifi schen Gefährdungslage und dem möglichen Maximalschaden im Einzelfall. Marktteilnehmer ist hier durchaus im allgemeinen Sinn zu verstehen: So bemüht sich ein Großteil der technischen Standards im Feld, die „Teilnehmer“ im Sinn von Nutzer einer bestimmten Technologie auf ein oder zumindest eines von wenigen Umsetzungsmodellen zu verpfl ichten. Dies triff t etwa für einen großen Teil der de facto-Standards in der RFC-Dokumentenserie (Requests for Comments) der IETF (Internet Engineering Task Force) [1] zu.

Methode 2: Risikoanalyse

Die relevantesten der vorliegenden (nicht nur IT-)Security-Standards fordern als Herzstück des Prozesses üblicherweise zwei Dinge: Erstens einen Durchführungszyklus. Klassisch war das der PDCA-Zyklus (Plan-Do-Check-Act), auch als Deming- oder Shewhartkreis bekannt [2], der jedoch in den neueren Managementsystemen in seiner expliziten Form langsam außer Mode kommt. Und zweitens eine sogenannte Risikoanalyse. Während sich das genaue Vorgehen von Standard zu Standard unterscheidet (und etwa im Rahmen des unbestritten wichtigsten IT-Security-Standards ISO 27001 [3] innerhalb bestimmter Vorgaben sogar frei zu wählen ist), beinhaltet diese in der Regel die Bestimmung aller zu schützenden Werte sowie die Betrachtung aller relevanten Bedrohungen für jeden von ihnen. Wie immer, wenn mehr Dimensionen – hier (Anzahl der) Assets mal (Anzahl der) Bedrohungen – ins Spiel kommen, ergibt sich großer Aufwand: Mathematisch spricht man näherungsweise von einem quadratischen Wachstum in den Parametern. Während dies für Algorithmen manchmal noch akzeptabel sein kann, kommen menschliche Bearbeiter und Entscheider hier schnell an ihre Grenzen.
Der IT-Grundschutz als spezifi sch deutsche „Variante“ der ISO 27001 versucht dieses Dilemmas durch Kombination der beiden bisher genannten Methoden Herr zu werden: Der Basisschutz wird im Wesentlichen als Mindestanforderungen defi niert, einschließlich der üblichen Möglichkeit, Maßnahmen als „entbehrlich“ wegzuargumentieren. Für höheren Schutzbedarf ist nach wie vor eine angeleitete Risikoanalyse durchzuführen [4]. Die Methode impliziert, dass die Risikoanalyse für „normalen“ Schutzbedarf durch die Autoren des Standards je Zielobjekttyp einmal a priori generisch durchgeführt worden ist. Dies kann nur für „normale“ (im Sinn von während der Risikoanalyse bedachte) Anwendungsfälle und „normale“ (im Sinn von für den Betreiber tragbare) zu erwartende Maximalschäden funktionieren.

Methode 3: Security Levels

Denkt man das Modell der Mindestanforderungen als eine Art Ground Zero in Richtung höherer Schutzbedarfe weiter, so kann man versuchen, weitere Stufen von Absicherung generisch zuzuschneiden, vorzudenken und in Maßnahmenpakete zu verpacken, deren Anwendung die Risikoanalyse bei Einhaltung der jeweiligen
Normalparameter ersparen soll. Dieses Modell der „Security Levels“ (SL), welches von den Safety Integrity Levels (SIL) aus der Safety bekannt ist, hat für die Industrial Security etwa in eine Reihe von Teilstandards der Normenreihe IEC 62443 Einzug gehalten [5-7].
Insgesamt lässt sich feststellen, dass es für IT wie OT unterschiedliche Methoden der Bewertung des notwendigen Sicherheitsniveaus gibt, jedoch im ICS-Umfeld in der Praxis eine größere Methodenvielfalt genutzt wird. Dies passt zum besonders großen Spektrum des Schutzbedarfs von IoT (Internet of Things) bis KRITIS. Betrachten wir nun, welche Unterschiede bezüglich der Methoden der Umsetzung von Security bestehen.
 


Bild 2: Zyklen nach IEC/ TS 62443-1-1 [8].

Verantwortungszyklen

Beim Stufenmodell für ICS-Security stellt sich die Frage, an welcher Stelle und durch wen im Security-Prozess das gewünschte SL (SL-T – „Target SL“) festzulegen ist. Weder kann der Komponentenhersteller im Vorhinein genau wissen, in welchen Anlagen seine Produkte irgendwann verbaut werden könnten, noch der Maschinen- oder Anlagenbauer, welche Betreiber ihn zukünftig beauftragen werden. Der Betreiber wiederum hat in der Regel kaum direkten Einfl uss auf die Gestaltung von Komponenten – höchstens in Form seiner Auswahl, falls der Markt und das Budget eine solche hergeben – und begrenzten auf den Systemintegrator, wenn er nicht genau weiß, wann und wie dieser zu packen ist.
Das aus der VDI/VDE 2182 [9] geerbte Bild der Verantwortungszyklen in der IEC 62443-1-1 [8] ist also in der Praxis bisher eher ein Idealbild als eine realistische Abbildung der Kommunikation im Security-Prozess.
Für eine korrekte Anwendung des Verfahrens sind also noch branchenspezifi sche Anleitungen und Prozesse zu entwickeln, wie etwa im Security-Leitfaden „Der Weg durch die IEC 62443“ für den Maschinen- und Anlagenbau unternommen [10].

Regulierung

Regulatorische Vorgaben schreiten in den verschiedenen Einsatzgebieten von ICS unterschiedlich schnell voran. Während in Deutschland im KRITIS-Bereich ab 2018 bzw. 2019 zum ersten Mal wesentliche IT-Sicherheitsmaßnahmen obligatorisch werden, sind Maschinenbauer, Komponentenhersteller und Betreiber in der Produktion abgesehen von einigen wenigen regulierten Teilsektoren bisher weitgehend außen vor. Dies birgt die Gefahr einer Marktzersplitterung, wenn irgendwann Komponenten nicht mehr nur eigens für den Einsatz in der Pharmazie, sondern auch – möglicherweise gar nach getrennten Standards – für die Nutzung im Energienetz, im Chemie- und im Stahlwerk zu zertifizieren sind. Momentan empfi ehlt es sich für alle Akteure daher, die Entwicklung der Vorgaben, insbesondere der verschiedenen Branchenspezifi schen Sicherheitsstandards (B3S) genau zu verfolgen, um vorbereitet zu sein. Zumal die Märkte mit einer gewissen Verzögerung nachziehen dürften, sobald sich Security als übliches Qualitätsmerkmal weiter durchsetzt.

Zonierung

Bei der Zonierung wird die Diskrepanz besonders deutlich. Zwar ist die Segregation von Netzen nach Schutzbedarf schon seit ca. Anfang der 2000er Jahre auch im OT-Bereich eine der wichtigsten Standardmaßnahmen, zu der viele Good Practices existieren. Auf der anderen Seite werden die vorliegenden formalen Methoden der systematischen Ableitung des Zonenmodells bis heute kaum konsequent eingesetzt. Im Gegenteil, der entsprechende Teil 3-2 der Standardfamilie IEC 62443 [11] ist besonders heftig umstritten. Schon die Diff erenzierung der Security-Level in Schutzziele („Foundational Requirements“) nach [8], welche eine einfache Vektoralgebra erfordert, wird außerhalb der Forschungs- und Normungscommunitys bislang kaum angewandt.

Pentests

Bis vor einigen Jahren herrschte die Meinung vor, dass Penetrationstests innerhalb von Produktionsnetzen zu risikoreich seien. Nun setzt sich langsam die Erkenntnis durch, dass es trotz des Risikos einer temporären Störung besser sein kann, eine Schwachstelle zu fi nden und zu beheben, bevor ein Angreifer sie entdeckt und ausnutzt. Denn der Glaube, Attacken langfristig grundsätzlich aus den eigenen Netzen heraushalten zu können, hat auch im ICS-Umfeld an Anziehungskraft verloren.
An die Stelle der Verteidigung nach dem Motto „Sieg oder Untergang“ tritt so nach und nach der Begriff der Resilienz, auch wenn bisher kaum ein Security-Standard diesen Begriff explizit nutzt. Dabei ist den Automatisierern das Konzept nicht fremd, wird doch in der Safety traditionell immer davon ausgegangen, dass – statistisch – etwas passieren wird. Pentests, ursprünglich als primär präventive Maßnahme ersonnen, erhalten so quasi als Nebenprodukt eine reaktive Komponente. Darüber hinaus werden selbstverständlich im Rahmen von Pentests nicht nur im Industriebereich als „Beifang“ regelmäßig auch bereits geschehene Vorfälle und sogar laufende Angriffe entdeckt werden (=detektive Maßnahme).

Technische Maßnahmen

Übliche technische IT-Sicherheitsmaßnahmen wie Firewalls, Virenschutz oder Mehrfaktorauthentifizierung haben heute auch in die Industrial Security weitgehend Einzug gehalten. Die beiden relevanten Unterschiede zur Enterprise- IT liegen zum einen begründet im Lebenszyklus: Langlaufende Maschinen werden ggf. erst nach 20 Jahren modernisiert. Zum anderen folgen sie aus der Komplexität der Systeme: Entweder ist eine Anlage vom Systemintegrator „mit AutoSec“ zu bekommen (und bezahlbar) – oder eben nicht, der Betreiber wird sie in letzterem Fall kaum eigenständig komplett Security-technisch aufrüsten können und dürfen. Dazu kommt, dass nicht bei jedem Betreiber bereits eine OT-fokussierte Security- Organisation etabliert ist, die Konfiguration, Monitoring und Response geeignet ausfüllen könnte.

Next Generation: Anomalieerkennung und Co.

Beinahe mehr noch als in der Office-IT wird in der OT-Security mit Marketingbegriffen wie Anomalieerkennung und maschinellem Lernen hantiert. Nicht wenige „ICOs“ (Initial Coin Offerings, also auf Kryptowährungen basierende Finanzierungsmodelle, insbesondere für Start-ups) zielen auf die Bereiche Utilities oder IoT ab. Es entsteht fast der Eindruck, als könne die zerklüftete Security-Landschaft im industriellen Bereich gleichsam über die Reifegrad- Tiefebene der „Standardsecurity“ gehievt und direkt in die next generation katapultiert werden. Dabei ist klar, dass sich ein niedriger Reifegrad bei den Prozessen nie allein durch eine Aufrüstung auf der technischen Seite ausgleichen lässt.

Fazit: Fraktaler Reifegrad

In allen betrachteten Dimensionen lässt sich feststellen, dass die Security-Toolbox für den Bereich der ICS heute theoretisch reich ausgestattet ist und wenn nicht in Technologien, so doch in methodischen Modellen der Enterprise- Security teilweise sogar voraus ist. In der Praxis zeichnet sich jedoch ein anderes Bild ab. Der Reifegrad der OT-Security kann hier in mehrfacher Hinsicht als fraktalisiert bezeichnet werden im Sinne einer Struktur, die bei genauerer Betrachtung komplexer und vielfältiger wird:
So ist zwar das Security-Niveau in der Produktion im Mittel unter dem durchschnittlichen Reifegrad von Unternehmen ohne ICS zu sehen, aber in der OT zeigen sich extremere Unterschiede im Vergleich zwischen unterschiedlichen Sektoren und Unternehmensgrößen, mithin deutlichere Ausreißer nach oben wie nach unten. Neben den langen Lebenszyklen dürfte ein wichtiger Grund darin zu suchen sein, dass die seit vielen Jahrzehnten eingeübten und stetig verbesserten Methoden der Safety und der Operational Security bestimmten Zielen der Informationssicherheit wie dem Schutz der Verfügbarkeit und der Wiederanlauffähigkeit in die Hände spielen. Allgemeiner könnte man sagen, dass einige Dimensionen der Resilienz von Industrieunternehmen traditionell gut beherrscht werden. Dort, wo statistisch schwer vorhersagbare, gezielte Angriffe auf die Integrität oder Vertraulichkeit drohen, ist damit allein jedoch wenig geholfen. Es ist hier im Gegenteil sogar besonders komplex, die Widersprüche zwischen Verfügbarkeit und Integrität sowie zwischen Verfügbarkeit und Vertraulichkeit in den organisatorischen Griff zu bekommen. Die OT-Security muss hier also nicht nur „einfach“ noch weiter aufholen und ihre soliden Konzepte stärker in die Praxis umsetzen, sondern bestimmte Grundfragen der Security dringender lösen als die IT.

Schlüsselwörter:

ICS, Security-Standards, IEC 62443, Reifegrad, Security-Level, Fraktalisierung

Literatur:

[1] IETF: Request for Comments (RFC). URL: https://www.ietf. org/rfc.html, Abrufdatum 16.11.2017.
[2] Moen, R.; Norman, C.: Evolution of the PDCA Cycle. 2009. URL: http://www.westga. edu/~dturner/PDCA.pdf, Abrufdatum 16.11.2017.
[3] ISO: ISO/IEC 27001:2013: Information technology, security techniques, information security management systems requirements. 2013.
[4] BSI: BSI-Standard 200-2 – IT-Grundschutz-Methodik, Version 1.0, Community Draft. 2017. URL: https://www.bsi. bund.de/SharedDocs/Downloads/ DE/BSI/Grundschutz/ IT-Grundschutz-Modernisierung/ BSI_Standard_200-2. pdf, Abrufdatum 16.11.2017.
[5] IEC: IEC 62443-3-3 (ISA: ISA- 62443-3-3): Industrial communication networks – Network and system security – Part 3-3: System security requirements and security levels, Edition 1.0. 2013.
[6] ISA: ISA-62443-4-1 (IEC 62443- 4-1): Security for industrial automation and control systems – Product development requirements, 2016. URL: http:// isa99.isa.org/ISA99%20Wiki/ WP_List.aspx, Abrufdatum 02.11.2017.
[7] ISA: ISA-62443-4-2 (IEC 62443- 4-2): Security for industrial automation and control systems – Technical security requirements for IACS components. 2017. URL: http://isa99.isa. org/ISA99%20Wiki/WP_List. aspx, Abrufdatum 02.11.2017.
[8] ISA: ISA-62443-1-1 (IEC/TS 62443-1-1): Security for industrial automation and control systems – Models and Concepts. 2017. URL: http:// isa99.isa.org/ISA99%20Wiki/ WP_List.aspx, Abrufdatum 02.11.2017.
[9] VDI/VDE: VDI/VDE 2182: Informationssicherheit in der industriellen Automatisierung – Allgemeines Vorgehensmodell, Blatt 1. 2011.
[10] VDMA/HiSolutions: Leitfaden Security für den Maschinenund Anlagenbau. Der Weg durch die IEC 62443, Version 1.0. 2016. URL: https://www. hisolutions.com/DE/Ueber_ uns/Presse/Security-Leitfaden_ Maschinen-und_Anlagenbau. php, Abrufdatum 02.11.2017.
[11] ISA: ISA-62443-3-2 (IEC 62443- 3-2): Security for industrial automation and control systems – Security risk assessment and system design. 2017. URL: http://isa99.isa.org/ISA99%20 Wiki/WP_List.aspx, Abrufdatum 02.11.2017.