SIEM und SOC Grundlagen für KMU

Warum SIEM und SOC auch für ein 80-Personen-KMU relevant sind

Die Fantasie vom SOC ist meistens ein abgedunkelter Raum mit zwölf Bildschirmen und Leuten in Kapuzenpullis. Die Realität in einem Schweizer KMU sieht anders aus: ein IT-Allrounder, der Firewall-Logs, Windows-Ereignisanzeigen, Microsoft-365-Sign-ins und vielleicht noch die VPN-Appliance im Blick behalten soll - nebenbei, zwischen Ticket-Bearbeitung und Drucker-Support. Genau da setzt die Kombination aus SIEM (Security Information and Event Management) und SOC (Security Operations Center) an: SIEM ist die Technologie, die Logs aus allen Quellen zentral sammelt, korreliert und Alarme generiert. SOC ist die organisatorische Funktion (intern oder extern), die diese Alarme rund um die Uhr auswertet und reagiert.

Der Unterschied ist entscheidend, weil viele KMU beides verwechseln: Ein SIEM ohne SOC-Betrieb ist wie eine Alarmanlage ohne Sicherheitsdienst - sie klingelt, aber niemand hört zu, ausser der eine Admin, der gerade im Ferien ist. Studien zeigen, dass die durchschnittliche Zeit bis zur Erkennung eines Angriffs ohne SOC-Unterstützung bei rund 197 Tagen liegt, mit einem gut betriebenen SOC sinkt sie auf unter 24 Stunden. Für ein KMU mit Kundendaten, ERP-System und Produktionsanbindung ist das der Unterschied zwischen einem abgewehrten Vorfall und einer Titelgeschichte in der Regionalzeitung.

Architektur: Von der Logquelle zum Alarm

Bevor wir zu Microsoft Sentinel als konkretem Produkt kommen, lohnt sich der Blick auf die generische SIEM-Pipeline, weil sie bei jedem Hersteller (Sentinel, Splunk, Wazuh, Elastic Security) im Kern gleich aussieht:

1. Log-Quellen - Firewalls, Windows-Server (Security-Event-Log), Entra ID Sign-ins, M365-Audit-Log, Linux-Syslog, Netzwerkgeräte, Cloud-Ressourcen.
2. Sammlung/Transport - Agenten (Azure Monitor Agent, Syslog-Forwarder), native API-Connectors, Log-Forwarder wie Logstash oder rsyslog.
3. Normalisierung - Rohdaten werden in ein einheitliches Schema gebracht (bei Sentinel z. B. Advanced Security Information Model, kurz ASIM), damit eine Regel unabhängig vom Hersteller-Rohformat funktioniert.
4. Speicherung - meist eine Log-Analytics-artige Datenbank mit Retention-Policy und Kostenstruktur pro GB.
5. Korrelation/Detection - Regeln (Analytics Rules), maschinelles Lernen, Threat-Intelligence-Abgleich.
6. Alarmierung/Incident-Management - aus mehreren Alerts wird ein Incident gebildet, das SOC übernimmt Triage und Response.
7. Automatisierung/Response - SOAR-Playbooks (z. B. Azure Logic Apps), die automatisch ein Konto sperren oder ein IP-Adressen-Ban auslösen.

Microsoft Sentinel: Cloud-natives SIEM auf Log Analytics

Microsoft Sentinel (früher Azure Sentinel) ist Microsofts SIEM- und SOAR-Lösung und läuft technisch auf einem Log-Analytics-Workspace in Azure. Es gibt keine eigene Sentinel-Datenbank - Sentinel ist im Grunde eine Sicherheitsschicht (Analytics Rules, Incidents, Workbooks, Playbooks, Threat Intelligence) oben auf einem ganz normalen Log-Analytics-Workspace, wie ihn auch das allgemeine Azure Monitoring nutzt.

Das hat zwei praktische Konsequenzen für ein KMU:

• Ihr könnt Sentinel auf einem bestehenden Log-Analytics-Workspace aktivieren, den ihr vielleicht schon für Azure-Monitoring nutzt - spart eine Migration.
• Die Kosten sind nicht “Sentinel-Lizenz plus Infrastruktur”, sondern reine Ingestion-Kosten pro Gigabyte plus ein Analyseaufschlag.

Datenspeicher-Tiers und Kosten

Seit 2024/2025 bietet Microsoft für Sentinel/Log Analytics drei Speicher-Tiers an, die für die Kostenkontrolle im KMU zentral sind:

Zusätzlich gibt es Commitment-Tiers (z. B. 100 GB/Tag für einen Fixpreis), die den Preis pro GB deutlich senken, sich für ein KMU mit wenigen GB/Tag aber selten lohnen. Die ersten 10 GB/Tag sind für 31 Tage im Trial kostenlos - gut, um eine erste Kostenschätzung zu machen, bevor man produktiv geht.

Data Connectors: Wie die Logs überhaupt reinkommen

Data Connectors sind die konfigurierbaren Bausteine, über die Sentinel Logquellen anbindet. Grob vier Kategorien:

• Native Azure/M365-Connectors - direkte API-Anbindung ohne Agent, z. B. “Microsoft Entra ID”, “Microsoft 365”, “Microsoft Defender XDR”, “Azure Activity”. Aktivierung meist mit wenigen Klicks und einer App-Registrierung mit den nötigen API-Permissions.
• Azure Monitor Agent (AMA) basierte Connectors - für Windows- und Linux-Server, auf denen ein Agent Security-Events, Sysmon-Daten oder Syslog sammelt und über Data Collection Rules (DCR) an den Workspace sendet. Das ist der Nachfolger des alten Log Analytics Agent (MMA), der 2024 das Ende des Supports erreicht hat.
• Syslog/CEF-Connectors - für Firewalls, Switches, NAS-Systeme: Ein Linux-Host mit AMA fungiert als Syslog-Collector und leitet CEF-formatierte (Common Event Format) Nachrichten weiter.
• Codeless Connector Platform (CCP) / Custom Logs - für Quellen ohne fertigen Connector, per REST-API oder benutzerdefinierten Log-Format-Definitionen.

Ein typisches Onboarding eines Syslog-Collectors sieht auf einem Ubuntu-Host so aus:

# Azure Monitor Agent auf dem Syslog-Collector installieren (via Azure Arc oder Extension)
sudo apt-get update
sudo apt-get install -y azuremonitoragent

# rsyslog so konfigurieren, dass die Firewall-Logs auf Port 514 UDP ankommen
sudo tee /etc/rsyslog.d/10-firewall.conf <<'EOF'
module(load="imudp")
input(type="imudp" port="514")
EOF

sudo systemctl restart rsyslog

Auf der Sentinel-Seite wird dazu eine Data Collection Rule (DCR) angelegt, die definiert, welche Facility/Severity-Kombination in welche Tabelle (z. B. CommonSecurityLog für CEF) geschrieben wird.

Damit eine Analytics Rule nicht für jeden Firewall-Hersteller neu geschrieben werden muss, bietet Sentinel das Advanced Security Information Model (ASIM). ASIM-Parser bilden herstellerspezifische Rohtabellen auf ein einheitliches Schema ab (z. B. _Im_NetworkSession), sodass eine Regel gegen “alle Netzwerk-Session-Quellen” funktioniert, egal ob Palo Alto, Fortinet oder Cisco.

Analytics Rules: Aus Logs werden Alarme

Analytics Rules sind das Herzstück der Erkennung. Sentinel kennt mehrere Regeltypen:

Beim Anlegen einer Scheduled Rule gibt der Assistent unter anderem vor:

• Query - die KQL-Abfrage, die die verdächtigen Ereignisse liefert.
• Entity Mapping - Zuordnung von Feldern (z. B. Account, IPAddress, Host) zu Sentinel-Entitätstypen, damit Incidents später automatisch verknüpft und angereichert werden können.
• Alert Grouping - ob mehrere Treffer zu einem Incident zusammengefasst werden.
• Results Simulation - eine Vorschau, wie viele Alarme die Regel in den letzten 50 Tagen ausgelöst hätte. Erzeugt sie mehr als 5-10 Alarme pro Tag für eine Regel, die eigentlich selten feuern sollte, ist die Schwelle oder die Ausschlusslogik zu grosszügig.

// Beispiel: mehrere fehlgeschlagene Anmeldungen gefolgt von Erfolg innerhalb kurzer Zeit
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != "0"
| summarize FailCount = count(), FailTimes = make_list(TimeGenerated) by UserPrincipalName, IPAddress
| where FailCount >= 5
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(1h)
    | where ResultType == "0"
    | project SuccessTime = TimeGenerated, UserPrincipalName, IPAddress
) on UserPrincipalName, IPAddress
| where SuccessTime > FailTimes[0]
| project UserPrincipalName, IPAddress, FailCount, SuccessTime

Diese Regel würde als Scheduled Rule alle 15 Minuten laufen und Brute-Force-mit-anschliessendem-Erfolg-Muster erkennen - ein klassisches Indiz für ein kompromittiertes Passwort.

KQL-Grundlagen: Die Sprache hinter jeder Regel

Kusto Query Language (KQL) ist eine pipe-basierte, schreibgeschützte Abfragesprache. Der Grundaufbau ist immer: Quelltabelle, dann eine Kette von Operatoren, getrennt durch |.

Die wichtigsten Operatoren für den Alltag:

// Grundgerüst: Tabelle, Zeitfilter, Feldfilter, Projektion
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625              // fehlgeschlagene Anmeldung
| project TimeGenerated, Account, Computer, IpAddress
| order by TimeGenerated desc

// summarize: Aggregation, z. B. Top-Quellen fehlgeschlagener Logins
SecurityEvent
| where EventID == 4625
| summarize FailedCount = count() by Account, bin(TimeGenerated, 1h)
| where FailedCount > 10
| render timechart

// Anreicherung über join: Prozessstart mit übergeordnetem Prozess korrelieren
DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand", "downloadstring")
| project TimeGenerated, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName

// let-Variablen für lesbare, wiederverwendbare Queries
let Schwellwert = 5;
let Zeitfenster = 1h;
SigninLogs
| where TimeGenerated > ago(Zeitfenster)
| where ResultType != "0"
| summarize Versuche = count() by UserPrincipalName, IPAddress
| where Versuche >= Schwellwert

Wichtige Operatoren im Überblick: where (Filter), project/project-away (Feldauswahl), summarize (Aggregation, oft mit bin() für Zeitfenster), join (Verknüpfung von Tabellen), extend (neue berechnete Spalten), parse (Text aus unstrukturierten Feldern extrahieren), render (Diagrammausgabe direkt im Portal).

Im Log-Analytics-Query-Editor kannst du eine markierte Query-Zeile mit Umschalt+Enter (Shift+Enter) sofort ausführen, ohne die ganze Abfrage laufen zu lassen. Praktisch beim schrittweisen Aufbau komplexer Pipelines mit mehreren join-Stufen.

Ein weiterer Praxistipp: Bevor eine neue Analytics Rule live geschaltet wird, immer zuerst die reine KQL-Query mit einem 14-Tage-Lookback im Logs-Blade laufen lassen und jede einzelne Zeile des Ergebnisses durchsehen. Viele “falsch positive” Regeln entstehen, weil ein Testadmin-Account oder ein Monitoring-Bot regelmässig Muster erzeugt, die wie ein Angriff aussehen.

SOC-Betriebsmodelle: Selbst betreiben, SOC-as-a-Service oder MDR?

Sentinel liefert die Technik - aber wer schaut sich die Incidents um 3 Uhr morgens an? Für die meisten Schweizer KMU sind drei Modelle realistisch:

1. In-house SOC - eigenes Team, 24/7-Bereitschaft, volle Kontrolle. Für ein mittelständisches Unternehmen liegen die Kosten für ein wirklich rund um die Uhr besetztes Team laut Branchenschätzungen zwischen CHF 1.8 Mio. und CHF 3.5 Mio. pro Jahr - für die allermeisten KMU illusorisch.
2. SOC-as-a-Service - ein externer Anbieter betreibt das SIEM (oft Sentinel oder Splunk) und die Überwachung, meldet Vorfälle aber primär, die Entscheidung über Massnahmen bleibt beim Kunden.
3. Managed Detection & Response (MDR) - geht einen Schritt weiter: Der Anbieter überwacht nicht nur, sondern greift bei einem bestätigten Vorfall aktiv ein (Host isolieren, Konto sperren), oft ohne vorherige Rückfrage, um Reaktionszeit zu minimieren.

Entscheidungshilfe: Welches Modell passt?

Start
  |
  v
Habt ihr eine eigene 24/7-Bereitschaft und Security-Spezialisten? 
  |-- Ja  --> In-house SOC (selten bei KMU sinnvoll, meist nur bei >1000 MA)
  |-- Nein
        v
  Reicht euch Alarmierung + eigene Reaktion tagsüber?
    |-- Ja  --> SOC-as-a-Service (Sentinel/Splunk extern betrieben, Alerts an euer Team)
    |-- Nein, wir brauchen auch nachts/am Wochenende aktive Reaktion
          v
        MDR (Anbieter greift eigenständig ein, SLA für Containment)

Bekannte Schweizer Anbieter für SOC-as-a-Service/MDR sind unter anderem Terreactive (Aarau, betreibt eigenes SOC-Team mit Splunk und Microsoft Sentinel), InfoGuard (Zug, CREST-zertifiziertes Cyber Defence Center) sowie diverse Managed-Service-Provider, die Microsoft-Sentinel-Betrieb als Zusatzservice anbieten. Bei der Auswahl lohnt sich ein Blick auf: CREST- oder ISO-27001-Zertifizierung, garantierte Reaktionszeiten (SLA), Datenstandort (Schweiz/EU wegen nDSG), und ob im Preis eine jährliche Tabletop-Übung inklusive ist.

Praxis-Szenario: Ein KMU führt Sentinel schrittweise ein

Ein typischer, realistischer Rollout-Plan für ein 120-Personen-KMU mit einem IT-Team von zwei bis drei Leuten:

1. Woche 1 - Log-Analytics-Workspace anlegen, Sentinel aktivieren, Trial-Kontingent (10 GB/Tag, 31 Tage) nutzen.
2. Woche 1-2 - Kern-Connectors: Entra ID, Microsoft 365, Azure Activity, Defender XDR. Alles native API-Connectors, kein Agent nötig.
3. Woche 2-3 - Domain Controller und wichtigste Server per Azure Monitor Agent anbinden, Data Collection Rule auf sicherheitsrelevante Event-IDs beschränken (nicht “alle Events”).
4. Woche 3-4 - Firewall via Syslog/CEF anbinden, ASIM-Parser prüfen.
5. Woche 4-5 - Erste 5-8 Analytics Rules aus dem Content Hub (vorgefertigte Regel-Templates von Microsoft) aktivieren, mit Results Simulation gegenprüfen.
6. Woche 5-6 - Eigene KQL-Regeln für unternehmensspezifische Muster (z. B. Zugriffe auf das ERP-System ausserhalb der Bürozeiten) bauen.
7. Laufend - Kosten-Workbook wöchentlich prüfen, Regeln nach False-Positive-Rate tunen, Entscheid SOC-Betrieb (intern light vs. SOC-as-a-Service) auf Basis der ersten 2-3 Monate Erfahrung treffen.

Der Sentinel Content Hub liefert für die meisten gängigen Datenquellen (Entra ID, Microsoft 365, gängige Firewalls) fertige Analytics-Rule-Vorlagen, Workbooks und Hunting-Queries als “Solutions”. Für den Einstieg deutlich effizienter, als jede Regel von Grund auf selbst in KQL zu schreiben - Anpassungen an die eigene Umgebung bleiben trotzdem nötig.

Fallstricke in der Praxis

• Alert Fatigue - zu viele, zu unspezifische Regeln führen dazu, dass echte Alarme im Rauschen untergehen. Lieber wenige, gut getunte Regeln als 50 Templates unverändert aktivieren.
• Fehlende Log-Retention-Strategie - Standard-Retention in Log Analytics ist 30 Tage (Analytics-Tier), konfigurierbar bis zu 2 Jahre; für forensische Nachvollziehbarkeit oder Compliance-Vorgaben (teils 1-3 Jahre) braucht es zusätzlich Long-Term-Retention oder Auxiliary Logs.
• Kein Ownership für Incident-Reaktion - ein SIEM ohne definierten Eskalationsprozess (wer wird wann per Telefon geweckt) erzeugt Alarme, die niemand abarbeitet.
• Data-Residency ignoriert - für nDSG-Konformität sollte der Log-Analytics-Workspace bewusst in einer Schweiz- oder zumindest EU-Azure-Region liegen, gerade bei Personendaten in den Logs (z. B. Benutzernamen, IP-Adressen).
• MDR-Vertrag ohne klare Eingriffsbefugnis - definiert der Vertrag nicht klar, welche Aktionen der Anbieter ohne Rückfrage ausführen darf (z. B. Konto sperren vs. ganzen Server vom Netz nehmen), gibt es im Ernstfall Reibung genau dann, wenn Zeit zählt.

Weiterlernen

• Microsoft Sentinel Dokumentation - offizielle Produktübersicht und Architektur
• Create scheduled analytics rules in Microsoft Sentinel - Schritt-für-Schritt-Anleitung für Analytics Rules
• KQL-Tutorial: Common tasks with KQL for Microsoft Sentinel - offizielles Kusto-Tutorial mit Sentinel-Bezug
• Microsoft Sentinel Pricing und Billing - offizielle Kostenübersicht und Tier-Erklärung
• Advanced Security Information Model (ASIM) - Normalisierung von Logquellen im Detail
• NCSC Schweiz - Meldepflicht für Cyberangriffe - offizielle Anlaufstelle für die 24-Stunden-Meldepflicht nach ISG

Videos

YouTube