Security by Design Decisions (German Version)

Security-Entscheidungen in das Engineering automatisierter Anlagen integrieren

Security by Design haben Sie mit Sicherheit schon einmal gehört; es ist ein Buzzword geworden. Im Rahmen des Forschungsvorhabens IDEAS entwickeln wir ein Konzept, wie Security-Entscheidungen möglichst früh — eben “by design” — in das Engineering automatisierter Anlagen integriert werden kann. Das Konzept heißt “Automation Security by Design Decisions”.

Bevor es losgeht, müssen wir aber zwei Fragen klären: Erstens, warum alle unbedingt Security by Design wollen. Zweitens, wie wir Security by Design eigentlich definieren.

Warum brauchen wir eigentlich Security by Design?

Weil man Security so schlecht sehen und anfassen kann, stellen wir uns einmal vor, der Zweck von Security wäre, dass kein Wasser aus einem Rohr austritt. Wir nennen die Disziplin „Dichtungsingenieurwesen“ und nehmen an, sie sei neu.

Jetzt stellen wir uns vor, Rohre würde ohne Dichtungsingenieure engineered, und die „Dichter“ würden — wie momentan die Security-Ingenieure — erst dazugeholt, wenn das Rohr eigentlich schon fertig, vielleicht sogar in Betrieb ist.

Was können sie dann noch tun? Klar, einfach ein Schild aufstellen: Achtung, Rohr undicht. Dann wissen die Leute immerhin Bescheid und können um die Pfütze drumherum laufen, statt nasse Füße zu bekommen.

Das ist unbefriedigend, weil bei vielen Pfützen irgendwann alles unter Wasser steht. Also, nächster Versuch: Eimer unter die undichte Stelle.

Ebenfalls unbefriedigend, denn das Rohr hat ja einen Sinn: Wasser von A nach B befördern. Und B ist nicht der Eimer… Also: Die undichten Stellen überkleben — Pflaster drauf.

Blöd nur, dass bei der Materialauswahl die Dichtungsingenieure nicht gefragt wurden, und das Rohrmaterial super wasserabweisend ist. Leider auch Pflaster-abweisend…hält nicht so toll. Und eigentlich wäre es ja auch viel besser, man würde vermeiden, dass durch Löcher überhaupt Wasser austreteten kann. Leider kann die Rohrbauweise nun nicht mehr geändert werden, aber es gibt ja Dichtungsflüssigkeit — kennen Sie vielleicht vom Auto oder Fahrradreifen— die Lecks verschließen kann.

Da muss man natürlich dran denken, dass man die Flüssigkeit auch jedes Mal beim Befüllen des Rohrs mit hinzugibt. Puh, damit das keiner vergisst, legen wir lieber mal ein ausführliches Handbuch dazu für die Rohrbenutzer.

Was sehen wir? Aus dem eigentlich eleganten, schönen, ausdesignten Rohr ist nun ein ganz schön hässliches und umständlich zu benutzendes Teil geworden. Und ähnlich machen wir es in der Security:

• Wir versuchen mit „Warnschildern“ (Awareness-Trainings), Nutzer vor dem Klicken auf böse Links zu bewahren.
• Wir versuchen mit „Eimern“ (Virenschutzprogrammen), Schadsoftware aufzufangen, bevor sie ausgeführt wird.
• Wir versuchen mit „Pflastern“ (Software-Updates) Schwachstellen zu schließen.
• Wir versuchen mit „Dichtungsmasse“ (User Policies), die Benutzung der Systeme sicherer zu machen.

Sie kennen das vielleicht: Security macht nichts als Ärger, und Produkte schwierig benutzbar. Das liegt auch daran, dass Security immer erst als allerletztes bedacht wird. Hätte man die Dichtungsingenieure gleich von Anfang an hinzugezogen, hätten sie beim Rohrmaterial, bei der Wanddicke, bei der Auslegung der Flansche mitreden können. Das hätte ein schönes Rohr ergeben, das „dicht by design“ ist, auch wenn man ihm das gar nicht ansieht.

Frühe Security-Entscheidungen sind besser als späte Entscheidungen und Nutzen von systemimmanenten Fähigkeiten ist besser als „angeflanschte“ Workarounds.

Das gilt auch für Security in der Automatisierung: „Security by design“ macht Systeme auf effizientere Art sicher, indem Security bereits im Engineering-Prozess mit berücksichtigt wid. Es weiß nur keiner, wie das praktisch gehen soll, auch weil bei automatisierten Anlagen noch ein paar mehr Disziplinen mitspielen als bei der Auslegung eines Rohrs.

Definition: Security by Design

Nun zur versprochenen Defininition. Wir brauchen für die Definition drei Aspekte.

In grau: Den Automation-Engineering-Workflow, mit dem das zu schützende System designt wird (zum Beispiel bestehend aus Basic Engineering, Detail Engineering, usw….).

In blau: Einen Security-Engineering-Workflow, mit dem Security-Entscheidungen getroffen werden.

In rot: Einen Integrationsmechanismus, mit dem die Security-Entscheidungen in den Automation-Engineering-Workflow integriert werden, und zwar früh genug, um wichtige Design-Entscheidungen (grün) noch beeinflussen zu können.

Damit landen wir bei folgender Definition:

Security by Design ist die ausreichend frühe Integration von Security-Entscheidungen in einen existierenden Engineering-Workflow, sodass wichtige Design-Entscheidungen noch beeinflusst werden können.

Existierende Ansätze für Security by Design kann man gut an ihren Integrationsmechanismen unterscheiden:

• Bei der Verschmelzung wird der Basis-Workflow so modifiziert, dass er Security Engineering enthält.
  Beispiele aus dem Software-Engineering sind Microsofts „Security Development Lifecycle“ oder auch — etwas moderner — DevSecOps.
• Bei der Harmonisierung wird der Security-Engineering-Workflow dem Basis-Workflow so ähnlich wie möglich gemacht, sodass er einfach integrierbar ist.
  Beispiele finden sich hier im Model-based Systems Engineering: Für die Modellierung mittels UML gibt es die Security-Ergänzung “UMLsec”, für SysML gibt es “SysMLsec”.
• Bei der Kopplung bleiben beide Workflows unverändert, aber es werden feste Kopplungspunkte im Basis-Workflow definiert, an denen Informationen ins Security-Engineering eingebracht werden und Ergebnisse aus dem Security-Engineering in den Basis-Workflow zurückfließen — und zwar vor den wichtigen Design-Entscheidungen (den grünen Punkten):
  Beispiele sind im Bereich Security for Safety zu finden. Sowohl der IEC TR 63069:2019 als auch der noch im Entwurf befindliche ISA TR84.00.09 Ed3 verwenden diesen Ansatz des „Co-Engineerings”.
• Die Auslösung ist ein Spezialfall der Kopplung mit nur einem Kopplungspunkt: wenn der Basis-Workflow an einem bestimmten Punkt ist, wird auf Basis dort vorhandener Informationen der Security-Engineering-Workflow ausgelöst.
  Beispiele kommen auch hier wieder aus dem Bereich Security for Safety (Security PHA), aber auch aus dem Bereich Security kritischer Infrastrukturen mit INL’s Consequence-driven, Cyber-informed Engineering (CCE).

All diese Ansätze haben eines gemeinsam: Sie funktionieren nur, wenn ich weiß, wie mein Engineering-Workflow aussieht. Sie sind also abhängig vom Basis-Workflow. Methoden, bei denen die Security vollständig mit dem Basis-Workflow verschmilzt, natürlich mehr, als solche, bei denen nur ein einzelner Triggerpunkt im Basis-Workflow definiert wird.

Hier liegt aber auch ein Problem: Je abhängiger Security by Design vom Basis-Workflow ist, desto schlechter ist die Methode auf andere Workflows übertragbar.

Wie viele Unternehmen kennen Sie, die denselben Engineering-Workflow für ihre Automatisierungssysteme nutzen? Ja, wie viele Projekte innerhalb ein und desselben Unternehmens kennen Sie, die denselben Engineering-Workflow nutzen?

Der Basis-Workflow ist sehr unterschiedlich je nach Branche, Region, Unternehmen, Projekt… Und die Variationen nehmen eher noch zu, durch individuellere, modularisierte Anlagen und Industrie 4.0. Wenn ich dann jedes Mal neu definieren muss, wie Security by Design funktioniert, hat das keine Zukunft.

Security by Design muss unabhängig von der Art des Automation-Engineering-Workflows gelingen.

Security by Design Decisions — Einführung ins Konzept

Nun, da wir Security by Design definiert haben und das Problem klarer ist, möchte ich Ihnen ein Konzept vorstellen, das wir „Security by Design Decisions“ getauft haben. Es rückt nicht einen Prozess oder Phasen, sondern Entscheidungen, genauer Entscheidungspunkte in den Mittelpunkt. Sie werden gleich sehen, warum das wichtig ist.

Sie können sich das Konzept grundsätzlich als als Sack roter Dreiecke vorstellen. Jedes rote Dreieck ist ein Entscheidungspunkt.

Das Konzept besteht aus zwei Teilen:

1. Im ersten Teil schauen wir nur von außen auf den Entscheidungspunkt, quasi auf sein Etikett und beantworten die Frage, WANN wir eine Security-Entscheidung treffen.
2. Im zweiten Teil machen wir den Entscheidungspunkt transparent, schauen ins Innere und bentworten die Frage, wie wir die Security-Entscheidung treffen.

1. Wann treffe ich eine Security-Entscheidung?

Sie erinnern sich an den Integrationsmechanismus „Kopplung“, bei dem beide Workflows weiter eigenständig funktionieren? Die einzige Abhängigkeit zum Basis-Workflow ist, dass man feste „Einhakpunkte“ für die Security-Entscheidungen definieren muss. Diese Einhakpunkte lösen wir nun in unserem Konzept und definieren stattdessen sogenannte Entscheidungspunkte — Sie sehen sie als rote Dreiecke in der Grafik — die alle notwendigen Informationen enthalten, um eine Security-Entscheidung an die richtige Stelle in einen beliebigen Basis-Workflow „einzuhaken“ und dann zu treffen.

Wir definieren also für unser Security-by-Design-Decisions-Konzept gar keinen neuen Workflow und setzen gar keine besonderen Eigenschaften des existierenden Workflows voraus — wir definieren nur zu treffende Entscheidungen. Der zugehörige Entscheidungspunkt enthält alle Informationen für die Kopplung der Entscheidung an den Basis-Workflow und schließlich zum Treffen der Entscheidung.

Die Frage, wo ein Entscheidungspunkt eingehakt werden muss, also wann eine Security-Entscheidung spätestens getroffen werden muss, kann mit den Informationen auf dem „Etikett“ des Entscheidungspunkts beantwortet werden.

Wir schauen uns das anhand des beispielhaften Entscheidungspunkts „DP1 — Prozessnahe Komponenten“ an. Er ist einer von neun Entscheidungspunkten, die wir in einer Analyse realer Engineering-Workflows bei unseren Anwendungspartnern INEOS und HIMA identifiziert haben.

Das Etikett enthält eine Liste von operativen Funktionen, die potenziell durch die Security-Entscheidung beeinflusst werden — für die prozessnahen Komponenten wären das beispielsweise die Aufnahme und Übermittlung von Messwerten, das physische Beeinflussen des Prozesses oder die Änderung eines Steuerungs-Betriebsmodus.

Sie können sich diese operativen Funktionen als die grünen Punkte vorstellen, die wir oben zur Veranschaulichung wichtiger Design-Entscheidungen genutzt haben. Die grünen Punkte helfen bei der Verankerung der Security-Entscheidungen im Automation-Engineering-Workflow. Spätestens, wenn festgelegt wird, wie diese operativen Funktionen realisiert werden, müssen auch die Security-Entscheidungen dieses Entscheidungspunkts getroffen werden.

Hier ist ein Beispiel, wie alle Entscheidungspunkte in einen Automation-Engineering-Workflow integriert werden können. Wir schauen uns wieder nur den ersten Entscheidungspunkt DP1 an (gelb hervorgehoben): In unserem Beispiel werden die relevanten Design-Entscheidungen im Rahmen der Erstellung der Tag-Liste und der Cause-Effekt-Matrix getroffen.

Jetzt haben wir geklärt, wie Sie die Security-Entscheidungspunkte in Ihrem individuellen Engineering-Workflow platzieren und damit Ihren eigenen Security-by-Design-Workflow zusammenbauen.

2. Wie treffe ich eine Security-Entscheidung?

Die viel interessantere Frage ist natürlich noch offen: was ist denn jetzt eigentlich eine Security-Entscheidung und wie treffen Sie die?

Auch dabei helfen Ihnen die Entscheidungspunkte; diesmal reicht aber nicht der Blick aufs Etikett, sondern wir müssen in einen Entscheidungspunkt hineinschauen.

Bevor wir das tun, versuchen wir aber erst einmal zu verstehen, was eigentlich eine Security-Entscheidung ist. Formell: Die Festlegung von Security-Anforderungen und Lösungen, die diese Anforderungen unsetzen.

Und praktisch?

Schauen wir mal in einen Beispielscope. Sie sehen hier ein exemplarisches OT-Netzwerk, ganz unten in hell- und dunkelblau die Feld- und Steuerungsebene, darüber in grün die Leitebene, dann — durch eine Firewall getrennt, wie es sich gehört, ein Büronetzwerk in gelb. Und in rot sehen Sie Beispiele dafür, was alles security-relevante Entscheidungen sein könnten. Wir sehen: Auf Security-Entscheidungen steht nicht immer auf den ersten Blick „Security“ drauf. Security-Entscheidungen sind vielmehr ein Sammelsurium kleiner Entscheidungen über verschiedene Gewerke hinweg.

Das bedeutet: Auch, wenn Sie überhaupt kein Security-by-Design-Konzept haben — Sie treffen trotzdem ständig Security-Entscheidungen.

Es ist unmöglich, KEINE Security-Entscheidungen zu treffen. Wichtig ist, sie sichtbar zu machen.

Security by Design muss Ihnen also helfen, die vielen unsichtbaren Security-Entscheidungen sichtbar zu machen und sie bewusst zu treffen.

Und genau darum geht es im Inhalt jedes Entscheidungspunktes: Darum, für den Scope eines Entscheidungspunktes die security-relevanten Informationen aus dem Basis-Workflow so sichtbar zu machen, dass Sie auf dieser Basis bewusste Security-Entscheidungen treffen können.

Dafür beinhaltet der Entscheidungspunkt Informationen gebündelt in einen Security-Entscheidungsraum (lila) und einen Security-Problemraum (grau).

Der Entscheidungsraum enthält Security-Parameter, also das Sammelsurium an kleinen Entscheidungen, die potenziell die Security Ihres Systems beeinflussen — z.B. der Wechselmechanismus für Steuerungs-Betriebsmodi.

Der Problemraum enthält einerseits aus dem Basis-Workflow bekannte unerwünschte Ereignisse,
z.B. Überdruck im Kessel, und andererseits mögliche Angriffspunkte, die zu diesen unerwünschten Auswirkungen führen können. Wir nennen diese Angriffspunkte auch „Indicators of Insecurity“ und werden gleich im Beispiel sehen, warum.

Zurück zum Beispiel: Wir müssen Ordnung in das unstrukturierte Sammelsurium von potenziell security-relevanten Informationen bringen, und das erste Konzept für Ordnung haben wir schon kennen gelernt: Es sind die operativen Funktionen.

Während auf dem Etikett des Entscheidungspunktes aber nur Titel der Funktionen standen, sehen sie hier nun einmal eine im Detail: Die Funktion „SPS programmieren“. Der Einfachheit halber nehmen wir an, es gäbe nur einen Weg, um die SPS im Beispiel zu programmieren, und zwar lokal mit einem tragbaren Programmiergerät. Die operative Funktion beinhaltet alle Informationen darüber, wie das Programmieren funktioniert: Welche menschliche Rolle es kann, welches Programmiergerät sie benutzt, welches Übertragunsprotokoll zwischen Programmiergerät und SPS gesprochen wird.

Die operativen Funktionen sind ein guter Filter für security-relevante Informationen: Um im Informationswust nicht unterzugehen, schauen wir uns nur die Informationen an, die im Kontext der gerade betrachteten operativen Funktion relevant sind. Die Funktion gibt somit den security-relevanten Informationen ihren operativen Kontext.

Nun schauen wir in den Security-Entscheidungsraum, der die Security-Entscheidungen in Form von Security-Parametern sichtbar macht: Ist die Programm-Aktualisierung während des SPS-Betriebs erlaubt? Hat die SPS Integritätsschutz für ihre Logik? Wie kann zwischen Betriebsmodi gewechselt werden?

Nicht alle Security-Parameter können in jedem Fall auch durch die Security entschieden werden. Anforderungen anderer Gewerke oder einfach technisch limitierte Möglichkeiten können dazu führen, dass für die Security keine Auswahlmöglichkeit mehr besteht. In unserem Beispiel steht schon fest, dass die Programm-Aktualisierung im Betrieb erlaubt sein muss; daher ist dieser Parameter fixiert.

Nun, da die Security-Parameter geklärt sind, kann eine andere Perspektive auf die Funktion eingenommen werden: Der Security-Problemraum kann betreten werden.

Hier ist nun alles interessant, was ein potenzieller Angriffspunkt ist. Das ist nicht dasselbe wie eine Schwachstelle. Ein Angriffspunkt kann eine Schwachstelle sein (wie hier im Beispiel eine Schwachstelle des Programmiergeräts), aber es können auch einfach intendierte Design-Entscheidungen sein, die aus Security-Sicht problematisch sind.

Aus den Angriffspunkten könnte man sich nun Angriffsszenarien zusammenbauen, aber wir begnügen uns hier mit dem Ergebnis eines Angriffs, mit einem unerwünschten Ereignis. Das Ereignis ist auch eine Information, die aus dem Automation-Engineering-Workflow kommt. Ein Beispiel für die operative Funktion „SPS Programmieren“ bzw. für die SPS und ihre zugehörigen Aktoren: Die Gefahrensituation „Überdruck im Kessel“.

Dazu kann man sich nun ein Security-Ziel überlegen, um dies zu vermeiden. Beispiel hier: Die Integrität der Ausgangswerte für eine Pumpe X und eine Heizung Y in der SPS.

Zurück in den Entscheidungsraum, das Security-Ziel nehmen wir mit. Von unseren verbliebenen variablen Parametern: Welche müssen wir wie setzen, um die Integrität der Ausgangswerte für die Pumpe und die Heizung in der SPS sicherzustellen?

Naheliegend in unserem vereinfachten Beispiel ist der Integritätsschutz, und zwar ein möglichst guter — wir fixieren also den Wert dieses Security-Parameters auf die Option „Hash“. Natürlich könnte man auch den Wechsel der Betriebsmodi mit hohen Hürden versehen und einen physischen Schlüsselschalter fordern.

Ausblick: Ein Tool für Security by Design Decisions

Nun kennen Sie die wichtigsten Eckpfeiler unseres Security by Design Decisions-Konzepts. Könnten Sie jetzt loslegen?

Vermutlich nicht.

Denn Sie fragen wahrscheinlich zurecht, wer Ihnen denn die ganzen lila Security-Parameter liefert und wer zur Hölle diese ganzen schönen Bilder malen und pflegen soll. Zurecht!

Daher arbeiten wir momentan in unserem Forschungsprojekt gemeinsam mit INEOS und HIMA an einem Demonstrator für ein Software-Werkzeug.

Das Frontend leitet durch den Entscheidungspunkte-Prozess, hilft beim Platzieren des Entscheidungspunkts im bestehenden Prozess und dann auch beim Treffen der Security-Entscheidungen auf Basis von Diagrammen, wie Sie sie gerade gesehen haben. Denn es ist so: Wir wissen, dass die Grafiken wichtig sind, damit Ingenieure mit knappen Zeitbudget ihren Security-Entscheidungsraum schnell erfassen können. (Sie wollen die Security-Parameter wirklich nicht als endlose Excel-Liste bearbeiten!).

Die Vielzahl von relevanten Informationen, um Security-Entscheidungen zu treffen, ist für Menschen am besten visuell erfassbar.

Das Backend beinhaltet ein Datenmodell, sodass die Entscheidungsraum- und Problemraum-Diagramme als verschiedene Sichten auf die Daten jederzeit generiert werden können. Außerdem macht es die Datenbasis effizient pflegbar und exportierbar. Das Datenmodell — auf Basis von AutomationML — entwickeln unsere Forschungspartner von der Hochschule Pforzheim.

Das dritte Feature des geplanten Demonstrators sind Bibliotheken. Denn ein ganz großer Game Changer der Security-Entscheidungspunkte ist, dass sie Security-Parameter sichtbar machen — dafür müssen aber diese Security-Parameter erst einmal gefunden werden. Und diese Arbeit möchte nicht jeder von Ihnen neu machen. Bibliotheken sind denkbar pro Komponententyp, pro operativer Funktion oder auch pro Hersteller. Außerdem: Mit einer guten Bibliothek als Beispiel lernt sich eine neue Methode viel angenehmer.

Wenn Sie nach dem Lesen dieses Texts alles wieder vergessen, was Sie über Security by Design für Automatisierungssysteme gelesen haben — diese drei Kernbotschaften sollten Sie mitnehmen:

• Security by Design muss unabhängig von der Art des Automation-Engineering-Workflows gelingen.
• Es ist unmöglich, keine Security-Entscheidungen zu treffen. Security by Design muss sie sichtbar machen.
• Die Vielzahl von relevanten Informationen, um Security-Entscheidungen zu treffen, ist für Menschen am besten visuell erfassbar.

Ich hoffe, wenn Sie jemand auf Security by Design anspricht, sagen Sie ab jetzt „klar, ist eigentlich nur ein Sack roter Dreiecke!“.

Diese Arbeit wird gefördert vom Bundesministerium für Bildung und Forschung im Rahmen des Forschungsvorhabens “IDEAS”. Das dazugehörige wissenschaftliche Paper ist im Tagungsband des AUTOMATION-Kongresses erschienen, der vom 28.-29. Juni 2022 in Baden-Baden stattgefunden hat.