Willkommen zum letzten Briefing im scheinbar unendlichen Sommer 2022, oder der Sommer, in dem "Schatten" und "Planschbecken" zu kritischen Infrastrukturen wurden. Weil man bei über 30 Grad ja wie durch Honig denkt, verlangsamen wir auch unser HardHats-Briefing ein bisschen: Wir nehmen uns Zeit für etwas dickere Bretter, dafür dürfen Sie bei jedem Thema etwas länger verweilen.

Es geht darum, wie Ingenieure Cybersecurity mitdenken lernen, wie Zero Trust (nicht) geht, wie man eigentlich Security-Entscheidungen trifft und wie es mit der ISA/IEC 62443 weiter geht.

In dieser E-Mail gibt es Neuigkeiten und Lesestoff zu folgenden Themen:

1. Cyber-Informed Engineering (CIE) wird im US-Energiesektor jetzt nationale Strategie
2. Zero Trust ist kein Produkt
3. Was ist eine Security-Entscheidung und wie trifft man sie?
4. August-Update zur ISA/IEC 62443: Kleine Übersetzungshilfe

1. Cyber-Informed Engineering (CIE) wird im US-Energiesektor jetzt nationale Strategie

Wer hier schon länger mitliest, weiß das: Ich beschwere mich gern darüber, dass "Security Engineering" das "Engineering" im Namen eigentlich nicht verdient. Ansätze, die das ernsthaft ändern wollen, sind rar. Das "Consequence-Driven, Cyber-Informed Engineering" (CCE) der staatlichen Forschungseinrichtung Idaho National Laboratory in den USA ist so ein Ansatz. Er geistert schon länger durch Konferenzen und die Community, war aber lange chronisch unterdokumentiert. Letztes Jahr hat sich das endlich geändert, als Andy Bochman und Sarah Freeman das Buch "Countering Cyber Sabotage" herausgebracht haben, das die Methode erstmals ausführlich beschreibt (Lesestoff 1). Ein Wermutstropfen: Das Ganze ist unglaublich aufwendig.

Nun hat das US-amerikanische Energieministerium ein Strategiepapier veröffentlicht (Lesestoff 2), das die CCE-Methode in ein größeres Ganzes, nämlich die "National Cyber-Informed Engineering Strategy", einordnet. Strategiepapiere enthalten naturgemäß nicht viele technische Details, aber einige kann man doch finden:

• Die Definition von Cyber-Informed Engineering (CIE): "CIE is an emerging method to integrate cybersecurity considerations into the conception, design, development, and operation of any physical system that has digital connectivity, monitoring, and control. Eine informellere, aber häufig gewählte Formulierung ist: CIE aims to "engineer out" cyber risk. Mit "engineer out" ist gemeint, das bevorzugt Maßnahmen aus dem Engineering-Werkzeugkoffer gewählt werden, also "systeminhärente" Änderungen im grundlegenden Anlagen-Design statt nachträglich hinzugefügte, oft softwareseitige, Security-Lösungen.
• Klingt nach Security by Design? Ist es auch. Später im Strategiepapier wird explizit erwähnt, dass CIE als Umsetzung von Security by Design und Zero Trust verstanden werden soll. Während Security by Design oft bei Software aufhöre, so die Autoren, soll CIE das Prinzip auch auf physische Systeme ausweiten.
• Der Scope von CIE ist interessant, weil recht breit. CIE richtet sich an "any physical system that has digital connectivity, monitoring, or control". Vorerst im Energiesektor (der Rest ist halt nicht die Baustelle des US Department of Energy), aber die Methode könne durchaus auf andere kritische Infrastrukturen übertragen werden.
• Als Anwender von CIE sehen die Autoren nicht unbedingt Security-Experten, sondern "engineers and industrial control system technicians"
• Principles of CIE: Hier wird das Papier etwas konkreter, vor allem bei den "Design and Operational Principles", die da wären:
• Consequence-Focused Design (also sich bewusst über seine eigenen kritischen Funktionen zu werden),
• Engineered Controls (also bereits während des Engineering-Prozesses möglichst systeminhärente Maßnahmen gegen negativen Auswirkungen wählen),
• Secure Information Architecture (also das bewusste Design von Datenflüssen),
• Design Simplification (also frühzeitiges Eliminieren aller nicht verwendeten Funktionen),
• Resilient Layered Defenses (ein fancy Begriff für Defense in Depth) sowie
• Active Defenses (also die in den USA so beliebten Lösungen zur Erkennung und Verhinderung von Angriffen).
• Am besten kann man sich die Philosophie hinter CIE vorstellen, wenn man die Beispielszenarien für die Ergebnisse der CIE-Denkweise auf Seite 9 liest.
• Und wie verhält sich nun CCE zu CIE? Darauf gibt es im Anhang noch eine Antwort: CCE ist eine Möglichkeit, die CIE-Prinzipien zu implementieren.

Das Papier ist trotz seiner hohen Flughöhe lesenswert, weil es zwei große Probleme im heutigen OT-Security-Engineering gut beschreibt: die fehlende Reife der Disziplin "Cybersecurity Engineering" und das Fehlen von Security by Design. Bei mir wird dazu dieses Bild hängen bleiben, das ohne viele Worte beschreibt, warum Security by Design so viel eleganter ist als im Nachhinein angeflanschte Lösungen:

Die Schwäche des Papiers ist natürlich, dass es "nur" ein Strategiepapier ist - die guten Versprechungen muss man erst einmal glauben, sie geben naturgemäß noch wenig Hinweise darauf, was das alles in der Praxis nützen oder verändern könnte. Gut deutlich wird das an den oben genannten Designprinzipien: So richtig "anders" sind dabei eigentlich nur die ersten beiden Prinzipien, der Rest klingt zwar gut und richtig, aber auch nach "schon oft gehört".

Hoffen wir, dass das Strategiepapier seine fünf Säulen "Awareness, Education, Development, Current Infrastructure und Future Infrastructure" mit Leben gefüllt bekommt und damit mehr und vor allem Anwendbareres in der Mache ist.
Es täte der Ingenieurdisziplin "Security Engineering" jedenfalls gut.

2. Zero Trust ist kein Produkt

Und weil das CIE-Strategiepapier das momentan allgegenwärtige Buzzword "Zero Trust" so schön nonchalant im Vorübergehen mit abräumt, hier noch zwei Beiträge, die ein wenig heiße Luft aus dem Begriff herauslassen:

1. John Kindervag, dem die Erfindung des Zero-Trust-Konzepts zugeschrieben wird, beschreibt das Konzept und die üblichen Missverständnisse in vier sehenswerten Minuten auf der Bühne der S4x22.
2. Yogesh Gupta hat einen kurzen Rant in seinem Blog dazu verfasst, dass Zero Trust keine Lösung ist, die man einem Hersteller mal eben abkaufen kann. (Das gilt eigentlich für die meisten sinnvollen Security-Konzepte).

3. Was ist eine Security-Entscheidung und wie trifft man sie?

Im Juni gab es noch eine weitere IDEAS-Veröffentlichung, für die in den letzten HardHats-Briefings kein Platz mehr war. Bei der Fachtagung "Entwurf Komplexer Automatisierungssysteme" in Magdeburg habe ich ein etwas theoretisches, für uns aber sehr grundlegendes Paper vorgestellt. 

Das englischsprachige Paper trägt den Titel "A Security Decision Base: How to Prepare Security by Design Decisions for Industrial Control Systems." Im Grund geht es darin um die Frage, wie wir Security-Entscheidungen treffen. Wir klären, was eine Security-Entscheidung eigentlich ist und auf welchen Wegen man dorthin kommt. Interessant ist dabei der Blick über den Tellerrand, den wir in der OT-Security sind sehr daran gewöhnt, Entscheidungen risikobasiert zu treffen - dabei ist das nicht die einzige Möglichkeit. In Security-by-Design-Ansätzen aus dem Software Engineering sind andere Entscheidungswege ebenso üblich.

Dann - und das ist der theorietriefende Teil - schauen wir, auf welcher Basis Security-Entscheidungen getroffen werden. Genauer: mit Hilfe welcher gedanklicher Konzepte werden die Informationen aufbereitet, die für eine Security-Entscheidung relevant sind? Das hängt natürlich vom Entscheidungsweg ab. Wenn Entscheidungen risikobasiert getroffen werden, sind relevante Konzepte Schwachstellen, Risikoszenarien und Auswirkungen. Weil es hier nicht viel Vorarbeit im Bereich der OT-Security gibt, schauen wir intensiv auf unsere Nachbardisziplinen, die sich schon länger mit Security by Design herumschlagen: Systems Engineering, Software Engineering, Requirements Engineering. Und am Ende machen wir Vorschläge für eine Entscheidungsbasis für Security by Design für Automatisierungssysteme, mit vielen altbewährten und wenigen neuen Konzepten.

Wer neugierig ist, für den habe ich die wichtigsten Inhalte in einen leicht verdaulichen Blogartikel gegossen - auf Deutsch und Englisch in den Lesestoff-Links 1 und 2.
Wer sehr neugierig ist, kann auch das ganze Paper lesen - verlinkt im Lesestoff 3.

4. August-Update zur ISA/IEC 62443: Kleine Übersetzungshilfe

Die ISA, die den Löwenanteil der Arbeit hinter der ISA/IEC 62443-Standardreihe macht, hat in der letzten Zeit viel an ihrer Kommunikation nach außen gearbeitet. Ein Teil dieser Kommunikation sind auch öffentliche "Committee Letters", in denen jeder nachlesen kann, was sich momentan in der Standard-Reihe tut. Sehr begrüßenswert, denn immerhin soll Standardisierung ja offen für alle sein und nicht nur für einen erlauchten Kreis, der Zeit, Firmensponsoring und notwendige Kontakte hat, um die relevanten Informationen zu bekommen.

Jüngst ist so ein "Committee Letter" des ISA-Komitees ISA99 erschienen. Das Komitee ISA99 ist die Summe der Arbeitsgruppen, die die ISA/IEC 62443 schreiben.
(Randbemerkung für Gestolperte im obigen Satz: Ja, die Anzahl der "m" und "t" in "Komitee" ist wirklich im Englischen und Deutschen so verschieden...)

Für alle, die sich nicht ständig mit Komitees und deren Schreibweise herumschlagen, hier Zusammenfassung der Updates zu den einzelnen Standardteilen inklusive Standardsprech-Übersetzungshilfe:

• ISA 62443-2-1 ("das ISMS für OT-Security"): Nach über zehn Jahren Diskussion, vor allem über die Beziehung zur ISO/IEC 27001, rückt nun das Erscheinen der neuen Version in greifbare Nähe. Noch dieses Jahr soll ein "Final Draft" zur Abstimmung im Komitee erscheinen. Die Abstimmung bedeuet, dass die Kommentierungsphase des Standards, in der größere Änderungen eingearbeitet werden, bereits vorbei ist. Nun geht nur noch "ja" oder "nein" (und "nein" nur mit Begründung).
  Ergibt die Abstimmung ein "ja", wird der Standard bald veröffentlicht. Erschwerend kommt bei der ISA/IEC 62443 immer hinzu, dass auch das IEC-Komitee TC65 mit abstimmen darf.
• ISA 62443-1-1 (Terminologie): Das Begriffsdefinitionsdokument jedes Standards ist eher etwas für Liebhaber. Davon gibt es aber viele, denn der erste Entwurf des Standards hat über 2000 Kommentare kassiert. Die löst die Arbeitsgruppe bei der ISA jetzt auf und bis Ende 2022 gibt es dann einen überarbeiteten Entwurf, der wieder kommentiert werden darf. Es ist also noch ein Stück zu gehen bis zur Abstimmung und Veröffentlichung.
• ISA 62443-2-3 (Patch Management): Der Technical Report (kein Standard, für Technical Reports gibt es weniger strenge Regeln als für Standards) ist von 2015. Er wird nun überarbeitet, aber es gibt noch keinen Entwurf zu kommentieren.
• ISA 62443-1-6 (Anwendung der 62443 auf IoT): Dazu wird es noch in diesem Jahr erstmalig einen Entwurf geben, der kommentiert werden kann.
• ISA 62443-1-3 (Quantitative Metriken für IACS Security): Auch ein Technical Report, und einer, der schon mal die Nummer gewechselt hat - war mal die ISA 62443-2-2. Der Standardteil ist grundlegend für die Harmonisierung der vielen Standardteile, denn die dort vorgestellte Struktur der "Security Program Requirements" dient nicht nur der Quantifizierung der Standarderfüllung, sondern es sollen künftig auch alle Standardteile daran angepasst werden. Die -2-1 wird wohl der erste Teil mit dieser neuen Struktur. (Siehe HardHats-Briefings von Juli 2020 und Mai 2021 zur Vorgeschichte dieses Standardteils).
• ISA 62443-1-3 (Micro Learning Modules): Die "MLM's" sind auch ein Teil der verbesserten Kommunikation des ISA99-Komittees. Sie erklären wichtige Themen rund um die ISA/IEC-62443-Standardreihe in leicht verdaulichen Happen im Videoformat, anzuschauen auf YouTube. An dieser Stelle muss man noch einmal daran erinnern, dass all diese Arbeit ehrenamtlich von Freiwilligen gemacht wird. Der Output kann sich durchaus sehen lassen. Übrigens: Es wird auch ein "MLM" zu Secure PLC Coding geben, dank der Initiative von Dan Ehrenreich.
• Außerdem gibt es noch Arbeit an "security profiles", die in großen Teilen bei der IEC (im Komitee TC65, Arbeitsgruppe WG10) gemacht wird. Bei den Profilen geht es um die Definition von Anforderungs-Sets aus der ISA/IEC 62443 für die 62443-Zertifizierung einer bestimmten Anwendergruppe.

Stay secure!
Sarah Fluchs