SIEM für KMU: Wann lohnt es sich und wie fängt man an?

"Wir sind zu klein für ein SIEM" - diese Annahme ist gefährlich. Nicht weil jedes KMU ein Enterprise-SIEM mit 10 Analysten braucht, sondern weil das Fehlen jeglicher zentraler Protokollierung bedeutet: Angriffe werden im Durchschnitt erst nach 207 Tagen bemerkt. Dieser Guide zeigt pragmatische SIEM-Konzepte für KMU mit begrenzten Ressourcen.

Wann braucht ein KMU ein SIEM?

Sie brauchen jetzt ein SIEM wenn:

• Sie einer regulatorischen Anforderung unterliegen: NIS2, ISO 27001, DSGVO Art. 32
• Ihre Branche einem hohen Angriffsdruck ausgesetzt ist: Gesundheit, Finanz, Energie, Anwaltskanzleien
• Sie sensitive Kundendaten verarbeiten: Kreditkarten, Gesundheitsdaten, personenbezogene Daten
• Remote-Zugang Standard ist (VPN, RDP, Cloud-Apps)
• Ihre Cyber-Versicherung einen Logging-Nachweis erfordert
• Es bereits einen Vorfall ohne Erkennung gab

Sie kommen noch ohne SIEM aus wenn:

• Sie weniger als 20 Mitarbeiter haben und keine Remote-Zugriffe bestehen
• Sie keine sensitiven Kundendaten verarbeiten
• Kein regulatorischer Druck vorliegt

Mindestanforderung: Auch ohne SIEM sollten Windows-Eventlogs zumindest lokal aufbewahrt werden.

Was ein SIEM nicht ersetzt

Folgende Maßnahmen sind Pflicht und müssen vor der SIEM-Einführung bestehen:

• EDR/AV auf Endpoints
• Firewall mit aktivierten Logs
• MFA für alle Remote-Zugänge
• Backup-Strategie
• Patch-Management

Außerdem sollten als minimale Logging-Voraussetzungen vor dem SIEM-Einsatz aktiviert sein: Windows Security Event Log, Firewall Deny-Logs, E-Mail-Gateway Attachment-Logs sowie VPN/RDP Login-Logs.

SIEM-Optionen für KMU - Kosten-Nutzen

Option 1: Microsoft Sentinel (Cloud-SIEM, empfohlen für M365-Kunden)

Kosten:

• Pay-as-you-go: ca. 2 EUR/GB ingested (die ersten 10 GB/Tag sind kostenlos)
• Commitment-Tier: ab 100 GB/Tag günstiger
• Für ein 50-Mitarbeiter-Unternehmen: ca. 200-500 EUR/Monat

Stärken:

• Native M365/Azure-Integration ohne zusätzliches Setup für M365-Logs
• Über 200 vorgefertigte Data Connectors
• MITRE ATT&CK-Mapping eingebaut
• SOAR integriert (automatische Responses)
• KQL als mächtige Abfragesprache

Schwächen:

• Kosten steigen schnell bei großen Log-Volumina
• Lernkurve für KQL

Option 2: Elastic SIEM / Elastic Stack (Open Source + Cloud)

Kosten selbst-gehostet:

• Hardware/VPS: ab 200 EUR/Monat (4 vCPU, 16 GB RAM)
• Elastic Cloud managed: ab 80 EUR/Monat
• Elasticsearch Security Features in der Basic-Version: kostenlos

Stärken:

• Open Source ohne Lizenzkosten
• Sehr leistungsfähig für große Datenmengen
• Gute Kibana-Dashboards
• EQL (Event Query Language) für Sequenz-Erkennung

Schwächen:

• Hoher Setup-Aufwand (Elasticsearch + Logstash + Kibana + Beats)
• Administration erfordert spezifische Expertise

Option 3: Splunk (Enterprise, meist zu groß für echte KMU)

Kosten:

• Splunk Cloud: ab 2.000 EUR/Monat
• Splunk Enterprise: erhebliche Lizenzkosten
• Splunk Free: maximal 500 MB/Tag - ausreichend nur für sehr kleine Umgebungen

Stärken: Marktführer mit dem größten App-Ökosystem, sehr mächtige SPL-Abfragesprache.

Empfehlung: Nur für Unternehmen ab 500 Mitarbeitern oder mit dediziertem SOC.

Option 4: Graylog (Open Source, günstige Alternative)

Kosten:

• Graylog Open: kostenlos bis 2 GB/Tag ohne Lizenz
• Hardware: 2 vCPU und 8 GB RAM reichen für 10 GB/Tag
• Sehr günstige Enterprise-Lizenz

Stärken:

• Einfachste Installation unter den SIEM-Alternativen
• Pipeline-Verarbeitung und Alerting bereits integriert
• Active Directory Integration

Schwächen:

• Weniger Detection-Content "out-of-the-box"
• Kleinere Community als Elastic

Empfehlung nach Unternehmensgröße

Größe	Empfehlung
1-50 MA	Graylog oder Microsoft Sentinel (wenn M365 vorhanden)
50-200 MA	Microsoft Sentinel oder Elastic SIEM
200+ MA	Splunk oder Microsoft Sentinel mit MDR-Dienstleister

Wichtigste Log-Quellen für KMU

Priorität 1 - sofort einbinden

Windows Domain Controller (Event Logs):

Die wichtigsten Event IDs für den DC:

Event ID	Bedeutung
4624	Erfolgreicher Login
4625	Fehlgeschlagener Login (Brute Force!)
4768	Kerberos TGT Request
4769	Kerberos Service Ticket (Kerberoasting!)
4776	NTLM-Authentifizierung
4720	User Account erstellt
4728	User zu privilegierter Gruppe hinzugefügt
1102	Security Audit Log gelöscht (SOFORT ALARM!)
4688	Neuer Prozess erstellt (Process Creation)

Diese Ereignisse werden über Group Policy unter Computer Configuration → Windows Settings → Security Settings → Local Policies → Audit Policy aktiviert - alle Kategorien auf "Success and Failure" setzen.

Firewall / Edge-Router:

• Alle blockierten Verbindungen
• Ausgehende Verbindungen zu unbekannten IPs
• Portscans werden erkennbar durch viele Verbindungen von einer einzigen Quelle

Priorität 2 - innerhalb eines Monats

E-Mail-Gateway / Exchange:

• Angenommene und abgelehnte E-Mails
• Anhang-Blockierungen
• DMARC-Failures

VPN/Remote-Access:

• Login, Logout, Fehler
• Geografischer Ursprung (GeoIP): Login aus Russland bei einem Mitarbeiter, der in Deutschland ist?

Endpoint-AV/EDR:

• Malware-Erkennungen
• Quarantäne-Events

Priorität 3 - innerhalb von drei Monaten

Web-Proxy (wenn vorhanden):

• Alle HTTP/HTTPS-Requests intern → extern
• Besonders wertvoll für die C2-Erkennung

Active Directory:

• Alle Gruppenänderungen
• Password-Resets
• Admin-Logins

Kritische Server (Fileserver, SQL, Exchange):

• Zugriffslogs
• Login-Events
• Dienst-Starts und -Stops

Erste Detection-Regeln - Wo anfangen?

Die wichtigsten acht Regeln für den Start, formuliert für Microsoft Sentinel (KQL):

Regel 1 - Brute-Force erkennen: Event ID 4625, mehr als 10 fehlgeschlagene Logins desselben Accounts in den letzten 15 Minuten von einer IP-Adresse:

SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(15m)
| summarize FailureCount = count() by Account, Computer, IpAddress
| where FailureCount > 10
| extend Alert = "Brute Force: " + tostring(FailureCount) + " Failed Logins"

Regel 2 - Account gesperrt (Lockout): Event ID 4740 löst sofortigen Alert aus. Hintergrund: es kann ein legitimer User sein, der sein Passwort vergessen hat - oder ein Brute-Force-Angriff.

Regel 3 - Ungewöhnliche Admin-Gruppenänderung: Event ID 4728, User zu "Domain Admins" oder "Enterprise Admins" hinzugefügt, erfordert sofortigen Alert.

Regel 4 - Anmeldung außerhalb Geschäftszeiten: Event ID 4624 mit LogonType 10 (Remote Interactive / RDP) außerhalb 7-20 Uhr oder am Wochenende.

Regel 5 - Neue Scheduled Task (Persistenz): Event ID 4698 (Scheduled Task erstellt) in den letzten 24 Stunden, mit Ausgabe von Computer, User, Task-Name und Task-Inhalt.

Regel 6 - PowerShell Encoded Command: DeviceProcessEvents mit powershell.exe als auslösendem Prozess und -enc, -encoded oder hidden in der Kommandozeile - häufiges Merkmal von Malware und Exploit-Frameworks.

Regel 7 - Event Log gelöscht:

SecurityEvent
| where EventID == 1102
| extend Alert = "CRITICAL: Security Event Log was cleared!"

Event ID 1102 ist immer verdächtig und erfordert sofortigen Tier-1-Alarm.

Regel 8 - Login aus ungewöhnlichem Land: SigninLogs (Azure AD / Entra ID) mit erfolgreichem Login (ResultType == 0) aus einem Land außerhalb des erlaubten Bereichs (z.B. nur DE, AT, CH).

Alert-Management und SOAR

Alert Fatigue vermeiden

Das größte Problem im Alert-Betrieb: Zu viele Alarme führen dazu, dass Analysten sie ignorieren - und echte Alarme werden übersehen. Die Lösung ist Alert-Qualität vor Alert-Quantität.

Tier-1-Alarme (sofortiger Menscheneingriff):

• Security Log gelöscht (EventID 1102)
• Domain Admin hinzugefügt
• Ransomware-Erkennung (EDR)
• MFA-Bypass-Versuch

Tier-2-Alarme (Investigation innerhalb einer Stunde):

• Brute-Force mit mehr als 50 Versuchen
• Erfolgreicher Login aus ungewöhnlichem Land
• PowerShell Encoded Command
• Neue Persistenz-Methode erkannt

Tier-3-Alarme (tägliches Ticket-Review):

• Einzelne Failed-Logins
• Neuer USB-Stick erkannt
• Unbekannte Anwendung gestartet

SOAR - Automatisierung mit Microsoft Sentinel

Microsoft Sentinel enthält SOAR built-in über Logic Apps und Playbooks.

Beispiel-Playbook: Auto-Block bei Brute-Force

• Trigger: Mehr als 50 fehlgeschlagene Logins von einer IP innerhalb von 5 Minuten
• Action 1: IP in Azure Firewall Deny-List aufnehmen
• Action 2: Slack-Alert an SOC-Channel senden
• Action 3: Ticket in Jira erstellen
• Action 4: Bei False Positive - IP per Knopfdruck in Slack wieder freigeben

Der Analyst muss nicht selbst sperren, sondern nur bestätigen oder aufheben. Die Mean Time to Respond (MTTR) sinkt dadurch von Stunden auf Minuten.

SIEM-Betrieb für KMU ohne SOC

Realistisches Betriebsmodell für ein 50-Mitarbeiter-Unternehmen

Ein IT-Mitarbeiter (kein Vollzeit-Analyst) kann leisten:

• Tägliches Dashboard-Review: 20 Minuten
• Tier-1-Alarme: sofortige Reaktion (Bereitschaftstelefon erforderlich)
• Wöchentliche Threat-Hunt-Session: 2 Stunden
• Monatliche Regel-Überprüfung: 1 Stunde

Tools, die den Aufwand reduzieren:

• Microsoft Sentinel mit KI-basierter Anomalie-Erkennung
• SOAR-Playbooks für automatische Reaktion auf bekannte Muster
• Wöchentliche Summary Reports per E-Mail mit den Top-5-Findings

Managed Detection and Response (MDR) als Alternative

Wer kein eigenes Personal für den SIEM-Betrieb hat, kann diesen an einen MDR-Dienstleister auslagern. Das bedeutet 24/7 SOC ohne eigenes Personal, mit Kosten zwischen 2.000 und 8.000 EUR/Monat je nach Unternehmensgröße. MDR-Dienstleister verfügen über mehr Threat-Intelligence und Erfahrung - für KMU ohne IT-Security-Expertise ist dies oft die bessere Wahl.

Hybrid-Modell (empfohlen)

• SIEM selbst betreiben (Sentinel, kostengünstig)
• Tier-1- und Tier-2-Alarme an das MDR-Team übergeben
• Intern: Compliance-Reports, Threat Hunts, Rule-Tuning
• Kosten: 500-2.000 EUR/Monat (Sentinel + MDR)

Schritt-für-Schritt-Einführung

Monat 1 - Foundation:

• Microsoft Sentinel aktivieren (oder Graylog aufsetzen)
• Domain Controller: Security Logs einspeisen
• Firewall-Logs einspeisen
• 5 Basis-Alerting-Regeln konfigurieren (Brute-Force, Admin-Änderungen, Log-Clear)

Monat 2 - Erweitern:

• E-Mail-Gateway-Logs integrieren
• VPN-Logs integrieren
• EDR-Integration einrichten
• GeoIP-Alerts konfigurieren

Monat 3 - Optimieren:

• SOAR-Playbook für Brute-Force erstellen
• False-Positive-Tuning durchführen
• Dashboard für das tägliche Review aufbauen
• Incident-Response-Playbook dokumentieren

---

SIEM ist kein Selbstzweck - es ist die Grundlage um Angriffe zu erkennen. AWARE7 hilft KMU bei der pragmatischen SIEM-Implementierung und bietet Managed Detection and Response als Alternative zum Eigenbetrieb.

SIEM-Beratung anfragen | Security Operations Beratung