Security Logging & Monitoring

SIEM steht für Security Information and Event Management – eine Technologiekategorie, die sicherheitsrelevante Log-Daten aus der gesamten IT-Infrastruktur zentral sammelt, normalisiert, korreliert und auswertet. Ein SIEM beantwortet die Frage: Was passiert gerade in meiner Umgebung – und deutet es auf einen Angriff hin? Es kombiniert zwei klassische Disziplinen: Security Information Management (SIM, Langzeitarchivierung und Compliance-Reporting) und Security Event Management (SEM, Echtzeit-Korrelation und Alerting).

Die Kernfunktionen eines SIEM sind Log-Aggregation (Daten aus Firewalls, Endpoints, Cloud, Active Directory, Anwendungen in einem zentralen System bündeln), Normalisierung (unterschiedliche Log-Formate in ein einheitliches Schema überführen), Event-Korrelation (Ereignisse aus verschiedenen Quellen und Zeiträumen verknüpfen, um komplexe Angriffsmuster zu erkennen), Alerting (Alarm bei verdächtigen Mustern) und Compliance-Reporting (revisionsichere Logarchivierung und Nachweisberichte für Auditoren).

SIEM unterscheidet sich von reinem Log Management: Log Management speichert Logs – SIEM analysiert sie aktiv. SIEM unterscheidet sich von SOAR (Security Orchestration, Automation and Response): SOAR reagiert automatisiert auf Alerts – SIEM erkennt sie. In der Praxis werden SIEM und SOAR häufig kombiniert: Das SIEM liefert den Alert, das SOAR automatisiert die Erstreaktion. Moderne Plattformen wie Microsoft Sentinel integrieren beide Funktionen in einem Produkt.

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.

In der Begleitung von ISO 27001-Audits und DORA-Prüfungen zeigt sich regelmäßig: Viele Organisationen können belegen, dass Logs vorhanden sind – nicht aber, dass sie systematisch ausgewertet werden. Auditoren und Wirtschaftsprüfer unterscheiden klar zwischen Logging als Compliance-Checkbox und nachweisbarer Erkennungsfähigkeit. Diese Unterscheidung ist prüfungsrelevant.

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 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.

SIEM ist kein optionales Add-on mehr – für regulierte Organisationen ist es ein Compliance-Muss. NIS2 Artikel 21 verlangt von wesentlichen und wichtigen Einrichtungen die Fähigkeit zur Angriffserkennung, Incident-Response und vollständigem Security Logging. Ohne zentrales SIEM sind weder die Erkennungs- noch die Nachweisfähigkeit gegenüber Aufsichtsbehörden gegeben. Die 24-Stunden-Meldefrist für erhebliche Sicherheitsvorfälle setzt voraus, dass Angriffe überhaupt erkannt werden – was ohne SIEM oft erst nach Wochen geschieht.

ISO 27001:2022 adressiert SIEM direkt in Annex A.8.15 (Logging) und A.8.16 (Monitoring): Logs sicherheitsrelevanter Ereignisse müssen erhoben, gespeichert und regelmäßig ausgewertet werden. Auditoren erwarten nicht nur, dass Logs existieren, sondern dass ein dokumentierter Prozess zeigt, wer wann welche Logs auswertet, nach welchen Regeln Alerts ausgelöst werden und wie auf Vorfälle reagiert wird. Ein SIEM liefert genau diese Audit-Evidenz. Aus der Begleitung von Zertifizierungsaudits wissen wir: Wirtschaftsprüfer prüfen nicht, ob ein SIEM vorhanden ist – sie prüfen, ob der Prozess dahinter funktioniert.

DORA (Digital Operational Resilience Act) verlangt von Finanzinstituten ein ICT-Risikomanagement mit Anomalie-Erkennungsfähigkeit und die technische Fähigkeit, sicherheitsrelevante Ereignisse im gesamten ICT-Stack zu protokollieren und zu analysieren. Für Finanzunternehmen unter BaFin-Aufsicht ist die nachweisbare Erkennungs- und Reaktionsfähigkeit damit keine freiwillige Maßnahme, sondern eine prüfungsrelevante Anforderung. Wir implementieren SIEM-Lösungen, die gleichzeitig NIS2-, ISO 27001- und DORA-Anforderungen erfüllen – mit einer konsolidierten Reporting-Struktur statt drei separater Compliance-Dokumente.