Die meisten Architekturen fallen im Ernstfall

NIS2 wirkt im Finanzsektor wie ein technischer Stresstest für bestehende Sicherheits­architekturen. Die Richtlinie bewertet die Fähigkeit von Systemen, Kompromittierungen zu erkennen, privilegierte Zugriffe zu begrenzen und laterale Bewegung einzudämmen. Sicherheitsarchitektur entscheidet im Angriff darüber, ob Systeme Kontrolle behalten oder verlieren.

von Okay Güler, Cloudyrion

Viele Institute betreiben gewachsene Umgebungen: zentrales Active Directory ohne sauberes Tiering, administrative Konten auf Standard-Workstations, Service-Accounts mit dauerhaften Rechten und Netzwerke mit breitem Ost‑West‑Traffic.

Ein praktisches Beispiel zeigt die Konsequenz. Ein Dienstleisterkonto wird kompromittiert. Angreifer extrahieren Credentials aus dem Speicher des Local Security Authority Subsystem Service (LSASS) und nutzen Pass‑the‑Hash oder Pass‑the‑Ticket, um sich gegenüber weiteren Systemen zu authentifizieren, ohne die Zugangsdaten zu kennen. So bewegen sie sich lateral im Netzwerk und übernehmen schrittweise privilegierte Konten.

Über SMB, RDP und WinRM bewegen sie sich zwischen Systemen. Offene interne Kommunikationspfade ermöglicht gezielte Sprünge. Da Backup-Systeme im gleichen Identitätskontext betrieben werden, erreichen Angreifer Sicherungs­infra­strukturen und können so Shadow Copies oder Backup-Kataloge manipulieren.

Die Schadensphase beginnt bereits mit der Kompromittierung des Dienstleisterkontos.“

Die nachfolgende Ausbreitung und Manipulation von Systemen zeigt, dass diese Angriffskette aus konkreten Architektur­entscheidungen entsteht.

Mapping NIS2 mit DORA, ISO 27001, BAIT und VAIT

In der Praxis wirken im Finanzsektor mehrere regulatorische Anforderungen gleichzeitig auf dieselben technischen Systeme. NIS2, DORA, ISO 27001 sowie BAIT und VAIT adressieren dabei identische Domänen wie Identitäten, Logging, Incident Management, Lieferketten und Resilienz. Unterschiede liegen in Granularität, Klassifikation und Fristen. NIS2 verlangt operative Wirksamkeit und strukturierte Meldungen, DORA definiert enge Zeitfenster, ISO 27001 liefert ein Rahmenwerk, BAIT und VAIT konkretisieren Anforderungen für Finanzinstitute.

In der Praxis entstehen parallele Modelle. Teams pflegen mehrere Asset‑Inventare, nutzen unterschiedliche Severity‑Skalen und betreiben getrennte Reporting‑Flows. Zwischen Detection und Meldung entsteht Reibungsverlust.

Eine tragfähige Mapping‑Logik integriert diese Anforderungen technisch. Ein zentrales Asset‑Inventare dient als Referenz. Identitäten verknüpfen Zugriffe mit konkreten Akteuren und machen Ereignisse dadurch im SIEM eindeutig zuordenbar und bewertbar. Event‑Normalisierung im SIEM erzeugt eine einheitliche Klassifikation über regulatorische Anforderungen hinweg. APIs überführen Incidents direkt in Ticketing- und Meldeprozesse.

Technische Fallstricke in der Umsetzung

Die Wirksamkeit entsteht aus konkreten Designentscheidungen. Im Identity‑Layer führen fehlendes AD‑Tiering und fehlende Privileged Access Workstations dazu, dass Admin‑Konten auf Clients genutzt werden.

Ein kompromittierter Endpoint eröffnet direkten Zugriff auf Tier‑0‑Ressourcen, wenn administrative Konten auf Clients genutzt werden.“

Diese Konten gehören ausschließlich auf isolierte Admin-Systeme, während Service‑Accounts mit SPNs und Delegation die Angriffsfläche zusätzlich erweitern. Privilegierte Rechte entstehen dabei gezielt und zeitlich begrenzt.

Auch im Netzwerk zeigt sich die Wirkung von Architektur­entscheidungen. Segmentierung bleibt häufig auf VLANs beschränkt, während interner Datenverkehr ohne Durchsetzung auf Host-Ebene und ohne Identity-basierte Kontrollen fließt. Typische Admin-Protokolle in Windows-Umgebungen wie SMB, RDP und WinRM benötigen klare zonenbasierte Einschränkungen, da Angreifer sonst wiederverwendete Tokens nutzen und sich gezielt zwischen Systemen bewegen.

Bei Backups entscheidet die Architektur über die Wieder­herstellungs­fähigkeit. Eine eigene Identitätsdomäne und unveränderbare Speichermechanismen sichern die Integrität, während fehlende Trennung es Angreifern ermöglicht, Snapshot-Ketten und Recovery-Pfade gezielt zu manipulieren.

In der Detection entsteht Wirkung durch Kontext. SIEM korreliert Logon‑Events, Privilegänderungen und Endpoint‑Telemetrie und priorisiert nach Asset-Kritikalität. So werden Angriffsmuster und Reichweite sichtbar.

Hybride Umgebungen erzeugen zusätzliche Pfade. Federation-Strukturen erfordern Transparenz, privilegierte Cloud-Rollen bleiben strikt begrenzt. So bleibt der Wechsel zwischen On‑Prem und Cloud kontrolliert.

Nachweisbarkeit im Betrieb

Nachweisbarkeit entsteht im Betrieb durch konsistente Daten und klare Zuordnung von Verantwortung. Kennzahlen wie Mean Time to Detect (MTTD) und Mean Time to Respond (MTTR) zeigen, wie schnell Systeme auf Vorfälle reagieren. Durchgängige Audit-Trails machen Zugriffe und Änderungen nachvollziehbar und bilden die Grundlage für regulatorische Bewertungen.

Gleichzeitig sorgt klare Ownership für Systeme und Controls dafür, dass Maßnahmen umgesetzt und Entscheidungen belastbar getroffen werden. Einheitliche Datenmodelle verbinden Detection, Bewertung und Meldung und ermöglichen eine konsistente Klassifikation sowie fristgerechte Kommunikation von Vorfällen.

Operative Resilienz als Ergebnis von Architektur­entscheidungen

Die Eingangsthese bestätigt sich im Betrieb: Sicherheitsarchitektur entscheidet, wie Systeme reagieren, wenn sie angegriffen werden. NIS2 macht diese Fähigkeit messbar. In den kommenden Jahren bestimmen durchgängige Telemetrie, integrierte Datenmodelle und automatisierte Reaktionen die Geschwindigkeit von Eindämmung und Wiederherstellung. Systeme mit klarer Architektur behalten Kontrolle über Identitäten, Zugriffe und Ausbreitung – genau daran entscheidet sich Resilienz im Finanzsektor.

Okay Güler, Cloudyrion