OSI-basiertes Network Threat Modeling: Schnell die Attack Surface bestimmen

OSI-basiertes Network Threat Modeling ist ein pragmatischer Ansatz, um in kurzer Zeit die Attack Surface (Angriffsfläche) eines Netzwerks zu bestimmen und Sicherheitsmaßnahmen zielgerichtet zu priorisieren. Anstatt Threat Modeling ausschließlich aus Applikationssicht zu betreiben, strukturiert dieser Leitfaden die Analyse entlang der OSI-Schichten L1–L7: Wo existieren Eingänge (Interfaces), welche Protokolle und Zustände sind exponiert, welche Trust-Boundaries werden überquert, und welche Kontrollen wirken tatsächlich an der Stelle, an der ein Angriff stattfindet? Das Ergebnis ist eine schnell erfassbare, technisch nachvollziehbare Landkarte der Risiken – nützlich für Security Engineers, Netzwerkteams, SRE und Architektur gleichermaßen. Besonders in hybriden Umgebungen (On-Prem, Cloud, Edge, SaaS) hilft das OSI-Modell, die Komplexität zu ordnen: Ein Problem, das sich als Layer-7-Fehler zeigt, kann seine Ursache in Layer 3 (Misroute, Segmentierungsfehler) oder Layer 4 (Stateful-Firewall/Conntrack) haben. Dieser Artikel beschreibt Schritt für Schritt, wie Sie mit OSI-basiertem Network Threat Modeling schnell die Attack Surface bestimmen, die wichtigsten Angriffsvektoren pro Layer erfassen und daraus umsetzbare Prioritäten für Hardening, Detection und Incident Response ableiten.

Warum OSI als „Schnellstruktur“ für Threat Modeling funktioniert

Threat Modeling scheitert in der Praxis selten am Willen, sondern an Zeit und Unübersichtlichkeit: zu viele Komponenten, zu viele Datenflüsse, zu viele Abhängigkeiten. Das OSI-Modell zwingt zur Ordnung. Es trennt technische Angriffsflächen nach Schichten und macht sichtbar, ob Sicherheitsmaßnahmen nur „oben“ (L7) existieren, während „unten“ (L2/L3) zentrale Kontrollpunkte fehlen. Gleichzeitig passt OSI gut zu Netzwerkrealität: Viele Angriffe nutzen nicht einen einzelnen Layer, sondern kombinieren Effekte (z. B. L2-Spoofing → L3-Lateral Movement → L7-Privilege Escalation). Mit OSI als Gerüst können Sie in Minuten die wichtigsten Fragen beantworten:

• Wo sind externe und interne Eintrittspunkte? (Ports, Peering, VPN, WLAN, API-Gateways)
• Welche Trust-Boundaries werden überschritten? (Tenant-Grenzen, VRFs, Zonen, VPCs)
• Welche Protokolle sind angreifbar oder missbrauchbar? (ARP, BGP, DNS, TLS, HTTP)
• Welche Kontrollen greifen an welcher Stelle? (Segmentation, ACLs, mTLS, WAF, NAC)

Für Threat Modeling als Methode ist NIST SP 800-154 (Guide to Data-Centric System Threat Modeling) ein hilfreicher Referenzrahmen, auch wenn Sie den OSI-Fokus ergänzend einsetzen.

Vorbereitung: Minimaler Input für eine schnelle Attack-Surface-Bestimmung

OSI-basiertes Network Threat Modeling kann sehr schlank starten. Für einen ersten Durchlauf reichen meist vier Informationsblöcke, die Sie in 30–60 Minuten zusammentragen können:

• Topologie grob: Edge/Ingress, Core, DC/Cloud Segmente, zentrale Gateways.
• Kritische Assets: IdP, DNS, Load Balancer, API-Gateways, Datenbanken, Admin-Zugänge, Routing-Knoten.
• Datenflüsse: Nord-Süd (Internet ↔ intern), Ost-West (Service ↔ Service), Management (Admin ↔ Geräte).
• Kontrollen & Telemetrie: Firewalls/SGs, NAC, Logging/Flow, Zertifikate/mTLS, Alarmierung.

Wichtig ist nicht Vollständigkeit, sondern Nutzbarkeit: Der erste Output soll die größten Angriffsflächen und Lücken sichtbar machen. Danach iterieren Sie.

Das OSI-Threat-Model-Canvas: Ein wiederholbares Arbeitsformat

Damit das Modell nicht zu einer Textwüste wird, empfiehlt sich ein einfaches Canvas pro Layer mit festen Feldern. Dieses Canvas lässt sich auf einer Seite dokumentieren und später verfeinern.

• Entry Points: Welche Interfaces/Protokolle sind erreichbar?
• Assets: Welche Komponenten und Daten sind betroffen?
• Trust Boundaries: Welche Zonen/Identitätsgrenzen werden überquert?
• Threats: Welche Angriffsmuster sind typisch?
• Controls: Welche Kontrollen existieren, wo greifen sie?
• Evidence: Welche Logs/Metriken/Flows beweisen Angriff oder Wirksamkeit?

Wenn Sie die Attack Surface „schnell“ bestimmen wollen, priorisieren Sie Entry Points und Trust Boundaries. Alles andere folgt daraus.

Layer 1: Physical Attack Surface (L1)

Layer 1 wird in der Netzwerksecurity häufig unterschätzt, ist aber die ultimative Angriffsfläche: physischer Zugriff kann höhere Layer umgehen. Die Attack Surface besteht aus Standorten, Racks, Cross-Connects und Management-Hardware.

• Typische Entry Points: Colocation-Zugänge, Remote Hands, ungesicherte Patchfelder, frei zugängliche Edge-Standorte.
• Threats: Rogue Taps, Manipulation von Verkabelung, Diebstahl von Geräten/Medien, Out-of-Band-Komponenten kompromittieren.
• Controls: Zutritt (MFA/Badges), Video, Rack Locks, Tamper-Evidence, Asset-Tracking, getrennte OOB-Netze.
• Evidence: Zutrittsprotokolle, Kamera-Events, Inventarabweichungen, Change-Records für Cross-Connects.

Für den „Schnelldurchlauf“ ist L1 häufig nur ein Risiko-Flag: Welche Sites sind besonders exponiert (Edge, Colocation, Shared Spaces)?

Layer 2: L2 Attack Surface (Broadcast-Domänen, Spoofing, Loops)

Layer 2 ist die Angriffsfläche für Spoofing und lokale Manipulation. Besonders relevant sind Campus-Netze, DC-Fabrics und geteilte L2-Domänen. Die wichtigste Frage lautet: Wo kann ein Angreifer L2 sprechen (Ethernet/WLAN), und wie stark ist dieser Bereich segmentiert?

• Entry Points: Switchports, WLAN, ungetaggte VLANs, Trunks, L2-Interconnects zwischen Zonen, Hypervisor vSwitch.
• Threats: ARP Spoofing, Rogue DHCP, MAC Flooding, VLAN Misconfig/VLAN-Hopping, L2 Storms als DoS.
• Controls: 802.1X/NAC, Port Security, DHCP Snooping, Dynamic ARP Inspection, Storm Control, PVLANs, BPDU Guard.
• Evidence: ARP/MAC-Table-Anomalien, DHCP-Bindings, STP-Topology-Changes, Broadcast-Rate-Spikes.

ARP als Grundlage ist in RFC 826 (ARP) beschrieben. Diese Referenz hilft, wenn Sie L2-Risiken und Gegenmaßnahmen technisch sauber begründen müssen.

Layer 3: L3 Attack Surface (Segmentierung, Routing-Integrität, Spoofing)

Layer 3 ist die zentrale Angriffsfläche für laterale Bewegung, Fehlsegmentierung und Routing-Manipulation. Für die schnelle Bestimmung der Attack Surface ist hier entscheidend: Welche Netze können miteinander sprechen, und wie wird das erzwungen?

• Entry Points: Internet Edge, Peering, VPN, Direct Connect/ExpressRoute, Inter-VRF-Services, NAT-Gateways, Transit-VPC/VNet.
• Threats: IP Spoofing, Route Leaks (intern), falsche VRF-Zuordnung („Tenant vertauscht“), Blackholing/Misrouting, unkontrollierte Anycast-Effekte.
• Controls: VRF/Zone-Segmentierung, ACLs/Security Groups, uRPF, Prefix-Filter, Route-Maps, kontrollierte Redistribution.
• Evidence: Prefix-Counts, RIB/FIB-Snapshots, Routing-Change-Events, Flow-Daten pro Interface/VRF.

Wenn BGP im Spiel ist, hilft RFC 4271 (BGP-4), um Risiken wie Policy-Fehler und Session-Stabilität präzise zu dokumentieren.

Layer 4: L4 Attack Surface (Statefulness, Ports, Exhaustion)

Layer 4 ist die Angriffsfläche für Port-basierte Zugriffe, Session-Exhaustion und DoS-Varianten, die Verbindungszustände ausnutzen. In der Praxis ist L4 stark von middleboxes geprägt: Firewalls, NAT, Load Balancer, Proxying. Das macht L4 zum häufigen Ursprung von „unerklärlichen“ Ausfällen, wenn Zustände nicht synchron sind (z. B. asymmetrisches Routing durch stateful Firewalls).

• Entry Points: offene Ports an Edge und intern, Load Balancer VIPs, Service Mesh Gateways, Admin-Ports, BGP/OSPF Nachbarschaften.
• Threats: SYN Flood, Session Table Exhaustion, Port Scans, Missbrauch exponierter Managementports, Timeout/State-Desync als Availability-Angriff.
• Controls: Stateful Policies, Rate Limiting, SYN Cookies/Proxy, Conntrack Limits, Segmentierung per Port, strikte Admin-Zugangswege.
• Evidence: Firewall Session Tables, NAT Port Utilization, TCP Retransmissions/Resets, Drop-Reasons (Policy/Policer/Queue).

Für TCP-Verhalten ist RFC 9293 (TCP) eine solide Grundlage, um Handshake- und Retransmission-Muster korrekt einzuordnen.

Layer 5: Session Attack Surface (Identität, Session-Lifecycle, Tokens)

Layer 5 wirkt abstrakter, ist aber für Security Engineers entscheidend: Sessions überdauern einzelne TCP-Verbindungen, werden zwischen Komponenten weitergegeben (Cookies, Tokens) und sind häufig das Ziel von Diebstahl oder Missbrauch. Für die Attack Surface zählen hier alle Mechanismen, die „wer bist du?“ und „bist du noch gültig?“ beantworten.

• Entry Points: SSO/IdP, Session Cookies, Refresh Tokens, API Tokens, Admin Sessions, Service-to-Service Identity.
• Threats: Session Hijacking, Replay, Token Leakage, Session Fixation, unzureichende Revocation.
• Controls: Token Rotation, kurze TTLs, Revocation, Device/Context Binding, sichere Cookie-Flags, step-up auth.
• Evidence: Auth-Logs, Token-Issuance/Revocation Events, ungewöhnliche Sessiondauer, Anomalie-Detektion.

Layer 6: Presentation Attack Surface (TLS, Zertifikate, Parser)

Layer 6 wird oft als „TLS-Layer“ betrachtet, umfasst aber generell Datenrepräsentation und Transformation: Verschlüsselung, Encoding, Serialisierung, Kompression. Die Attack Surface entsteht dort, wo Daten entschlüsselt, transformiert oder validiert werden (z. B. TLS-Termination am LB, Decompression im Proxy, Deserialization im Service).

• Entry Points: TLS Termination (Edge/LB), mTLS zwischen Services, Zertifikats-Distribution, Gateways mit Content-Transformation.
• Threats: Downgrade/Weak Ciphers, Zertifikatsmissbrauch, fehlende Validierung, Deserialization/Parser-Bugs, Kompressionsmissbrauch.
• Controls: TLS Policies (Version/Ciphers), mTLS, Zertifikatsrotation, Härtung von Parsern/Deserializern, sichere Defaults.
• Evidence: TLS Handshake Error Rates, Zertifikatsablauf-Events, mTLS Success/Fail, Fingerprint-Trends (kontextabhängig).

Für TLS 1.3 ist RFC 8446 (TLS 1.3) eine verlässliche Referenz zur technischen Argumentation von Policies und Fehlersignaturen.

Layer 7: Application Attack Surface (HTTP, APIs, Business Logic)

Layer 7 ist oft die sichtbarste Attack Surface: URLs, APIs, Parameter, AuthN/AuthZ, Uploads, Business Logik. Für OSI-basiertes Network Threat Modeling geht es hier weniger um vollständiges App-Threat-Modeling, sondern um das Netzwerk-nahe Verständnis: Welche L7-Eingänge existieren, wo terminieren sie, und welche Gateways/Proxies beeinflussen den Datenfluss?

• Entry Points: öffentliche Endpoints, APIs, Webhooks, Admin UIs, interne APIs über Service Mesh, Message Gateways.
• Threats: Injection, SSRF, Broken Access Control, Credential Stuffing, API Abuse, volumetrische und semantische DoS.
• Controls: WAF/WAAP, API Gateway Policies (Schema, Quotas), AuthN/AuthZ (OIDC/SAML), Rate Limits, Input Validation, Audit Logging.
• Evidence: Request Logs, WAF Events, Auth Logs, Traces für Fehlerpfade, per-endpoint Latenz/Fehlerraten.

Als praxisnahe Risikoübersicht eignet sich OWASP Top 10, insbesondere wenn Sie L7-Risiken schnell kategorisieren müssen.

Attack Surface „schnell“ bestimmen: Ein OSI-basierter Kurzprozess

Wenn Sie unter Zeitdruck stehen (z. B. neues Projekt, Merger, neue Edge-Region), ist Geschwindigkeit wichtiger als Perfektion. Der folgende Kurzprozess ist darauf optimiert, innerhalb eines Workshops eine belastbare erste Angriffsflächenkarte zu erzeugen.

• Schritt 1: Liste aller externen Entry Points (Internet Edge, VPN, Peering, öffentliche APIs, Admin Zugänge).
• Schritt 2: Markieren der wichtigsten Trust Boundaries (Tenant/VRF, Prod/Non-Prod, DMZ/Intern, Management Plane).
• Schritt 3: Pro Layer 2–3 „dominante“ Risiken auswählen (die wahrscheinlichsten oder mit größtem Impact).
• Schritt 4: Pro Risiko die aktuell wirksame Kontrolle und die Evidenzquelle notieren (falls keine Evidenz: Detection-Lücke).
• Schritt 5: Top 5 Maßnahmen ableiten: zwei Hardening, zwei Detection, eine Response-Verbesserung.

Priorisierung: Risiko greifbar machen, ohne sich zu verlieren

Eine OSI-Landkarte ist nur dann nützlich, wenn sie Entscheidungen ermöglicht. Eine einfache, NOC- und Security-taugliche Priorisierung kombiniert Eintrittswahrscheinlichkeit P, Auswirkung I und Kontrollstärke K (0 bis 1, wobei 1 = starke Kontrolle). Ein reduzierter Risikowert R lässt sich dann als:

$R=P\cdot I\cdot (1-K)$

Das ist kein Compliance-Modell, aber ein praktikabler „Schnellindikator“. Er zwingt zu klaren Aussagen: Wenn K für L2-Spoofing praktisch 0 ist, steigt das Risiko unabhängig davon, wie gut Ihre WAF ist.

Detection und Evidenz pro Layer: Was Sie messen sollten

Ein Threat Model ohne Telemetrie bleibt Theorie. OSI hilft, Monitoring sauber zuzuordnen: Welche Signale zeigen Angriffe, Fehlkonfigurationen oder Kontrollversagen?

• L1: Zutrittsereignisse, Asset-Drift, OOB-Änderungen.
• L2: ARP/MAC-Anomalien, STP-Changes, Broadcast/Multicast-Spikes, Port-Security Violations.
• L3: Routing-Änderungen, Prefix-Counts, uRPF-Drops, Flow-Top-Talkers pro VRF/Zone.
• L4: Session Table Pressure, SYN-Raten, Conntrack Drops, NAT Exhaustion, Reset/Timeout Muster.
• L5: Anomalien in Auth/Session-Lifecycle, ungewöhnliche Refresh-Token-Nutzung, fehlende Revocation.
• L6: TLS-Handshake-Fehler, Zertifikatsablauf, mTLS-Fails, Policy-Downgrades.
• L7: WAF Events, API Abuse, Fehlerraten pro Endpoint, AuthZ-Denies, ungewöhnliche Parameter-/Payload-Muster.

Für Angriffs- und Technikmuster über verschiedene Ebenen hinweg kann MITRE ATT&CK als Katalog dienen, um Beobachtungen (Telemetry) und Taktiken/Techniken konsistent zu benennen.

Typische OSI-Mapping-Fallen und wie Sie sie vermeiden

OSI-basiertes Network Threat Modeling ist schnell, aber nur dann präzise, wenn Sie gängige Denkfehler vermeiden.

• „Alles ist Layer 7“: Viele Ursachen liegen in L2/L3/L4. Erzwingen Sie pro Layer mindestens ein Risiko, sonst ist das Modell ein AppSec-Plan im OSI-Kleid.
• „Kontrolle existiert“ ohne Wirksamkeitsnachweis: Wenn Sie nicht messen können, ob eine Kontrolle greift, ist sie operativ schwach. Ergänzen Sie Evidence-Quellen.
• Zu grobe Trust Boundaries: „Intern“ ist keine Boundary. Arbeiten Sie mit Zonen/VRFs/Tenants/Management vs. Data Plane.
• Keine Ownership: Jedes Layer-Risiko braucht einen Owner (NetOps, SecOps, AppSec, Plattform), sonst bleibt es liegen.
• Kein Response-Bezug: Ein Threat Model sollte konkrete Runbooks/Evidence Packs inspirieren, nicht nur Controls.

Output-Artefakte: Was am Ende eines schnellen OSI-Threat-Modelings stehen sollte

Damit das Ergebnis direkt nutzbar ist, sollte Ihr Output bewusst „betriebsnah“ sein. Für einen schnellen Durchlauf genügen meist diese Artefakte:

• Attack-Surface-Karte: Entry Points + Trust Boundaries + wichtigste Protokolle/Gateways.
• OSI-Risikomatrix: pro Layer 2–5 Risiken, jeweils mit Controls und Evidence.
• Top-5-Prioritäten: konkrete Maßnahmen mit Owner und grobem Zeithorizont.
• Detection-Gaps: Liste der Stellen, an denen Sie Angriffe/Fehlkonfigurationen nicht beweisen können.
• Incident-Runbook-Hinweise: welche Checks bei welchen Symptomen zuerst laufen (Layer-Hypothesen).

So entsteht aus einem „Schnellmodell“ ein praktischer Plan, der sowohl Security- als auch Betriebsrealität abbildet.

Outbound-Quellen für vertiefendes Verständnis

Für methodische Grundlagen des Threat Modelings ist NIST SP 800-154 ein hilfreicher Einstieg. Für die Benennung und Strukturierung von Angriffs- und Technikmustern über verschiedene Ebenen hinweg eignet sich MITRE ATT&CK. Für Web- und API-Risiken auf Layer 7 ist OWASP Top 10 eine verbreitete, praxisnahe Referenz. Für Protokollgrundlagen, die beim OSI-basierten Mapping häufig relevant sind, bieten RFC 826 (ARP), RFC 4271 (BGP-4), RFC 9293 (TCP) und RFC 8446 (TLS 1.3) belastbare technische Hintergründe.

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.