Ich schwöre, ich hab es nicht drauf angelegt - aber das Security-Briefing hat diesen Monat mal wieder einen deutlichen Security-by-Design-Drall. Wenn 15 internationale Sicherheitsbehörden das Thema zum Buzzword des Jahres erklären, machste halt nix.

Dafür kommt das Security-Briefing für Hard Hats dieses Mal in einer Lesemuffel-Edition: So viele Videos statt Texte habe ich glaube ich noch nie verlinkt - aufgenommen in Düsseldorf und Singapur. Also, Popcorn bereitstellen!

Übrigens verabschieden sich die Hard Hats nach diesem Briefing in eine kleine Winterpause. Warum? Ich muss unser Forschungsprojekt beenden und dafür mal kurz abtauchen - denn das braucht Denkzeit. Ich melde mich gut durchdacht Anfang 2024 wieder.

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

1. Neues CISA-Papier zu Security by Design: Wer zahlt die Zeche?
2. Angriffserkennung mit dem eigenen Leitsystem
3. Systems Engineering in der Praxis
4. Technischer Fortschritt oder "Normalisation of Deviance?"
5. Ein realistischeres Bild von Security by Design (OTCEP-Video)

1. Neues CISA-Papier zu Security by Design: Wer zahlt die Zeche?

Zum Thema Security by Design gibt es mal wieder Neuigkeiten. Die US-amerikanische CISA (Cybersecurity & Infrrastructure Security Agency) hat mal wieder ein Papier dazu herausgebracht, und die halbe Welt macht mit: NSA, FBI und Security-Behörden aus 15 Ländern, inklusive dem deutschen BSI.

Es ist schon das zweite Dokument zu diesem Thema in diesem Jahr. Und auch dieses enthält wieder Secure by Design-Prinzipien und außerdem "Secure by default practices", "Secure product development practices" und "Pro-security business practices" für jedes der drei Prinzipien. Alles ausschließlich für Software.

Dokumente mit "Secure by design"-Prinzipien gibt es mehr, als man zählen kann. Aber zwei Punkte sind an dem CISA-Dokument bemerkenswert:

• Konkrete Forderungen, was Hersteller öffentlich machen sollten: Bedrohungsmodelle ("high level threat models"), den Secure Software Development Lifecycle, dem sie sich verschreiben, eine Software Bill of Materials (SBOM), eine Policy zur Veröffentlichung von Schwachstellen, den Manager, der Security by Design verantwortet, eine Security by Design Roadmap, interne Erfolge und Stolpersteine beim Einführen des Secure Software Development Lifecycle....

Das sind hohe Erwartungen. Ich fürchte, solang wir weiter öffentlich auf allen Herstellern herumtrampeln, die Security-Probleme haben, werden sie einen Teufel tun und all das öffentlich machen - und ich kann sie verstehen. Trotzdem brauchen wir eine Diskussion darüber, was Hersteller veröffentlichen müssen, damit wir alle zusammen, Produkthersteller und ihre Nutzer, dem Ziel Security by Design näher kommen. Mehr dazu gleich.

• Klare Vorstellungen, wer Security by Design bezahlen soll:
  Kurz: Die Hersteller. Zitat: "Manufacturers of products that are “secure by default” do not charge extra for implementing added security configurations Instead, they include them in the base product like seatbelts are included in all new cars. [...] Security should not be a luxury option, but should be considered a right customers receive without negotiating or paying more."

Puh. Das klingt gut, aber realitätsfern - zumindest, solang es ein Dokument ist, das Hersteller (Zitat) "drängt, die Prinzipien in diesem Dokument zu befolgen", aber außer vielen prominenten Mitherausgebern keinerlei regulatorischen Wumms hat. Jason Weiss hat das in einem LinkedIn-Post schön zusammengefasst.

Nach den vielen Gesprächen mit Produktherstellern und Produktnutzern, die ich in den letzten Jahren über Security by Design geführt hat, befürchte ich:
Hersteller werden keine Funktionen integrieren, für die niemand zahlt. Sie werden sich von niemandem "gedrängt" fühlen, Funktionen einzubauen, außer von ihren Kunden (oder von verbindlichen Gesetzen). Und das ist auch verständlich (und, unpopular opinion, wohl auch gut so. Es gibt nichts Tödlicheres für ein Produkt, als Features, die Kunden nicht wollen).

Die Diskussion ist aber auch zu schwarz-weiß. Sie suggeriert, entweder sei Security "eingebaut" oder nicht. Ich kenne Unternehmen, die "sichere Versionen" und "normale" Versionen z. B. von Programmiergeräten haben. Der Unterschied? Das Preisschild. Die meisten Kunden entscheiden sich für die normale Version.

Dabei hat Security by Design - genauso wie jede funktionale Anforderung - jede Menge Verhandlungsspielraum (was gut ist). Genau wie nicht jeder einen Porsche kauft, weil er vielleicht nicht Hunderttausende für ein Auto ausgeben möchte, werden auch Nutzer von IT/OT-Systemen niemals bereit sein, für "alle Security-Funktionen" zu zahlen.

Sie zahlen für die Funktionen, die für sie wirklich wichtig sind. Dafür braucht es: Transparenz, womit sich der Kreis zum ersten Punkt schließt.

Transparenz ist aber keine Einbahnstraße.
Die Anbieter müssen aufhören zu sagen: "Das zahlt doch sowieso keiner", und sie müssen anfangen, die Optionen für Sicherheitsfunktionen und ihren Preis transparent darzustellen. Und die Kunden müssen aufhören, mit unrealistischen Sicherheitswünschen um sich zu werfen ("Gebt mir SL 4!") und anfangen, transparent zu machen, welche Sicherheitsziele für sie wichtig sind.

Hersteller, Nutzer: Schreitet zum Äußersten und redet miteinander, statt euch Feature-listen an den Kopf zu knallen.

2. Angriffserkennung mit dem eigenen Leitsystem

Das IT-Sicherheitsgesetz 2.0 schreibt's vor: Systeme zur Angriffserkennung. Lösungen dazu gibt's ja wie Sand am Meer - also einfach eine kaufen und fertig? Lieber nicht. Ragnar Schierholz hat in seinem Vortrag bei SECURITY UNTER KONTROLLE 2023 erklärt, wie man sich die Besonderheiten von Automatisierungssystemen für die Angriffserkennung zunutze machen kann - und den Vortrag gibt's jetzt als Video (Link siehe unten).

Bei Systemen zur Angriffserkennung gibt's ja drei drängende Fragen: Welche Systeme beobachte ich eigentlich, woher kommen die Daten und wie erkenne ich einen Angriff? Der Vortrag hat interessante Antworten auf alle drei:

Woher kommen die Daten?

Ragnar stellt "Lean Monitoring" vor: Das bedeutet, man nutzt die Daten, die im Prozessleitsystem ohnehin schon vorhanden sind. Da ist ja ein ganzes System, das nur dafür da ist, den Prozess zu beobachten - man wäre ja blöd, wenn man die nicht nutzt. Die Daten sind schon validiert, und man kann sie in ein eigenes Monitoring-System (SIEM) weiterleiten, sodass man trotzdem keine Rückwirkungen der Angriffserkennung aufs Leitsystem fürchten muss.

Welche Systeme sollte man beobachten?

"Alles" ist eine schlechte Antwort, führt nämlich zu Datenflut. Bessere Ansatzpunkte:

1. Wichtige Funktionen beobachten - zum Beispiel "essential functions" aus der ISA/IEC 62443.
2. Schutzmaßnahmen beobachten: Wenn eine auslöst, möchte man das wissen.

Woran erkennt man einen Angriff?

Detektionsregeln sind im OT-Umfeld manchmal sogar leichter zu schreiben, denn die Systeme sind ja deterministisch und die Änderungen leichter vorhersagbar.

Natürlich gibt es Veränderungen, die im Regelbetrieb unüblich sind und auf einen Angriff hinweisen: eine Alarmdeaktivierung für die Leitsystemalarme oder die Änderungen an Prozessparametern der funktionalen Sicherheit (andere Parameter werden im Regelbetrieb durchaus mal verändert).

In einer deterministischen Systemumgebung können sogar Alarme für Ereignisse Sinn machen, die in der Büroumgebung viel zu häufig wären: Neue Netzwerkteilnehmer oder unübliche DNS-Anfragen zum Beispiel.

Den ganzen Vortrag finden Sie im Video-Link 1.

Ja, und wenn so ein System zur Angriffserkennung da ist, fängt die Arbeit ja erst an: Detektionsregeln muss man nämlich nicht nur schreiben, sondern auch laufend verbessern. Wer da ganz tief eintauchen will, für den haben wir noch einen Folge-Vortrag im Köcher: Nicolas Coppik erklärt Details dazu, wie man effizient Detektionsregeln für ein System zur Angriffserkennung schreibt und verbessert - inklusive OpenSource-Toolstack (Video-Link 2).

Randnotiz: Beide Videos sind von ABB-Mitarbeitern... man könnte uns bei SECURITY UNTER KONTROLLE also Unausgewogenheit vorwerfen, zumal ABB auch Sponsor war. Aber: Wir haben einen 20-köpfigen Programmbeirat, der mit dem Sponsoring nichts zu tun hat und die Vorträge nach gemeinsam festgelegten inhaltlichen Regeln auswählt. Ragnar Schierholz und Nicolas Coppik haben also einfach das Kunststück geschafft, beide so gute Vorträge einzureichen, dass es dem Beirat wurscht war, dass zweimal ABB im Programm ist.

3. Systems Engineering in der Praxis

Ich hatte das Thema im letzten Hardhats-Briefing in einem Nebensatz erwähnt: Wird Systems Engineering (ISO/IEC/IEEE 15288 und Verwandte) eigentlich in der Praxis von irgendjemandem erfolgreich angewendet?

Ich habe danach auf LinkedIn gefragt und viele interessante Antworten bekommen. Eine Goldmine, wenn Sie nach Erfahrungen mit Systems Engineering suchen: Wer macht's, wie geht's und womit kämpfen andere?

Meine Lieblingszitate, die ich hier jetzt mal schamlos aus dem Kontext reiße:

• "15288 creates friction. Friction is the enemy of adoption." (Tony Turner)
• "like cyber (which is in its infancy), systems engineering (which is in its teenage years) is still establishing itself" (Rob Orr)
• "15288 is intended to be a tailorable framework… a list of raw ingredients…that an org uses to define their processes." (Kenneth Crowther)

Außerdem habe ich Lesetipps bekommen, die ich Ihnen nicht vorenthalten möchte. Sie finden Sie unten in den Lesestoff-Links.
Lesestoff 1: MITRE Systems Engineering Guide. MITRE ist eine der wenigen Organisationen, die Systems Engineering wirklich leben (Zitat Kenneth Crowther). Der MITRE Guide ist daher nicht "yet another standard", sondern wirkliches Erfahrungswissen. 726 Seiten Erfahrungswissen (wenn ich etwas über Systems Engineering gelernt habe, dann, dass es IMMER mit vielen Seiten einhergeht).
Lesestoff 2: Modellbasierte Darstellung der ISO/IEC/IEEE 15288. Dov Dori ist eine Koryphäe zum Thema model-based Engineering. Er ist der Vater der Modellierungssprache OPM (Object-process methodology) und Autor des Buchs "Model-based Systems Engineering with OPM and SysML". Im Lesestoff-Paper wird's jetzt ein wenig meta: Dov Dori hat seine Modellierungssprache OPM verwendet, um die ISO/IEC/IEEE 15288 zu modellieren. Ein Modell, das einen Standard darstellt? Wer braucht sowas? Die Visualisierungen machen die vielen textuellen Prozessbeschreibungen der ISO 15288 (Sie erinnern sich: 28 Prozesse) schneller zugänglich. Kein schlechter Einstieg also.

4. Technischer Fortschritt oder "Normalisation of Deviance"?

Die Video-Mitschnitte vom OT Cybersecurity Expert Panel Forum (OTCEP), das diesen Sommer in Singapur stattgefunden hat, sind online. Darauf habe ich mich schon lange gefreut, denn es sind einige dabei, die sich lohnen anzusehen. Ich fange mal mit dem von Marco Ayala an.

Das Wichtigste, was Sie aus dem Video mitnehmen können, ist die Bekanntschaft mit einem neuen Begriffe: Normalisation of Deviance - auf Deutsch in etwa: Normalisierung der Abweichung. Es gibt Begriffe, die sind so mächtig, dass es schon einen Unterschied macht, wenn man sie einfach nur kennt.
Die Normalisation of Deviance beschreibt das Phänomen, dass wir eigentlich unhaltbare Zustände - Abweichungen von einem "guten Zustand" - beginnen, als normal wahrzunehmen, wenn lange genug nichts passiert (und dabei Warnzeichen ignorieren). Das Abweichen vom Ideal wird für uns normal, wenn nur die "Inkubationszeit" bis zum Desaster lang genug ist.
Diane Vaughan hat in ihrem Buch "The Challenger Launch Decision" beschrieben, dass solche Prozesse zum Absturz der Challenger-Raumfähre 1986 geführt haben.

Marco führt den Begriff ein und beschreibt dann vier Generationen von Steuerungen für die funktionale Sicherheit seit den 80er Jahren: Stückchenweise sind wir von mechanischen, komplett unabhängigen Systemen zu digitalen, voll ins Leitsystemen integrierten Systemen "abgewichen". (Ohne größere Vorfälle. Ach ja, außer halt den paar Vorfällen aus der Cybersecurity: Maroochydore, Stuxnet, Triton..).
Ist das technischer Fortschritt? Oder "Normalisation of Deviance"?

Einen Gänsehautmoment hat Marco auch eingebaut. Er lässt nämlich Dr. David Clark zu Wort kommen, der am MIT in den 70ern die Architektur für das mitgebaut hat, was heute das Internet ist. In einem 2011 aufgenommenen Video erzählt er:
"Als die Leute gefragt haben, ob wir uns vorstellen konnten, dass das Internet mal Systeme auf der ganzen Welt verbinden würde, haben wir gesagt - klar! Es könnte Zehntausende Systeme im Internet geben! [...] Wenn Sie uns damals gefragt hätten, hätten wir wahrscheinlich gesagt, dass es eine ziemliche dumme Idee ist, Teile des Netzwerks für den Betrieb von kritischen militärische Operationen oder kritischer Infrastuktur wie dem Stromnetz an ein öffentliches Network zu hängen. Das tut man einfach nicht!"

Wir wissen alle: Tut man mittlerweile halt doch. Technischer Fortschritt? Oder "Normalisation of Deviance"?

Marco macht das klug, er beantwortet die Frage nicht. Aber er sorgt dafür, dass wir sie uns stellen. Das Video lohnt sich, Link folgt:

5. Ein realistischeres Bild von "Security by Design" (OTCEP-Video)

Und noch mal Singapur: Auch meine Präsentation für das OT Cybersecurity Expert Panel Forum ist nun online. Es geht um Security-by-Design-Mythen, aber vor allem ist die Präsentation auch der bislang umfassendste öffentlich verfügbare Einblick in das Security-by-Design-Tool, das wir während unseres Forschungsprojektes "IDEAS" gebaut haben.

Aber nun zu den drei "Security by Design"-Mythen:

Mythos 1: Security by Design ist ein Herstellerproblem.
Realität: Security by Design (in der Industrie) ist ein gemeinsames Problem von Herstellern und Anlagenbetreibern, das sie auch nur gemeinsam lösen können. (Auch wenn ich jeden Betreiber verstehen kann, der nach jahrelanger KRITIS-Regulierung gern auch mal einen Teil des Problems zu den Herstellern schieben würde).

Mythos 2: Security by Design macht man, indem man "Secure by Design-Prinzipien" befolgt.
Realität: Security by Design macht man, indem man Security-Entscheidungen in der Designphase explizit macht und trifft. (Das ist gar nicht so schwer, wenn man weiß, wo man suchen muss. Ich zeige Ihnen im Video acht Arten von "Security by Design"-Entscheidungen, damit Sie sie künftig nicht mehr übersehen).

Mythos 3: Security by Design ist erfolgreich, wenn nach dem Design keine Schwachstellen auftauchen.
Realität: Das ist ein unrealistisches Ziel und hilft nur "Cybersicherheitsexperten", die gerne mit dem Finger auf "lächerlich unsichere" Unternehmen zeigen. Wie wäre es, wenn wir uns Ziele setzen, die wir messen und erreichen können? Zum Beispiel das hier: Security by Design ist erfolgreich, wenn nach dem Design alle Security-Entscheidungen für Dritte nachvollziehbar sind.

Das war die Kurzform - Langform und alles, was bei der praktischen Umsetzung von Security by Design hilft, gibt's im Video. Habe ich Ihnen unten verlinkt.

Stay secure!
Sarah Fluchs