Purple-Team-Übung nach OSI: Szenarien pro Schicht zum Training

Eine Purple-Team-Übung nach OSI verbindet die Stärken von Red Team (Angriffssicht) und Blue Team (Verteidigungssicht) in einem gemeinsamen, messbaren Training. Der entscheidende Vorteil: Statt „gewonnen“ oder „verloren“ zu diskutieren, optimieren beide Seiten gemeinsam Detection, Response und Hardening – basierend auf realistischen Szenarien und klarer Evidenz. Die OSI-Schichten bieten dabei eine überraschend praxistaugliche Struktur, weil sie technische Kontrollpunkte (Layer 2–7) logisch trennt und gleichzeitig Abhängigkeiten sichtbar macht. So lässt sich eine Übung modular planen: Sie trainieren gezielt pro Schicht, definieren Telemetrie-Anforderungen, validieren Use Cases im SIEM/NDR/EDR und dokumentieren, welche Kontrollen zuverlässig greifen. Gerade für Einsteiger schafft das Modell Ordnung, während Profis davon profitieren, dass das Training reproduzierbar bleibt und sich nach Reifegrad skalieren lässt. In diesem Artikel erhalten Sie einen Leitfaden für eine Purple-Team-Übung nach OSI – inklusive Szenarien pro Schicht, typischen Beobachtungsdaten, Erfolgskriterien und einem Bewertungsschema, das technische Qualität statt Bauchgefühl misst.

Grundprinzipien einer OSI-basierten Purple-Team-Übung

Bevor Sie Szenarien auswählen, sollten Sie ein gemeinsames Fundament definieren. Purple Teaming ist kein „Penetrationstest mit Beobachtern“, sondern ein Lernzyklus: planen, ausführen, messen, verbessern. OSI hilft, den Umfang zu begrenzen und die Übung in Trainingsblöcke zu zerlegen. Gleichzeitig dürfen Sie die Praxis nicht vergessen: Viele Angriffe starten auf einer Schicht und eskalieren in andere (z. B. Layer 2 zu Layer 7), weshalb Übergänge explizit geübt werden sollten.

• Scope und Umgebung: Üben Sie bevorzugt in einer isolierten Lab- oder Staging-Umgebung mit realistischen Datenflüssen, aber ohne Kundendaten.
• Rules of Engagement: Definieren Sie erlaubte Zeiten, Systeme, Testkonten, Eskalationswege und Abbruchkriterien.
• Messbarkeit: Jede Übung braucht vorab definierte Signale (Logs, Flows, Alerts) und Erfolgskriterien.
• Dokumentation: Halten Sie Hypothesen, Observables, Beweise und Verbesserungen direkt in einem gemeinsamen Runbook fest.

Als gemeinsame Sprache für Taktiken und Techniken eignet sich MITRE ATT&CK, um Szenarien nicht nur nach OSI, sondern auch nach Angriffsphasen zu strukturieren. Für den Incident-Prozess ist NIST SP 800-61 hilfreich, weil es Detection, Containment, Eradication und Recovery sauber trennt.

Planungsrahmen: Ziele, Telemetrie und Erfolgskriterien

Ein häufiger Fehler ist, mit „wir simulieren einen Angriff“ zu starten. Besser ist, die Übung als Validierung konkreter Kontrollen zu formulieren: „Wir prüfen, ob unser Netzwerk Monitoring eine Manipulation auf Layer 2 erkennt“ oder „Wir testen, ob unsere Application Logs Missbrauchsmuster auf Layer 7 differenzieren können“. Daraus ergeben sich Telemetrie-Anforderungen und Metriken.

Empfohlene Kernmetriken für Purple Teaming

• MTTD (Mean Time to Detect): Zeit von Start des Szenarios bis zur ersten belastbaren Erkennung.
• MTTR (Mean Time to Respond): Zeit bis zu einer wirksamen Eindämmung (Containment) oder stabilen Abwehrmaßnahme.
• Evidenzqualität: Sind Logs/Flows/Traces ausreichend, um Ursache und Blast Radius zu belegen?
• False-Positive-Rate: Wie viele Alerts entstehen ohne echten Missbrauch, und wie gut ist die Priorisierung?

Für ein einfaches Scoring können Sie Detection (D), Response (R) und Evidenz (E) gewichten. Das sorgt dafür, dass Teams nicht nur „einen Alert“ produzieren, sondern auch beweisfähig reagieren.

$\mathrm{Score}=wDD+wRR+wEE$

In der Praxis wählen Teams oft wD höher in frühen Reifephasen (erst einmal zuverlässig erkennen) und erhöhen später wE (Beweiskette/Forensik) sowie wR (automatisiertes Containment).

Layer 1: Physical – Szenarien für „Realitätschecks“

Layer 1 wird in vielen Cyber-Übungen ignoriert, obwohl physische Faktoren häufig Security- und Reliability-Incidents auslösen. Purple Teaming auf Layer 1 bedeutet nicht, Einbrüche zu „spielen“, sondern Kontrollen und Telemetrie rund um Infrastruktur, Cabling und Zugangsprozesse zu validieren.

• Szenario: Unautorisierte Patch-Änderung – Prüfen Sie, ob Patch-Panel-Änderungen dokumentiert, auditiert und zeitnah bemerkt werden (z. B. durch Asset-Prozesse, Kamera-Review, Port-Status-Anomalien).
• Szenario: Strom-/Klimaanomalie – Simulieren Sie einen Ausfall einer Kühlungseinheit oder UPS-Events und testen Sie, ob Security und SRE die gleiche Lageinterpretation teilen (Angriff vs. Defekt).
• Szenario: Rogue Device im Rack – Platzieren Sie ein autorisiertes Testgerät und prüfen Sie, ob Inventar, NAC/NDR und Change-Prozess konsistent reagieren.

Für Governance und Kontrollen bieten sich Frameworks wie die CIS Controls als Orientierung an, um Layer-1-nahe Prozesse (Asset Management, Access Control, Monitoring) sauber zu verankern.

Layer 2: Data Link – Szenarien rund um Switching, ARP und Segmentgrenzen

Layer 2 ist ideal für Purple-Team-Training, weil viele interne Missbrauchsfälle „leise“ starten: falsche Zuordnungen, Segment-Fehlkonfigurationen oder Man-in-the-Middle-Muster, die auf höheren Schichten nur als diffuse Fehler erscheinen. Ziel ist nicht, Angriffstechniken zu „lehren“, sondern Erkennung und Hardening-Validierung zu trainieren.

• Szenario: ARP-Anomalien im Segment – Validieren Sie, ob NDR/Switch-Telemetrie ARP-Änderungen, IP/MAC-Mismatches oder ungewöhnliche ARP-Raten erfasst und in einen Use Case übersetzt.
• Szenario: Rogue DHCP-Indizien – Prüfen Sie, ob DHCP-Server-Quellen validiert werden, ob „DHCP Snooping“-ähnliche Kontrollen wirksam sind und ob Clients mit ungewöhnlichen Leases auffallen.
• Szenario: STP-/Topology-Instabilität – Simulieren Sie eine unerwartete Topologieänderung, um zu testen, ob Root-Guard/BPDU-Protections und Monitoring greifen.

Erfolgskriterien auf Layer 2

• Erkennung basiert auf Switch-/NDR-Signalen, nicht nur auf Endgerätebeschwerden.
• Containment ist klar: Port-Shutdown, Quarantäne-VLAN, NAC-Policy oder physische Trennung.
• Evidenz enthält Port, VLAN, MAC, Zeitfenster und betroffene Hosts (Blast Radius).

Layer 3: Network – Szenarien für IP, Routing und Egress-Kontrolle

Auf Layer 3 lassen sich hervorragend „Missbrauch vs. Fehlkonfiguration“ trainieren: Ist ein ungewöhnlicher Traffic ein Routing-Problem oder eine bewusste Umgehung? Purple-Team-Übungen auf Layer 3 sollten sowohl interne Ost-West-Flüsse als auch Nord-Süd-Verkehr berücksichtigen.

• Szenario: IP-Spoofing-Indizien – Testen Sie, ob Anti-Spoofing-Kontrollen (z. B. Ingress-Filter, uRPF-Strategien in passenden Bereichen) Alarme und verwertbare Logs liefern.
• Szenario: Route-Policy-Drift – Simulieren Sie eine unbeabsichtigte Änderung einer Route-Map/ACL und prüfen Sie, ob Config-Drift-Detektion und Change-Korrelation funktionieren.
• Szenario: Auffälliger Egress – Validieren Sie, ob DNS/Proxy/Firewall-Logs eine plötzliche Zunahme von ausgehenden Verbindungen zu unbekannten Zielen sichtbar machen.

Telemetrie, die sich hier besonders lohnt

• NetFlow/sFlow/IPFIX für Volumen- und Pattern-Erkennung
• Firewall-Logs mit Session-Metadaten (Allow/Deny, Rule-ID, NAT-Mapping)
• DNS-Query-Logs (inklusive Response-Codes und ungewöhnlicher Query-Längen)

Layer 4: Transport – Szenarien für State, SYN-Patterns und DDoS-ähnliche Belastung

Layer 4 ist die Domäne von „State“: Verbindungen, Handshakes und Tabellen. Hier zeigt sich schnell, ob Load Balancer, Firewalls und Services robuste Limits haben und ob Telemetrie zwischen legitimen Peaks und Missbrauch differenziert. Auch hier gilt: Die Übung sollte kontrolliert und abgesichert sein, um keine unbeabsichtigten Ausfälle zu verursachen.

• Szenario: State-Table-Pressure – Prüfen Sie, ob Firewalls/Load Balancer eine Erschöpfung der Session-Tabellen früh signalisieren und ob Response-Pläne (Rate Limits, SYN-Cookies, Priorisierung) greifen.
• Szenario: Port-Scanning-Indizien – Validieren Sie „Low-Noise“-Detection: Viele Zielhosts bei niedriger Rate, ungewöhnliche Portkombinationen, fehlende App-Follow-ups.
• Szenario: QUIC/UDP-Visibility – Testen Sie, ob Monitoring auch bei UDP-basierten Protokollen sinnvolle Metadaten und Anomalien liefert (ohne Payload-Inspektion).

Erfolgskriterien auf Layer 4

• Der Use Case unterscheidet „Verbindungsaufbau“ (Handshake) von „Traffic“ (Datenfluss).
• Containment vermeidet Kollateralschäden (z. B. gezielte Rate Limits statt pauschaler Block).
• Evidence enthält Zeitreihen: Connection-Rate, Resets, Retransmits, Drops, Top-Sources/Targets.

Layer 5: Session – Szenarien für Auth-Session, Token und Remote Access

Layer 5 wird im Enterprise-Alltag oft über Authentisierung, Sitzungsverwaltung und Remote Access sichtbar: VPN, RDP/VDI, SSO-Sessions oder langlebige Service-Tokens. Purple-Team-Training auf dieser Ebene ist besonders wertvoll, weil viele Angriffe nicht durch „Exploit“, sondern durch Missbrauch legitimer Sessions eskalieren.

• Szenario: Anomale Remote-Access-Session – Prüfen Sie, ob VPN-/RDP-Logs Session-Start, Device-Identität, MFA-Events, Geo-Anomalien und Session-Dauer aussagekräftig erfassen.
• Szenario: Session-Persistence-Indizien – Validieren Sie, ob ungewöhnlich lange Sessions, ungewöhnliche Token-Renewals oder parallele Sessions eines Accounts auffallen.
• Szenario: Lateral Movement Muster – Testen Sie, ob Korrelation zwischen Session-Events und Netzwerkzugriffen auf neue Zielsysteme (SMB/LDAP/RDP) sauber funktioniert.

Für moderne Identity-Bedrohungsmodelle und Kontrollideen sind die Best Practices rund um OAuth/OIDC bei oauth.net ein nützlicher Einstieg, während Application-Sicherheitsaspekte häufig in der OWASP Top 10 strukturiert werden.

Layer 6: Presentation – Szenarien für TLS, Zertifikate und Trust Chains

Layer 6 ist in der Praxis „Kryptografie und Vertrauensmodell“: TLS-Versionen, Cipher Suites, Zertifikatsketten, mTLS und Rotation. Purple-Team-Übungen auf Layer 6 sind extrem praxisnah, weil Fehlkonfigurationen hier schnell sowohl Security- als auch Availability-Auswirkungen haben.

• Szenario: Zertifikatsanomalie – Testen Sie, ob Zertifikatswechsel (geplant) sauber überwacht wird: Ablaufdaten, Chain-Änderungen, unbekannte Issuer, unerwartete SANs.
• Szenario: TLS-Policy-Regression – Simulieren Sie eine zu „lockere“ oder inkonsistente Cipher-Policy in einer Staging-Umgebung und prüfen Sie, ob Monitoring und Gatekeeping (CI/CD Checks) das erkennt.
• Szenario: mTLS-Rotation – Validieren Sie den operativen Ablauf: Rollout, Trust-Store-Updates, Fehlertoleranz, Observability (Handshake-Fehler, Mutual Auth Failures).

Was Sie auf Layer 6 zwingend messen sollten

• TLS-Version, Cipher Suite, SNI/ALPN (sofern sichtbar), Zertifikatsfingerprint
• Handshake-Fehlercodes, Erfolgsraten, Verteilung nach Client/Service
• Ablaufdaten (NotAfter), Issuer/Subject-Änderungen und Kettenvalidierung

Für das Verständnis von TLS-Mechanismen und Standardisierung sind RFCs eine solide Quelle; ein guter Startpunkt ist die Übersicht bei RFC Editor, wenn Sie Protokoll-Details nachvollziehen möchten.

Layer 7: Application – Szenarien für Abuse, APIs, Bots und Logging-Qualität

Layer 7 ist meist der sichtbare „Business-Schaden“: Kontoübernahmen, API-Missbrauch, Request-Flooding, SSRF-Indizien oder Datenabfluss über legitime Endpunkte. Purple-Team-Übungen sollten hier besonders auf „nutzbares Logging“ zielen: Was ist tatsächlich korrelierbar und beweisfähig, ohne Datenschutz und Compliance zu verletzen?

• Szenario: Bot vs. legitime Automatisierung – Validieren Sie, ob Sie bösartige Bots (Credential Stuffing, Carding, Scraping) von echten Integrationen unterscheiden können (Header, Verhalten, Rate, Auth, Fehlerprofile).
• Szenario: API-Gateway als Control Point – Testen Sie Rate Limits, AuthN/Z, Quotas, Schema-Validierung und ob Gateway-Logs die notwendigen Felder enthalten (Client-ID, Token-Claims, Route, Latenz, Response-Code).
• Szenario: SSRF-Indizien in Cloud-Umgebungen – Üben Sie Erkennungsmuster auf Metadaten-Zugriffe, ungewöhnliche Zielhosts/IP-Ranges und anomale Server-seitige Requests (ohne Exploit-How-to).
• Szenario: Request-Anomalien – Prüfen Sie, ob WAF/Ingress-Layer ungewöhnliche Request-Formen erkennt (z. B. inkonsistente Header/Längen) und ob die Anwendung aussagekräftige Fehlerlogs liefert.

Minimal-Set an Feldern für „nutzbares“ Layer-7-Logging

• Request-ID (End-to-End), Timestamp mit Zeitzone, Client-Identifier (nicht nur IP), Auth-Kontext (z. B. User/Service-ID)
• Route/Endpoint, Methode, Statuscode, Latenz, Response-Größe
• Rate-Limit-Entscheidung, WAF-Decision, Fehlerklasse (4xx/5xx) und interne Error-Codes
• Für APIs: Token-Audience/Issuer, Scopes/Roles (in datensparsamem Umfang), Tenant/Org-Kontext

Übergänge zwischen Schichten: Die „Ketten“-Übung als Reifegrad-Booster

Der größte Lerneffekt entsteht oft nicht in der Einzelschicht, sondern in der Korrelation. Planen Sie mindestens ein Szenario, das bewusst mehrere OSI-Schichten verbindet. Beispiel: Ein Layer-2-Indiz (Segment-Anomalie) führt zu Layer-3-Egress-Auffälligkeiten und endet in Layer-7-Abuse-Signalen. Das trainiert nicht nur Technik, sondern auch Zusammenarbeit: Wer übernimmt Incident Command? Welche Daten werden zuerst gesichert? Welche Teams liefern welche Evidenz?

• Kette A: Segment-Anomalie (L2) → ungewöhnlicher Egress (L3) → erhöhte Verbindungsraten (L4) → API-Missbrauch (L7)
• Kette B: Remote-Access-Anomalie (L5) → TLS-Handshake-Fehler/Policy-Drift (L6) → Auth-Fehler und verdächtige Requests (L7)
• Kette C: Zertifikatswechsel (L6) → Load-Balancer-State-Pressure (L4) → Ausfallbild, das wie Reliability aussieht, aber Security-Prozess erfordert

Durchführung: Rollenmodell und Ablauf in 90–180 Minuten

Eine OSI-basierte Purple-Team-Übung lässt sich gut in kompakten Sessions durchführen. Wichtig ist ein klarer Ablauf, damit nicht nur „getestet“, sondern auch gelernt wird. Typisch sind 90 bis 180 Minuten pro Block, abhängig von Komplexität und Anzahl der beteiligten Systeme.

• Kick-off (10–15 Min.): Scope, Ziele, Sicherheitsvorkehrungen, Abbruchkriterien, Kommunikationskanal.
• Baseline (10–15 Min.): Normalzustand messen (Traffic, Logs, Alerts), damit Anomalien später eindeutig sind.
• Execution (30–90 Min.): Szenario durchführen, Blue Team beobachtet live, Purple moderiert, Red liefert kontrollierte Stimuli.
• Validation (20–40 Min.): Wurden Use Cases getriggert? Sind die Daten vollständig? Können Teams Ursache/Scope belegen?
• Fix & Re-test (20–40 Min.): Kleine Anpassungen direkt testen (Regeln, Parser, Dashboards, Limits, Alerts).

Auswertung ohne „Fazit“: Verbesserungen als Backlog mit Priorisierung

Damit Purple Teaming nicht zu einem isolierten Event wird, muss jedes Ergebnis in eine konkrete Verbesserung übergehen: Parser ergänzen, Felder loggen, Dashboards bauen, Playbooks präzisieren, Kontrollen härten, Zuständigkeiten klären. Besonders wirkungsvoll ist ein Backlog, das nicht nur „fehlender Alert“ enthält, sondern auch den Wert für Incident Response beschreibt: Welche Evidenz fehlte, welche Entscheidung war dadurch nicht möglich, welches Risiko entsteht daraus?

• Telemetrie-Fix: fehlende Felder, falsche Zeitstempel, unklare IDs, keine Korrelation über Systeme hinweg
• Detection-Fix: Regeln zu generisch, zu viele False Positives, fehlende Baselines, fehlender Layer-Kontext
• Response-Fix: kein klarer Containment-Schritt, fehlende Automation, unklare Freigabeprozesse
• Hardening-Fix: fehlende Guardrails (z. B. Policy-Checks), unsichere Defaults, inkonsistente Segmentierung

Wenn Sie Purple Teaming zusätzlich in eine Zero-Trust-Strategie einbetten möchten, hilft ein Blick auf NIST Zero Trust Architecture, weil dort Trust Boundaries, Policy Enforcement Points und kontinuierliche Verifikation strukturiert beschrieben werden. Genau diese Elemente lassen sich in OSI-Szenarien übersetzen und Schritt für Schritt trainieren.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.