Threat Modeling nach OSI: Schnell die Attack Surface bestimmen

Threat Modeling nach OSI ist eine pragmatische Methode, um in kurzer Zeit die Attack Surface (Angriffsfläche) eines Systems zu bestimmen – ohne sich in Detaildiskussionen zu verlieren oder sofort in Tooling zu versinken. Viele Teams starten beim Threat Modeling zu abstrakt („Welche Threats gibt es?“) oder zu unstrukturiert („Wir sammeln mal Ideen“). Das OSI-Modell bietet hier eine klare, technische Ordnung: Jede Kommunikationsschicht (Layer 1 bis 7) bringt typische Assets, Einstiegspunkte, Protokolle, Fehlkonfigurationen und Angriffsarten mit. Wer die Attack Surface schnell erfassen möchte, braucht vor allem eine wiederholbare Checkliste: Welche Interfaces existieren? Welche Daten fließen? Wo sind Trust Boundaries? Wo wird authentifiziert, autorisiert und protokolliert? Mit einem OSI-basierten Vorgehen lassen sich diese Fragen systematisch beantworten – unabhängig davon, ob Sie eine klassische On-Prem-Anwendung, eine Cloud-native Microservice-Landschaft, ein API-Produkt oder IoT-Geräte analysieren. Der Nutzen ist unmittelbar: Sie erhalten ein nachvollziehbares Bild der Angriffsfläche, priorisieren Risiken fundierter und leiten konkrete Maßnahmen ab, die sich in Architektur, Betrieb und Entwicklung verankern lassen.

Warum OSI als „Schnellstart“-Rahmen für Threat Modeling funktioniert

Das OSI-Modell strukturiert Kommunikation in Schichten, die unterschiedliche technische Zuständigkeiten abbilden. Genau dadurch eignet es sich als Raster für Attack-Surface-Analysen: Je tiefer die Schicht, desto stärker sind Aspekte wie physischer Zugriff, lokale Netzwerkeffekte und Routing entscheidend; je höher die Schicht, desto stärker dominieren Identitäten, Protokolllogik, Datenformate und Geschäftsprozesse. Das verhindert typische Blind Spots: Wer nur auf Layer 7 schaut, übersieht ARP-Spoofing oder schwache Segmentierung; wer nur Netzwerk-Firewalls prüft, verpasst Autorisierungsfehler in APIs. Eine solide Grundlagenbeschreibung des OSI-Modells finden Sie beispielsweise in der Übersicht zum OSI-Modell; für protokollnahe Details sind die IETF RFCs eine verlässliche Referenz.

Begriffe klären: Attack Surface, Datenflüsse und Trust Boundaries

Bevor Sie Threat Modeling nach OSI anwenden, sollten Sie drei Begriffe eindeutig definieren. Das reduziert Missverständnisse und beschleunigt Workshops.

• Attack Surface (Angriffsfläche): Alle erreichbaren und potenziell missbrauchbaren Schnittstellen eines Systems – inklusive Netzwerkports, APIs, UI-Flows, Admin-Interfaces, Integrationen, Identitätswege, Supply-Chain-Abhängigkeiten und operative Zugänge.
• Datenfluss: Ein klar beschriebener Weg, auf dem Daten von A nach B gelangen (inklusive Protokoll, Authentisierung, Transformation und Speicherung). Datenflüsse werden häufig in DFDs (Data Flow Diagrams) dokumentiert.
• Trust Boundary: Eine Grenze, an der das Sicherheitsmodell wechselt – etwa zwischen Internet und VPC, zwischen Nutzergerät und Backend, zwischen zwei Mandanten, zwischen Prod und Admin oder zwischen zwei Services mit unterschiedlichem Vertrauensniveau.

Wenn Sie Threats später systematisch kategorisieren möchten, ist STRIDE eine verbreitete Methode (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Eine kompakte Einführung liefert Microsofts Dokumentation zu STRIDE und Threat Modeling.

Die OSI-Shortlist: In 30–60 Minuten zur ersten Attack-Surface-Karte

Das Ziel dieser Shortlist ist nicht Vollständigkeit, sondern Geschwindigkeit und Wiederholbarkeit. Sie eignet sich besonders für Kickoffs, Architekturreviews, neue Services oder als „Pre-Work“ vor einem tieferen Threat Modeling.

• Systemgrenze definieren: Was gehört dazu (Services, Clients, Netzsegmente, Identitätssysteme) und was ist extern (Drittanbieter, Partnernetze)?
• Top-5 Datenflüsse skizzieren: Nutzerlogin, API-Call, Datenimport/-export, Admin-Flow, Monitoring/Logging.
• OSI-Layer durchgehen: Pro Layer die erreichbaren Interfaces und Kontrollpunkte erfassen.
• Trust Boundaries markieren: Wo wechseln Netz, Identität, Mandant, Berechtigungsmodell oder Verwaltungsebene?
• „Crown Jewels“ festhalten: Welche Daten/Assets wären bei einem Angriff am kritischsten (PII, Schlüssel, Zahlungsdaten, Produktionszugänge)?

Layer 1: Physikalische Angriffsfläche schnell erfassen

Layer 1 wirkt in Cloud-Umgebungen oft „wegabstrahiert“, bleibt aber für On-Prem, Edge, IoT, Offices, Labore und bestimmte Compliance-Scopes entscheidend. Bei der Attack Surface zählen hier vor allem Zugangspunkte und Manipulationsmöglichkeiten.

• Zugänge: Serverräume, Schaltschränke, Patchfelder, Geräte-Standorte, Lieferketten- und Wartungszugänge.
• Manipulation: Abziehen/Umstecken von Kabeln, Rogue Devices, physisches Abhören, Funkstörungen.
• Verfügbarkeit: Strom, Kühlung, Leitungsredundanz – relevant für DoS durch physische Einwirkungen.

Wenn physische Security relevant ist, hilft ein Blick auf etablierte Sicherheitsanforderungen wie ISO/IEC 27001, insbesondere für organisatorische und physische Maßnahmen.

Layer 2: Data-Link – lokale Netze, VLANs und „unsichtbare“ Einstiegspunkte

Layer 2 ist häufig der Startpunkt für laterale Bewegungen in internen Netzen. Viele Angriffe bleiben hier lange unentdeckt, weil Monitoring und Regeln zu stark auf IP- oder Applikationsebene ausgerichtet sind.

• Angriffsfläche: Switch-Ports, WLAN, VLAN-Trunks, Broadcast-Domänen, ARP/DHCP-Prozesse.
• Typische Threats: ARP-Spoofing (MITM), Rogue DHCP, MAC-Flooding, VLAN-Hopping.
• Schnellprüfung: Gibt es 802.1X/NAC? Sind Management-Netze isoliert? Ist DHCP Snooping/DAI aktiv? Sind Gast- und IoT-Netze getrennt?

Für die praktische Analyse und das Verständnis von Frame-/Packet-Verhalten ist Wireshark ein Standardwerkzeug, auch wenn Sie für ein schnelles Threat Modeling meist schon mit Architekturwissen und Konfigurations-Checks weit kommen.

Layer 3: Network – Routing, Subnetze und Zonen als Attack-Surface-„Großkarte“

Auf Layer 3 erkennen Sie die große Struktur der Angriffsfläche: Welche Netze können miteinander sprechen, welche Wege existieren ins Internet, welche Integrationen führen nach außen, und wo droht „Flat Network“-Risiko? Hier wird die Attack Surface oft erstmals quantifizierbar: Anzahl Zonen, erlaubte Routen, exponierte Subnetze, Egress-Pfade.

• Angriffsfläche: Public IPs, VPNs, Peering, Transit Gateways, NAT-Gateways, Routing-Tabellen, DNS-Zonen.
• Typische Threats: IP-Spoofing, Fehlrouten, zu breite Security Groups/ACLs, unkontrollierter Egress, DDoS.
• Schnellprüfung: Default-Deny zwischen Zonen? Egress-Filter? Anti-Spoofing? Trennung von Prod/Admin/Monitoring?

Für DDoS-Grundlagen und typische Angriffsmuster ist ein Einstieg über Erklärungen zu DDoS-Angriffen hilfreich, um Risiken an exponierten Übergängen realistisch einzuordnen.

Layer 4: Transport – Ports, Sessions und Ressourcenerschöpfung

Layer 4 konkretisiert die Angriffsfläche in Form von erreichbaren Services: Welche Ports sind offen, welche Protokolle werden genutzt, wie wird Zustand verwaltet, und welche Limits schützen Ressourcen? Hier entstehen oft „harte“ Findings: unnötig offene Ports, veraltete Admin-Dienste, fehlendes Rate Limiting, fehlende Timeouts.

• Angriffsfläche: Offene Ports (Inbound und East-West), Load Balancer Listener, Service Mesh Sidecars, Datenbank-Ports, Admin-Ports.
• Typische Threats: Port Scans, Brute Force auf Service-Endpoints, SYN-Flood/UDP-Flood, Missbrauch interner Serviceports.
• Schnellprüfung: Minimale Portfreigaben? Connection Limits? Rate Limits? Health-Check-Exposition? Trennung von Control Plane und Data Plane?

Layer 5: Session – Auth-Flows, Token-Lebensdauer und Trust-Wechsel

Layer 5 ist für Attack Surface besonders relevant, weil hier die Übergänge zwischen „nicht authentifiziert“ und „authentifiziert“ sowie zwischen Rollen/Scopes stattfinden. Viele kritische Vorfälle sind nicht „exotische Exploits“, sondern Missbrauch von Sessions: Token-Replay, Session-Fixation, unzureichende Invalidierung oder zu lange Token-Lebenszeiten.

• Angriffsfläche: Login-Endpoints, Session-Cookies, Refresh-Token-Flows, SSO-Integrationen, Device-Binding, Passwort-Reset-Prozesse.
• Typische Threats: Credential Stuffing, Session Hijacking, Token Leakage, Weak MFA-Bypass, fehlerhafte Logout-Logik.
• Schnellprüfung: MFA für kritische Rollen? Rotieren Sessions nach Privilege Change? Kurze TTLs für Admin? Erkennung ungewöhnlicher Session-Muster?

Bei Web- und API-Systemen ist OWASP eine der praxisnächsten Referenzen; insbesondere die OWASP Top 10 helfen, session- und authbezogene Risiken in bekannte Kategorien einzuordnen.

Layer 6: Presentation – TLS, Zertifikate und gefährliche Parser

Layer 6 wird oft mit „TLS ist aktiviert“ abgehakt. Für die Attack Surface reicht das nicht: Entscheidend ist, wo TLS terminiert wird, wie Zertifikate verwaltet werden, ob mTLS genutzt wird, und ob Datenformate sicher verarbeitet werden. Parser und Serialisierung sind häufige Ursachen für Sicherheitslücken, weil sie komplexe Randfälle erzeugen.

• Angriffsfläche: TLS-Termination (Ingress, Load Balancer, Gateway), Zertifikatsketten, interne CA, JSON/XML/Proto-Parsing, Kompression.
• Typische Threats: TLS-Misconfig (veraltete Versionen/Cipher), Zertifikatsfehler, unsichere Deserialisierung, Parser-DoS, Side-Channel-Risiken.
• Schnellprüfung: Einheitliche TLS-Policies? Automatisierte Rotation? HSTS wo sinnvoll? Schema-Validierung vor Verarbeitung?

Für konkrete TLS-Härtung ist das OWASP TLS Cheat Sheet eine gut umsetzbare Quelle, gerade wenn mehrere Teams an unterschiedlichen Services arbeiten.

Layer 7: Application – APIs, Geschäftslogik und die „wertvollsten“ Angriffspfade

Layer 7 ist häufig der Ort, an dem Angreifer ihr Ziel erreichen: Datenzugriff, Kontoübernahme, Manipulation von Workflows oder Mandantentrennung. Für die Attack Surface sind hier nicht nur „Endpoints“ relevant, sondern auch Zustandsübergänge (z. B. Bestellung anlegen → bezahlen → stornieren), Rollenmodelle und Integrationen.

• Angriffsfläche: REST/GraphQL/gRPC APIs, Web-UI, Admin-Konsole, Webhooks, Import/Export, Third-Party-Integrationen, Feature Flags.
• Typische Threats: Injection (SQL/NoSQL/Command), Broken Access Control, SSRF, CSRF, IDOR, Business-Logic-Abuse.
• Schnellprüfung: Autorisierung serverseitig und objektbasiert? Eingabevalidierung und Output-Encoding? Rate Limits pro Identität? Audit Logs für Admin-Aktionen?

Attack Surface über User Journeys statt nur über Endpoints

Ein schneller, sehr effektiver Ansatz ist die Analyse von 3–5 kritischen User Journeys: „Registrierung & Login“, „Rechte ändern“, „Zahlung & Refund“, „Datenexport“, „Admin-Operation“. Pro Journey markieren Sie: Einstiegspunkte, Datenobjekte, Trust Boundaries, externe Abhängigkeiten und „entscheidende Checks“ (z. B. Autorisierung). So finden Sie häufig schneller kritische Risiken als durch reines Endpoint-Zählen.

Praktische OSI-Mapping-Tabelle: Was Sie pro Layer dokumentieren sollten

Um Threat Modeling nach OSI in Ihrem Team wiederholbar zu machen, dokumentieren Sie pro Layer stets dieselben Felder. Das Ergebnis ist eine kompakte Attack-Surface-Karte, die sich bei Systemänderungen schnell aktualisieren lässt.

• Interfaces: Was ist erreichbar (physisch, logisch, intern, extern)?
• Protokolle/Technologien: z. B. Ethernet/WLAN, VLAN, IP, TCP, TLS, HTTP, OAuth/OIDC.
• Trust Boundaries: Wo ändert sich das Vertrauensmodell?
• Kontrollpunkte: Firewalls, Gateways, Auth, Logging, Validation, Secrets Management.
• Telemetrie: Welche Logs/Signale belegen Betrieb und Angriffsversuche?
• „High-Risk“-Annahmen: Was darf auf keinen Fall falsch sein (z. B. Mandantentrennung, Admin-Rechte, Schlüsselrotation)?

Wenn Sie daraus anschließend konkrete Kontrollen ableiten möchten, ist NIST SP 800-53 eine hilfreiche Kontrollbibliothek, weil sie technische und organisatorische Maßnahmen strukturiert beschreibt und sich gut auf Layer und Verantwortlichkeiten abbilden lässt.

Priorisierung: Schnell bewerten, was zuerst mitigiert werden sollte

Nach dem OSI-Durchlauf haben Sie typischerweise mehr potenzielle Risiken als Zeit. Für eine schnelle Priorisierung können Sie eine einfache Risikozahl nutzen, die Eintrittswahrscheinlichkeit und Auswirkung kombiniert. Das ersetzt keine vollständige Risikoanalyse, funktioniert aber gut für frühe Entscheidungen, Backlog-Sortierung und Fokus in Threat-Modeling-Workshops.

Ein verbreiteter Ansatz ist: Risiko = Likelihood × Impact. Als Skala eignet sich z. B. 1–5 für beide Werte. Wenn Sie es formal in HTML abbilden möchten, kann das mit MathML so aussehen:

$R=L\times I$

• Likelihood (L): Wie einfach ist der Angriff (Exponierung, Komplexität, vorhandene Kontrollen, benötigte Privilegien)?
• Impact (I): Was passiert im Erfolgsfall (Datenabfluss, Systemausfall, Privilege Escalation, Compliance-Folgen)?
• Praxis-Tipp: Priorisieren Sie zuerst Risiken, die (a) extern erreichbar sind oder (b) Admin-/Mandanten-Grenzen betreffen oder (c) Schlüssel/Identitäten kompromittieren könnten.

Beispiel 1: Web-App mit API und Admin-Konsole – Attack Surface in OSI-Minuten

Angenommen, Sie haben eine Web-Anwendung mit öffentlicher API, einem Admin-Portal und einem internen Worker-Service.

• L3/L4: Public Load Balancer mit 443; interner Zugriff auf DB nur aus Worker-Subnetz; Admin-Portal nur über VPN oder Identity-Aware Proxy.
• L6: TLS-Termination am Ingress; Zertifikatsrotation automatisiert; mTLS zwischen Services.
• L7: API mit JWT; object-level authorization; Admin-Funktionen mit Step-up-MFA; Datenexport mit zusätzlicher Freigabe und Audit.

Die schnellen „Attack-Surface-Hotspots“ sind hier typischerweise: Login/Token-Flows (L5), Admin-Endpoints (L7), Datenexport (L7), Third-Party-Webhooks (L7) und Egress-Pfade (L3). Für wiederkehrende Web-Risiken sind OWASP-Referenzen wie die OWASP Top 10 besonders nützlich, weil sie häufige Fehlerbilder gut zusammenfassen.

Beispiel 2: IoT/Edge – wenn Layer 1 bis 3 plötzlich kritisch werden

Bei IoT-Systemen verschiebt sich die Attack Surface deutlich nach unten: physischer Zugriff, Funk, lokale Netze und Firmware-Update-Ketten sind oft entscheidend.

• L1: Gerät steht in unkontrollierter Umgebung; physische Debug-Ports (UART/JTAG) sind potenziell zugänglich.
• L2: WLAN/Bluetooth; Risiko durch schwache Pairing-Mechanismen oder Rogue APs.
• L3/L4: Geräte sprechen mit Cloud-Endpoints; NAT und lokale Netze; potenzielles laterales Movement im Heim-/Firmennetz.
• L6/L7: TLS und Zertifikate auf dem Gerät; Update-Signaturen; API-Auth für Device-Identitäten.

Ein OSI-basierter Durchlauf zeigt hier schnell, ob die Angriffsfläche durch physische Ports, unsichere lokale Protokolle oder fehlende Update-Integrität dominiert – oft bevor überhaupt die „Anwendungslogik“ diskutiert werden muss.

Workshop-Format: Threat Modeling nach OSI in einem Termin durchführen

Wenn Sie das Verfahren im Team einsetzen, bewährt sich ein kurzes, klar getaktetes Format. Das Ziel ist ein belastbares Ergebnis, nicht perfekte Dokumentation.

• 10 Minuten: Scope, Crown Jewels, Top-Datenflüsse.
• 20 Minuten: OSI-Layer Walkthrough (Interfaces + Trust Boundaries + Kontrollpunkte).
• 15 Minuten: STRIDE-Check auf die kritischsten Flows (optional, aber sehr effektiv).
• 15 Minuten: Priorisierung (R = L × I), Top-Maßnahmen, Owner und nächste Schritte.

Für Incident-Readiness ist es sinnvoll, schon beim Threat Modeling zu prüfen, ob Monitoring und Reaktionspläne zur Angriffsfläche passen. Als Orientierung für Prozesse und Rollen bietet NIST SP 800-61 (Incident Handling Guide) einen strukturierten Rahmen.

Checkliste: Die schnellsten Attack-Surface-Fragen pro OSI-Layer

• Layer 1: Wer kann physisch an Systeme/Ports? Gibt es Wartungs- oder Lieferkettenzugänge?
• Layer 2: Wo sind Switch/WLAN-Einstiegspunkte? Gibt es NAC/802.1X, VLAN-Trennung, ARP/DHCP-Schutz?
• Layer 3: Welche Netze/Zonen existieren? Wo ist Internet-Exposure? Wie sieht Egress aus?
• Layer 4: Welche Ports/Services sind erreichbar? Gibt es Rate Limits und Connection Limits?
• Layer 5: Wie funktionieren Login, Token, SSO, Passwort-Reset? Wie werden Sessions invalidiert und rotiert?
• Layer 6: Wo wird TLS terminiert? Wie werden Zertifikate/Keys rotiert? Werden Formate sicher geparst?
• Layer 7: Welche APIs/Admin-Flows existieren? Ist Autorisierung objektbasiert? Wie werden kritische Aktionen auditiert?

Ergebnis-Artefakte: Was am Ende auf dem Tisch liegen sollte

Damit Threat Modeling nach OSI im Alltag Nutzen stiftet, sollten Sie am Ende drei Artefakte haben, die sich leicht pflegen lassen und bei Änderungen schnell aktualisiert werden können.

• Attack-Surface-Karte: Interfaces und Trust Boundaries entlang OSI, inklusive externer Abhängigkeiten.
• Top-Risiken mit Begründung: Kurzbeschreibung, betroffener Layer/Flow, Risiko (L×I), betroffene Crown Jewels.
• Maßnahmenliste mit Owner: Konkrete Controls, die in Architektur/Backlog/Operations verankert werden (inkl. Logging/Monitoring).

Wenn Sie diese Artefakte konsequent pro System führen, entsteht eine belastbare, skalierbare Praxis: Neue Services werden schneller sicher, Reviews werden effizienter, und die Attack Surface bleibt auch bei Wachstum nachvollziehbar.

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.