OSI-basiertes „Security Runbook“ für SecOps erstellen

Ein OSI-basiertes Security Runbook für SecOps ist ein praxisnahes Nachschlagewerk, das Security-Analysten im Incident schnell von Symptomen zu belastbaren Maßnahmen führt. In vielen Organisationen scheitert Reaktion nicht an fehlenden Tools, sondern an fehlender Struktur: Alerts sind unvollständig, Teams springen zwischen Netzwerk- und Applikationssicht, und Entscheidungen werden ohne klare Beweise getroffen. Das OSI-Modell schafft hier eine gemeinsame Sprache, um Beobachtungen konsistent zu klassifizieren: Ist es ein Layer-1/2-Problem (Physik/Switching), ein Layer-3/4-Thema (Routing/Transport), oder steckt ein Layer-7-Missbrauch dahinter (HTTP-API, Auth, Payload)? Ein gutes Runbook verbindet diese Einordnung mit operativen Schritten: welche Daten zuerst sichern, welche Checks sind „low risk“ und schnell, welche Maßnahmen sind potenziell disruptiv, und wie eskaliert man sauber an Netzbetrieb, Plattformteams oder Application Owner. Dieser Leitfaden zeigt, wie Sie ein OSI-basiertes Security Runbook so aufbauen, dass es im Alltag genutzt wird: kurz genug für den Ernstfall, aber detailliert genug für konsistente Entscheidungen, reproduzierbare Evidence und eine verlässliche Incident-Kommunikation.

Zielbild: Was ein Security Runbook für SecOps liefern muss

Ein produktionsreifes Runbook ist mehr als eine Checkliste. Es sollte bei jedem Incident vier Kernfragen beantworten:

• Was ist los? (Symptome, Scope, betroffene Assets, Zeitfenster)
• Wo liegt es im Stack? (OSI-Layer als gemeinsame Klassifikation)
• Welche Beweise sichern wir? (Logs, Flows, PCAP, System-Events – mit Priorität)
• Welche Maßnahmen sind sicher? (Containment/Eradication/Recovery mit Risikoabschätzung)

Als etablierte Grundlage für Incident Response Prozesse und Phasen (Preparation, Detection/Analysis, Containment, Eradication, Recovery) eignet sich NIST SP 800-61. Ihr OSI-basiertes Runbook sollte diese Phasen nicht ersetzen, sondern mit einer schnellen technischen Einordnung verknüpfen.

Runbook-Design: Struktur, die im Stress funktioniert

Damit das Runbook im Ernstfall genutzt wird, braucht es eine klare, wiederkehrende Struktur. Bewährt hat sich ein Aufbau mit drei Ebenen:

• Level 1: Triage-Playbook (10–15 Minuten, minimal disruptiv)
• Level 2: OSI-Layer-Playbooks (tiefergehende Checks je Layer)
• Level 3: Incident-Typen (z. B. DDoS, Credential Stuffing, Lateral Movement, Data Exfiltration)

Wichtig: Jede Seite sollte dieselben Elemente enthalten – „Signal“, „Beweise“, „Entscheidung“, „Aktion“, „Eskalation“, „Rollback“. So können neue Teammitglieder konsistent arbeiten, und erfahrene Analysten verlieren keine Zeit mit Formatwechseln.

Vorbereitung: Voraussetzungen, ohne die ein Runbook nicht trägt

Ein OSI-basiertes Runbook lebt von Datenqualität und Zugriff. Ohne vorbereitete Telemetrie bleibt es theoretisch. Minimum-Voraussetzungen:

• Asset-Inventar: Owner, Kritikalität, Umgebung (Prod/Non-Prod), Tags (Business Service)
• Netzwerk-Topologie: Zonen/VRFs/VPCs, Trust Boundaries, zentrale Gateways/Firewalls
• Log-Pipeline: zentrale Sammlung, Zeit-Synchronisierung, Retention, Zugriffskontrolle
• Flow-Daten: NetFlow/sFlow/IPFIX oder Cloud Flow Logs an Boundaries
• Frontdoor-Logs: WAF/API-Gateway/Reverse Proxy mit request_id/trace_id
• Identity-Telemetrie: IdP/SSO-Events, MFA-Events, privilegierte Sessions

Für Angreifer-Techniken und eine gemeinsame Taxonomie, die sich gut mit Telemetrie mappen lässt, ist MITRE ATT&CK hilfreich, insbesondere wenn Sie OSI-Layer-Playbooks später mit Use Cases verbinden.

Das Kernstück: OSI-basierte Triage in 12 Minuten

Dieses Triage-Playbook ist bewusst kurz und eignet sich als Einstieg bei fast jedem Alert. Ziel ist eine erste Hypothese und ein sicheres Evidence-Minimum.

Schritt 1: Scope und Zeitfenster fixieren

• Startzeit des Symptoms (erstes Alert-Event) und aktueller Status (aktiv/abklingend)
• Betroffene Assets (IPs, Hosts, Services, Accounts) und betroffene Zonen
• Impact-Indikatoren: erhöhte Fehler, Login-Fails, Drop-Spikes, ungewöhnlicher Egress

Schritt 2: Evidence-Minimum sichern

• Flow-Snapshot für betroffene Assets (Top Destinations, Ports, Byte/Packet Volumen)
• Firewall/WAF decisions für das Zeitfenster (allow/deny/block, rule_id)
• Auth-Events für relevante Accounts (Login, MFA, Token, Anomalien)
• System-/Endpoint-Signale (wenn vorhanden): neue Prozesse, neue Verbindungen, EDR-Detections

Schritt 3: OSI-Layer-Hypothese wählen

• L1/L2: Link flaps, MAC flapping, STP-Ereignisse, Broadcast/ARP-Anomalien
• L3: Routing-Änderungen, Route Leak, asymmetrische Pfade, VRF-Misroute
• L4: SYN-Flood, Retransmissions, Session-Reset-Spikes, Port-Scans
• L7: HTTP 4xx/5xx Muster, WAF blocks, API abuse, verdächtige Payloads

Schritt 4: Entscheidung „Security vs. Reliability“ transparent treffen

Eine klare Trennlinie ist nicht immer möglich, aber eine strukturiert begründete Entscheidung spart Zeit. Nutzen Sie eine leichte, nachvollziehbare Einstufung:

$S=\frac{E\cdot C}{U+1}$

• E: Evidenz für adversarial Verhalten (z. B. Scans, C2-Beaconing, Auth-Anomalien)
• C: Confidence der Daten (mehrere Quellen, konsistente Korrelation)
• U: Unsicherheit (fehlende Logs, unklare Topologie, widersprüchliche Metriken)

Der Score ist kein „Beweis“, aber ein Hilfsmittel, um Eskalation, Kommunikationsstil und nächste Schritte zu standardisieren.

Layer 1: Physikalische Ebene – Security-relevant, wenn Verfügbarkeit manipuliert wird

L1-Probleme sind selten direkt „Security“, aber sie können durch Sabotage, Fehlverkabelung oder gezielte Störungen verursacht werden. Runbook-Ziel: schnell erkennen, ob es ein lokales Infrastrukturproblem oder ein Muster ist.

• Symptome: Link flaps, Interface down/up, optische Fehler (CRC/FCS), Strom-/Transceiver-Alarme
• Evidence: Interface Counters, Syslogs, transceiver diagnostics, Zeitkorrelation über mehrere Ports
• Sichere Maßnahmen: Port isolieren, redundanten Pfad nutzen, Maintenance prüfen, NOC eskalieren
• Risky Maßnahmen: Umstecken/Neukonfiguration in Produktion ohne Change-Fenster

Layer 2: Data Link – ARP, MAC und Broadcast als Angriffsfläche

L2 ist für SecOps wichtig, weil lokale Angriffe (ARP Spoofing, MAC Flooding) oder Fehlkonfigurationen (Loops) sehr schnell zu großflächigen Störungen führen können. Ein OSI-basiertes Runbook sollte L2-Symptome klar von L3/L7 trennen.

• Symptome: Broadcast-Storm, MAC flapping, ungewöhnliche ARP-Raten, STP Topology Changes
• Evidence: Switch Logs (STP, MAC table changes), ARP tables, SPAN/ERSPAN Samples
• Sichere Maßnahmen: Storm Control prüfen, Port Security/Rate Limits aktivieren, betroffene VLANs eingrenzen
• Eskalation: Netzwerkteam, wenn Topologie-Änderungen oder Loops wahrscheinlich sind

Layer 3: Network – Routing, VRF, Leaks und „falsche Wege“

Auf L3 entscheidet sich häufig, ob ein Incident groß wird: Route Leaks, VRF-Verwechslungen, falsch gesetzte Prefix-Lists oder asymmetrische Pfade können Security-Signale erzeugen, die wie Angriffe aussehen – oder echte Angriffe verschleiern.

• Symptome: plötzlicher Pfadwechsel, Erreichbarkeit nur aus bestimmten Netzen, ungewöhnliche Egress-Routen
• Evidence: RIB/FIB-Checks, BGP-Updates, Prefix Count Anomalien, VRF-Route-Targets
• Sichere Maßnahmen: Policy-Diff prüfen, Prefix Limits/Max Prefix kontrollieren, „known good“ Routen vergleichen
• Risky Maßnahmen: globale Route Withdraws ohne klaren Rollback

Layer 4: Transport – TCP/UDP, DDoS-Muster, Retransmissions und Scans

L4 ist der Bereich, in dem Security- und Reliability-Symptome oft kollidieren. Ein SYN-Flood kann wie „Server down“ aussehen, Retransmissions können Routing-/MTU-Probleme maskieren, und aggressive WAF/Firewall-Settings können Session-Resets erzeugen.

• Symptome: SYN backlog, Connection timeouts, RST-Spikes, UDP-Flood, Port-Scan-Muster
• Evidence: Conntrack/Session tables, SYN/ACK-Raten, TCP Flag Statistiken, PCAP-Samples
• Sichere Maßnahmen: Rate Limits (staged), DDoS-Scrubbing aktivieren, Canary-Blocking nach ASN/Geo (wenn begründet)
• Risky Maßnahmen: pauschales Blocken großer Netze ohne Impact-Abschätzung

Layer 5/6: Session und Presentation – TLS als Dreh- und Angelpunkt

In modernen Umgebungen ist TLS ein zentraler Control Point: Ohne Klartext sinkt Detektionsfähigkeit, mit Entschlüsselung steigt Betriebs- und Datenschutzkomplexität. Das Runbook sollte deshalb klare Regeln enthalten, wann TLS-Themen primär Reliability (Handshake-Failures) und wann Security (MITM-Indikatoren, verdächtige Zertifikate) sind.

• Symptome: TLS handshake failures, Zertifikatsfehler, plötzlicher Wechsel von TLS-Version/Cipher, SNI-Anomalien
• Evidence: Gateway/WAF TLS-Metriken, ClientHello/ServerHello im PCAP, Zertifikatsketten
• Sichere Maßnahmen: Zertifikats- und Chain-Checks, OCSP/CRL-Connectivity prüfen, Rollout-Rücknahme bei fehlerhafter Rotation

Für TLS-Grundlagen ist RFC 8446 (TLS 1.3) eine belastbare Referenz.

Layer 7: Application – WAF, API Abuse, Auth und Payloads

L7 ist für SecOps häufig der „Hauptarbeitsbereich“. Hier entscheidet sich, ob ein Alert echte Ausnutzung, Missbrauch (Abuse) oder ein Fehlkonfigurationsproblem (z. B. neue WAF-Regel) ist. Das Runbook sollte L7 explizit mit Business-Flows verbinden, weil Outages hier schnell Umsatz und Nutzererlebnis treffen.

• Symptome: HTTP 401/403-Spikes, 5xx-Spikes, ungewöhnliche Request-Raten, WAF block-rate steigt, API errors
• Evidence: WAF/Gateway Logs (rule_id, action), request_id/trace_id Korrelation, App Logs, Auth Logs
• Sichere Maßnahmen: neue WAF-Regeln zuerst log-only, scoped exceptions statt global allow, Rate Limits pro Route
• Risky Maßnahmen: WAF komplett deaktivieren oder „allow all“ ohne temporäre Begrenzung

Für L7-Angriffsflächen ist OWASP Top 10 als Referenz sinnvoll, insbesondere zur Einordnung typischer Kategorien wie Injection, Broken Access Control oder Security Misconfiguration.

Containment nach OSI: Maßnahmen-Matrix mit Risikoetikett

Ein OSI-basiertes Runbook sollte Containment-Maßnahmen nicht nur listen, sondern nach „Disruption-Risiko“ labeln. Ein praxistaugliches Schema:

• Grün: Beobachten/Loggen/Scope reduzieren ohne Traffic-Block (Low Risk)
• Gelb: Eingriffe mit begrenztem Scope (Canary, einzelne Route, einzelnes Subnet)
• Rot: Globale Maßnahmen (large-scale blocks, Policy-Reverts, deaktivierte Frontdoors)

Diese Label helfen, Entscheidungen konsistent zu kommunizieren und Rollback-Pfade im Runbook verpflichtend zu machen.

Evidence Pack: Welche Daten pro OSI-Layer standardmäßig gesichert werden

SecOps braucht in der Regel nicht „mehr Daten“, sondern ein standardisiertes Evidence Pack. Definieren Sie pro Layer ein Minimum, das in jedem Incident gesichert wird:

• L1: Interface Status, Fehlerzähler, Link-Events, Zeitfenster
• L2: MAC table changes, ARP tables, STP Events, betroffene VLANs
• L3: Routing table snapshots (RIB/FIB), BGP Updates/Policy-Diffs, VRF Mapping
• L4: Session/Conntrack Stats, TCP Flag Summaries, PCAP-Samples (klein, gezielt)
• L5/6: TLS Handshake Metriken, Zertifikatsketten, SNI/ALPN Informationen
• L7: WAF decisions, Gateway access logs, App errors, Auth events, request_id/trace_id Korrelation

Die Runbook-Qualität steigt massiv, wenn Sie diese Packs als Automatisierung („One-Click Evidence“) bereitstellen und in Ihr SIEM/Case-Management integrieren.

Eskalation und Zusammenarbeit: Übergaben, die keine Zeit kosten

OSI-basierte Runbooks sind besonders stark, wenn sie Übergaben zwischen SecOps, NOC und Plattformteams standardisieren. Definieren Sie für jede Eskalation ein Minimum an Übergabeinformationen:

• Symptom-Statement: „Was sieht der Nutzer/Service?“ in einem Satz
• OSI-Hypothese: aktuell vermuteter Layer + alternative Hypothesen
• Evidence Links: Flow-Snapshot, Firewall/WAF Logs, Auth-Events, PCAP falls vorhanden
• Impact: betroffene Services/Regionen, aktuelle Mitigation, Risiko bei weiteren Maßnahmen
• Next Action: konkrete Frage/Bitte an das Eskalationsteam (nicht „Bitte prüfen“)

Runbook-Qualität messen: Operative KPIs für SecOps

Damit ein Runbook nicht veraltet, müssen Sie Wirkung messen. Sinnvolle KPIs sind nicht „Anzahl Seiten“, sondern operative Outcomes:

• MTTA (Mean Time to Acknowledge) und MTTI (Mean Time to Identify)
• MTTR (Mean Time to Restore) mit getrenntem Tracking für Security- vs. Reliability-Fälle
• False Positive Rate pro Control Point (WAF rules, IDS signatures, anomaly models)
• Coverage: Anteil Incidents, bei denen das Evidence Pack vollständig vorhanden war
• Rollback Rate: wie oft Changes zurückgenommen werden mussten (Signal für Change-Review-Reife)

Automatisierung: OSI-Runbook als „Policy“ statt als Dokument

Der langfristige Reifegrad ist erreicht, wenn das Runbook nicht nur gelesen, sondern ausgeführt wird: Buttons, Queries, Automations. Typische Automatisierungsbausteine:

• Standard-Queries pro OSI-Layer im SIEM (Flows, Firewall decisions, Auth anomalies)
• Auto-Enrichment: Asset-Owner, Kritikalität, Zone/VRF, zuletzt deployte Changes
• Guardrails: Canary-Blocking, WAF log-only Phasen, automatische Abbruchkriterien
• Evidence Export: automatisiertes RCA-Paket (Logs, Graphen, Zeitlinien) für Postmortems

Als methodischer Unterbau für zuverlässige Betriebspraktiken und kontrollierte Changes kann das Google SRE Book als Referenz dienen, insbesondere für Change-Management, Monitoring und Incident-Prozesse.

Outbound-Quellen für belastbare Grundlagen

Für Incident Response Prozesse und Phasen ist NIST SP 800-61 eine etablierte Referenz. Für Zero-Trust-Prinzipien, Trust Boundaries und Identity-Fokus eignet sich NIST SP 800-207. Für Angreifer-Techniken, die Sie mit Netzwerk- und Security-Telemetrie mappen können, ist MITRE ATT&CK hilfreich. Für typische Webrisiken im Layer-7-Kontext dient OWASP Top 10 als praxisnahe Orientierung. Für TLS-Grundlagen und Handshake-Verhalten ist RFC 8446 (TLS 1.3) eine technische Referenz, und für DNS-Grundlagen eignen sich RFC 1034 sowie RFC 1035.

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.