SIEM-Architektur — Referenz.

Ingestion-Layer

• Source-Tier-Priorisierung.
  • Tier 1, volle Retention (1 Jahr+): Identity (AD/Okta-Auth), Endpoint-EDR-Telemetry, Cloud-Control-Plane (CloudTrail, AzureActivityLog, GCP AuditLog), DNS, Firewall-Flow.
  • Tier 2, hot 30 Tage + Cold-Archive: Web-Proxy, Network-IDS, Application-Audit.
  • Tier 3, sampeln oder summieren: Debug-Level-App-Logs, NetFlow im Volumen, Syslog von Systemen ohne Security-Relevanz.
• Schema-on-Write vs Schema-on-Read.
  • Schema-on-Write (Splunk-classic, ES mit Mappings): schnellere Query, teurer Change, schwer evolvierbar.
  • Schema-on-Read (Splunk SPL, ES Runtime, Snowflake auf Raw): günstiger Ingest, langsamere Query, leichter evolvierbar.
  • Hybrid (meiste moderne): Raw landen + kritische Felder beim Ingest extrahieren; volles Schema bei Query verfügbar.
• Kosten-Hebel. Verbose-aber-nutzlose Felder beim Ingest droppen (chatty Windows-Event-Payloads). Per-Source-Filter (kein 4624 von Low-Value-Workstations in voller Lautstärke). Hot/Warm/Cold-Tiering — Query-Latenz proportional zu Kosten.

Normalisierung — wo SIEMs gelingen oder scheitern

• Canonical-Schema. ECS (Elastic Common Schema), OCSF (Open Cybersecurity Schema Framework) oder ein Vendor-CIM (Splunk Common Information Model). Eines wählen und erzwingen.
• Schlüssel-normalisierte Felder.
  • user.name + user.id + user.email — konsistent über Sources.
  • source.ip / destination.ip — Richtung zählt, beide Seiten korrekt setzen.
  • event.action + event.outcome — was passierte, war es erfolgreich.
  • host.name — gleicher Host heißt gleicher Hostname über Endpoints, Network-Logs, EDR.
  • process.executable + process.command_line + process.parent.executable — Process-Tree-Pivot.
• Anti-Pattern. Jede Source hat downstream eigene Feldnamen; jede Regel muss Conditions pro Source schreiben. Resultat: Regeln werden nicht geschrieben oder für eine Source und verrotten für den Rest.
• Enrichment zur Normalisierungszeit. User → Role/Group (aus IAM). IP → Asset (aus CMDB). Hostname → Owner-Team. Ohne diese muss jede Regel lookupen, und die meisten tun's nicht.

Detektions-Layer

• Rule-based (Sigma, native SPL/KQL). Höchste Präzision wenn aus realem Attack-Pattern geschrieben (MITRE ATT&CK-Technique). Sigma in SIEM-Native-Query konvertiert ermöglicht Portabilität.
• Statistische Baselines. Volume pro User pro Stunde, Byte-Count pro Host pro Tag. Fängt Commodity-Angriffe; hohe FP bei legitimen Changes.
• Behavioral / UEBA. Per-Entity-Baseline, Deviation als Score. Hunt-Input, keine Blocking-Decision.
• Sequence / Correlation. Event A dann Event B innerhalb Fenster. Am wertvollsten, am schwersten zu maintainen (State-Explosion im Maßstab). Sparsam für bekannte Kill-Chains.
• Threat-Intel-Match. IP/Domain/Hash-Watchlist. Hohe FP bei veralteten Listen; nach Konfidenz und Recency tieren.

Response-Loop

1. Alert. An SOAR / Ticket-System geroutet mit normalisierten Feldern + empfohlenem Playbook.
2. Triage. Analyst bestätigt TP / FP / Benign-aber-Unusual.
3. Playbook-Automation. Enrichment (User-Kontext, Asset-Kritikalität, verwandte Alerts), Containment-Optionen (User disabeln, Endpoint isolieren), Evidence-Collection automatisiert.
4. Decision. Analyst (oder Auto-Rule bei High-Confidence) führt Containment / Eskalation aus.
5. Feedback. Disposition zurück zu Detection-Autoren. FP-Rate pro Rule getrackt. Lautstarke Rules retired oder getuned, nicht verrotten gelassen.

Kostenanalyse

• Per-GB-Ingest vs Per-GB-Stored. Vendor-Modell bestimmt Optimierung. Splunk → Ingest cutten. Sumo / DataDog → Stored cutten. Sentinel → Table-Tier-Choice.
• Hot vs Cold. Hot-Daten kosten N× Cold. Searchable Cold-Tier akzeptabel für After-the-Fact-Investigation, nicht für Live-Detection.
• Long-Tail-Rule-Maintenance. Jede Detection hat Carrying-Cost (FP-Triage-Stunden + Rule-Update-Stunden pro Quartal). Detections retiren, deren Carrying-Cost ihren Wert übersteigt.