Sichtbarkeit im SOC-Setup

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?")

Die vier Sichtbarkeits-Ebenen

Netzwerk-Grenze (Filterlog + IPS)

• 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"

ISB-Punkt

• 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

Identität (Auth-Logs, LDAP, SSH)

• Wer hat sich wann, von wo, mit welchem Erfolg angemeldet
• Beantwortet die klassische Forensik-Frage: Account-Kompromittierung ja/nein

ISB-Punkt

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

Content-Ebene (WAF + Proxy/AV)

• 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

ISB-Punkt

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

Host-Integrität (FIM)

Was ist FIM

• 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

ISB-Punkt

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

Wo ist Verkehr überhaupt lesbar?

• 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

ISB-Punkt

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

Eskalation

• 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

ISB-Punkt

• 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"