MITRE ATT&CK auf OSI-Schichten mappen: Praxis, die im Feld wirklich hilft

Wer Security „im Feld“ betreibt, merkt schnell: Das MITRE ATT&CK auf OSI-Schichten mappen ist kein akademischer Luxus, sondern eine Abkürzung zu besseren Entscheidungen. MITRE ATT&CK liefert eine gemeinsame Sprache für Angreifer-Taktiken und -Techniken, aber im Alltag bleibt oft unklar, wo genau man ansetzen soll: Welche Telemetrie fehlt? Welche Kontrolle wirkt wirklich? Warum findet das SIEM bestimmte Aktivitäten nie? Das OSI-Modell (Layer 1 bis 7) hilft, diese Fragen zu erden – entlang konkreter technischer Ebenen. Indem Sie ATT&CK-Techniken auf OSI-Schichten abbilden, übersetzen Sie „was Angreifer tun“ in „wo es sichtbar wird“ und „womit Sie es stoppen oder erkennen“. Das Ergebnis ist praxisnah: schnellere Triage, klarere Detection-Engineering-Backlogs, nachvollziehbare Gap-Analysen und weniger Diskussionen zwischen Netzwerk-, Plattform- und App-Teams. In diesem Artikel geht es darum, wie Sie das Mapping pragmatisch aufbauen, welche Fallstricke es gibt und welche Abbildung im Incident Response, Threat Modeling und Purple Teaming tatsächlich hilft – ohne in Theorie zu versinken.

Warum ATT&CK und OSI zusammen mehr bringen als jedes Framework allein

MITRE ATT&CK beschreibt Angreiferverhalten in Form von Taktiken (Ziele wie Initial Access, Persistence, Exfiltration) und Techniken (konkrete Vorgehensweisen). Das OSI-Modell strukturiert Kommunikation und Systeme in Schichten. Kombiniert ergeben sich drei Vorteile, die im Betrieb sofort spürbar sind:

• Telemetrie-Disziplin: Sie sehen, ob eine Technik prinzipiell nur auf L7 erkennbar ist (z. B. API-Missbrauch) oder ob L3/L4-Signale reichen (z. B. ungewöhnlicher Egress).
• Kontrollklarheit: Sie vermeiden, dass Teams aneinander vorbeireden („WAF ist doch da“), wenn das Risiko eigentlich auf L5 (Sessions/Tokens) oder L2 (laterale Bewegung) liegt.
• Priorisierung: Sie können Abdeckung (Coverage) und Lücken systematisch bewerten und auf die größten Risikohebel fokussieren.

Damit das funktioniert, muss man akzeptieren: ATT&CK ist nicht „OSI-nativ“. Viele Techniken betreffen mehrere Ebenen gleichzeitig. Das Mapping ist daher nicht „eine Wahrheit“, sondern eine praxisorientierte Zuordnung: Wo ist die Technik sichtbar, wo kann ich sie blocken, und wo brauche ich Kontext aus mehreren Layern?

Das Grundprinzip des Mappings: Sichtbarkeit, Kontrolle, Kontext

Eine Technik auf eine OSI-Schicht zu mappen, heißt nicht, sie auf eine Schicht zu reduzieren. In der Praxis verwenden erfahrene Teams drei Perspektiven pro Technik:

• Primäre Sichtbarkeit: In welchem Layer liefert Telemetrie die schnellsten und belastbarsten Indikatoren?
• Primäre Kontrolle: In welchem Layer kann ich den Angriffsweg mit geringstem Kollateralschaden effektiv einschränken?
• Notwendiger Kontext: Welche zusätzlichen Layer brauche ich, um False Positives zu reduzieren und Attribution/Impact zu bestimmen?

Beispiel: „Exfiltration über Web“ ist oft auf L3 als Egress-Anomalie sichtbar, aber ohne L7 (welcher Benutzer, welches Objekt) bleibt der Impact unklar. Gleichzeitig ist die effektivste Bremse häufig L3 (zielgerichtetes Egress-Blocking) oder L7 (Export-Funktion drosseln), je nach Situation.

Pragmatisches Vorgehen: In vier Schritten zum brauchbaren ATT&CK-OSI-Mapping

• Scope definieren: Welche Plattform (Cloud, On-Prem, SaaS), welche Kernsysteme, welche Kronjuwelen (PII, Schlüssel, Admin-Zugänge)?
• Top-Techniken auswählen: Nicht „alles ATT&CK“, sondern die wichtigsten Techniken für Ihr Umfeld (z. B. Identity-Missbrauch, Exfiltration, Lateral Movement).
• Layer-Check durchführen: Für jede Technik festlegen: Sichtbarkeit/Kontrolle/Kontext pro OSI-Layer.
• In Engineering übersetzen: Ergebnis muss als Backlog enden: Datenquellen, Detection-Regeln, Härtungsmaßnahmen, Runbooks.

Wenn Sie Unterstützung bei der Auswahl von „Top-Techniken“ benötigen, helfen die ATT&CK-Navigator-Ansätze und die Technikseiten direkt im Framework. Ergänzend ist es sinnvoll, Vorfälle und Findings aus der eigenen Umgebung einzubeziehen, damit das Mapping nicht theoretisch bleibt.

Layer 1: Physikalisch – selten im Fokus, aber entscheidend für Edge und On-Prem

Viele ATT&CK-Techniken setzen indirekt physische Voraussetzungen voraus: unkontrollierte Gerätezugänge, manipulierte Hardware, ungesicherte Ports. Das wird im klassischen IT-SOC oft übersehen, ist aber in OT, IoT, Retail, Edge-Computing und RZ-nahen Umgebungen relevant.

• Typische Zuordnung: Techniken rund um physische Manipulation, „Rogue Devices“, Zugriff auf Debug-Ports, Diebstahl von Datenträgern.
• Sichtbarkeit: Zutrittsprotokolle, Inventarabweichungen, Port-Status, Umgebungssensorik.
• Kontrollen: Physische Zutrittskontrolle, Hardware-Härtung, Device-Management, sichere Entsorgung, Tamper-Evident Maßnahmen.

Als Rahmen für physische und organisatorische Maßnahmen bietet ISO/IEC 27001 praxisrelevante Anforderungen, die sich in viele Umgebungen übertragen lassen.

Layer 2: Data Link – Lateral Movement beginnt oft „unterhalb“ von IP

ATT&CK spricht bei lateraler Bewegung und Discovery häufig über Netzwerkeffekte. Viele konkrete Angriffspfade in internen Netzen nutzen jedoch Layer-2-Mechaniken: ARP-Manipulation, VLAN-Missbrauch, Rogue DHCP, MAC-Flooding. Das ist besonders relevant, wenn Angreifer bereits Fuß gefasst haben und sich im internen Netz bewegen.

• Praktische Mappings: Teile von Discovery und Lateral Movement, die durch lokale Netz-Manipulation unterstützt werden.
• Sichtbarkeit: Switch-/WLAN-Controller-Logs, NAC/802.1X-Ereignisse, ARP/DHCP-Protection-Alarme, ungewöhnliche MAC-Wechsel.
• Kontrollen: 802.1X/NAC, Segmentierung (VLAN), DHCP Snooping, Dynamic ARP Inspection, Port Security.

Ein Feld-Tipp: Wenn Ihr SOC keine Layer-2-Telemetrie sieht, ist es für Angreifer oft deutlich leichter, unbemerkt MITM-Positionen aufzubauen oder Traffic umzuleiten. Auch wenn Sie nicht alles zentral loggen können, lohnt zumindest die Korrelation kritischer Events (Port-Down/Up, neue MACs auf Admin-Ports, NAC-Quarantäne).

Layer 3: Network – ATT&CK wird hier „messbar“ durch Beziehungen und Flüsse

Layer 3 ist der beste Layer, um ATT&CK-Techniken für viele Umgebungen schnell operationalisierbar zu machen. Warum? Weil Flow-Daten, Firewall-Logs und DNS-/Routing-Telemetrie Beziehungen sichtbar machen: Wer spricht mit wem, wie oft, wie groß, wohin. Das ist Gold für Discovery, Command-and-Control, Exfiltration und teilweise Initial Access.

• Beispiele für Mapping-Nutzen: C2-ähnliche Kommunikationsmuster, ungewöhnlicher Egress, neue externe Ziele, auffällige DNS-Nutzung.
• Sichtbarkeit: NetFlow/IPFIX, Firewall-Logs, DNS-Logs, Routing-Audits, Cloud-Netzwerklogs.
• Kontrollen: Egress-Filter, Segmentierung, DNS-Policies, Blocklisten für bekannte bösartige Ziele, Zero-Trust-Zonenmodelle.

Im Feld hilft das besonders bei Triage: Wenn Sie ATT&CK-Techniken wie Exfiltration oder C2 vermuten, liefert L3 oft die schnellsten „Ja/Nein“-Signale. Für Angriffsarten und -muster lohnt ein Blick in MITRE ATT&CK, weil viele Technikseiten konkrete Indikatoren und Gegenmaßnahmen anreißen.

Layer 4: Transport – Ports, Zustände, Scans und „laute“ Bewegungen

Layer 4 ist wichtig, wenn Techniken sich durch Portnutzung, Verbindungsraten und Zustandsanomalien äußern. Das umfasst Portscans, Brute-Force gegen Dienste, Flooding/DoS und viele Formen von interner Service-Enumeration.

• Praktische Zuordnung: Teile von Discovery (Service Scanning), Credential Access (Brute Force gegen Dienste), Impact (DoS), Command-and-Control (ungewöhnliche Verbindungsprofile).
• Sichtbarkeit: IDS/IPS, Load-Balancer-Statistiken, Firewall-Session-Tables, Connection-Metriken.
• Kontrollen: Rate Limiting, Connection Limits, harte Service-Exposure-Policies, segmentierte Serviceports, „default deny“ intern.

Ein realistischer Hinweis: L4-Signale sind oft gut für Detektion „lauter“ Aktivitäten, aber schwächer bei „leiser“ Exfiltration oder Token-Missbrauch. Hier brauchen Sie fast immer Kontext aus L5/L7, um echte Angriffe von legitimen Lastspitzen zu trennen.

Layer 5: Session – wo ATT&CK in modernen Umgebungen häufig entscheidet

In Cloud- und SaaS-lastigen Realitäten sind viele der gravierendsten Vorfälle identity-getrieben: kompromittierte Accounts, missbrauchte Service Principals, Token-Replay, überprivilegierte Sessions. Diese Muster gehören in der Praxis zur „Primärschicht“ vieler ATT&CK-Techniken rund um Credential Access, Persistence und Privilege Escalation.

• Warum Layer 5 so oft kritisch ist: Sessions verbinden Identität, Gerät, Kontext und Berechtigung. Wer Sessions kontrolliert, kontrolliert häufig die Realität im System.
• Sichtbarkeit: IdP-/SSO-Logs, MFA-Events, Token-Issuance/Revoke, Session-Korrelation, anomale Login-Standorte.
• Kontrollen: MFA/Phishing-resistente Verfahren, Conditional Access, Token-Rotation, Session-Timeouts, Step-up-Auth für Admin-Aktionen.

Für praxisnahe Risiken rund um Authentifizierung und Zugriffskontrolle sind die OWASP Top 10 sowie passende Cheat Sheets eine wertvolle Ergänzung, weil sie typische Fehlerbilder in Web-/API-Kontexten strukturiert benennen.

Layer 6: Presentation – Verschlüsselung, Zertifikate und „Format als Angriffsfläche“

Layer 6 ist im ATT&CK-OSI-Mapping häufig unterschätzt. Dabei entscheiden TLS-Konfigurationen, Zertifikatsmanagement, Serialisierung und Parser-Robustheit darüber, ob Angreifer Payloads einschleusen, Traffic verstecken oder Systeme durch Parsing/Decoding stressen können.

• Praktische Zuordnung: Defense Evasion (Verschleierung über verschlüsselte Kanäle), Collection/Exfiltration (verschlüsselte Übertragung), Impact (Parser-DoS), teils Initial Access (Missbrauch von Protokoll-/Parser-Schwächen).
• Sichtbarkeit: TLS-Handshake-Fehler, Zertifikatsänderungen, Protokoll-/Decode-Errors, ungewöhnliche Client-Fingerprints.
• Kontrollen: TLS-Policies, automatisierte Zertifikatsrotation, mTLS intern, strikte Schema-Validierung, robuste Parser-Konfigurationen.

Für konkrete TLS-Härtung ist das OWASP TLS Cheat Sheet eine praktische Referenz, insbesondere wenn Sie Konsistenz über viele Services hinweg erreichen müssen.

Layer 7: Application – wo ATT&CK zu Business-Risiken wird

Layer 7 ist der Layer, in dem Angriffe „Wert“ realisieren: Datenzugriff, Mandantenverletzungen, Admin-Missbrauch, Manipulation von Workflows. Viele ATT&CK-Techniken werden hier sichtbar, weil nur die Anwendung den Kontext kennt: welcher Nutzer, welches Objekt, welche Rolle, welche Aktion, welcher Tenant.

• Praktische Zuordnung: Initial Access (Web-Facing Application), Privilege Escalation (Misskonfiguration/Autorisierungsfehler), Collection/Exfiltration (Exports, API-Abfragen), Impact (Manipulation).
• Sichtbarkeit: API-Gateway-Logs, App-Audit-Trails, WAF-Events, Business-Event-Logs (z. B. Export gestartet, Rolle geändert).
• Kontrollen: Objektbasierte Autorisierung (ABAC/RBAC sauber umgesetzt), Input Validation/Output Encoding, Rate Limits pro Identität, Feature Toggles für Notfall-Containment.

Feldtaugliche Regel: L7-Detektion braucht „stabile Ereignisse“, nicht nur Fehlerlogs

Viele Teams loggen auf L7 nur Exceptions. Für ATT&CK-Detektion ist das zu wenig. Feldtauglich wird es, wenn Sie stabile, semantische Ereignisse loggen: „Rolle geändert“, „API-Key erstellt“, „Export ausgeführt“, „Admin-Feature aktiviert“, „Webhook-URL geändert“. Diese Events lassen sich deutlich besser korrelieren und sind weniger anfällig für Rauschen.

Ein Mapping, das wirklich hilft: Beispiele als Denkwerkzeug

Statt eine lange Technikliste abzuschreiben, lohnt ein Musterdenken. Die folgenden Beispiele zeigen, wie ein OSI-Mapping die Praxis verbessert, weil es sofort Telemetrie- und Kontrollentscheidungen lenkt.

• Verdacht auf Exfiltration: Primäre Sichtbarkeit oft L3 (Egress-Anomalie) + L7 (welches Objekt/Export). Primäre Kontrolle häufig L3 (zielgerichtetes Egress-Blocking) oder L7 (Export-Funktion drosseln). Kontext L5 (wer war eingeloggt, Token?).
• Verdacht auf Account Takeover: Primäre Sichtbarkeit L5 (SSO/MFA, Token) + L7 (ungewöhnliche Aktionen). Kontrolle L5 (Token revoke, MFA erzwingen) + L7 (Admin-Aktionen sperren). Kontext L3 (geografische/ASN-Anomalien).
• Verdacht auf interne Ausbreitung: Primäre Sichtbarkeit L2/L3 (neue Ost-West-Flows, Segmentwechsel) + L7 (Admin-Tools/Remote-Execution). Kontrolle L3/L4 (Segment isolieren, Ports schließen) + L5 (Service Accounts härten). Kontext L7 (welche Aktionen).

Coverage messen: Ein einfaches Scoring für ATT&CK-zu-OSI-Abdeckung

Damit das Mapping nicht im Dokumentationsordner verschwindet, brauchen Sie eine messbare Abdeckung. Ein einfacher, feldtauglicher Ansatz ist ein Score pro Technik, der Sichtbarkeit und Reaktionsfähigkeit kombiniert. Zum Beispiel:

$C=D+P+R$

• D (Detection): Haben wir verlässliche Signale? Skala 0–2 (0 = keine, 1 = schwach/rauschig, 2 = stark/korrelierbar).
• P (Prevention): Können wir den Pfad erschweren/stoppen? Skala 0–2.
• R (Response): Haben wir ein Runbook + schnelle Containment-Mechanik? Skala 0–2.

Der Score ist bewusst grob. Der Nutzen liegt darin, schnell Lücken zu erkennen: Viele Organisationen haben starke Prävention auf L3/L4, aber schwache L5/L7-Detektion; oder sie haben gute Detektion, aber keine schnelle Reaktion (kein Token-Revoke, kein Feature Toggle, keine Egress-Policy in Minuten).

Wie Sie das Mapping in Detection Engineering übersetzen

Der größte praktische Gewinn entsteht, wenn das OSI-Mapping direkt in Datenquellen und Regeln übersetzt wird. Ein bewährter Ablauf:

• Pro Technik 1–3 Kernsignale: Nicht alles loggen, sondern die stärksten Indikatoren wählen (z. B. „neuer Admin-Token“, „Export gestartet“, „neues externes Ziel mit hohem Datenvolumen“).
• Korrelation über Layer: L3-Egress-Anomalie bekommt erst Gewicht mit L5/L7-Kontext (User, Token, Aktion, Tenant).
• False-Positive-Bremse: Business-Kalender (Deployments), bekannte Integrationen, Service Accounts mit definiertem Verhalten.
• Response Hooks: Jede Detektion sollte eine Containment-Option haben (Token revoke, Egress block, Account disable, Segment isolieren).

Als Orientierung für Kontrollen und Sicherheitsanforderungen jenseits reiner Detektion kann NIST SP 800-53 helfen, weil es viele technische und organisatorische Controls in einer strukturierten Taxonomie beschreibt.

Wie Sie das Mapping im Incident Response nutzen

Im Incident Response ist OSI-Mapping besonders dann hilfreich, wenn Sie schnell triagieren müssen: Welche Logs zuerst, welches Team zuerst, welche Containment-Maßnahme mit geringem Risiko? Mit ATT&CK-OSI denken Sie nicht nur „Was könnte das sein?“, sondern „Wo muss ich hinschauen, um es zu bestätigen?“

• Schnelle Layer-Entscheidung: Identity-Symptome → L5 zuerst; Egress-Spike → L3 zuerst; App-spezifische Aktionen → L7 zuerst.
• Beweissicherung: Pro Layer die schnellsten Artefakte sichern (IdP-Logs, Flow-Daten, API-Gateway-Logs), bevor Änderungen erfolgen.
• Containment nahe am Problem: Token revoke statt Netzwerk-Kahlschlag; Egress-Block statt Hotfix, wenn Exfiltration läuft; Segment-Isolation bei lateral movement.

Für Incident-Handling-Prozesse und Nachvollziehbarkeit ist NIST SP 800-61 eine solide Referenz, die sich gut mit OSI-Runbooks kombinieren lässt.

Purple Teaming: Warum OSI-Mapping die Zusammenarbeit zwischen Red und Blue verbessert

Purple Teaming scheitert oft daran, dass Red Teams „Techniken“ sprechen und Blue Teams „Logs und Produkte“. Das OSI-Mapping wirkt wie ein Übersetzer: Red kann sagen „wir simulieren Technik X“, Blue antwortet mit „primär sichtbar auf L5/L7, wir brauchen diese Events, und wir testen diese Containment-Option“. Dadurch werden Übungen reproduzierbar und messbar.

• Vor der Übung: Technik auswählen, OSI-Sichtbarkeitsannahmen festhalten, benötigte Datenquellen prüfen.
• Während der Übung: Beobachtungen pro Layer dokumentieren (welche Signale kamen an, welche fehlten).
• Nach der Übung: Backlog nach Layern sortieren (z. B. „L5-Logging fehlt“, „L7-Audit-Event unvollständig“, „L3-Flow-Daten nicht zentral“).

Typische Fallstricke und wie Sie sie im Feld vermeiden

• „Eine Technik = ein Layer“: In der Praxis fast immer falsch. Besser: Sichtbarkeit/Kontrolle/Kontext getrennt mappen.
• Zu viel Fokus auf L3/L4: Das liefert schnelle Signale, aber ohne L5/L7 bleiben viele Incidents unklar (wer/was/warum).
• Kein stabiles Logging auf L7: Ohne semantische Events (Rollenänderung, Export, Key-Erstellung) wird ATT&CK-Detektion dünn.
• Verschlüsselung ohne Strategie: TLS ist notwendig, kann aber Inspektion erschweren. Dann brauchen Sie stärkere Endpoint-/App-Telemetrie statt „mehr Netzwerk-Inspection“.
• Mapping ohne Engineering-Follow-up: Wenn keine Tickets entstehen (Datenquelle, Regel, Control, Runbook), bleibt es Papier.

Was Sie am Ende haben sollten: Artefakte, die im Alltag nützlich sind

• ATT&CK-OSI-Matrix: Pro priorisierter Technik die Zuordnung „Sichtbarkeit/Kontrolle/Kontext“ entlang OSI.
• Layer-zu-Owner-Liste: Wer liefert Logs, wer kann Controls ändern, wer kann Containment ausführen?
• Detection-&-Response-Backlog: Konkrete Arbeitspakete: Logging erweitern, Korrelation bauen, Rate Limits setzen, Token-Revoke automatisieren.
• Runbooks: Kurze Playbooks pro Technik-Cluster (Identity, Exfiltration, Lateral Movement), geordnet nach OSI-Layern.

Wenn Sie diese Artefakte pflegen, wird das Mapping zu einem echten Betriebswerkzeug: Es beschleunigt die Kommunikation zwischen Teams, verbessert die Messbarkeit der Abdeckung und sorgt dafür, dass MITRE ATT&CK nicht nur ein Poster ist, sondern eine praktische Brücke zwischen Angreiferrealität und technischer Umsetzung.

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.