Kapitel 1. Resilienz in Software und Systemen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Die Welt steht auf Absurditäten, und ohne sie würde vielleicht gar nichts passieren.

Fjodor Dostojewski, Die Brüder Karamasow

In unserer heutigen Realität ist Cybersicherheit eher eine geheimnisvolle Kunst als eine Wissenschaft - eine undurchschaubare, oft quälende Abfolge von Ritualen zum Ankreuzen von Kästchen1 die bestätigen, dass man die entsprechenden (und oft willkürlichen) gesetzlichen oder normativen Anforderungen erfüllt hat. Was die Sicherheit von Systemen angeht, ist der Idealzustand die Widerstandsfähigkeit - die Gewährleistung, dass Systeme trotz der Gefahren, die in unserer digitalen Welt lauern, jetzt und in Zukunft erfolgreich arbeiten können. Um die Widerstandsfähigkeit aufrechtzuerhalten, müssen wir verstehen, wie alle Maschinen und Menschen im System zusammenwirken, um ein gemeinsames Ziel zu erreichen, und wie sie auf Störungen reagieren.2 Es reicht nicht aus, die Feinheiten der Cybersicherheit zu kennen. Wir müssen die Widerstandsfähigkeit des Systems (oder deren Mangel) verstehen, wenn wir es schützen wollen, was ein Verständnis der Systemdynamik voraussetzt, wie wir in diesem Kapitel untersuchen werden. Aus diesem Grund behandeln wir in diesem Buch die Sicherheit als Teilbereich der Resilienz.

Dieses Buch ist ein praktischer Leitfaden dafür, wie man Systeme entwirft, baut und betreibt, die widerstandsfähiger gegen Angriffe sind. Wir geben dem Fortschritt Vorrang vor der Perfektion. Wir ziehen Lehren aus anderen Bereichen komplexer Systeme, wie dem Gesundheitswesen, der Luft- und Raumfahrt, der Katastrophenhilfe, der Ökologie, der städtischen Infrastruktur und der Psychologie. Der reichhaltige Diskurs über Resilienz in diesen anderen Bereichen ist ein weiterer Grund, warum Resilienz die Grundlage des Security Chaos Engineering (SCE) ist. "Sicherheit" ist ein abstraktes, schwammiges Konzept, das in der Cybersicherheitsbranche (oder "Infosec") weitgehend in sich abgeschlossen ist, wobei gelegentlich Konzepte aus der physischen Sicherheit, der Strafverfolgung und - besonders berüchtigt - der Kriegsführung übernommen werden. Bei der Widerstandsfähigkeit können wir jedoch viel von anderen Disziplinen lernen, um unsere Systeme sicher zu betreiben und den Arbeitsaufwand und die "Denkarbeit" zu reduzieren, die wir für unseren Erfolg benötigen.

Wenn wir unseren Fokus von der Sicherheit auf die Resilienz verlagern, gewinnen wir eine Superkraft: Wir investieren unsere Zeit, Energie und andere Ressourcen in ergebnisorientierte Aktivitäten, anstatt diese Ressourcen für performative Arbeit zu verschwenden, die sich zwar produktiv anfühlt, aber in Wirklichkeit unsere Systeme nicht schützt. Resilienz spielt in jedem komplexen System eine Rolle und ist in komplexen Systemen, an denen Menschen beteiligt sind, besonders aufschlussreich. Das ist unsere Vision für Sicherheitsprogramme, die in Zukunft zu Resilienzprogrammen werden können. Wenn du dich der SCE-Bewegung anschließt, kannst du die Fähigkeit deines Unternehmens schützen, jetzt und in Zukunft erfolgreich zu sein. Alles, was du dafür tun musst, ist, offen zu sein für neue Perspektiven und neue Wege zur Erreichung von Sicherheitsergebnissen, um die es in diesem Buch geht.

Das SCE versucht, durch experimentelle Beweise herauszufinden, ob unsere Systeme unter bestimmten Bedingungen belastbar sind, damit wir lernen können, wie wir sie noch belastbarer machen können. Versagen ist eine normale Bedingung für den Betrieb eines Systems. SCE bietet Unternehmen eine pragmatische Reihe von Prinzipien und Praktiken, um unbekannte Fehler in ihren Systemen proaktiv aufzudecken, bevor sie sich in kundenorientierten und geschäftsrelevanten Problemen manifestieren. Wer SCE praktiziert, wartet nicht mehr passiv darauf, wie Dinge in der Produktion kaputtgehen, sondern geht von einer reaktiven zu einer proaktiven Haltung über.

Dies sind nur einige der Ergebnisse, die durch einen resilienzbasierten Ansatz zur Systemsicherheit durch die SCE möglich sind. Bevor wir uns auf den Weg machen, müssen wir uns - wie jeder gute Wissenschaftler - die grundlegenden Konzepte aneignen, die uns den Weg ebnen werden. Was ist ein komplexes System? Was ist Versagen? Was ist Resilienz? Und was hat die SCE damit zu tun? Dieses Kapitel gibt Antworten auf all diese Fragen. Viele traditionelle Infosec-Volksweisheiten werden in Frage gestellt und zugunsten von hart erarbeiteten, empirischen Lektionen über Resilienz in verschiedenen Bereichen verworfen. Wir laden dich ein, wie Neo in der Matrix, deinen Geist zu befreien und mit uns einen Sprung in die reale Welt zu wagen, in der Resilienz nicht nur unser Überleben, sondern auch unser Gedeihen bestimmt.

Was ist ein komplexes System?

Ein komplexes System ist ein, in dem eine Reihe von Komponenten miteinander interagieren und dadurch ein nichtlineares Verhalten erzeugen. Wir Menschen haben ständig mit komplexen Systemen zu tun, von globalen Lieferketten über Volkswirtschaften und Städte bis hin zu unserem eigenen Körper und unserem eigenen Gehirn. Doch bevor wir uns eingehender mit komplexen Systemen beschäftigen, sollten wir erst einmal verstehen, was Komplexität ist.

Komplexität wird formal als zusammenfassender Begriff für die Eigenschaften definiert, die sich aus den Wechselbeziehungen zwischen den Variablen in einem System ergeben.3 Wenn die Fähigkeiten eines Systems zunehmen, werden die Abhängigkeiten zwischen diesen Variablen größer, tiefer und undurchsichtiger. Diese Abhängigkeiten können zu einem Dominoeffekt führen, bei dem sich Störungen von einer Variablen auf andere, mit ihr verbundene Variablen ausbreiten. Dies wird als "Ansteckungseffekt" bezeichnet und ist in Bereichen wie den Finanzmärkten zu beobachten,4 Psychologie,5 und natürlich auch bei biologischen Viren.6 In verteilten Systemen wird dieses Phänomen auch als "Kaskadenversagen" bezeichnet (das wir in Kapitel 3 genauer untersuchen werden ).

Was macht ein System in der Praxis komplex? Denken wir zunächst an einfache Systeme. Lineare Systeme sind einfach. Wenn etwas Schlimmes passiert, musst du nur dafür sorgen, dass das System robust genug ist, um wieder zum Status quo zurückzukehren. Nehmen wir Mr. Potato Head: Es gibt eine klare, direkte Ursache und Wirkung zwischen dem Einstecken seiner Augäpfel und den Augäpfeln in seinem Gesicht. Wenn du stattdessen sein Ohr in den Armsteckplatz steckst, ist es einfach, zu der beabsichtigten Anordnung zurückzukehren - und dieser Fehler verursacht keine Probleme mit seinen Augen, Füßen, seinem Hut, seinem Mund oder seinem ikonischen Schnurrbart. Die Basis des Kartoffelkopfs interagiert mit den Anbauteilen auf extrem vorhersehbare und wiederholbare Weise. Aber lineare Systeme wie Mr. Potato Head7 findet man eher in Lehrbüchern und in konstruierten Hypothesen als in der realen Welt, die chaotisch ist. Um eine klassische Weisheit für Computersysteme zu übernehmen: "Kein 'perfekter' Softwaredienst überlebt den ersten Kontakt mit dem Produktionsverkehr."

Wo weichen komplexe Systeme und lineare Systeme am meisten voneinander ab? Um diese Frage zu beantworten, wollen wir das Wesen komplexer Systeme erforschen, einschließlich Vielfalt, Anpassungsfähigkeit und Ganzheitlichkeit.

Vielfalt macht komplexe Systeme aus

Vielfalt ist vielleicht das bestimmende Element von Komplexität; was wir als "komplexe" Systeme bezeichnen, sind Systeme mit einem hohen Maß an Vielfalt. Systeme sind voll von allen Arten von Vielfalt: die Vielfalt der Komponenten, die Vielfalt der Wechselwirkungen zwischen diesen Komponenten und die Vielfalt der möglichen Ergebnisse im System. Unsere Computersysteme beinhalten viele Variablen und Komponenten - Wetware (unser Gehirn), Software, Hardware - und bieten daher auch eine große Vielfalt an möglichen zukünftigen Zuständen.

Da komplexe Systeme ein wahres Festival von Variablen beinhalten, die sich auf oft unkonventionelle Weise miteinander tummeln, können sie eine große Vielfalt an möglichen Zuständen aufweisen.8 Die Sicherheitsforschungsorganisation Jepsen stellt fest, dass verteilte Systeme "einen logischen Zustand haben, der sich im Laufe der Zeit ändert", und das ist bei allen Arten von komplexen Computersystemen nicht anders. Aus diesem Grund wird die Vorhersage in einem Resilienz-Paradigma als extravagante Ablenkung empfunden. Bei so vielen möglichen zukünftigen Zuständen innerhalb des Systems gibt es nie nur einen Weg, der zu einem bestimmten Ergebnis führt.9 Noch schwieriger ist es, dass die gleiche Abfolge von Aktionen im System zu unterschiedlichen Ergebnissen führen kann. Um in einem komplexen System von Punkt A nach Punkt B zu gelangen, muss man weniger "Luftlinie" als vielmehr "wie eine Katze wandern" (oder "zoomen").

Komplexe Systeme sind anpassungsfähig

Wichtig ist, dass komplexe Systeme anpassungsfähig sind; sie verändern und entwickeln sich über Zeit und Raum hinweg, insbesondere als Reaktion auf Veränderungen in ihrer äußeren Umgebung. Unsere Softwaresysteme sind komplexe adaptive Systeme und, was manche Informatiker manchmal vergessen, sie sind soziotechnologischerNatur. Sowohl Maschinen als auch Menschen sind Bestandteile unserer technischen Systeme, egal ob es sich um Produktionssysteme oder IT-Systeme von Unternehmen handelt. Das Ökosystem der Cybersicherheit ist selbst ein komplexes adaptives System, das nicht nur aus einer Vielzahl von Maschinen besteht, sondern auch aus Entwicklern, Verteidigern, Endnutzern, staatlichen Aufsichtsbehörden, staatlich geförderten Angreifern, kriminellen Organisationen, Prüfern und unzähligen anderen menschlichen Akteuren.

Komplexe Systeme sind anpassungsfähig, weil Veränderungen nicht gestoppt werden können - und somit auch das Auftreten von Fehlern nicht verhindert werden kann. Ein resilientes komplexes System ist ein System, das mit diesem Versagen gut umgehen kann und sein Verhalten so anpasst, dass seine kritischen Funktionen erhalten bleiben.10 Das Verständnis der Übergänge zwischen den verschiedenen möglichen zukünftigen Zuständen - wie sich ein System an laufende Veränderungen anpasst - ist der Schlüssel zum Verständnis der Widerstandsfähigkeit und Sicherheit deines Systems im Laufe der Zeit.

Wir müssen auch anerkennen, dass Menschen eine Quelle der Stärke sind, wenn ein System an der Grenze zwischen Erfolg und Scheitern steht. Menschen sind in vielen Fällen unsere Anpassungsmechanismen angesichts widriger und sich entwickelnder Bedingungen, weil sie von Natur aus neugierig auf die Probleme sind, mit denen sie konfrontiert werden.11 Im Gesundheitswesen zum Beispiel sind Notaufnahmen aufgrund von Veränderungen, die das Management durch finanziellen und betrieblichen Druck erzwungen hat, oft brüchig und damit weniger widerstandsfähig gegenüber "kumulativen oder kaskadierenden Anforderungen", die sie über ihre bekannte sichere Kapazität hinaus belasten.12 Das System der Notaufnahme muss sich daher angesichts größerer Anforderungen an den Betrieb "strecken", damit sich einzelne Fehler - wie z. B. notwendige Aktivitäten, die durch die Maschen fallen - nicht anhäufen und das Gesamtsystem zum Scheitern bringen. Wie wird dieses Dehnen erreicht? Die Menschen im System sind diejenigen, die diese Ausdehnung ermöglichen. Sie können härter arbeiten, ihre Strategien anpassen und nach zusätzlichen Ressourcen suchen, z. B. indem sie andere Menschen bitten, ihnen zu helfen, um zusätzliche Anpassungsfähigkeit zu schaffen.13

Die holistische Natur komplexer Systeme

Die Komplexität eines Systems - und sein Verhalten - ist ganzheitlich definiert; aus dem Verhalten der einzelnen Komponenten lässt sich nur wenig ablesen.14 Systemdenken ist für die meisten Menschen nicht selbstverständlich, und auch Sicherheitsexperten sind davon nicht ausgenommen. In der Cybersicherheitsbranche gibt es einen Trend zur Komponentisierung, bis hin zu spezifischen Werkzeugen und Umgebungen. Leider schränkt dieser komponentenbasierte Fokus deine Fähigkeit ein, zu verstehen, wie dein Teilbereich der Sicherheit mit allen anderen Komponenten zusammenhängt, die zusammen die Funktionsweise des Systems bestimmen. Wenn du nur eine Komponente betrachtest, ist das wie ein enger Blickwinkel - oder besser gesagt, wie ein Kegelkragen, der es dir schwer macht, dich in der Welt zurechtzufinden. Nancy G. Leveson, Professorin für Luft- und Raumfahrttechnik am MIT, warnt uns davor, dass "ein enger Fokus auf die Handlungen des Bedieners, das Versagen physischer Komponenten und die Technologie dazu führen kann, dass einige der wichtigsten Faktoren für die Verhinderung künftiger Unfälle außer Acht gelassen werden".15

Angreifer erkennen die ganzheitliche Natur von Systemen und nutzen routinemäßig die Zusammenhänge zwischen den Komponenten aus. Sie suchen nach Möglichkeiten, wie sie sich durch Interaktionen innerhalb eines Systems einen Vorteil verschaffen können. Die Angriffsphase "Lateral Movement" bedeutet nichts anderes, als die Verbindung zwischen einer Komponente eines Systems und anderen Komponenten innerhalb des Systems auszunutzen. Verteidiger/innen hingegen denken bei der Sicherheit traditionell daran, ob einzelne Komponenten sicher sind oder ob die Verbindungen zwischen ihnen sicher sind. Beim Status quo der Sicherheit denkt man eher in Listen als in Graphen, während Angreifer eher in Graphen als in Listen denken. In der traditionellen Cybersicherheitsverteidigung mangelt es an Systemwissen, was Angreifer nur allzu gerne ausnutzen.

Die aufsehenerregende Kompromittierung von SolarWinds verdeutlicht diese Dynamik sehr gut. Der russische Auslandsgeheimdienst (SVR) hatte ein bestimmtes Ziel vor Augen: Zugang zu Bundesbehörden und Fortune-500-Unternehmen zu (vermutlich) Spionagezwecken. Eine Möglichkeit, dieses Ziel zu erreichen, bestand darin, nach Komponenten und Subsystemen zu suchen, die die Zielsysteme gemeinsam hatten. Die Orion-Plattform von SolarWinds, die die Überwachung und Verwaltung von Infrastrukturen ermöglicht, wurde nicht nur von vielen Bundesbehörden und großen Unternehmen genutzt, sondern verfügte auch über Funktionen, die ihr Zugang zur internen Infrastruktur der Kunden gewährten. Auf diese Weise nutzten die Angreifer Zusammenhänge und Interaktionen auf mehreren Abstraktionsebenen aus.

Eine ganzheitliche Systemperspektive darf sich jedoch nicht auf eine bestimmte Technologie beschränken. Die Art und Weise, wie Unternehmen Technologie nutzen, beinhaltet auch wirtschaftliche und soziale Faktoren, die von traditionellen Cybersicherheitsprogrammen für Unternehmen nur allzu oft ignoriert oder übersehen werden. Zu den wirtschaftlichen Faktoren in einem Unternehmen gehören Umsatz- und Gewinnziele, die Struktur von Vergütungssystemen oder andere Haushaltsentscheidungen. Zu den sozialen Faktoren in einem Unternehmen gehören die wichtigsten Leistungsindikatoren, die Leistungserwartungen an die Beschäftigten, die Art von Verhalten, das belohnt oder geahndet wird, oder andere kulturelle Facetten.

In der Branche neigen wir dazu, Schwachstellen mit Fehlern in der Software in Verbindung zu bringen, aber Schwachstellen werden auch durch Anreizsysteme verursacht. Wir übersehen die Schwachstelle, wenn wir Anreize schaffen, mehr Arbeit zu erledigen, aber schneller. Wir übersehen die Anfälligkeit von Boni für "Ja-Sager" und diejenigen, die politische Spielchen beherrschen. Diese Schwachstellen verringern die Widerstandsfähigkeit der Organisation genauso wie Softwarefehler, aber sie tauchen nur selten in unseren Bedrohungsmodellen auf. Gelegentlich identifizieren wir "verärgerte Mitarbeiter" als potenzielle Insider-Bedrohung, ohne die Faktoren zu untersuchen, die sie dazu bringen, verärgert zu sein.

Diese "Schicht 8"-Faktoren (menschliche Faktoren) sind in einer Organisation vielleicht schwer zu erkennen, geschweige denn zu beeinflussen. Aber wenn wir uns überlegen, wie sich Scheitern manifestiert, müssen wir sie trotzdem berücksichtigen.

Was ist Scheitern?

Ein Ausfall bezieht sich auf, wenn Systeme - einschließlich der beteiligten Personen und Geschäftsprozesse - nicht wie vorgesehen funktionieren.16 Ein Dienst, der die Kommunikation mit einem anderen Dienst, von dem er abhängt, nicht abschließen kann, würde als Fehlschlag gelten. In ähnlicher Weise können wir es als Fehler betrachten, wenn Sicherheitsprogramme die Sicherheitsziele nicht erreichen. Es gibt mehr mögliche Fehler in Software, als wir aufzählen können: Missbrauch einer API, der zu einem Leck in den Nutzerdaten führt, das Ängste auslöst und die Nutzer dazu zwingt, Kreditüberwachungsdienste zu kaufen; ein Denial-of-Service-Angriff (DoS), der lange genug dauert, um Service-Level-Agreements (SLAs) zu verletzen und Umsatzrückerstattungen auszulösen; sich wiederholende, mühsame und manuelle Aufgaben mit unklarem Ergebnis, die zu ausgebrannten, verärgerten menschlichen Bedienern führen. Und so weiter, bis ins Unendliche.

Scheitern ist unvermeidlich und passiert ständig. Es ist ein normaler Teil des Lebens und der Arbeit in einem komplexen System, und unsere Entscheidungen - ob sie erfolgreich sind oder nicht - haben Einfluss auf das Ergebnis. Unabhängig davon, in welchem Bereich der menschlichen Tätigkeit wir tätig sind, können wir ein Scheitern nur vermeiden, indem wir die Tätigkeit ganz vermeiden: Wir könnten Flugzeugabstürze vermeiden, indem wir nie fliegen; Todesfälle bei Operationen vermeiden, indem wir uns nie einer Operation unterziehen; Finanzabstürze vermeiden, indem wir nie ein Finanzsystem aufbauen; oder, im Bereich der Cybersicherheit, Softwareversagen vermeiden, indem wir nie eine Software einsetzen. Das klingt albern, und das ist es auch, aber wenn wir nach "perfekter Sicherheit" streben oder wenn der Vorstand verlangt, dass wir nie einen Sicherheitsvorfall erleben, stellen wir uns (ironischerweise) selbst auf ein Scheitern ein. Da das Ziel von Sicherheitsprogrammen in der Regel darin besteht, "Vorfälle zu verhindern", ist es kein Wunder, dass Praktiker/innen das Gefühl haben, in einem Kampf zu stehen, den sie ständig verlieren.

Auch wenn es in der Cybersicherheit häufig so dargestellt wird, ist ein Sicherheitsversagen nie das Ergebnis eines einzigen Faktors. Ein Versagen ist nie allein auf das Vorhandensein einer Schwachstelle oder die Zurückweisung eines einzelnen Alarms zurückzuführen. Versagen funktioniert wie eine Symphonie, bei der mehrere Faktoren in wechselnden Harmonien und Dissonanzen zusammenspielen. Daher müssen wir eine Systemperspektive einnehmen, wenn wir versuchen, das Versagen von Sicherheitssystemen zu verstehen, und unseren Fokus auf die Beziehungen zwischen den einzelnen Komponenten ausweiten, anstatt die Schuld auf eine einzelne Ursache zu schieben.

Wenn wir über Sicherheitsmängel nachdenken, denken wir meist an Situationen, die eintreten, wenn die Systeme erst einmal in Betrieb sind, wie z.B. Datenpannen. Aber die Voraussetzungen für ein Sicherheitsversagen werden schon viel früher geschaffen. Versagen ist das Ergebnis miteinander verbundener Komponenten, die sich auf unerwartete Weise verhalten. Das kann - und tut es fast immer - viel früher beginnen, nämlich bei der Art und Weise, wie Systeme entworfen und entwickelt werden, und bei anderen Aktivitäten, die beeinflussen, wie unsere Systeme letztendlich aussehen und funktionieren.

Scheitern ist eine Lernchance. Es ist eine Chance, alle Faktoren zu entwirren, die zu einem unerwünschten Ereignis geführt haben, um zu verstehen, wie das Zusammenspiel dieser Faktoren das Scheitern begünstigt hat. Wenn du die Ziele, Zwänge und Anreize, die ein System beeinflussen, nicht verstehst, wirst du kaum Fortschritte machen, um das System widerstandsfähiger gegen Angriffe zu machen.

Akute und chronische Stressoren in komplexen Systemen

Wenn wir über Sicherheitsvorfälle nachdenken, neigen wir dazu, den Vorfall einem akuten Ereignis zuzuschreiben, z. B. einem Doppelklick eines Benutzers auf eine bösartige Datei oder einem Angreifer , der einen Krypto-Miner-Nutzlast ausführt. Im Fachjargon werden diese akuten Ereignisse als impulsartige Stressoren bezeichnet. Impulsartige Stressoren sind negative Einflüsse auf das System, die über einen kurzen Zeitraum hinweg auftreten, wie z.B. Wirbelstürme in ökologischen Systemen. Im Gegensatz dazu sind Stressoren vom Typ "Druck" negative Einflüsse, die über einen längeren Zeitraum auftreten, wie z. B. Umweltverschmutzung, Überfischung oder die Erwärmung der Meere. Der Klarheit halber werden wir in diesem Buch pulsartige Stressoren als "akute Stressoren" und drückende Stressoren als "chronische Stressoren" bezeichnen.

Das Problem bei der kurzsichtigen Fokussierung auf akute Stressoren in einem komplexen System ist, dass diese Ereignisse das System nicht von alleine zum Scheitern bringen. Das Hintergrundrauschen chronischer Stressoren schwächt die Widerstandsfähigkeit des Systems über einen längeren Zeitraum, ob Monate oder Jahre, so dass das System nicht mehr in der Lage ist, ein akutes Ereignis zu absorbieren oder sich davon zu erholen, wenn es eintritt.

Wie sehen chronische Stressoren in der Cybersicherheit aus? Dazu können gehören:

  • Regelmäßige Mitarbeiterfluktuation

  • Werkzeugausbreitung und Regalware

  • Unfähigkeit, Systeme/Software zu aktualisieren

  • Unflexible Verfahren

  • Laufband aufrüsten und reparieren

  • Technologie-Schulden

  • Voreingenommenheit gegenüber dem Status quo

  • Burnout der Beschäftigten

  • Lücken in der Dokumentation

  • Alarmsignale von geringer Qualität

  • Kontinuierliche Wartung der Werkzeuge

  • Angespannte oder gestörte Beziehungen innerhalb der Organisation

  • Automatisierungsrückstau oder Paradigma des manuellen Verfahrens

  • Fokus auf menschliches Versagen und Schuldzuweisungen

  • Mentalität der Prävention

Und zu den akuten Stressoren in der Cybersicherheit können gehören:

  • Ransomware Betrieb

  • Menschlicher Fehler

  • Kernel-Exploit

  • Neue Verwundbarkeit

  • Fusionen, Übernahmen oder ein IPO-Ereignis

  • Jährliche Prüfung

  • Ende der Lebensdauer eines kritischen Werkzeugs

  • Ausfall aufgrund eines Sicherheitstools

  • Ausfall des Logs oder der Überwachung

  • Änderung des Konformitätsstandards

  • Neue Produkteinführung

  • Gestohlene Cloud-Administrator-Anmeldedaten

  • Umstrukturierung oder Personalfragen

  • Vertragliche Änderungen (wie SLAs)

Die Erholung von akuten Stressoren ist zwar wichtig, aber das Verständnis und der Umgang mit chronischen Stressoren in deinem System stellen sicher, dass die Erholung nicht eingeschränkt wird.

Überraschungen in komplexen Systemen

Komplexe Systeme haben auch das "Geschenk" plötzlicher und unvorhergesehener Ereignisse, die in manchen Bereichen als "Überraschungen" bezeichnet werden. Die Evolutionsbiologin Lynn Margulis beschrieb das Element der Überraschung treffend als "die Offenbarung, dass ein bestimmtes Phänomen der Umwelt bis zu diesem Moment falsch interpretiert wurde".17 In der Softwarebranche kommen die Überraschungen, denen wir begegnen, von Computern und Menschen. Beide können uns auf unterschiedliche Weise überraschen, aber wir neigen dazu, weniger nachsichtig zu sein, wenn es Menschen sind, die uns überraschen. Es lohnt sich, beide Arten von Überraschungen zu erforschen, denn sie zu akzeptieren ist der Schlüssel zur Erhaltung der Widerstandsfähigkeit unserer komplexen Softwaresysteme.

Computer Überraschungen

Computer überraschen uns auf ärgerliche Art und Weise. Kernel geraten in Panik, Festplatten stürzen ab, Gleichzeitigkeit führt zu Deadlocks, der Speicher streikt und Netzwerke werden unterbrochen (oder schlimmer noch, Netzwerkverbindungen flattern!). Die Menschheit wird ständig mit Computerüberraschungen überschwemmt.18 Eine ewige Herausforderung für die Programmierung ist es, dafür zu sorgen, dass sich ein Programm genau so verhält, wie es von seinem Entwickler beabsichtigt war.

Wenn wir von einem Computer überrascht werden, versuchen wir instinktiv (außer den Computer zu verfluchen), das Potenzial für eine solche Überraschung in der Zukunft auszuschließen. Bei Hardware könnten wir Trusted Platform Modules (TPMs) aktivieren, um kryptografische Schlüssel besser zu schützen, oder wir könnten für mehr Redundanz sorgen, indem wir zusätzliche physische Replikate von einigen Komponenten einsetzen. Bei Software könnten wir einen Schwachstellenscanner in unsere Entwicklungspipeline einbauen oder eine manuelle Sicherheitsüberprüfung vor der Übergabe an die Produktion vorschreiben. Wenn du alle Fehler aus der Software entfernen kannst, bevor sie in die Produktionsumgebung gelangt, kannst du die Überraschungen für Computer minimieren, oder?

Natürlich wird keine dieser Maßnahmen - und auch keine andere - das Phänomen der Computerüberraschungen aus der Welt schaffen. Überraschungen sind, genau wie Fehlschläge, unvermeidlich. Sie sind ein typisches Merkmal komplexer Systeme.

Doch einige Computerüberraschungen sind im Zusammenhang mit der Sicherheit eher zweifelhaft. Angreifer, die Software wie NetWire nutzen, ein öffentliches Fernadministrationstool, das erstmals 2012 auftauchte und Ende 2022 immer noch auftaucht, sollten keine Überraschung sein. Die Realität ist, dass das Narrativ vom "schnellen und sich ständig weiterentwickelnden Angreifer" mehr Mythos als Realität ist (ein besonders bequemer Mythos für Sicherheitsanbieter und Verteidiger, die sich vor der Verantwortung drücken wollen). Angreifer entwickeln sich nur dann weiter, wenn sie es müssen, weil ihre operative Strategie, ihre Werkzeuge oder ihre Infrastruktur nicht mehr die gewünschten Ergebnisse liefert; wir werden ihr Kalkül in Kapitel 2 diskutieren.

Tipp

Komplexität verleiht unserem Leben Lebendigkeit, Neuartigkeit und Bedeutung. Ohne Komplexität gäbe es keine Gemeinschaften, keine Volkswirtschaften und keinen Fortschritt. Wenn wir versuchen, jegliche Komplexität aus unseren soziotechnischen Systemen zu verbannen, können wir negative Überraschungen auf Kosten von angenehmen Überraschungen ausschließen. Die Innovation und Kreativität, die wir schätzen, wird oft durch "Rationalisierung" unterdrückt.

Wie können wir stattdessen Gelegenheiten zum Aufblühen fördern - unsere Systeme beleben, statt sie abzustumpfen? Wir müssen die Komplexität fördern, anstatt sie zu behindern.19 indem wir Möglichkeiten bewahren und die durch Komplexität hervorgerufenen Störungen minimieren. In der Zwischenzeit können wir die richtigen Gelegenheiten finden, um Teile unserer Systeme linearer zu gestalten - mehr unabhängige Komponenten mit vorhersehbarem, kausalem Einfluss auf die Ergebnisse - so dass wir mehr Aufwand betreiben können, um die Plastizität zu fördern. In den Kapiteln 3 bis 7 erfahren wir, wie wir diese Möglichkeiten über den gesamten Lebenszyklus der Softwareentwicklung hinweg nutzen können.

Menschliche Überraschungen

Obwohl die meisten Kindergartenkinder verstehen, dass Fehler zu machen ein unvermeidlicher Teil des Lebens ist, scheint die traditionelle Cybersicherheitsbranche zu glauben, dass menschliche Fehler aus der Welt geschafft werden können. Dieses magische Denken manifestiert sich in den Sicherheitsstrategien des Status quo, die extrem anfällig für menschliche Überraschungen sind (was oft auch mit der Anfälligkeit für Computerüberraschungen zusammenhängt ). Wenn ein Mensch auf einen Link in einer E-Mail klickt, eine Aktivität, die er tausende Male im Jahr ohne Zwischenfälle durchführt, sollte das vielleicht das am wenigsten überraschende Ereignis von allen sein. Ein Mensch, der das Patchen eines Servers hinauszögert, weil zuerst ein Dutzend Genehmigungsschritte erforderlich sind, ist ebenfalls nicht überraschend. Und doch werden beide Ereignisse immer noch häufig als Hauptursache für Sicherheitsvorfälle verantwortlich gemacht, so als läge das Versagen beim Menschen, der ein ganz normales menschliches Verhalten an den Tag legt, und nicht bei einer Sicherheitsstrategie, die sich ausdrücklich dafür entscheidet, das normale menschliche Verhalten zu ignorieren.

Systeme, die am widerstandsfähigsten gegenüber menschlichen Überraschungen sind, kombinieren verschiedene Ansätze und erkennen an, dass es keine "Einheitsgröße" für alle gibt. Ein Element ist die Entwicklung (und kontinuierliche Verbesserung) von Systemen, die sich an den Menschen anpassen, anstatt den Menschen durch strenge Richtlinien zu zwingen, sich dem System anzupassen. In diesem Sinne ist kein Nice-to-have, sondern eine grundlegende Eigenschaft von resilientem Design (auf das wir in Kapitel 7 eingehen werden). Ein weiteres Element ist die Verfolgung einer lernorientierten Strategie, bei der Fehler eine Gelegenheit sind, neue Erkenntnisse zu gewinnen und Verbesserungen vorzunehmen, anstatt sie zu tadeln, zum Sündenbock zu machen oder zu bestrafen.

Wir können den Menschen nicht in absehbarer Zeit aus unseren Systemen entfernen, und deshalb ist das menschliche Element für alle Teile der SCE relevant - und dafür, wie wir die Resilienz in unseren Systemen fördern.

Was ist Resilienz?

Resilienz ist die Fähigkeit eines Systems, seine Funktionsweise als Reaktion auf veränderte Bedingungen anzupassen, damit es weiterhin erfolgreich arbeiten kann. Anstatt zu versuchen, Misserfolge zu verhindern, ermutigt uns Resilienz, mit Misserfolgen anmutig umzugehen. Die National Academy of Sciences (Nationale Akademie der Wissenschaften) definiert Resilienz als "die Fähigkeit, sich auf widrige Ereignisse vorzubereiten und zu planen, sie aufzufangen, sich von ihnen zu erholen und sich erfolgreicher an sie anzupassen".20 In ihrem Zeitschriftenartikel "Features of Resilience" (Merkmale der Resilienz) skizzieren die Autoren die fünf gemeinsamen Merkmale, die Resilienz ausmachen:21

  1. Kritische Funktionalität

  2. Sicherheitsgrenzen (Schwellenwerte)

  3. Interaktionen über die Raum-Zeit hinweg

  4. Feedback-Schleifen und Lernkultur

  5. Flexibilität und Offenheit für Veränderungen

Alle diese Merkmale - die wir im Folgenden mit den Zutaten unseres Resilienztranks in Verbindung bringen - sind für die SCE relevant und werden im Laufe des Buches immer wieder als Motiv auftauchen. Gehen wir auf jedes dieser Merkmale näher ein.

Kritische Funktionalitäten

Wenn du die Widerstandsfähigkeit eines Systems verstehen willst, musst du seine kritischen Funktionen verstehen - vor allem, wie es diese Kernfunktionen unter dem Druck schädlicher Ereignisse ausführt. Einfach ausgedrückt: Du kannst ein System nicht schützen, wenn du seinen eigentlichen Zweck nicht verstehst.

Die Definition der Daseinsberechtigung des Systems ist eine wesentliche Voraussetzung, um die Resilienz eines Systems zu beschreiben. Das Ziel ist es, die Resilienz von was, wofür und für wen zu bestimmen. Ohne diesen Rahmen bleibt unsere Vorstellung von der Widerstandsfähigkeit des Systems abstrakt und unsere Strategie ziellos, so dass es schwierig ist, Prioritäten für Maßnahmen zu setzen, die uns helfen, die Widerstandsfähigkeit zu verbessern.

Diese grundlegende Aussage kann wie folgt formuliert werden: "Die Widerstandsfähigkeit von <kritischen Funktionen> gegen <unvorteilhaftes Szenario>, damit <positives Ergebnis für den Kunden (oder die Organisation)> erreicht wird.

Für eine Börsen-API könnte die Aussage lauten: "Die Widerstandsfähigkeit der Bereitstellung von performanten Aktienkursen gegen DoS-Angriffe für Finanzdienstleistungskunden, die Echtzeit-Ergebnisse benötigen." Für ein Krankenhaus könnte die Aussage lauten: "Die Ausfallsicherheit der Workstations in der Notaufnahme gegen Ransomware, damit das medizinische Personal die Patienten angemessen versorgen kann." Wenn du festlegst, was kritische Funktionen sind und was nicht, hast du in einer Krise die Möglichkeit, vorübergehend unkritische Funktionen zu opfern, um kritische Funktionen betriebsbereit zu halten.

Das verdeutlicht, warum der Status quo von Sicherheitsteams, die in einem Elfenbeinturm sitzen, der Resilienz-Realität nicht gerecht wird. Um Systeme zu entwerfen, zu bauen und zu betreiben, die widerstandsfähiger gegen Angriffe sind, brauchst du Leute, die den Zweck des Systems verstehen und wissen, wie es funktioniert. Jede Person definiert die kritischen Funktionen eines Systems anders als eine andere Person. Die Einbeziehung von Interessenvertretern mit subjektiven, aber erfahrungsbasierten Wahrnehmungen des Systems wird notwendig. Das heißt, dass die "Verteidiger" eine Mischung aus Architekten, Erbauern und Betreibern sein müssen, um die kritischen Funktionen eines Systems zu identifizieren und seine Widerstandsfähigkeit zu verstehen. Das Team, das sich um die Sicherheit kümmert, kann sogar wie ein Team für Plattformentwicklung aussehen, das aus Softwareentwicklern besteht, wie wir in Kapitel 7 näher erläutern werden.

Sicherheitsgrenzen (Schwellenwerte)

Unser zweiter Bestandteil des Resilienztranks sind die Sicherheitsgrenzen, d.h. die Schwellenwerte, ab denen das System nicht mehr belastbar ist. Wir werden es vermeiden, zu tief in die umfangreiche Literatur22 über Schwellenwerte23 im Zusammenhang mit der Widerstandsfähigkeit von Systemen.24 Für die Zwecke der SCE ist es wichtig, sich daran zu erinnern, dass jedes System nur bis zu einem bestimmten Punkt in der Lage ist, Veränderungen der Bedingungen aufzufangen und in seinem aktuellen, gesunden Zustand zu bleiben (der Zustand, der unseren Annahmen über das Verhalten des Systems zugrunde liegt, was wir "mentale Modelle" nennen). Jenseits dieses Punktes gerät das System in einen anderen Existenzzustand, in dem seine Struktur und sein Verhalten von unseren Erwartungen und Absichten abweichen.25

Ein klassisches Beispiel für Sicherheitsgrenzen findet sich in dem Buch Jurassic Park.26 Als die Protagonisten ihre Tour durch den Park beginnen, befindet sich das System in einem stabilen Zustand. Die Dinosaurier befinden sich in den ihnen zugewiesenen Gebieten und das erste Erlebnis auf der Schiene bringt die Gäste erfolgreich zur Lodge zurück. Aber die Veränderungen der Bedingungen häufen sich: Der leitende Genetiker füllt Lücken in den DNA-Sequenzen der Velociraptoren mit Frosch-DNA auf, so dass sie ihr Geschlecht wechseln und sich fortpflanzen können; Landschaftsgärtner pflanzen westindischen Flieder im Park, dessen Beeren von Stegosauriern mit Magensteinen verwechselt werden und sie vergiften; ein Computerprogramm zur Schätzung der Dinosaurierpopulation sucht nach der erwarteten Anzahl (238) und nicht nach der tatsächlichen Anzahl (244), damit es schneller arbeitet; ein verärgerter Angestellter legt die Telefonleitungen und die Sicherheitsinfrastruktur des Parks lahm, um Embryos zu stehlen, was zu einem Stromausfall führt, der die elektrischen Zäune und Tourfahrzeuge lahmlegt; der verärgerte Angestellte stiehlt den Notfall-Jeep (mit einem Raketenwerfer auf dem Rücksitz) und macht es dem Wildhüter unmöglich, die nun im Park gestrandeten Protagonisten zu retten. Diese Veränderungen führen dazu, dass der Park als System seine Schwelle überschreitet und in einen neuen Zustand versetzt wird, der eher als tödliches Chaos denn als konstruktives Chaos bezeichnet werden kann, das SCE anstrebt. Sobald diese Schwelle überschritten ist, ist es für den Park fast unmöglich, in seinen vorherigen Zustand zurückzukehren.

Zum Glück ist es bei Computersystemen etwas einfacher, zum erwarteten Verhalten zurückzukehren, als die Dinosaurier in ihre Gehege zurückzudrängen. Aber nur ein bisschen. Hysterese, die Abhängigkeit des Zustands eines Systems von seiner Geschichte,27 ist ein typisches Merkmal komplexer Systeme und bedeutet, dass es selten möglich ist, vollständig zum vorherigen Zustand zurückzukehren. Aus Sicht der Resilienz ist es besser, das Überschreiten dieser Schwellenwerte von vornherein zu vermeiden, wenn es möglich ist. Dazu gehört auch die kontinuierliche Weiterentwicklung des Systems selbst, damit seine Sicherheitsgrenzen erweitert werden können, um sich verändernden Bedingungen anzupassen.

Wenn wir wollen, dass unsere Systeme widerstandsfähig gegen Angriffe sind, müssen wir die Sicherheitsgrenzen unseres Systems ermitteln, bevor sie überschritten werden - ein kontinuierlicher Prozess, denn die Sicherheitsgrenzen ändern sich, wenn sich das System selbst verändert. Sicherheitschaos-Experimente können uns dabei helfen, die Empfindlichkeit unseres Systems gegenüber bestimmten Bedingungen festzustellen und so seine Schwellenwerte zu ermitteln, sowohl jetzt als auch im Laufe der Zeit, wenn sie sich weiterentwickeln. Wenn wir diese Sicherheitsgrenzen kennen, haben wir eine bessere Chance, das System davor zu schützen, diese Schwellen zu überschreiten und zu versagen. Wenn sich ein System auf die Grenzen seines sicheren Betriebs zubewegt, ist eine Wiederherstellung immer noch möglich, aber langsamer. Die Kenntnis der Schwellenwerte kann uns helfen, das schwierige Ziel zu erreichen, die Systemleistung zu optimieren (es muss schnell gehen!) und gleichzeitig die Fähigkeit zur schnellen Wiederherstellung zu bewahren.

Tipp

Wenn du regelmäßig - oder besser noch kontinuierlich - Chaos-Experimente durchführst, sollten die Ergebnisse aufzeigen, ob deine Systeme (aus soziotechnischer Sicht) auf Schwellenwerte zu driften scheinen, die sie angesichts eines plötzlichen Aufpralls weniger widerstandsfähig machen. Dieses Abdriften könnte auf chronische Stressfaktoren hindeuten, die es wert sind, dass du dir die Zeit nimmst, sie zu untersuchen und aufzudecken, damit du die Systeme (und das Team) wieder auf ein gesünderes Betriebsniveau bringen kannst. (Wir werden in Kapitel 2 über Chaos-Experimente zur Bewertung der Widerstandsfähigkeit sprechen).

Schließlich solltest du dich daran erinnern, dass komplexe Systeme nichtlinear sind. Was wie eine geringfügige Veränderung aussieht, kann der sprichwörtliche letzte Strohhalm sein, der das System über seine Resilienzschwelle hinausschiebt. Ökologische Resilienzforscher haben es treffend formuliert: "Relativ kleine lineare Veränderungen von Stressoren können relativ abrupte und nichtlineare Veränderungen in Ökosystemen verursachen."28 Es ist nie nur ein Faktor, der zum Scheitern führt, sondern eine Kumulation, die die Grenzen des sicheren Betriebs des Systems überschreitet.

Interaktionen über Raum und Zeit hinweg

Da komplexe Systeme viele Komponenten umfassen, die miteinander interagieren, kann ihre Belastbarkeit nur durch die Systemdynamik in Raum und Zeit verstanden werden. Da die Variablen (nicht die Programmiervariablen) innerhalb deines Systems interagieren, werden sich im Laufe der Zeit und über die Topologie des Systems hinweg unterschiedliche Verhaltensweisen entfalten. Zu den zeitlichen Aspekten der Resilienz gehören der Zeitpunkt eines Vorfalls sowie die Dauer zwischen dem Auftreten des Vorfalls und der Wiederherstellung der Systemfunktionalität. Die räumliche Facette ist das Ausmaß der Auswirkungen des Vorfalls - der daraus resultierende Zustand des Systems mit seinen Komponenten, Funktionen und Fähigkeiten.

Wenn du zum Beispiel die Widerstandsfähigkeit einer verbraucherorientierten Anwendung gegen einen DDoS-Angriff (Distributed Denial of Service) überlegst, kann es sein, dass einer, einige oder alle Dienste betroffen sind. Der Angriff kann während der Hauptverkehrszeiten erfolgen, wenn deine Server bereits überlastet sind, oder während der Ruhezeit deiner Zielkunden, wenn deine Server gähnende Kapazitätsreserven haben. Die Wiederherstellung eines akzeptablen Leistungsstandards kann Millisekunden oder Stunden dauern. Ein längerer Ausfall eines Dienstes kann die Leistung der anderen Dienste, mit denen er verbunden ist, beeinträchtigen. Und ein Ausfall aller Dienste kann zu einer längeren Wiederherstellungszeit für das gesamte System führen. Wie dieses Beispiel zeigt, sind Zeit und Raum untrennbar miteinander verbunden, und du musst beides bei der Bewertung der Ausfallsicherheit berücksichtigen.

Es gibt einen Vorbehalt gegenüber dem Begriff "Zeit" (abgesehen von der Tatsache, dass die Menschheit immer noch nicht weiß, was das eigentlich ist).29 Die Zeit bis zur Wiederherstellung ist eine wichtige Kennzahl (die wir in Kapitel 5 besprechen werden), aber wie wir in unserer Diskussion über Sicherheitsgrenzen gelernt haben, ist es ebenso wichtig zu bedenken, dass es möglicherweise bessere alternative Betriebszustände gibt. Das heißt, es ist nicht immer wünschenswert, das aktuelle Gleichgewicht wiederherzustellen, wenn dieses Gleichgewicht von Betriebsbedingungen abhängt, die nicht der Realität entsprechen. Wie in unserem Beispiel mit den wild gewordenen Dinosauriern im Jurassic Park kann man manchmal einfach nicht zum ursprünglichen Gleichgewicht zurückkehren, weil sich die Realität zu sehr verändert hat.

Feedbackschleifen und Lernkultur

Resilienz hängt davon ab, dass wir uns an Misserfolge erinnern und aus ihnen lernen. Wir wollen mit dem Scheitern mit Leichtigkeit und Würde umgehen, anstatt es nur zu verhindern; dazu müssen wir das Scheitern als Lehrmeister annehmen. Rückkopplungsschleifen, in denen die Ergebnisse des Systems als Inputs für zukünftige Operationen verwendet werden, sind daher für die Widerstandsfähigkeit des Systems unerlässlich. Wenn wir einen Vorfall beobachten und uns an die Reaktion des Systems darauf erinnern, können wir dies nutzen, um Änderungen vorzunehmen, die das System in Zukunft widerstandsfähiger gegen solche Vorfälle machen. Dieser Prozess des Lernens und der Veränderung als Reaktion auf Ereignisse wird als Anpassung bezeichnet, die wir weiter oben in diesem Kapitel eingeführt haben und auf die wir in Kürze noch näher eingehen werden. Leider hören wir oft die Infosec-Volksweisheit, wie schnell sich Angreifer an die Verteidigung anpassen, aber es wird nicht so viel darüber diskutiert, wie wir mehr Anpassung in unserer Verteidigung unterstützen können (abgesehen von dem handfesten Gerede über KI). Das SCE will das ändern.

Die Bedeutung des operativen Gedächtnisses für die Resilienz zeigt sich auch in anderen Bereichen. Das ökologische Gedächtnis zum Beispiel ist die Fähigkeit der Vergangenheit, die gegenwärtigen oder zukünftigen Reaktionen eines Ökosystems zu beeinflussen,30 umfasst sowohl das informationelle als auch das materielle Gedächtnis. Das informatorische Gedächtnis umfasst Anpassungsreaktionen, während das materielle Gedächtnis neue Strukturen wie Samen oder Nährstoffe umfasst, die aus einer Störung resultieren.31

Dieses Gedächtnis aufrechtzuerhalten ist nicht trivial, aber die Vielfalt innerhalb eines Systems hilft dabei. Sozioökologische Systeme, die sich durch modulares Experimentieren anpassen, können sich nach einer Störung effektiver reorganisieren.32 Wenn das Netzwerk der Variablen eines Systems vielfältiger und die Verbindungen zwischen ihnen modularer sind, ist es unwahrscheinlicher, dass eine Störung alle Funktionen innerhalb eines Systems erreicht. Diese Fähigkeit, sich nach einer Störung neu zu orientieren, bedeutet, dass weniger Variablen und Verbindungen zwischen ihnen während einer Störung verloren gehen - so bleiben mehr Erinnerungen an das Ereignis erhalten, die als Input für Rückkopplungsschleifen genutzt werden können.

Ein Beispiel: Die Urbanisierung von Konstantinopel war zum Teil deshalb erfolgreich, weil die Gemeinschaft aus den wiederholten Belagerungen der Stadt (im Durchschnitt alle fünfzig Jahre) gelernt hat.33 Diese wiederholten Vorfälle, so schreiben Archäologen und Wissenschaftler für urbane Nachhaltigkeit, "erzeugten eine Vielfalt an sozioökologischen Erinnerungen - die Mittel, mit denen das Wissen, die Erfahrung und die Praxis, wie ein lokales Ökosystem zu verwalten ist, in einer Gemeinschaft gespeichert und weitergegeben wurden. Es waren nicht nur Historiker, die diese Erinnerungen bewahrten. Mehrere gesellschaftliche Gruppen bewahrten die Erinnerungen an die Belagerung auf, was zu Anpassungen wie der Dezentralisierung der Nahrungsmittelproduktion und des Transports in kleinere Gemeinschaften führte, die weniger wahrscheinlich von einer Belagerung gestört werden konnten - ähnlich wie eine modulare, serviceorientierte Architektur, die Störungen aufgrund einer Ressourcenspitze in einer Komponente isoliert. Um Platz für diese neue landwirtschaftliche Nutzung und für Gärten zu schaffen, wurden die Verteidigungsmauern versetzt. Diese Mauern dienten als visuelle Erinnerung an die aus der Belagerung gezogenen Lehren und schützten diese Erinnerungen davor, sich im Laufe der Zeit aufzulösen.

Wie wir im Laufe des Buches immer wieder betonen werden, sind unsere Computersysteme soziotechnischer Natur und daher ist die Pflege des Gedächtnisses durch die Gemeinschaft für die Widerstandsfähigkeit der Systeme in unserer Welt genauso wichtig wie für Konstantinopel. Wer auch immer das Sicherheitsprogramm in deinem Unternehmen umsetzt, er muss sicherstellen, dass die aus Vorfällen gewonnenen Erkenntnisse nicht nur gespeichert werden (und zwar so, dass sie für die Gemeinschaft zugänglich sind), sondern auch auf neue Weise genutzt werden, wenn sich die Bedingungen im Laufe der Zeit ändern. Wir kennen das Phänomen nur zu gut, dass ein Unternehmen von Angreifern angegriffen wird und plötzlich einen Berg von Geld und Energie in die Sicherheit investiert. Aber wenn die Erinnerung an den Vorfall verblasst, verblasst auch die erhöhte Investition in die Sicherheit. Die Realität ändert sich ständig, aber wenn ein schockierendes Ereignis eine Zeit lang ausbleibt, kann das die Notwendigkeit verringern, sich in Zukunft darauf vorzubereiten.

Eine Lernkultur entsteht nicht nur nach einem Vorfall. Auch Feedbackschleifen gibt es nicht nur einmal. Die Überwachung von Veränderungen in kritischen Funktionen und Systembedingungen ist eine Ergänzung zur Bewahrung von Erinnerungen an Vorfälle. Vorfälle - ob durch Angreifer oder Sicherheitschaos verursacht - können eine Art sensorischen Input liefern, der uns hilft, kausale Zusammenhänge in unseren Systemen zu verstehen (ähnlich wie das Berühren einer heißen Herdplatte und das Erinnern daran, dass dies zu einem "Aua" führt). Überwachung, Protokollierung und andere Formen der Sensorik helfen uns, anhand dieser kausalen Zusammenhänge zu verstehen, ob sich unsere Systeme den Grenzen eines sicheren Betriebs nähern. Das Verhalten in der Vergangenheit ist zwar kein Indikator für zukünftiges Verhalten, aber die Kombination aus dem Lernen aus Erinnerungen, dem Sammeln von Daten über das Systemverhalten und dem Durchführen von Experimenten, die Fehlerszenarien simulieren, gibt uns viel mehr Sicherheit, dass wir auf das Unvermeidliche vorbereitet sind, wenn es passiert.

Flexibilität und Offenheit für Veränderungen

Schließlich ist die Aufrechterhaltung der Flexibilität über Raum-Zeit ein wesentlicher Bestandteil der Resilienz. Im Resilienz-Engineering wird dies oft als "Anpassungsfähigkeit" bezeichnet.34 Die Anpassungsfähigkeit gibt an, wie bereit ein System für Veränderungen ist - seine Verhaltensweisen, Modelle, Pläne, Verfahren, Prozesse und Praktiken -, damit es in einer sich verändernden Welt mit Stressoren, Überraschungen und anderen Unwägbarkeiten weiter funktionieren kann.35 Wir müssen diese Flexibilität auch im Laufe der Zeit aufrechterhalten, was angesichts der sozialen Dynamik und der Kompromisse in der Organisation schwierig werden kann.36

Wie wir bereits bei den Lernkulturen und Feedbackschleifen erwähnt haben (und in Kapitel 4 näher erläutern werden), kann Modularität die Widerstandsfähigkeit unterstützen. Dazu gehört auch, dass das System flexibel genug ist, um auf veränderte Betriebsbedingungen zu reagieren. Das System muss in der Lage sein, sich räumlich und zeitlich über seine Sicherheitsgrenzen hinaus auszudehnen. (Ich hoffe, du erkennst jetzt, wie sich alle Zutaten in unserem Resilienz-Trank gegenseitig ergänzen!) Eine andere Art, darüber nachzudenken, ist, wie David D. Woods es treffend ausdrückt: "Wir müssen darauf vorbereitet sein, überrascht zu werden."

Wie immer ist auch hier das menschliche Element von Bedeutung. Wir als Beteiligte, die unsere Systeme sicher machen wollen, müssen auch offen für Veränderungen in uns selbst sein (nicht nur in unseren Maschinen). Vielleicht sind wir dem Status quo verhaftet oder wir wollen den Kurs nicht ändern, weil wir schon so viel Zeit und Geld investiert haben. Vielleicht war es unsere besondere Idee, die uns eine Beförderung eingebracht hat. Oder wir haben Angst, dass Veränderungen schwierig sein könnten. Aber dieser kognitive Widerstand untergräbt die Fähigkeit deines Systems, auf Zwischenfälle zu reagieren und sich anzupassen. Eine gute Entscheidung vor einem Jahr ist vielleicht heute keine gute Entscheidung mehr. Wir müssen wachsam sein, wenn unsere Annahmen nicht mehr zutreffen, weil sich die Welt um uns herum verändert hat.

Es gibt nie nur eine Sache, die dein System beeinträchtigt; viele Dinge werden das System immer wieder überraschen oder belasten und seine Sicherheitsgrenzen ständig verschieben. Flexibilität ist die wesentliche Eigenschaft, die es einem System ermöglicht, diese Ereignisse aufzufangen und sich an sie anzupassen, ohne dass es seinen eigentlichen Zweck verliert. Wir werden nie vollständiges Wissen über ein System erlangen, egal wie viele Daten wir sammeln. Selbst wenn wir das könnten, würde es uns helfen, den Zustand des Systems zu verstehen, aber es gäbe immer noch viele Unklarheiten darüber, wie sich eine bestimmte Veränderung auf das System auswirkt oder welche Art von Strategie oder Verfahren die Widerstandsfähigkeit des Systems gegenüber einer bestimmten Art von Angriffen verbessern würde. Es sind einfach zu viele Faktoren und Zusammenhänge im Spiel.

Da wir in dieser unbestimmten Realität leben, müssen wir offen für Entwicklungen sein und die Starrheit ablegen, die die Sicherheitsansätze des Status quo empfehlen. Aufbauend auf den Feedbackschleifen und der Lernkultur, die wir besprochen haben, müssen wir weiterhin etwas über unsere Systeme lernen und die Ergebnisse unserer Experimente oder Vorfälle verfolgen, um unser Verständnis davon zu verfeinern, wie ein wirklich widerstandsfähiges Sicherheitsprogramm für unsere Systeme aussieht. Diese kontinuierliche Anpassung hilft uns, uns besser auf künftige Störungen vorzubereiten, und gibt uns die Gewissheit, dass es in unserer Macht steht, unsere Reaktionsstrategien anzupassen und dafür zu sorgen, dass das System weiterhin erfolgreich seine kritische Funktion erfüllt, egal was auf uns zukommt.

Resilienz ist ein Verb

"Resilient" oder "sicher" ist eine emergente Eigenschaft von Systemen, keine statische.39 Als Teil der Resilienz ist Sicherheit etwas, das ein System tut, nicht etwas, das ein System hat. Als solche kann Sicherheit nur im Ereignisstrom der Realität aufgedeckt werden. Resilienz ist nicht nur die Fähigkeit, sich von Bedrohungen und Stressoren zu erholen, sondern auch die Fähigkeit, unter verschiedenen Bedingungen die erforderliche Leistung zu erbringen und auf Störungen und Chancen angemessen zu reagieren. Bei Resilienz geht es nicht nur darum, Stürme zu überstehen. Es geht auch um Innovation - darum, Gelegenheiten zu erkennen, wie du deine Praktiken weiterentwickeln kannst, um noch besser auf den nächsten Sturm vorbereitet zu sein. Resilienz sollte als ein proaktiver und ständiger Kreislauf betrachtet werden, der das gesamte System überwacht, Störungen vorhersieht, aus Erfolgen und Misserfolgen lernt und das System im Laufe der Zeit anpasst.40 Obwohl der Begriff "Resilienz" am besten geeignet wäre, um den handlungsorientierten Charakter von Resilienz zu beschreiben, werden wir im Laufe des Buches aus Gründen der Klarheit Wendungen wie "Resilienz erhalten" oder "Resilienz pflegen" verwenden.

In ähnlicher Weise ist Sicherheit ein Wert, den wir in unseren Unternehmen ständig aufrechterhalten sollten, anstatt ihn als Ware, Ziel oder erwarteten Endzustand zu betrachten. Wir müssen so denken, dass wir unseren Systemen helfen, widerstandsfähig und sicher in der unberechenbaren Wildnis der Produktion zu bestehen, anstatt sie "sicherer" zu machen. Diese Perspektive hilft uns zu verstehen, wie sich das Versagen in einem System entfaltet, und ermöglicht es uns, die Punkte zu identifizieren, an denen das Versagen hätte gestoppt oder umgelenkt werden können. So können wir herausfinden, welche Signale uns helfen können, Fehler früher zu erkennen und den Kreislauf fortzusetzen.

Die Betrachtung von Sicherheit als etwas, das ein System tut, anstatt es zu haben, versetzt dich auch in die Lage, die Bedingungen für ein Versagen, das in der Zukunft auftreten könnte, vorherzusehen. Die Forscher für menschliche Faktoren und Systemsicherheit, Richard Cook und Jens Rasmussen, stellen in ihrem Artikel "Going Solid" fest, dass ein System im Laufe der Zeit dazu neigt, sich schrittweise den Grenzen des sicheren Betriebs zu nähern.41-die Schwellenwerte, die wir bereits erwähnt haben. Produktivitätssteigerungen durch die Technologie äußern sich selten in kürzeren Arbeitszeiten oder einer neu gewonnenen Fähigkeit, die Sicherheit zu verbessern. Unternehmen werden immer den Wunsch haben, ihre Tätigkeiten mit weniger Aufwand und schneller auszuführen, und dieser Wunsch wird sich in ihren Systemen niederschlagen.

Sich ständig weiterentwickelnde und anpassende Systeme bieten denjenigen, die für Resilienz und Sicherheit verantwortlich sind, eine wachsende Arbeitsplatzsicherheit. Wenn das Sicherheitsprogramm der Organisation dabei helfen kann, neue Arten von Gefahren und Fehlermöglichkeiten zu erkennen, während die Organisation ihre Systeme weiterentwickelt, dann wird die Sicherheit von unschätzbarem Wert. Das ist oft das, was die Cybersicherheit im Großen und Ganzen zu tun glaubt, aber in Wirklichkeit neigt sie dazu, die Organisation in der Vergangenheit zu verankern, anstatt nach vorne zu schauen und einen sicheren Weg in die Zukunft zu bahnen. Welche anderen Fehleinschätzungen schleichen sich in die allgemeine Cybersicherheitsdiskussion ein? Als Nächstes werden wir andere Mythen zum Thema Resilienz untersuchen.

Resilienz: Mythos versus Realität

Aristoteles argumentierte, dass wir, um etwas zu verstehen, verstehen müssen, was es nicht ist.42 Dieser Abschnitt befasst sich mit den Mythen und der Realität der Resilienz, um dir zu helfen, dem Schlangenöl rund um den Begriff zu widerstehen.

Mythos: Robustheit = Widerstandsfähigkeit

Ein weit verbreiteter Mythos ist, dass Resilienz die Fähigkeit eines Systems ist, einem Schock, wie einem Angriff, zu widerstehen und zum "Normalzustand" zurückzukehren. Diese Fähigkeit wird in der Resilienz-Literatur als Robustheit bezeichnet. Im Cybersicherheitsdialog wird Resilienz häufig auf Robustheit reduziert, vor allem im übereifrigen Marketing (obwohl Cybersicherheit nicht der einzige Bereich ist, der diesem Fehler zum Opfer fällt). In Wirklichkeit ist ein resilientes System nicht robust, sondern es ist ein System, das potenzielle Situationen vorhersehen, laufende Situationen beobachten, auf Störungen reagieren und aus vergangenen Erfahrungen lernen kann .43

Ein Fokus auf Robustheit führt zu einer "defensiven" Haltung. Wie die riesige Eiche in der Fabel von Äsop versucht die Robustheit gegen den Sturm zu kämpfen, während sich das Schilfrohr - ähnlich wie adaptive Systeme - demütig im Wind biegt, in der Annahme, dass widrige Umstände sie beeinflussen werden. Das Ergebnis ist, dass der Status quo in der Cybersicherheit auf perfekte Prävention abzielt und der Realität trotzt, indem versucht wird, Vorfälle von vornherein zu verhindern. Dieser Fokus auf die Verhinderung des Unvermeidlichen lenkt uns davon ab, uns auf das Unvermeidliche vorzubereiten.

Robustheit verleitet uns auch dazu, der Wiederherstellung eines kompromittierten Systems in den vorherigen Zustand Vorrang einzuräumen, obwohl es für die Bedingungen, die die Kompromittierung begünstigt haben, anfällig ist.44 Dieser Irrglaube treibt uns dazu, technische oder strafende Kontrollen vorzunehmen, anstatt systemische oder konstruktive Abhilfemaßnahmen zu ergreifen, was wiederum ein falsches Sicherheitsgefühl in einem System erzeugt, das von Natur aus anfällig ist.45 Ein Beispiel aus der Welt der Naturkatastrophen: Wenn in einem Wohngebiet eine physische Barriere gegen Überschwemmungen errichtet wird, steigt die Wahrscheinlichkeit, dass dort mehr Häuser gebaut werden - und damit auch die Wahrscheinlichkeit, dass es zu einer Katastrophe kommt, wenn die Barriere fehlschlägt.46 Um eine Parallele zur Cybersicherheit zu ziehen, denke an unsichere interne Anwendungen, die in dem Glauben gelassen werden, dass eine Firewall oder ein Intrusion Detection System (IDS) Angreifer daran hindern wird, auf sie zuzugreifen und sie auszunutzen.

Der Resilienzansatz erkennt, dass Veränderung die Sprache des Universums ist. Ohne aus Erfahrungen zu lernen, können wir uns nicht an die Realität anpassen. Resilienz erkennt auch an, dass Gedeihen Überleben bedeutet. Robustheit, also die Fähigkeit, einem widrigen Ereignis wie einem Angriff zu widerstehen, reicht nicht aus.

Mythos: Wir können und sollten Misserfolge verhindern

Die traditionelle Cybersicherheitsbranche konzentriert sich auf die Verhinderung von Fehlern. Das Ziel ist es, Bedrohungen zu "vereiteln", Exploits zu "stoppen", Angriffe zu "blockieren" und andere aggressive Formulierungen zu verwenden, um zu beschreiben, wie Angreifer daran gehindert werden, im technologischen Ökosystem deines Unternehmens aktiv zu werden. Während aufschlussreiche Berichte über leistungsbezogene Vorfälle (manchmal auch "Postmortems" genannt) oft veröffentlicht werden, werden Sicherheitsvorfälle als beschämende Angelegenheiten behandelt , die nur hinter verschlossenen Türen oder in kostenpflichtigen Informationsaustauschgruppen diskutiert werden sollten. Misserfolge werden moralisch als "Sieg der Bösewichte" dargestellt - kein Wunder, dass der Diskurs in der Sicherheitsbranche oft so düster und pessimistisch ist. Das Ziel ist es, irgendwie alle Probleme immer zu verhindern, was ironischerweise das Sicherheitsprogramm zum Scheitern verurteilt (ganz zu schweigen davon, dass es eine Lernkultur erstickt).

Mit dieser Besessenheit von Prävention verbunden ist die neuere Leidenschaft für Vorhersagen. Die FAIR-Methode, ein quantitatives Risikoanalysemodell, das für die Cybersicherheit entwickelt wurde, ist in traditionellen Sicherheitsprogrammen weit verbreitet und erfordert Annahmen über die Wahrscheinlichkeit der "Häufigkeit von Schadensereignissen" und das "Ausmaß von Schäden". Wenn du vorhersagen kannst, welche Arten von Angriffen auf dich zukommen, wie oft sie auftreten und welche Auswirkungen sie haben werden, kannst du den richtigen Betrag für Sicherheitsmaßnahmen bestimmen und wie er ausgegeben werden sollte.

Aber genaue Vorhersagen sind in komplexen Systemen unmöglich; wenn du denkst, dass Sicherheitsprognosen schwierig sind, dann sprich mit einem Meteorologen. Unsere Vorliebe für Vorhersagen mag dem Homo sapiens geholfen haben, zu überleben, indem wir lineare Probleme gelöst haben, z. B. wie die Beute sich im Wald zurechtfindet, aber in einer modernen Welt voller Interaktivität schadet sie wohl mehr, als sie hilft. Da Resilienz etwas ist, was ein System tut und nicht hat, lässt sie sich nicht mit Wahrscheinlichkeiten von Störungsereignissen quantifizieren. Wie die Seismologin Susan Elizabeth Hough im Zusammenhang mit Naturkatastrophen sagte: "Einem Gebäude ist es egal, ob ein Erdbeben oder eine Erschütterung vorhergesagt wurde oder nicht.47

Der Versuch, Ausfälle in unseren komplexen Computersystemen zu verhindern oder vorherzusagen, ist eine kostspielige Angelegenheit, weil sie uns ablenkt und Ressourcen von der eigentlichen Vorbereitung auf Ausfälle abzieht. Es ist produktiver und pragmatischer, Misserfolge als Lernchance zu betrachten und sich auf sie vorzubereiten. Anstatt so viel Zeit damit zu verbringen, vorherzusagen, wie viele Ressourcen wo ausgegeben werden müssen, kannst du Experimente durchführen und aus den Erfahrungen lernen, um dein Sicherheitsprogramm auf der Grundlage konkreter Beweise ständig zu verbessern. (Außerdem musst du bei diesem Ansatz viel weniger Zeit mit Excel verbringen, was für die meisten ein Vorteil ist).

Die "bösen Jungs"48 werden manchmal gewinnen. Das ist einfach ein unbefriedigender Teil des Lebens, egal wo du die Menschheit siehst. Was wir aber kontrollieren können, ist, wie sehr wir darunter leiden. Das frühzeitige Erkennen von Fehlern in den Sicherheitskontrollen kann den Unterschied zwischen einer nicht ausgenutzten Schwachstelle und der Ankündigung einer Datenpanne für deine Kunden bedeuten. Resilienz und Chaos-Engineering berücksichtigen die Tatsache, dass Modelle unvollständig sind, Kontrollen versagen und Abhilfemaßnahmen deaktiviert werden - mit anderen Worten: Dinge werden fehlschlagen und weiter versagen, während sich die Welt dreht und weiterentwickelt. Wenn wir unsere Systeme so gestalten, dass wir mit Fehlern rechnen, unsere Annahmen durch Experimente proaktiv in Frage stellen und die gewonnenen Erkenntnisse als Feedback in unsere Strategie einfließen lassen, können wir besser verstehen, wie unsere Systeme tatsächlich funktionieren und wie wir sie am besten verbessern und sichern können.

Anstatt zu versuchen, das Auftreten von Fehlern zu verhindern, besteht das Ziel von Resilience- und Chaos-Engineering darin, mit Fehlern anständig umzugehen.49 Die frühzeitige Erkennung von Ausfällen minimiert die Auswirkungen von Vorfällen und reduziert die Kosten für deren Behebung. Ingenieure haben gelernt, dass die frühzeitige Erkennung von Serviceausfällen - wie z. B. die lange Latenzzeit bei einer Zahlungs-API - die Kosten für die Behebung senkt, und bei Sicherheitsausfällen ist das nicht anders.

So kommen wir zu zwei zentralen Leitprinzipien der SCE:

  1. Rechne damit, dass Sicherheitskontrollen fehlschlagen können und bereite dich entsprechend vor.

  2. Versuche nicht, Zwischenfälle komplett zu vermeiden, sondern nimm die Fähigkeit an, schnell und effektiv auf sie zu reagieren.

Nach dem ersten Prinzip müssen Systeme unter der Annahme entworfen werden, dass Sicherheitskontrollen fehlschlagen und dass die Nutzer die Auswirkungen ihrer Handlungen auf die Sicherheit nicht sofort verstehen (oder sich darum kümmern).50 Nach dem zweiten Prinzip, das der Ökonom Peter Timmerman beschrieben hat, kann man sich Resilienz als den Aufbau von "Pufferkapazitäten" in einem System vorstellen, um seine Fähigkeit, in der Zukunft zurechtzukommen, kontinuierlich zu stärken.51

Es ist wichtig, zu akzeptieren, dass Kompromisse und Fehler passieren werden, und sich darauf zu konzentrieren, dass unsere Systeme mit widrigen Ereignissen umgehen können. Die Sicherheit muss von einer defensiven Haltung zu einer belastbaren Haltung übergehen und sich von dem unmöglichen Standard der perfekten Prävention verabschieden.

Mythos: Die Sicherheit der einzelnen Komponenten ergibt die Widerstandsfähigkeit

Da Resilienz eine aufkommende Eigenschaft auf Systemebene ist, kann sie nicht durch die Analyse von Komponenten gemessen werden. Das ist sehr bedauerlich, da die traditionelle Cybersicherheit weitgehend auf der Komponentenebene angesiedelt ist, sei es bei der Bewertung der Sicherheit von Komponenten oder beim Schutz von Komponenten. Die Auflistung von Schwachstellen in einzelnen Komponenten wird als Beweis dafür angesehen, wie sicher die Organisation gegen Angriffe ist. Aus der Perspektive des Resilience Engineering ist diese Vorstellung unsinnig. Wenn wir ein Frontend, das Eingaben empfängt, mit einer Datenbank verbinden und prüfen, ob jede Komponente für sich genommen "sicher" ist, entgeht uns möglicherweise das Potenzial für SQL-Injection, das sich aus ihrem Zusammenspiel ergibt.

Die Abschwächung und der Schutz auf Komponentenebene sind teilweise auf diesen Mythos zurückzuführen. Eine andere Überzeugung, die von Praktikern nur ungern zugegeben wird, ist, dass es bequemer ist, Sicherheitsprobleme einzeln, Komponente für Komponente, anzugehen, als sich mit dem Gesamtbild der Systemsicherheit zu befassen. Es ist eine natürliche menschliche Tendenz, sich auf die Arbeit zu konzentrieren, die sich einfacher anfühlt, und sie mit einem tieferen Grund (wie diesem Mythos) zu rechtfertigen. So sehen wir auch im Gesundheitswesen den gleichen Fokus auf die Neugestaltung von Prozessen und die Sicherheitstechnik auf Komponentenebene.52 Der Mangel an Wissen und Verständnis darüber, wie komplexe Systeme funktionieren, zieht sich durch alle Branchen.

Die gute Nachricht ist, dass wir keine genauen Messungen brauchen, um die Widerstandsfähigkeit zu beurteilen (wie wir in Kapitel 2 näher erläutern werden). Die Bewertung der Brüchigkeit und der Widerstandsfähigkeit erfolgt durch die Beobachtung des Systems sowohl in ungünstigen als auch in gesunden Szenarien. Das ist das Schöne an der SCE: Durch gezielte Experimente kannst du Hypothesen über die Widerstandsfähigkeit deines Systems gegenüber verschiedenen Arten von ungünstigen Bedingungen testen und beobachten, wie deine Systeme darauf reagieren. Wie bei einem Mosaik fügt sich jedes Experiment zu einem umfassenderen Bild deines Systems zusammen und hilft dir, es besser zu verstehen. Wie wir in Kapitel 7 sehen werden, können wir Sicherheit sogar als Produkt betrachten und die wissenschaftliche Strenge und das Experimentieren anwenden, die uns helfen, bessere Produktergebnisse zu erzielen.

Bereiche außerhalb der Software haben diesen Luxus nicht. Wir wollen weder das Great Barrier Reef mit Wirbelstürmen überziehen, um seine Widerstandsfähigkeit zu testen, noch würden wir eine Volkswirtschaft, einen menschlichen Körper auf dem Operationstisch, ein städtisches Wassersystem, ein Flugzeug während des Flugs oder irgendein anderes reales, lebendiges System, von dem Menschen abhängen, mit ungünstigen Bedingungen überziehen wollen. Da (soweit wir wissen) Computer nicht empfindungsfähig sind und solange wir die Zustimmung der menschlichen Akteure in unseren Computersystemen haben, hat dieser Bereich einen großen Vorteil gegenüber anderen Bereichen, wenn es darum geht, die Widerstandsfähigkeit von Systemen zu verstehen, denn wir können Experimente mit Sicherheitschaos durchführen .

Mythos: Die Schaffung einer "Sicherheitskultur" behebt menschliche Fehler

Die Cybersicherheitsbranche denkt und spricht viel über "Sicherheitskultur", aber dieser Begriff bedeutet je nachdem, wen du fragst, etwas anderes. Infosec ist mit diesem Schwerpunkt nicht allein ; auch andere Bereiche, vor allem das Gesundheitswesen,53 haben der Förderung einer "Sicherheitskultur" viel Aufmerksamkeit gewidmet. Aber die Grundlage dieses Fokus auf "Kultur" - unabhängig von der Branche - ist das streitbare Beharren darauf, dass die Menschen, die mit den Systemen verbunden sind , sich mehr auf die Sicherheit (oder "Safety" in anderen Bereichen) konzentrieren müssen. Besonders im Bereich der Cybersicherheit ist dies ein Versuch, die Last der Sicherheit auf den Rest des Unternehmens zu verteilen - einschließlich der Verantwortung für Zwischenfälle. Daher sind wir davon besessen, zu verhindern, dass Nutzer/innen auf Dinge klicken, obwohl sie bei ihrer Arbeit viele Dinge mehrmals am Tag anklicken müssen. Man könnte die "Sicherheitskultur" im Bereich der Informationssicherheit als das Bestreben bezeichnen, Menschen daran zu hindern, auf Dinge zu klicken - diemoderne Monomanie, den unbezwingbaren weißen Wal des Internet-Zeitalters zu bändigen.

Diskussionen über Kultur bringen wenig, wenn sie nicht in der Realität der dynamischen, komplexen Systeme verankert sind, in denen Menschen arbeiten. Es ist leicht zu behaupten, dass alles besser würde, wenn die Menschen bei ihrer Arbeit einfach mehr auf Sicherheitsbelange achten würden, aber solche Empfehlungen werden wohl kaum Bestand haben. Fruchtbarer ist es, zu verstehen , warum Sicherheitsbelange übersehen werden - sei es wegen konkurrierender Prioritäten, Produktionsdruck, Aufmerksamkeitsschwierigkeiten, verwirrenden Warnmeldungen und vielem mehr. Und welche Arbeit meinen wir dann? Für einen Beschaffungsexperten, der häufig mit externen Parteien interagiert, bedeutet Sicherheit etwas ganz anderes als für einen Entwickler, der APIs für Produktionsumgebungen entwickelt.

Jede fruchtbare Diskussion in dieser Richtung wird oft durch schlecht gewählte Gesundheitsmetriken und andere "Sicherheits-Eitelkeits"-Metriken im Keim erstickt. Sie liefern einfach kein vollständiges Bild der organisatorischen Sicherheit, sondern verleiten Praktiker dazu, zu glauben, dass sie etwas verstehen, weil sich Quantifizierung wie echte Wissenschaft anfühlt - genau wie Schamanismus, Humoralismus und Astrologie in früheren Epochen. Der Prozentsatz der Nutzer, die in deinem Unternehmen auf Phishing-Links klicken, sagt nichts darüber aus, ob es in deinem Unternehmen zu einem schrecklichen Vorfall kommt, wenn ein Nutzer auf etwas klickt, das er nicht sollte. Wenn die Anzahl der gefundenen Schwachstellen steigt, ist das gut oder schlecht? Vielleicht ist die Anzahl der gefundenen Schwachstellen in Anwendungen weniger wichtig als die Frage, ob diese Schwachstellen früher im Lebenszyklus der Software gefunden werden, ob sie schneller behoben werden oder, noch besser, ob die Produktionsumgebung so gestaltet ist, dass ihre Ausnutzung keine wesentlichen Auswirkungen hat. Es erübrigt sich zu sagen, dass eine Kennzahl wie die prozentuale "Risikoabdeckung" (das Ziel ist eine 100%ige Abdeckung dieses phantastischen Ektoplasmas) kaum mehr als Füllmaterial ist, mit dem Führungskräfte und Vorstände ohne technisches Fachwissen gefüttert werden.

Das andere beunruhigende Nebenprodukt der traditionellen Versuche eine "Sicherheitskultur" zu fördern, ist der Fokus auf die Bestrafung von Menschen oder die Behandlung von Menschen als Feinde, die als "Insider-Bedrohungen" bezeichnet werden. Sicherheitsprogramme des Status quo kaufen vielleicht Tools mit maschinellen Lernsystemen und natürlichen Sprachverarbeitungsfunktionen, um herauszufinden, welche Mitarbeiter traurig oder wütend klingen, um "Insider-Bedrohungen" frühzeitig zu erkennen.54 Oder die Sicherheitsteams installieren Spionageprogramme55 auf den Geräten der Mitarbeiter/innen installieren, um festzustellen, ob sie sich nach einem anderen Job umsehen oder andere willkürliche Anzeichen dafür zeigen, dass sie mit dem Unternehmen unzufrieden sind. Im Sicherheitsstatus quo behandeln wir Menschen lieber wie Schrödingers Angreifer, als die organisatorischen Faktoren zu analysieren, die überhaupt erst zu dieser Form der Anfälligkeit führen können. Das mag die Verantwortlichen beschwichtigen, aber es ist unser Versagen bei der Förderung der organisatorischen Sicherheit.

Cybersecurity ist nicht der einzige Problembereich, der diese Tendenz aufweist. Der Soziologe Charles Perrow aus Yale hat bei komplexen Systemen beobachtet, dass:

Bei fast allen Systemen, die wir untersuchen werden, steht "Bedienerfehler" ganz oben auf der Liste der ursächlichen Faktoren - in der Regel werden etwa 60 bis 80 Prozent der Unfälle auf diesen Faktor zurückgeführt. Aber wenn der Bediener, wie wir immer wieder sehen werden, mit unerwarteten und meist mysteriösen Wechselwirkungen zwischen Fehlern konfrontiert wird, kann er oder sie erst im Nachhinein sagen, dass er oder sie hätte "zick" statt "zack" machen sollen.56

Bemerkenswerterweise schreibt die Cybersicherheitsbranche etwa den gleichen Anteil der Ausfälle auch "menschlichem Versagen" zu. Wie hoch der Anteil des "menschlichen Versagens" bei Datenschutzverletzungen genau ist, hängt davon ab, welche Quelle du betrachtest: Im Verizon Data Breach Investigations Report von 2022 heißt es, dass 82 % der Datenschutzverletzungen "ein menschliches Element" beinhalten, während eine andere Studie von 2021 menschliches Versagen als Ursache für 88 % der Datenschutzverletzungen angibt. Von den Verstößen, die dem Information Commissioner's Office (ICO) zwischen 2017 und 2018 gemeldet wurden, nannten 90 % ebenfalls menschliches Versagen als Ursache. Wenn man jedoch genauer untersucht, was diese menschlichen Fehler waren, handelt es sich oft um Handlungen, die in anderen Zusammenhängen völlig harmlos sind, wie z. B. das Klicken auf Links, das Pushen von Code, das Aktualisieren von Konfigurationen, das Teilen von Daten oder das Eingeben von Anmeldedaten in Anmeldeseiten.

SCE unterstreicht die Bedeutung von Außenperspektiven. Wir sollten die Perspektive unserer Gegner berücksichtigen (wie wir in Kapitel 2 besprechen) und Nutzerforschung betreiben (wie wir in Kapitel 7 besprechen), um ein Verständnis für die Perspektiven derjenigen zu entwickeln, die Systeme bauen, warten und nutzen, damit das Sicherheitsprogramm nicht auf einer Fantasie beruht. Die Übernahme einer Systemperspektive ist der erste Schritt, um mit dem Scheitern von Sicherheitsprogrammen besser umgehen zu können, denn sie ermöglicht es dir zu erkennen, wie eine Kombination aus chronischen und akuten Stressfaktoren zum Scheitern führt.

Mit SCE kann das Sicherheitsprogramm einen immensen Wert für die Organisation schaffen, indem es die Lücke zwischen der Arbeit, wie sie gedacht ist, und der Arbeit, wie sie ausgeführt wird, verkleinert.57 Systeme stoßen an ihre Sicherheitsgrenzen, wenn Richtlinien und Verfahren auf der Grundlage idealer betrieblicher Verhaltensweisen (sowohl von Menschen als auch von Maschinen) entwickelt werden. Von Menschen zu erwarten, dass sie mehrere Schritte nacheinander ausführen, ohne dass sie daran erinnert werden oder visuelle Hilfen erhalten, ist ein Rezept für Fehler und Versäumnisse.

Sicherheitsprogramme in SCE sind auch neugierig auf Workarounds, anstatt sie zu verbieten. Umgehungslösungen können die Widerstandsfähigkeit unterstützen. Menschen sind sehr geschickt darin, auf konkurrierende Anforderungen und Ziele zu reagieren und Umgehungslösungen zu schaffen, die es dem System ermöglichen, seine kritischen Funktionen aufrechtzuerhalten. Wenn die Umgehungslösungen eliminiert werden, ist es für die Menschen, die mit dem System interagieren, schwieriger, eine Vielzahl von Strategien zu nutzen, um auf die verschiedenen Verhaltensweisen zu reagieren, denen sie bei ihrer Arbeit begegnen. Und das untergräbt die Widerstandsfähigkeit. Im Gegensatz zum traditionellen Wissen über Sicherheitssysteme sieht SCE Workarounds als das, was sie sind: Anpassungen als Reaktion auf sich verändernde Bedingungen, die in komplexen Systemen natürlich sind.58 Es lohnt sich, Workarounds zu verstehen, um die richtigen Verfahren zu entwickeln, mit denen Menschen flexibel und sicher arbeiten können.

Kapitel Takeaways

  • Alle unsere Softwaresysteme sind komplex. Komplexe Systeme sind vielfältig, anpassungsfähig und von Natur aus ganzheitlich.

  • Ein Versagen liegt vor, wenn Systeme - oder Komponenten in Systemen - nicht wie vorgesehen funktionieren. In komplexen Systemen ist das Scheitern unvermeidlich und passiert die ganze Zeit. Es kommt darauf an, wie wir uns darauf vorbereiten.

  • Scheitern ist nie das Ergebnis eines einzelnen Faktors; es gibt mehrere Einflussfaktoren, die zusammenwirken. Akute und chronische Stressoren sind ebenso Faktoren wie Computer und menschliche Überraschungen.

  • Resilienz ist die Fähigkeit eines Systems, seine Funktionsweise als Reaktion auf sich verändernde Bedingungen anzupassen, damit es weiter gedeihen kann.

  • Resilienz ist die Grundlage des Security Chaos Engineering. Security Chaos Engineering (SCE) ist eine Reihe von Prinzipien und Praktiken, die dir helfen, komplexe Systeme zu entwerfen, zu bauen und zu betreiben, die widerstandsfähiger gegen Angriffe sind.

  • Zu den fünf Zutaten des "Resilienz-Tranks" gehören das Verständnis der kritischen Funktionen eines Systems, das Verständnis seiner Sicherheitsgrenzen, die Beobachtung der Wechselwirkungen zwischen seinen Komponenten in Raum und Zeit, die Förderung von Feedbackschleifen und einer Lernkultur sowie die Aufrechterhaltung von Flexibilität und Offenheit für Veränderungen.

  • Resilienz ist ein Verb. Sicherheit, als Teilbereich von Resilienz, ist etwas, das ein System tut, nicht etwas, das ein System hat.

  • SCE hat erkannt, dass ein widerstandsfähiges System ein System ist, das unter einer Vielzahl von Bedingungen die erforderliche Leistung erbringt und sowohl auf Störungen - wie Bedrohungen - als auch auf Chancen angemessen reagieren kann. Sicherheitsprogramme sollen dem Unternehmen dabei helfen, neue Arten von Gefahren zu erkennen, aber auch Chancen für Innovationen zu nutzen, um auf den nächsten Vorfall noch besser vorbereitet zu sein.

  • Es gibt viele Mythen über Resilienz, von denen wir vier behandelt haben: Resilienz wird mit Robustheit verwechselt, also der Fähigkeit, nach einem Angriff wieder zum Normalzustand zurückzukehren; der Glaube, dass wir Ausfälle verhindern können und sollten (was unmöglich ist); der Mythos, dass die Sicherheit jeder einzelnen Komponente die Sicherheit des gesamten Systems ausmacht; und dass die Schaffung einer "Sicherheitskultur" das Problem des "menschlichen Versagens" löst.

  • Die SCE macht sich die Idee zu eigen, dass Scheitern unvermeidlich ist und nutzt es als Lernmöglichkeit. Anstatt Misserfolge zu verhindern, müssen wir uns darauf konzentrieren, mit Misserfolgen anständig umzugehen - was auch besser mit den Unternehmenszielen übereinstimmt.

1 George V. Neville-Neil, "Securing the Company Jewels", Communications of the ACM 65, no. 10 (2022): 25-26.

2 Richard J. Holden, "Menschen oder Systeme? Schuld ist der Mensch. The Fix Is to Engineer", Professionelle Sicherheit 54, Nr. 12 (2009): 34.

3 David D. Woods, "Engineering Organizational Resilience to Enhance Safety: A Progress Report on the Emerging Field of Resilience Engineering", Proceedings of the Human Factors and Ergonomics Society Annual Meeting 50, Nr. 19 (Oktober 2006): 2237-2241.

4 Dirk G. Baur, "Financial Contagion and the Real Economy", Journal of Banking & Finance 36, Nr. 10 (2012): 2680-2692; Kristin Forbes, "The 'Big C': Identifying Contagion", National Bureau of Economic Research, Working Paper 18465 (2012).

5 Iacopo Iacopini et al., "Simplicial Models of Social Contagion," Nature Communications 10, no. 1 (2019): 2485; Sinan Aral und Christos Nicolaides, "Exercise Contagion in a Global Social Network," Nature Communications 8, no. 1 (2017): 14753.

6 Steven Sanche et al., "High Contagiousness and Rapid Spread of Severe Acute Respiratory Syndrome Coronavirus 2", Emerging Infectious Diseases 26, no. 7 (2020): 1470.

7 Ein moderner Diogenes könnte Mr. Potato Head hochhalten und erklären: "Seht her! Ein lineares System!"

8 Amy Rankin et al., "Resilience in Everyday Operations: A Framework for Analyzing Adaptations in High-Risk Work," Journal of Cognitive Engineering and Decision Making 8, no. 1 (2014): 78-97.

9 Rankin, "Resilience in Everyday Operations", 78-97.

10 Joonhong Ahn et al. (Hrsg.), Reflections on the Fukushima Daiichi Nuclear Accident: Toward Social-Scientific Literacy and Engineering Resilience (Berlin: Springer Nature, 2015).

11 Nick Chater und George Loewenstein, "The Under-Appreciated Drive for Sense-Making", Journal of Economic Behavior & Organization 126 (2016): 137-154.

12 Institute of Medicine, Hospital-Based Emergency Care: At the Breaking Point (Washington, DC: The National Academies Press, 2007).

13 Christopher Nemeth et al., "Minding the Gaps: Creating Resilience in Health Care", in Advances in Patient Safety: New Directions and Alternative Approaches, Vol. 3: Performance and Tools (Rockville, MD: Agency for Healthcare Research and Quality, August 2008).

14 Len Fisher, "To Build Resilience, Study Complex Systems", Nature 595, no. 7867 (2021): 352-352.

15 Nancy G. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety (Cambridge, MA: MIT Press, 2016).

16 Zu den relevanten Bereichen gehören Katastrophenmanagement (z. B. Hochwasserschutz), Klimawandel (z. B. Landwirtschaft, Korallenriffmanagement) und sicherheitskritische Branchen wie Luftfahrt und Medizin.

17 Lynn Margulis und Dorion Sagan, Was ist Leben? (Berkeley und Los Angeles, CA: University of California Press, 2000).

18 Ein Beispiel: Facebook veröffentlichte eine Studie zu Speicherfehlern im großen Maßstab und stellte fest, dass bei 9,62 % der Server korrigierbare Speicherfehler auftraten (kumuliert über alle Monate), was den Trend bestätigt, dass Speicherfehler immer noch ein weit verbreitetes Problem sind.

19 Jane Jacobs, The Death and Life of Great American Cities (New York: Vintage Books, 1992).

20 Susan L. Cutter et al., "Disaster Resilience: A National Imperative," Environment: Wissenschaft und Politik für nachhaltige Entwicklung 55, Nr. 2 (2013): 25-29.

21 Elizabeth B. Connelly et al., "Features of Resilience," Environment Systems and Decisions 37, no. 1 (2017): 46-50.

22 Jens Rasmussen, "Risk Management in a Dynamic Society: A Modelling Problem", Safety Science 27, Nr. 2-3 (1997): 183-213.

23 K. J. Willis et al., "Biodiversity Baselines, Thresholds and Resilience: Testing Predictions and Assumptions Using Palaeoecological Data," Trends in Ecology & Evolution 25, no. 10 (2010): 583-591.

24 Didier L. Baho et al., "A Quantitative Framework for Assessing Ecological Resilience", Ecology & Society 22, no. 3 (2017): 17.

25 Dieser Teil des Anpassungszyklus wird als "Zusammenbruch" oder "Verwirrung" bezeichnet. Brian D. Fath et al., "Navigating the Adaptive Cycle: An Approach to Managing the Resilience of Social Systems," Ecology & Society 20, no. 2 (2015): 24.

26 Das Buch taucht überraschend tief in die Theorie nichtlinearer Systeme ein, während der Film nur an der Oberfläche kratzt.

27 Arie Staal et al., "Hysteresis of Tropical Forests in the 21st Century", Nature Communications 11, no. 4978 (2020).

28 Craig R. Allen et al., "Quantifying Spatial Resilience", Journal of Applied Ecology 53, no. 3 (2016): 625-635.

29 Carlo Rovelli, "Das Verschwinden von Raum und Zeit", in Philosophy and Foundations of Physics: The Ontology of Spacetime, 25-36 (Amsterdam und Oxford, UK: Elsevier, 2006).

30 Terry P. Hughes et al., "Ecological Memory Modifies the Cumulative Impact of Recurrent Climate Extremes", Nature Climate Change 9, Nr. 1 (2019): 40-43.

31 Jill F. Johnstone et al., "Changing Disturbance Regimes, Ecological Memory, and Forest Resilience", Frontiers in Ecology and the Environment 14, no. 7 (2016): 369-378.

32 Fath, "Navigating the Adaptive Cycle".

33 John Ljungkvist et al., "The Urban Anthropocene: Lessons for Sustainability from the Environmental History of Constantinople", in The Urban Mind: Cultural and Environmental Dynamics, 367-390 (Uppsala, Schweden: Uppsala University Press, 2010).

34 Nick Brooks et al., "Assessing and Enhancing Adaptive Capacity", in Adaptation Policy Frameworks for Climate Change: Developing Strategies, Policies and Measures, 165-181 (New York und Cambridge, UK: UNDP und Cambridge University Press, 2005).

35 Carl Folke et al., "Resilienz und nachhaltige Entwicklung: Building Adaptive Capacity in a World of Transformations", AMBIO: A Journal of the Human Environment 31, no. 5 (2002): 437-440.

36 Shana M. Sundstrom und Craig R. Allen, "The Adaptive Cycle: Mehr als nur eine Metapher". Ecological Complexity 39 (August): 100767.

37 Woods, "Engineering Organizational Resilience to Enhance Safety", 2237-2241.

38 Nemeth, "Minding the Gaps".

39 J. Park et al., "Integrating Risk and Resilience Approaches to Catastrophe Management in Engineering Systems", Risk Analysis 33, no. 3 (2013): 356-366.

40 Connelly, "Merkmale der Resilienz", 46-50.

41 Richard Cook und Jens Rasmussen, "Going Solid: A Model of System Dynamics and Consequences for Patient Safety", BMJ Quality & Safety 14, no. 2 (2005): 130-134.

42 Alan Lightman, Wahrscheinliche Unmöglichkeiten: Musings on Beginnings and Endings (New York: Pantheon Books, 2021).

43 Rankin, "Resilience in Everyday Operations", 78-97.

44 Adriana X. Sanchez et al., "Are Some Forms of Resilience More Sustainable Than Others?" Procedia Engineering 180 (2017): 881-889.

45 Dies ist als "Paradoxon der sicheren Entwicklung" bekannt: Die erwartete Sicherheit, die durch die Einführung einer technischen Lösung für ein Problem gewonnen wird, erleichtert stattdessen die Anhäufung von Risiken im Laufe der Zeit, was im Falle eines Vorfalls zu größeren potenziellen Schäden führt. Siehe Raymond J. Burby, "Hurricane Katrina and the Paradoxes of Government Disaster Policy: Bringing About Wise Governmental Decisions for Hazardous Areas," The ANNALS of the American Academy of Political and Social Science 604, no. 1 (2006): 171-191.

46 Caroline Wenger, "The Oak or the Reed: How Resilience Theories Are Translated into Disaster Management Policies", Ecology and Society 22, no. 3 (2017): 18.

47 Susan Elizabeth Hough, Predicting the Unpredictable, Reprint Ed. (Princeton, NJ: Princeton University Press, 2016).

48 Wir werden den Begriff "böse Jungs" oder "böse Akteure" in diesem Buch aus verschiedenen Gründen nicht verwenden, unter anderem wegen der infantilen Weltanschauung, die damit zum Ausdruck gebracht wird. Dennoch wirst du ihn im typischen Infosec-Diskurs wahrscheinlich als Schimpfwort gegen Angreifer im Allgemeinen verwenden.

49 Siehe Bill Hoffmans Grundsätze für betriebsfreundliche Dienste, über James R. Hamilton, "On Designing and Deploying Internet-Scale Services", LISA 18 (November 2007): 1-18.

50 "Endnutzer" und "Systemadministratoren" werden in den jährlichen Ausgaben des Verizon Data Breach Investigations Report (DBIR) (2020 Report) immer wieder als "Top-Akteure" bei Datenschutzverletzungen genannt.

51 Peter Timmerman, "Vulnerability, Resilience and the Collapse of Society", Environmental Monograph No. 1 (1981): 1-42.

52 Nemeth, "Minding the Gaps".

53 Cook, "Going Solid", 130-134.

54 Es gibt einige Beispiele für diese Art der Stimmungsanalyse zur Erkennung von "Insider-Bedrohungen", eines davon ist: https://oreil.ly/qTA76. Im Blogbeitrag der CMU findest du die Herausforderungen, die damit in der Praxis verbunden sind.

55 In der Regel sagen die Anbieter nicht ausdrücklich "Keylogging", sondern verwenden Euphemismen wie "Keystroke Dynamics", "Keystroke Logging" oder "User Behavior Analytics". Die CISA erklärt in ihrem Leitfaden zur Abwehr von Insider-Bedrohungen (Insider Threat Mitigation Guide ) über User Activity Monitoring (UAM): "Im Allgemeinen überwacht UAM-Software die gesamte Bandbreite des Cyberverhaltens eines Benutzers. Sie kann Tastatureingaben protokollieren, Screenshots aufnehmen, Videoaufnahmen von Sitzungen machen, Netzwerkpakete untersuchen, Kernel überwachen, das Surfen und Suchen im Internet verfolgen, das Hoch- und Herunterladen von Dateien aufzeichnen und Systemprotokolle überwachen, um ein umfassendes Bild der Aktivitäten im Netzwerk zu erhalten." Siehe auch die Präsentation "Exploring keystroke dynamics for insider threat detection".

56 Charles Perrow, Normale Unfälle: Living with High-Risk Technologies, Revised Edition (Princeton, NJ: Princeton University Press, 1999).

57 Manikam Pillay und Gaël Morel, "Measuring Resilience Engineering: An Integrative Review and Framework for Bench-marking Organisational Safety", Safety 6, no. 3 (2020): 37.

58 Rankin, "Resilience in Everyday Operations", 78-97.

Get Sicherheit Chaos Engineering now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial