Security Engineering braucht ein R&I-Fließbild
Warum Ingenieure Systemmodelle bauen (und wie die Layered Blueprints zu ihrem Namen kamen)
Wenn du an Security denkst — was siehst du? Was siehst du, wenn du daran denkst, wie du ein System sicherer machst?
Oder: Wenn du genau ein Blatt Papier zeigen solltest, das erklärt, wie du ein Security-Problem löst — was wäre darauf zu sehen?
Eine Linux-Konsole — weiße Schrift auf schwarzem Grund?
Eine CVE-Datenbank?
Tabelle mit rot-gelb-grünen Risiken?
Netzpläne mit Cisco-Symbolen?
Ein Entscheidungsbaum mit Angriffsszenarien?
Die Frage ist für das Security Engineering gar nicht so leicht zu beantworten — und das ist auffällig, denn für andere Ingenieurdisziplinen fällt das leichter.
Stellen wir uns vor, wir stellen dieselbe Frage anderen Ingenieuren: Wenn du genau ein Blatt Papier zeigen solltest, das erklärt, wie du ein Problem löst — was wäre darauf zu sehen?
Der Maschinenbauingenieur könnte zum Beispiel antworten: Eine CAD-Zeichnung:
Die Elektroingenieurin? Ein Schaltplan:
Ein Regelungstechniker? Ein Blockschaltbild:
Eine Verfahrenstechnikerin? Ein Rohrleitungs- und Instrumentierungs (R&I)-Fließbild:
Ingenieurdenken heißt in Modellen denken
Wahrscheinlich gibt es nicht nur die eine Antwort; jede Disziplin mag mehrere beliebte Modelle haben, in denen sie denkt.
Aber: Sie alle haben solche Modelle, und sie sind so weit verbreitet, dass kein Ingenieur, keine Ingenieurin in der Ausbildung an ihnen vorbei kommt. Wenn ein Ingenieur ein Problem lösen möchte, baut er sich erst einmal ein Modell — aus gutem Grund: Modelle helfen, Denken zu kanalisieren. Sie entfernen alle Aspekte, die das zu lösende Problem nicht beeinflussen, und zeigen die Welt aus einer Perspektive, aus der das Problem am besten deutlich wird. Eine Ingenieurin fasst mit einem Modell ihr Problem mitsamt aller relevanten Randbedingungen in einem Bild zusammen, und dann verändert sie dieses Bild, formt und knetet es zurecht, bis es eine Lösung beinhaltet.
Am Ende zeigt das Modell eine Lösung, druckbar auf ein Blatt Papier, das man weitergeben kann, um die Lösung anderen verständlich zu machen und mit anderen zu diskutieren.
Prozessmodell vs Systemmodell
Wenn wir nun beginnen, über Modelle zu sprechen, müssen wir noch mindestens eine Unterscheidung machen, denn Modelle gibt es viele. Sie lassen sich auch auf vielfältige Weise in Kategorien einteilen, aber begnügen wir uns hier mit der Unterscheidung zwischen Prozessmodellen und Systemmodellen.
Prozessmodelle gibt es, um einen Vorgang besser zu strukturieren. Sie geben Orientierung und helfen, auf dem richtigen Weg zu bleiben. Sie machen es einfacher, zu identifizieren und darüber zu sprechen, wo im Prozess man gerade steckt und was der nächste Schritt zum Ziel sein muss. Die wahrscheinlich bekanntesten Beispiele für Prozessmodelle sind das Wasserfall-Modell und das V-Modell.
Es gibt eine Reihe von Prozessmodellen im Security-Engineering, auch wenn sie meistens nicht explizit so heißen und oft auch nur einen Teil des Security-Engineering-Prozesses abbilden. Sie finden sich zum Beispiel in der Form von Risikoanalysemethoden oder dem Systems Security Engineering. Für Risikoanalysemethoden gibt es eine ganze Reihe von Standards. Das Systems Security Engineering ist in der NIST Special Publication 800–160 und der ISO/IEC 21827:2008 beschrieben — und in Deutschland so wenig bekannt, dass die deutsche Übersetzung einigermaßen ungewohnt klingt: Systemsicherheitstechnik.
Diese Prozessmodelle verfolgen unterschiedliche Ziele und bilden unterschiedliche Teile des Security-Engineering-Prozesses ab. Um etwas Orientierung im Prozessmodelldschungel zu bekommen und die Prozessmodelle einfacher vergleichbar zu machen, kann man sie in ein einfaches, methodenneutrales Prozessmodell einsortieren, wie letztes Jahr in unserem atp-Hauptbeitrag ausführlich beschrieben und in Bild 5 in groben Zügen skizziert:
Zuerst (im Leuchtturm: zuunterst) wird die Frage nach dem Schutzziel beantwortet — dafür müssen die Funktionen und Abhängigkeiten des schützenswerten Systems verstanden werden.
Auf der zweiten Ebene wird identifiziert, gegen welche Risiken das System geschützt werden soll.
Im dritten Schritt werden Security-Anforderungen definiert, die die identifizierten Risiken mildern können.
Zuletzt wird die Frage beantwortet, wie diese Anforderungen in die Realität umgesetzt werden können.
Aber Prozessmodelle sind nicht das eine Blatt Papier, das wir suchen. Sie helfen uns nicht, unsere Security-Lösung zu modellieren und kommunizieren — nur, wie wir dorthin gekommen sind. Prozessmodelle modellieren weder die Annahmen noch das eigentliche Problem, und eine Security-Engineering-Lösung können sie auch nicht beschreiben. Es ist wahrscheinlich noch nie eine Ingenieurin stolz mit einem V-Modell wedelnd in das Büro ihres Kollegen gestürmt mit den Worten “Heureka, ich hab’s”, wenn sie ihm eine bahnbrechende Lösung präsentieren wollte.
Was wir suchen, ist eher ein Systemmodell für Security. Systemmodelle sind das, was das Prozessmodell “unterwegs” produziert. Nehmen wir unser Prozessmodell aus Bild 5, können wir uns auf jeder Ebene des Prozessmodells vorstellen, dass die Ergebnisse eines Prozessschritts in ein Systemmodell modelliert werden. Auf der untersten Ebene brauchen wir ein Systemmodell der Funktionen und Abhängigkeiten des zu schützenden Systems, und dann müssen wir es verändern, verfeinern und “in Form kneten”, bis wir eine Security-Lösung modelliert haben.
Wie wir das Systemmodell Schritt für Schritt verändern? Dabei hilft uns das Prozessmodell.
So kamen die “Layered Blueprints”, der Arbeitstitel für Bild 5, übrigens zu ihrem Namen: Auf der untersten Ebene wird ein erster “Blueprint” des Systemmodells der Security-Lösung erzeugt, und dieser wird — Ebene für Ebene, Layer für Layer, ergänzt zu “Layered Blueprints”. Wenn man oben angekommen ist, so die Vision, hat man seinen untersten Blueprint so lang zurechtgeknetet und ergänzt, dass man nun das Modell der erdachten Security-Lösung in der Hand hält.
Wofür ist ein R&I-Fließbild gut?
Warum also haben wir für das Security Engineering kein solches Systemmodell, das in unserer Disziplin so fest verankert ist, dass es jeder kennt? Wir müssten dafür eigentlich ziemlich viel Verwendung haben, denn Security ist ja nie ein Selbstzweck. Security Engineering braucht man immer erst dann, wenn andere Ingenieurdisziplinen schon am Werk waren. Security Engineering erfüllt keine einzige zusätzliche funktionale Anforderung, sondern sorgt dafür, dass die Funktionen, die andere Ingenieurdisziplinen geschaffen haben, zuverlässig arbeiten — selbst wenn es Angreifer gibt, die das verhindern wollen.
Oder, speziell für Automation Security Engineering: Ohne Automation Engineering braucht es kein Automation Security Engineering.
Das heißt auch: Wenn Security-Ingenieure ihre Arbeit beginnen, gibt es immer schon einen Haufen Ingenieurarbeit zu verstehen, einen Haufen Modelle aus verschiedenen Disziplinen übereinzubringen, um das Gesamtsystem zu verstehen, auseinanderzunehmen, das schwächste Glied zu finden und es stärker zu machen. Tun wir uns deswegen so schwer mit dem Bilden eines eigenen Modells — weil wir auf anderen Modellen aus verschiedenen Quellen aufbauen müssen?
So willkommen so eine Ausrede auch sein mag — lasst uns nicht zu schnell dorthin hinüberretten.
Schauen wir einmal auf das Beispiel Automatisierungstechnik. Automatisierungsingenieure haben eigentlich ein sehr ähnliches Problem wie wir: Sie automatisieren einen Prozess, zum Beispiel die Produktion einer Chemikalie oder das Zusammenbauen eines Autos — und dieser Prozess ist schon da, wenn sie mit ihrer Arbeit anfangen. Sie haben ihn nicht selbst erdacht und ausgelegt und sie verändern ihn nicht. Sie machen diesen Prozess effizienter, indem sie ihn Prozess automatisieren — aber dafür müssen sie erst einmal verstehen, was schon da ist, was andere Ingenieurdisziplinen bereits modelliert, aufgeschrieben und vielleicht sogar schon umgesetzt haben.
Oder: Ohne Process Engineering braucht es kein Process Control Engineering.
Wie machen sie das?
Sie nehmen ein “Blatt Papier” von den Prozessingenieuren, auf dem die Informationen modelliert sind, die sie für das Auslegen ihrer Automatisierungslösung brauchen — nämlich das Verständnis über den zu automatisierenden Prozess. Dann beginnen sie, ihren eigenen Engineering-Prozess zu durchlaufen und fügen Schritt für Schritt Informationen hinzu — sie modellieren und formen und kneten, bis das Modell ihre Lösung enthält.
Das “Blatt Papier” der Prozessingenieure enthält in der Regel ein sogenanntes Rohrleitungs- und Instrumentierungs-Fließbild (R&I-Fließbild). Jeder Verfahrens- oder Prozesstechniker kennt diese Bilder, sie sind weit verbreitet und genormt (Normenreihe DIN EN ISO 10628) und enthalten eine für Menschen intuitiv lesbare Darstellung eines Prozesses, indem ein Produktfluss durch Rohre sowie alle “Stationen”, in denen etwas am Produkt verändert wird (Behälter, Ventile, Pumpen, Motoren, Heizelemente, …) modelliert wird.
Hier ist ein simples Beispiel:
Für Automatisierungsingenieure sind diese R&I-Fließbilder eine gute Basis. Man kann sie zurechtkneten und ergänzen, sodass sie auch Informationen über die Automatisierung des Prozesses enthalten, und zwar mit sogenannten Prozessleittechnik-Stellen (PLT-Stellen), auch “Mess- und Regelstellen” genannt. PLT-Stellen sind Ergänzungen am R&I-Fließbild für die interdisziplinäre Zusammenarbeit zwischen Verfahrens- oder Prozessingenieuren und Automatisierungsingenieuren.
Auch die Darstellung dieser Mess- und Regelstellen ist standardisiert in den Normen(reihen) ISO 3511, zukünftig ISO 14617 und ISO 15519 sowie die digitale Representation in IEC bzw. DIN EN 62424— alles aufbauend auf den standardisierten R&I-Fließbildern.
Hier ist unser obiges Beispiel ergänzt um PLT-Stellen:
Ein R&I-Fließbild für Security — wie kann das aussehen?
Natürlich sind die Problemstellungen, für deren Lösunge R&I-Fließbilder das Denken sortieren, andere als die, die Security Engineering löst.
Wahrscheinlich sieht ein Systemmodell für Security völlig anders aus als ein R&I-Fließbild. Die richtige Frage ist daher auch eine andere:
Ein Systemmodell für Security — wie kann das aussehen?
Egal, wie wir es formulieren: Lasst uns herausfinden, wie so ein Modell aussieht.
Lasst uns ein Modell bauen, das unser Denken in geordnete Bahnen lenkt, das uns hilft, unsere Gedanken über ein Security-Problem anderen zu erklären, das wir nehmen und ergänzen und in Form kneten können, bis wir eine Lösung haben — die wir anderen wiederum einfach erklären können.
Lasst uns Schritt für Schritt ein Systemmodell für Security bauen.
Damit wir nicht auf einem weißen, gähnend leeren Blatt Papier anfangen müssen, mache ich einen ersten Aufschlag in einem zukünftigen Text.
Deal?
Update 17.04.2020: Weiterlesen
- Jake Brodksy hat eine Antwort auf diesen Text auf seinem Blog veröffentlicht und wertvolle Punkte zur Diskussion hinzugefügt (wie etwa Geschichte und Zweck des Purdue Models):
http://scadamag.infracritical.com/index.php/2020/04/12/diagramming-ics-security/ - In der Kommentarsektion dieses LinkedIn-Posts hat sich außerdem eine lebendige Diskussion zur Modellierung von Security entwickelt. Beim Durchstöbern finden sich einige Debatten sowie eine höchst interessante Fundgrube von Ideen und Erfahrungsberichten:
https://www.linkedin.com/posts/sarah-fluchs_security-engineering-needs-a-pi-diagram-activity-6655072880163864576-xv9A
