Microsoft Sentinel als SIEM: Deployment, Detection Rules und KQL-Abfragen

Microsoft Sentinel ist für viele Microsoft-Kunden der natürlichste Einstieg ins SIEM - native M365-Integration, AAD-Logs ohne zusätzliche Connectoren, und Entra ID-Risikosignale direkt verfügbar. Die Herausforderung: ohne gute Detection-Rules, Alert-Tuning und Kostenkontrolle wird aus dem eleganten Cloud-SIEM schnell eine teure Alert-Flut. Dieser Guide zeigt den Weg zu einem funktionierenden Sentinel-SOC.

Sentinel-Architektur

Komponenten-Übersicht:

Log Analytics Workspace:
  → Datenbasis für Sentinel
  → Alle Daten landen im Workspace (KQL-Datenbank)
  → Retention: Standard 90 Tage, erweiterbar bis 2 Jahre
  → Multi-Workspace: Enterprise-Trennung (SIEM-Workspace ≠ App-Workspace)

Data Connectors (Datenquellen):
  → Microsoft-First-Party (kostenlos, sofort aktivierbar):
    - Microsoft Defender for Endpoint (MDE)
    - Microsoft Defender for Office 365 (MDO)
    - Microsoft Defender for Identity (MDI)
    - Entra ID (Sign-in + Audit Logs)
    - Microsoft 365 (Exchange, SharePoint, Teams)
    - Azure Activity + Azure AD
  → Drittanbieter (kostenpflichtig, aber umfangreich):
    - AWS CloudTrail (CEF/SYSLOG)
    - Cisco Firepower, Palo Alto, Fortinet
    - CrowdStrike Falcon, SentinelOne
    - Syslog/CEF (fast alle Geräte unterstützt)

Ingestion-Pipeline:
  Quelle → DCR (Data Collection Rule) → Log Analytics Workspace
  → DCR: Filtern vor Ingestion (Kosten sparen!)
  → Transformation: Felder umbenennen, berechnen

Microsoft Sentinel Free Tier:
  → Erste 5 GB/Tag: kostenlos für Sentinel
  → Log Analytics selbst: extra Kosten (ab 0,25€/GB)
  → Commitment Tiers: Rabatt bei > 100 GB/Tag

Pricing-Kalkulation (grob):
  100 Endpoints MDE:    ~5-10 GB/Tag
  500 Mailboxes MDO:    ~2-5 GB/Tag
  Azure-Ressourcen:     variabel
  Sentinel + LA:        ~€3-5 per GB (Ingestion)
  Typisches KMU (100 User): €500-1.500/Monat

Data Connectors konfigurieren

Schritt 1 - Microsoft 365 Defender Connector:

  Sentinel → Data Connectors → Microsoft 365 Defender → Connect

  Aktivierte Tabellen:
  DeviceEvents, DeviceFileEvents, DeviceNetworkEvents
  DeviceProcessEvents, DeviceRegistryEvents, DeviceLogonEvents
  EmailEvents, EmailUrlInfo, EmailAttachmentInfo
  IdentityInfo, IdentityLogonEvents
  AlertEvidence, SecurityAlert, SecurityIncident

  Wichtig: Connector aktiviert alle MDE/MDO/MDI-Tabellen gleichzeitig!
  → Prüfen was wirklich gebraucht wird (Kostenkontrolle!)

Schritt 2 - Entra ID (Azure AD):

  Sentinel → Data Connectors → Azure Active Directory → Connect
  Aktivieren:
  ✓ Sign-in Logs       (jeder Login)
  ✓ Audit Logs         (Konfigurationsänderungen)
  ✓ Provisioning Logs  (User-Erstellung, SCIM)
  ✗ Non-interactive Logins  (sehr voluminös, oft nicht nötig!)

Schritt 3 - Syslog / CEF für Netzwerkgeräte:

  # Syslog-Forwarder (Linux VM) konfigurieren:
  # Agent auf Forwarder-VM installieren:
  wget -O install.sh https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh
  sudo bash install.sh -w WORKSPACE_ID -s PRIMARY_KEY

  # rsyslog konfigurieren (/etc/rsyslog.conf):
  *.* @127.0.0.1:514  # Lokal an OMS-Agent

  # Firewall-Syslog an Forwarder senden (Cisco IOS):
  logging host <FORWARDER_IP>

Kostenkontrolle - DCR Transformation:

  # Transformation: nur Security-relevante Events behalten
  # Vor DCR (teuer): alle Events ingesten
  # Nach DCR (günstiger): Events filtern

  # DCR Transformation (KQL-artig):
  source
  | where EventID in (4624, 4625, 4648, 4720, 4728, 4732, 4756)
  # Nur sicherheitsrelevante Security Event-IDs behalten!
  # → Spart 70-80% der SecurityEvent-Kosten!

Detection Rules (Analytics Rules)

Regeltypen in Sentinel:

Scheduled Analytics Rule (häufigste):
  → KQL-Query läuft periodisch (5min bis 24h)
  → Ergebnis → Alert + Incident erstellen
  → Empfehlung: alle eigenen Detection-Rules als Scheduled

Near-Real-Time (NRT) Rule:
  → Läuft sekündlich (maximale Reaktionsgeschwindigkeit)
  → Nur für kritische Alerts (Performance-Impact!)
  → Beispiel: Mass-Login-Failures → sofortiger Alert

Microsoft Security Rule:
  → Weiterleitung von Alerts aus anderen Defender-Produkten
  → M365 Defender, MDE, MDO, MDI → Sentinel-Incident

Fusion Rule:
  → ML-basierte Korrelation: mehrere Low-Fidelity Signals → High-Severity Alert
  → Beispiel: Unusual Login + Malware + Data Exfiltration = APT-Alert

---

Eigene Detection Rule erstellen:

  # Beispiel: Verdächtiger PowerShell-Encoded-Command
  # Sentinel → Analytics → Create → Scheduled

  # KQL Query:
  DeviceProcessEvents
  | where FileName in~ ("powershell.exe", "pwsh.exe")
  | where ProcessCommandLine has_any ("-EncodedCommand", "-enc ", "IEX", "Invoke-Expression")
  | where ProcessCommandLine !contains "ACCEPTABLE_PATTERN"  // Allowlist!
  | project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName

  # Alert Enrichment:
  Entities: DeviceName (Device), AccountName (Account)
  Alert-Name: "Suspicious PowerShell Encoded Command - {{DeviceName}}"

  # MITRE ATT&CK Mapping:
  Tactics: Execution
  Techniques: T1059.001 (Command and Scripting Interpreter: PowerShell)

  # Scheduling:
  Query Period: Last 5 minutes
  Run Query Every: 5 minutes

  # Alert Threshold:
  Number of events > 0 → Alert

---

Wichtige mitgelieferte Sentinel-Rules (Templates):

  SIEM Detections → Browse Templates:

  Identity:
  → "Brute force attack against Azure Portal" (A07)
  → "Sign-ins from IPs that attempt sign-ins to disabled accounts"
  → "New admin account activity"

  Lateral Movement:
  → "Lateral movement via WMI remote code execution"
  → "Suspicious Task Execution via Process" (Scheduled Tasks)

  Persistence:
  → "Registry persistence via Run keys"
  → "Malware in the recycle bin"

  Exfiltration:
  → "Mass download from SharePoint"
  → "User bulk deletion"

  Cloud:
  → "Azure resource deletion"
  → "New or altered federation domain"
  → "Service Principal assigned to privileged role"

KQL-Abfragen für SOC-Analysten

Essentielle KQL-Abfragen:

1. Failed Login Attempts (Brute Force):
   SecurityEvent
   | where EventID == 4625  // Failed Login
   | where TimeGenerated > ago(1h)
   | summarize FailedCount = count() by Account, IpAddress, Computer
   | where FailedCount > 10
   | order by FailedCount desc

2. Unusual Logon Times (After Hours):
   SigninLogs
   | where TimeGenerated > ago(7d)
   | extend Hour = datetime_part("hour", TimeGenerated)
   | where Hour < 6 or Hour > 20  // Außerhalb 06:00-20:00
   | where ResultType == 0  // Erfolgreich!
   | project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName
   | where UserPrincipalName !contains "serviceaccount"

3. Impossible Travel Detection:
   SigninLogs
   | where ResultType == 0
   | project TimeGenerated, UserPrincipalName, IPAddress, Location
   | order by UserPrincipalName, TimeGenerated asc
   | extend PrevLocation = prev(Location, 1),
            PrevTime = prev(TimeGenerated, 1),
            PrevUser = prev(UserPrincipalName, 1)
   | where UserPrincipalName == PrevUser
   | where Location != PrevLocation
   | extend TimeDiff = datetime_diff('minute', TimeGenerated, PrevTime)
   | where TimeDiff < 60  // Verschiedene Länder < 60 Minuten apart!

4. Mass File Deletion (Ransomware-Vorläufer):
   DeviceFileEvents
   | where ActionType == "FileDeleted"
   | where TimeGenerated > ago(15m)
   | summarize DeleteCount = count(), UniqueExtensions = dcount(FileName)
     by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName
   | where DeleteCount > 100  // > 100 Dateien in 15 Minuten!

5. LSASS Memory Access (Credential Dumping):
   DeviceProcessEvents
   | where ProcessCommandLine contains "lsass"
      or (FileName == "procdump.exe")
      or (InitiatingProcessFileName == "powershell.exe"
          and ProcessCommandLine contains "sekurlsa")
   | project DeviceName, AccountName, FileName, ProcessCommandLine, Timestamp

6. Newly Created Admin Account:
   SecurityEvent
   | where EventID == 4728  // User added to global group
       or EventID == 4732   // User added to local group
       or EventID == 4756   // User added to universal group
   | parse EventData with * '<Data Name="TargetUserName">' NewAdmin '</Data>' *
   | parse EventData with * '<Data Name="GroupName">' GroupName '</Data>' *
   | where GroupName contains "Admin" or GroupName contains "Admins"
   | project TimeGenerated, NewAdmin, GroupName, Account, Computer

7. Suspicious DNS Queries (Possible C2):
   DnsEvents
   | where TimeGenerated > ago(24h)
   | where Name has_any ("pastebin.com", "raw.githubusercontent.com")
      or Name matches regex @"[a-z0-9]{20,}\.com"  // Random-Subdomain-DGA
   | summarize count() by Name, ClientIP
   | where count_ > 10
   | order by count_ desc

8. Lateral Movement via SMB:
   DeviceNetworkEvents
   | where RemotePort == 445
   | where InitiatingProcessFileName !in~ ("System", "svchost.exe", "MsMpEng.exe")
   | summarize SMBConnections = count() by DeviceName, RemoteIP, InitiatingProcessFileName
   | where SMBConnections > 20  // Ungewöhnlich viele SMB-Verbindungen

Incident Management und Automation

Automation Rules (leichtgewichtig):

  # Auto-Close false Positives:
  Trigger: Incident created
  Conditions: Alert name contains "Known-FP-Pattern"
  Actions: Change status → Closed, Reason: False Positive

  # Ticket erstellen (ServiceNow):
  Trigger: Incident created, Severity = High
  Actions: Run Playbook "Create-ServiceNow-Ticket"

  # SOC-Analyst zuweisen:
  Trigger: Incident created, Tactics contains "Lateral Movement"
  Actions: Assign to specific analyst, Send Teams-Notification

Playbook (Logic App) - Endpunkt isolieren:

  Trigger: Sentinel Incident (Severity: Critical)
  1. Parse Alert Entities → finde DeviceName
  2. Condition: ist Endpunkt kritisch? (CMDB-Lookup via HTTP)
  3. Wenn ja: POST an MDE API
     POST https://api.securitycenter.microsoft.com/api/machines/{id}/isolate
     {"Comment": "Sentinel Auto-Isolation: Incident #{id}"}
  4. Teams-Nachricht: "Endpunkt {device} isoliert"
  5. ServiceNow-Ticket: mit Isolation-Details

---

Kostenkontrolle Best Practices:

  □ Data Connector: nur notwendige Tabellen aktivieren
    → Non-Interactive Logins, Entra Provisioning Logs: oft nicht nötig
  □ DCR Transformation: Filter vor Ingestion
    → SecurityEvent: nur relevante Event-IDs (spart 70-80%)
  □ Archive Tier: Daten älter 90 Tage ins günstigere Archive-Log
  □ Commitment Tier ab 100 GB/Tag: 15-60% Rabatt!
  □ Sentinel Cost Workbook: Azure Portal → Monitor → Workbooks
    → Zeigt Ingestion-Kosten pro Tabelle → findet Kostentreiber

  Monatliche Kostenüberwachung:
  Usage
  | where DataType != "Heartbeat"
  | where TimeGenerated > startofmonth(now())
  | summarize IngestedGB = sum(Quantity) / 1000 by DataType
  | order by IngestedGB desc
  | take 20
  // → Zeigt welche Datentypen am meisten kosten

Microsoft Sentinel ist für M365-Kunden oft die sinnvollste SIEM-Wahl - die nativen Integrationen reduzieren den Deployment-Aufwand erheblich. AWARE7 unterstützt bei Sentinel-Deployment, Detection-Rule-Entwicklung und SOC-Betrieb.

SIEM-Beratung anfragen | SOC als Service