OSI-Modell für Security Architecture Reviews: Template mit den richtigen Fragen

Ein OSI-Modell für Security Architecture Reviews: Template mit den richtigen Fragen ist ein pragmatischer Ansatz, um Architektur-Reviews reproduzierbar, vollständig und nachvollziehbar zu machen. In vielen Organisationen laufen Reviews sonst nach Bauchgefühl: Der eine fragt nach „Zero Trust“, der nächste nach „Logging“, ein dritter nach „Verschlüsselung“ – und am Ende bleiben Lücken, weil niemand systematisch geprüft hat, wo sich Kontrollpunkte, Trust Boundaries und Telemetrie tatsächlich befinden. Das OSI-Modell ist dabei weniger ein technisches Dogma als eine Strukturhilfe: Es zwingt dazu, Security-Themen entlang der Schichten zu ordnen, Verantwortlichkeiten sauber zuzuweisen und Annahmen transparent zu machen. Ein gutes Template soll nicht „mehr Papier“ erzeugen, sondern schneller zu belastbaren Entscheidungen führen: Was ist das Risiko, wo ist der Control Point, wie wird es geprüft, und welche Evidence belegt die Wirksamkeit? Genau dafür liefert das OSI-Review-Template eine klare, leicht verständliche Checkliste, die sowohl Einsteiger als auch Profis nutzen können – ohne Buzzwords, aber mit den Fragen, die in der Praxis wirklich entscheiden.

Warum OSI als Review-Struktur funktioniert

Security Architecture Reviews scheitern oft an drei Mustern: Erstens werden Themen vermischt (z. B. TLS, Auth und Routing in einem einzigen Block), zweitens werden Controls nicht an konkrete Stellen im System gemappt, und drittens fehlen überprüfbare Akzeptanzkriterien. Das OSI-Modell verhindert diese Probleme, weil es eine natürliche Ordnung vorgibt: Physische und Netzwerkgrundlagen (Layer 1–3), verbindungs- und zustandsbasierte Risiken (Layer 4–5) sowie kryptografische und applikative Controls (Layer 6–7). Dadurch entsteht ein „Vollständigkeits-Check“: Wenn Sie zu jeder Schicht die Kernfragen beantworten können, sinkt die Wahrscheinlichkeit, dass ein Review relevante Angriffsflächen übersieht.

Als ergänzende Orientierung, wie Architekturentscheidungen in ein Zero-Trust-Denken überführt werden, ist NIST SP 800-207 hilfreich, insbesondere für Begriffe wie Policy Enforcement Points, Trust Evaluation und kontinuierliche Verifikation.

So nutzen Sie das Template in der Praxis

Ein OSI-basiertes Review-Template ist am wirksamsten, wenn es in drei Phasen genutzt wird: Vorab (As-Is/To-Be klären), im Review (Risiken und Controls abprüfen) und nach dem Review (Findings, Maßnahmen, Nachweise). Das Ziel ist nicht, jede Frage „mit Text zu beantworten“, sondern eindeutige Entscheidungen zu treffen: akzeptiert, mitigiert, transferiert oder offen – mit Owner und Termin.

• Vorab: Architekturdiagramme, Datenflüsse, Identitäts- und Netzsegmente, kritische Assets, externe Abhängigkeiten.
• Review: OSI-Fragenkatalog durchgehen, Control Points markieren, fehlende Evidence identifizieren.
• Nacharbeit: Findings priorisieren (Risiko), Maßnahmen definieren (Engineering), Tests und Monitoring festlegen (Betrieb).

Template-Header: Kontextfragen, die jedes Review braucht

Bevor Sie in OSI-Schichten einsteigen, sollten Sie den Rahmen festziehen. Diese Fragen reduzieren Missverständnisse und helfen, die Review-Tiefe an die Kritikalität anzupassen.

• Was ist der Geschäftszweck des Systems und welche kritischen Prozesse hängen davon ab?
• Welche Datenklassen werden verarbeitet (z. B. personenbezogen, Finanzdaten, Secrets, Betriebsgeheimnisse)?
• Welche Umgebungen sind im Scope (Prod, Staging, Dev) und wie unterscheiden sie sich?
• Wo liegen die Trust Boundaries (intern/extern, Tenant-Grenzen, Admin vs. Data Plane)?
• Welche externen Abhängigkeiten bestehen (Cloud-Dienste, SaaS, Anbieter, Remote Hands)?
• Welches Threat Model ist plausibel (Insider, Internet-Angreifer, kompromittierter Client, Supply-Chain)?
• Welche Evidence soll ein Auditor oder Incident Response später sehen können?

Für ein strukturiertes Risikodenken und Sicherheits-Outcomes eignet sich als Rahmen NIST CSF, weil es Anforderungen an Identify/Protect/Detect/Respond/Recover systematisch verknüpft.

Layer 1: Physische Sicherheit, Standort- und Lieferkettenannahmen

Layer 1 ist im Review oft unterrepräsentiert, obwohl physische Zugänge und Lieferkette einen direkten Einfluss auf die Glaubwürdigkeit aller späteren Controls haben. Gerade in Rechenzentren, Colocation oder bei Drittparteien müssen Annahmen sauber dokumentiert werden.

• Wo stehen die Systeme physisch (eigene RZs, Colocation, Edge, Büro, OT-Standorte)?
• Wer hat physischen Zugang zu Racks, Konsolen, Management-Netzen und Ersatzhardware?
• Gibt es eine Chain-of-Custody für Hardwarewechsel, RMA, Remote Hands und Lieferungen?
• Wie wird Manipulation erkannt (Inventar, Siegel, Kamera, Zutrittsprotokolle, regelmäßige Checks)?
• Welche Abhängigkeiten bestehen bei Strom, Klima, Verkabelung, OOB-Management?

Layer 2: Switching, Spoofing-Risiken und lokale Angriffsflächen

Layer 2 ist besonders relevant in Campus/LAN, Rechenzentrums-Fabrics und hybriden Setups. In reinen Cloud-VPCs ist Layer 2 oft abstrahiert; dann muss im Review klar sein, welche L2-ähnlichen Controls (z. B. virtuelle Switch-Funktionen, Host-Policies) tatsächlich vorhanden sind.

• Welche Segmente sind Layer-2-basiert, welche sind geroutet (L3)?
• Wie werden ARP-/DHCP-Spoofing und Rogue Services verhindert oder detektiert?
• Gibt es NAC/802.1X oder gleichwertige Mechanismen zur Geräte-Authentisierung?
• Wie wird der Blast Radius bei kompromittierten Endgeräten begrenzt (VLANs, PVLANs, Isolation)?
• Welche Monitoring-Daten existieren auf L2 (Switch-Logs, MAC-Table Events, Port-Status, BPDU Events)?

Layer 3: Routing, Segmentierung und klare Boundaries

Layer 3 ist das Rückgrat vieler Sicherheitsarchitekturen, weil dort Zonen, Reachability und Egress gesteuert werden. Ein OSI-Review muss hier sehr konkret sein: „Segmentiert“ ist kein Zustand, sondern eine Policy mit expliziten Erlaubnissen.

• Welche Sicherheitszonen existieren (User, Server, Prod, Management, Third-Party, Internet Edge)?
• Ist die Default-Policy zwischen Zonen deny und sind Ausnahmen dokumentiert?
• Wie wird Egress kontrolliert (zentrale Gateways, Proxies, NAT, DNS-Resolver, CASB)?
• Wie wird IP-Spoofing verhindert (uRPF/ACLs, Edge-Filtering, Anti-Spoofing auf Transit)?
• Wie werden Routing-Änderungen (Peering, BGP/OSPF, Cloud Route Tables) freigegeben und überwacht?
• Welche Flow-Daten existieren (NetFlow/sFlow/IPFIX, VPC Flow Logs) und wie lange werden sie aufbewahrt?

Mini-Check: Segmentierung als prüfbare Anforderung formulieren

• Welche Zonen dürfen miteinander sprechen – und über welche Ports/Protokolle?
• Wo liegt der Enforcement Point (Firewall, Security Group, Router ACL, Service Mesh Egress)?
• Welche Evidence belegt die Policy (Export, Rule-ID, Change Ticket, Log-Korrelation)?

Layer 4: Transport, State, DDoS-Resilienz und Scan-Signale

Layer 4 entscheidet, ob Systeme unter Last stabil bleiben und ob Verbindungsabuse früh erkannt wird. Reviews sollten hier nicht nur „Firewall-Regeln“ abfragen, sondern auch Kapazitäts- und Timeout-Design, weil State Exhaustion in der Praxis häufige Ausfall- und Incident-Ursache ist.

• Welche Services sind stateful, welche stateless (Firewalls, Load Balancer, NAT, Proxies)?
• Wie werden SYN-Flood, Connection Exhaustion und State-Table-Überlauf mitigiert?
• Welche Timeouts sind gesetzt (SYN, TCP idle, UDP, NAT) und sind sie risiko- und lastgerecht?
• Gibt es Rate Limits oder DDoS-Schutz auf L4 (Scrubbing, Anycast, Upstream Filtering)?
• Wie wird Port-Scanning (auch Low-and-Slow) erkannt (Flow-Analytics, Firewall-Events, IDS)?

Ein prüfbarer Indikator für State-Reserven mit MathML

Damit „ausreichende Kapazität“ nicht zur Gefühlssache wird, kann ein einfaches Sicherheitskriterium vereinbart werden:

$\mathrm{ReserveRatio}=\frac{\mathrm{MaxStateEntries}}{\mathrm{PeakObservedStates}}$

Im Review sollten Sie fragen: Welcher Mindestwert ist akzeptabel (z. B. > 2), wie wird Peak gemessen, und welche Alarme greifen, bevor der Wert kritisch wird?

Layer 5: Session, Remote Access, Admin Plane und Persistenz

Viele Architektur-Reviews fokussieren auf Netz und TLS, unterschätzen aber Session-Risiken: Wie lange bleiben Sessions gültig, wie werden sie gebunden, und wie wird Missbrauch sichtbar? Das gilt besonders für Remote Access (VPN, ZTNA, Bastion, RDP, SSH) und für Management-Oberflächen.

• Welche Session-Typen existieren (User, Service, Admin) und wie unterscheiden sich ihre Policies?
• Welche maximalen Session-Lifetimes und Idle-Timeouts gelten – und warum?
• Wie wird Session Hijacking/Replay erschwert (Re-Auth, Token Binding, mTLS, Device Posture)?
• Wie wird Remote Access überwacht (Login, MFA, Quell-IP, Ziel, Dauer, Befehle/Aktionen)?
• Gibt es Break-Glass-Accounts, wie sind sie gesichert, und wie wird die Nutzung geprüft?

Layer 6: TLS, Zertifikate, Cipher Policies und Trust Stores

Layer 6 ist die Schicht, in der „Verschlüsselung“ konkret wird: Protokollversionen, Cipher Suites, Zertifikatslebenszyklus und Trust Model. Reviews sollten hier nicht bei „TLS ist an“ stehen bleiben, sondern Rotation, Validierung und Betriebsrealität (Monitoring, Inspection, Compliance) abprüfen.

• Welche TLS-Versionen sind erlaubt, und sind Legacy-Protokolle deaktiviert?
• Wie ist die Cipher-Suite-Policy definiert und wie werden Downgrades verhindert?
• Wie werden Zertifikate inventarisiert, rotiert, überwacht (Ablauf, Miss-Issuance, Revocation-Handling)?
• Welche Trust Stores existieren (Clients, Server, Proxies, Container Images) und wie werden Änderungen kontrolliert?
• Wo findet TLS-Termination statt (Edge, Load Balancer, Service Mesh) und was bedeutet das für Logging und Forensics?

Für praxisnahe TLS-Empfehlungen und sichere Defaults sind die OWASP Cheat Sheet Series eine gute, zugängliche Referenz.

Layer 7: App-, API- und Identity-Kontrollen als Architekturfragen

Layer 7 ist der Ort, an dem Authentisierung, Autorisierung, Abuse-Prevention und Datenzugriff zusammenkommen. In Infrastrukturprojekten wird Layer 7 relevant, sobald Sie API Gateways, WAF, Identity Provider, Service Mesh, zentrale Admin-UIs oder SaaS-Integrationen einsetzen.

• Wie ist AuthN/AuthZ umgesetzt (SSO, MFA, RBAC/ABAC, Scopes, Least Privilege)?
• Wie werden API-Risiken adressiert (Rate Limits, Schema-Validierung, AuthZ pro Endpoint, Token-Lifetime)?
• Welche Schutzmechanismen existieren gegen typische Web-Angriffe (Injection, Smuggling, Traversal, SSRF)?
• Wie werden Bots und automatisierte Zugriffe unterschieden (Legit Automation vs. Abuse)?
• Welche Audit-Events entstehen für Admin-Aktionen und kritische Datenzugriffe?

Als gemeinsame Sprache für Web- und API-Risiken ist OWASP Top 10 hilfreich, weil es Kategorien liefert, die sich gut in Requirements und Use Cases übersetzen lassen.

Cross-Layer: Logging, Telemetrie, Evidence und IR-Fähigkeit

Ein Review ist nur so gut wie die spätere Nachweisbarkeit. Deshalb sollte ein OSI-Template einen eigenen Block für „Evidence“ enthalten: Welche Datenquellen belegen, dass Controls wirken, und wie können Sie einen Incident untersuchen, ohne raten zu müssen? Das ist auch ein starker E-E-A-T-Hebel, weil es Betrieb und Incident Response sichtbar mitdenkt.

• Welche zentralen Logs existieren (Identity, Netzwerk, Endpoint, Cloud Control Plane, App)?
• Ist Zeitsynchronisation überall konsistent und werden Events mit korrelierbaren IDs versehen (Request-ID, Session-ID)?
• Welche Aufbewahrungsfristen gelten, und wie ist Log-Integrität (Manipulationsschutz) sichergestellt?
• Welche Detection-Use-Cases sind definiert (Egress-Anomalien, ungewöhnliche Admin-Aktionen, Policy-Drift)?
• Wie werden False Positives reduziert (Layer-Kontext, Asset-Kritikalität, Baselines)?

Review-Scoring: Wie Sie Ergebnisse priorisieren, ohne zu überfrachten

Damit ein Template nicht zu einer endlosen Checkliste wird, hilft eine einfache Priorisierung pro Finding. Sie müssen kein komplexes Risikomodell einführen; entscheidend ist Konsistenz. Eine praktikable Methode ist, Findings entlang von Impact, Likelihood und Detection-Ability zu bewerten und daraus eine Umsetzungsreihenfolge abzuleiten.

• Impact: Was passiert im Worst Case (Datenabfluss, Produktionsausfall, Privilege Escalation)?
• Likelihood: Wie realistisch ist das Szenario angesichts Exponiertheit und Angriffsfläche?
• Detection: Würden Sie es bemerken – und könnten Sie es beweisen?

„Die richtigen Fragen“ als kompakter Fragenkatalog zum Mitnehmen

Wenn Sie nur einen Kernteil aus diesem Template übernehmen, dann diesen: ein kurzer, schichtbasierter Fragenkatalog, der in jedem Review in 30–60 Minuten die größten Lücken aufdeckt.

• L1: Wer kann physisch eingreifen, und welche Annahmen machen wir über Standorte und Drittparteien?
• L2: Können lokale Angreifer Spoofing betreiben, und wie ist der Blast Radius begrenzt?
• L3: Wo sind die Zonen, und ist Default-Deny wirklich durchgesetzt – inklusive Egress?
• L4: Wo existiert State, und was passiert bei Überlast, Scans oder DDoS-ähnlichen Mustern?
• L5: Wie werden Sessions begrenzt, gebunden und überwacht – besonders für Admin und Remote Access?
• L6: Welche TLS- und Zertifikatsstandards gelten, und wie stellen wir Rotation und Trust sicher?
• L7: Wie wird AuthZ granular umgesetzt, wie verhindern wir Abuse, und welche Audit-Spuren entstehen?
• Evidence: Welche Logs/Metriken beweisen Wirksamkeit, und wie würden wir einen Incident rekonstruieren?

So machen Sie das Template „review-ready“ für Teams und Stakeholder

Ein Template entfaltet Wirkung, wenn es in bestehende Prozesse integriert ist: Architektur-Boards, Change Management, IaC-Reviews, Security Gates. Damit es nicht als „Security-Bürokratie“ wahrgenommen wird, sollten Sie es schlank halten und konsequent mit technischen Artefakten verknüpfen.

• Jede OSI-Schicht bekommt einen festen Abschnitt im Review-Dokument (max. 5–10 Fragen, je nach Kritikalität).
• Zu jeder relevanten Antwort existiert ein Link/Artefakt: Diagramm, Policy-Export, Terraform-Plan, Log-Beispiel, Testfall.
• Findings werden nicht als „Problem“ formuliert, sondern als Entscheidung: akzeptieren, mitigieren, verschieben – mit Owner und Datum.
• Für Ausnahmen gibt es einen Ablaufmechanismus (Expiry) und einen Nachweis, dass das Risiko verstanden wurde.

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.