Security Logging & Monitoring

Die durchschnittliche Zeit zwischen der initialen Kompromittierung und der Entdeckung eines Angriffs liegt laut Mandiant M-Trends-Report bei mehreren Wochen bis Monaten. In dieser Zeit bewegen sich Angreifer durch das Netzwerk, eskalieren Privilegien, exfiltrieren Daten und etablieren Persistenz. Der eigentliche Ransomware-Angriff, der Aktivierung von Backdoors oder die Datenveröffentlichung ist oft der letzte Schritt eines langen Angriffsprozesses – der mit Security Monitoring hätte erkannt werden können.

Die Grundlage für Erkennung ist vollständiges, strukturiertes Logging. Ohne Logs keine Erkennung; ohne zentrale Aggregation keine Korrelation; ohne Korrelationsregeln kein Alert. Die meisten Unternehmen haben irgendeine Form von Logging – aber es ist dezentral, unvollständig, unterschiedlich formatiert und niemand schaut systematisch drauf. Dieses Logging ist keine Security-Ressource, sondern Daten-Friedhof.

Security Monitoring beginnt mit der Frage: Was sind die kritischsten Angriffe, die uns treffen könnten – und welche Logs würden diese Angriffe sichtbar machen? Diese Frage ist schwerer zu beantworten als die technische Implementierung eines SIEM. Wir beginnen mit dieser Frage und bauen das Monitoring von dort aus.

Ein SIEM (Security Information and Event Management) aggregiert Logs aus verschiedenen Quellen, normalisiert sie in ein einheitliches Format, korreliert Ereignisse über Quellen und Zeiten hinweg und generiert Alerts bei verdächtigen Mustern. Die Wahl der SIEM-Plattform hängt von Ihrer Infrastruktur, Ihrem Budget und Ihrem Betriebsmodell ab: Microsoft Sentinel für Azure-zentrierte Umgebungen, Splunk für leistungsstarkes Enterprise-Logging, Elastic Security als kosteneffiziente Open-Source-Alternative, QRadar für komplexe hybride Umgebungen.

Die kritischen Log-Quellen für eine Windows-zentrierte Unternehmensumgebung sind: Active Directory Ereignislogs (Security, System, Application), DNS-Queries, Netzwerk-Flow-Daten (NetFlow, sFlow), Firewall- und Proxy-Logs, VPN-Authentifizierungen, EDR-Telemetrie (Endpoint Detection & Response), Cloud-API-Logs (Azure Activity, AWS CloudTrail) und Applikations-Logs für kritische Businesssysteme. Jede dieser Quellen hat spezifische Herausforderungen: Volumen, Format, Signalrauschen, Normalisierung.

Wir dimensionieren SIEM-Architekturen realistisch: Was sind die tatsächlichen Log-Volumina? Welche Quellen liefern den höchsten Sicherheitswert? Wo lohnt Hot Storage (für schnelle Abfragen), wo reicht Cold Storage (für Compliance und Forensik)? Überdimensionierte SIEM-Deployments scheitern an Betriebskosten; unterdimensionierte verlieren wichtige Events. Wir finden die richtige Balance für Ihr Profil.

Detection Engineering ist die Disziplin, wirksame Erkennungsregeln zu entwickeln, die echte Angriffe identifizieren ohne Alarm-Müdigkeit durch False Positives zu erzeugen. Das MITRE ATT&CK Framework bietet die konzeptionelle Grundlage: Es katalogisiert bekannte Taktiken, Techniken und Prozeduren (TTPs) von Angreifern und ordnet sie phasenweise von Initial Access bis Impact ein. Für jede Technik – Kerberoasting, LSASS Credential Dumping, Scheduled Task Persistence, Data Staged for Exfiltration – gibt es typische Log-Signaturen, die erkannt werden können.

Wir entwickeln maßgeschneiderte Detection-Regeln auf Basis von MITRE ATT&CK, abgestimmt auf Ihre spezifische Infrastruktur und Bedrohungslage. Eine Regel, die in einer Organisation mit 5.000 Windows-Clients gut funktioniert, kann in einer anderen mit 50 Clients eine Flut von False Positives erzeugen. Wir kalibrieren Regeln gegen Ihre Umgebung, bevor sie in die Produktion gehen.

Zu jeder Alert-Regel entwickeln wir Playbooks: Was ist bei diesem Alert zu tun? Wie wird der Alert validiert? Welche weiteren Indikatoren sollen abgefragt werden? Wer wird wann informiert? Diese Playbooks können manuell ausgeführt oder in SOAR-Plattformen (Security Orchestration, Automation and Response) automatisiert werden, um die Reaktionszeit zu minimieren.