IT-Security-Management Gegen alle Risiken gewappnet – Bedrohungsanalyse in Produktionsnetzwerken

Soll ein IT-Security-Management in der Produktion aufgebaut werden, gilt es die Bedrohungen und Risiken zu bewerten sowie wirtschaftliche Gegenmaßnahmen zu ergreifen.

Anbieter zum Thema

PFLITSCH GmbH & Co. KG

compmall GmbH

SMC Deutschland GmbH

Phoenix Contact GmbH & Co. KG

Als Basis zur Umsetzung des IT-Security-Managements müssen die zu schützenden Werte identifiziert werden. Sie reichen von der Verfügbarkeit der Produktionseinrichtungen über das spezifische Know-how bis zu den Sachwerten von Maschinen und Anlagen. Nachdem die relevanten Bedrohungen ermittelt worden sind, lassen sich die Risiken beurteilen sowie angemessene Gegenmaßnahmen planen. In diesem Zusammenhang ist zwischen den Blickwinkeln eines Betreibers und eines Produkt- oder Lösungsanbieters zu unterscheiden.

Gemäß Glossar des IT-Grundschutzes [1] handelt es sich bei einer Bedrohung um einen „Umstand oder Ereignis, durch den oder das ein Schaden entstehen kann“. Die Erfassung der Bedrohungen fällt unter Umständen sehr umfangreich aus. Eine gute Unterstützung bieten verfügbare Kataloge, wie der Gefährdungskatalog aus dem IT-Grundschutz [1]. Für bestimmte Szenarien existieren spezielle Kataloge, beispielsweise aus dem Open Web Application Security Project [2] für Web-Anwendungen. Zum Einstieg in die Bedrohungsanalyse sollte der Fokus auf den größten Schadenspotenzialen liegen. In einer Fertigungsanlage könnte dies ein Produktionsausfall sein.

Bildergalerie

Unterschiedlicher Blickwinkel von Betreiber und Anbieter

Der Betreiber kennt seine Anwendungsbedingungen und kann daher die mögliche Schadenshöhe angeben sowie für die Risikobewertung eine wirtschaftliche Abwägung hinsichtlich der Angemessenheit von Gegenmaßnahmen treffen. Als Risk Owner hat er die Möglichkeit, auf für ihn unrentable Aktivitäten zu verzichten und stattdessen ein Risiko zu akzeptieren. Wichtig ist in diesem Kontext, dass die Bedrohungen und Risiken als Entscheidungsgrundlage transparent und vollständig vorliegen.

Der Anbieter eines Produkts oder einer Lösung muss seine Bedrohungs- und Risikoanalyse hingegen auf Annahmen stützen. Diese Vermutungen sollten die künftigen Einsatzbedingungen, die sich an den Kenntnissen des Anbieters über den Markt orientieren, möglichst gut widerspiegeln. Für den Anbieter erweisen sich nur die Bedrohungen als relevant, die sein Angebot im Rahmen der Anwendungsszenarien direkt betreffen. Er beschreibt dann in seiner Security-Dokumentation den bestimmungsgemäßen Gebrauch, sodass der Käufer, der Betreiber selbst oder ein anderer Beteiligter in der Wertschöpfung die Eignung des Produkts/der Lösung für seine Zwecke einschätzen kann. Der Anbieter führt nun ebenfalls seine Risikobewertung durch und setzt die Aktivitäten um, welche die Security-Risiken adressieren. Er ist dabei an seine zugesagten Security-Eigenschaften gebunden und kann Risiken nicht stillschweigend billigen, weil ihm etwa die für Gegenmaßnahmen anfallenden Kosten nicht angemessen erscheinen. In einem solchen Fall müsste der Anbieter entweder den bestimmungsgemäßen Gebrauch einschränken oder die verbleibende Bedrohung direkt dokumentieren und gegebenenfalls externe kompensierende Maßnahmen vorschlagen. Auf der Grundlage dieser Informationen kann der Käufer wiederum eine Entscheidung fällen.

Genaue Betrachtung des Zusammenwirkens von Einzelaspekten im System

Möchte der Anbieter eine technische Risikobewertung vornehmen, muss er das Schadensausmaß technisch verstehen. Das Common Vulnerability Scoring System (CVSSv3) empfiehlt eine Aufteilung, deren höchste Stufe als „kritisch“ bezeichnet wird. Im Fall eines Datenverlusts könnten sich die Auswirkungen beispielsweise von „unwichtige Daten verloren“ bis „wichtige Daten verloren und nicht wieder herstellbar“ erstrecken. Zur Beurteilung der Wahrscheinlichkeit des Auftretens von Risiken werden häufig die Faktoren erforderliches Know-how und Ressourcen sowie der Angriffsweg und notwendige Voraussetzungen zugrunde gelegt. Letztlich basieren sowohl das Schadensausmaß als auch die Eintrittswahrscheinlichkeit auf einer Experteneinschätzung, die von den vorgesehenen Einsatzbedingungen abhängt.

Ein Spannungsfeld in der Bedrohungs- und Risikoanalyse stellt das Zusammenwirken von Einzelaspekten im System dar. Um ein sicheres System aufzubauen, werden sichere Komponenten benötigt. Das erzielbare Security-Niveau hängt aber nur sehr indirekt von den Security-Eigenschaften der Geräte ab. So lassen sich beispielsweise unsichere Komponenten in einem sicheren System betreiben, sofern sie durch vorgeschaltete Maßnahmen – wie eine Firewall – isoliert und lediglich von anderen sicheren Systemen ansprechbar sind. Umgekehrt können Geräte mit einem hohen Security-Niveau falsch verwendet und konfiguriert werden, was zu einem unsicheren Gesamtsystem führt.

Sofortige Einleitung von Gegenmaßnahmen bei Schwachstellen

Die Risikobewertung für eine Komponente oder ein System kann sich schnell verändern, wenn eine Schwachstelle gefunden wird. Die Ursache liegt oftmals in einem Implementierungsfehler. Es sind jedoch auch schon Fehler in öffentlich empfohlenen Algorithmen und Protokollen entdeckt worden. Zur Einschätzung des Schweregrads einer Schwachstelle hat sich das bereits erwähnte Common Vulnerability Scoring System (CVSS) durchgesetzt, das aktuell in der Version 3.0 vorliegt [3]. Ähnlich wie bei der normalen technischen Risikoanalyse wird die Ausnutzbarkeit des Fehlers auf der Grundlage des Angriffsvektors und der Angriffswege beurteilt. Außerdem erfolgt eine Bewertung der Auswirkungen im Hinblick auf die Vertraulichkeit, Integrität und Verfügbarkeit („Base Score“). Im Ergebnis erhält der Anwender nur eine Zahl zwischen 0 und 10 zur Einschätzung.

In diesem Fall gilt ebenso, dass eine Schwachstelle in einer Komponente nicht zwingend in der gleichen Beurteilung auf der Systemebene resultieren muss. Ein kritischer Fehler in einer Komponentenfunktion kann keinerlei Auswirkungen auf die Systemebene haben, sofern die Funktion selbst nicht relevant oder zugänglich ist. Aus Betreibersicht ist es durchaus möglich, dass die Bewertung der Schwachstelle zu anderen Ergebnissen führt, weil der Anbieter von einem angenommenen Einsatzszenario ausgeht, der Betreiber aber davon abweichende Schutzziele hat. Das CVSS umfasst daher auch eine Einschätzung über die realen Anwendungsbedingungen („Environmental Score“). Grundsätzlich sollten Schwachstellen jedoch über die Zulieferkette verfolgt, die entstehenden Risiken bewertet und Gegenmaßnahmen eingeleitet werden. Im Automatisierungsumfeld ist dabei immer das Risiko einer Fehlfunktion nach einem Patch mit zu betrachten.

Sicherheit

Warum IT-Security einen ganzheitlichen Ansatz erfordert

Umfassende Unterstützung über die gesamte Prozesskette

Phoenix Contact steht seinen Kunden über die gesamte Prozesskette mit standardisierter Security zur Seite. Bei der Bestandsaufnahme und Bedrohungsanalyse bestehender oder geplanter Anlagen bilden individuelle Dienstleistungsangebote die Basis für die Umsetzung von Security-Konzepten. Darüber hinaus werden für verschiedene Branchen sichere Automatisierungslösungen zur Verfügung gestellt. Zum Aufbau sicherer Netzwerke tragen nicht zuletzt die entsprechenden Security-Komponenten wie Firewalls und sichere Steuerungen des Unternehmens bei, die in Kombination mit den Sicherheitsfunktionen anderer Komponenten wirken.

Vom sicheren Entwicklungsprozess bis zum kontinuierlichen Schwachstellenmanagement des Phoenix Contact PSIRT (Product Security Incident Response Team) ist Security dazu im kompletten Lebenszyklus der Produkte und Lösungen verankert. Erfahrung und Wertschöpfungstiefe unterstützen die Anwender ferner bei der Erreichung ihrer Security-Qualitätsziele.

Zertifizierte Entwicklung von sicheren Produkten und Lösungen

Phoenix Contact wurde als eines der ersten Unternehmen in Deutschland vom TÜV Süd nach der Normreihe für IT-Sicherheit IEC 62443-4-1 und -2-4 zertifiziert. Dies bestätigt, dass das Unternehmen

• die Entwicklung von Secure-by-Design-Produkten entsprechend dem Prozess IEC 62443-4-1 sowie

• das Design von sicheren Automatisierungslösungen gemäß dem Prozess IEC 62443-2-4

durchführt. Die Zertifizierungen unterstreichen die Strategie von Phoenix Contact, standardisierte Security in Produkten, Industrielösungen und Beratungsdienstleistungen anzubieten, um einen zukunftssicheren Betrieb von Maschinen, Anlagen und Infrastrukturen zu ermöglichen.

Als zentrale Elemente in der IEC 62443-4-1 und -2-4 fungieren eine Bedrohungsanalyse auf Basis des Anwendungsszenarios und ein Produkt- oder Lösungsentwicklungsprozess, mit dem sicher nachvollzogen werden kann, dass alle identifizierten Security-Anforderungen implementiert, verifiziert und dokumentiert werden. Zusätzlich müssen Gerätehersteller auf Security-Schwachstellen angemessen reagieren und verlässlich Security-Updates veröffentlichen. Diese Anforderung wird bei Phoenix Contact durch das etablierte Product Security Incident Response Team (PSIRT) übernommen.

Cyber Security

Proaktive Sicherheit ist jetzt das Gebot der Stunde

Literaturverzeichnis:

[1] IT-Grundschutz-Kataloge. Bundesamt für Sicherheit in der Inforamationstechnik

[2] OWASP: Open Web Application Security Project. https://www.owasp.org/

[3] FIRST. Common Vulnerability Scoring System v3.0: Specification Document

* Dr.-Ing. Lutz Jänicke, Product & Solution Security Officer im Bereich Corporate Technology & Value Chain, Phoenix Contact GmbH & Co. KG, Blomberg

(ID:45874212)