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

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 spezifischen 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 verpflichten. Dies trifft 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.

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

Der IT-Grundschutz als spezifisch 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 definiert, 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

Zum Weiterlesen klicken Sie hier