OSI-Modell für Security Architecture Reviews: Pflichtfragen pro Layer

Das OSI-Modell für Security Architecture Reviews ist ein äußerst praktisches Werkzeug, um Architekturentscheidungen systematisch zu prüfen – unabhängig davon, ob es um On-Premises-Netze, Cloud-Setups, hybride Umgebungen oder servicebasierte Plattformen geht. In vielen Reviews verlaufen Diskussionen entweder zu abstrakt („Zero Trust einführen“) oder zu toolzentriert („Wir brauchen eine WAF“), ohne klar zu machen, wo eine Kontrolle technisch greift und welche Angriffsfläche damit tatsächlich reduziert wird. Genau hier hilft das OSI-Modell: Es strukturiert ein Review entlang der Schichten L1–L7 und zwingt dazu, Eintrittspunkte, Trust Boundaries, Protokolle, Zustände, Kontrollen und Telemetrie sauber zuzuordnen. Das Ergebnis sind weniger „blinde Flecken“ (z. B. starke Layer-7-Controls, aber schwache Layer-2/3-Hygiene), schnellere Entscheidungen und eine Audit-taugliche Argumentation, weil Anforderungen und Nachweise pro Layer klar benannt werden können. Dieser Leitfaden liefert Pflichtfragen pro Layer, die Sie in Security Architecture Reviews standardisieren können – inklusive typischer Risiken, Evidence-Artefakte und Hinweise, wie Sie Cross-Layer-Kontrollen wie Zero Trust, DDoS-Schutz oder Microsegmentation korrekt einordnen.

Warum OSI-basierte Pflichtfragen Reviews schneller und besser machen

Security Architecture Reviews scheitern oft an zwei Dingen: fehlender Struktur und fehlender Prüfbarkeit. Eine OSI-basierte Fragenliste löst beides. Struktur entsteht, weil jede Frage einem Layer zugeordnet ist und dadurch klar wird, ob ein Thema „Netzwerkfundament“ (L2/L3), „Transportzustand“ (L4), „Identität/Sitzung“ (L5), „Kryptografie“ (L6) oder „Applikationslogik“ (L7) betrifft. Prüfbarkeit entsteht, weil Sie für jede Antwort definieren können, welche Artefakte als Nachweis gelten (Konfiguration, Logs, Dashboards, Tests, Runbooks).

• Vollständigkeit: Pro Layer werden typische Angriffspfade abgefragt, nicht nur „Lieblingstools“.
• Verantwortlichkeiten: Teams können klar zugeordnet werden (NetOps, SecOps, IAM, Plattform, AppSec).
• Messbarkeit: Jede Kontrolle wird mit Telemetrie/Evidence verbunden, nicht nur „wir haben das“.
• Wiederholbarkeit: Gleiche Fragen in jedem Review reduzieren Zufall und Personabhängigkeit.

Für allgemeine Control-Struktur und Audit-Argumentation eignet sich NIST SP 800-53 Rev. 5 als Referenzrahmen, den Sie mit OSI-Fragen technisch konkretisieren können.

So nutzen Sie die Pflichtfragen in einem Review-Prozess

Damit aus Fragen echte Entscheidungen werden, sollten Sie den Review-Ablauf standardisieren. Ein bewährtes Vorgehen ist: (1) Scope definieren, (2) Entry Points und Trust Boundaries markieren, (3) pro Layer Pflichtfragen beantworten, (4) offene Punkte als Risiken/Actions erfassen, (5) Wirksamkeitsnachweise und Review-Zyklen festlegen.

Minimaler Output eines OSI-Reviews

• Architecture Map: grobe Topologie inkl. Trust Boundaries (Zonen, VRFs, VPCs, Management vs. Data Plane).
• Control Map: wichtigste Kontrollen pro Layer mit Enforcement Points.
• Evidence List: Links/Artefakte, die Antworten belegen (Config, Logs, Dashboards, Tests).
• Risk & Action List: offene Risiken, Owner, Termin, Abhängigkeiten.

Layer 1: Physical Security – Pflichtfragen für L1

Layer 1 wird in Architektur-Reviews häufig unterschätzt. Dennoch ist L1 entscheidend, weil physischer Zugriff viele höhere Kontrollen umgehen kann. In Cloud-Umgebungen wird L1 oft an den Provider delegiert – in Colocation, Edge und On-Premises bleibt es jedoch Ihr Thema.

• Welche Standorte sind Teil des Scopes? (DC, Colocation, Edge, Remote Sites)
• Wie wird physischer Zugang kontrolliert? (MFA/Badges, Besucherprozess, Begleitung)
• Wie werden kritische Komponenten geschützt? (Racks/Cages, Port-/Patch-Management, Tamper-Evidence)
• Wie ist Out-of-Band-Management abgesichert? (separate Pfade, RBAC, Session Logging)
• Wie werden Remote-Hands und Drittparteien gesteuert? (Freigabe, Vier-Augen-Prinzip, Audit Trail)
• Wie sieht die Asset- und Lifecycle-Kontrolle aus? (Inventar, Decommission, sichere Entsorgung)

Evidence in L1-Reviews sind häufig: Zutrittslogs, Asset-Inventar, Change-Tickets für Cross-Connects, OOB-Zugriffslogs und Provider-/Colocation-Reports.

Layer 2: Data Link – Pflichtfragen für L2

Layer 2 ist eine klassische Quelle für laterale Bewegung und lokale Manipulation: ARP-Spoofing, Rogue DHCP, MAC-Flooding, VLAN-Fehlkonfigurationen oder L2-Stürme. Selbst wenn Ihr Security-Fokus auf Anwendungen liegt, kann ein schwaches L2-Fundament Segmentierung aushebeln.

• Wo existieren Broadcast-Domänen? (VLANs, L2-Stretch, vSwitches) und wie groß sind sie?
• Wie wird Port-Zugang kontrolliert? (802.1X/NAC, Port Security, Gäste-/IoT-Profile)
• Welche Anti-Spoofing-Mechanismen sind aktiv? (DHCP Snooping, Dynamic ARP Inspection, IP Source Guard)
• Wie wird L2-Stabilität abgesichert? (STP Guards, Loop Prevention, Storm Control)
• Wie werden Trunks und VLANs gehärtet? (Allowed VLAN Lists, Native VLAN Policy, konsequentes Tagging)
• Wie wird L2-Telemetrie überwacht? (Broadcast/Multicast-Spikes, Port-Security Violations, STP Changes)

Für ARP-Grundlagen, die in Reviews häufig als Referenz dienen, ist RFC 826 (ARP) geeignet.

Layer 3: Network – Pflichtfragen für L3

Layer 3 ist der Ort, an dem Zonen und Tenants technisch getrennt werden. Hier entscheidet sich, ob „Least Privilege im Netz“ tatsächlich durchgesetzt wird oder nur dokumentiert ist. Gleichzeitig sind L3-Fehler oft hochgradig impactstark (Route Leaks, Misroutes, Blackholing).

• Welche Trust Boundaries gibt es? (VRFs, VPCs/VNets, DMZ, Prod/Non-Prod, Management)
• Wie wird Segmentierung erzwungen? (ACLs, Security Groups, Policy-Routing, Inter-VRF Gateways)
• Wie wird Anti-Spoofing umgesetzt? (Ingress-Filter, uRPF strict/loose, egress policy)
• Wie wird Routing-Integrität gesichert? (Prefix-Lists, Route-Maps/Policies, max-prefix, Redistribution-Regeln)
• Wie wird „Blast Radius“ begrenzt? (Zonierung, kontrollierte Exports/Imports, Anycast/ECMP Governance)
• Welche Nachweise gibt es im Betrieb? (Prefix-Count Monitoring, RIB/FIB Snapshots, Routing Change Events)

Wenn BGP im Scope ist, hilft RFC 4271 (BGP-4) für saubere Begrifflichkeit und technische Ableitungen im Review.

Layer 4: Transport – Pflichtfragen für L4

Layer 4 ist besonders relevant, wenn stateful Geräte (Firewalls, NAT, Load Balancer) im Pfad sind. Viele Security- und Availability-Probleme entstehen aus Zustandsfragen: Timeouts, Conntrack-Exhaustion, asymmetrische Pfade, aggressive Rate Limits oder falsch verstandene „Allow“-Regeln.

• Welche Ports sind extern und intern exponiert? (Service-Ports, Admin-Ports, Routing-Protokolle)
• Wo wird Statefulness erzwungen? (stateful firewall, L4 LB, NAT, proxies) und was passiert bei Asymmetrie?
• Wie werden DoS- und Exhaustion-Risiken adressiert? (SYN protections, rate limits, connection limits, conntrack sizing)
• Wie sind Timeouts definiert? (Idle, session, NAT mappings) und sind sie dokumentiert?
• Wie wird Kapazität überwacht? (Session Table Pressure, NAT Port Utilization, Drops/Resets)
• Wie werden Admin-Zugänge geschützt? (Bastion, RBAC, MFA, Restriktion auf Management-Zonen)

Für TCP-Verhalten und Terminologie ist RFC 9293 (TCP) eine geeignete Referenz.

Layer 5: Session – Pflichtfragen für L5

Layer 5 ist in OSI-Diskussionen oft „unsichtbar“, aber für Architektur-Reviews entscheidend: Wie wird Identität in Sitzungen abgebildet, wie lange sind Sessions gültig, wie werden sie widerrufen, und wie verhindern Sie Missbrauch durch Token-Diebstahl?

• Wie werden Sessions und Tokens verwaltet? (TTL, Rotation, Refresh, Revocation)
• Welche Identitätsprovider und Flows sind im Einsatz? (SSO, OIDC, SAML, service identities)
• Wie wird privilegierter Zugriff abgesichert? (step-up auth, just-in-time access, approval flows)
• Wie wird Session-Missbrauch erkannt? (Anomalien, ungewöhnliche Sessiondauer, impossible travel)
• Welche Session-Grenzen existieren zwischen Zonen? (Admin vs. User Sessions, Prod vs. Non-Prod)
• Welche Nachweise gibt es? (Auth-Logs, token issuance/revocation events, access reviews)

Layer 6: Presentation – Pflichtfragen für L6

Layer 6 wird häufig mit „TLS“ gleichgesetzt, umfasst jedoch generell Verschlüsselung, Zertifikate, Datenrepräsentation und Transformation. In Reviews geht es darum, ob Kryptografie konsistent erzwungen wird, ob Zertifikatslebenszyklen beherrscht werden und wo Klartextdaten entstehen (Termination Points).

• Wo terminieren TLS-Verbindungen? (Edge, LB, API Gateway, Service Mesh) und wo liegt Klartext vor?
• Welche TLS-Policies gelten? (Versionen, Cipher Suites, HSTS, client auth / mTLS)
• Wie wird Zertifikatsmanagement betrieben? (automatisierte Ausstellung, Rotation, Alarmierung bei Ablauf)
• Wie werden Keys und Secrets verwaltet? (Vault, RBAC, Rotation, Audit Logs)
• Wie werden Parser- und Transformationsrisiken adressiert? (Deserialization, decompression, content transformations)
• Welche Evidenz existiert? (Scanner-Reports, TLS handshake metrics, inventory, expiry dashboards)

Als technische Referenz für TLS 1.3 ist RFC 8446 (TLS 1.3) geeignet, insbesondere für Policy-Definitionen und Fehlersignaturen.

Layer 7: Application – Pflichtfragen für L7

Layer 7 ist für viele Security Architecture Reviews der Schwerpunkt, weil hier Business-Logik, APIs und Nutzerzugriffe stattfinden. Die Pflichtfragen sollten jedoch nicht nur Tool-Fragen sein („WAF ja/nein“), sondern systematisch Autorisierung, Eingabeverarbeitung, Missbrauchsschutz und Auditfähigkeit abdecken.

• Welche Entry Points existieren? (öffentliche APIs, Webhooks, Admin UIs, Partner-Integrationen)
• Wie wird Authentifizierung umgesetzt? (SSO, MFA, risk-based auth, device posture)
• Wie wird Autorisierung erzwungen? (RBAC/ABAC, default deny, least privilege, regelmäßige Reviews)
• Wie werden APIs geschützt? (Schema validation, quotas, rate limits, abuse detection)
• Wie wird Input verarbeitet? (server-side validation, sichere Defaults, upload handling)
• Wie wird protokolliert? (Audit Logs für privilegierte Aktionen, Korrelation IDs, manipulationsschutz)
• Welche Controls liegen am Gateway? (WAF/WAAP, API Gateway, bot management) und wie wird getunt?

Für praxisnahe Web- und API-Risikokategorien eignet sich OWASP Top 10 als Referenz, um Review-Feststellungen sauber zu klassifizieren.

Cross-Layer Pflichtfragen: Kontrollen, die mehrere Schichten betreffen

Viele Architekturentscheidungen sind bewusst „cross-layer“: Zero Trust, Microsegmentation, DDoS-Schutz, Observability. In Reviews sollten Sie diese Themen separat abfragen, damit sie nicht nur als Schlagworte bestehen bleiben.

• Zero Trust: Welche Entscheidungen sind Identitätsbasiert (L5/L7) und welche sind Netzwerkbasiert (L3/L4)? Wo wird durchgesetzt?
• Microsegmentation: Ist sie policy-driven (L3/L4) und wird sie mit Service Identity/mTLS (L5/L6) ergänzt?
• DDoS-Resilienz: Welche Schutzmechanismen existieren volumetrisch (L3/L4) und semantisch (L7)? Wie wird getestet?
• Supply Chain/Third Parties: Wo kommen Partnernetze, SaaS, Remote-Hands, Managed Services ins Spiel (L1–L7)?
• Observability: Können Sie pro Layer Angriffe, Fehlkonfigurationen und Kontrollversagen nachweisen?

Für die Strukturierung von Angriffs- und Technikmustern (hilfreich für Detection und Review-Feststellungen) ist MITRE ATT&CK ein gängiger Referenzkatalog.

Evidence- und Nachweisfragen: Was ein Review „audit-ready“ macht

Eine häufige Schwäche von Architektur-Reviews ist, dass Entscheidungen getroffen werden, aber Nachweise unklar bleiben. Deshalb sollten Sie zusätzlich zu den Layer-Fragen eine Evidenzsektion aufnehmen: Welche Artefakte belegen, dass die Architektur so umgesetzt ist und so betrieben wird?

• Gibt es eine Source of Truth? (IaC-Repo, Config-Versionierung, CMDB/Inventory)
• Wie wird Drift erkannt? (Config Drift Checks, Policy Compliance, regelmäßige Reviews)
• Welche Logs sind Pflicht? (Routing/Firewall/IdP/API) und wie lange werden sie aufbewahrt?
• Wie werden Findings geschlossen? (Tickets, Owner, Termine, Abnahme, Re-Test)
• Welche Tests existieren? (Pen-Test, Tabletop, DDoS-Drills, Policy-Unit-Tests, Post-Change Checks)

Ein einfacher Review-Reifegrad-Index

Wenn Sie Reviews vergleichbar machen wollen, können Sie pro Layer vier Aspekte bewerten: Design (D), Implementierung (I), Betrieb (B), Wirksamkeitstest (W). Jeder Wert 0 bis 1. Der Layer-Score S als Durchschnitt:

$S=\frac{D+I+B+W}{4}$

Dieser Score ersetzt keine Risikobewertung, hilft aber, typische Schwächen sichtbar zu machen: Häufig ist D und I gut, aber W (Wirksamkeitstest) fehlt.

Typische Review-Fallen und wie Sie sie mit OSI-Fragen vermeiden

• Tool statt Kontrolle: „Wir haben eine Firewall“ ist keine Antwort. Pflicht: Regelprinzip, Enforcement Point, Evidence, Betrieb.
• Nur Layer 7 prüfen: L2/L3 werden oft übergangen – genau dort entstehen jedoch Segmentierungs- und Spoofing-Lücken.
• Keine Trust Boundaries: „Intern“ ist keine Zone. Pflicht: explizite Grenzen (Prod/Non-Prod, Management/Data, Tenant A/B).
• Keine Betriebsperspektive: Kontrollen ohne Monitoring und Runbooks sind in Incidents häufig wirkungslos.
• Unklare Ownership: Jede Kontrolle braucht einen Owner und einen Review-Zyklus.

Outbound-Quellen für belastbare Review-Methodik und Referenzen

Für die Struktur und Nachweisführung von Security Controls ist NIST SP 800-53 Rev. 5 ein etablierter Rahmen. Für Web- und API-Risiken, die in Layer-7-Reviews typischerweise relevant sind, ist OWASP Top 10 eine praxisnahe Referenz. Für Angriffstechniken und zur Konsistenz von Detection- und Review-Findings kann MITRE ATT&CK herangezogen werden. Für technische Protokollgrundlagen, die in Layer-2/3/4/6-Fragen häufig auftauchen, sind RFC 826 (ARP), RFC 4271 (BGP-4), RFC 9293 (TCP) und RFC 8446 (TLS 1.3) stabile Referenzen für präzise Architektur-Reviews.

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.