Mitternachtshacking

Über das Buch „Normal Accidents“ von Charles Perrow und die Zusammenfassung von Dick Piccard wollte ich schon länger was schreiben aber irgendwie hat immer die Zeit gefehlt. Perrow hängt seine Beispiele am Kernreaktorunfall in Three Mile Island 1979 auf, man kann jedoch leicht Analogien zu modernen IT-Infrastrukturen, insbesondere auch in der Produktion ziehen. Die Begriffe mit denen wir im IT-Risikomanagement arbeiten sind im Grunde jedoch die gleichen.

Es gibt Fehler und Ausfälle („Discrete Failures“), die an einer Stelle auftreten und an und für sich gut verstanden sind. Ein Ausfall einer Festplatte könnte so ein Fehler sein. Um den Schaden solcher Ausfälle zu minimieren werden fehlertolerante Systeme eingesetzt, d.h. wichtige Server enthalten redundante Platten, redundante Netzteile, etc. und wenn eine Komponenten ausfällt bleibt das Gesamtsystem erhalten. Damit versucht man einen „Single Point of Failure“ zu vermeiden.

Gleichzeitig ist die gesamte Infrastruktur immer stärker und enger vernetzt, man nennt das auch „tight coupling“. Solange daher nur ein diskreter Ausfall auftritt bleibt die Situation leicht beherrschbar. Wenn jedoch mehrere solcher diskreter Ausfälle gleichzeitig auftreten dann kann aufgrund der hohen Vernetzung leicht eine Situation eintreten, in der die verschiedenen Ausfälle nicht mehr zuverlässig identifiziert werden können und durch das Zusammenwirken der eigentlich harmlosen Einzelfehler ein hoher Schaden eintritt. Perrow spricht hier von „Interactive Complexity“.

Ein „Normal Accident“ ist ein Unfall oder Schaden, der aufgrund des Zusammenspiels mehrerer für sich genommen harmloser Einzelfehler auftritt, die in Summe kaum noch beherrschbar sind. Solche Unfälle sind auf Dauer kaum vermeidbar, da Fehler mit einer gewissen Wahrscheinlichkeit auftreten und zufällig auch Häufungen vorkommen können.

Um diese Unfälle zu minimieren sind mehrere Maßnahmen hilfreich:

•  Effizentes Risikoassessment mit einer realistischen Risikoanalyse zur Bewertung der Gefahren und Schäden
• Minimierung der möglichen Schäden, um Katastrophen zu vermeiden. Hier können oft bereits in der Planung einer Infrastruktur schlimme Fehler vermieden werden
• Vermeidung von Technologie, die nicht beherrschbar sind. Oft wäre es besser ein stabil betriebenes System mit geringerer Funktionalität zu nutzen als ein unsicheres das jedoch ein paar Gimmicks mehr hat
• Vermeidung zu starker Integration und Vernetzung, damit sich Schäden nicht ausbreiten können

Vieles davon lässt sich auch in der IT gut umsetzen. Es scheitert jedoch oft am Willen. Dazu vielleicht später mehr.