Checkliste für Security Controls pro OSI-Layer (audit-ready)

Eine Checkliste für Security Controls pro OSI-Layer ist besonders dann wertvoll, wenn Sie nicht nur „irgendwelche“ Schutzmaßnahmen sammeln, sondern einen audit-ready Nachweis führen müssen: Welche Kontrollen existieren, wo wirken sie technisch (L1–L7), wie werden sie überwacht, wer ist verantwortlich, und welche Evidenz belegt Wirksamkeit und Betrieb? In vielen Umgebungen scheitern Audits weniger an fehlenden Tools als an fehlender Nachvollziehbarkeit. Kontrollen sind zwar implementiert, aber nicht dokumentiert; Logs existieren, aber ohne Retention-Plan; Policies sind definiert, aber nicht durchgesetzt; und es fehlt eine klare Zuordnung zu Systemgrenzen und Trust-Boundaries. Das OSI-Modell bietet hier eine stabile Struktur: Es zwingt dazu, Sicherheitsmaßnahmen entlang der tatsächlichen Angriffsflächen zu ordnen – von physischem Zugriff (Layer 1) über Spoofing und Routing-Integrität (Layer 2/3) bis hin zu Transport-, Session-, Kryptografie- und Applikationskontrollen (Layer 4–7). Diese Checkliste ist so aufgebaut, dass sie im Tagesbetrieb nutzbar ist (für Engineering und Betrieb) und gleichzeitig auditfähig bleibt (für Compliance, interne Revision, externe Prüfer). Sie erhalten pro Layer konkrete Kontrollpunkte, typische Evidenzen, Prüfintervalle und Hinweise, wie Sie Lücken schnell identifizieren, ohne in „Checkbox-Security“ abzurutschen.

So verwenden Sie die Checkliste audit-ready (ohne Overhead zu erzeugen)

„Audit-ready“ bedeutet in der Praxis: Eine Kontrolle ist nicht nur implementiert, sondern auch nachweisbar und betriebsfähig. Dafür sollten Sie jede Kontrolle mit vier Metadaten versehen: Scope (wo gilt sie), Owner (wer verantwortet sie), Evidence (welche Beweise gibt es) und Cadence (wie oft wird geprüft). Diese vier Punkte machen den Unterschied zwischen einer Tool-Liste und einem prüfbaren Kontrollsystem.

• Scope: Asset/Zone/VRF/VPC, betroffene Interfaces, Services, Standorte.
• Owner: Teamrolle (NetOps, SecOps, Plattform, AppSec, IAM, Facilities).
• Evidence: Konfigurations-Snapshot, Logauszug, Telemetrie-Dashboard, Ticket/Change, Report.
• Cadence: kontinuierlich (Monitoring), täglich, wöchentlich, monatlich, pro Change, pro Quartal.

Minimaler Kontrollnachweis pro Item

Wenn Sie pro Kontrolle einen minimalen Nachweisstandard festlegen, vermeiden Sie endlose Diskussionen. Ein praxistauglicher Mindeststandard kann so aussehen:

• Design-Nachweis: Policy oder Architekturentscheidung (was soll erreicht werden?).
• Implementierungs-Nachweis: Konfiguration oder IaC-Quelle (wie ist es umgesetzt?).
• Betriebs-Nachweis: Monitoring/Alerts/Reports (wie wird es betrieben?).
• Wirksamkeits-Nachweis: Test, Tabletop, Kontrollmessung oder Incident-Learning (wirkt es wirklich?).

Layer 1: Physical Controls (L1) – Zugriff, Manipulation, Supply Chain

Layer 1 ist häufig außerhalb klassischer Security-Engineering-Routinen, ist aber auditkritisch: Physischer Zugriff kann höhere Kontrollen umgehen. Die Checkliste fokussiert daher auf nachweisbare Zutritts- und Manipulationssicherheit sowie auf Change-Disziplin an physischen Übergängen.

• Zutrittskontrolle zu Standorten: Badge/MFA, Besucherprozesse, Begleitungspflicht. Evidence: Zutrittslogs, Besucherregister, Policy-Dokument.
• Racks/Rooms abgesichert: Rack Locks, Cage, getrennte Bereiche für kritische Systeme. Evidence: Asset-Inventory, Foto-/Auditprotokoll, Standortplan.
• Tamper-Evidence: Plomben/Tamper-Seals an kritischen Komponenten und Cross-Connects. Evidence: Prüfprotokolle, Seriennummernzuordnung.
• Out-of-Band (OOB) getrennt: OOB-Netz logisch/physisch getrennt, strenge Zugriffskontrolle. Evidence: Netzplan, Firewall/ACL-Regeln, Jump-Host-Logs.
• Remote-Hands Governance: Freigabeprozess, Vier-Augen-Prinzip für kritische Arbeiten. Evidence: Tickets, Change-Records, Lieferanten-Reports.
• Medien- und Hardware-Entsorgung: sichere Löschung/Schreddern, Chain-of-Custody. Evidence: Entsorgungszertifikate, Asset-Decommission-Tickets.

Layer 2: Data Link Controls (L2) – Spoofing, Loops, Segmentgrenzen

Layer 2 ist ein häufiger „Blind Spot“ in Audits, weil viele Kontrollen implizit angenommen werden („Das Netz ist intern“). Audit-ready wird L2 erst, wenn Sie nachweisen können, wie Sie Spoofing und lokale Manipulation begrenzen.

• 802.1X/NAC (wo anwendbar): Authentifizierung am Port/WLAN, definierte Rollen/Profiles. Evidence: NAC-Policies, Auth-Logs, Ausnahmeprozess.
• Port Security: MAC-Limits, Sticky MAC, Shutdown/Restrict bei Verstoß. Evidence: Switch-Konfig, Violation-Events.
• DHCP Snooping: Trust/Untrust Ports korrekt, Binding-Table aktiv. Evidence: Snooping-Konfig, Binding-Auszug.
• Dynamic ARP Inspection: DAI auf relevanten VLANs, gekoppelt an Snooping. Evidence: DAI-Stats, Drop-Counter, Policy.
• Storm Control: Limits für Broadcast/Multicast/Unknown Unicast. Evidence: Interface-Counter, Alarm-Regeln.
• STP Guards: BPDU Guard/Root Guard, dokumentierte Topologie. Evidence: STP-Status, Topology-Change Logs.
• L2-Segmentierung: minimale Broadcast-Domänen, PVLANs/EVPN je nach Design. Evidence: VLAN/EVPN-Design, Konfig-Auszug.

Für technische Grundlagen zu ARP eignet sich RFC 826 (ARP) als stabile Referenz, besonders wenn Sie DAI/DHCP-Snooping begründen.

Layer 3: Network Controls (L3) – Routing-Integrität, Segmentierung, Anti-Spoofing

Layer 3 ist auditrelevant, weil hier Trust Boundaries technisch erzwungen werden: VRFs/VPCs, ACLs, Routing-Policies. Der Schwerpunkt liegt auf „Least Privilege“ im Netz (wer darf wohin?) und auf Integrität der Routing-Entscheidungen (keine ungewollten Leaks).

• Segmentierung per VRF/VPC/VNet: klare Zonen, dokumentierte Interconnects. Evidence: Netzarchitektur, Route Targets/Peers, Inter-VRF-Regeln.
• ACLs / Security Groups: Default-Deny an Zonenübergängen, explizite Freigaben. Evidence: Regelwerke, Review-Protokolle, IaC-Diffs.
• Anti-Spoofing (uRPF / Ingress-Filter): uRPF (strict/loose) oder statische Ingress-Filter an Edge/Access. Evidence: Konfig, Drop-Counter, Ausnahme-Liste.
• Routing-Policy Guards: Prefix-Lists, Route-Maps/Policies, max-prefix Limits. Evidence: Policy-Konfig, Prefix-Count Monitoring, Change-History.
• Route Leak Prevention: kontrollierte Redistribution, klare Export/Import-Regeln. Evidence: Policy-Dokument, Tests, Incident-Postmortems (falls vorhanden).
• Management Plane Trennung: separate Management-Netze/VRFs, Zugriff nur über Jump Host. Evidence: Netzplan, Firewall-Regeln, Session-Logs.

Wenn BGP eine Rolle spielt, ist RFC 4271 (BGP-4) eine passende Referenz, um Nachweise zu Sessions, Policies und Sicherheitsrisiken sauber zu formulieren.

Layer 4: Transport Controls (L4) – Statefulness, Portflächen, Exhaustion-Schutz

Layer 4 ist die Schicht, in der sich viele Availability- und Abuse-Risiken materialisieren: SYN Floods, Session Exhaustion, Fehlfunktionen durch asymmetrisches Routing bei stateful Geräten. Audit-ready wird L4, wenn Sie nicht nur Ports freigeben, sondern Zustands- und Kapazitätsgrenzen aktiv steuern.

• Stateful Firewall Policies: Default-Deny, minimale Portfreigaben, dokumentierte Ausnahmen. Evidence: Policy-Exports, Review-Logs.
• Admin-Ports restriktiv: SSH/RDP/WinRM nur über Bastion, keine „Anywhere“-Freigaben. Evidence: Firewall/SG-Regeln, Bastion-Access-Logs.
• SYN-Flood-Schutz: SYN Cookies/SYN Proxy, Rate Limits. Evidence: DDoS-Profile, Metriken (SYN Rate), Tests/Drills.
• Conntrack/Session Table Monitoring: Auslastung, Drops, Timeouts, Kapazitätsplanung. Evidence: Dashboards, Alarm-Definitionen, Kapazitätsreports.
• NAT-Exhaustion Prevention: Portpool-Monitoring, Limits, Skalierungsplan. Evidence: NAT-Stats, Trendgrafiken, Runbook.
• Timeout-Policies: dokumentierte Session-Timeouts passend zum Traffic. Evidence: Config-Auszug, Change-Notes, Troubleshooting-Beispiele.

Für TCP-Verhalten und Begriffe wie Retransmissions, Handshake und Zustandslogik ist RFC 9293 (TCP) eine stabile Referenz.

Layer 5: Session Controls (L5) – Identität, Token, Lifecycle, Revocation

Layer 5 wird im OSI-Alltag oft vernachlässigt, ist aber auditkritisch, weil viele Kontrollen zur Zugriffssicherheit (Sessions, Tokens, SSO) hier wirken. „Audit-ready“ bedeutet vor allem: nachvollziehbarer Session-Lifecycle und saubere Widerrufbarkeit.

• Session-Lifecycle Policies: TTLs, Idle-Timeouts, Rotation. Evidence: Policy-Dokument, Konfig im IdP/Gateway.
• Token Rotation und Revocation: Refresh Token Rotation, schnelle Sperrung bei Incident. Evidence: Revocation-Logs, Playbooks, Testprotokolle.
• Sichere Cookies: Secure, HttpOnly, SameSite passend zum Use Case. Evidence: Header-Checks, Security-Scanner-Reports.
• Step-up Auth für kritische Aktionen: zusätzliche Verifikation für Admin/Payments/Secrets. Evidence: IAM-Policies, Audit-Trails.
• Anomalieerkennung: ungewöhnliche Sessiondauer, „impossible travel“, Token-Missbrauch. Evidence: SIEM-Regeln, Detection-Runbooks.

Layer 6: Presentation Controls (L6) – TLS, Zertifikate, Kryptografie-Policies

Layer 6 ist in Audits häufig ein Schwerpunkt, weil TLS-Policies, Zertifikatslebenszyklen und Schlüsselmanagement messbar sind und klare Standards existieren. Audit-ready heißt: klare Krypto-Standards, automatisierte Rotation und nachweisbare Durchsetzung.

• TLS-Policy: erlaubte Versionen/Cipher Suites, Deaktivierung schwacher Optionen. Evidence: Policy, Scanner-Reports, Gateway/LB-Konfig.
• Zertifikatsmanagement: automatisierte Ausstellung, Rotation, Ablaufalarme. Evidence: CA-Logs, Zertifikatsinventar, Expiry-Dashboards.
• mTLS (wo erforderlich): Service-to-Service Absicherung, klare Trust Stores. Evidence: mTLS Success/Fail Metriken, Mesh/Gateway-Konfig.
• Key/Secret Management: zentrale Vault/Secrets, Zugriff nach Least Privilege, Rotation. Evidence: Access-Logs, Policies, Rotation-Protokolle.
• Certificate Pinning (kontextabhängig): nur dort, wo operativ beherrschbar. Evidence: Client-Policy, Ausnahmeprozess.

Für TLS 1.3 als Referenz eignet sich RFC 8446 (TLS 1.3), wenn Sie Anforderungen und Fehlersignaturen präzise dokumentieren wollen.

Layer 7: Application Controls (L7) – WAF, API Security, AuthZ, Business Abuse

Layer 7 ist oft am stärksten ausgebaut, aber auditready wird es erst durch klare Policies, konsistente Logs und nachweisbare Autorisierungsregeln. Der Fokus liegt nicht nur auf Blocken, sondern auf nachvollziehbarer Durchsetzung und messbarer Wirksamkeit.

• WAF/WAAP-Regeln: Baseline-Schutz, Tuning-Prozess, dokumentierte Ausnahmen. Evidence: Rule Sets, Block/Allow Logs, Change-Historie.
• API Gateway Policies: Auth, Schema Validation, Quotas, Rate Limits. Evidence: Policy-Exports, Per-Endpoint-Metriken.
• AuthZ (RBAC/ABAC): „deny by default“, least privilege, Reviews für Rollen. Evidence: IAM-Model, Access Reviews, Audit Logs.
• Input Validation: serverseitige Validierung, sichere Defaults. Evidence: Secure Coding Standards, Tests, SAST/DAST Reports.
• Abuse-Prevention: Credential Stuffing Schutz, Bot-Management, risk-based Auth. Evidence: Detection-Regeln, Fraud/Abuse Dashboards.
• Audit Logging: unveränderbare Logs für privilegierte Aktionen, PII-Schutz. Evidence: Logschema, Retention-Policy, Zugriffskontrollen.

Als praxisnahe Referenz für typische Webrisiken und Kontrollklassen eignet sich der OWASP Top 10.

Cross-Layer: Kontrollen, die mehrere OSI-Schichten abdecken (und im Audit sauber erklärt werden müssen)

Viele der wirksamsten Maßnahmen sind nicht „nur“ L3 oder „nur“ L7, sondern wirken über mehrere Ebenen. Audit-ready ist hier vor allem die klare Beschreibung der Durchsetzungspunkte und der Evidenz.

• Zero Trust / Identity-Aware Access: Identität (L5/L7), Transportabsicherung (L6), Segmentierung (L3), Enforcement am Gateway (L7). Evidence: Policy, Auth-Logs, Segmentregeln.
• DDoS-Mitigation: volumetrisch (L3/L4) und semantisch (L7). Evidence: Scrubbing-Events, Rate-Limit Logs, Impact-Metriken.
• Microsegmentation: L3/L4 Policies plus Service Identity/mTLS (L5/L6). Evidence: Policy Graph, mTLS Metriken, Change Reviews.
• Monitoring/Detection: Metriken (L2–L4), Logs/Traces (L7), Korrelation (SIEM). Evidence: Alarmregeln, Playbooks, Incident-Timeline.

Audit-Format: So dokumentieren Sie jede Kontrolle in einem einheitlichen Record

Damit die Checkliste nicht „lose Punkte“ bleibt, sollten Sie pro Kontrolle einen standardisierten Record pflegen. Ein guter Record ist kurz, aber vollständig genug für Prüfungen und Betrieb.

• Control-ID: eindeutige Kennung (z. B. L3-ACL-001).
• OSI-Layer: L1–L7 (ggf. mehrere).
• Ziel: was verhindert/erkennt die Kontrolle?
• Scope: Systeme, Zonen, Interfaces, Services.
• Owner: Team/Role, Eskalationspfad.
• Enforcement Point: wo wird technisch durchgesetzt (Device/Gateway/Agent)?
• Evidence: Links/Artefakte (Konfig, Logs, Dashboard, Ticket).
• Cadence: Review-/Testfrequenz.
• Exceptions: dokumentierte Abweichungen mit Ablaufdatum.
• Tests: wie wird Wirksamkeit geprüft (automatisiert/manuell)?

Ein einfaches „Audit-Readiness“-Scoring

Wenn Sie schnell sehen wollen, welche Kontrollen auditreif sind, hilft ein kleines Scoring aus vier Dimensionen: Design (D), Implementierung (I), Betrieb (B), Wirksamkeitstest (W). Jeder Wert 0–1. Der Audit-Readiness-Score ARS ist der Durchschnitt:

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

Kontrollen mit niedrigem W (kein Wirksamkeitstest) sind typische Audit-Fallstricke, selbst wenn Policy und Konfiguration existieren.

Review-Zyklen: Welche Kontrollen wie oft prüfen?

Audits fragen nicht nur „gibt es das?“, sondern „wie stellen Sie sicher, dass es weiterhin gilt?“. Ein pragmatischer Plan koppelt die Kadenz an Risiko und Änderungsrate.

• Kontinuierlich: Drops/Anomalien, IDS/WAF Events, Zertifikatsablaufalarme, Session Table Pressure.
• Wöchentlich: Top Änderungen an ACLs/SGs, neue offene Ports, neue DNS/Ingress Endpoints.
• Monatlich: Access Reviews, Ausnahme-Reviews, WAF/Rate-Limit Tuning, Config Drift Checks.
• Quartalsweise: Tabletop/Drills, DDoS-Übung, Zertifikats-/Key-Prozesse, Segmentierungsreview.
• Pro Change: Post-Change-Checks für kritische Netz- und Security-Änderungen.

Typische Audit-Fallen im OSI-Checklistenansatz (und wie Sie sie vermeiden)

• Kontrollen ohne Evidenz: „Wir haben WAF“ reicht nicht. Sie brauchen Regeln, Logs, Tuning- und Ausnahmeprozess.
• „Default Allow“ durch Ausnahmen: Ausnahmen dürfen nicht zum Standard werden; setzen Sie Ablaufdaten und Reviews.
• Unklare Ownership: Ohne Owner sind Kontrollen in der Praxis unbetreibbar und auditkritisch.
• Nur L7, kaum L2/L3: Audits erkennen schnell, wenn Segmentierung nur behauptet wird, aber technisch nicht erzwungen ist.
• Keine Wirksamkeitstests: Policies ohne Tests sind reine Absichtserklärungen.
• Retention ohne Plan: Logs sind vorhanden, aber nicht lange genug oder nicht manipulationsgeschützt.

Framework-Anbindung: OSI-Checkliste sinnvoll „übersetzen“

Die OSI-Checkliste ersetzt keine Standards, sie macht sie technisch greifbar. Häufige Audit-Referenzen lassen sich gut ergänzen, wenn Sie Ihre OSI-Controls zusätzlich auf Frameworks mappen (ohne doppelte Pflege zu erzeugen). Als konzeptioneller Rahmen für Control-Klassen ist NIST SP 800-53 Rev. 5 verbreitet; für Angriffs- und Technikmuster zur Ableitung von Detection/Evidence eignet sich MITRE ATT&CK. Für Web- und API-Risiken, die typischerweise Layer 7 betreffen, ist der OWASP Top 10 eine praxisnahe Ergänzung.

Weiterführende Ressourcen (für Policies und technische Nachweise)

• NIST SP 800-53 Rev. 5 für strukturierte Security-Control-Klassen und Audit-Argumentation.
• OWASP Top 10 für Layer-7-Risikokategorien und passende Kontrollmuster.
• MITRE ATT&CK für Taktiken/Techniken zur Ableitung von Detection- und Evidence-Anforderungen.
• RFC 826 (ARP), RFC 4271 (BGP-4), RFC 9293 (TCP), RFC 8446 (TLS 1.3) als stabile Protokollreferenzen für technische Nachweise pro OSI-Layer.

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.