Risiko und Defense-in-Depth

Die Risiko-Formel

In der einfachsten Form gilt:

Risiko = Eintrittswahrscheinlichkeit × Schaden

Beide Faktoren sind selten exakt zu beziffern — aber selbst grobe Schätzungen reichen, um aus einer langen Liste „möglicher Probleme" eine sinnvoll sortierte Aktions-Liste zu machen. Der praxistauglichste Weg ist eine Risiko-Matrix mit grobem 3×3- oder 5×5-Raster:

Ein paar Beispiele aus dem Web-Umfeld:

• Phishing auf Buchhaltung mit BEC-Schaden — Wahrscheinlichkeit hoch, Schaden hoch (Geld). Risiko: hoch. Priorität: Schulung + Mail-Filter + 4-Augen-Prozess bei IBAN-Änderungen.
• Server-Ausfall, CDN bleibt verfügbar — Wahrscheinlichkeit mittel, Schaden niedrig (statische Seite kommt). Risiko: niedrig. Priorität: gering, akzeptabel.
• Vollständiger Verlust der Produktions-Datenbank ohne Backup — Wahrscheinlichkeit niedrig (mit Disziplin), Schaden katastrophal. Risiko: mittel — aber wegen des katastrophalen Schadens muss die Eintrittswahrscheinlichkeit unbedingt klein gehalten werden (= Backups, Restore-Tests).
• APT-Angriff auf Solo-Selbstständige — Wahrscheinlichkeit sehr niedrig, Schaden hoch. Risiko: niedrig — nicht weiter investieren.

Die Matrix ist subjektiv. Sie wird trotzdem nützlich, sobald sie schriftlich und gemeinsam entsteht — Diskussionen über die Einordnung sind selbst die wertvollste Phase, weil sie Annahmen sichtbar machen.

Risiko-Behandlung: vier Optionen

Aus dem klassischen Risiko-Management (ISO 31000, ISO/IEC 27005) kommen vier Standard-Antworten auf jedes identifizierte Risiko:

• Mindern (Mitigate). Schutzmaßnahmen einführen, die Wahrscheinlichkeit oder Schaden reduzieren. Der häufigste Fall — und das, womit sich der Rest dieser Doku beschäftigt.
• Übertragen (Transfer). Cyber-Versicherung, externes Hosting mit SLA, Auslagerung an spezialisierten Provider. Risiko ist nicht weg, aber die finanzielle Konsequenz wandert.
• Vermeiden (Avoid). Die risikobehaftete Funktion einfach nicht anbieten. Wer keine Kreditkartendaten speichert, kann keine verlieren — PCI-DSS-Scope geht so von „voll" auf „minimal".
• Akzeptieren (Accept). Bewusste Entscheidung, das Risiko zu tragen, weil Kosten der Mitigation > erwarteter Schaden. Wichtig: Akzeptanz muss dokumentiert sein. Sonst wird sie als „vergessen" missverstanden.

Die häufigste Fehlentscheidung ist stille Akzeptanz — niemand hat formal entschieden, aber auch niemand kümmert sich. Bei jedem Audit kommt das Thema neu auf den Tisch, jedes Mal beginnt die Diskussion von vorn.

Defense-in-Depth: warum eine Mauer nicht reicht

Aus der Risiko-Logik folgt direkt: keine einzelne Schutzmaßnahme reicht aus. Jeder Schutz hat eine Restschwäche — sei es ein noch nicht entdeckter Bug, eine Fehlkonfiguration, ein menschlicher Fehler. Defense-in-Depth baut deshalb mehrere unabhängige Schichten so übereinander, dass ein Angreifer mehrere Hürden überwinden muss.

Das Konzept stammt aus dem Militär (Antiken, dann Festungsbau) und hat sich in der IT-Sicherheit Ende der 1990er etabliert. Charakteristisch sind drei Eigenschaften:

• Redundanz — gleiche Schutzwirkung über verschiedene Mechanismen.
• Diversität — Schichten nutzen unterschiedliche Technologien, damit ein Bug nicht alle gleichzeitig kippt.
• Annahme: jede Schicht kann fallen — Architektur ist explizit so gebaut, dass kein einzelner Punkt katastrophal ist.

Defender's Advantage: Ein Angreifer muss alle sieben Schichten überwinden — die Verteidigung braucht nur eine intakte, um den Angriff zu stoppen oder zumindest sichtbar zu machen.

Defense-in-Depth im Konkreten: XSS-Beispiel

Das Schichtmodell wird konkret, wenn man eine einzelne Schwachstelle gegen alle möglichen Schichten prüft. Beispiel: Schutz vor Cross-Site Scripting.

Sieben Schichten gegen ein Problem. Keine ist allein perfekt — zusammen ist die Eintrittswahrscheinlichkeit eines schadhaften XSS-Vorfalls nahe null. Genau diese Argumentation gehört in jede Sicherheits-Diskussion: wo ist meine Diversität, wo ist mein Single Point of Failure?

Least Privilege: das andere Grundprinzip

Eng verwandt mit Defense-in-Depth ist das Prinzip der minimalen Rechte — Least Privilege. Jeder Bestandteil eines Systems bekommt genau die Rechte, die er für seine Aufgabe braucht — und nicht mehr. Das reduziert den Schaden, wenn die Komponente kompromittiert oder missbraucht wird.

Anwendungs-Beispiele:

• Datenbank-User für eine Web-App: SELECT/INSERT/UPDATE/DELETE auf einige Tabellen, kein DROP TABLE, kein CREATE ROLE, kein Superuser. Migrationen laufen unter einem getrennten User mit höheren Rechten — manuell oder per CI, nicht im laufenden Request.
• Service-Accounts sind nicht gleich. Der Cron-Job, der nächtens Bilder skaliert, braucht keinen Netzwerk-Zugang und keinen DB-Lesezugang.
• Browser-Extensions sollten nur Domain-Zugriffe verlangen, die sie wirklich brauchen. Eine PDF-Reader-Extension mit <all_urls>-Permission ist eine Backdoor in spe.
• API-Tokens mit minimalen Scopes. Ein „PR-anlegen"-Token für CI braucht keinen Read-Org-Members-Scope.
• OAuth-Apps bei Drittanbietern: bei jeder neuen Connection prüfen, welche Scopes wirklich nötig sind — viele Apps fragen aus Bequemlichkeit Vollzugriff an.

Least Privilege ist billig in der Implementierung und teuer im Vergessen-Werden. Die typische Codebase wächst über Jahre, Rollen vermehren sich, Berechtigungen kumulieren — bis ein Audit zeigt, dass jeder zweite Mitarbeitende theoretisch Produktions-DB-Zugang hat.

Praktische Pflege:

• Quartals-Reviews von Service-Account-Rechten und Mitarbeitenden-Rollen.
• Just-in-Time-Zugang für Sondersituationen statt dauerhafter Admin-Rechte.
• Default-Deny. Alles, was nicht explizit erlaubt ist, ist verboten — nicht umgekehrt.

Zero Trust: Defense-in-Depth, modern formuliert

Ein verwandter, in den letzten Jahren populärer Begriff ist Zero Trust. Die Kernaussage: das traditionelle Modell „innen = vertrauenswürdig, außen = misstrauisch" funktioniert in cloud-, mobile- und remote-getriebenen Architekturen nicht mehr. Stattdessen gilt überall Misstrauen, jeder Zugriff wird neu verifiziert — unabhängig davon, ob er aus dem Office-Netz oder aus einem Café kommt.

Konkrete Bausteine:

• Identity-First Authentication. Wer ruft an, mit welchem Gerät, in welchem Zustand?
• Kontinuierliche Re-Verifikation statt einmaliger VPN-Anmeldung am Morgen.
• Mikro-Segmentierung. Services dürfen nur mit den anderen Services sprechen, mit denen sie sprechen müssen.
• Policy-Engine. Zugang als Auswertung von Identität + Gerät + Kontext + Ressource, nicht als statisches Netzwerk-Recht.

Zero Trust ist letztlich Defense-in-Depth + Least Privilege, neu gepackt für hybride und Cloud-Umgebungen. Die NIST-Spezifikation SP 800-207 ist die nüchterne Referenz; die meisten Vendoren-Marketing-Versionen kochen die gleiche Suppe.

Typische Fehler in der Praxis

• Defense-in-Width statt Defense-in-Depth. Viele kleine Schutzmaßnahmen auf der gleichen Schicht, statt unabhängige Tiefen-Schichten. Drei Anti-Virus-Programme nebeneinander ersetzen kein Backup.
• Schichten, die identisch versagen. Wenn alle Schutzmaßnahmen dasselbe Library nutzen (z. B. einen kaputten Hashing-Algorithmus), ist Diversität nicht gegeben — ein Bug killt alle.
• „Mehr Sicherheit = mehr Sicherheit". Wer 17 Auth-Faktoren hintereinanderschaltet, baut keine Sicherheit, sondern Frustration — Nutzer:innen umgehen das System (Passwort-Schreibzettel, Token-Sharing). Sicherheit endet, wo Nutzbarkeit endet.
• Vergessene Akzeptanz. „Das Risiko nehmen wir in Kauf" ist eine valide Antwort — aber sie muss schriftlich, mit Datum, mit verantwortlicher Person stehen. Sonst ist es kein Risiko-Management.
• Verzicht auf Restore-Tests. Backups, die nie zurückgespielt wurden, funktionieren statistisch in einem hohen Prozentsatz der Fälle nicht. Mindestens halbjährlich testen.

Weiterführende Ressourcen

Externe Quellen

• NIST SP 800-207 – Zero Trust Architecture
• NIST SP 800-30 – Guide for Conducting Risk Assessments
• ISO 31000 – Risk Management Standard
• ISO/IEC 27005 – Information Security Risk Management
• Saltzer & Schroeder – The Protection of Information in Computer Systems (1975)
• OWASP – Defense-in-Depth Concept
• BSI – IT-Grundschutz-Methodik

Verwandte Artikel

• Was ist Web-Sicherheit?
• Bedrohungsmodelle
• Angreifer-Typen
• Angriffsketten und Kill Chain
• Sicherheits-Mythen