„Mehrere Schichten sind besser als eine.“

Das ist die Absicht hinter Defense in Depth. Aber eine gute Absicht ist nicht genug, wenn du einem CFO erklären musst, warum du Geld für eine dritte Kontrolle ausgeben willst, obwohl du schon zwei hast. Die gute Nachricht: Die Mathematik ist auf deiner Seite. Und sie ist einfacher, als du denkst.

Das einfachste Modell

Stell dir eine Kontrolle vor, sagen wir, eine Firewall. Sie blockiert 99% aller böswilligen Zugriffe. Klingt gut, oder?
Aber was bedeutet das in absoluten Zahlen? Wenn du 100.000 Angriffsversuche pro Jahr hast, kommen 1.000 durch.
Das ist Immer noch ein Problem.
Jetzt fügst du eine zweite Kontrolle hinzu. Ein Intrusion Detection System, das ebenfalls 99% der verbliebenen Angriffe erkennt.
Von den 1.000, die durch die Firewall kamen, erkennt das IDS 990.
Es kommen nur noch 10 durch.
Eine dritte Kontrolle, die Endpoint Protection mit derselben Effektivität, reduziert dann das auf 0,1 erfolgreiche Angriffe pro Jahr.
Statistisch gesehen: Ein erfolgreicher Angriff alle zehn Jahre.

Das ist die Macht der Multiplikation unabhängiger Wahrscheinlichkeiten.

Die mathematische Formel

Wenn du eine Kontrolle hast, die Angriffe mit Wahrscheinlichkeit p₁ stoppt, und eine zweite mit Wahrscheinlichkeit p₂, dann ist die kombinierte Durchlasswahrscheinlichkeit:

(1 – p₁) × (1 – p₂)

Für drei Kontrollen mit je 99% Effektivität:

(1 – 0,99) × (1 – 0,99) × (1 – 0,99) = 0,01 × 0,01 × 0,01 = 0,000001

Ein Millionstel. Das ist der Unterschied zwischen „meistens sicher“ und „praktisch sicher“.

Das Unabhängigkeitsproblem

Jetzt kommt allerdings ein Haken. Diese Art von Rechnung kann man allerdings nur dann anstellen, wenn die Kontrollen voneinander auch unabhängig sind. Und das sind sie aber oft nicht.
Stell dir vor, du hast zwei Firewalls. Beide vom selben Hersteller, mit derselben Konfiguration. Wenn ein Angreifer eine Schwachstelle in der einen findet, dann hat er automatisch die andere auch geknackt. Die Kontrollen sind also nicht unabhängig. Die Wahrscheinlichkeiten multiplizieren sich dann nicht mehr.
Oder stell dir vor, du hast Firewall und IDS, aber beide werden von derselben Person administriert. Wenn diese Person einen Fehler macht z.B. eine Fehlkonfiguration, ein übersehenes Update dann sind oft beide Kontrollen betroffen.

Die Lektion: Defense in Depth funktioniert nur dann, wenn die Schichten wirklich verschieden sind. Verschiedene Technologien, verschiedene Anbieter, verschiedene Teams, verschiedene Fehlerquellen.

Die Grenzkosten von Kontrollen

Ein weiterer mathematischer Aspekt: abnehmender Grenznutzen.

Die erste Kontrolle reduziert das Risiko um 99%. Die zweite reduziert das verbleibende Risiko um weitere 99%.
Allerdings ist das verbleibende Risiko nach der ersten Kotrolle nur noch 1% des Originals. In absoluten Zahlen ist der Gewinn der zweiten Kontrolle kleiner als der der ersten.
Die dritte Kontrolle reduziert wieder 99%. Dieses Mal aber nur noch von 0,01%. Der absolute Gewinn ist daher noch einmal kleiner.
Das bedeutet nicht, dass zusätzliche Kontrollen sinnlos sind. Aber es bedeutet, dass der Return on Investment mit jeder Schicht sinkt. Irgendwann ist das Geld besser in anderen Bereichen investiert.

Die Frage ist nun nur:
Wann ist dieser Punkt erreicht? Die Antwort hängt von deinem akzeptablen Risikoniveau ab und das ist eine Business-Entscheidung, keine technische. Setzt aber voraus dass du deine Risiken und Restrisiken auch entsprechend in monetärer Form ausweisen kannst. Das kannst du in dem folgenden Post noch einmal nachlesen: FAIR verstehen: Quantitative Risikoanalyse für Praktiker.

Die Realität: Keine Kontrolle ist zu 99% effektiv

Ich habe bisher mit 99% Effektivität gerechnet. Das ist optimistisch. Sehr optimistisch.
In der Realität ist die Effektivität einer Kontrolle schwer zu messen und variiert stark. Eine Firewall stoppt vielleicht 99,9% der bekannten Angriffsmuster aber nur 0% der Zero-Days. Ein Virenscanner erkennt 99% der bekannten Malware aber nur 2% der brandneuen über die Verahaltensanalyse.

Das ändert die Rechnung, aber nicht das Prinzip. Auch wenn jede Kontrolle nur 80% effektiv ist, verbessern drei Kontrollen die Gesamteffizienz erheblich:

(1 – 0,80)³ = 0,008 = 0,8%

Statt 20% Durchlassrate nur noch 0,8%. Das ist immer noch ein Faktor von 25.

Der Swiss-Cheese-Effekt

Es gibt eine Metapher, die Defense in Depth gut erklärt: das Swiss-Cheese-Modell.

Jede Kontrolle ist eine Scheibe Käse. Jede Scheibe hat Löcher, also Schwachstellen, Umgehungsmöglichkeiten, Fehlkonfigurationen. Wenn du nur eine Scheibe hast, kommen Angriffe leicht durch die Löcher.
Aber wenn du mehrere Scheiben hintereinander stapelst, müssen die Löcher zufällig übereinander liegen, damit ein Angriff durchkommt. Je mehr Scheiben, desto unwahrscheinlicher diese Ausrichtung.
Das Modell zeigt auch, warum ein einzelner Fehler manchmal katastrophal ist: Wenn zufällig alle Löcher übereinander liegen (vielleicht weil derselbe Fehler mehrere Kontrollen betrifft) gibt es plötzlich einen völlig freien Durchgang.

Praktische Implikationen

Was bedeutet das für die Praxis?

Diversifiziere deine Kontrollen. Nicht drei Firewalls, sondern Firewall, IDS und Endpoint Protection. Nicht drei Produkte vom selben Hersteller, sondern ein Mix. Die Unabhängigkeit ist entscheidend.
Priorisiere die ersten Schichten.
Die erste Kontrolle bringt den größten absoluten Gewinn. Stell sicher, dass sie gut ist, bevor du über die dritte und vierte nachdenkst.
Kenne die Grenzen jeder Kontrolle. Wo sind die Löcher im Käse? Welche Angriffstypen werden nicht oder nur schwer erkannt? Deine nächste Schicht sollte dann genau diese Löcher abdecken.
Investiere in verschiedene Dimensionen. Nicht nur in technische Kontrollen sondern auch in Prozesse, Trainings, physische Sicherheit. Ein Angreifer, der alle technischen Kontrollen umgeht, aber an einem aufmerksamen Mitarbeiter scheitert ist gescheitert und das ist Defense in Depth in perfekter Aktion.

Wann sind zu viele Schichten zu viel?

Es gibt einen Punkt, an dem zusätzliche Kontrollen mehr schaden als nutzen.

Erstens: Komplexität. Jede Kontrolle muss gemanagt, gepatcht, konfiguriert werden. Mehr Kontrollen bedeuten mehr Angriffsfläche für Fehlkonfiguration. Mehr Stellen, an denen etwas schief gehen kann.

Zweitens: Friction. Jede Kontrolle kostet Zeit und Bequemlichkeit. Benutzer, die durch zu viele Hürden müssen, finden sehr schnell irgendwelche Workarounds. Und Workarounds sind oft weniger sicher als wenn keine Kontrolle da wäre.

Drittens: False Positives. Mehr Kontrollen bedeuten auch mehr Alerts. Wenn die meisten davon allerdings falsch sind, entwickelt sich eine Art Alert Fatigue. Das Security-Team hört auf, aufzupassen.

Die Kunst ist, die richtige Balance zu finden. Genug Schichten für einen echten Schutz zu haben und nicht so viele, dass sie sich selbst behindern.

Das Defense-in-Depth-Audit

Hier ist eine Übung, die ich empfehle: Zeichne deine kritischsten Assets auf ein Blatt Papier. Dann zeichne alle Kontrollen ein, die ein Angreifer überwinden müsste, um von außen an diese Assets zu gelangen.

Zähle die Schichten. Sind es mindestens drei? Sind sie unabhängig? Decken sie unterschiedliche Angriffstypen ab?
Dann stell dir vor, du bist der Angreifer. Wo sind die Löcher in jeder Schicht? Gibt es einen Pfad, auf dem die Löcher übereinander liegen? Wenn ja, dann hast du eine Schwachstelle gefunden.
Diese Übung ist nicht mathematisch exakt. Aber sie gibt dir ein Gefühl dafür, ob dein Defense-in-Depth-Konzept trägt oder ob es nur ein Marketingbegriff bleibt.

Das fundamentale Prinzip

Am Ende geht es um ein fundamentales Prinzip:
Keine einzelne Kontrolle ist perfekt. Jede kann umgangen werden, jede kann versagen, jede hat blinde Flecken.
Defense in Depth akzeptiert diese Realität und antwortet darauf: Wenn eine Kontrolle nicht reicht, dann eben mehrere. Die Mathematik zeigt, dass das funktioniert. Solange die Kontrollen unabhängig sind!

Das ist kein neues Konzept. Burgen hatten Mauern, Gräben und Türme. Banken haben Tresore, Alarmanlagen und Wachleute. Die Grundidee ist uralt.
Neu ist nur, dass wir sie mathematisch fundieren können. Und das macht den Unterschied zwischen Intuition und Argumentation.

—

Die Originalpublikation zum Swiss-Cheese-Modell stammt von James Reason (1990). Für Security-Anwendungen empfehle ich die Lektüre von NIST SP 800-53, das Defense in Depth als Architekturprinzip behandelt.