Ein Security-Engineering-Werkzeug für Automatisierer
BMBF-Projekt IDEAS: Integrated Data Models for the Engineering of Automation Security
Automatisierungsingenieure kennen das Problem: Sie dürfen mit dem Engineering von Leitsystem, Steuerung und Feldbussen oft erst dann beginnen, wenn alle anderen Gewerke — Elektroplanung, Mechanik, Verfahrenstechnik etwa — schon wegweisende Entscheidungen getroffen haben.
Security Engineering hat das gleiche Problem, nur noch einen Schritt später: Es beginnt oft erst dann, wenn auch die Automatisierungsingenieure fertig sind, oder sogar erst nach der Inbetriebnahme der Anlage.
Security by Design sieht anders aus.
Security? Machen die anderen…
Eine Ursache: Für Automatisierer ist Security immer noch oft das, was die IT-Abteilung macht. Die Spielverderberdisziplin, von der ständig unrealistische Anforderungen kommen (Zwei-Faktor-Authentifizierung? Junge, die in der Leitwarte schauen sowieso laufend auf den Bildschirm!).
Für Hersteller ist Security das, was man ja wirklich gern machen würde, wenn der Betreiber es denn bezahlen würde. Für Betreiber: Das, worin man so viel besser wäre, wenn sich die Hersteller auch mal kümmern würden.
Kurz — für Automatisierer ist Security im Zweifel eher Sache der anderen. Das kann man ihnen kaum verdenken, denn in ihrem ohnehin schon interdisziplinären Engineering-Prozess ist die Security die neueste Teilnehmerin, und auch die methodisch unreifste. Wie Security Engineering methodisch ablaufen soll, darüber gibt es zumindest im Bereich der Risikoanalysen eher zu viele als zu wenige Vorschläge. Schwierig wird es spätestens bei der Frage, wie Security-Informationen eigentlich kommuniziert werden sollen. Schaltbild? R&I-Fließbild? Für Security sind solche —in anderen Gewerken oft grafischen — Denkhilfen Fehlanzeige. Wenn es welche gibt, nehmen wir halt die Netzpläne.
Überhaupt: Was sind eigentlich Security-Informationen?
Ja, es wird Zeit, dass das Security Engineering ein bisschen erwachsener wird, und zwar so, das Automatisierungsingenieurinnen damit etwas anfangen können. Damit sie das können, brauchen Sie eine überschaubare, systematische Methode, eine Idee, wie sie die in ihren bestehenden Engineering-Prozess integrieren können und ein Werkzeug, das sie souverän und effizient durch das Security-Engineering führt.
Ein Werkzeug, das nicht für sie, sondern mit ihnen denkt, und ihnen nicht die Zeit raubt, ihren eigentlich Job (Automatisierungstechnik, die funktioniert!) zu machen.
Was das mit diesen “integrated data models” aus dem IDEAS-Titel zu tun hat? Eins nach dem anderen. Wir haben in den nächsten drei Jahren Forschungsprojekt drei Schritte vor:
Schritt 1: Den Security-Engineering-Prozess in den Automation-Engineering-Prozess einpflanzen
Security by design klingt gut, soweit sind wir uns alle einig. Aber da muss mehr Fleisch dran: Wie geht denn Security by design? Oder: Wann können wir frühstmöglich anfangen, Security beim Engineering einer automatisierten Anlage mitzudenken?
Im ersten Schritt sezieren wir die existierenden Phasen und Unterphasen des Automation-Engineering-Prozesses, schauen uns an, was es für jede Phase braucht und was dabei rauskommt, und prüfen, inwiefern diese Ergebnisse ausreichen, um mit der Security zu beginnen, und wie sie für das Security-Engineering verwendet werden können. Am Ende haben wir, so der Plan, nicht nur einen Punkt (oder wahrscheinlich mehrere Punkte), an denen wir Security-Engineering in den bestehenden Engineering-Prozess einpflanzen können, sondern auch eine Liste von Informationen und typischen Arbeitsdokumenten, die für Security relevant sind und die Security ergänzen kann.
Moment, einpflanzen? Ja, einpflanzen. Security soll nicht nur ein draufgeflanschtes Anhängsel des Engineering-Prozesses werden, sondern ganz natürlich dazugehören — als hätte man das Security Engineering ins das Automation Engineering eingepflanzt. (Und dann immer gut gegossen).
Schritt 2: Ein Informationsmodell für Security-Engineering entwickeln
Nun haben wir eine Idee, wie Security Engineering und Automation Engineering zu Automation Security Engineering verschmelzen können. Die Liste von Informationen und typischen Arbeitsdokumenten, die aus dem Automation Engineering für Security verwendet werden und von der Security ergänzt werden können, ist eine gute Basis. Wenn Security nicht erwachsen werden wollte, sondern nur in die Schule kommen, könnten wir uns jetzt zurücklehnen.
Aber die “big kids” haben ja nicht nur Listen von Informationen und Dokumententypen, sondern meistens auch Informationsmodelle (hier sind eine paar Beispiele). Ein Bild sagt mehr als tausend Worte und ein R&I-Fließbild sagt mehr als eine Liste von tausend Rohrlängen und Pumpen. Und wenn man effizient arbeiten will, sagt ein für Computer les- und verstehbares Informationsmodell noch viel mehr als ein Bild mit Tusche auf Papier.
Doch wo in der Automatisierung — ein Ergebnis jahrzehntelanger Methoden- und Standardisierungsarbeit — für fast jeden Blickwinkel Informationsmodelle in unterschiedlichen Reifegraden existieren, ist im Security Engineering bislang ein großes schwarzes Loch. Den Berg an security-relevanten Informationen aus dem Automation Engineering und dem eingepflanzten Security Engineering können wir bislang nicht einmal für Menschen, geschweige denn für Maschinen lesbar gut darstellen.
Security lebt aber davon, dass Menschen (ja, Ingenieure sind auch Menschen) ihre Systeme und Security-Eigenschaften verstehen, überblicken, und Angriffsmöglichkeiten erkennen, bevor es ein Angreifer tut. Unser zweiter Schritt im Projekt wird daher sein, Security Engineering aus dem Grundschulalter herauswachsen zu lassen und auf Basis der Input- und Output-Informationen für den eingepflanzten Automation-Security-Engineering-Prozess sowohl ein menschen- als auch ein maschinenlesbares Informationsmodell zu entwickeln.
Weil wir am Ende ja etwas schaffen wollen, das Automatisierern nützt, setzen wir auf für Automatisierer vertraute und bewährte Modellierungsansätze. Gute Kandidaten sind AutomationML und der digitale Zwilling in seiner Verwaltungsschalen-Implementierung. Gut, dass wir mit Rainer Drath und Emre Tastan von der Hochschule Pforzheim und der NAMUR echte Informationsmodell-Experten an Bord haben.
Schritt 3: Ein Security-Engineering-Werkzeug für Automatisierungsingenieure bauen
Der letzte Schritt ist der Grund für die Kleinteilarbeit der ersten beiden Schritte. Der schönste eingepflanzte Automation-Security-Engineering-Prozess hilft ja niemandem außerhalb des akademischen Elfenbeinturms, wenn er nicht nutzbar gemacht wird, also wenn der Prozess zu anstregend ist, um ihm zu leben und wenn das Informationsmodell niemand anschaut, pflegt und befüllt. Den Transfer in die Praxis wird in Schritt 3 ein Demonstrator für ein Security-Engineering-Werkzeug liefern, das von Automatisierungsingenieurinnen benutzbar ist. Wie finden heraus, ob das Werkzeug benutzbar ist? Wir fragen die potenziellen Nutzer.
Für die harte Landung in der Realität — sowohl für den Engineeringprozess aus Schritt 1 als auch für das Werkzeug aus Schritt 3 haben wir unsere Anwendungspartner INEOS und HIMA, einen Betreiber und einen Hersteller von Automatisierungstechnik. Sie werden für uns testen, ob Prozess und Werkzeug dem Arbeitsalltag standhalten können.
Abschließend sind hier alle drei Forschungsfragen im IDEAS-Projekt auf einen Blick dargestellt:
IDEAS wird vom Bundesministerium für Bildung und Forschung (BMBF) gefördert.
admeritia ist Projektkoordinator, die Hochschule Pforzheim Forschungspartner, INEOS und HIMA sind Anwendungspartner und die NAMUR unterstützt uns mit Input aus ihren Arbeitsgruppen.
Das Projekt hat eine Laufzeit von drei Jahren (2021–2023).
Hier geht es zum Projektsteckbrief auf den Seiten des BMBF.
