Inhaltsverzeichnis
- Überblick & Zielsetzung
- High-Level Architektur
- Log-Quellen & Collection
- Elasticsearch – SIEM Data Store
- Alert & Correlation Engine
- MITRE ATT&CK Mapping
- Threat Intelligence
- SOAR – Automatisierte Reaktion
- SOC Dashboard
- Portal-Integration
- SOC-KPIs & Reporting
- Forensik-Unterstützung
- Compliance & Datenschutz
1. Überblick & Zielsetzung
Das SIEM Add-on ist eine eigenständige Applikation, die auf demselben RKE2-Kubernetes-Cluster wie das Self-Help Service Portal betrieben wird. Es ersetzt Microsoft Sentinel (das bisherige Azure-basierte SIEM) vollständig durch eine On-Premises-Lösung auf Basis von Elasticsearch.
| Ziel | Beschreibung |
|---|---|
| Zentrale Log-Aggregation | Alle sicherheitsrelevanten Logs aus On-Premises- und Cloud-Quellen an einem Ort |
| Echtzeit-Erkennung | Anomalien, Bedrohungen und Policy-Verstöße in Echtzeit erkennen |
| Automatisierte Reaktion | SOAR-Fähigkeiten für automatische Eindämmung und Ticket-Erstellung |
| Compliance-Nachweis | Auditierbare Log-Aufbewahrung gemäß BaFin/BAIT und DSGVO |
| Portal-Integration | Bidirektionale Synchronisation mit dem Self-Help Portal (Tickets, Incidents) |
| Sentinel-Ablösung | Vollständiger Ersatz von Microsoft Sentinel ohne Funktionsverlust |
1.1 Architekturprinzipien
| Prinzip | Umsetzung |
|---|---|
| On-Premises First | Alle SIEM-Daten verbleiben im eigenen Rechenzentrum |
| Eigenständige Applikation | Unabhängig deploybar, eigener Namespace, eigene APIs |
| Portal-Integration via REST | Bidirektionale Anbindung über definierte REST-APIs |
| Shared Infrastructure | Nutzt denselben RKE2-Cluster und kann Elasticsearch mit dem Portal teilen |
| Open-Source-basiert | Kein Vendor-Lock-in, alle Kernkomponenten sind Open Source |
| DSGVO-konform | Pseudonymisierung, Zugriffskontrolle und Löschkonzept für personenbezogene Daten |
2. High-Level Architektur
SIEM Add-on Architektur
┌─── Log-Quellen ────────────────────────────────────────────────┐
│ │
│ Kubernetes On-Premises Cloud (M365) │
│ ────────── ────────── ──────────── │
│ • K8s Audit Logs • Active Directory • Exchange Logs │
│ • Pod Logs • Windows Event Logs • SharePoint │
│ • Ingress Logs • Firewall Logs • Entra ID Logs │
│ • Portal App Logs • DNS / DHCP Logs • Teams Audit │
│ • API Gateway Logs • Mail Gateway Logs │
│ • Vault Audit Logs • Endpoint Logs │
│ • CyberArk/PAM Logs │
└────────────────────────────┬────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────┐
│ FLUENT BIT (Log Collection Layer) │
│ DaemonSet (K8s) │ Syslog Receiver │ HTTP/REST Receiver │
│ Parser → Filter → Enrichment → Routing → Output │
└────────────────────────────┬───────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────┐
│ ELASTICSEARCH CLUSTER (SIEM Data Store) │
│ Hot Tier (30 Tage, SSD) │ Warm Tier (90 Tage, HDD) │
│ Cold Tier (1 Jahr, MinIO/S3 Snapshots) │
└────────────────────────────┬───────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────┐
│ ALERT & CORRELATION ENGINE (Node.js / Python) │
│ Sigma Rules │ Correlation Engine │ MITRE ATT&CK Mapper │
│ Threat Intel │ SOAR Engine │ Anomaly Detection (ML) │
└────────────────────────────┬───────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────┐
│ SOC DASHBOARD (React / Next.js) │
│ Incident Mgmt │ Alert Dashboard │ Threat Hunting │ Forensik │
└────────────────────────────┬───────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────┐
│ PORTAL INTEGRATION (REST API, bidirektional) │
│ SIEM → Portal: Security-Tickets, Incident-Sync, Alerts │
│ Portal → SIEM: User-Events, Admin-Actions, AI-Audit-Logs │
└────────────────────────────────────────────────────────────────┘
2.1 Komponentenübersicht
| Komponente | Technologie | Zweck |
|---|---|---|
| Log Collector | Fluent Bit (DaemonSet) | Log-Sammlung von allen K8s-Nodes |
| Syslog Receiver | Fluent Bit (Deployment) | Empfang von Syslog-Daten (Non-K8s-Quellen) |
| Cloud Poller | Node.js Service | Graph API Polling für M365-Logs |
| Data Store | Elasticsearch 8 Cluster | Indizierung, Suche, Aggregation |
| Alert Engine | Node.js / Python | Sigma-Transpiler, Korrelation, Alerting |
| SOAR Engine | Node.js | Playbook-Ausführung, Auto-Containment |
| Threat Intel Service | Python | Feed-Integration, IoC-Management |
| SOC Dashboard | React (Next.js) | Visualisierung, Incident Management |
| Forensic Service | Node.js / Python | Evidence Collection, Investigation |
| API Gateway | Kong / Traefik (shared) | REST-API-Exposition für Portal-Integration |
2.2 Kubernetes Deployment
Namespace: hafs-siem
Alle SIEM-Komponenten laufen im eigenen Kubernetes-Namespace. Geschätzter Ressourcenbedarf: 12–16 vCPU, 48–64 GB RAM, 2 TB SSD (Hot) + 5 TB HDD (Warm) + MinIO (Cold).
| Deployment-Typ | Services |
|---|---|
| DaemonSets | fluent-bit (alle Worker Nodes) |
| Deployments (HA) | siem-alert-engine (2R), siem-correlation-svc (2R), siem-soar-engine (2R), siem-dashboard (2R), siem-api (2R), siem-syslog-receiver (2R) |
| Deployments (Single) | siem-threat-intel-svc, siem-forensic-svc, siem-cloud-poller |
| StatefulSets | elasticsearch-siem-hot (3 Nodes, SSD), elasticsearch-siem-warm (2 Nodes, HDD) |
| CronJobs | sigma-rule-sync (stündlich), threat-intel-update (4h), ilm-rollover (täglich), cold-tier-snapshot (täglich), compliance-report (wöchentlich) |
3. Log-Quellen & Collection
Das SIEM erfasst alle sicherheitsrelevanten Log-Quellen aus Kubernetes, On-Premises-Infrastruktur und der Microsoft 365 Cloud.
| Log-Quelle | Protokoll / Methode | EPS | Priorität |
|---|---|---|---|
| Kubernetes Audit Logs | Fluent Bit DaemonSet (Datei) | ~50 | Hoch |
| Portal Application Logs | Fluent Bit DaemonSet (stdout) | ~100 | Hoch |
| Active Directory | Syslog (WinLogBeat → Fluent Bit) | ~150 | Kritisch |
| Firewall Logs | Syslog (UDP/TCP 514) | ~500 | Kritisch |
| Windows Event Logs | Syslog (WinLogBeat → Fluent Bit) | ~300 | Hoch |
| DNS Logs | Syslog (UDP/TCP 514) | ~400 | Mittel |
| Network Flow Logs | NetFlow/sFlow → Fluent Bit | ~1000 | Mittel |
| CyberArk/PAM Logs | Syslog (CEF-Format) | ~30 | Kritisch |
| HashiCorp Vault Audit | Fluent Bit DaemonSet (Datei) | ~20 | Kritisch |
| M365 / Entra ID Logs | Graph API Polling (5 Min) | ~50 | Hoch |
| Exchange Online Logs | Graph API Polling (5 Min) | ~80 | Hoch |
~3.200
Events pro Sekunde (gesamt)
~15 GB
Log-Volumen pro Tag
14+
Log-Quellen integriert
3.1 Fluent Bit Pipeline
Fluent Bit Log Collection Pipeline
┌─── Input Plugins ──────────────────────────────────────────┐
│ [tail] → /var/log/containers/*.log (K8s Pods) │
│ [systemd] → journald (Node-Level Logs) │
│ [syslog] → TCP/UDP 514 (Firewall, AD, DNS, DHCP) │
│ [syslog] → TCP 6514 TLS (Mail Gateway, Endpoints) │
│ [http] → HTTP 8888 (Webhooks, Custom Sources) │
└─────────────────────────────┬──────────────────────────────┘
▼
┌─── Processing Pipeline ────────────────────────────────────┐
│ Parser: JSON, Syslog RFC 5424, CEF, Regex (Legacy) │
│ Filter: K8s-Metadata, ECS-Normalisierung, Noise- │
│ Reduction, PII-Pseudonymisierung, Throttle │
│ Enrichment: GeoIP, Asset-Lookup, Threat-Intel-Lookup │
└─────────────────────────────┬──────────────────────────────┘
▼
┌─── Output ─────────────────────────────────────────────────┐
│ [es] → Elasticsearch (siem-logs-YYYY.MM.DD) │
│ [nats] → NATS / RabbitMQ (Echtzeit-Alerts-Pipeline) │
│ [file] → /backup/ (Fallback bei ES-Ausfall) │
└─────────────────────────────────────────────────────────────┘
3.2 Daten-Normalisierung (Elastic Common Schema)
Alle Logs werden auf das Elastic Common Schema (ECS) normalisiert, um einheitliche Korrelation und Suche zu ermöglichen.
| ECS-Feld | Beschreibung | Beispiel |
|---|---|---|
@timestamp | Zeitstempel des Events | 2026-02-10T14:30:00.000Z |
event.category | Event-Kategorie | authentication, network, process |
event.action | Durchgeführte Aktion | user-login-success, firewall-deny |
event.severity | Schweregrad (0–100) | 75 |
source.ip | Quell-IP-Adresse | 10.20.1.15 |
user.name | Benutzername | m.mueller |
mitre.tactic | MITRE ATT&CK Taktik | initial-access |
mitre.technique | MITRE ATT&CK Technik | T1078 (Valid Accounts) |
4. Elasticsearch – SIEM Data Store
4.1 Cluster-Konfiguration
| Parameter | Wert | Beschreibung |
|---|---|---|
| Cluster-Typ | Shared oder Dediziert | Kann den Portal-ES-Cluster mitnutzen oder eigenen betreiben |
| Hot Nodes | 3 Nodes, SSD | Aktuelle Daten (30 Tage), schnelle Suche |
| Warm Nodes | 2 Nodes, HDD | Ältere Daten (31–90 Tage), langsamere Suche |
| Cold Tier | MinIO Snapshots | Archiv (91 Tage–1 Jahr), Restore on Demand |
| Shard-Strategie | 1 Primary + 1 Replica | Balance zwischen Performance und Redundanz |
| Index-Pattern | siem-logs-YYYY.MM.DD | Tägliches Rollover für effizientes ILM |
4.2 Index Lifecycle Management (ILM)
Index Lifecycle Management
Hot Phase (0–30 Tage)
┌────────────────────────────────────────────────────────┐
│ SSD-backed Nodes, 1 Primary + 1 Replica Shard │
│ Rollover bei 50 GB oder 1 Tag, Force Merge │
│ Volle Suchgeschwindigkeit, Echtzeit-Indexierung │
└──────────────────────┬─────────────────────────────────┘
▼ Nach 30 Tagen
Warm Phase (31–90 Tage)
┌────────────────────────────────────────────────────────┐
│ HDD-backed Nodes, Shrink auf 1 Shard, Read-Only │
│ Langsamere Suche, aber vollständig querybar │
└──────────────────────┬─────────────────────────────────┘
▼ Nach 90 Tagen
Cold Phase (91 Tage–1 Jahr)
┌────────────────────────────────────────────────────────┐
│ Snapshot → MinIO (S3-kompatibel), Index entfernt │
│ Searchable Snapshot (optional), Restore on Demand │
└──────────────────────┬─────────────────────────────────┘
▼ Nach 1 Jahr
Delete Phase (> 1 Jahr, konfigurierbar)
┌────────────────────────────────────────────────────────┐
│ Löschung nach 1 Jahr (Standard) │
│ Ausnahme: BaFin/BAIT-relevante Logs → 5–10 Jahre │
│ Security-Incident-Logs → bis Case Closed │
└────────────────────────────────────────────────────────┘
4.3 Speicher-Kalkulation
| Tier | Dauer | Volumen/Tag | Gesamt |
|---|---|---|---|
| Hot | 30 Tage | ~15 GB/Tag | ~450 GB |
| Warm | 60 Tage | ~10 GB (komprimiert) | ~600 GB |
| Cold | 275 Tage | ~5 GB (komprimiert) | ~1,4 TB |
| Gesamt (1 Jahr) | 365 Tage | — | ~2,5 TB |
portal.hafs.de/siem/logs?index=security-*
source.ip: "10.0.0.*" AND event.action: "authentication_failure" AND @timestamp >= now-1h
▶ Suchen
Index: security-* ▾
Zeitraum: Letzte Stunde ▾
342 Treffer in 0.12s
11:42:03.221WARNauth_failure src=10.0.0.45 user=admin dst=DC01 method=NTLM reason="invalid_password"
11:41:58.103WARNauth_failure src=10.0.0.45 user=admin dst=DC01 method=NTLM reason="invalid_password"
11:41:52.887WARNauth_failure src=10.0.0.45 user=admin dst=DC02 method=NTLM reason="invalid_password"
11:41:47.445ERRORauth_failure src=10.0.0.45 user=svc_backup dst=DC01 method=Kerberos reason="account_locked"
11:41:42.201WARNauth_failure src=10.0.0.45 user=admin dst=DC01 method=NTLM reason="invalid_password"
11:41:38.112INFOauth_failure src=10.0.0.88 user=j.fischer dst=EX01 method=OAuth reason="token_expired"
★ AI-Analyse
Verdächtig: 47 fehlgeschlagene Anmeldeversuche von 10.0.0.45 innerhalb von 5 Minuten. Ziel: Domain Controller. Pattern deutet auf Brute-Force-Angriff hin (MITRE: T1110.001).
⚠ Incident erstellen
IP blockieren
SIEM Log-Suche mit KQL-Query, Echtzeit-Ergebnissen und AI-Anomalie-Erkennung
5. Alert & Correlation Engine
5.1 Sigma Rules Integration
Das SIEM Add-on unterstützt Sigma Rules als primäres Detection-Format. Ein Transpiler konvertiert Sigma-YAML-Regeln automatisch in Elasticsearch Query DSL.
Sigma Rules Pipeline
Sigma Rule (YAML)
│
▼
┌──────────────────┐
│ Sigma Transpiler │
│ (sigmac / pySigma)│
│ │
│ YAML → ES Query │
│ DSL │
└────────┬─────────┘
│
├──► Elasticsearch Watcher (Scheduled Query, 1–5 min)
├──► Elasticsearch Alerting Plugin
└──► Alert Engine (Custom, komplexe Korrelation)
Sigma-Quellen:
• SigmaHQ Community Rules (~3.000 Regeln)
• HAFS Custom Rules (~200+ eigene Regeln)
• CERT-Bund / BSI Advisories (konvertiert)
• Branchenspezifische Finance-Regeln
5.2 Sigma Rule Beispiel
# Impossible Travel Detection
title: Impossible Travel - Portal Access
id: hafs-custom-001
status: stable
description: |
Login von zwei verschiedenen Geo-Locations innerhalb
unmöglicher Reisezeit erkannt
author: HAFS Security Team
logsource:
category: authentication
product: portal
detection:
selection:
event.action: user-login-success
condition: selection
# Korrelation: 2 Logins desselben Users,
# Distanz > 500km, Zeitdifferenz < (Distanz / 900 km/h)
level: high
tags:
- attack.initial_access
- attack.t10785.3 Detection Rules – HAFS Custom
| Regel | Trigger | MITRE | Aktion |
|---|---|---|---|
| Impossible Travel | Login von 2 Geo-Locations in unmöglicher Reisezeit | T1078 | Security-Ticket (P2), MFA erzwingen |
| Mass Permission Request | > 10 Berechtigungsanfragen in 1h | T1098 | Security-Ticket (P2), Requests pausieren |
| Off-Hours Admin Activity | Admin-Aktion außerhalb Geschäftszeiten | T1078.002 | Security-Ticket (P3), Manager benachrichtigen |
| Portal AI Abuse | Prompt Injection, > 50 Anfragen/h, Jailbreak-Versuche | T1059 | Security-Ticket (P2), User-Sperre |
| Bulk Data Export | Export von > 1000 Datensätzen pro Session | T1567 | Security-Ticket (P3), DLP-Check |
| Brute Force Detection | > 5 fehlgeschlagene Logins in 5 Minuten | T1110 | Auto-Block (15 min), Security-Ticket (P2) |
| Lateral Movement | Auth an > 5 Systemen in 10 min | T1021 | Security-Ticket (P1), Account-Review |
| Privilege Escalation | Berechtigung erhöht ohne Access Request | T1078.002 | Security-Ticket (P1), Revert |
| DNS Tunneling | DNS-Queries > 100 Zeichen oder hohe Frequenz | T1071.004 | Security-Ticket (P2), DNS-Block |
| Unauthorized Certificate | Vault-Zertifikat außerhalb definierter Services | T1552.004 | Security-Ticket (P1), Zertifikat widerrufen |
5.4 Correlation Engine
Die Correlation Engine erkennt mehrstufige Angriffe durch Verknüpfung mehrerer Events:
| Korrelationsregel | Events | Zeitfenster | Severity |
|---|---|---|---|
| Account Compromise Chain | Failed Logins → Successful Login → Privilege Escalation | 30 min | Critical |
| Insider Threat Pattern | Off-Hours Login → Bulk Data Access → External Email | 2h | Critical |
| Malware Propagation | Endpoint Alert → Lateral Movement → Multi-Host Alerts | 1h | Critical |
| Data Exfiltration | Large Query → Data Export → External Transfer | 1h | Critical |
| Phishing Campaign | Multiple Users klicken gleichen Link → Credential Theft | 4h | High |
| Supply Chain Attack | New Binary Deployed → Unusual Network Connections | 24h | High |
portal.hafs.de/siem/alerts
| Severity | Alert | Source | MITRE | Count | Last Seen | Status |
|---|---|---|---|---|---|---|
| CRITICAL | Brute-Force Attack – DC01 | 10.0.0.45 | T1110.001 | 342 | vor 2 min | Open |
| CRITICAL | Lateral Movement Detected | 10.0.0.45 | T1021.002 | 12 | vor 5 min | Investigating |
| HIGH | Suspicious PowerShell Execution | WS-0142 | T1059.001 | 3 | vor 12 min | Triaged |
| HIGH | Unusual Outbound Traffic – Port 4444 | 10.0.1.22 | T1571 | 87 | vor 18 min | Open |
| MEDIUM | Failed Login – Service Account | svc_backup | T1078.002 | 5 | vor 23 min | Resolved |
SIEM Alert-Übersicht mit Severity-Stufen, MITRE ATT&CK-Mapping und Event-Counts
6. MITRE ATT&CK Mapping
MITRE ATT&CK Coverage Map
Initial Access Execution Persistence
T1078 Valid Accounts ██ T1059 Cmd&Script ██ T1098 Account Man. ██
T1133 External Svc ██ T1204 User Exec ██ T1136 Create Acct ██
T1566 Phishing ██ T1203 Exploitation █░ T1053 Sched Task █░
Privilege Escalation Defense Evasion Credential Access
T1078 Valid Accounts ██ T1070 Indicator Rm ██ T1110 Brute Force ██
T1068 Exploitation ██ T1036 Masquerading █░ T1003 OS Cred Dump █░
T1548 Abuse Elev. █░ T1562 Impair Def. ██ T1552 Unsec. Cred ██
Lateral Movement Collection Exfiltration
T1021 Remote Svc ██ T1530 Cloud Storage██ T1567 Exfil Web Svc██
T1213 Data from IS ██ T1071 App Layer ██
Legende: ██ Vollständig █░ Teilweise ░░ Geplant
Jeder erkannte Incident wird automatisch einer oder mehreren MITRE ATT&CK Taktiken und Techniken zugeordnet. Diese Zuordnung erscheint im SOC Dashboard und im Portal-Ticket.
| Feld im Incident | Beschreibung | Beispiel |
|---|---|---|
mitre.tactic | ATT&CK Taktik(en) | ["initial-access", "credential-access"] |
mitre.technique | ATT&CK Technik-ID(s) | ["T1078", "T1110"] |
mitre.sub_technique | Sub-Technik (falls zutreffend) | ["T1078.002"] |
mitre.confidence | Zuordnungs-Konfidenz | 0.85 |
portal.hafs.de/siem/mitre-heatmap
Enterprise ATT&CK v14 · Detections: 47/201 Techniken abgedeckt (23.4%)
Keine Daten
1–5
6–20
21–50
51–100
100+
| Taktik | Technik 1 | Technik 2 | Technik 3 | Technik 4 | Technik 5 |
|---|---|---|---|---|---|
| Initial Access | T1566 Phishing (142) | T1078 Valid Accts (38) | T1190 Exploit (4) | T1133 RDP | T1199 Trust |
| Execution | T1059 PowerShell (67) | T1204 User Exec (12) | T1047 WMI (3) | T1053 Task | T1569 Svc |
| Persistence | T1136 Acct Create (15) | T1053 Sched Task (2) | T1547 Boot | T1546 Event | T1556 Auth |
| Credential Access | T1110 Brute Force (347) | T1003 OS Cred (29) | T1558 Kerberos (8) | T1552 Unsec | T1539 Cookie |
| Lateral Movement | T1021 Remote Svc (42) | T1570 Lateral Tool (5) | T1550 Alt Auth | T1563 RDP | T1080 Shared |
| Exfiltration | T1048 Alt Proto (11) | T1567 Web Svc (2) | T1041 C2 | T1052 Phys | T1537 Cloud |
MITRE ATT&CK Heatmap: Farbcodierte Technik-Matrix mit Detection-Coverage und Event-Counts
7. Threat Intelligence
Threat Intelligence Integration
┌─── Externe Feeds ──────────────────────────────────────────┐
│ CERT-Bund (BSI) │ MISP (Open Source) │ Abuse.ch │
│ Advisories │ IoC-Sharing │ URLhaus, │
│ Warnmeldungen │ TI Platform │ MalwareBazaar │
└────────────────────────────┬────────────────────────────────┘
▼
┌─── Threat Intel Service (Python) ──────────────────────────┐
│ STIX/TAXII-Client (Feed-Ingestion) │
│ IoC-Normalisierung (IP, Domain, Hash, URL, Email) │
│ Deduplication & Scoring, Expiration Management (TTL) │
└────────────────────────────┬────────────────────────────────┘
▼
┌─── Interne Quellen ────────────────────────────────────────┐
│ Eigene IoCs aus HAFS-Incidents │
│ Blocklists aus Firewall-Analysen │
│ Branchenspezifische Finance-Sector-Feeds (FS-ISAC) │
└─────────────────────────────────────────────────────────────┘
Verwendung:
• Echtzeit-Matching in Fluent Bit Pipeline (bekannte Bad-IPs)
• Enrichment in Elasticsearch (threat.indicator.* Felder)
• Alert-Priorisierung (IoC-Match → höhere Severity)
• SOC Dashboard: Threat Intel Overlay auf Incidents
7.1 IoC-Typen
| IoC-Typ | Quelle | Aktualisierung | Nutzung |
|---|---|---|---|
| IP-Adressen | CERT-Bund, MISP, Abuse.ch | Alle 4h | Firewall-Enrichment, Alert-Korrelation |
| Domains | CERT-Bund, URLhaus | Alle 4h | DNS-Log-Matching, Proxy-Enrichment |
| File Hashes | MalwareBazaar, MISP | Alle 4h | Endpoint-Log-Matching |
| URLs | URLhaus, CERT-Bund | Alle 4h | Proxy-Log-Matching, Mail-Gateway |
| E-Mail-Adressen | MISP, Intern | Täglich | Phishing-Detection |
| CVE-Referenzen | CERT-Bund, NVD | Täglich | Vulnerability-Korrelation |
portal.hafs.de/siem/threat-intel
1.247
Active IoCs
3
Matches (24h)
⚠
12
Neue IoCs (24h)
AKTIVE IoC-MATCHES
| Typ | Indikator | Source | Threat | Confidence | Match |
|---|---|---|---|---|---|
| IP | 185.220.101.45 | AlienVault OTX | APT28 C2 Server | 95% | Outbound Traffic detected |
| Hash | a3f2b…e91d | MISP | Cobalt Strike Beacon | 98% | Found on WS-0142 |
| Domain | evil-update.net | AbuseIPDB | Phishing Infrastructure | 72% | DNS-Query blockiert |
Threat Intelligence Feed mit IoC-Matching, Confidence-Scores und aktiven Treffern
8. SOAR – Automatisierte Reaktion
Die SOAR Engine (Security Orchestration, Automation & Response) führt bei erkannten Alerts automatisch YAML-basierte Playbooks aus:
SOAR Engine – Playbook-Architektur
Alert/Incident
│
▼
┌──────────────────┐
│ Playbook Router │
│ Severity + Type │──► Playbook-Auswahl
└────────┬─────────┘
│
├──► Auto-Enrichment Playbook
│ GeoIP, User-Profil, Asset-Info, Threat-Intel,
│ Historische Incidents des Users
│
├──► Auto-Containment Playbook (bei Critical)
│ Account-Sperre, Session Termination,
│ Netzwerk-Isolation, DNS-Sinkhole
│
├──► Auto-Ticket Playbook
│ Security-Ticket im Portal erstellen,
│ Severity-Mapping, SLA-Timer starten
│
├──► Auto-Notification Playbook
│ Teams an SOC-Channel, E-Mail an Security-Officer,
│ PagerDuty (P1 außerhalb Geschäftszeiten)
│
└──► Investigation Playbook
Log-Aggregation, Timeline, Affected Assets,
IOC-Extraktion aus Incident
Konfiguration: YAML-basiert, Git-versioniert
Ausführung: Event-driven via NATS/RabbitMQ
Audit: Jede Playbook-Ausführung wird protokolliert
8.1 Playbook-Severity-Mapping
| SIEM Severity | Portal Priority | Auto-Actions | Reaktionszeit |
|---|---|---|---|
| Critical (90–100) | P1 | Auto-Containment + Auto-Ticket + PagerDuty | < 15 min |
| High (70–89) | P2 | Auto-Ticket + Teams-Alert + Auto-Enrichment | < 30 min |
| Medium (40–69) | P3 | Auto-Ticket + E-Mail-Notification | < 4h |
| Low (1–39) | P4 | Logging + wöchentlicher Summary-Report | Nächster Arbeitstag |
| Informational (0) | — | Nur Logging, kein Ticket | — |
portal.hafs.de/siem/incidents/SEC-2026-0042
Timeline
Evidence
Affected Assets
SOAR Actions
11:42
Brute-Force Alert: 342 auth failures
Source: 10.0.0.45 → DC01 · MITRE: T1110.001
11:44
SOAR: IP automatisch blockiert
Firewall-Regel erstellt · Playbook: Brute-Force-Response
11:45
Lateral Movement detected
SMB-Sessions von 10.0.0.45 zu 3 weiteren Hosts · T1021.002
11:47
AI-Korrelation: Cobalt Strike IoC
Hash-Match auf WS-0142 · TI-Source: MISP (98% Confidence)
11:50
SOAR: Host-Isolation ausgeführt
WS-0142 vom Netzwerk isoliert · EDR-Scan gestartet
11:42:03ALERT342x auth_failure from 10.0.0.45 in 300s (threshold: 10)
11:45:12ALERTSMB lateral movement: 10.0.0.45 → 10.0.0.88, .91, .103
11:47:01ALERTTI match: cobalt_strike_beacon hash=a3f2b...e91d on WS-0142
INCIDENT SUMMARY
🕑 Dauer: 18 min
💻 Assets: 4 betroffen
👤 Accounts: 2 kompromittiert
MITRE MAPPING
T1110.001
T1021.002
T1059.001
T1571
SOAR PLAYBOOK
✓
IP blockieren
Abgeschlossen 11:44
✓
Host isolieren
Abgeschlossen 11:50
3
EDR Full Scan
Läuft…
4
Forensik-Image
Wartend
Security Incident Workspace mit Timeline, Log-Evidence und SOAR-Playbook-Fortschritt
9. SOC Dashboard
Das SOC Dashboard ist eine React-basierte Webanwendung (Next.js), die denselben Tech-Stack wie das Hauptportal verwendet. Es kann als eigenständige Ansicht oder als integrierter Bereich im Portal aufgerufen werden.
SOC Dashboard – Übersicht
┌─── Übersicht ──────────────────────────────────────────────┐ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Open │ │ Critical │ │ EPS │ │ Security │ │ │ │ Incidents│ │ Alerts │ │ (Events/ │ │ Score │ │ │ │ 12 │ │ 3 │ │ Sekunde)│ │ 78/100 │ │ │ │ │ │ │ │ 3.247 │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ └─────────────────────────────────────────────────────────────┘ ┌─── Incident Management ────────────────────────────────────┐ │ │ │ ID │ Type │ Severity │ Status │ │ ───────────────┼───────────────────┼──────────┼────────── │ │ SEC-2026-0042 │ Anomalous Login │ Critical │ Investing. │ │ SEC-2026-0041 │ Brute Force │ High │ Contained │ │ SEC-2026-0040 │ Policy Violation │ Medium │ Open │ │ SEC-2026-0039 │ Bulk Export │ Medium │ Resolved │ └─────────────────────────────────────────────────────────────┘ ┌─── MITRE ATT&CK Heatmap ──────────────────────────────────┐ │ Tactic │ Hits (30d) │ Top Technique │ │ ──────────────────┼────────────┼─────────────────────── │ │ Initial Access │ 15 │ T1078 Valid Accounts │ │ Credential Access │ 22 │ T1110 Brute Force │ │ Execution │ 8 │ T1059 Command & Script │ │ Lateral Movement │ 3 │ T1021 Remote Services │ └─────────────────────────────────────────────────────────────┘ ┌─── Threat Intel ───────────────────────────────────────────┐ │ Aktive IoCs: 45.230 │ Matches (24h): 12 │ Feeds: 5 │ └─────────────────────────────────────────────────────────────┘
9.1 Security Incident Workspace
Für jeden Incident bietet das Dashboard einen dedizierten Workspace mit folgenden Bereichen:
- Incident Details: ID, Typ, Severity, Status, MITRE-Mapping, zugewiesener Analyst, verknüpftes Portal-Ticket
- AI Enrichment: User-Profil, Geo-Location-Anomalie, Risk Score, Threat-Intel-Matches, ähnliche Incidents, AI-Empfehlung
- SOAR Actions: Ausgeführte automatische Aktionen + manuelle Action-Buttons (Account sperren, MFA Reset, Forensik starten, Eskalieren)
- Timeline: Chronologische Darstellung aller Events rund um den Incident
- Related Logs: Elasticsearch-Query-Interface mit direktem Zugriff auf relevante Logs
portal.hafs.de/siem/dashboard
12.4K
EPS (Events/sec)
Normal
2
Critical Alerts
+2 heute
5
High Alerts
78
Security Score
AKTIVE INCIDENTS
CRIT Lateral Movement
vor 18 min
CRIT Brute-Force DC01
vor 22 min
HIGH Suspicious PowerShell
vor 1h
TOP ALERT SOURCES (24H)
SOC Dashboard mit Echtzeit-EPS, Security Score, aktiven Incidents und Alert-Verteilung
10. Portal-Integration
Die Integration zwischen SIEM Add-on und Self-Help Portal erfolgt über bidirektionale REST-APIs und asynchrone Event-Kommunikation via NATS/RabbitMQ.
10.1 SIEM → Portal (Outbound)
| API-Endpunkt | Funktion |
|---|---|
POST /api/v1/tickets | Security-Ticket erstellen bei Alert/Incident |
PUT /api/v1/tickets/{id}/status | Ticket-Status synchronisieren (Contained, Resolved) |
POST /api/v1/tickets/{id}/comments | Enrichment-Daten als Ticket-Kommentar anfügen |
POST /api/v1/notifications | Sicherheitsbenachrichtigungen an User/Teams senden |
POST /api/v1/security/incidents | Incident-Objekt mit MITRE-Mapping im Portal anlegen |
10.2 Portal → SIEM (Inbound)
| API-Endpunkt | Funktion |
|---|---|
POST /api/v1/siem/events | Portal-Events an SIEM senden (Login, Admin-Action) |
GET /api/v1/siem/incidents/{id} | Incident-Details aus SIEM abrufen |
GET /api/v1/siem/alerts?severity=critical | Aktive Alerts für Security-Dashboard im Portal |
POST /api/v1/siem/search | Log-Suche aus dem Portal heraus (eingeschränkt) |
GET /api/v1/siem/kpis | SOC-KPIs für das Portal-Dashboard |
10.3 Event-Mapping SIEM → Portal
| Event im SIEM | Automatische Portal-Aktion |
|---|---|
| Critical Alert | Security-Ticket (P1) erstellen, On-Call benachrichtigen |
| Anomale Login-Aktivität | Security-Ticket (P2), Account-Review triggern |
| Malware Detection | Security-Ticket (P1), Isolierung empfehlen |
| Brute Force Attempt | Auto-Block + Security-Ticket (P2) |
| Data Exfiltration Alert | Security-Ticket (P1), DLP-Team + CISO benachrichtigen |
| Phishing Campaign Detected | Mass-Notification, KB-Artikel aktualisieren |
11. SOC-KPIs & Reporting
< 15 min
MTTD (Mean Time to Detect)
< 30 min
MTTR (Mean Time to Respond)
< 2h
MTTC (Mean Time to Contain)
> 70%
MITRE ATT&CK Coverage
11.1 KPI-Übersicht
| KPI | Beschreibung | Ziel |
|---|---|---|
| MTTD | Durchschnittliche Zeit von Angriffsbeginn bis Erkennung | < 15 min |
| MTTR | Durchschnittliche Zeit bis zur ersten Reaktion | < 30 min |
| MTTC | Durchschnittliche Zeit bis zur Eindämmung | < 2h |
| MTTRE | Durchschnittliche Zeit bis zur vollständigen Behebung | < 24h |
| False Positive Rate | Anteil der Fehlalarme an allen Alerts | < 20% |
| Auto-Resolution Rate | Anteil der automatisch gelösten Incidents | > 30% |
| Coverage Score | MITRE ATT&CK Abdeckungsgrad | > 70% |
| Log Ingestion Rate | Events pro Sekunde (EPS) | > 3.000 |
| Rule Effectiveness | Anteil der Regeln mit mindestens 1 True Positive | > 60% |
11.2 Compliance-Reporting
| Report | Frequenz | Empfänger | Inhalt |
|---|---|---|---|
| SOC Daily Summary | Täglich | SOC-Team | Alerts, Incidents, offene Tickets |
| Security Weekly Report | Wöchentlich | CISO, IT-Leitung | KPIs, Trends, Top-Threats |
| BAIT Compliance Report | Monatlich | Compliance, BaFin | Log-Retention-Nachweis, Incident-Statistik |
| ISMS Audit Report | Quartalsweise | ISMS-Beauftragter | Control-Effectiveness, Incident-Response-Metriken |
| Management Security Report | Monatlich | Geschäftsführung | Executive Summary, Risk Posture, Top-5-Risiken |
12. Forensik-Unterstützung
12.1 Evidence Collection
Automatische Beweissicherung
Bei Incident-Erstellung werden automatisch alle relevanten Logs sichergestellt: User-Logs (24h vor/nach Alert), System-Logs, Network Flows, DNS-Queries, Auth-Events und ein Elasticsearch-Index-Snapshot. Speicherung in dediziertem MinIO-Bucket mit SHA-256 Hash-Integrität.
12.2 Chain of Custody
Jeder Zugriff auf forensische Daten wird lückenlos protokolliert:
- Wer hat zugegriffen (User, Rolle)
- Wann (Timestamp, Timezone)
- Was wurde eingesehen / exportiert
- Warum (Incident-Referenz, Begründung)
- Hash-Verifikation bei jedem Zugriff
Format: Append-Only Log in PostgreSQL (Audit-Tabelle), unveränderlich mit Hash-Chain (Blockchain-ähnlich).
12.3 Forensik-Prozess
| Phase | Beschreibung | Tooling |
|---|---|---|
| Identification | Incident wird als forensisch relevant klassifiziert | SOC Dashboard, Alert Engine |
| Preservation | Automatische Evidence Collection und Hash-Sicherung | Forensic Service, MinIO |
| Collection | Gezielte Datensammlung auf Basis der Investigation | ES-Queries, Timeline Builder |
| Examination | Analyse der gesammelten Daten | Investigation Workspace, AI-Enrichment |
| Analysis | Zusammenführung, Angriffsrekonstruktion | Timeline, Network Graph, MITRE Mapping |
| Reporting | Forensik-Bericht erstellen (intern oder für Behörden) | Report Generator (PDF/STIX) |
13. Compliance & Datenschutz
13.1 BaFin/BAIT-Anforderungen
| BAIT-Anforderung | SIEM-Umsetzung |
|---|---|
| Protokollierung sicherheitsrelevanter Ereignisse | Alle Log-Quellen werden zentral erfasst und korreliert |
| Aufbewahrungsfristen | Hot: 30 Tage, Warm: 90 Tage, Cold: 1 Jahr (konfigurierbar bis 10 Jahre) |
| Nachvollziehbarkeit | Vollständige Audit-Trails für alle SIEM-Aktionen |
| Anomalie-Erkennung | Sigma Rules + Correlation Engine + ML-basierte Anomalie-Detection |
| Incident-Response-Fähigkeit | SOAR-Playbooks, < 30 min Reaktionszeit |
| Regelmäßige Überprüfung | Quartalsweise Rule-Effectiveness-Reviews, KPI-Reporting |
13.2 DSGVO-konformes Log-Handling
DSGVO-konformes Log-Handling
┌─── Pseudonymisierung ──────────────────────────────────────┐ │ Fluent Bit Lua-Filter: │ │ • Benutzernamen → HMAC-SHA256(username, daily-salt) │ │ • E-Mail-Adressen → Pseudonymisiert │ │ • IP-Adressen → Letztes Oktett maskiert │ │ │ │ Ausnahme: Bei Security-Incident wird Klartext in │ │ separatem, zugriffsbeschränktem Index gespeichert │ │ (nur SOC-Team + CISO mit 4-Augen-Prinzip) │ └─────────────────────────────────────────────────────────────┘ ┌─── Zugriffskontrolle ─────────────────────────────────────┐ │ Elasticsearch Security (X-Pack / Search Guard): │ │ • Document-Level Security (DLS) │ │ • Field-Level Security (FLS) │ │ • Rollen: soc-analyst, soc-lead, ciso, auditor │ └─────────────────────────────────────────────────────────────┘ ┌─── Löschkonzept ──────────────────────────────────────────┐ │ • ILM-Policies löschen Daten automatisch nach Ablauf │ │ • Löschnachweis wird in Audit-Log protokolliert │ │ • Forensik-Daten erst nach Case-Close + Frist gelöscht │ └─────────────────────────────────────────────────────────────┘ ┌─── Rechtsgrundlage ──────────────────────────────────────┐ │ • Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse) │ │ • § 26 BDSG (Beschäftigtendatenschutz) │ │ • BaFin/BAIT als regulatorische Verpflichtung │ │ • Betriebsrat-Vereinbarung über Log-Verarbeitung │ └──────────────────────────────────────────────────────────┘