Log-Daten allein schaffen keine Sicherheit — erst die intelligente Auswertung durch Korrelationsregeln, UEBA und Threat Intelligence macht das SIEM zur Angriffserkennung. Dieser Artikel erklärt die Analysemethoden.
Was sind Korrelationsregeln im SIEM
Korrelationsregeln verbinden mehrere Ereignisse zu einem Alert. Beispiel: Regel 'Brute Force': WENN >5 fehlgeschlagene Logins von selber IP in 5 Minuten → Alert 'Möglicher Brute-Force-Angriff'. Regeln werden in SIEM-spezifischer Sprache (Splunk SPL, Microsoft Sentinel KQL, ElasticSearch EQL) geschrieben. Qualität der Regeln bestimmt True-Positive-Rate.
Was ist UEBA und wie funktioniert es
UEBA (User and Entity Behavior Analytics): Machine-Learning-basierte Anomalieerkennung. SIEM lernt 'normales' Verhalten von Nutzern und Systemen. Abweichungen werden als verdächtig markiert. Beispiel: Mitarbeiter lädt normalerweise 10 MB/Tag herunter, plötzlich 5 GB → Datenexfiltrations-Alert. UEBA ergänzt regelbasierte Erkennung für unbekannte Angriffsmuster.
Was ist Threat Intelligence im SIEM-Kontext
Threat Intelligence (TI) im SIEM: externe Feeds mit bekannten schädlichen IPs, Domains, Datei-Hashes (IOCs — Indicators of Compromise). SIEM prüft eingehende Log-Daten gegen TI-Feeds. Übereinstimmung = sofortiger Alert. Quellen: MISP, OpenCTI, kommerzielle Feeds (Recorded Future, CrowdStrike), BSI-Warnungen. TI macht reaktive Erkennung bekannter Bedrohungen effizienter.
Was ist ein Security Use Case und wie entwickelt man ihn
Use Case = Dokumentiertes Szenario das das SIEM erkennen soll. Struktur: Name, Bedrohungsscenario, Log-Quellen, Erkennungslogik, Schweregrad, Response-Prozess, KPIs (False-Positive-Rate, True-Positive-Rate). Entwicklung: Bedrohungsmodell → relevante Angriffstechniken (MITRE ATT&CK) → Use Cases ableiten → Regeln schreiben → testen. Kontinuierlich erweitern.
Wie reagiert man auf SIEM-Alerts
Alert-Response-Prozess: Tier-1-Analyst (SOC) bewertet Alert (echt oder False Positive?), bei echtem Vorfall: Triage und Eskalation an Tier-2, Tier-2 analysiert und leitet Incident Response ein, SOAR kann bestimmte Responses automatisieren (Account sperren, IP blocken), Dokumentation in Ticketing-System, Post-Incident-Review. Ohne definierten Prozess: Alerts werden ignoriert.
✓ Checkliste: Wie erfolgt die Auswertung im SIEM?
- Verantwortlichkeiten klar definiert
- Dokumentation vollständig und aktuell
- Risikoanalyse durchgeführt
- Maßnahmen priorisiert und umgesetzt
- Mitarbeiter geschult
- Regelmäßige Überprüfung geplant
- Management informiert und eingebunden
- Compliance-Anforderungen erfüllt
- Technische Maßnahmen implementiert
- Auditierbarkeit sichergestellt
Fazit
Wie erfolgt die Auswertung im SIEM? ist für Unternehmen jeder Größe relevant. Professionelle Umsetzung schützt vor Risiken, erfüllt regulatorische Anforderungen und schafft Vertrauen. APASEC begleitet Sie von der ersten Analyse bis zur nachhaltigen Implementierung.
APASEC unterstützt Sie — praxisnah und auf Ihr Unternehmen zugeschnitten. Jetzt unverbindlich anfragen →
Häufige Fragen (FAQ)
Korrelationsregeln verbinden mehrere Ereignisse zu einem Alert. Beispiel: Regel 'Brute Force': WENN >5 fehlgeschlagene Logins von selber IP in 5 Minuten → Alert 'Möglicher Brute-Force-Angriff'. Regeln werden in SIEM-spezifischer Sprache (Splunk SPL, Microsoft Sentinel KQL, ElasticSearch EQL) geschrieben. Qualität der Regeln bestimmt True-Positive-Rate.
UEBA (User and Entity Behavior Analytics): Machine-Learning-basierte Anomalieerkennung. SIEM lernt 'normales' Verhalten von Nutzern und Systemen. Abweichungen werden als verdächtig markiert. Beispiel: Mitarbeiter lädt normalerweise 10 MB/Tag herunter, plötzlich 5 GB → Datenexfiltrations-Alert. UEBA ergänzt regelbasierte Erkennung für unbekannte Angriffsmuster.
Threat Intelligence (TI) im SIEM: externe Feeds mit bekannten schädlichen IPs, Domains, Datei-Hashes (IOCs — Indicators of Compromise). SIEM prüft eingehende Log-Daten gegen TI-Feeds. Übereinstimmung = sofortiger Alert. Quellen: MISP, OpenCTI, kommerzielle Feeds (Recorded Future, CrowdStrike), BSI-Warnungen. TI macht reaktive Erkennung bekannter Bedrohungen effizienter.
Use Case = Dokumentiertes Szenario das das SIEM erkennen soll. Struktur: Name, Bedrohungsscenario, Log-Quellen, Erkennungslogik, Schweregrad, Response-Prozess, KPIs (False-Positive-Rate, True-Positive-Rate). Entwicklung: Bedrohungsmodell → relevante Angriffstechniken (MITRE ATT&CK) → Use Cases ableiten → Regeln schreiben → testen. Kontinuierlich erweitern.
Alert-Response-Prozess: Tier-1-Analyst (SOC) bewertet Alert (echt oder False Positive?), bei echtem Vorfall: Triage und Eskalation an Tier-2, Tier-2 analysiert und leitet Incident Response ein, SOAR kann bestimmte Responses automatisieren (Account sperren, IP blocken), Dokumentation in Ticketing-System, Post-Incident-Review. Ohne definierten Prozess: Alerts werden ignoriert.