Sichtbarkeit im SOC-Setup

Einstieg: Warum das für ISB relevant ist

Zentrale Frage: an welcher Stelle im Netz können wir überhaupt eine Aussage treffen?
Sicherheit ≠ "wir haben ein Tool installiert" — Sicherheit = wir können zu jedem Zeitpunkt sagen, was passiert ist, wer es war, und ob es normal war
Blinde Flecken sind der Normalzustand, nicht die Ausnahme — jede Infrastruktur hat sie. Die Frage ist, ob man sie kennt
ISB-Verantwortung: nicht Technik im Detail verstehen, aber wissen, WO Aussagen möglich sind und WO nicht — Grundlage für Risikobewertung und Meldepflichten ("können wir überhaupt rekonstruieren, was passiert ist?")

Firewall-Filterlog: jedes Pass/Block-Ereignis an einer Zonengrenze (WAN↔DMZ, DMZ↔LAN) — beantwortet "wer hat versucht wohin zu kommunizieren"
Suricata IPS inline: erkennt Angriffsmuster im Traffic selbst (Exploits, C2-Verkehr, Portscans) — beantwortet "war erlaubter Traffic trotzdem bösartig"

Filterlog zeigt nur Regelverstöße gegen die eigene Policy — ein Angriff über eine erlaubte Regel (z.B. Port 443 zum Webserver) taucht dort NICHT als Anomalie auf. Dafür braucht's IPS

Ohne das: technisch korrekter Zugriff sieht identisch aus wie Missbrauch mit gestohlenem Credential — kein Unterschied erkennbar ohne Kontext (Uhrzeit, Ort, Häufigkeit)

WAF (Coraza) sieht den tatsächlichen HTTP-Request-Inhalt zu unseren eigenen Webanwendungen — SQL-Injection, XSS, Command Injection auf Anwendungsebene
Proxy mit SSL-Bump + ClamAV (c-icap) sieht den Inhalt von ausgehendem Traffic der Nutzer — Malware-Download, Datenexfiltration

Das ist die einzige Ebene, die tatsächlich in die Nutzlast reinschaut — alle anderen Ebenen sehen nur Metadaten oder Muster

FIM = File Integrity Monitoring — Überwachung von Dateien/Verzeichnissen auf unerwartete Änderungen (Inhalt, Rechte, Eigentümer)
Was hat sich auf dem System selbst verändert — Dateien, Konfigurationen, Berechtigungen

Letzte Verteidigungslinie: wenn ein Angreifer alle Netzwerk-Kontrollen umgangen hat, sieht man es hier trotzdem, weil er auf dem System etwas anfassen musste

Ohne SSL-Bump: Firewall/IPS sehen nur Ziel-IP, Port, SNI (Servername) — der eigentliche Inhalt bleibt verschlüsselt und damit unsichtbar, auch für uns
Mit SSL-Bump am Proxy: Inhalt wird entschlüsselt, geprüft, neu verschlüsselt — aber NUR für Traffic, der tatsächlich über den Proxy läuft
Direkter TLS-Traffic (nicht über Proxy geroutet) bleibt für uns unsichtbar — Netzwerksegmentierung und Routing entscheiden, was überhaupt einsehbar sein kann
WAF sieht nur, was auf sie terminiert (Layer 7 HTTP/S, unsere eigenen Anwendungen) — alles andere läuft dran vorbei

Sichtbarkeit ist keine Eigenschaft eines Tools, sondern eine Eigenschaft der Netzwerkarchitektur — ein Tool kann nur sehen, was man ihm auch vorbeischickt

Alert entsteht am Sensor (Suricata / Filterlog / WAF / AV / FIM) → Wazuh-Agent → Wazuh-Manager
Manager korreliert Ereignisse, vergibt einen Schweregrad (Level 0–15)
Ab definierter Schwelle (z.B. Level ≥ 7) → automatische Mail-Benachrichtigung an das SOC-Postfach
SOC prüft: False Positive? Reale Bedrohung? → Ticket / Rückmeldung an zuständigen Admin

Die Eskalationskette ist nur so gut wie der schwächste Schritt — ein Sensor ohne Wazuh-Anbindung ist ein blinder Fleck, egal wie gut er lokal loggt
Für die ISB-Bewertung zählt nicht "loggt das System", sondern "kommt das Ereignis auch tatsächlich beim SOC an"