❓ Die Ausgangsfrage

Dies ist der hundertste Beitrag dieser Reihe. Eine runde Zahl, und beim Schreiben fĂ€llt mir auf, dass sie als Ziel in meinem Fach nirgends vorkommt. Hundert Prozent Sicherheit verspricht niemand, der etwas davon versteht. Gefragt wird trotzdem danach, in Ausschreibungen, in Aufsichtsratssitzungen und in der ersten Viertelstunde jedes Projekts. Warum also scheitert die Zahl, die ĂŒberall sonst das Ziel ist?

🔍 Die erste Antwort

Weil sie zu teuer ist. Das ist die Antwort, die ich am hĂ€ufigsten gebe, und sie stimmt. Die erste Kontrolle kostet wenig und hĂ€lt viel ab, die zwölfte kostet ein Vielfaches und fĂ€ngt das ab, was elf andere schon abgefangen haben. Irgendwann wird die nĂ€chste Maßnahme teurer als der Schaden, den sie verhindert, und genau dort hört ein vernĂŒnftiges Sicherheitsprogramm auf.

Diese Antwort hat einen Vorzug und einen Haken. Der Vorzug: Sie lÀsst sich rechnen, und wer rechnet, entscheidet, statt zu vertagen. Der Haken: Sie belÀsst alles bei der Betriebswirtschaft. Wer sie hört, denkt sich die Grenze weg, sobald jemand genug Geld mitbringt.

⚡ Die unbequeme Folgefrage

Was also, wenn Geld keine Rolle spielt? Es gibt Systeme, bei denen es das nicht tut. Ein Steuerrechner im Kraftwerk, ein Herzschrittmacher, die Software in einem Flugzeug: Dort wird nicht gespart, dort wird nach Vorschrift geprĂŒft, formal verifiziert und dreifach ausgelegt. WĂ€re die Ökonomie die einzige Grenze, mĂŒsste sich dort hundertprozentige Sicherheit kaufen lassen.

Sie lĂ€sst sich nicht kaufen. Auch diese Systeme werden mit Restrisiko in Betrieb genommen, und die Betreiber wissen das. Das Geld ist also nicht der Grund, sondern nur der erste, auf den man stĂ¶ĂŸt.

🔁 Die Gegenprobe

Hinter der Betriebswirtschaft liegt die Berechenbarkeitstheorie, und dort wird die Sache endgĂŒltig. Henry Gordon Rice hat 1953 bewiesen, dass jede nichttriviale Eigenschaft des Verhaltens eines Programms unentscheidbar ist. Kein Verfahren kann fĂŒr beliebige Programme entscheiden, ob sie eine bestimmte Eigenschaft haben – und „ist sicher" ist eine solche Eigenschaft. Wer hier einwendet, dass sich Sicherheit oft gar nicht an einem einzelnen Programmlauf entscheidet, sondern erst im Vergleich mehrerer, hat recht – und benennt damit das grĂ¶ĂŸere Problem. Solche Eigenschaften, die Fachleute Hypereigenschaften nennen, lassen sich schwerer prĂŒfen als gewöhnliche, nicht leichter. Edsger Dijkstra hat die praktische Seite davon 1969 auf der NATO-Tagung in Rom in einen Satz gefasst: Testen zeigt die Anwesenheit von Fehlern, nie deren Abwesenheit.

Das ist kein Kostenargument mehr. Ein unbegrenztes Budget Ă€ndert daran nichts, weil hier nichts knapp ist außer der Beweisbarkeit. Wer formal verifiziert, widerlegt das nicht, sondern bestĂ€tigt es: Der Beweis betrifft eine bestimmte Eigenschaft eines bestimmten Programms, gemessen an einer Spezifikation, die ein Mensch geschrieben hat. Was in dieser Spezifikation fehlt, bleibt unbewiesen – und was fehlt, weiß man vorher nie vollstĂ€ndig. Damit verschiebt sich die Frage von „ist es sicher" zu „habe ich das Richtige aufgeschrieben" – und die zweite beantwortet keine Maschine.

🎯 Die Antwort, die bleibt

Beide Grenzen gelten, und die zweite liegt hinter der ersten. Die ökonomische ziehen wir selbst: Wir entscheiden, wo wir aufhören zu investieren. Die logische zieht niemand, sie gilt. Der Unterschied ist fĂŒr die Praxis erheblich: Gegen die erste hilft mehr Geld, gegen die zweite hilft nur eine andere Frage. Nicht „wann sind wir fertig", sondern „womit rechnen wir, wenn es passiert".

Genau das verlangt die ISO 27001, wenn sie Akzeptanzkriterien fordert, bevor das erste Risiko bewertet wird. Wer sie festlegt, hat nicht aufgegeben, sondern nur aufgehört, eine Zahl zu versprechen, die es nicht gibt.

Hundert BeitrĂ€ge sind eine Anzahl; die erreicht man, indem man hundertmal schreibt. Hundert Prozent wĂ€ren eine Quote – und diese eine erreicht man nicht, man handelt sie aus. Oder man verspricht sie und hofft, dass niemand nachrechnet.

📚🔍