System-Resilienz im Software-Engineering
Multiperspektivische Betrachtung soziotechnischer Faktoren im Software-Engineering
Zunehmende Interkonnektivität ist eine charakteristische Eigenschaft evolutionärer Systemlandschaften,
in der die inhärente Systemkomplexität dazu beiträgt, dass die Anfälligkeit für Störungen zunimmt.
Daher ist die Adaption von Störeinflüssen besonders interessant.
Resilience-Engineering hat sich seit den frühen 2000er-Jahren als interdisziplinäres Ingenieurparadigma etabliert
und baut auf Erkenntnissen der Systemtheorie und der Sicherheitsforschung auf.
Eine Schwierigkeit liegt dabei in der konzeptionellen Betrachtungsweise von Risiken.
Die Risikobewertung (Ergebnis der Risikoanalyse) quantifiziert die Wahrscheinlichkeit und die Folgen eines Ereignisses,
um kritische Systemkomponenten zu identifizieren, die für spezifische Bedrohungen anfällig sind.
Die System-Resilienz verfolgt einen „bedrohungsagnostischen“ Standpunkt.
System-Resilienz wird als die Fähigkeit eines Systems verstanden, sich an veränderte Bedingungen anzupassen,
Störeinflüsse zu erkennen und Störungen zu absorbieren.
Besondere Relevanz erfährt das Resilienz-Konzept, wenn Risiken nicht ausreichend abschätzbar sind.
Daher braucht die Resilienzmessung neuartige analytische Ansätze,
die komplementär zu existierenden Risikoansätzen sind und sich dennoch differenzieren.
Delay -/Holding Attack
Im industriellen Systemkontext werden Störungen in Messaging-Systemen besonders kritisch bewertet,
da sie essentiell für die Kommunikation von Cyber-Physical-Systemen (CPS) sind und oftmals eine Brücke (Kopplung)
zwischen der digitalen und der physischen Welt (beispielsweise in der Mess- und Regeltechnik für Motoren, Ventile, Turbinen) bilden.
Im industriellen Kontext sind nicht nur die Verfügbarkeit, sondern auch die Deterministik entscheidend,
also die Gewissheit, dass eine Nachricht (I/O Signale) innerhalb festegelter und oft sehr kurzen Zeitfenstern ankommt,
da bereits geringe Verzögerungen ein erhebliches Schadenspotenzial aufweisen können.
Eine Delay Attacke, auch als Latency - oder Holding Attack bezeichnet,
erhöht die Latenz von Nachrichten um einen konstanten oder variablen Betrag.
Dabei werden Protokollschwächen beispielsweise in Messaging-Protokollen, wie MQTT (CVE-2026-22535, CVE-2026-40046) oder
OPC UA (CVE-2025-11043), oder Schwachstellen in Softwaresystemen ausgenutzt.
Automatisierte, adaptive Systeme zur Reaktion auf Sicherheitsvorfälle gehören zu den effektiveren Massnahmen gegen Bedrohungsszenarien.
Dies beinhaltet die integrierte Automatisierung in „Cyber Threat Intelligence (CTI) Frameworks“,
um eine schnelle Eindämmung und Behebung differenzierter Störungen zu ermöglichen.
Exemplarisch lässt sich das STIX/TAXII-Framework nennen, das eingesetzt werden kann,
um den Austausch von CTI-Organisationen, Sicherheitsplattformen und Regierungsbehörden zu automatisieren.
STIX steht für Structured Threat Information Expression und lässt sich als standardisierte Sprache zur Beschreibung von Cyber Threats,
Angriffsmustern, Kampagnen, Indikatoren, Malware und Bedrohungsakteuren, etc. verstehen.
TAXII (ab Version 2.1) ist ein auf JSON basierendes Protokoll für den Austausch der CTI-Informationen und
ist seit Juni 2021 in der Version 2.1 verfügbar. TAXII wird von verschiedenen CTI-Plattformen,
Security Information and Event Management, kurz SIEM-Systemen und Computer Emergency Response Team, kurz CERTs genutzt.
Link(s): STIX Version 2.1 Errata 01, TAXII 2.1
Das Konzept der System-Resilienz (ISO/IEC FDIS 9837) besteht aus drei wesentlichen Fähigkeiten:
(1) Erkennen und Einschätzen von Störungen (t0, siehe Abbildung),
(2) Anpassung/Reaktion (t1, t2) und
(3) Wiederherstellung konsistenter Systemzustände und Daten (t3 - t5).
Zur Vermeidung von Kaskadeneffekten (propagation) gilt es eine möglichst hohe Transientenstabilität zu erreichen.
Als ein transient stabiler Zustand wird ein konsistenter Zustand elementarer Systemfunktionen (Kernfunktionalität) verstanden,
der erhalten bleibt, bis wieder ein stationärer Zustand (Above the Curve) erreicht werden kann.
Abbildung: System-Resilienz (eigene Darstellung)
In der modernen Software-Architektur wird System-Resilienz (ISO/IEC FDIS 9837) nicht als „Abwesenheit von Fehlern“ verstanden,
sondern als die Fähigkeit eines Systems, unter besonderer Belastung oder bei Systemstörungen
die elementaren Systemfunktionen (Kernfunktionalität) aufrechtzuerhalten (Hollnagel, E., 2011).
Unterstützend wirken dabei
(1) die Vermeidung von Fehlerzuständen,
(2) die Reaktion auf Fehlerzustände und der Erhalt elementarer Systemfunktionen sowie
(3) die Wiederherstellung des stationären Zustands (Zielzustand).
Der Zielzustand gilt als stationärer Zustand, in dem das System über die erforderliche Performance (Above the Curve) verfügt.
Quelle:
ISO/IEC FDIS 9837 (2026) „Systems and software engineering - Systems resilience concepts“, Hollnagel, E. (2011) „Resilience Engineering in Practice: A Guidebook“
Resilience-Engineering
Ein erweitertes Aufgabenspektrum im Software-Engineering
Resilience-Engineering ist eine relativ neue Disziplin und erweitert das Spektrum
mit dem Fokus auf Widerstandsfähigkeit gegen zufällige (unmotivierte) und provozierte (motivierte) Einflüsse,
die potenziell zu Systemausfällen führen können („drift into failure“).
Eine grundlegende Beobachtung, die das Resilienz-Engineering begründet ist,
dass komplexe Systeme dynamisch sind und damit instabil.
Ein instabiler Zustand kann „sich entwickeln“ oder „unerwartet“ in Erscheinung treten.
Lehman beschreibt in
Programs, life cycles, and laws of software evolution,
dass produktive Softwaresysteme einem permanenten Änderungsdruck unterliegen und
zunehmend komplexer und schwerer beherrschbar werden, sofern keine Maßnahmen zur Reduktion ergriffen werden.
Diese „Gesetzmäßigkeit“ ist heute nicht weniger aktuell.
Gerade unter sich verädernden Rahmenbedingungen, wie die fortschreitende Vernetzung
von ursprünglich isolierten und überwiegend organisationsinternen Infrastrukturen
wird das Kompetenzfeld Resilience-Engineering zunehmend mehr nachgefragt.
Dies gilt besonders für Informationssysteme, die sensible Betriebs-, Fertigungs- oder Forschungsdaten verarbeiten,
auch da Systeme mit hoher Kopplung und geringer Transparenz besonders anfällig für Fehlerkaskaden und Ausbreitungseffekte sind.
Quelle: Lehman, M. M. (1980) „Programs, life cycles, and laws of software evolution“
Wie unterscheidet sich das Resilience-Engineering von anderen Qualitätskonzepten?
Wie sich das Resilience-Engineering von anderen Qualitätskonzepten unterscheidet,
wird im Vergleich mit einem Qualitätsmerkmal wie Zuverlässigkeit (Reliability) deutlich.
Zuverlässigkeit (Reliability) wird entsprechend der Norm ISO/IEC 25010:2023
als eine Qualitätseigenschaft verstanden, durch die beschrieben werden kann
wie lange und unter welchen Bedingungen eine spezifizierte Leistung erbracht wird oder erbracht werden kann.
Dabei wird diese Eigenschaft auf eine oder mehrere Systemfunktion(en) und spezifizierte Anforderungen bezogen.
Resilience-Engineering hingegen lässt sich als interdisziplinäres Paradigma verstehen,
das die Gestaltung resilienter Systeme fokussiert.
Resiliente Systeme sind so gestaltet, dass sie adaptiv reagieren können.
Das bedeutet, dass sie Störungen antizipieren, absorbieren und gestörte Funktionen wieder herstellen können;
die Stärkung der Systemfähigkeiten steht dabei im Fokus.
Soziotechnische Methoden
Eine multiperspektivische Betrachtung
Die soziotechnischen Methoden im Software-Engineering berücksichtigen
individuelle und organisatorische (soziale) sowie technische Faktoren.
Die Anwendung dieser Methoden kann zur Gestaltung effektiver und effizienter Organisationsstrukturen,
Methoden und Prozessen beitragen.
Die Entwicklung soziotechnischer Methoden im Software-Engineering ist auf die Feststellung zurückzuführen,
dass eine isolierte Betrachtung des Aufgabenspektrums der eigentlichen Komplexität und
der bestehenden Wechselwirkungen nicht gerecht wird.
Beispielsweise lassen sich Wechselwirkungen zwischen den Ebenen
(1) Individuum,
(2) Interaktion/Situation und
(3) organisatorischen/strukturellen Rahmenbedingungen beschreiben,
die global und lokal unterscheidbar sind und sich über die Zeit verändern.
Die globale Beeinflussung wird von außen an die Organisation, die Situation, das Individuum herangetragen,
während sich die individuelle Position und Perspektive aus der Interaktion innerhalb der Organisation verändert.
Damit erschließt sich ein Untersuchungsansatz, der auf der Anwendung soziotechnische Methoden und Maßnahmen basiert.
Soziotechnische Ansätze werden im organisationale Kontext selten berücksichtigt,
obwohl deren Bedeutung seit den frühen 1960ern
bekannt und wissenschaftlich fundiert sind.
Empirische Arbeiten aus den letzten Jahren lassen vermuten, dass die Gründe für die zurückhaltende Anwendung auf
die Schwierigkeit bezüglich der praktischen Umsetzung und
auf eine fehlende Verbindung zwischen diesen Methoden, den technischen Fragestellungen und betriebsinternen Prioritäten
auf operativer oder taktischer Ebene zurückzuführen sind.
Qualität zur Mitigation von Risiken
Organisiert durch das NATO Science Committee wurde 1968 in Garmisch (Bayern) die Frage diskutiert,
wie rechnergestützte Führung- und Kommunikationssysteme unter Bedingungen von Störung und
Überlastung funktionsfähig bleiben können und Systemverwundbarkeiten (system vulnerabilities)
reduziert werden können.
Die frühen Arbeiten zeigten, dass Software-Systeme nur durch eine korrekte Programmierung, entsprechend der Software-Spezifikation,
nicht ausreichend gegen Störungen geschützt werden können und dass darüber hinaus Strukturen, redundante Ressourcen und
Optionen zur Anpassung während der Laufzeit der Software-Systeme notwendig sind.
Dabei wurden besonders die Grundprobleme der Komplexität, Interdependenz und
die Gefahr des Funktionsverlusts durch unmotivierte und motiviert Störungen benannt.
Die Konferenz von 1968 gilt als bedeutender Grundstein der Software-Qualität. So dass in der Zwischenzeit
weitere Entwicklungsrichtungen der Informatik entstanden, mit dem Ziel die Stabilität von Software-Systemen zu erhöhen.
Motiviert durch die Einsicht, dass für den störungsfreien Betrieb komplexer Systeme
zunächst in der Entwicklung und später im gesamten Software Development Life Cycle (SDLC)
systematische Methoden und Prozesse benötigt werden.
Friedrich L. Bauer war eine der zentralen Schlüsselfiguren der NATO-Konferenz. Für ihn war der Begriff
„Software Engineering“ eine bewusste Entscheidung, um der „Softwarekrise“ in den 1960er Jahren entgegenzuwirken.
Friedrich L. Bauer prägte die Konferenz durch seine Überzeugung, dass die Softwareentwicklung aus dem Stadium des
„Herumbastelns“ in einen sauberen, ingenieurmäßigen Prozess überführt werden müsse.
Friedrich L. Bauer (1924-2015), Prof. für Mathematik und Informatik an der Technischen Universität München (TUM).
Quellen: Naur, Peter & Randell, Brian (1968) „Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th-11th October 1968“; Naur, Peter (1960) „Report on the Algorithmic Language ALGOL 60. Communications of the ACM, 3(5), 299-314.“
Technische Schulden
Mit dem Begriff technische Schulden wird ein Phänomen beschrieben,
bei dem kurzfristige Entscheidungen, beispielsweise aufgrund organisatorischer und situativer Gründe,
wie etwa die Beschleunigung des Release-Zyklus, zu langfristigen Mehraufwänden und Risiken führen.
Ursprünglich ein Phänomen der Software-Wartung, sind technische Schulden eine primäre Ursache für
die Beeinträchtigung der organisatorischen Leistungsfähigkeit und Qualität,
die sich auf die System-Resilienz (Systemperformance, -Stabilität und -Sicherheit) auswirken.
Technische Schulden entstehen, wenn kurzfristige Entscheidungen langfristige Risiken erzeugen.
Diese Risiken lassen sich proaktiv managen, sofern die notwendige Transparenz über Anforderungen und Abhängigkeiten besteht.
Während Anforderungen meist ein Aspekt im Anforderungsmanagement (kurzfristig) ist,
sind Abhängigkeiten in der Regel ein Aspekt der Software-Qualität (langfristig);
wodurch das ökonomische Dilemma skiziert ist.
Systemstörungen in dynamischen Systemumgebungen
In gewachsenen Systemumgebungen, mit dynamischer Orchestrierung (nicht-stationären Systemumgebungen)
werden Systemstabilität sowie Identifikation und Attribution von Störungen
durch die Vielzahl impliziter und expliziter Abhängigkeiten zur Herausforderung.
Störungen resultieren häufig aus der Interaktion verschiedener Systeme und deren Systemkomponenten (Softwareartefakte),
Konfigurationen und Scheduling-Entscheidungen, die sich zur Laufzeit verändern.
Eine Herausforderung für die Root-Cause-Analyse (RCA), die zeit- und kostenintensiv werden kann und Experten bindet.
Die Resilience-Analyse berücksichtigt die Abhängigkeiten von Systemkomponenten (Softwareartefakten) über Infrastrukturgrenzen hinweg.
Durch die explizite Berücksichtigung der Komponentenbeziehungen,
beispielsweise zwischen Services, Containern, Secrets, Queues, Datenbanken, ... und
Provisionierungsartefakten lassen sich (potenzielle) Ausbreitungspfade sichtbar machen und bewerten.