In komplexen technischen Systemen treten Störungen und Unfälle oft unvermeidlich auf – Charles Perrows Theorie der „Normalen Unfälle“ (Normal Accidents) erklärt, warum das so ist. Doch lassen sich die für die Safety (Betriebssicherheit) entwickelten Prinzipien auch auf die Security (Schutz vor Angriffen) übertragen? Dieser Artikel untersucht die Gemeinsamkeiten und Unterschiede zwischen Safety und Security und zeigt, wie Perrows Erkenntnisse aus der Unfallforschung genutzt werden können, um Sicherheitsmaßnahmen gegen vorsätzliche Angriffe zu verbessern. Wir definieren zentrale Begriffe, erläutern Perrows Grundlagen und veranschaulichen anhand von Beispielen und Empfehlungen, inwiefern Safety-Prinzipien auf Security anwendbar sind.
Begriffsbestimmung: Safety vs. Security
Im deutschen Sprachgebrauch werden beide mit Sicherheit übersetzt, doch meinen Safety und Security unterschiedliche Aspekte der Gefahrenabwehr. Safety bezeichnet die technische Betriebssicherheit und zielt darauf ab, Menschen und Systeme vor ungewollten Unfällen oder Ausfällen zu schützen (z. B. Hardwarefehler, Brand, Bedienfehler)[1]. Security hingegen bezieht sich auf den Schutz vor absichtlichen Angriffen und Bedrohungen von außen – also Maßnahmen gegen bewusste, böswillige Handlungen wie Cyberangriffe, Sabotage oder Datendiebstahl[1].
Gemeinsamkeiten: Beide Bereiche teilen das Ziel, Schaden von Menschen, Umwelt und Vermögenswerten abzuwenden. Sowohl Safety als auch Security erfordern systematisches Risikomanagement, fortlaufende Überwachung und präventive Maßnahmen. Auch greifen sie oft ineinander: Ein technischer Ausfall (Safety-Problem) kann Angriffe erleichtern, während eine Sicherheitslücke (Security-Problem) wiederum einen Unfall herbeiführen kann[1]. Deshalb wird zunehmend betont: „Ohne Security keine Safety“ – moderne Systeme müssen sicher und gegen Angriffe geschützt sein, um wirklich zuverlässig zu funktionieren.
Unterschiede: Der Kernunterschied liegt in der Art der Bedrohung. Safety adressiert interne zufällige Fehler oder natürliche Gefahren, Security dagegen vorsätzliche Angriffe durch Menschen[1]. Dadurch unterscheiden sich Herangehensweisen: Safety-Ingenieure konzentrieren sich z.B. auf Fehlertoleranz, Redundanz und Notfallpläne gegen technische Pannen. Security-Experten hingegen implementieren Zugriffskontrollen, Verschlüsselung und Überwachungssysteme, um Angreifer abzuschrecken oder zu entdecken[1]. Eine weitere Differenz ist die Dynamik der Gegenspieler: In der Security gibt es intelligente Täter, die Sicherheitsmaßnahmen umgehen wollen – eine Herausforderung, die es in der Safety (bei Unfällen) so nicht gibt. Dennoch lassen sich spannende Parallelen ziehen, wie im Folgenden gezeigt wird.
Perrows Theorie der „Normalen Unfälle“ in komplexen Systemen (Safety)
Zunächst ein Blick auf die von Charles Perrow entwickelten Grundsätze der Safety. In seinem einflussreichen Werk „Normale Katastrophen: Die unvermeidbaren Risiken der Großtechnik“ (Original: Normal Accidents, 1984) analysiert Perrow Unfälle in Hochrisiko-Technologien wie Kernkraftwerken, Flugverkehr oder Chemieanlagen[2]. Er kommt zu dem überraschenden Schluss, dass in bestimmten Systemen schwere Unfälle unvermeidlich („normal“) sind – selbst wenn alle Beteiligten ihr Bestes tun. Dies gilt insbesondere, wenn die folgenden Bedingungen vorliegen:
Hohe Systemkomplexität: Viele Komponenten interagieren unvorhersehbar. Ursachen und Wirkungen sind schwer überschaubar.
Bestehen einer engen Koppelung: Kaum Puffer oder Verzögerung zwischen Komponenten. Fehler breiten sich rasant aus und greifen sofort auf gekoppelte Teile über.
Großes Schadenspotenzial: Im System steckt die Möglichkeit katastrophaler Auswirkungen. Kleine Störungen können zu sehr schwerwiegenden Konsequenzen eskalieren.
Auf Basis dieser Eigenschaften formuliert Perrow folgende Grundsätze der Systemsicherheit:
- Unfälle sind in hochkomplexen, eng gekoppelten Systemen normal: Wenn ein System gleichzeitig komplex (vielschichtige, nicht-linear verknüpfte Prozesse) und eng gekoppelt (Prozesse greifen zeitlich oder technisch ohne Verzögerung ineinander) ist, dann werden früher oder später Unfälle passieren. Mehrere unerwartete Fehler können zusammenwirken und trotz aller Vorsicht zu einem Unfall führen, weil man nicht alle Wechselwirkungen voraussehen kann[2]. Ein bekannter Beleg war der Unfall von Three Mile Island (1979): Eine Kernschmelze, verursacht durch das Zusammenspiel mehrerer kleiner Fehlfunktionen, die niemand antizipiert hatte[2]. Perrow bezeichnet solche Ereignisse als „normal“, weil sie systemimmanent sind – praktisch unvermeidbar in solchen Systemen[2].
- Große Unfälle haben kleine Anfänge: Katastrophen beginnen oft mit scheinbar trivialen Störungen. Perrow zeigte, dass kleine Fehler häufig unentdeckt bleiben oder heruntergespielt werden, bis sie sich unvorhersehbar aufschaukeln und zu einer Krise auswachsen[2]. Winzige Auslöser kaskadieren in komplex vernetzten Systemen schnell zu Großschäden[2]. Dieses Prinzip lehrt: Eine Kultur der Achtsamkeit gegenüber Frühwarnsignalen ist essenziell.
- Menschliche und organisatorische Faktoren sind entscheidend: Entgegen der Annahme, technische Versagen seien Hauptursache, betont Perrow, dass Organisationsfehler, Managementversagen und menschliche Fehlhandlungen zentrale Unfallursachen sind[2][2]. Bedienungsfehler treten zwar häufig auf, aber die Organisationsstruktur und Prozesse bestimmen, ob daraus eine Katastrophe wird[2]. Eine schlechte Sicherheitskultur, unklare Verantwortlichkeiten oder mangelnde Kommunikation tragen mehr zu Unfällen bei als rein technisches Versagen. Safety ist somit nicht nur ein Ingenieursproblem, sondern eine organisationale Herausforderung.
- Traditionelle Sicherheitsmaßnahmen können trügerisch sein: Interessanterweise können Redundanzen und komplexe Sicherheitsvorrichtungen unter Umständen das Risiko erhöhen[2]. Perrow zeigt drei Effekte, wie „zu viel des Guten“ schaden kann[2]: (1) Zusätzliche Sicherheitssysteme machen das Gesamtsystem noch komplexer und damit störanfälliger. (2) Menschen verlassen sich dann auf die Technik und zeigen riskanteres Verhalten oder weniger Aufmerksamkeit (Verantwortungsdiffusion). (3) Redundanzen können zu höherer Auslastung verleiten – man treibt das System näher an die Leistungsgrenze, was es insgesamt unsicherer macht[2]. Die Lehre: Sicherheitskonzepte müssen ganzheitlich gedacht werden, ohne naive Technikgläubigkeit. Manchmal ist eine Vereinfachung oder radikale Neugestaltung eines Systems sicherer als immer komplexere Schutzmechanismen[2].
- Radikale Optionen erwägen: Perrow folgert in Fällen extremer Risiken, man solle überlegen, ob bestimmte Hochrisiko-Technologien überhaupt beherrschbar sind. Ist ein System so gefährlich, dass normale Unfälle unakzeptable Folgen hätten, kann die Vermeidung der Technologie selbst (Ausstieg) oder ein fundamental neues Design die sicherste Lösung sein[2]. Dieses Prinzip zeigt die konsequente Denkweise der Safety-Domain: Safety First – notfalls Verzicht auf zu riskante Prozesse.
Zusammenfassend revolutionierte Perrows Normal Accident Theory in den 1980er Jahren das Verständnis von Sicherheit und Risiko. Sie machte klar, dass Unfälle nicht allein durch einzelne Fehler oder „menschliches Versagen“ erklärt werden können, sondern als Produkt komplexer Systembedingungen gesehen werden müssen[2]. Diese Einsichten haben das Feld der Sicherheitswissenschaft nachhaltig geprägt.
Übertragung von Perrows Prinzipien auf die Security
Wie lassen sich diese Safety-Grundsätze nun auf die Security anwenden, also auf den Schutz vor gezielten Angriffen und Sicherheitsvorfällen? Trotz der unterschiedlichen Natur (unbeabsichtigter Unfall vs. vorsätzlicher Angriff) gibt es auffällige Parallelen. Moderne IT- und Organisationsstrukturen ähneln Hochrisiko-Technologien darin, dass sie hochkomplex, eng vernetzt und von kritischer Bedeutung sind. Folglich können wir Perrows Kernthesen übersetzen: Auch gravierende Sicherheitsvorfälle sind in komplexen Systemen „normal“ und unausweichlich, wenn gewisse Bedingungen gegeben sind[3][4]. Im Folgenden betrachten wir die wichtigsten Übertragungen sowie die Besonderheiten, die im Security-Kontext berücksichtigt werden müssen.
1. Unvermeidbarkeit von Sicherheitsvorfällen erkennen
In der heutigen vernetzten Welt gilt: **Schwerwiegende Cyber-Zwischenfälle sind nicht *falls*, sondern *wann* sie eintreten**[3]. So wie Perrow Unfälle als unvermeidbares Systemrisiko beschreibt, argumentieren Sicherheitsexperten analog, dass *Cyberangriffe in ausreichend komplexen IT-Landschaften unvermeidlich* sind[4]. Kein Unternehmen und keine Institution mit digitaler Infrastruktur kann sich realistisch vollständig gegen jedes Szenario absichern – es wird irgendwann eine Sicherheitslücke ausgenutzt werden. Diese Erkenntnis deckt sich mit Beobachtungen: „Cyber-Attacken sind unvermeidlich und allgegenwärtig… erfolgreiche Angriffe sind unumgänglich“, schreibt der Jurist Derek E. Bambauer und fordert, dass man sich von der Illusion verabschiedet, absolut alle Angriffe verhindern zu können[4]. Stattdessen müsse Cybersecurity sich auf Schadensbegrenzung und Resilienz fokussieren, nicht nur auf Prävention[4].
Was bedeutet das konkret? Zunächst ein Mentalitätswechsel: Organisationen sollten Sicherheitsvorfälle als Normalfall einkalkulieren. Die Frage ist nicht mehr, ob etwas passiert, sondern ob man darauf vorbereitet ist. Dieses Bewusstsein schafft die Grundlage dafür, proaktiv Maßnahmen zu ergreifen, um den Impact eines unvermeidlichen Vorfalls zu minimieren. Kurz: Expect the unexpected.
2. Komplexität und Kopplung reduzieren, wo möglich
Perrows Analyse lehrt, dass Systemkomplexität und enge Kopplung zentrale Treiber von unkontrollierbaren Zwischenfällen sind[2]. Übertragen auf Security heißt das: Je vielschichtiger und vernetzter die IT-Systeme, desto anfälliger sind sie für schwer zu beherrschende Angriffe. In der Praxis sehen wir dies an globalen Cybervorfällen: Ein einzelner infizierter Rechner kann dank hoher Vernetzung blitzschnell ganze Netzwerke lahmlegen. Beispiele sind die Ransomware-Epidemien WannaCry und NotPetya im Jahr 2017, bei denen sich Schadsoftware rasch weltweit ausbreitete und sogar unbeteiligte Organisationen traf – ein Effekt der unkontrollierten Kopplung globaler IT-Systeme[5].
Abhilfe: Sicherheitsarchitekten übertragen Perrows Prinzip „Entkopplung statt Komplexität“ durch Strategien wie Netzwerksegmentierung, beschränkte Schnittstellen und Diversifizierung. Konkret empfiehlt Bambauer z.B. zwei Designprinzipien für resilientere Systeme[4]: Disaggregation (Daten und Dienste werden verteilt statt zentral gebündelt, sodass nicht alles auf einmal kompromittiert werden kann) und Heterogenität (Einsatz unterschiedlicher Systeme/Software, um Monokulturen zu vermeiden, damit ein einzelner Exploit nicht die gesamte Infrastruktur durchdringt)[4]. Diese Ansätze verfolgen ein ähnliches Ziel wie Redundanz im Safety-Bereich – jedoch mit dem Bewusstsein, die Anfälligkeit durch Systemarchitektur zu verringern. Lose gekoppelte, modulare Systeme können einen Angriff besser eindämmen: Wenn ein Modul ausfällt oder gehackt wird, reißen nicht zwangsläufig alle anderen mit. Ebenso sollte man Komplexität senken: „Keep it simple“ gilt auch in der IT-Sicherheit – einfachere Systeme bieten weniger unerwartete Angriffspfade.
Dabei muss man beachten, dass zerlegte oder heterogene Systeme die Verwaltung erschweren können – ein analoger Trade-off zu Perrows Redundanz-Dilemma. Es gilt, ein balanciertes Design zu finden, das die IT-Landschaft überschaubar und kontrollierbar hält, ohne notwendige Integrationen zu verhindern. Hier kommen Konzepte wie Microservices, Zero Trust Architecture und sorgfältiges Interface-Management ins Spiel, um flexible Entkopplung zu erreichen. Das Ziel ist, dass lokale Fehler nicht global eskalieren – ganz im Sinne von Perrows Maxime.
3. „Große Angriffe haben kleine Anfänge“ – Frühwarnzeichen ernst nehmen
Wie bei Unfällen geschehen auch gravierende Sicherheitsverstöße oft durch eine Kette kleinerer Ereignisse. Ein typischer Cybersecurity-Vorfall beginnt vielleicht mit einer scheinbar harmlosen Phishing-E-Mail, die einen einzelnen Mitarbeiter täuscht. Daraus kann sich durch Folgeschritte – gestohlene Zugangsdaten, weitergegeben an einen weiteren kompromittierten Dienst, Ausnutzung einer ungepatchten Schwachstelle usw. – eine Großkrise entwickeln, z.B. der Diebstahl zehntausender Kundendaten. Jeder einzelne Schritt für sich mag beherrschbar oder unbedeutend wirken, in Summe jedoch entsteht ein Desaster. Diese Kaskadeneffekte spiegeln genau Perrows Beobachtung wider, dass Katastrophen sich aus kleinen Auslösern hochschaukeln[2].
Daraus folgt für die Security: Kleinen Sicherheitsvorfällen ist große Aufmerksamkeit zu schenken. Jede Anomalie – sei es ein fehlgeschlagener Login, eine ungewöhnliche Netzwerkaktivität oder ein isolierter Malwarefund – sollte als mögliches Frühwarnsignal behandelt werden. Organisationen brauchen effektive Monitoring- und Erkennungssysteme (Intrusion Detection, SIEM etc.), aber ebenso eine Kultur des Meldens und Reagierens: Mitarbeiter müssen ermutigt werden, jede Auffälligkeit zu melden, und Teams sollten solche Meldungen ernst nehmen. Eine offene Fehler- und Meldekultur, wie sie im Flugverkehr durch Crew Resource Management etabliert wurde, kann auch in IT-Teams Leben retten – bzw. schlimme Schäden verhindern. Lernen aus Beinahe-Vorfällen (Near Misses) ist ebenso wichtig wie aus tatsächlichen Sicherheitsbrüchen.
4. Menschlicher Faktor und organisatorische Sicherheit
Sowohl bei Safety als auch bei Security gilt: Technik allein verhindert keine Unfälle oder Angriffe – es kommt entscheidend auf Mensch und Organisation an. Perrow hat gezeigt, dass organisatorische Mängel oft die Wurzel von Unfällen sind[2]. Genauso ist in der Cybersecurity bekannt, dass der „Faktor Mensch“ häufig die größte Schwachstelle darstellt[3]. Ein unaufmerksamer Mitarbeiter klickt auf einen schädlichen Link, ein Admin setzt ein leichtes Passwort, eine Führungskraft unterschätzt die Bedeutung von Updates – solche Fehler öffnen Angreifern Tür und Tor.
Aber der menschliche Faktor ist nicht nur in Form von Fehlern relevant, sondern kann auch zur stärksten Sicherheitsressource werden. Wie bei Safety die Sicherheitskultur in Unternehmen (Schulungen, klare Verantwortlichkeiten, Übung von Notfallprozeduren) Unfälle verhindert, so kann eine gute Security-Kultur Angriffe abwehren. Sensibilisierung und Training aller Mitarbeiter sind daher unverzichtbar. Studien, die Normal Accident Theory auf Cybervorfälle anwenden, empfehlen explizit, den Schwerpunkt auf menschliches und organisatorisches Verhalten zu legen, um Risiken zu minimieren[6]. Best Practices müssen allen bekannt und zugänglich sein, regelmäßige Schulungen und Audits helfen, die „menschliche Firewall“ zu stärken[6], noch viel wichtiger sind aber ergonomische Prozesse und Tools, Fehler vermeiden und grundlegende systemische Voraussetzungen für sicheres Verhalten wie beispielsweise eine hinreichende Ressourcenausstattung oder ausreichende Ruhezeiten.
Zudem sind klare Prozesse und Verantwortlichkeiten im Ernstfall wichtig: Wer reagiert wie auf einen Sicherheitsalarm? Gibt es ein Incident-Response-Team mit eingeübten Abläufen (Analog zum Notfallplan bei Unfällen)? Organisatorische Vorbereitung entscheidet darüber, ob ein Angriff schnell eingedämmt wird oder sich wegen Chaos und langsamem Reagieren ungebremst ausweitet. Hier zahlt es sich aus, Sicherheitsvorfälle regelmäßig als Drills zu proben, ähnlich wie Feueralarme geübt werden. Eine lernende Organisation, die nach jedem Vorfall analysiert „Was lief gut, was schlecht?“ und entsprechende Veränderungen vornimmt, wird mit der Zeit widerstandsfähiger – dies folgt direkt Perrows Erkenntnis, dass Organisationen aus Fehlern lernen müssen.
5. Resilienz über Prävention: Vorbereitung auf den Ernstfall
Da sowohl Normalunfälle als auch große Sicherheitsvorfälle niemals komplett auszuschließen sind, lautet ein zentrales Prinzip: Fokus auf Schadensbegrenzung und Widerstandsfähigkeit (Resilienz). Im Safety-Bereich zeigt sich das etwa in Notfallsystemen, Brandschutzkonzepten oder Evakuierungsplänen, die Menschen im Falle eines Unfalls schützen. Übertragen auf Security bedeutet das: **Neben präventiven Maßnahmen muss vor allem die *Reaktions- und Auffangfähigkeit* im Vordergrund stehen**[4].
Ein robustes Sicherheitskonzept stellt sicher, dass ein erfolgreicher Angriff nicht zum Totalausfall führt. Dazu gehören zum Beispiel: regelmäßige Backups und redundante Systeme, um bei Ransomware-Angriffen die Daten wiederherstellen zu können; Notfallpläne für Cybervorfälle, damit im Chaos eines Angriffs die Kommunikation und Entscheidungswege klar sind; und Übungen für Incident Response Teams, um im Ernstfall eingespielt zu handeln. Diese Maßnahmen zielen darauf ab, die Auswirkungen eines „normalen“ Security-Unfalls zu begrenzen – ähnlich wie Sicherheitsgurte und Airbags zwar einen Unfall nicht verhindern, aber die Folgen abmildern.
Auch die Schnelligkeit der Erkennung und Reaktion gehört zur Resilienz. Wenn Angreifer sich unbemerkt wochenlang im Netzwerk bewegen können, steigt der Schaden enorm. Frühzeitige Detektion (durch Monitoring) und schnelle Isolation betroffener Systeme (durch Notfallprozeduren) sind daher essenziell. Hier zeigt sich erneut die Parallele zu Safety: In beiden Fällen entscheiden die ersten Minuten/Stunden einer Krise darüber, wie schlimm es wird. Ein gut vorbereitetes Team kann aus einem potenziellen Desaster vielleicht nur einen begrenzten Zwischenfall machen.
6. Kontinuierliches Lernen: Analysen, Feedback und Verbesserung
Eine Schlüssellehre aus der Safety-Welt ist die systematische Unfalluntersuchung – berühmte Institutionen wie die Flugunfall-Untersuchungsstellen (NTSB, BFU etc.) tragen enorm zur Sicherheit bei, indem sie jeden Vorfall gründlich analysieren und die Erkenntnisse mit der Branche teilen. Ein vergleichbares Prinzip gewinnt in der Security an Bedeutung: Jeder Sicherheitsvorfall sollte gründlich ausgewertet werden, um daraus zu lernen. Post-Incident Analysis und Transparenz sind hier die Stichworte[3]. Genau wie im Luftfahrtsektor könnte die gesamte IT-Branche profitieren, wenn Unternehmen offen über Sicherheitsvorfälle berichten und Lehren teilen. In dieser Hinsicht bewegt sich die Security-Community bereits in Richtung eines Sicherheitsmanagements nach Safety-Vorbild – beispielsweise veröffentlichen einige Firmen ausführliche Incident-Reports, und es gibt Ansätze für branchenweite Austauschplattformen zu Cybervorfällen.
Zudem fordern Experten stärkere regulatorische Vorgaben nach Vorbild der Safety-Branchen. Jack Hamm etwa argumentiert, die IT-Sicherheit brauche klare, konsequent durchgesetzte Rahmenrichtlinien und Meldepflichten, um eine Kultur des Lernens und der Rechenschaft zu fördern[3]. Dinge wie eine Pflicht zur Vorfallsberichterstattung (ähnlich wie Meldeketten bei Arbeitsunfällen) oder Audits durch unabhängige Stellen (wie TÜV/Behörden in der Anlagensicherheit) können Unternehmen anspornen, Security ernst zu nehmen und kontinuierlich zu verbessern[6][6]. In der EU etwa gibt es mit der NIS-Richtlinie erste Schritte in diese Richtung, die kritische Sektoren zu Mindeststandards und Meldungen verpflichten.
Schließlich muss Risikomanagement in beiden Feldern ein fortwährender Prozess sein. Weder Safety noch Security sind je „fertig“. Veränderungen in Technik, Organisation oder Bedrohungslage machen regelmäßige Risikobewertungen nötig[1]. In der Praxis bedeutet das: Szenarien durchspielen (Was wäre, wenn…?), neue Angriffsmuster beobachten, interne Prozesse hinterfragen. Genau wie in der Arbeitssicherheit regelmäßige Gefährdungsbeurteilungen vorgeschrieben sind, sollten in der IT-Sicherheit turnusmäßige Security-Assessments und Penetrationstests stattfinden. Dies stellt sicher, dass neue Schwachstellen früh erkannt und behoben werden – bevor sie sich zu „normalen“ Unfällen auswachsen.
Beispiele: Wenn Safety-Prinzipien die Security stärken
Zur Veranschaulichung, wie Perrows Prinzipien in der Praxis der Security wirken können, betrachten wir zwei Szenarien:
- Fallstudie 1 – Kaskadierender Datenleak: Ein großes Finanzunternehmen erleidet einen schweren Datenverlust. Die Untersuchung ergibt, dass eine Reihe von Versäumnissen zusammenkam: Ein veralteter Server wurde nicht gepatcht (technische Schwachstelle), ein Angreifer drang über diesen ein, konnte sich im internen Netzwerk frei bewegen (fehlende Segmentierung, enge Kopplung), mehrere Warnmeldungen im Monitoring blieben unbeachtet (organisatorisches Versagen) und schließlich wurden massenhaft sensible Daten exfiltriert. Kein einzelner Fehler allein hätte die Katastrophe verursacht – erst das Zusammenwirken führte zum Großschaden. Analyse: Dieses Ereignis entspricht genau einem „normal accident“ im Security-Kontext. Hätte man Perrows Lehren beachtet, wären etwa durch stärkere Netzwerk-Isolation und bessere Schulung der Admins (für Patch-Disziplin und Monitoring) die Chancen deutlich höher gewesen, den Vorfall zu verhindern oder zu begrenzen.
- Fallstudie 2 – Resilienz bei Ransomware: Ein mittelständisches Produktionsunternehmen wird Opfer einer Ransomware-Attacke, die weite Teile der IT verschlüsselt. Trotz der unvermeidlichen Betriebsstörung kann die Firma erstaunlich schnell weiterarbeiten: Dank vorgelagerter Planung gibt es Offline-Backups aller kritischen Daten und ein Notfallbetriebssystem für Maschinensteuerungen. Innerhalb von 48 Stunden werden die Systeme aus Backups wiederhergestellt, der Schaden bleibt gering. Analyse: Hier zeigt sich der Wert von Resilienzmaßnahmen. Obwohl der Angriff als solches nicht verhindert wurde (er war letztlich „normal“ gegeben die globale Bedrohungslage), konnte das Unternehmen durch vorausschauendes Safety-Denken (Redundanzen, Notfallprozess) die Auswirkungen stark begrenzen. Ein Lernen aus Vorfällen anderer (vorherige Ransomware-Wellen) hat zur präventiven Vorbereitung geführt – ein klassischer Safety-Ansatz, übertragen auf Security.
Diese Beispiele unterstreichen: Wenn Organisationen Safety-Grundsätze beherzigen – etwa systematisch Risiken analysieren, nach dem Schlimmsten fragen und in „Was wäre wenn“-Kategorien denken – sind sie für Security-Vorfälle wesentlich besser gerüstet. Umgekehrt können spektakuläre Sicherheitsfälle oft durch die Brille der Unfalltheorie verstanden werden: Man erkennt die Kausalketten, die Versäumnisse im Systemdesign oder Management, und kann daraus lernen.
Herausforderungen bei der Übertragung
Trotz aller Parallelen gibt es auch Spannungsfelder, wenn man Safety-Prinzipien auf Security anwendet:
- Adaptiver Gegner: Anders als ein defektes Bauteil lernt ein Hacker aus unseren Abwehrmaßnahmen. Maßnahmen nach dem Prinzip „gleiche Ursache, gleiche Wirkung“ greifen weniger, da Angreifer ihre Taktiken anpassen. Die Unfalltheorie geht von systeminternen Dynamiken aus, während bei Security ein externer Agent aktiv gegensteuert. Lösung: Sicherheitskonzepte müssen dynamisch und intelligent sein, z.B. mittels Threat Intelligence und adaptiver Verteidigung (Stichwort “Purple Teams”, die proaktiv Angriffe simulieren, um Systeme immer wieder zu testen).
- Schwierigkeit der Risikoabwägung: In der Safety kann man oft statistisch einschätzen, wie wahrscheinlich ein Ausfall ist (z.B. Ausfallraten von Bauteilen). In der Security ist das schwerer – das Risiko hängt vom Motiv und Können von Angreifern ab, was volatil ist. Daraus folgt, dass Risikobeurteilung in der Security unschärfer ist. Man muss stärker auf Worst-Case-Betrachtungen und Szenarienplanung setzen, statt auf exakte Eintrittswahrscheinlichkeiten.
- Kulturwandel erforderlich: Viele Organisationen haben historisch Safety-Management verankert (z.B. Arbeitsschutz), aber IT-Security wurde lange getrennt behandelt. Die Integration beider Denkweisen erfordert kulturellen Wandel und bereichsübergreifende Zusammenarbeit. Beispielsweise müssen IT-Abteilungen, Geschäftsführung und ggf. Safety-Beauftragte zusammen eine gemeinsame Sicherheitsstrategie entwickeln, in der sowohl Unfallschutz als auch Cyberabwehr Platz haben. Das ist organisatorisch herausfordernd, aber immer mehr Unternehmen erkennen die Notwendigkeit („Safety & Security by Design“ als integraler Ansatz).
- Kosten-Nutzen-Fragen: Sicherheitsmaßnahmen – ob Safety oder Security – kosten Geld und können Komfort oder Effizienz verringern. Beim Übertragen von Safety auf Security kann es Diskussionen geben, wie viel Redundanz oder Overengineering vertretbar ist, um Sicherheit zu erhöhen. Hier hilft der interdisziplinäre Ansatz: mit Methoden der Safety (z.B. FMEA – Fehlermöglichkeits- und Einflussanalyse) auch IT-Risiken zu bewerten, um faktenbasiert zu entscheiden, welche Schutzmaßnahmen am wirksamsten und wirtschaftlich sind.
Trotz dieser Herausforderungen zeigt die Entwicklung in Praxis und Forschung, dass die Konvergenz von Safety und Security der richtige Weg ist. Branchen wie die Automobilindustrie verlangen heute, dass elektronische Systeme sowohl funktional sicher (Safety) als auch cyber-sicher (Security) entwickelt werden – Normen und Standards (z.B. ISO 26262 für Safety und ISO 21434 für Automotive Security) wachsen zusammen. Diese integrative Sichtweise wird künftig zum Standard werden, da Digitalisierung alle Bereiche durchdringt.
Empfehlungen und Best Practices: Safety-Prinzipien für bessere Security nutzen
Abschließend fassen wir die wichtigsten Empfehlungen zusammen, wie Perrows Safety-Grundsätze praktisch genutzt werden können, um Security zu stärken:
Akzeptanz der Unvermeidbarkeit: Gehen Sie von vornherein davon aus, dass Sicherheitsvorfälle passieren werden. Entwickeln Sie Notfallpläne und schützen Sie kritische Werte in Erwartung eines Angriffs (Backup-Strategien, Incident Response Teams).
System-Design überprüfen: Analysieren Sie Ihre IT-Landschaft auf Komplexität und Kopplung. Vereinfachen Sie wo möglich, segmentieren Sie Netzwerke, minimieren Sie Single-Points-of-Failure. Streben Sie ein Design an, bei dem ein einzelner Fehler/Angriff nicht das ganze System lahmlegt.
Mensch und Organisation stärken: Schulen Sie Mitarbeiter regelmäßig in Sicherheitsbewusstsein. Etablieren Sie klare Prozesse für Vorfallreaktionen. Fördern Sie eine Kultur, in der Fehler und Auffälligkeiten gemeldet werden, ohne Schuldzuweisung – lernen statt vertuschen.
Vorfälle auswerten und teilen: Untersuchen Sie jeden Sicherheitsvorfall gründlich (Root Cause Analysis). Teilen Sie gewonnene Erkenntnisse intern – und wenn möglich auch extern mit der Branche. Halten Sie Ihr Schutzkonzept lebendig durch kontinuierliche Verbesserungen.
Regulatorische Rahmen nutzen: Richten Sie sich nach anerkannten Standards (ISO, NIST etc.) und gesetzlichen Vorgaben. Unterstützen Sie Initiativen für branchenweite Sicherheitsstandards und Meldepflichten. Einheitliche Regeln fördern eine Sicherheitskultur ähnlich der Arbeitssicherheit.
Fazit: Die Prinzipien von Charles Perrow aus der Unfallforschung bieten wertvolle Anregungen für die IT- und Informationssicherheit. Beide Disziplinen – Safety und Security – befassen sich letztlich mit dem Management von Risiko in komplexen Systemen. Durch die Übertragung von Safety-Grundsätzen auf Security können Organisationen proaktiver und resilienter gegenüber Bedrohungen werden. Zwar muss man die intentionalen Aspekte der Security berücksichtigen, doch Konzepte wie das Akzeptieren von unvermeidbaren Ereignissen, die Fokussierung auf robuste Systemarchitekturen, menschliche Faktoren und kontinuierliches Lernen sind universell gültig.
In einer immer stärker vernetzten und technologieabhängigen Welt verschwimmen die Grenzen zwischen Safety und Security zunehmend. Eine ganzheitliche Sicherheitspolitik, die Betriebssicherheit und Angriffssicherheit integriert, schafft ein höheres Schutzniveau. Perrows Erkenntnis, dass wir mit gewissen Risiken leben lernen müssen, mahnt uns gleichzeitig, ständig an Systemen und Organisationen zu arbeiten, um für das Unerwartete gewappnet zu sein. Indem wir Safety und Security nicht als Gegensätze, sondern als zwei Seiten derselben Medaille betrachten, können wir die Widerstandsfähigkeit komplexer Systeme insgesamt steigern – sei es gegen natürliche Unfälle oder gezielte Angriffe. [2][1]
References
[1] „Safety“ VS „Security“, was bedeutet das überhaupt?
[3] Viewing Cybersecurity Incidents as ‘Normal Accidents’
[4] Ghost in the Network – Penn Law Review
[5] Normal cyber accidents – Taylor & Francis Online
[6] Applying Normal Accident Theory to Ideological and Nation-State …
