Oft werden sieben Säulen eines Security-Ökosystems gezeigt. Hier die detaillierte Einordnung: Wozu jede Domäne dient, welche Artefakte Pflicht sind und wie sie in ein ISMS/NIS2-Programm passen.

1. Information Security (InfoSec)

Zweck: Schutz von Informationen unabhängig vom Medium (digital, Papier, verbal). InfoSec liefert die Policies, Rollen und Prozesse.

Kernbausteine:
- Richtlinien (Sicherheitsleitlinie, Acceptable Use, Klassifizierung)
- Access-Management (RBAC, SoD-Checks, Berechtigungsreviews)
- Incident- & Breach-Logs (inkl. Meldeprozesse)
- Data-Classification-Register (Kritikalität, Owner, Schutzbedarf)

Praxis: InfoSec definiert, was geschützt werden muss und wie Entscheidungen dokumentiert werden. Ohne klare Verantwortung, keine Compliance.

2. Application Security (AppSec)

Zweck: Sicherstellen, dass Eigenentwicklungen und externe Anwendungen sicher gebaut, getestet und betrieben werden.

Kernbausteine:
- Threat Modeling (STRIDE, PASTA)
- Secure Coding Guidelines (Language-Specific)
- SAST/DAST-Reports, Dependency-Checks
- Patch- und Release-Tracking, SBOMs

Praxis: AppSec muss mit DevOps verzahnt sein (CI/CD-Gates, Pull-Request-Templates). Ohne Automatisierung versinkt man in manuellen Reviews.

3. Governance, Risk & Compliance (GRC)

Zweck: Transparenz über Anforderungen, Risiken, Kontrollen und Auditergebnisse.

Kernbausteine:
- Compliance-Register (ISO, NIS2, DORA, TISAX …)
- Risikoregister inkl. KRIs
- Control-Mapping (z. B. ISO 27001 ↔ NIS2-Artikel)
- Audit-Log & Maßnahmenverfolgung

Praxis: GRC liefert Management-Reports und stellt sicher, dass jede Maßnahme „prüffähig“ dokumentiert ist.

4. Security Operations Center (SOC)

Zweck: Erkennen und Reagieren. SOC bündelt Monitoring, Alerting, Triage und Forensik.

Kernbausteine:
- Use-Case-Katalog + Log-Source-Onboarding
- Incident-Response-Playbooks, Triage-Checklisten
- Malware-/RCA-Reports, Lessons Learned
- KPIs (MTTD, MTTR, False Positive Rate)

Praxis: Ein SOC funktioniert nur mit sauberem Asset-Inventar und klaren Kommunikationswegen zur IT/OT – sonst bleibt es beim „Ticket-Pingpong“.

5. Data Security

Zweck: Schutz sensibler Daten über ihren gesamten Lebenszyklus.

Kernbausteine:
- Dateninventar & Flow-Diagramme
- DLP-Policies, Incident-Logs
- Verschlüsselungs- und Schlüsselmanagement
- Aufbewahrungs- & Löschkonzepte

Praxis: Data Security muss eng mit InfoSec und Legal/Privacy zusammenarbeiten, sonst kollidieren Regulierung (z. B. DSGVO) und Betriebsanforderungen.

6. Network Security

Zweck: Segmentierung, Überwachung und Härtung des Netzwerks (On-Prem, Cloud, OT).

Kernbausteine:
- Zonen- & Segmentierungsdesign (Zero Trust, SD-WAN)
- NAC-Logs, Firewall-Rules, Allow-/Deny-Lists
- DDoS-Runbook, Remote-Access-Policies
- Inventar für Netzwerkgeräte & Firmwarestände

Praxis: Netzwerksicherheit ist heute stark mit Cloud-Security-Posture verknüpft: Security Groups, Azure Firewall, CloudFlare, etc.

7. Endpoint Security

Zweck: Schutz von Clients, Servern, mobilen Geräten und IoT/OT-Endpunkten.

Kernbausteine:
- Asset-Inventar + CMDB
- Baselines (CIS Benchmarks, Intune Policies)
- EDR/XDR-Alerts, Quarantäne-Workflows
- Kosten-/Auswirkungsreports für Incidents

Praxis: Endpoint Security ist die letzte Verteidigungsschicht. Ohne automatisierte Response (Isolation, Rollback) wird jeder Vorfall teuer.

Zusammenspiel & Lessons Learned

  • InfoSec + GRC geben den Rahmen (Policies, Nachweise).
  • AppSec, Data, Network, Endpoint liefern präventive Controls.
  • SOC überwacht und reagiert.
  • Alle speisen Daten ins ISMS (Risikoregister, KPIs, Audits).

Wer Cybersecurity so strukturiert, hat automatisch die Grundlage für NIS2, DORA oder ISO 27001 geschaffen – weil jede Domäne klare Ziele, Verantwortliche und Artefakte besitzt. Tools sind dann „nur“ die Umsetzung dieser Struktur.