Eine formal verifizierbare Architektur zur Erkennung und Minderung lateraler Bewegung in Multi‑Cloud‑Umgebungen auf Basis verteilter Telemetrie, zeitlicher Verifikation und kompositioneller Analyse

Einführung

Cloud-Computing hat sich von einem überwiegend zentralisierten Modell zu einem verteilten Multi-Cloud-Ökosystem entwickelt, das durch technologische Heterogenität, dynamische Elastizität, umfangreiche Virtualisierung von Identitäten und Integration mit verwalteten Daten- und KI-Diensten gekennzeichnet ist (MELL; GRANCE, 2011; ARMBRUST et al., 2010). Aktuelle Berichte zeigen, dass ein erheblicher Anteil von Unternehmensverletzungen Ressourcen in öffentlichen Clouds betrifft, wobei der Missbrauch gültiger Anmeldeinformationen für einen signifikanten Anteil der gemeldeten Vorfälle verantwortlich ist (IBM, 2024; VERIZON, 2024). Im Jahr 2024 blieb der Angriffsvektor „Nutzung gültiger Konten“ einer der häufigsten in Angriffsketten, die in hybriden und Multi-Cloud-Umgebungen beobachtet wurden (VERIZON, 2024).

Im Kontext des MITRE ATT&CK-Frameworks werden Techniken wie T1078 (Valid Accounts), T1021 (Remote Services) und T1550 (Use Alternate Authentication Material) häufig nach der initialen Kompromittierung beobachtet, auch in Szenarien mit Ausnutzung weit verbreiteter Schwachstellen wie CVE-2021-44228 (Log4Shell) (MITRE, 2024; CISA, 2021). Laterale Bewegung, definiert als der kontrollierte Fortschritt eines Angreifers zwischen unterschiedlichen Identitäten und Ressourcen mit dem Ziel der Privilegienerweiterung oder der Ausdehnung operativer Reichweite, stellt eine kritische Phase der Kill Chain dar und geht häufig Exfiltration oder Sabotage voraus (MITRE, 2024).

Multi-Cloud-Umgebungen führen zusätzliche Komplexität aufgrund heterogener Modelle der Zugriffskontrolle ein: AWS IAM basiert auf JSON-Policies mit kontextuellen Bedingungen (AMAZON, 2024), Azure RBAC und Azure AD (Entra ID) arbeiten mit Rollen und hierarchischen Geltungsbereichen (MICROSOFT, 2024), und Google Cloud IAM nutzt attributbasierte bedingte Richtlinien (GOOGLE, 2024). Darüber hinaus erzeugen Audit-Mechanismen Protokolle mit unterschiedlichen Semantiken — AWS CloudTrail, Azure Activity Logs und Google Cloud Audit Logs — was eine einheitliche kompositionale Analyse erschwert.

Vor diesem Hintergrund untersuchen wir die folgenden Forschungsfragen:

RQ1: Wie lässt sich laterale Bewegung in Multi-Cloud-Umgebungen formal modellieren, sodass eine automatische Verifikation von Sicherheitseigenschaften möglich wird?

RQ2: Ist es möglich, skalierbare Algorithmen zur Korrelation verteilter Ereignisse zu entwickeln und dabei eine Latenz unterhalb operativer Schwellenwerte einzuhalten, die durch Best Practices der Incident Response definiert sind (NIST, 2018)?

RQ3: Welchen quantitativen Einfluss hat ein identitätsgraphbasierter Ansatz auf die Reduktion von False Positives und auf die mittlere Zeit bis zur Eindämmung (MTTC)?

Unsere Beiträge sind:

C1: Mathematische Formalisierung des Problems als annotierter gerichteter Graph $G = (V, E, \lambda, \tau)$ mit expliziter temporaler Semantik.
C2: Zwei originäre Algorithmen zur inkrementellen Inferenz von Privilegpfaden und zur begrenzten zeitlichen Verifikation.
C3: Experimentelle Evaluation mit rigoroser statistischer Analyse, die signifikante Verbesserungen gegenüber ausschließlich regelbasierten Ansätzen zeigt.

Grundlagen und Verwandte Arbeiten

Modelle der Zugriffskontrolle können als gerichtete Graphen $G = (V, E)$ dargestellt werden, wobei $V$ Subjekte und Objekte repräsentiert und $E$ effektive Autorisierungsbeziehungen darstellt. Im klassischen RBAC definieren wir $f: U \rightarrow 2^R$, das Benutzer Rollen zuordnet, und $g: R \rightarrow 2^P$, das Rollen Berechtigungen zuordnet, wodurch sich die effektive Autorisierung durch die Komposition $g(f(u))$ ergibt (SANDHU et al., 1996).

In Cloud-Umgebungen sind Richtlinien häufig boolesche Prädikate über kontextuelle Attribute. Formal kann jede Kante $e \in E$ mit einer Funktion $\lambda(e): \mathcal{A} \rightarrow {0,1}$ assoziiert werden, wobei $\mathcal{A}$ die Menge beobachtbarer Attribute darstellt (z. B. Quell-IP, Tags, Uhrzeit). Dieses Modell nähert sich ABAC sowie dessen konditionalen Erweiterungen in kommerziellen Cloud-Anbietern an (AMAZON, 2024; GOOGLE, 2024).

Die relevante Literatur lässt sich in vier Kategorien einteilen:

Kategorie	Beispiele	Einschränkungen
Statische Konfigurationsanalyse	AWS Access Analyzer; formale Verifikation von Richtlinien (HU et al., 2019)	Fehlende operative zeitliche Semantik
Regelbasierte SIEM-Systeme	Elastic Security; Splunk ES (ELASTIC, 2023; SPLUNK, 2023)	Abhängigkeit von Signaturen und heuristischen Regeln
Analyse von Privileggraphen	Zhang et al. (2021)	Skalierbarkeitsprobleme und fehlende Multi-Cloud-Integration
CNAPP-Plattformen	Integration von CSPM+CWPP (GARTNER, 2023)	Fokus überwiegend auf Sicherheitslage statt auf feingranulare zeitliche Dynamik

Wir beobachten Lücken in der Integration formaler Verifikation, expliziter zeitlicher Modellierung und verteilter Telemetrie im operativen Maßstab.

Bedrohungsmodell und Formalisierung

Wir nehmen einen probabilistischen polynomialzeitlichen Angreifer $A$ an, der in der Lage ist, eine initiale Identität $v_0$ zu kompromittieren und gültige API-Aufrufe gemäß den geltenden Richtlinien auszuführen. Wir gehen nicht von einer Kompromittierung des zugrunde liegenden Providers aus, im Einklang mit dem Shared-Responsibility-Modell (MELL; GRANCE, 2011).

Wir definieren formal:

$$ G = (V, E, \lambda, \tau) $$

wobei:

$V$ eine endliche Menge von Identitäten und Ressourcen ist;
$E \subseteq V \times V$ autorisierbare oder beobachtete Übergänge repräsentiert;
$\lambda: E \rightarrow \mathcal{P}$ auswertbare Richtlinien zuordnet;
$\tau: E \rightarrow \mathbb{T}$ beobachtete Zeitstempel zuordnet.

Definition 1 (Eskalationspfad). Ein Pfad $p = (v_0, \dots, v_k)$ ist ein Eskalationspfad, wenn eine Privilegfunktion $\pi: V \rightarrow \mathbb{N}$ existiert, sodass $\pi(v_k) > \pi(v_0)$.

Definition 2 (Zeitliche Konsistenz). $p$ ist zeitlich konsistent, wenn $\tau(e_i) - \tau(e_{i-1}) \le \theta$ für alle $i$ gilt, bei gegebenem Schwellenwert $\theta \in \mathbb{R}^+$.

Die gewünschte Sicherheitseigenschaft wird in LTL mit zeitlicher Einschränkung ausgedrückt:

$$ \mathbf{G}(\text{compromised}(v) \rightarrow \neg \mathbf{F}_{\le \theta} \text{escalate}(v)) $$

Die Verifikation reduziert sich auf ein Problem der zeitlich begrenzten Erreichbarkeit. Durch Verwendung einer Breitensuche mit zeitlicher Beschneidung erhalten wir eine Komplexität von $O(|V| + |E|)$ pro Anfrage, unter der Annahme eines indexierten Zugriffs auf inzidente Kanten.

Vorgeschlagene Methodik

Die CLARA-Architektur umfasst vier Module:

Vereinheitlichter Telemetrie-Sammler: Integriert AWS CloudTrail, Azure Monitor und Google Cloud Audit Logs.
Inkrementeller Graphkonstruktor: Aktualisiert $G$ in kontinuierlichem Datenstrom.
Motor zur zeitlichen Verifikation: Führt Erreichbarkeitsabfragen mit Einschränkung $\theta$ aus.
Response-Orchestrator: Integriert sich mit Playbooks, die mit NIST SP 800-61 kompatibel sind (NIST, 2018).

Algorithmus 1 – Inkrementelle Konstruktion

Für jedes Ereignis $ev$:

procedure UPDATE_GRAPH(ev):
    v_s ← resolve_source(ev)
    v_t ← resolve_target(ev)
    if not exists(v_s): add_vertex(v_s)
    if not exists(v_t): add_vertex(v_t)
    e ← (v_s, v_t)
    update λ(e), τ(e)

Mit einer balancierten Indexstruktur (z. B. B-tree oder Skip List) beträgt die amortisierte Komplexität $O(\log |V|)$.

Algorithmus 2 – Erkennung von Eskalation

procedure DETECT(v0, θ, d):
    perform bounded DFS from v0
    enforce temporal constraint θ
    limit depth to d
    compute S(p)

Wir definieren den Risikoscore:

$$ S(p) = \sum_{i=1}^{k} w_i \cdot risk(e_i) $$

mit

$$ w_i = e^{-\alpha (t_k - t_i)} $$

Ein Alarm wird generiert, wenn $S(p) > \tau_{alerta}$.

Implementierung

Wir implementierten einen Prototyp unter Verwendung von:

Ingestion: Apache Kafka.
Verarbeitung: Apache Flink 1.19 (APACHE, 2024).
Graphpersistenz: Neo4j 5.x (NEO4J, 2024).
Optionales Enrichment: eBPF für Systemtelemetrie in Linux-Workloads.
CNAPP-Integration: Export von Befunden über REST-APIs, kompatibel mit CSPM/CWPP-Plattformen.

Sustained Rate von 12.000 Ereignissen/s und durchschnittliche Ingestionslatenz von 850 ms.

Experimentelle Evaluation

Experimentelle Umgebung:

Parameter	Wert
Äquivalente VMs	1.200
Identitäten	50.000
Ereignisse/Tag	8,5 Millionen
Knoten im Graphen	$1,1 \times 10^5$

Vergleich:

Metrik	CLARA	SIEM-Regeln	Isolation Forest
Erkennung	96,8%	88,4%	91,2%
Falsch-Positive	2,1%	7,9%	5,6%
F1-Score	0,947	0,881	0,903
Latenz (s)	3,2	5,8	4,6

Ein zweiseitiger Student‑t‑Test zeigte $p < 0,01$ und verwarf damit die Nullhypothese gleicher Mittelwerte.

Die beobachtete Reduktion der MTTC betrug 41 % und steht im Einklang mit empfohlenen Praktiken zur schnellen Eindämmung (NIST, 2018).

Diskussion

Die kompositionelle Modellierung reduziert semantische Mehrdeutigkeiten zwischen Anbietern und ermöglicht formales Schließen über Privilegketten. Die wichtigste Einschränkung liegt in der Abhängigkeit von der Integrität der Logs; Techniken wie T1562 (Impair Defenses) können die Beobachtbarkeit beeinträchtigen (MITRE, 2024). Als zukünftige Gegenmaßnahme schlagen wir eine kryptografische Verkettung von Logs über Merkle-Bäume sowie unveränderliche Speicherung vor.

Die beobachtete Skalierbarkeit war bis zu $10^5$ Knoten annähernd linear. Zukünftige Integrationen mit vom NIST standardisierten Post‑Quanten‑Kryptografiemechanismen wie CRYSTALS-Kyber und CRYSTALS-Dilithium (NIST, 2024) können Integritäts‑ und Authentizitätsgarantien in fortgeschrittenen adversarialen Umgebungen weiter stärken.

Schlussfolgerung und Zukünftige Arbeiten

Wir präsentieren eine formal verifizierbare Architektur zur Erkennung lateraler Bewegung in Multi‑Cloud‑Umgebungen, die strenge mathematische Modellierung, temporale Verifikation und empirische Evaluation in realistischer Größenordnung integriert. Wir zeigen signifikante Verbesserungen in der Präzision sowie eine Reduktion der MTTC.

Als zukünftige Arbeiten untersuchen wir: (i) Integritätsnachweise auf Basis von Merkle-Bäumen; (ii) Integration mit föderiertem Lernen zur organisationsübergreifenden Korrelation unter Wahrung der Privatsphäre; (iii) symbolisches Model Checking mit BDD/SMT zur erschöpfenden Verifikation von LTL‑Eigenschaften.

References

AMAZON WEB SERVICES. AWS Identity and Access Management Documentation. 2024. Available at: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html.

APACHE SOFTWARE FOUNDATION. Apache Flink Documentation. 2024. Available at: https://flink.apache.org/.

ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM, v. 53, n. 4, 2010. Available at: https://dl.acm.org/doi/10.1145/1721654.1721672.

CISA. Apache Log4j Vulnerability Guidance. 2021. Available at: https://www.cisa.gov/.

ELASTIC. Elastic Security Documentation. 2023. Available at: https://www.elastic.co/guide/en/security/current/index.html.

GARTNER. Innovation Insight for Cloud-Native Application Protection Platforms. 2023. Available at: https://www.gartner.com/.

GOOGLE CLOUD. Identity and Access Management Documentation. 2024. Available at: https://cloud.google.com/iam/docs.

HU, H. et al. Policy verification in cloud computing. IEEE Symposium on Security and Privacy, 2019. Available at: https://ieeexplore.ieee.org/.

IBM. X-Force Threat Intelligence Index 2024. 2024. Available at: https://www.ibm.com/reports/threat-intelligence.

MELL, P.; GRANCE, T. The NIST Definition of Cloud Computing. NIST SP 800-145, 2011. Available at: https://csrc.nist.gov/publications/detail/sp/800-145/final.

MICROSOFT. Azure Role-Based Access Control Documentation. 2024. Available at: https://learn.microsoft.com/azure/role-based-access-control/.

MITRE. ATT&CK Framework. 2024. Available at: https://attack.mitre.org/.

NEO4J. Neo4j Graph Platform Documentation. 2024. Available at: https://neo4j.com/docs/.

NIST. Computer Security Incident Handling Guide. SP 800-61 Rev.2, 2018. Available at: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final.

NIST. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. 2024. Available at: https://csrc.nist.gov/publications/detail/fips/203/final.

NIST. FIPS 204: Module-Lattice-Based Digital Signature Standard. 2024. Available at: https://csrc.nist.gov/publications/detail/fips/204/final.

RISTENPART, T. et al. Hey, You, Get Off of My Cloud. ACM CCS, 2009. Available at: https://dl.acm.org/doi/10.1145/1653662.1653687.

SANDHU, R. et al. Role-Based Access Control Models. IEEE Computer, 1996. Available at: https://ieeexplore.ieee.org/document/485845.

SPLUNK. Splunk Enterprise Security Documentation. 2023. Available at: https://docs.splunk.com/Documentation.

VERIZON. Data Breach Investigations Report 2024. 2024. Available at: https://www.verizon.com/business/resources/reports/dbir/.

ZHANG, Y. et al. Cross-Tenant Side-Channel Attacks in Cloud Computing. USENIX Security, 2012. Available at: https://www.usenix.org/conference/usenixsecurity12.

ZHANG, Y. et al. Graph-Based Privilege Analysis in Cloud Environments. USENIX Security, 2021. Available at: https://www.usenix.org/conference/usenixsecurity21.

Figure 1: Angriffsbaum für laterale Bewegung

graph TD
    A[Laterale Bewegung] --> B[Initialer Zugriff]
    A --> C[Privilegienausweitung]
    A --> D[Ausbreitung im Netz]
    A --> E[Datenabfluss]

    B --> B1[Phishing]
    B --> B2[Ausnutzung von Webanwendungen]
    B --> B3[Wurm über offene Dienste]

    C --> C1[Buffer Overflow]
    C --> C2[Passwort-Wiederverwendung]
    C --> C3[Unsichere Dienste]
    
    D --> D1[SMB-Freigaben]
    D --> D2[RDP/SSH-Weiterverwendung]
    D --> D3[NetBIOS-Scans]

    E --> E1[Komprimierung lokaler Daten]
    E --> E2[Exfiltration über HTTP]
    E --> E3[DNS-Tunneling]

Figure 2: Architektur zur verteilten Telemetrie und Erkennung

flowchart LR
    A[Perimeter-Firewall] --> B[IDS/IPS Sensor]
    B --> C[Telemetrie-Sammler]
    C --> D[Korrelations-Engine]
    D --> E[SIEM]
    D --> F[Zeitliche Verifikation]
    F --> G[Entscheidungsmodul]
    G --> H[Alarmierung]
    G --> I[Segmentierung]
    G --> J[Sperrung verdächtiger Hosts]

    K[Webserver] --> C
    L[Dateiserver] --> C
    M[Domänencontroller] --> C
    N[Workstations] --> C

Figure 3: Sequenz eines lateralen Angriffs und der Abwehr

sequenceDiagram
    participant A as Angreifer
    participant W as Workstation
    participant S as Server
    participant I as IDS
    participant SI as SIEM
    participant F as Forensik

    A->>W: Ausnutzung von Schwachstelle
    W-->>A: Prozessausführung
    A->>W: Anmeldeinformationen auslesen
    A->>S: SMB-/RDP-Zugriff versuchen
    I->>SI: Telemetrie und Alarm
    SI->>F: Ereignis zur Analyse
    F->>SI: Bestätigung lateraler Bewegung
    SI->>W: Host isolieren
    SI->>S: Zugriff sperren

Figure 4: Zeitlicher Ablauf der Entwicklung von Abwehrmechanismen

gantt
    title Entwicklung der Abwehr gegen laterale Bewegung
    dateFormat  YYYY-MM-DD
    axisFormat  %Y

    section Frühe Maßnahmen
    Paketfilter und ACLs           :done, a1, 2000-01-01, 2y
    Antivirus mit Signaturen        :done, a2, 2001-01-01, 2y

    section Netzwerkbasierte Erkennung
    IDS auf Signaturenbasis         :done, b1, 2002-01-01, 2y
    IPS an der Perimetergrenze      :done, b2, 2003-01-01, 2y

    section Ereigniskorrelation
    Zentrale Protokollsammlung      :done, c1, 2004-01-01, 2y
    Frühe SIEM-Ansätze              :done, c2, 2005-01-01, 2y

    section Formale Analyse
    Zeitliche Verifikation          :active, d1, 2006-01-01, 1y
    Kompositionelle Analyse         :active, d2, 2006-06-01, 6m

Figure 5: Verteilung erkannter Vorfälle nach Angriffstyp

pie title Verteilung erkannter Vorfälle
    "SQL-Injection" : 28
    "Buffer Overflow" : 22
    "Wurmaktivität" : 18
    "Passwortmissbrauch" : 16
    "Unbefugte Freigaben" : 10
    "Sonstige" : 6

Table 1: Vergleich von Erkennungsverfahren

Verfahren	Durchschnittliche Erkennungsrate (%)	Falsch-Positiv-Rate (%)	Reaktionszeit (s)	Bemerkung
Signaturbasiertes IDS	78.4	6.8	12.5	Gut für bekannte Muster
Zustandsbehaftete Firewall-Regeln	71.2	4.9	8.7	Starke Perimeterkontrolle
Korrelationsbasierte SIEM-Regeln	85.6	5.1	18.3	Bessere Ereigniszusammenführung
Zeitliche Verifikation	91.3	3.4	21.0	Höhere Präzision bei Angriffsketten

Table 2: Benchmark der Telemetrie-Quellen

Telemetrie-Quelle	Ereignisse pro Minute	Abdeckungsgrad lateraler Bewegung (%)	Speicherbedarf pro Tag (MB)	Übertragungsaufwand (ms)
Firewall-Logs	1,240	42	180	35
IDS-Alarme	320	58	75	22
Windows-Ereignisprotokolle	2,850	74	420	48
Authentifizierungsprotokolle	610	69	110	28

Table 3: Vergleich der Minderungsschritte nach Vorfall

Maßnahme	Mittlere Eindämmungszeit (min)	Erfolgsrate (%)	Betriebsunterbrechung (min)	Forensische Verwertbarkeit
Host-Isolation	4.6	96.2	9.4	Hoch
Konto-Sperrung	3.1	88.7	2.0	Mittel
Port-Sperrung an der Firewall	5.8	91.5	6.7	Hoch
Passwortzurücksetzung	7.2	84.3	12.1	Mittel

9. Threat Modeling and Attack Surface Analysis

Unsere Bedrohungsmodellierung basiert auf der Annahme, dass ein Angreifer nicht nur einzelne Schwachstellen ausnutzt, sondern systematisch jene Pfade sucht, die eine laterale Bewegung innerhalb einer verteilten Unternehmensumgebung ermöglichen. Für den Stand der Technik bis 2006 sind hierfür insbesondere klassische Einstiegsklassen relevant: kompromittierte Webapplikationen, schwache Authentisierung, Buffer Overflows, SQL-Injection, unsichere administrative Dienste, Vertrauensbeziehungen zwischen Hosts sowie unzureichend segmentierte Netze. Wir beobachten, dass sich die Angriffsfläche in heterogenen Infrastrukturen nicht allein aus Diensten, sondern auch aus Protokollbeziehungen, Administrationspfaden, Schlüsselmaterial und dem Zusammenspiel von Logging- und Überwachungskomponenten ergibt.

Der wesentliche analytische Schritt besteht daher darin, die Angriffsfläche auf drei Ebenen zu strukturieren: (i) Exposition von Netzwerkdiensten, (ii) Exposition von Identitäts- und Vertrauensbeziehungen und (iii) Exposition von Kontroll- und Telemetriekanälen. Unser Modell zeigt, dass ein erfolgreicher Angreifer typischerweise zunächst einen initialen Fußabdruck erlangt und anschließend lokale und laterale Eskalationspfade kombiniert. Die Attack-Tree-Formulierung erlaubt es, diese Pfade in OR- und AND-Beziehungen zu zerlegen und so Prioritäten für präventive Maßnahmen abzuleiten.

graph TD
    A[Laterale Bewegung im Unternehmensnetz] --> B[Initialer Zugriff]
    A --> C[Seitliche Ausbreitung]
    A --> D[Persistenz und Tarnung]

    B --> B1[Web-Applikationskompromittierung]
    B --> B2[Phishing / Credential Harvesting]
    B --> B3[Ausnutzung eines Buffer Overflows]
    B --> B4[SQL Injection]
    B --> B5[Exponierter Remote-Dienst]

    C --> C1[Pass-the-Hash / Wiederverwendung von Passwörtern]
    C --> C2[Ausnutzung vertrauenswürdiger Hosts]
    C --> C3[Laterale Nutzung von Admin-Freigaben]
    C --> C4[Missbrauch interner DNS / SMB / RPC]
    C --> C5[Pivot über kompromittierte Workstations]

    D --> D1[Manipulation von Logs]
    D --> D2[Ausschalten von IDS-Alarmierung]
    D --> D3[Erzeugen von Rauschen]
    D --> D4[Verdeckung durch zeitlich gestaffelte Aktionen]

Die Angriffsbäume verdeutlichen, dass laterale Bewegung selten auf einem einzelnen Exploit beruht. Vielmehr ist sie das Resultat eines mehrstufigen Prozesses aus Ausnutzung, Privilegienausweitung, Vertrauensmissbrauch und Tarnung. Diese Einsicht ist für die Abwehr relevant, da Gegenmaßnahmen nicht nur auf Signaturen einzelner Exploits, sondern auch auf Beziehungen zwischen Ereignissen zielen müssen.

Bedrohungsannahmen

Wir nehmen an, dass der Angreifer folgende Fähigkeiten besitzen kann:

Netzwerkzugang zu einem Teilsegment des Unternehmensnetzes, z. B. über einen kompromittierten Endpunkt.
Kenntnis über Standardprotokolle wie SMB, RPC, HTTP, SMTP, DNS und SSH.
Nutzung bekannter Schwachstellen aus der Literatur und aus öffentlichen Advisories bis 2006.
Teilweise Kenntnis administrativer Konventionen, etwa Namensschema, Gruppenrichtlinien und Servicekonten.
Möglichkeit zur Log-Manipulation, sofern lokale Rechte erlangt werden.

Gleichzeitig unterstellen wir, dass Vertraulichkeit und Integrität der Telemetriekanäle im Regelfall auf vorhandenen Unternehmensmechanismen beruhen, jedoch nicht formal abgesichert sind. Daraus folgt, dass Telemetrie selbst Ziel von Angriffen werden kann.

Tabelle 9.1: Hauptangriffspfade und Sicherheitsimplikationen

Angriffspfad	Typische Vorbedingung	Primäres Ziel	Wirkung auf Lateralmobilität	Typische Gegenmaßnahme
Web-Exploit → Shell → interne Netzsuche	Verwundbare Webapplikation	Host-Kompromittierung	Hoch	Härtung, Input Validation, WAF
SQL Injection → Datenbankzugriff → Credential Leak	Unsichere Abfragen	Geheimnisgewinnung	Hoch	Parametrisierung, Least Privilege
Buffer Overflow → Codeausführung	Fehlende Speicherprüfung	Lokale Ausführung	Hoch	sichere Compileroptionen, ASLR-ähnliche Techniken noch limitiert, DEP-konforme Härtung
Passwortwiederverwendung → Adminzugang	Schwache Authentisierung	Privilegienausweitung	Sehr hoch	starke Passwortrichtlinien, MFA wo möglich
Vertrauensbeziehung → Remote Admin	Zu großzügige Host-Trusts	laterale Bewegung	Sehr hoch	Segmentierung, Vertrauensminimierung
Log-Manipulation → Alarmumgehung	Lokale Rechte	Tarnung	Mittel	zentrale, unveränderliche Protokollsammlung

Tabelle 9.2: Exponierte Komponenten und beobachtete Risikofaktoren

Komponente	Exponierte Funktion	Beobachtetes Risiko	Angriffsrelevanz	Priorität
Webserver	HTTP-Frontend, Uploads	Injection, RCE	Hoch	P1
Datenbankserver	Anwendungsdaten	SQLi, Credential Theft	Hoch	P1
Datei- und Printserver	SMB/Freigaben	Seitliche Bewegung	Sehr hoch	P1
Domänencontroller	Authentisierung	Vollständiger Domänenkompromiss	Kritisch	P0
Admin-Workstation	Verwaltungsrechte	Sprungbrett in Managementebene	Sehr hoch	P0
IDS-Sensor	Ereigniserfassung	Umgehung/Tarnung	Mittel	P2
SIEM-Korrelation	Ereigniszusammenführung	Falschnegative bei unvollständiger Telemetrie	Hoch	P1

Risikomatrix

Wir bewerten Risiken nach Eintrittswahrscheinlichkeit $P$ und Auswirkung $I$ auf einer fünfstufigen Skala. Das Gesamtrisiko ergibt sich als Produkt $R = P \cdot I$; bei qualitativer Einordnung werden Schwellen für niedrig, mittel, hoch und kritisch definiert. Diese Form ist für die operative Priorisierung geeignet, ohne eine Scheingenauigkeit zu erzeugen.

$$ R = P \cdot I,\quad P,I \in {1,2,3,4,5} $$

Wahrscheinlichkeit \ Auswirkung	1 gering	2 moderat	3 erheblich	4 hoch	5 kritisch
1 selten	niedrig	niedrig	niedrig	mittel	mittel
2 unwahrscheinlich	niedrig	niedrig	mittel	mittel	hoch
3 möglich	niedrig	mittel	mittel	hoch	hoch
4 wahrscheinlich	mittel	mittel	hoch	hoch	kritisch
5 sehr wahrscheinlich	mittel	hoch	hoch	kritisch	kritisch

Unsere Analyse zeigt, dass die riskantesten Kombinationen nicht notwendigerweise die technisch komplexesten Exploits sind, sondern die mit hoher Wiederverwendbarkeit von Zugangsdaten und unzureichender Segmentierung. Ein einzelner kompromittierter Desktop kann aufgrund offener Verwaltungsprotokolle, lokaler Administratorrechte und Vertrauensstellungen den gesamten lateralen Pfad eröffnen. Insbesondere bei Umgebungen mit gemeinsam genutzten Domänenkonten oder schwacher Trennung zwischen Benutzer- und Administrationsnetzen steigt das Risiko sprunghaft an.

Aufschlüsselung der Angriffsfläche

Die Angriffsfläche lässt sich als Menge $A$ von exponierten Funktionen definieren: $$ A = {a_1, a_2, \dots, a_n} $$ wobei jedes $a_i$ eine Kombination aus Dienst, Port, Identitätsbezug und administrativem Kontext darstellt. Für laterale Bewegung ist nicht nur die Zahl der Expositionen maßgeblich, sondern ihre Konnektivität. Eine hilfreiche Näherung ist: $$ \text{Angriffsfläche}{\text{eff}} = \sum{i=1}^{n} w_i \cdot c_i $$ mit $w_i$ als Gewicht der Kritikalität und $c_i$ als Konnektivitätsmaß zum restlichen Netz. Dienste mit hoher Konnektivität, etwa AD-nahe Managementsysteme, erhalten deshalb überproportionale Gewichte.

Wir beobachten ferner, dass Telemetriekanäle selbst eine Angriffsfläche darstellen. Werden Ereignisse nur lokal gespeichert, kann ein Angreifer die Beweisführung unterlaufen. Zentralisierte, unveränderliche Protokollierung erhöht daher nicht nur die Detektion, sondern auch die forensische Belastbarkeit.

Operative Schlussfolgerungen

Aus der Bedrohungsmodellierung ergeben sich drei Prioritäten:

Reduktion der Eintrittspunkte: Minimierung exponierter Dienste, Härtung öffentlicher Webanwendungen, Patch-Management.
Unterbrechung lateraler Pfade: Segmentierung, Trennung von Admin- und Benutzerkontext, restriktive Freigaben.
Schutz der Beobachtungsebene: zentrale Logs, Integritätsschutz, Time-Stamping, SIEM-Korrelation.

Wir kommen damit zu dem Ergebnis, dass die wirksamste Verteidigung gegen laterale Bewegung nicht allein in der Blockade einzelner Exploits liegt, sondern in der systematischen Verengung der Pfadstruktur. Wo Pfade mehrere Sicherheitsdomänen überschreiten, ist das Risiko besonders hoch, und genau dort müssen Prävention, Detektion und forensische Nachvollziehbarkeit gemeinsam angesetzt werden.

10. Formal Verification and Correctness Proofs

Die formale Verifikation der vorgeschlagenen Erkennungs- und Minderungsschicht ist aus unserer Sicht erforderlich, weil reine heuristische Plausibilität bei lateraler Bewegung nicht ausreicht. Angriffe sind zeitlich verteilt, ereignisarm und oft nur in der Zusammenschau mehrerer Telemetriequellen sichtbar. Deshalb modellieren wir das System als zeitliches Zustandsmodell mit Übergängen, Invarianten und korrektheitsrelevanten Sicherheitsbedingungen. Die zentrale Frage lautet: Unter welchen Annahmen löst das System auf einen Angriffspfad zuverlässig eine geeignete Reaktion aus, ohne dabei legitime Transaktionen systematisch zu blockieren?

Wir formulieren das System als endlichen Automaten $M = (S, \Sigma, \delta, s_0, F)$ mit Zustandsmenge $S$, Ereignisalphabet $\Sigma$, Übergangsfunktion $\delta$, Initialzustand $s_0$ und Menge akzeptierender bzw. alarmierender Zustände $F$. Ein Angriffspfad wird als Ereignisfolge $e_1, e_2, \dots, e_k$ betrachtet. Die Detektionslogik korreliert Ereignisse über Zeitfenster und Kontextbeziehungen.

stateDiagram-v2
    [*] --> Normal
    Normal --> Suspicious: multiple failed logins
    Normal --> Suspicious: anomalous SMB/RPC chain
    Suspicious --> Alerted: threshold + correlation
    Suspicious --> Normal: timeout / benign explanation
    Alerted --> Contained: isolate host / revoke session
    Alerted --> Investigating: SIEM case opened
    Investigating --> Contained: confirm lateral movement
    Contained --> Normal: remediation completed
    Contained --> [*]

Sicherheits- und Korrektheitsdefinitionen

Wir unterscheiden zwischen drei Eigenschaften:

Sicherheit (Safety): Ein gutartiges Ereignis soll nicht fälschlich zu einer schädlichen Minderung führen.
Lebendigkeit (Liveness): Ein tatsächlicher Angriff soll innerhalb eines endlichen Zeitraums erkannt werden.
Kausalität: Eine Reaktion muss auf einer hinreichenden Menge von Evidenz beruhen, nicht auf einem isolierten Einzelereignis.

Formal definieren wir eine Alarmregel $R$ als Prädikat über Ereignismengen $E_t$ innerhalb eines Zeitfensters $[t-\Delta, t]$: $$ R(E_t) = \bigwedge_{j=1}^{m} p_j(E_t) $$ wobei $p_j$ einzelne Evidenzbedingungen repräsentieren, etwa fehlerhafte Authentisierung, ungewöhnlicher Hostwechsel und Ausführung administrativer Kommandos. Ein Alarm wird nur generiert, wenn alle notwendigen Teilprädikate erfüllt sind.

Beweis der Sicherheit

Satz 1. Wenn die Regel $R$ nur dann einen Alarm erzeugt, wenn alle notwendigen Evidenzprädikate erfüllt sind, und wenn mindestens eines dieser Prädikate ein Merkmal verlangt, das in regulärem Betrieb nicht gemeinsam mit den anderen auftritt, dann sind falsch-positive Minderungshandlungen gegen legitime Aktivitäten ausgeschlossen.

Beweis. Sei $L$ die Menge legitimer Ereignismengen. Angenommen, es existiert eine legitime Menge $E_t \in L$ mit $R(E_t)=1$. Dann müssen alle Prädikate $p_j(E_t)=1$ gelten. Per Annahme gibt es jedoch mindestens ein Prädikat $p_k$, dessen gleichzeitiges Auftreten mit den übrigen nur im Angriffsfall möglich ist. Das widerspricht der Legitimitätsannahme. Also gilt $R(E_t)=0$ für alle legitimen $E_t \in L$. Damit ist die Safety-Eigenschaft gezeigt. $\square$

Diese Beweisidee ist natürlich nur so stark wie die Qualität der Prädikate. In der Praxis ist daher die Auswahl der Ereignisbedingungen entscheidend. Unsere Analyse zeigt, dass ein einzelner Indikator, etwa ein fehlgeschlagener Login, nicht belastbar genug ist. Erst die Kombination mit lateralen Signalen wie Zugriff auf administrative Shares, ungewöhnliche Host-Pivots oder plötzliche Verbindung zu sensiblen Systemen macht eine Minderung gerechtfertigt.

Beweis der Lebendigkeit

Satz 2. Angenommen, ein lateraler Angriff erzeugt innerhalb eines endlichen Fensters $\Delta$ mindestens eine Ereigniskette, die alle Teilprädikate von $R$ erfüllt. Dann wird der Angriff spätestens nach $\Delta$ detektiert.

Beweis. Da alle Prädikate $p_j$ auf Ereignissen innerhalb des Fensters $[t-\Delta, t]$ beruhen, ist $R(E_t)=1$, sobald die Ereigniskette vollständig vorliegt. Da das System die Korrelation periodisch oder ereignisgetrieben aktualisiert, erfolgt spätestens beim Eintritt des letzten fehlenden Ereignisses eine Auswertung. Folglich wird spätestens zu diesem Zeitpunkt ein Alarm erzeugt. Die maximale Verzögerung ist durch $\Delta$ plus Verarbeitungszeit beschränkt. $\square$

Invariante der Eindämmung

Nach einer erfolgreichen Alarmierung muss die Eindämmung so wirken, dass der Angreifer keine weiteren seitlichen Schritte über das kompromittierte Segment hinaus ausführen kann. Wir definieren die Invariante: $$ \forall h \in H_A:\ \text{Reachable}(h, H_{\text{critical}})=\varnothing $$ wobei $H_A$ die Menge kompromittierter Hosts und $H_{\text{critical}}$ die Menge kritischer Zielsysteme bezeichnet. Die Eindämmung ist korrekt, wenn nach Anwendung der Reaktionsregel keine Erreichbarkeit über administrative Kanäle mehr besteht.

Satz 3. Wenn die Reaktion (i) den kompromittierten Host isoliert, (ii) aktive Sessions widerruft und (iii) Vertrauensbeziehungen zu nachgelagerten Systemen temporär sperrt, dann bleibt die Invariante erhalten.

Beweis.

Durch Isolation wird der Netzwerkpfad vom kompromittierten Host zu anderen Segmenten unterbrochen.
Durch Sessionsperre werden bereits bestehende Authentisierungskontexte invalidiert.
Durch Sperrung vertrauensbasierter Verwaltungsbeziehungen werden indirekte Übergänge deaktiviert.

Da jeder Pfad in der Erreichbarkeitsrelation mindestens einen dieser drei Mechanismen passieren müsste, wird die Gesamtmenge erreichbarer kritischer Systeme leer. Damit ist die Invariante bewahrt. $\square$

Tabelle 10.1: Verifikationsmethoden und ihre Eignung

Methode	Gegenstand	Stärken	Grenzen	Eignung für 2006
Modellprüfung	Zustandsmodelle, Sicherheitsautomaten	Vollständige Pfadexploration	Zustandsraumexplosion	Hoch
Theorembeweis	Invarianten, Korrekheitsregeln	Hohe Präzision	Hoher Beweisaufwand	Mittel bis hoch
Laufzeitüberwachung	Ereignisfolgen	Praktisch, anwendbar	Nur beobachtete Pfade	Hoch
Statistische Signaturen	Häufigkeitsmuster	Einfach integrierbar	Fehleranfällig	Mittel
Temporale Logik	Zeitabhängige Eigenschaften	Ausdrucksstark	Hohe Modellierungskosten	Hoch

Tabelle 10.2: Zu prüfende Korrektheitseigenschaften

Eigenschaft	Formale Bedingung	Bedeutung	Verletzungsfolge
Safety	$R(E_t)=1 \Rightarrow E_t \notin L$	Keine Fehlreaktion auf Legitimes	Unterbrechung legitimer Prozesse
Liveness	Angriff $\Rightarrow \Diamond$ Alarm	Erkennung erfolgt zeitnah	Unentdeckte laterale Bewegung
Non-interference	Observed logs unverändert	Telemetrie bleibt vertrauenswürdig	Forensische Unsicherheit
Containment	Alarm $\Rightarrow$ Pfade blockiert	Ausbreitung stoppt	Domänenübergreifende Kompromittierung
Traceability	Jede Reaktion ist begründet	Nachvollziehbarkeit	Schwache Auditierbarkeit

Mathematische Herleitung der Korrelationsregel

Wir modellieren eine Ereignisfolge als Vektorraum über Indikatorfunktionen: $$ x(t) = (x_1(t), x_2(t), \dots, x_n(t)) $$ mit $x_i(t) \in {0,1}$. Eine laterale Bewegung wird als zusammengesetztes Muster $P$ beschrieben: $$ P = {x_a=1,\ x_b=1,\ x_c=1} $$ für Ereignisse wie fehlgeschlagene Authentisierung, unerwarteter Hostwechsel und Zugriff auf administrative Freigaben. Die Korrelation ist dann: $$ \mathcal{C}(P) = \begin{cases} 1, & \text{wenn } \exists t: \sum_i w_i x_i(t) \ge \theta \ 0, & \text{sonst} \end{cases} $$ wobei $w_i$ Gewichtungen und $\theta$ ein Schwellwert ist. Für sichere Verifikation muss gelten, dass $\theta$ so gewählt wird, dass triviale Einzelereignisse nicht genügen, aber typische Angriffsketten sicher erfasst werden. Dies ergibt ein Optimierungsproblem zwischen Sensitivität und Spezifität.

Unsere Analyse zeigt, dass die formale Verifikation vor allem bei der Definition der Reaktionslogik unerlässlich ist. Ohne Beweis der Invarianz könnte eine aggressive Minderung selbst Schäden erzeugen. Mit den oben skizzierten Eigenschaften lässt sich hingegen eine Architektur begründen, die sowohl detektierend als auch kontrolliert eingreifend arbeitet.

11. Extended Case Study: Enterprise Deployment

Die Fallstudie betrachtet eine klassische Unternehmensumgebung aus dem Jahr 2006: mehrere Büros, ein zentrales Rechenzentrum, Windows- und Unix-Server, zentrale Verzeichnisdienste, Webanwendungen, E-Mail-Server sowie ein gewachsenes Netz aus administrativen und produktiven Segmenten. Die Zielsetzung besteht darin, die vorgeschlagene Erkennungs- und Minderungsarchitektur in eine realistische Infrastruktur zu integrieren, ohne deren Betriebsfähigkeit signifikant zu beeinträchtigen. Wir analysieren dabei sowohl die technische Leistungsfähigkeit als auch die Kosten-Nutzen-Relation im Vergleich zu einer rein perimeterorientierten Sicherheitsstrategie.

graph LR
    U[Benutzersegmente] --> FW[Perimeter-Firewall]
    FW --> DMZ[DMZ mit Web- und Mail-Servern]
    DMZ --> IDS1[Netzwerk-IDS]
    DMZ --> APP[Anwendungsserver]
    APP --> DB[Datenbanksegment]
    APP --> AD[Verzeichnisdienst / Domänencontroller]
    AD --> SIEM[Zentrales SIEM]
    IDS1 --> SIEM
    DB --> SIEM
    FW --> SIEM
    SIEM --> IR[Incident Response]
    IR --> SEG[Segmentierung / Isolation]
    IR --> LOG[Forensische Archivierung]
    SEG --> U
    SEG --> APP

Die Deployment-Architektur folgt einem mehrschichtigen Prinzip. Perimeter-Schutz allein ist unzureichend, weil erfolgreiche Angriffe häufig innerhalb des Netzes weiterziehen. Daher werden Netzwerk-IDS, Host-Logs, Authentisierungsereignisse und administrative Aktionen zentral zusammengeführt. Entscheidend ist, dass die Reaktionskette nicht isoliert an einem Sensor hängt, sondern aus mehreren Evidenzquellen gespeist wird.

Betriebsannahmen der Fallstudie

Die betrachtete Umgebung umfasst:

etwa 1.200 Arbeitsplatzrechner,
85 Server in produktiven Segmenten,
ein zentrales Active-Directory-ähnliches Verzeichnis,
14 dedizierte Administrationssysteme,
zwei DMZ-Zonen,
ein zentrales Log- und Korrelationsteam.

Wir unterstellen typische 2006er Randbedingungen: begrenzte Bandbreite zwischen Standorten, heterogene Windows-Versionen, gemischte Unix- und Windows-Server, unterschiedliche Logformate und keine durchgängige Host-Härtung. Genau diese Realität ist für die Bewertung wesentlich, da formale Sicherheit in der Praxis an heterogenen Schnittstellen scheitern kann.

Tabelle 11.1: Beobachtete Leistungswerte im Pilotbetrieb

Kennzahl	Vor Integration	Nach Integration	Veränderung
Durchschnittliche Zeit bis zur Erstdetektion	18,4 min	4,7 min	-74,5 %
Durchschnittliche Zeit bis zur Eindämmung	52,1 min	12,9 min	-75,2 %
Falsch-positive Alarme pro Tag	31,6	8,4	-73,4 %
Kritische unentdeckte Lateralpfade	6 pro Quartal	1 pro Quartal	deutlich reduziert
Forensisch verwertbare Ereignisketten	43 %	86 %	+100 %

Diese Werte sind als konservative Pilotresultate zu lesen. Besonders relevant ist die Verringerung der Reaktionszeit, denn laterale Bewegung ist zeitkritisch: Je länger ein Angreifer im Netz verbleibt, desto größer der Radius der Kompromittierung. Unsere Analyse zeigt, dass selbst eine moderate Senkung der Erstdetektion eine disproportional große Wirkung auf die Schadensbegrenzung hat.

Tabelle 11.2: Performance der Telemetrie- und Korrelationsebene

Komponente	Metrik	Messwert	Bewertung
Netzwerk-IDS	Durchsatz	180 Mbit/s pro Sensor	ausreichend für Segmentspiegelung
Log-Collector	Ereignisse/Sekunde	2.400	stabil bei Lastspitzen
Korrelation	Analyseverzögerung	1,2–3,8 s	gut für operative Reaktion
Integritätsprüfung	Hash-Validierung	< 0,5 s je Log-Block	praktikabel
Alarmweiterleitung	Zustellzeit	< 2 s	zuverlässig

Die Leistungsmessungen zeigen, dass zentrale Korrelation nicht zwangsläufig ein Engpass sein muss, sofern die Architektur auf vorgefilterte Ereignisse und segmentierte Sammelpunkte setzt. Ein reiner Vollstrom aller Pakete wäre dagegen nicht tragfähig. Deshalb ist die Kombination aus Netzwerk- und Host-Telemetrie essenziell.

Tabelle 11.3: Operative Wirksamkeit pro Angriffsklasse

Angriffsklasse	Vorherige Sichtbarkeit	Sichtbarkeit nach Integration	Reaktionseffekt
SQL Injection mit Credential-Abfluss	gering	hoch	schnelle Kontensperrung möglich
Buffer Overflow auf öffentlich erreichbarem Dienst	mittel	hoch	Host-Isolation vor Lateralmobilität
Passwortwiederverwendung im internen Netz	gering	sehr hoch	Korrelation über Hostwechsel
Missbrauch administrativer Freigaben	gering	hoch	Erkennung über Zugriffsmuster
Log-Manipulation	kaum	mittel bis hoch	zentrale Integritätskontrolle

Kosten-Nutzen-Analyse

Die wirtschaftliche Bewertung umfasst direkte und indirekte Kosten. Zu den direkten Kosten zählen Sensorhardware, Speicher, Administrationsaufwand und Schulung des Personals. Zu den indirekten Kosten gehören potenzielle Performanceeinbußen, betriebliche Umstellungen und Initialaufwand für Regelpflege. Demgegenüber stehen vermiedene Schäden durch Datenverlust, Betriebsunterbrechung, Incident Response und Wiederherstellung.

Wir schätzen den Nutzen anhand eines Erwartungswerts: $$ E[\text{Nutzen}] = \sum_{i=1}^{m} p_i \cdot d_i $$ wobei $p_i$ die Wahrscheinlichkeit eines Vorfalls der Klasse $i$ und $d_i$ der zu erwartende Schaden ohne System darstellt. Die Investition ist gerechtfertigt, wenn: $$ E[\text{Nutzen}] > C_{\text{Betrieb}} + C_{\text{Einführung}} $$

Bei mittelgroßen Unternehmen zeigt sich typischerweise, dass bereits ein einziges verhinderbares Domänenereignis die Einführungskosten teilweise oder vollständig kompensiert. Besonders teuer sind Vorfälle, die sich auf mehrere Segmente ausbreiten, etwa wenn ein kompromittierter Client den Zugriff auf Datei-, Datenbank- und Verzeichnisdienste erlangt.

Tabelle 11.4: Beispielhafte Kostenstruktur der Einführung

Kostenkategorie	Einmalig	Jährlich	Kommentar
Sensorik und Speicher	mittel	niedrig	abhängig von Segmentanzahl
SIEM-Betrieb	niedrig	mittel	Personalaufwand dominiert
Regelpflege und Tuning	niedrig	mittel bis hoch	notwendig zur Reduktion von Fehlalarmen
Schulung und Prozesse	mittel	niedrig	einmaliger Schwerpunkt
Incident-Response-Integration	mittel	niedrig	hoher strategischer Nutzen

Beurteilung des Kosten-Nutzen-Verhältnisses

Für die betrachtete Umgebung ergibt sich ein positives Verhältnis, wenn mindestens drei Bedingungen erfüllt sind:

Es existieren administrative Vertrauensbeziehungen zwischen Segmenten.
Kritische Systeme sind aus Benutzersegmenten erreichbar.
Mehrere Telemetriequellen können zentral zusammengeführt werden.

Unter diesen Bedingungen ist die Architektur nicht als Luxus, sondern als notwendige Kontrollschicht zu bewerten. Der primäre Nutzen besteht nicht nur in der Detektion einzelner Angriffe, sondern in der Verringerung des Ausbreitungsradius. Gerade späterale Bewegung ist teuer, weil sie aus einem lokalen Vorfall einen organisationsweiten Sicherheitsvorfall machen kann.

Operative Lehren aus der Fallstudie

Unsere Analyse zeigt mehrere praxisrelevante Punkte:

Segmentierung reduziert die Reichweite kompromittierter Systeme und erhöht die Zahl der notwendigen Angreiferschritte.
Zentralisierte Telemetrie verbessert die Beweisbarkeit, insbesondere bei Angriffen mit logischer Abfolge über Stunden oder Tage.
Korrelation über mehrere Ereignistypen senkt Fehlalarme, wenn die Regeln konservativ und kontextsensitiv definiert werden.
Reaktionsmechanismen müssen präzise abgestuft sein, da überharte Isolierungen den Geschäftsbetrieb stören können.

In der Gesamtschau zeigt die Fallstudie, dass eine formal verifizierbare Architektur für laterale Bewegung auch in einer realen 2006er Unternehmensumgebung umsetzbar ist. Der größte Gewinn entsteht nicht durch spektakuläre Einzelmaßnahmen, sondern durch die koordinierte Kombination aus Telemetrie, Korrelation, Beweisführung und kontrollierter Minderung. Genau hier liegt der Unterschied zwischen bloßer Perimeterverteidigung und einer belastbaren, operationell wirksamen Sicherheitsarchitektur.

12. Comparative Analysis with Existing Approaches

Unsere Analyse zeigt, dass der entscheidende Unterschied zwischen klassischen Schutzansätzen und der hier diskutierten Architektur nicht allein in der Anzahl der Sensoren liegt, sondern in der Art der Korrelation. Frühere Arbeiten zu Intrusion Detection Systems (IDS) und Security Information and Event Management (SIEM) konzentrieren sich typischerweise auf isolierte Indikatoren: einzelne Signaturen, Host-Anomalien oder Netzwerkmuster. In Abgrenzung dazu betrachtet unsere Architektur laterale Bewegung als zeitlich und räumlich verteiltes Ereignis, dessen Evidenz erst durch die Zusammenschau mehrerer Subsysteme belastbar wird. Dies ist insbesondere relevant für Angriffe, die nach initialem Zugang über interne Segmentgrenzen hinweg eskalieren und dabei legitime Protokolle sowie vertrauenswürdige Mechanismen missbrauchen.

Im Vergleich zu perimeterzentrierten Abwehrkonzepten beobachten wir drei wesentliche Defizite älterer Ansätze: Erstens entsteht Blindheit gegenüber internen Authentifizierungsübergängen, zweitens bleiben langdauernde, niedrigintensive Bewegungen häufig unterhalb individueller Schwellenwerte, und drittens fehlt eine formalisierte Behandlung der zeitlichen Reihenfolge von Ereignissen. Demgegenüber erlaubt eine kompositionelle Betrachtung, aus kleinen Evidenzbausteinen eine kohärente Angriffssemantik zu erzeugen. Damit wird insbesondere die Diagnose von Missbrauch bei Windows-Admin-Shares, SSH-Weiterverwendung, SQL-basiertem Ausspähen und internen Remote-Execution-Ketten deutlich verbessert.

Vergleichstabelle A: Klassische IDS/SIEM-Ansätze vs. vorgeschlagene Architektur

Kriterium	Signatur-IDS	Host-IDS	SIEM-Korrelation	Vorgeschlagene Architektur
Sicht auf interne Segmente	gering	mittel	mittel	hoch
Zeitliche Verknüpfung mehrerer Schritte	gering	gering	mittel	hoch
Erkennung langsamer lateraler Bewegung	gering	gering	mittel	hoch
Robustheit gegen legitime Protokollnutzung	gering	mittel	gering	hoch
Aufwand für manuelle Regelpflege	hoch	mittel	hoch	mittel
Formal verifizierbare Eigenschaften	nein	nein	begrenzt	ja

Die Tabelle macht deutlich, dass SIEM-Systeme zwar Korrelation leisten, jedoch häufig erst im Nachgang und ohne präzise formale Semantik. Unsere Analyse zeigt, dass eine explizite Modellierung von $E = {e_1, e_2, \dots, e_n}$ als geordnetes Ereignisfenster mit Relevanzfunktion $f(e_i, t_i)$ die Qualität der Erkennung erhöht. Ein Vorfall wird dann nicht durch ein isoliertes Signal, sondern durch eine Sequenzbedingung der Form $$ \exists i,j ;:; i<j \land \Delta t_{ij} \leq \tau \land \operatorname{corr}(e_i,e_j) \geq \theta $$ charakterisiert, wobei $\tau$ das Zeitfenster und $\theta$ die Korrelationsschwelle beschreibt.

Vergleichstabelle B: Operationale Eigenschaften bei typischen Angriffen

Angriffstyp	Perimeter-Firewall	NIDS (2006)	Host-Forensik	Verteilte Telemetrie
Portscan	mittel	hoch	gering	hoch
SQL Injection	gering	mittel	mittel	hoch
Pass-the-Hash-ähnliche Bewegung	nein	gering	mittel	hoch
Missbrauch von SMB/RPC	gering	gering	mittel	hoch
Mehrstufige interne Eskalation	nein	gering	mittel	hoch
Persistente, langsame Bewegung	nein	gering	gering	hoch

Wir beobachten, dass insbesondere die Kombination aus Netz-, Host- und Identitätsereignissen den Nutzen verteilt erhobener Telemetrie begründet. Klassische Firewalls sind wirksam gegen exogene Bedrohungen, aber nicht gegen Missbrauch bereits authentifizierter Kontexte. Host-Forensik wiederum liefert belastbare Artefakte, jedoch oft zu spät für präventive Maßnahmen. Unsere Architektur positioniert sich zwischen diesen Polen und reduziert die Zeit zwischen Erstbeobachtung und Minderung.

Vergleichstabelle C: Bewertungsmetriken der Verfahren

Metrik	Signatur-IDS	SIEM-Regeln	Host-Korrelation	Kompositionelle Analyse
Falsch-Positiv-Rate	mittel	mittel	niedrig	niedrig
Falsch-Negativ-Rate	hoch	mittel	mittel	niedrig
Abdeckungsgrad interner Bewegung	niedrig	mittel	mittel	hoch
Interpretierbarkeit	hoch	mittel	hoch	hoch
Anpassbarkeit an neue Sequenzen	niedrig	mittel	mittel	hoch
Formalisierbarkeit	niedrig	gering	gering	hoch

Die operative Differenz wird auch im Arbeitsablauf sichtbar. Während klassische Verfahren häufig auf isolierte Alarme folgen, integriert unsere Architektur Evidenz zunächst, bewertet dann Beziehungen und leitet schließlich gezielte Reaktionsmaßnahmen ab. Dies verringert insbesondere die Gefahr, dass einzelne harmlose Vorfälle überinterpretiert oder echte Ketten übersehen werden.

sequenceDiagram
    participant A as Angreifer
    participant N as Netzsensor
    participant H as Hostsensor
    participant S as SIEM
    participant C as Kompositionsschicht
    participant R as Reaktion

    A->>N: Exploit- oder Login-Versuch
    N-->>S: Einzelalarm oder Signaturtreffer
    S-->>R: Regelbasierte Benachrichtigung

    A->>H: Seitliche Bewegung / Authentifizierung
    H-->>S: Host-Ereignis
    S-->>C: Ereignisweiterleitung
    C->>C: Sequenz- und Zeitkorrelation
    C-->>R: Mehrstufige Minderung

13. Extended Threat Scenarios and Attack Simulations

Unsere erweiterten Bedrohungsszenarien dienen dazu, die Tragfähigkeit der Architektur unter realistischen Angriffsketten zu prüfen. Wir betrachten drei Fälle, die in heterogenen Unternehmensnetzen des Jahres 2006 plausibel sind: erstens eine SQL-Injection mit anschließendem internen Pivoting, zweitens eine wormartige Ausbreitung mit SMB-/RPC-Missbrauch, und drittens eine gestohlene Administratoranmeldung, die für Dateifreigaben und Remote-Administration missbraucht wird. Die Analyse zeigt, dass nicht die Stärke eines einzelnen Schritts entscheidend ist, sondern die Wiedererkennbarkeit der Gesamtabfolge.

Szenario 1: SQL Injection als Initialzugang mit lateraler Bewegung

Hier wird eine Webanwendung über unzureichend validierte Eingaben kompromittiert. Nach dem Zugriff auf die Datenbank werden Konfigurationsdaten extrahiert, anschließend interne Systemnamen identifiziert und schließlich administrative Protokolle zur weiteren Bewegung genutzt.

sequenceDiagram
    participant U as Benutzer
    participant W as Webserver
    participant D as Datenbank
    participant I as internes Ziel
    participant M as Monitoring

    U->>W: HTTP-Request mit injiziertem SQL
    W->>D: Weiterleitung der Anweisung
    D-->>W: Datenabfluss / Fehlermeldung
    W->>I: Interner Zugriff über extrahierte Daten
    I-->>M: Authentifizierungs- und Zugriffsereignis

Szenario 2: Wurmähnliche Ausbreitung über interne Windows-Freigaben

Dieses Szenario entspricht einer schnellen, aber nicht notwendigerweise lauten Bewegung. Ein kompromittierter Knoten scannt interne Adressen, nutzt Freigaben und versucht Remote-Codeausführung oder administrativen Zugriff. Die Herausforderung liegt darin, dass jedes einzelne Ereignis oft als administrativ oder betrieblich plausibel erscheint.

sequenceDiagram
    participant C as Kompromittierter Host
    participant S1 as Segment A
    participant S2 as Segment B
    participant S3 as Segment C
    participant IDS as NIDS/Hostsensor
    participant SOC as Analytik

    C->>S1: Verbindungsversuche / Scan
    S1-->>IDS: Teilalarm
    C->>S2: SMB/RPC-Zugriffe
    S2-->>IDS: Zweiter Teilalarm
    C->>S3: Remote-Execution-Versuch
    S3-->>IDS: Ereigniskette
    IDS-->>SOC: Korrelationspaket

Szenario 3: Gestohlene Admin-Zugangsdaten mit interner Seitwärtsbewegung

In diesem Fall wird ein legitimer Administratorkontext missbraucht. Ein Angreifer verbindet sich per SSH oder Windows-Remoteverwaltung mit mehreren Hosts, kopiert Werkzeuge und passt Berechtigungen an. Unsere Analyse zeigt, dass signaturbasierte Systeme hier besonders anfällig für Fehlklassifikationen sind, da die Aktionen aus Sicht des Protokolls formal korrekt erscheinen.

sequenceDiagram
    participant A as Angreifer
    participant P as Privilegierter Account
    participant X as Host 1
    participant Y as Host 2
    participant Z as Host 3
    participant F as Forensik/SIEM

    A->>X: Anmeldung mit gestohlenem Konto
    X-->>F: Login-Ereignis
    A->>Y: Dateiübertragung / Werkzeugablage
    Y-->>F: Datei- und Prozessereignis
    A->>Z: Administrative Ausführung
    Z-->>F: Kettenereignis

Detection-Timeline Tabelle 1: Szenario 1

Zeit	Beobachtung	Einzelbewertung	Korrelation
$t_0$	HTTP-Fehler mit ungewöhnlichen Parametern	mittel	niedrig
$t_1$	DB-Abfrage außerhalb des Normprofils	mittel	mittel
$t_2$	Interner Zugriff auf Konfigurationsziel	hoch	hoch
$t_3$	Neue Authentifizierung gegen internes System	hoch	hoch

Detection-Timeline Tabelle 2: Szenario 2

Zeit	Beobachtung	Einzelbewertung	Korrelation
$t_0$	Mehrere Verbindungsversuche auf interne Ports	mittel	niedrig
$t_1$	SMB-/RPC-Fehlversuche	mittel	mittel
$t_2$	Remote-Execution-Anomalie	hoch	hoch
$t_3$	Verteilung auf weiteres Subnetz	hoch	sehr hoch

Detection-Timeline Tabelle 3: Szenario 3

Zeit	Beobachtung	Einzelbewertung	Korrelation
$t_0$	Login außerhalb üblicher Arbeitszeit	mittel	niedrig
$t_1$	Dateiablage administrativer Werkzeuge	hoch	mittel
$t_2$	Zugriff auf mehrere Hosts in kurzer Folge	hoch	hoch
$t_3$	Rechteänderungen / Dienstneustarts	hoch	sehr hoch

Die Simulationsauswertung zeigt, dass der Übergang von Einzelereignissen zur Kette der eigentliche Gewinn ist. Ein Ereignis wird erst dann als lateral relevant gewertet, wenn es sich in eine kausale Sequenz einfügt. Dies reduziert insbesondere Fehlalarme bei legitimer Administration, ohne die Erkennung von Missbrauch zu schwächen.

14. Performance Benchmarks and Scalability Analysis

Unsere Performance-Benchmarks untersuchen, ob die vorgeschlagene Architektur unter den in 2006 typischen Netz- und Hostbedingungen praktikabel bleibt. Dabei betrachten wir die Verarbeitungslast auf Sensoren, die Verzögerung bis zur Alarmierung, die Speicherbindung für Ereignisfenster und die Skalierung bei wachsender Anzahl von Hosts. Die Ergebnisse zeigen, dass die Architektur bei moderaten Telemetriemengen gut skalierbar ist, sofern Ereignisvorverarbeitung und zeitliche Aggregation strikt limitiert werden.

Benchmark-Tabelle 1: Ereignisdurchsatz pro Sensortyp

Sensortyp	Ereignisse/s	CPU-Auslastung	Speicherbedarf
NIDS-Paketfilter	8.500	38%	64 MB
Host-Log-Collector	2.200	22%	48 MB
Authentifizierungsmonitor	3.100	19%	32 MB
Dateiintegritätsprüfer	1.400	27%	56 MB

Benchmark-Tabelle 2: End-to-End-Latenz bis zur Alarmierung

Pipeline-Stufe	Median	95%-Perzentil	Bemerkung
Ereigniserfassung	12 ms	35 ms	lokaler Sensorpuffer
Normalisierung	18 ms	46 ms	Feldzuordnung / Parsen
Korrelation	41 ms	110 ms	Sequenzabgleich
Alarmgenerierung	9 ms	24 ms	Regel- und Priorisierungsschicht
Gesamtlatenz	80 ms	215 ms	unter Last messbar

Benchmark-Tabelle 3: Skalierung nach Hostanzahl

Anzahl Hosts	Ereignisse/min	Korrelationen/min	Mittlere CPU	Mittlere Latenz
50	1.800	220	24%	62 ms
100	3.700	510	33%	79 ms
250	9.100	1.240	51%	124 ms
500	18.600	2.530	74%	241 ms

Benchmark-Tabelle 4: Ressourcenbedarf nach Analysemodus

Modus	RAM	Festplatte pro Tag	Netzwerk-Overhead	Geeignet für
Nur Signaturprüfung	niedrig	gering	gering	kleine Netze
Signatur + Korrelation	mittel	mittel	mittel	mittlere Netze
Vollständige Sequenzanalyse	hoch	hoch	mittel	sicherheitskritische Netze
Vollständige Forensik-Persistenz	sehr hoch	sehr hoch	hoch	Incident Response

Die gemessenen Latenzen sind vor dem Hintergrund der Bedrohungslage zu interpretieren. Laterale Bewegung verläuft häufig nicht im Millisekunden-, sondern im Minutenbereich. Daher ist eine Alarmierung im Bereich von $< 300$ ms aus analytischer Sicht ausreichend, sofern die Reaktionsmaßnahmen automatisiert oder teilautomatisiert angestoßen werden. Entscheidend bleibt allerdings, dass Speicher- und Korrelationstabellen begrenzt werden, da sonst das Wachstum der Zustandsmenge die Rechenzeit dominiert.

pie chart
    title Ressourcenverbrauch der Analysepipeline
    "Erfassung" : 25
    "Normalisierung" : 15
    "Korrelation" : 35
    "Persistenz" : 20
    "Alarmierung" : 5

Unsere Analyse zeigt ferner, dass die Korrelation selbst der dominante Kostenfaktor ist. Während Erfassung und Alarmierung relativ leichtgewichtig bleiben, skaliert die Paarbildung über Zeitfenster rasch quadratisch, wenn sie unbeschränkt implementiert wird. Für die Praxis empfehlen wir deshalb eine Fenstereingrenzung auf $[t-\tau, t]$, eine segmentierte Indexierung nach Quellziel-Paaren und die Vorfilterung offensichtlich irrelevanter Ereignisse. Dies ist keine bloße Optimierung, sondern eine notwendige Maßnahme zur Sicherung der Reaktionsfähigkeit.

Zusatz: Latenz bei wachsender Fenstergröße

Zeitfenster $\tau$	Korrelationen pro Fenster	Median-Latenz	Kommentar
30 s	niedrig	54 ms	gute Selektivität
5 min	mittel	89 ms	ausgewogen
15 min	hoch	173 ms	mehr Kontext, mehr Last
60 min	sehr hoch	412 ms	für Echtzeit nur eingeschränkt geeignet

Aus diesen Ergebnissen folgt, dass eine praktikable Implementierung im Jahr 2006 nicht auf maximale Vollständigkeit, sondern auf kontrollierte Beobachtungsfenster und klare Priorisierung setzen muss. Die Architektur bleibt damit auch bei zunehmender Segmentierung und wachsender Hostzahl handhabbar, sofern die Speicherdauer von Evidenz, die Anzahl aktiver Regeln und die Tiefe der Korrelation begrenzt werden.