Ich bin gerade aus den USA von der S4x23 in "SoBe" (Miami South Beach) zurück und sowas von vollgesogen mit neuen Ideen. Dementsprechend ist das Security-Briefing in diesem Monat auch etwas USA-lastig.
Außerdem habe ich aber auch unsere bislang umfangreichste Veröffentlichung aus unserem Security-by-Design-Forschungsprojekt im Gepäck. Und zum Ende des Briefings schauen wir in die Ukraine und dann "umme Ecke" - nach Essen.

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

1. S4x23: Die Kraft des Satzes "ich weiß es nicht"
2. S4x23: Security by Design Decisions - entscheiden, welche Security-Maßnahmen Sie NICHT brauchen
3. CISA-Chefin schreibt ein starkes Plädoyer für Security by Design
4. Wissenschaftliche Grundlage für Security-Engineering-Diagramme
5. Ein Jahr Krieg in der Ukraine: Blick hinter die Kulissen der Cyberabwehr
6. "Safety und Security in der Anlagensicherheit" in Essen

1. S4x23: Die Kraft des Satzes "ich weiß es nicht"

Tja, drei Tage S4 mit so viel neuen Ideen - wo fängt man da an? Ganz vorne, habe ich entschieden - mit Dale Petersons Keynote zur Einstimmung auf die Konferenz. Die Keynote war voll gepackt mit guten Gedanken. Einen davon habe ich für Sie herausgepickt:

"Vor dem 19. Jahrhundert hatten die Kartographen das, was Historiker als horror vacui bezeichnen, eine Angst davor, leeren Raum auf der Karte einzuzeichnen. [...]
Einer der wichtigsten Fortschritte in der Kartenerstellung bestand darin, zuzugeben, was nicht bekannt war. Den horror vacui zu überwinden und ihn sogar zu nutzen. Die Anerkennung dieser leeren Flecken motivierte die Forscher, sich auf den Weg zu machen und die Informationen zu suchen, um die Leerstellen zu füllen.
Für die meisten unserer "good practices" für OT-Security wissen wir nur sehr wenig über die tatsächliche Auswirkung auf Verluste und missionskritische Risiken. Wir haben unsere eigene Version des horror vacui. Wir wollen nicht zugeben, dass wir es wirklich nicht wissen."

Cybersecurity ist eine Branche voller Berater. Ich selbst wollte eigentlich nie Berater werden, wurde es aber trotzdem, weil es die beste (damals: einzige?) Möglichkeit war, sich mit Security für industrielle Automatisierungssysteme (ICS) zu beschäftigen - und zwar "an der bleeding edge", also da, wo die ganz neuen Erkenntnisse entstehen.

Heute bin ich gerne Beraterin, aber der horror vacui, den Dale erwähnt, ist tatsächlich eine Berater-Berufskrankheit, eine "déformation professionelle".

In einem Geschäft, dessen Existenzberechtigung darin besteht, dass man mehr weiß als seine Kunden; in einem Geschäft mit dem geflügelten Wort "first said ist right", ist die Angst, sein Nichtwissen zuzugeben, verständlich.

Aber sie schadet mehr, als sie nützt, wie Mariana Mazzucato in einem kürzlich erschienenen Buch über Beratung im öffentlichen Sektor (Lesestoff 1+2) brillant darlegt:

"Berater und Outsourcer, so Mazzucato, wissen weniger, als sie behaupten, kosten mehr, als sie vorgeben, und verhindern - auf lange Sicht -, dass der öffentliche Sektor eigene Fähigkeiten entwickelt. 'Wir sind nicht gegen Berater. Das Problem ist, wenn eine Branche keinen Anreiz hat, die Regierung zur Unabhängigkeit zu bewegen. Ein Therapeut, der seinen Patienten ewig in Therapie hält, ist offensichtlich kein sehr guter Therapeut.' "

Wie Dale richtig feststellt, wissen wir in der Cybersecurity ALLE viel zu wenig darüber, welche unserer "Best Practices" wirklich helfen. Und mal ehrlich: Wenn ALLE Experten es nicht wissen, ist es wirklich keine Schande, wenn du als Berater es nicht weißt - selbst wenn du als Cybersecurity-Experte eingestellt wurdest.

Aber wir trauen uns nicht zuzugeben, dass wir etwas nicht wissen, und wir trauen uns auch nicht, einige der "Best Practices" bewusst NICHT zu implementieren (mehr dazu im nächsten Thema dieses Briefings).
Was für eine Zeit- und Geldverschwendung, Cybersecurity-"Patienten" für immer in Therapie zu halten....

Alle Sessions der S4 wurden übrigens aufgezeichnet und werden in den nächsten Wochen und Monaten nach und nach auf den YouTube-Kanal der Konferenz hochgeladen. Dale hat allerdings das vollständige Transkript seiner Keynote schon jetzt veröffenlicht, sodass Sie sie nachlesen können (Lesestoff 3), bevor das Video verfügbar ist.

2. S4x23: Security by Design Decisions - entscheiden, welche Security-Maßnahmen Sie NICHT brauchen

Letzten Monat habe ich meinen eigenen S4-Vortrag zu Security by Design hier nur kurz angerissen. Jetzt gibt es hier - auch, bevor das Video online geht - die Kerninhalte und das vollständige Transkript.

Es gibt zwei Arten von Security-Entscheidungen:

1. Security-Operations-Entscheidungen helfen, dass System im Betrieb zu verteidigen ("defend the system") und
2. Security-Design-Entscheidungen helfen, ein System zu schaffen, das gut zu verteidigen ist ("defensible system")

Für Nummer 1 gibt es unzählige Tools, die die Entscheidungsfindung unterstützen: Virenschutz, Schwachstellenmanagement, Intrusion Detection, SOCs...

Für Nummer 2....gibt es nicht viel mehr als die ständig wachsenden Checklisten für Security-Maßnahmen, die wir zu befolgen versuchen. Das ist hoffnungslos, und es ist eine Verschwendung von Zeit und Geld.

Die eigentliche Herausforderung besteht also in der bewussten Entscheidung, welche Security-Maßnahmen man NICHT ergreifen wird. Mit anderen Worten: Wir müssen endlich damit beginnen, fundierte, informierte, bewusste Security-Design-Entscheidungen zu treffen.

Wer hier schon länger mitliest, weiß, dass wir seit zwei Jahren an einem BMBF-Projekt zum Thema Security by Design arbeiten. Ein Teil dieser Arbeit bestand darin, herauszufinden, warum Security by Design für Automatisierungsingenieure so schwierig ist (Spoiler: Sie haben weder Zeit noch Security-Expertise) und wie wir es für sie praktikabler machen können. In meiner S4-Präsentation habe ich vier Konzepte vorgestellt, die Security Engineering leichter machen: 

✂ Filter
📚 Bibliotheken
📊 Diagramme, und
💻 Werkzeugunterstützung

Das vollständige Transkript des Vortrags finden Sie im Lesestoff.

Vielen Dank an alle, die nach meinem Vortrag (physisch oder virtuell) zu einem Gespräch vorbeigekommen sind. Ich bin immer noch dabei, all die Ideen und das Feedback zu verarbeiten.

3. CISA-Chefin schreibt starkes Plädoyer für Security by Design

Und da wir gerade so schön beim Thema "Security by Design" sind: Die US-amerikanische Cybersecurity & Infrastructure Security Agency (CISA, unter anderem bekannt für den Betrieb des US CERT und ICS CERT) hat sich das Thema jüngst ebenfalls prominent auf die Fahnen geschrieben.

Als Auftakt hat CISA-Chefin Jen Easterly gemeinsam mit Ihrem Kollegen Eric Goldstein einen Gastbeitrag in "Foreign Affairs" veröffentlicht. Der Text trägt den schönen Titel "Stop Passing the Buck on Cybersecurity", in etwa "Hört auf, Security wie einen Schwarzen Peter weiterzureichen".
Es ist einer dieser Texte, bei dem man mit einem Textmarker mit Nachdruck alle guten Passagen gelb anstreicht - und hinterher feststellt, dass jetzt irgendwie der ganze Text gelb ist; zumindest ging es mir so. Die klare Empfehlung ist also: Lesen Sie einfach den ganzen Text, er ist auch gar nicht so lang (im Lesestoff - hinter einer Bezahlschranke, die aber für einen Probeartikel umgangen werden kann).

Warum, schreiben Easterly und Goldstein, ist es eigentlich normal und akzeptiert, dass Produkte eben unsicher sind und Anwender dafür sorgen müssen, dass sie sicher sind? Sie ziehen eine Parallele zur Sicherheit von Autos:

"For the first half of the twentieth century, conventional wisdom held that automotive accidents were the fault of bad drivers. Similarly, today, if a company suffers a cybersecurity breach, the company itself is blamed if it did not patch a known vulnerability. Such an approach neglects to question why the vendor that produced the technology needed to issue so many patches in the first place or why failure to implement a patch allowed a damaging breach to occur.
Any car manufactured today has an array of standard safety features—seatbelts, airbags, antilock brakes, and so on. No one would think of purchasing a car that did not have seatbelts or airbags, nor would anyone pay extra to have these basic security elements installed."

Die Verantwortung für sichere Produkte, argumentieren die beiden Autoren, muss beim Produkthersteller liegen - genauso wie die Verantwortung für sichere Autos beim Automobilproduzenten liegt. Konkret: Hersteller müssen die Verantwortung für die Security-Konsequenzen tragen, die ihre Kunden treffen, anstatt zu jedem Produkt einen Gewährleistungsausschluss mitzudenken: "Für Security musst du bei der Benutzung selbst sorgen, lieber Kunde".

Klingt absurd - das kann schließlich niemand verantworten?
Nun, die CISA ist mit diesem Blickwinkel nicht allein, und für andere Bereiche als die Security - siehe das Autobeispiel - ist dieser Ansatz ja auch schon Standard. Die EU plant mit dem Cyber Resilience Act sehr konkrete Schritte in dieselbe Richtung; ebenso das BSI mit dem IT-Sicherheitskennzeichen.

Auch der Foreign-Affairs-Artikel schließt mit konkreten Forderungen:

1. Secure by design / default definieren: Die Regierung muss konkrete Produkteigenschaften definieren, die von "secure by default" und "secure by design"-Produkten erwartet werden - und bei ihren eigenen Beschaffungsprozessen mit der Durchsetzung dieser Anforderungen beginnen.
2. Cybersecurity-Kennzeichen: Die Regierung muss Unternehmen brandmarken, die fahrlässig mit Security umgehen und solche loben, die Fortschritte machen - zum Beispiel mit der Vergabe von Cybersecurity-Kennzeichen.
3. Cybersecurity ist kein IT-Thema: Cybersecurity-Risiken müssen als globale Geschäftsrisiken eines Unternehmens betrachtet werden, und die Verantwortung für diese Risiken muss beim CEO liegen. Cybersecurity muss raus aus der IT-Nische.
4. Transparenz und Zusammenarbeit: Mehr Informationen müssen zwischen Regierung und Privatwirtschaft ausgetauscht werden. Informationen zu Security-Vorfällen und -Angriffen, aber auch zu Verteidigungsstrategien.
5. Den Kleinen helfen: Besonders kleine, aber sehr kritische Unternehmen ("target rich, cyber poor") brauchen Unterstützung beim Aufbau ihrer Cybersecurity.
6. Lösungsneutrale Anforderungen: Um kleineren Unternehmen den Markteintritt nicht zu erschweren, sollen Anforderungen für Security-Anforderungen außerdem auf das richtige Ergebnis, nicht auf dogmatische, vorgeschriebene Features abzielen, damit kreative, eigene Lösungen möglich bleiben.

Das alles ist erst einmal nur ein Gastbeitrag in einer Zeitung, aber die Vision ist groß, mutig und zeitgemäß. Eine der riesigen Herausforderungen wird es sein, die Security-by-Design-Anforderungen entgegen aller Lobby-Bemühungen tatsächlich lösungsneutral zu halten - udn Unternehmen das Handwerkszeug an die Hand zu geben, damit sie ihre eigenen Lösungen finden können. Wer weiß, vielleicht wird ja eines Tages ein besonders elegant umgesetztes Security-Feature sogar mal ein Verkaufsargument?
Ich würde das Produkt, das mich von den gefühlten tausend verschiedenen Authentifizierungsmaßnahmen auf meinem Rechner und Smartphone erlöst, jedenfalls sofort kaufen.

The ultimate goal, however, is to dramatically improve product safety, so technology customers rarely need to secure their systems on their own. Although some safety measures will become as easy to use as a seatbelt, most organizations should be protected before they even “buckle up.”

4. Wissenschaftliche Grundlage für Security-Engineering-Diagramme

Schon jahrelang habe ich den Traum von Diagrammen, die uns beim Security Engineering helfen. Ein R&I-Fließbild für Security! Alle anderen Ingenieurdomänen haben das doch auch!

Ich habe mal Maschinenbau studiert. Egal, in welchem Fach ich Klausuren schrieb - um das Problem zu verstehen (und oft auch, um es zu lösen), machte man erst einmal ein Zeichnung. Was haben wir alles gezeichnet: Oliven in Martinigläsern, kugelrunde Schweine, Schnee auf Dächern, Kardanwellen, Gas- und Dampf-Kraftwerke, Eisen-Kohlenstoff-Diagramme, den Endgegner Radialwellendichtring und natürlich unzählige Schrauben.

Aber für Security? Welche Zeichnung hilft für Security, die Gedanken zu ordnen und Probleme zu lösen?

Natürlich, ich hätte nun einfach drauflosmalen können und Diagramme erstellen. Aber es gibt ja schon Fragmente, nicht standardisierte Diagramme, die man für Security-Überlegungen nutzen kann: Netzwerkpläne, Data-Flow-Diagramme.
Security ist außerdem eine Querschnittsdisziplin, also könnte man auch bestehende Diagramme - R&I-Fließbilder beispielsweise - nutzen und ergänzen.
Und dann gibt es einen großen Fundus an existierenden Diagrammen aus dem Software- und Model-based Engineering, teilweise auch standardisiert in UML und SysML, und dazu Security-Versionen: UMLsec, SysML-Sec, Secure UML. Von security-spezifischen Bildsprachen wie CORAS ganz zu schweigen.

Nur: Wie nutzt man all das für Security Engineering? Und ist es auch nutzbar für Industrial Control System (ICS) Security?

Und: Wann genau hat ein Diagramm eigentlich Vorteile gegenüber einem schnöden Text oder einer Tabelle? Sagt ein Bild wirklich immer mehr als tausend Worte? Ein weiteres Kaninchenloch, kann ich Ihnen sagen, denn die Antwort ist natürlich "nein" - um wirklich effektive Diagramme zu konstruieren, muss man abtauchen in die Wissenschaft der menschlichen visuellen Wahrnehmung und neue Vokabeln wie "cognitive effectiveness" lernen.

Sie sehen also: So einfach, wie es zunächst aussieht, ist das mit den Security-Engineering-Diagrammen nicht. Ich kann nicht mehr zählen, wie viele Diagramme ich gewälzt habe. Das Ergebnis ist ein peer-reviewter Journalbeitrag, in dem wir

• Definieren, was wir eigentlich unter Security Engineering verstehen
• Erklären, wie Diagramme beim Security Engineering helfen können
• Qualitätskriterien für Semantik und Syntax solcher Diagramme definieren ("cognitive effectiveness" lässt grüßen)
• Existierende Diagramme, die für Security Engineering verwendet werden könnten, anhand dieser Kriterien evaluieren (all die oben erwähnten und mehr)
• Aus den Ergebnissen der Evaluierung fünf Säulen für tragfähige Security-Engineering-Diagramme ableiten
• ...und schließlich in einer Vision skizzieren, wie diese aussehen könnten.

Das Paper ist eher keine leichte Kost, aber es ist die wissenschaftliche Basis für die Security-Engineering-Diagramme, die wir gerade entwickeln. Ich kann meinen Ko-Autoren Prof. Dr.-Ing. Rainer Drath und Prof. Dr.-Ing. Alexander Fay nicht genug danken, dass sie sich mit mir durch diese Grundlagenarbeit gebissen haben.

Der Journalbeitrag ist frei verfügbar (Open Access). Den Link finden Sie im Lesestoff. Sollte er Fragen aufwerfen (was bei 28 Seiten, 22 Abbildungen, 13 Tabellen und 72 Quellen schon mal passieren kann): Ich stehe für Antworten parat.

5. Ein Jahr Krieg in der Ukraine: Blick hinter die Kulissen der Cyberabwehr

Der 24. Februar 2022, der Tag des russischen Einmarschs in die Ukraine, hat sich gerade zum ersten Mal gejährt. Schon ein Jahr lang dauert der Krieg - hätte man damit vor einem Jahr gerechnet?

Zu diesem traurigen Jahrestag interviewt Kerry Tomlinson die Ukrainerin Anastasiia Voitova, eine Kryptographie-Spezialistin, die nun seit einem Jahr mit der Abwehr russischer Cyberangriffe beschäftigt ist. Und davon, das kann man im Interview nachlesen, gibt es immer noch täglich jede Menge. Die Ausnahmesituation, unter der die Menschen in der Ukraine leben und arbeiten, kann man sich wohl nur vorstellen, wenn sie einem plastisch beschrieben wird:

"I have food, water, power banks, candles, thermos bottle with coffee, bathroom office (no windows, double walls, pillows everywhere), duplicated internet channels, masks, Geiger counter and many more. [...]
Everything is very scary. But when I work, when I do something productive, and when I do something that helps, I don't read news. [...]
The joke is that in Ukraine, we don't have PTSD. Because post traumatic means 'post event.' We have an ongoing stress disorder, just because there's so many events are happening ongoing in real life right now."

Das ganze Interview finden Sie im Lesestoff.

6. "Safety und Security in der Anlagensicherheit" in Essen

Zum Abschluss des März-Briefings noch ein Veranstaltungshinweis, für alle, die sich mit Anlagensicherheit für Chemieanlagen und der Störfallverordnung beschäftigen (müssen): Ende März (21.-23.03.) findet die Veranstaltung "Safety und Security in der Anlagensicherheit" statt.
Ich war letztes Jahr schon da und habe selten ein so praxisnahes, breit gefächertes Programm rund um Safety UND Security gesehen. Nach den drei Tagen haben Sie alles Rüstzeug, um die Anlagensicherheit in Ihrem Unternehmen in die Hand zu nehmen. Außerdem sind BSI und LANUV vertreten, falls Sie gern Behörden mit Fragen löchern... ich darf zwei Sessions zur IT-Risikobeurteilung beisteuern und habe meine Inhalte vom letzten Jahr nach all den Erfahrungen mit der KAS-51 generalüberholt.
Man kann sich online zuschalten oder nach Essen kommen. Anmeldungen sind noch möglich, den Link finden Sie unten im Lesestoff.

Und weil wir gerade beim Thema sind: Unser neuer Kongress "Security unter Kontrolle" ist übrigens nun als Weiterbildung für Störfallbeauftragte anerkannt....falls Ihnen noch das letzte Argument fehlte, um vorbeizukommen.

Stay secure!
Sarah Fluchs