Softwarearchitektur verstehen und entscheiden

Aaron KreisÜber mich
Sicherheitsarchitektur

Defense in Depth

Mehrere Schutzschichten hintereinander

Die Idee und ihr Nutzen

Ein Angreifer bringt einen Sachbearbeiter einer Versicherung mit einer gefälschten E-Mail dazu, sein Passwort preiszugeben. Allein mit diesem Passwort soll der Angreifer trotzdem weder Kundendaten abrufen noch Zahlungen freigeben können. Deshalb schützen mehrere voneinander unabhängige Maßnahmen die Schadenanwendung, mit der der Sachbearbeiter arbeitet: eine zweite Prüfung beim Anmelden, begrenzte Rechte jedes Kontos und eine Überwachung auffälliger Zugriffe. Jede dieser Maßnahmen bildet eine eigene Schutzschicht. Versagt eine Schutzschicht, begrenzt die nächste den Schaden: Gelangt der Angreifer trotz der zweiten Prüfung in das Konto, verhindern die begrenzten Rechte, dass er große Summen freigibt. Dieses Vorgehen heißt Defense in Depth, auf Deutsch gestaffelte Verteidigung.

Bausteine: Angreifer: hat ein Passwort erbeutet; Anmeldung: verlangt zusätzlich einen Code vom Diensthandy; Schadenanwendung: prüft jede Aktion gegen die Rechte des Kontos; Kundendaten und Zahlungen; Überwachung: erkennt auffällige Zugriffe. Verbindungen: Angreifer → Anmeldung; Anmeldung — Schadenanwendung; Schadenanwendung — Kundendaten und Zahlungen; Überwachung — Anmeldung (beobachtet); Überwachung — Schadenanwendung (beobachtet). „Anmeldung“, Schadenanwendung und „Überwachung“ schützen unabhängig voneinander; versagt eine Schutzschicht, begrenzen die anderen den Schaden.

Wie funktioniert es?

Der Angreifer versucht, sich mit dem erbeuteten Passwort des Sachbearbeiters an der Schadenanwendung anzumelden. Die „Anmeldung“ ist ein eigener Dienst, der jeden Anmeldeversuch prüft, bevor jemand in die Schadenanwendung gelangt. Die „Anmeldung“ verlangt außer dem Passwort einen Code, den eine App auf dem Diensthandy des Sachbearbeiters erzeugt. Diesen Code hat der Angreifer nicht, und die „Anmeldung“ lehnt den Anmeldeversuch ab. Das ist Schutzschicht 1. Angenommen, der Angreifer gelangt über einen noch unbekannten Fehler in der „Anmeldung“ doch in das Konto des Sachbearbeiters. In der Schadenanwendung versucht der Angreifer, für einen Schaden in einer fremden Region 50.000 Euro freizugeben. Die Schadenanwendung prüft jede Aktion gegen die Rechte des Kontos. Dieser Sachbearbeiter darf nur Schäden seiner eigenen Region und nur bis 10.000 Euro freigeben. Die Grenze reicht für die meisten Schäden seiner Region und verhindert, dass ein einzelnes Konto große Summen freigeben kann. Deshalb lehnt die Schadenanwendung die Freigabe ab. Das ist Schutzschicht 2. Stattdessen ruft der Angreifer in kurzer Zeit Hunderte Kundenakten ab, die er mit den Rechten des Kontos lesen darf. Die Schadenanwendung protokolliert jeden Abruf. Die „Überwachung“ ist ein eigener Dienst, der die Protokolle mit festgelegten Regeln vergleicht. Ist eine Regel für ungewöhnlich viele Abrufe eingerichtet, meldet die „Überwachung“ dem Betriebsteam der Versicherung einen Verdacht. Das ist Schutzschicht 3. Das Betriebsteam reagiert nach einem eingeübten Ablauf. Es sperrt zum Beispiel das Konto und untersucht den Zugriff.

Weil jede einzelne Schutzmaßnahme Lücken hat, legt die Versicherung Schutzschichten in mehreren Bereichen an:

  • Netz: Firewalls sind Programme oder Geräte, die nur festgelegten Netzverkehr durchlassen. Die Schadenanwendung steht in einem getrennten Netzbereich, den niemand direkt aus dem Internet erreicht. Erlaubten Verkehr lässt eine Firewall allerdings durch, auch wenn darin ein Angriff steckt.
  • Zugang: Die „Anmeldung“ verlangt einen zweiten Faktor. Das ist ein zusätzlicher Nachweis neben dem Passwort, bei der Versicherung der Code vom Diensthandy. Das Passwort allein genügt nicht, weil es über eine gefälschte Anmeldeseite abgefangen werden kann.
  • Anwendung: Jeder Sachbearbeiter hat in der Schadenanwendung ein eigenes Konto mit eigenen Rechten. Die Schadenanwendung prüft außer den Rechten auch jede Eingabe, etwa ob in einem Textfeld Datenbankbefehle versteckt sind.
  • Daten: Die Daten werden beim Speichern und beim Übertragen verschlüsselt. Stiehlt ein Angreifer gespeicherte Dateien, bleiben die Dateien unlesbar, solange er den Schlüssel nicht mit erbeutet. Kundenakten, die der Angreifer über die Schadenanwendung abruft, sieht er dagegen unverschlüsselt.
  • Erkennung: Protokolle halten jeden Zugriff fest, und automatische Warnungen melden auffälliges Verhalten, etwa Hunderte Aktenabrufe eines Kontos in kurzer Zeit.
  • Reaktion: Für den Fall, dass ein Angriff gelingt, gibt es Notfallpläne, Datensicherungen und eingeübte Abläufe.

Neben Technik gehören auch Menschen und Abläufe zu den Schutzschichten, weil sich Angriffe nicht nur gegen die Technik richten, sondern auch gegen die Menschen, die die Schadenanwendung bedienen. Ein Beispiel sind Schulungen, in denen Mitarbeitende gefälschte E-Mails erkennen lernen. Weil jede Software einen Fehler enthalten kann, den noch niemand kennt, beruhen die Schutzschichten auf verschiedenen Techniken: Hängen zwei Schutzschichten am selben Programm, setzt ein einziger Fehler in diesem Programm beide außer Kraft. Für Netz, „Anmeldung“, Schadenanwendung und „Überwachung“ sind oft verschiedene Teams mit verschiedenen Werkzeugen zuständig.

Defense in Depth: mehrere Schutzschichten halten einen Angreifer auf

Beteiligte: Angreifer: hat das Passwort eines Sachbearbeiters erbeutet; Anmeldung: verlangt Passwort und Code vom Diensthandy; Schadenanwendung: prüft jede Aktion gegen die Rechte des Kontos; Überwachung: erkennt auffälliges Verhalten; Betriebsteam: reagiert auf Warnungen. Ablauf: 1. Der Angreifer versucht, sich mit dem erbeuteten Passwort eines Sachbearbeiters an der Schadenanwendung anzumelden. 2. Die „Anmeldung“ lehnt den Anmeldeversuch ab, weil der Code aus der App auf dem Diensthandy fehlt. 3. Angenommen, der Angreifer gelangt doch in das Konto. In der Schadenanwendung versucht er, für einen Schaden in einer fremden Region 50.000 Euro freizugeben. 4. Die Schadenanwendung prüft die Rechte des Kontos: Der Sachbearbeiter darf nur Schäden seiner eigenen Region und nur bis 10.000 Euro freigeben. Deshalb lehnt die Schadenanwendung die Freigabe ab. 5. Stattdessen ruft der Angreifer in kurzer Zeit Hunderte Kundenakten ab, die er mit den Rechten des Kontos lesen darf. 6. Die Schadenanwendung protokolliert jeden Abruf. 7. Ist eine Regel für ungewöhnlich viele Abrufe eingerichtet, meldet die „Überwachung“ dem Betriebsteam einen Verdacht.

Wann ist es sinnvoll und wann nicht?

Defense in Depth lohnt sich

  • Ein System enthält schützenswerte Daten wie die Kundenakten der Schadenanwendung. In regulierten Branchen wie Versicherungen und Banken erwarten die Aufsichtsbehörden diesen Ansatz. Ohne gestaffelte Verteidigung schützt oft nur eine einzige Maßnahme diese Daten, und versagt diese Maßnahme, liegen alle Kundenakten offen.
  • Ein System ist aus dem Internet erreichbar. Dann kann jeder, der seine Adresse kennt, Angriffe versuchen. Ohne gestaffelte Verteidigung genügt ein einziger Fehler in der „Anmeldung“, und jeder dieser Angreifer gelangt an die Kundenakten.
  • Ein einzelner Fehler würde sonst Zugriff auf Kundendaten oder Zahlungen geben. Ein Beispiel ist das erbeutete Passwort. Verlässt sich die Versicherung nur auf das Passwort, kann der Angreifer alles tun, was der Sachbearbeiter darf, und niemand bemerkt es.

Defense in Depth ist nicht das Richtige

  • Ein internes Werkzeug enthält keine vertraulichen Daten. Ein Beispiel ist ein Programm zum Buchen von Besprechungsräumen. Gelangt ein Angreifer in dieses Werkzeug, findet er dort keine Kundendaten und kann keine Zahlungen freigeben. Die Versicherung betreibt das Werkzeug deshalb nur in einem getrennten Netzbereich, den niemand aus dem Internet erreicht. Zweiter Faktor, eigene Rechte je Konto und „Überwachung“ entfallen für dieses Werkzeug, ebenso ihre Einrichtung und Pflege. Lässt die Firewall des getrennten Netzbereichs durch einen Fehler doch Zugriffe aus dem Internet zu, ist das Werkzeug allerdings ungeschützt.
  • Eine bekannte Sicherheitslücke in der Schadenanwendung ist noch offen. Eine weitere Schutzschicht würde die Gefahr nur verringern, etwa eine Firewall, die Anfragen mit dem bekannten Angriffsmuster abweist, bevor sie die Schadenanwendung erreichen. Stattdessen schließt das Team, das die Schadenanwendung betreut, die Lücke mit einem Update. Eine geschlossene Lücke kann kein Angreifer mehr ausnutzen.
  • Eine zusätzliche Schutzschicht würde nur dieselbe Technik wiederholen. Ein Beispiel ist eine zweite Firewall desselben Herstellers mit denselben Regeln. Die zweite Firewall bringt zusätzlichen Aufwand, fängt aber keinen Fehler der ersten auf. Dann setzt die Versicherung die zusätzliche Schutzschicht in einem anderen Bereich an, etwa mit eigenen Rechten je Konto in der Schadenanwendung. Die zweite Firewall und ihre Pflege entfallen.

Nachteile und typische Fehler

Jede Schutzschicht kostet Geld, bringt Betriebsaufwand und verlangt von den Nutzern oft einen zusätzlichen Schritt. Ein Beispiel ist der Code vom Diensthandy bei jedem Anmelden. Schutzschichten, die auf verschiedenen Techniken beruhen, bedeuten mehr Produkte, mehr Fachwissen und mehr Pflege. Die Regeln der „Überwachung“ müssen eingerichtet und laufend angepasst werden, damit die „Überwachung“ auffälliges Verhalten meldet, ohne das Betriebsteam mit Fehlalarmen zu überschwemmen. Ob die Schutzschichten tatsächlich schützen, muss regelmäßig geprüft werden, und auch das braucht Zeit. Auch alle Schutzschichten zusammen machen das System nicht unangreifbar.

Typische Fehler und woran man sie erkennt:

  • Umgangene Hürden: Zu viele Schutzmaßnahmen, die die Nutzer bei der Arbeit aufhalten, verleiten die Nutzer dazu, diese Maßnahmen zu umgehen. Die Nutzer teilen zum Beispiel Konten oder notieren Passwörter auf Zetteln. Erkennbar ist das daran, dass sich dasselbe Konto von mehreren Arbeitsplätzen gleichzeitig anmeldet.
  • Ungeprüfte Schutzschichten: Niemand prüft regelmäßig, ob die Schutzschichten tatsächlich funktionieren, und weil es viele Schutzschichten gibt, hält das Betriebsteam die Schadenanwendung für sicher. Erkennbar ist das an einem Angriffsversuch, den die Versicherung zur Probe in Auftrag gibt und bei dem eine Schutzschicht nichts abwehrt.
  • Gemeinsamer Ausfall: Zwei Schutzschichten beruhen doch auf derselben Technik und fallen gemeinsam aus. Die „Anmeldung“ und die Rechteprüfung der Schadenanwendung nutzen zum Beispiel dieselbe Programmbibliothek. Ein Fehler in dieser Programmbibliothek lässt den Angreifer dann ohne Code vom Diensthandy in das Konto und hebt zugleich die Grenze von 10.000 Euro auf. Erkennbar ist das an einer einzigen Sicherheitslücke, die mehrere Schutzschichten zugleich außer Kraft setzt.
  • Fehlende Regel: Die „Überwachung“ erhält die Protokolle, aber keine Regel meldet ungewöhnlich viele Aktenabrufe. Der Angreifer kann Kundenakten unbemerkt abrufen. Erkennbar ist das an Hunderten Abrufen eines Kontos im Protokoll ohne zugehörige Warnung.

Weiterführend

Verwandte Ansätze

  • Zero Trust: prüft jeden Zugriff einzeln, auch wenn er aus dem eigenen Firmennetz kommt, statt dem internen Netz pauschal zu vertrauen. Zero Trust lässt sich als weitere Schutzschicht im Bereich Zugang in die gestaffelte Verteidigung einbauen.
  • Least Privilege: der Grundsatz, jedem Konto nur die nötigsten Rechte zu geben. Least Privilege begrenzt den Schaden, wenn ein Angreifer eine Schutzschicht überwunden hat.
  • Encryption: beschreibt die Verschlüsselung, die Schutzschicht für die Daten.
  • Audit Logging: beschreibt das geschützte Festhalten sicherheitsrelevanter Handlungen, eine Schutzschicht für Erkennung und Nachweis.

Werkzeuge und Umsetzungen

Jede Schutzschicht beruht auf eigenen Werkzeugen. Beispiele für Werkzeuge einzelner Schutzschichten:

  • Coraza: Firewall für Webanwendungen, die typische Angriffsmuster in Anfragen erkennt und abweist.
  • Suricata: erkennt Angriffe im Netzverkehr.
  • Falco: erkennt verdächtiges Verhalten von Programmen im laufenden Betrieb, auch in Containern, also in abgeschlossenen Paketen aus einem Programm und allem, was es zum Laufen braucht.
  • Keycloak: Anmeldedienst, der unter anderem einen zweiten Faktor beim Anmelden verlangen kann.
  • Wazuh: sammelt Sicherheitsmeldungen vieler Systeme zentral und meldet Auffälligkeiten.

Quellen

  • NIST: Glossary, defense-in-depth: Begriffsbestimmungen der US-Normungsbehörde, unter anderem aus NIST SP 800-53, die Defense in Depth als Zusammenspiel von Menschen, Technik und Abläufen über mehrere Schichten beschreiben und verschiedenartige Techniken verlangen, damit ein Angriff, den eine Technik übersieht, von einer anderen erkannt wird.
  • AWS: Well-Architected Framework, Security design principles: verlangt Schutzmaßnahmen auf allen Ebenen vom Netz bis zum Code und ergänzt Nachvollziehbarkeit durch Protokolle und die Vorbereitung auf Sicherheitsvorfälle.