OSI nutzen, um Security Requirements für Infrastruktur zu schreiben

Wer Security Requirements für Infrastruktur formulieren muss, steht oft vor demselben Problem: Die Anforderungen sind entweder zu allgemein („Netzwerk absichern“) oder zu technisch fragmentiert („Port X schließen, Regel Y setzen“), aber nicht durchgängig strukturierbar. Genau hier hilft der Ansatz OSI nutzen, um Security Requirements für Infrastruktur zu schreiben. Das OSI-Modell schafft eine einheitliche Denk- und Schreibstruktur über alle relevanten Ebenen hinweg – von physischer Anbindung über Routing und Transport bis hin zu Sitzungen, Datenrepräsentation und anwendungsnahen Infrastrukturservices. Dadurch werden Anforderungen präziser, überprüfbar und teamübergreifend verständlich. Für Einsteiger bietet das Modell eine klare Leitplanke, für erfahrene Teams ist es ein belastbares Raster für Architektur, Compliance und Betrieb. Entscheidend ist: Gute Security Requirements beschreiben nicht nur, was geschützt werden soll, sondern auch wo, wie und mit welchem Nachweis. Mit einer OSI-basierten Methodik lassen sich Anforderungen priorisieren, sauber in Backlogs überführen und über den gesamten Lebenszyklus einer Infrastruktur konsistent weiterentwickeln.

Warum OSI als Schreibrahmen für Infrastruktur-Sicherheitsanforderungen so gut funktioniert

Infrastruktur ist immer mehrschichtig. Selbst eine scheinbar einfache Anwendungskommunikation durchläuft physische Medien, Switching, Routing, Transportmechanismen, Sitzungszustände, Verschlüsselungs- und Formatlogik sowie servicebezogene Richtlinien. Wenn Security Requirements nur auf einer Ebene formuliert sind, entstehen Lücken an Übergängen – genau dort, wo Angriffe häufig ansetzen.

Das OSI-Modell verhindert diese Lücken, weil es Anforderungen entlang klarer Schichten ordnet. So lässt sich für jede Schicht beantworten:

• Welche Assets sind betroffen?
• Welche Bedrohungen sind realistisch?
• Welche Kontrollziele gelten?
• Wie lautet die konkrete, testbare Anforderung?

Diese Struktur erhöht die Qualität in drei Dimensionen:

• Nachvollziehbarkeit: Stakeholder verstehen, warum eine Vorgabe existiert.
• Prüfbarkeit: Audits und technische Tests lassen sich direkt an Anforderungen koppeln.
• Betriebstauglichkeit: Teams können Anforderungen in Policies, IaC und Monitoring übersetzen.

Was gute Security Requirements ausmacht

Bevor Sie OSI-Schicht für Schicht schreiben, sollten die Qualitätskriterien klar sein. Viele Anforderungen scheitern nicht am Inhalt, sondern an der Formulierung. Eine robuste Sicherheitsanforderung ist:

• Eindeutig: Keine mehrdeutigen Begriffe wie „angemessen“, „ausreichend“, „zeitnah“ ohne Schwellenwert.
• Messbar: Mit klaren Parametern, Grenzwerten oder Zuständen.
• Umsetzbar: Technisch realistisch in der Zielumgebung.
• Verifizierbar: Durch Test, Review, Scan oder Monitoring belegbar.
• Risiko-orientiert: Ableitbar aus Bedrohung, Schutzbedarf und Trust Boundaries.

Eine einfache Schreibformel ist hilfreich:

Anforderung = Objekt + Muss + Bedingung + Messkriterium + Nachweis

Beispielhaft gedacht: „Alle administrativen Zugriffe müssen über starke MFA erfolgen, wenn der Zugriff aus nicht verwalteten Netzen erfolgt; Nachweis über IdP-Logs und monatliche Kontrollprüfung.“

OSI-Methodik: Von Bedrohung zu Infrastruktur-Anforderung

Ein praxistauglicher Ablauf lässt sich in fünf Schritten umsetzen:

• Scope festlegen: Welche Infrastrukturdomäne wird betrachtet (z. B. Rechenzentrum, Cloud-VPC, Kubernetes-Cluster, WAN)?
• Trust Boundaries markieren: Wo wechseln Kontrolle und Vertrauensniveau?
• Schichtbezogene Bedrohungen erfassen: Je OSI-Layer typische Angriffsvektoren identifizieren.
• Kontrollziele formulieren: Was soll verhindert, erkannt oder begrenzt werden?
• Requirements schreiben: Präzise Soll-Vorgaben mit Prüf- und Nachweiskriterien erstellen.

Wichtig ist, nicht nur präventive Anforderungen zu schreiben. Gute Kataloge enthalten immer auch detektive und reaktive Elemente, damit Vorfälle früh erkannt und kontrolliert werden können.

Security Requirements pro OSI-Layer formulieren

Layer 1: Physische Sicherheit als Infrastrukturgrundlage

Auch in Cloud-zentrierten Umgebungen bleibt Layer 1 relevant, insbesondere für Edge, Filialen, OT-nahe Bereiche und Colocation. Typische Anforderungen:

• Netzwerk- und Serverhardware in kritischen Zonen muss gegen unautorisierten physischen Zugriff geschützt sein.
• Patchfelder und Uplink-Ports müssen dokumentiert, beschriftet und gegen unbeabsichtigte Umsteckvorgänge gesichert sein.
• Umgebungsalarme (Temperatur, Strom, Türkontakte) müssen zentral überwacht und revisionssicher protokolliert werden.

Nachweise können über Zutrittsprotokolle, Inventarlisten, Wartungsdokumentation und Alarm-Events geführt werden.

Layer 2: Sicherungsschicht, Zugangskontrolle und lokale Segmentierung

Layer 2 ist häufig die erste technische Verteidigung gegen laterale Bewegung im lokalen Netz. Anforderungen auf dieser Ebene adressieren unautorisierte Geräte, Spoofing und Broadcast-Domänenrisiken:

• Alle Access-Ports in Nutzersegmenten müssen 802.1X oder eine gleichwertige netzbasierte Authentisierung erzwingen.
• Trunk-Ports dürfen nur auf dokumentierten Uplinks aktiv sein; ungenutzte Ports müssen deaktiviert werden.
• Schutzmechanismen gegen ARP- und DHCP-Manipulation müssen in produktiven VLANs aktiviert sein.
• Management-VLANs sind strikt von Client- und Gastsegmenten zu trennen.

Verifikation erfolgt über Switch-Konfigurationen, NAC-Reports und Netzwerk-Scans in festgelegten Intervallen.

Layer 3: Routing, Zonierung und kontrollierte Erreichbarkeit

Layer 3 bestimmt, welche Netze überhaupt miteinander sprechen dürfen. Hier entstehen die zentralen Segmentierungsanforderungen:

• Jede Kommunikation zwischen Sicherheitszonen muss über definierte Kontrollpunkte geführt werden.
• Interzonenverkehr muss nach „Default Deny, Explicit Allow“ geregelt sein.
• Routing zwischen Produktiv-, Management-, Backup- und Entwicklungsnetzen muss logisch getrennt werden.
• Egress-Verkehr aus hochkritischen Zonen darf nur zu explizit freigegebenen Zielen erfolgen.

Diese Anforderungen sind besonders wirksam, weil sie die Reichweite eines erfolgreichen Erstzugriffs stark begrenzen.

Layer 4: Transportkontrollen, Portpolitik und Resilienz

Auf Transportebene geht es um Verbindungssteuerung, Session-Last und Missbrauchsbegrenzung. Typische Anforderungen:

• Offene TCP/UDP-Ports müssen pro Dienst dokumentiert und regelmäßig auf Notwendigkeit geprüft werden.
• Administrative Protokolle dürfen nur aus dedizierten Managementsegmenten erreichbar sein.
• Rate-Limits und Schutzmechanismen gegen Verbindungsfluten müssen an exponierten Endpunkten aktiv sein.
• Unsichere Legacy-Protokolle sind zu deaktivieren oder in isolierte Übergangssegmente zu kapseln.

Messkriterien umfassen offene Portlisten, Regelrezertifizierung und Last-/DoS-Testresultate.

Layer 5: Sitzungsintegrität und Identitätskontext

Viele Infrastrukturvorfälle eskalieren über schwache Sitzungssteuerung, etwa in Admin-Portalen, Bastion-Lösungen oder API-Gateways. Anforderungen sollten daher Sitzungslebenszyklen präzise festlegen:

• Privilegierte Sitzungen müssen nach definierter Inaktivitätszeit automatisch beendet werden.
• Session-Tokens sind kryptografisch stark zu erzeugen, kurzlebig auszugestalten und widerrufbar zu halten.
• Kontextwechsel mit erhöhtem Risiko (z. B. Gerät, Standort, Netzwerktyp) muss Re-Authentisierung auslösen.
• Parallele Admin-Sessions pro Identität sind auf ein begründetes Maß zu begrenzen.

Nachweise sind über IdP-Logs, Session-Store-Parameter und SIEM-Korrelation möglich.

Layer 6: Verschlüsselung, Protokollhärtung und Datenrepräsentation

Layer 6-Anforderungen definieren, wie Daten auf dem Weg und bei der Interpretation geschützt werden. Das betrifft Zertifikate, Cipher-Suites, Datenformate und Parsing-Regeln:

• Alle externen und internen sensiblen Verbindungen müssen mit aktuellen TLS-Konfigurationen abgesichert sein.
• Zertifikatsvalidierung darf nicht deaktivierbar sein; Zertifikatslebenszyklen sind automatisiert zu verwalten.
• Unsichere Verschlüsselungsalgorithmen und schwache Cipher-Suites sind auszuschließen.
• Nur definierte Datenformate und Content-Types dürfen an kritischen Schnittstellen verarbeitet werden.

Für die Prüfbarkeit eignen sich TLS-Scans, Zertifikatsinventare und Konfigurations-Baselines.

Layer 7: Infrastruktur-nahe Applikationsdienste und Policy-Enforcement

Auch wenn Layer 7 oft der Anwendungsentwicklung zugeschrieben wird, existieren zahlreiche infrastrukturseitige L7-Services: Reverse Proxies, API-Gateways, DNS-Sicherheitsfunktionen, WAF, E-Mail-Gateways, Service-Mesh-Policies.

• Exponierte Web- und API-Endpunkte müssen durch zentrale Policy-Enforcement-Komponenten geschützt werden.
• Eingaben an kritischen Schnittstellen sind auf Schema-, Größen- und Methodenebene zu validieren.
• DNS-Anfragen aus Serversegmenten dürfen nur über kontrollierte Resolver mit Logging erfolgen.
• Administrative Oberflächen müssen getrennte Zugriffspfade und erhöhte Authentisierungsanforderungen erzwingen.

Nachweise ergeben sich aus Gateway-Policies, WAF-Regelständen, DNS-Logs und Change-Dokumentation.

Requirements richtig priorisieren: Kritikalität, Exposition, Kompensationsgrad

Nicht jede Anforderung hat dieselbe Dringlichkeit. Damit Backlogs steuerbar bleiben, empfiehlt sich ein gewichtetes Priorisierungsmodell:

Priorität = Kritikalität × Exposition × Bedrohungsrelevanz − Kompensationsgrad

Mit Skalen von 1 bis 5 erhalten Sie eine einfache, teamtaugliche Rangfolge. So werden zunächst Anforderungen umgesetzt, die bei hoher Exposition und hohem Schadenpotenzial noch unzureichend kompensiert sind.

Vorlage für ein belastbares Requirement-Template

Ein standardisiertes Template reduziert Interpretationsspielräume und beschleunigt Reviews. Bewährte Felder sind:

• ID: Eindeutige Kennung
• OSI-Layer: Primärer Wirkbereich
• Schutzziel: Vertraulichkeit, Integrität, Verfügbarkeit, Nachvollziehbarkeit
• Anforderung: Präzise Muss-Formulierung
• Geltungsbereich: Systeme, Zonen, Umgebungen
• Prüfmethode: Test, Scan, Review, Monitoring
• Nachweis: Report, Log, Ticket, Konfigurationssnapshot
• Owner: Verantwortliche Rolle
• Review-Zyklus: Monatlich, quartalsweise, releasebasiert

Mit diesem Aufbau wird aus einer abstrakten Sicherheitsidee ein operativ nutzbares Steuerungsobjekt.

Integration in Betrieb und Cloud: von Papieranforderung zu technischer Durchsetzung

Security Requirements entfalten erst Wirkung, wenn sie in Betriebsprozesse und Automatisierung übersetzt werden. Dafür sind drei Ebenen zentral:

• Policy as Code: Anforderungen als versionierte Regeln in Infrastruktur- und Plattformpipelines.
• Continuous Compliance: Laufende Prüfung von Konfigurationen gegen Soll-Zustände.
• Runtime Visibility: Kontinuierliche Überwachung, ob Kontrollen im Betrieb wirksam bleiben.

Für Multi-Cloud- und Hybrid-Setups sollte je Requirement klar sein, wie die technische Entsprechung pro Plattform lautet, damit Sicherheitsziele konsistent bleiben, auch wenn die Implementierung variiert.

Häufige Fehler beim Schreiben von Infrastruktur-Requirements

• Zu abstrakt formuliert: Ohne Messkriterium nicht prüfbar.
• Tool-zentriert statt zielzentriert: Anforderungen sollten Kontrollziel und Wirkung beschreiben, nicht nur ein Produkt nennen.
• Kein Lebenszyklus: Fehlende Rezertifizierung führt zu Regelalterung und Schattenfreigaben.
• Keine Trennung nach Layern: Verantwortlichkeiten verschwimmen, Lücken bleiben unerkannt.
• Nur Prävention, keine Detektion: Vorfälle werden zu spät entdeckt.

Wer diese Fehler früh vermeidet, verbessert nicht nur die Sicherheitslage, sondern auch die Umsetzungsfähigkeit im Tagesbetrieb erheblich.

E-E-A-T stärken: belastbare Quellen und fachliche Verankerung

Für qualitativ hochwertige, veröffentlichungsfähige Security-Inhalte ist die Orientierung an anerkannten Quellen entscheidend. Für methodische und technische Vertiefung bieten sich unter anderem das NIST Cybersecurity Framework, die NIST SP 800-53 Sicherheitskontrollen, der CIS Controls Katalog, die ISO/IEC 27001 sowie das OWASP-Projekt zur IaC-Sicherheit an. Diese Referenzen helfen, Security Requirements für Infrastruktur nachvollziehbar zu begründen, konsistent zu priorisieren und revisionssicher zu dokumentieren.

Praxisnahe Beispielanforderungen für den direkten Einsatz

• Interzonenverkehr zwischen Produktiv- und Managementnetz muss standardmäßig blockiert und ausschließlich über freigegebene Jump-Pfade erlaubt sein.
• Alle administrativen Zugriffe auf Infrastrukturkomponenten müssen MFA-geschützt sein und über zentral protokollierte Identitäten erfolgen.
• Kritische interne Dienste müssen TLS-gesichert kommunizieren; unverschlüsselte Protokollvarianten sind in Produktionsumgebungen unzulässig.
• DNS-Verkehr aus Serversegmenten darf nur über autorisierte Resolver erfolgen; direkte externe DNS-Anfragen sind zu unterbinden.
• Firewall- und Security-Group-Regeln müssen mindestens quartalsweise rezertifiziert und ungenutzte Freigaben entfernt werden.
• Erkennungskontrollen für laterale Bewegung müssen für privilegierte Segmente aktiv sein und Alarme an das zentrale SIEM liefern.

Mit dieser OSI-orientierten Schreibweise werden Sicherheitsanforderungen präzise, überprüfbar und betrieblich anschlussfähig. Genau das ist in modernen Infrastrukturen der entscheidende Unterschied zwischen formaler Compliance und tatsächlich wirksamer Sicherheit.

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.