1. Integrations-Philosophie

1.1 Grundprinzip: Security-Event-Driven IT Operations

Das Self-Help Service Portal behandelt Security-Events als zentrale Auslöser für IT-Prozessautomatisierung. Jeder sicherheitsrelevante Vorgang – ob SIEM-Alert, Threat-Intel-Match oder Compliance-Verstoß – wird automatisch in einen nachverfolgbaren, auditierbaren Ticket-Workflow überführt.

Security-Event-Driven IT Operations
                    ┌──────────────────┐
                    │  SECURITY EVENT  │
                    │  (SIEM Alert,    │
                    │   Threat Intel,  │
                    │   Policy-Verstoß)│
                    └────────┬─────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
              ▼              ▼              ▼
     ┌──────────────┐ ┌──────────┐ ┌──────────────┐
     │ Ticketsystem │ │ SOAR     │ │ Governance   │
     │              │ │ Engine   │ │ & Compliance │
     │ • Security-  │ │          │ │              │
     │   Tickets    │ │ • Auto-  │ │ • Audit-     │
     │ • Incidents  │ │   Cont.  │ │   Trail      │
     │ • War Room   │ │ • Play-  │ │ • BAIT-      │
     │ • SLA-Track. │ │   books  │ │   Nachweis   │
     └──────┬───────┘ └─────┬────┘ └──────┬───────┘
            │               │              │
            └───────────────┼──────────────┘
                            ▼
              ┌──────────────────────────┐
              │  UNIFIED SECURITY AUDIT  │
              │  TRAIL (Compliance-ready)│
              └──────────────────────────┘

1.2 Warum tiefe Integration?

AspektOhne IntegrationMit Integration
Security AlertSIEM zeigt Alert → Analyst schaut → manuelles TicketSIEM Alert → Auto-Ticket (P1/P2) → Auto-Enrichment → Analyst bearbeitet
Incident ResponseE-Mail an SOC → manuelle KoordinationAuto-Ticket → SLA-Timer → Eskalation → War Room bei Major Incident
Threat IntelligenceTI-Feed importiert → manuelle PrüfungTI-Match → Auto-Assessment → Auto-Ticket bei relevanten Treffern
SOAR-ContainmentAccount gesperrt → keine DokumentationAccount gesperrt → Auto-Kommentar im Ticket → Audit-Trail komplett
Compliance-NachweisSeparate Logs durchsuchenUnified Audit Trail: SIEM-ID ↔ Ticket-ID ↔ SOAR-ID
ForensikManuell zusammensuchenEin-Klick-Forensik-Paket aus Ticket heraus
ReportingSIEM-KPIs und Ticket-KPIs separatIntegriertes Dashboard: MTTD + MTTR + SLA in einer Ansicht

2. Hybrid-Architektur: Security-Event-Flows

2.1 Event-Flow-Architektur

Security Event Flow Architecture
  ┌─── ON-PREMISES RECHENZENTRUM ──────────────────────────────┐
  │                                                              │
  │  Log-Quellen: AD, Firewall, DNS, K8s, Vault, Portal-Events │
  │       │                                                      │
  │       ▼                                                      │
  │  ┌──────────────────────────────────────────────────────┐   │
  │  │  SIEM ADD-ON                                          │   │
  │  │                                                       │   │
  │  │  Elasticsearch → Alert Engine → Correlation Engine    │   │
  │  │       │               │                │              │   │
  │  │       │               ▼                ▼              │   │
  │  │       │        ┌──────────┐    ┌──────────────┐      │   │
  │  │       │        │ SOAR     │    │ MITRE ATT&CK │      │   │
  │  │       │        │ Engine   │    │ Mapper       │      │   │
  │  │       │        └────┬─────┘    └──────┬───────┘      │   │
  │  │       │             └────────┬────────┘              │   │
  │  └───────┼──────────────────────┼───────────────────────┘   │
  │          │  REST API + RabbitMQ │                            │
  │          ▼                      ▼                            │
  │  ┌──────────────────────────────────────────────────────┐   │
  │  │  SELF-HELP PORTAL                                     │   │
  │  │                                                       │   │
  │  │  Ticket Engine: Auto-Create, SLA, Eskalation, War Room│  │
  │  │  AI Services:   Incident-Summary, Empfehlungen         │  │
  │  │  Log-Suche:     Elasticsearch-Query aus Ticket heraus  │  │
  │  └──────────────────────────────────────────────────────┘   │
  └──────────────────────────────────────────────────────────────┘
         │
         │  Graph API (HTTPS, Outbound Only)
         ▼
  ┌─── AZURE / MICROSOFT 365 CLOUD ───────────────────────────┐
  │                                                              │
  │  M365 Audit Logs   Defender Alerts   Entra ID Sign-In Logs  │
  │  Purview DLP       Teams Events      Conditional Access     │
  │                                                              │
  │  Einbahnstraße: Cloud → On-Prem (Daten bleiben im RZ)     │
  └──────────────────────────────────────────────────────────────┘

2.2 Datenfluss-Prinzip

Daten-TypPrimärer SpeicherortAzure-AnteilSync-Richtung
SIEM-LogsElasticsearch (On-Prem)Keine Cloud-KopieN/A
Security-TicketsPostgreSQL (On-Prem)Keine Cloud-KopieN/A
Forensik-EvidenceMinIO (On-Prem)Keine Cloud-KopieN/A
M365 Audit LogsES (On-Prem)Azure (Quelle)Azure → On-Prem
Defender AlertsES (On-Prem)Azure (Quelle)Azure → On-Prem
Threat Intel FeedsES (On-Prem)ExternExtern → On-Prem
NotificationsOn-Prem (Portal)Teams (Graph API)On-Prem → Azure

2.3 Azure/M365 Log-Quellen

Entra ID: Sign-In Logs, Audit Logs, Risky Sign-Ins, Conditional Access Evaluations – Polling alle 5 min via Graph API
M365 Services: Exchange (Phishing, DLP), SharePoint (External Sharing), Teams (External Participants) – Management Activity API
Defender: Malware, Suspicious Processes, Lateral Movement, Tamper Protection – Polling alle 2 min
Purview: DLP Violations, Sensitivity Label Changes, Data Classification – Management Activity API

3. SIEM-Alert → Ticket: Automatische Erstellung

3.1 Alert-zu-Ticket-Pipeline

Alert-zu-Ticket Pipeline
  SIEM Alert (Sigma Rule / Correlation / ML / TI-Match)
       │
       ▼
  ┌──────────────────┐
  │ 1. SEVERITY      │
  │    ASSESSMENT     │
  │                   │
  │ • Base Severity   → Sigma Rule Level
  │ • Asset Criticality→ CMDB-Lookup
  │ • Threat Intel     → IoC-Match? +10
  │ • User Context     → VIP/Admin? +15
  │ • Korrelation      → Multi-Event? +20
  │ → Final Score: 0-100
  └────────┬─────────┘
           ▼
  ┌──────────────────┐
  │ 2. TICKET-       │
  │    ENTSCHEIDUNG   │
  │                   │
  │ 90-100 → P1 + Auto-Containment
  │ 70-89  → P2 + SOC-Notification
  │ 40-69  → P3 + E-Mail
  │ 20-39  → P4 (Weekly Summary)
  │  0-19  → Info (nur Logging)
  └────────┬─────────┘
           ▼
  ┌──────────────────┐
  │ 3. DEDUPLIZIERUNG│
  │                   │
  │ Offenes Ticket vorhanden?
  │ → Ja: Kommentar hinzufügen
  │ → Nein: Neues Ticket
  │ Zeitfenster: 30 min
  └────────┬─────────┘
           ▼
  ┌──────────────────┐
  │ 4. TICKET-       │
  │    ERSTELLUNG     │
  │                   │
  │ POST /api/v1/tickets
  │ type: security_incident
  │ siem_alert_id, mitre_*, enrichment
  └──────────────────┘

3.2 Alert-Typ → Ticket-Kategorie Mapping

SIEM Alert-TypTicket-KategorieDefault-Priorität
Impossible TravelSecurity > Incident > Anomalous LoginP1-Critical
Brute ForceSecurity > Incident > Brute ForceP2-High
Malware DetectionSecurity > Incident > MalwareP1-Critical
Phishing CampaignSecurity > Incident > PhishingP1-Critical
Data ExfiltrationSecurity > Incident > DatenverlustP1-Critical
Privilege EscalationSecurity > IAM > BerechtigungP1-Critical
Lateral MovementSecurity > Incident > VerdächtigP1-Critical
DLP ViolationSecurity > Incident > DatenverlustP2-High
Off-Hours AdminSecurity > PAM > Session-ReviewP3-Medium
Policy ViolationGovernance > Ausnahme-AntragP3-Medium
Vulnerability (Critical)Security > Vulnerability > PatchP2-High
AI Abuse DetectionSecurity > Incident > VerdächtigP2-High

3.3 Auto-Enrichment bei Ticket-Erstellung

Bei jedem automatisch erstellten Security-Ticket wird sofort angereichert:

User-Enrichment: Name, Abteilung, Standort, Manager, VIP-Status, MFA-Status, Gruppen
Asset-Enrichment: Hostname, OS, Patch-Level, Kritikalität, VLAN, Vulnerability-Status
GeoIP: Quell-IP → Land, Stadt, ISP, Vergleich mit üblichen Standorten
Threat Intelligence: IP/Domain/Hash gegen TI-Feeds, IoC-Matches, MITRE ATT&CK
Historischer Kontext: Ähnliche Incidents (30 Tage), offene Tickets für Asset
AI (Claude): Zusammenfassung, Handlungsempfehlung, Risiko-Score (0-100)
portal.hafs.de/tickets/SEC-2026-0042
HAFS Service Portal ACTIVE INCIDENT SOC · M. Becker
SEC-2026-0042
Impossible Travel – Privilegierter Account kompromittiert
Containment Eskalieren
Quelle: SIEM Auto-Alert
Typ: Security Incident
Priorität: P1 Critical
Status: Active Incident
Erstellt: 10.02.2026, 14:23:18
Zugewiesen: SOC Team Alpha
SLA Response: 15 min Verbleibend: 03:42
Incident-Timeline
14:23:18
Alert ausgelöst P1
Sigma Rule: Impossible Travel – Login aus Frankfurt (DE), dann 4 min später aus Bukarest (RO). User: s.hoffmann (Domain Admin).
14:23:19
AI Triage Claude
Confidence: 98% – „Hohe Wahrscheinlichkeit einer Account-Kompromittierung. Empfehlung: Sofortige Sperrung, Session-Kill, MFA-Token zurücksetzen.“
14:23:20
Auto-Eskalation
Score 95/100 → P1-Playbook aktiviert. Benachrichtigung: PagerDuty, Teams #soc-critical, CISO.
14:24:01
Team zugewiesen
SOC Team Alpha (M. Becker, L. Fischer, K. Braun). Auto-Assignment nach Schichtplan.
14:26:33
Containment gestartet Aktiv
Account s.hoffmann gesperrt (AD + Entra ID). 3 aktive Sessions terminiert. MFA-Token revoked.
SIEM-Kontext
Korrelierte Alerts (3)
Impossible Travel Critical
Privilege Escalation Attempt Critical
Anomalous SMB Access High
Betroffene Assets
WS-FRA-0142 Workstation (Frankfurt)
DC-FRA-01 Domain Controller
FS-FRA-03 File Server (Kundenablage)
VPN-GW-01 VPN Gateway
MITRE ATT&CK
T1078 – Valid Accounts T1110 – Brute Force T1021 – Remote Services T1083 – File Discovery
Quell-IP Analyse
IP: 185.234.xx.xx
Standort: Bukarest, Rumänien
ISP: VPN-Anbieter (verdächtig)
Reputation: Malicious (3 TI-Feeds)
In SIEM-Dashboard öffnen →
Security-Incident-Ticket mit SIEM-Kontext: Automatisch erstelltes P1-Ticket zeigt Timeline, AI-Triage, korrelierte Alerts, betroffene Assets und MITRE-ATT&CK-Mapping.

4. Ticket → SIEM: Bidirektionale Synchronisation

4.1 Portal-Events als SIEM-Log-Quellen

Portal-EventSIEM Event-KategorieRelevanz
Security-Ticket erstelltsecurity-incidentAudit-Trail
Ticket-Status geändertsecurity-incidentSLA-Tracking
Containment durchgeführtsecurity-responseSOAR-Audit
War Room aktiviertsecurity-incidentMajor Incident
Forensik-Paket erstelltsecurity-forensicsChain of Custody
Ticket eskaliertsecurity-incidentSLA-Breach
SOAR-Playbook ausgeführtsecurity-responseAutomatisierung
False Positive markiertsecurity-tuningRule-Tuning

4.2 SIEM-Aktionen aus dem Ticket heraus

Ticket-integrierte SIEM-Aktionen
  ┌─── Security-Ticket HAFS-2026-01234 ──────────────────┐
  │                                                        │
  │  [Ticket-Details, Enrichment, Timeline]                │
  │                                                        │
  │  SIEM Quick Actions:                                   │
  │                                                        │
  │  Investigate:                                          │
  │  [Log-Suche User] [Log-Suche Asset] [Network Flows]  │
  │  [DNS-Queries]    [Auth-Events 24h]  [Admin-Actions]  │
  │                                                        │
  │  Contain:                                              │
  │  [Account sperren]  [Session kill]  [Device isolieren]│
  │  [DNS-Sinkhole]     [Firewall-Block] [MFA erzwingen] │
  │                                                        │
  │  Analyze:                                              │
  │  [Forensik-Paket]   [MITRE Mapping] [Timeline]       │
  │  [IOCs extrahieren] [In Kibana öffnen]               │
  │                                                        │
  │  Report:                                               │
  │  [Incident-Report PDF]  [STIX Export]                 │
  │  [Management Summary]   [BaFin-Meldung Draft]        │
  │                                                        │
  │  Jede Aktion → Ticket-Kommentar + SIEM-Event          │
  └────────────────────────────────────────────────────────┘

5. SOAR-Ticket-Integration

5.1 Playbook-Orchestrierung mit Ticket-Lifecycle

SOAR Playbook ↔ Ticket Lifecycle
  SIEM Alert (Severity: Critical)
       │
  ┌────┴───────────────────────────────────────────────────┐
  │  PLAYBOOK: "Critical Security Incident Response"        │
  │                                                         │
  │  PHASE 1: ERKENNUNG (0-1 min)                          │
  │  ✓ Auto-Enrichment (GeoIP, User, Asset, TI, History)  │
  │  ✓ Ticket erstellen (P1) → Status: NEW → TRIAGED     │
  │  ✓ AI-Assessment (Claude) → Summary + Empfehlung     │
  │                                                         │
  │  PHASE 2: EINDÄMMUNG (1-5 min)                        │
  │  ✓ Auto-Containment (Account-Lock, Session-Kill)      │
  │  ✓ Ticket → ASSIGNED (SOC-Team)                       │
  │  ✓ Notification (Teams, PagerDuty, E-Mail CISO)       │
  │                                                         │
  │  PHASE 3: INVESTIGATION (SOC-Analyst)                   │
  │  ○ Analyst nimmt Ticket an → IN_PROGRESS               │
  │  ○ Log-Suche, Timeline, Forensik aus Ticket              │
  │                                                         │
  │  PHASE 4: REMEDIATION                                   │
  │  ○ Passwort-Reset, MFA-Token, Firewall-Regeln           │
  │  ○ Jede Aktion → Ticket-Kommentar + SIEM Event        │
  │                                                         │
  │  PHASE 5: RECOVERY & CLOSURE                           │
  │  ○ Containment aufheben → Ticket: RESOLVED             │
  │  ○ Post-Incident Review → Knowledge Base               │
  │  ○ Ticket: CLOSED → KPI-Berechnung                     │
  └─────────────────────────────────────────────────────────┘

5.2 Playbook-Katalog

PlaybookTriggerAuto-TicketAuto-ContainmentNotification
Critical IncidentScore 90-100P1Account-Lock + Session-KillPagerDuty + Teams + CISO
Brute Force> 5 Failed/5minP2IP-Block 15minTeams #soc-alerts
PhishingExchange DetectionP2E-Mail-QuarantäneTeams + betroffene User
MalwareDefender AlertP1Device-Isolation empf.PagerDuty + Teams
Data ExfiltrationBulk + ExternalP1Account-Lock + Net-BlockPagerDuty + CISO + DPO
Insider ThreatKorrelationP1Account-LockCISO + HR + Legal
Lateral Movement> 5 Hosts/10minP1Segment-IsolationPagerDuty + Network
DLP ViolationPurview MatchP2/P3Nach SeverityManager + Compliance
TI MatchIoC in Live-TrafficP2DNS-Sinkhole (C2)Teams #soc-alerts

5.3 SLA-Eskalation für Security-Tickets

P1-Critical: 0 min: Auto-Containment + SOC-Alert | 15 min: Team Lead | 30 min: Security-Manager | 60 min: CISO | 120 min: War Room

P2-High: 0 min: SOC-Alert (Teams) | 30 min: Agent Push | 2h: Team Lead | 4h: Security-Manager

P3-Medium: 0 min: E-Mail SOC-Queue | 4h: Reminder | 8h: Team Lead

Bei jeder Eskalation: Ticket-Kommentar + SIEM Event + Eskalations-Zähler
portal.hafs.de/soar/playbook/PB-BruteForce/execution/42
HAFS Service Portal SOAR Playbook-Ausführung #42
PB-BruteForce · Execution #42
Playbook: Brute-Force Response
Trigger: SEC-2026-0042 · Gestartet: 10.02.2026, 14:23:20
Laufend Abbrechen
6 / 8
Schritte abgeschlossen
17:24
Gesamtdauer
4 auto
Automatisiert
1 manual
Genehmigt
1
Alert Validierung Done 0,3s
SIEM-Alert verifiziert. Sigma Rule Match bestätigt. Severity Score: 95/100.
2
IP Reputation Check Done 1,2s
185.234.xx.xx → 3 TI-Feeds: Malicious. Zuordnung: VPN-Exit-Node (Bukarest). Historisch 12 Abuse-Reports.
3
Account Status prüfen Done 0,8s
User: s.hoffmann – Domain Admin, VIP-Flag, 3 aktive Sessions, letzte MFA-Validierung vor 6h.
4
IP blockieren Done auto 2,1s
Firewall-Rule erstellt: BLOCK 185.234.xx.xx (inbound/outbound). DNS-Sinkhole für assoziierte Domains.
5
Host isolieren Done manual 4min
WS-FRA-0142 isoliert (VLAN-Quarantäne). Genehmigung durch M. Becker (SOC Lead), 14:27:15.
6
EDR Full Scan Aktiv läuft seit 12min
CrowdStrike Full Scan auf WS-FRA-0142. Fortschritt: 67%. Bisherige Funde: 2 suspicious DLLs.
7
Forensik-Image erstellen Ausstehend
Wartet auf Abschluss EDR Scan. Memory Dump + Disk Image von WS-FRA-0142.
8
Post-Incident Report Ausstehend
AI-generierter Bericht (Claude Sonnet). Inkl. Timeline, IoCs, Empfehlungen, BaFin-Meldungsentwurf.
Ausführungslog
14:23:20.103 INFO Playbook PB-BruteForce gestartet. Trigger: SEC-2026-0042 (Score: 95)
14:23:20.412 INFO Step 1: Alert validiert – Sigma Rule „Impossible Travel“ confirmed
14:23:21.634 WARN Step 2: IP 185.234.xx.xx in 3/5 TI-Feeds als malicious gelistet
14:23:22.418 WARN Step 3: User s.hoffmann ist Domain Admin – erhöhtes Risiko
14:23:24.502 INFO Step 4: Firewall-Rule BLOCK-185234xx erstellt (auto-approved)
14:23:24.891 INFO Step 4: DNS-Sinkhole für 3 assoziierte Domains aktiviert
14:24:01.000 WARN Step 5: Host-Isolation erfordert manuelle Genehmigung (VIP-Asset)
14:27:15.332 INFO Step 5: Genehmigt durch M. Becker (SOC Lead). WS-FRA-0142 isoliert.
14:27:16.001 INFO Step 6: EDR Full Scan gestartet auf WS-FRA-0142
14:35:42.718 ERR Step 6: Suspicious DLL gefunden: C:\Windows\Temp\svc_update.dll (SHA256: a3f2…)
14:38:11.204 ERR Step 6: Suspicious DLL gefunden: C:\Users\s.hoffmann\AppData\rundll_helper.dll
SOAR-Playbook-Ausführung: Automatisierte Brute-Force-Response mit 8 Schritten – von Alert-Validierung über IP-Blockierung bis zum Post-Incident-Report, inkl. manuellem Genehmigungsschritt.

6. War Room Integration

6.1 Automatische Aktivierung

Trigger-Bedingungen:
• P1-Ticket + > 10 betroffene User
• P1-Ticket + SLA-Breach (> 120 min)
• > 3 P1-Tickets zum selben Angriffspattern
• Manuell: IT-Manager oder CISO
War Room Activation
  Trigger erkannt
       │
       ▼
  1. Master-Ticket erstellen (SEC-MAJOR-2026-001)
     → Verknüpft alle Related Tickets

  2. Teams-Channel: "#warroom-sec-2026-001"
     → SOC-Team, CISO, IT-Security-Manager,
       Fachbereiche, Incident Commander,
       (Optional: Legal, DPO, HR)

  3. Live-Dashboard im Portal
     → Echtzeit-Status aller verknüpften Tickets
     → SIEM-Alert-Feed für Angriffsmuster
     → Impact-Tracking (User, Services, Assets)
     → Timeline aller Aktionen

  4. Automatische Status-Updates
     → Alle 30 min: AI-generierte Zusammenfassung

  5. Communication Templates
     → Interne Kommunikation, Management-Briefing
     → Optional: BaFin-Meldung, Kunden-Komm.
portal.hafs.de/warroom/SEC-2026-0042
HAFS Service Portal WAR ROOM SEC-2026-0042 · Aktiv seit 47 min
⚠ Major Incident: Privilegierter Account kompromittiert
Incident Commander: Dr. A. Winkler (CISO) · Geöffnet: 10.02.2026, 14:23 · Teams: #warroom-sec-2026-042
Severity: CRITICAL
Live-Kommunikation
MB
M. Becker (SOC Analyst) · 14:26
Account s.hoffmann gesperrt. 3 Sessions beendet. Quelle ist VPN-Exit-Node Bukarest. Sieht nach gezieltem Angriff aus.
TW
T. Wagner (Network Admin) · 14:29
Firewall-Logs bestätigen: 47 Verbindungsversuche von 185.234.xx.xx in den letzten 2h. Ziel waren SMB-Shares auf FS-FRA-03. IP ist jetzt geblockt.
AW
Dr. A. Winkler (CISO) · 14:34
Danke für schnelle Reaktion. Bitte prüfen ob Kundenablage betroffen ist – falls ja, müssen wir BaFin-Meldung vorbereiten. @T. Wagner: Bitte Network-Flows der letzten 24h exportieren.
MB
M. Becker (SOC Analyst) · 14:38
EDR hat 2 suspicious DLLs auf WS-FRA-0142 gefunden. Warte auf Full-Scan-Ergebnis. Forensik-Image wird nach Scan erstellt.
TW
T. Wagner (Network Admin) · 14:42
Gute Nachricht: Keine Datenexfiltration erkennbar. SMB-Zugriffe waren Read-Only, 4 Dateien geöffnet, keine Downloads über Proxy/NAT.
Aktions-Timeline
14:23
Alert & Ticket erstellt
SIEM Impossible Travel Alert → Auto-Ticket SEC-2026-0042 (P1)
14:24
War Room aktiviert
P1 + Domain Admin betroffen → automatische Aktivierung
14:26
Containment: Account
s.hoffmann gesperrt (AD + Entra ID). Sessions terminiert.
14:27
Containment: Host
WS-FRA-0142 in VLAN-Quarantäne verschoben.
14:29
Containment: Netzwerk
IP 185.234.xx.xx geblockt. DNS-Sinkhole aktiv.
14:35
EDR Fund !
2 suspicious DLLs auf WS-FRA-0142 identifiziert.
14:42
Entwarnung Exfiltration
Keine Datenexfiltration nachweisbar.
Quick Actions
✓ Host isoliert ✓ IP geblockt ✓ Account gesperrt Forensik-Image
Status
Dauer: 47 min
Assets: 4 betroffen
Team: 5 Mitglieder
Tickets: 3 verknüpft
Playbook: Step 6/8
Team
AW Dr. A. Winkler (IC)
MB M. Becker (SOC)
TW T. Wagner (Net)
LF L. Fischer (SOC)
KB K. Braun (SOC)
War Room: Kollaborative Incident-Response-Ansicht mit Live-Chat, Aktions-Timeline und Quick-Actions – ermöglicht koordinierte Zusammenarbeit zwischen SOC, Netzwerk-Team und CISO.

7. Cross-System Integration: SIEM ↔ IAM/PAM ↔ Tickets

7.1 Integrierte Incident-Response-Kette

Cross-System Incident Response: Kompromittierter Account
  SIEM ADD-ON:
   1. Erkennung: Impossible Travel + Brute Force
   2. Alert-Severity: Critical (Score: 95)
   3. MITRE: T1078 + T1110
          │
          ▼
  TICKETSYSTEM (Portal):
   4. Auto-Ticket: HAFS-2026-01234 (P1)
   5. Auto-Enrichment: User, Asset, GeoIP, TI
   6. AI-Assessment: "Hohe Wahrsch. Account-Komprom."
   7. SLA-Timer: Response 15 min
          │
          ▼
  IAM/PAM ADD-ON:
   8. Auto-Containment: Account disabled (AD + Entra ID)
   9. PAM-Sessions terminiert (Vault)
  10. Audit-Log: IAM-Action mit Ticket-Referenz
          │
          ▼
  BACK TO TICKETSYSTEM:
  11. Notifications: SOC (Teams), CISO (E-Mail)
  12. SOC-Analyst Investigation
  13. Remediation: Passwort-Reset, MFA-Token
  14. Containment aufheben
  15. Ticket → Resolved → Post-Incident Review

  Ziel: < 30 min von Erkennung bis Containment
  Lückenloser Audit-Trail über 3 Systeme

7.2 Cross-System Event-Bus

EventQuelleZiel(e)Bus-Topic
security.alert.createdSIEMTickets, IAM/PAMsecurity.alert.created
ticket.security.createdTicketsSIEM, IAM/PAMticket.security.created
iam.containment.executedIAM/PAMTickets, SIEMiam.containment.executed
ticket.escalatedTicketsSIEM, Notificationsticket.escalated
soar.playbook.executedSIEM (SOAR)Ticketssoar.playbook.executed
warroom.activatedTicketsSIEM, IAM/PAM, Teamswarroom.activated
forensics.evidence.collectedSIEMTicketsforensics.evidence.collected
ti.ioc.matchedSIEM (TI)Ticketsti.ioc.matched

8. REST-API-Spezifikation

8.1 SIEM → Portal APIs

EndpointMethodeBeschreibung
/api/v1/ticketsPOSTSecurity-Ticket erstellen (type, priority, siem_alert_id, mitre_*, enrichment)
/api/v1/tickets/{id}/statusPUTTicket-Status synchronisieren (Contained, Resolved)
/api/v1/tickets/{id}/commentsPOSTEnrichment-Daten, SOAR-Actions als Kommentar
/api/v1/tickets/{id}/relatePOSTTickets verknüpfen (caused_by, related_to, duplicate_of)
/api/v1/security/incidentsPOSTIncident-Objekt mit MITRE-Mapping erstellen
/api/v1/security/warroomPOSTWar Room für Major Incident aktivieren
/api/v1/notifications/securityPOSTSecurity-Benachrichtigung (Teams, E-Mail, PagerDuty)

8.2 Portal → SIEM APIs

EndpointMethodeBeschreibung
/api/v1/siem/eventsPOSTPortal-Events an SIEM senden
/api/v1/siem/incidents/{id}GETIncident-Details aus SIEM abrufen
/api/v1/siem/searchPOSTLog-Suche mit Ticket-Kontext-Filter
/api/v1/siem/alertsGETAktive Alerts für Portal-Dashboard
/api/v1/siem/kpisGETSOC-KPIs (MTTD, MTTR, etc.)
/api/v1/siem/forensics/collectPOSTForensik-Paket für Ticket erstellen
/api/v1/siem/forensics/{id}GETForensik-Paket-Details abrufen
/api/v1/siem/forensics/{id}/timelineGETAuto-generierte Incident-Timeline
/api/v1/siem/containment/account-lockPOSTAccount sperren (via IAM/PAM)
/api/v1/siem/containment/session-killPOSTAlle aktiven Sessions terminieren
/api/v1/siem/containment/network-isolatePOSTNetzwerk-Isolation (via Firewall API)
/api/v1/siem/containment/dns-sinkholePOSTDNS-Sinkhole für verdächtige Domain

9. Security-Dashboard im Portal

Portal: Security Operations Dashboard
  ┌─── Quick Stats ──────────────────────────────────────────┐
  │                                                            │
  │  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐ │
  │  │ Offene   │  │ Critical │  │ MTTD     │  │ Security │ │
  │  │ Security-│  │ Alerts   │  │ (Avg)    │  │ Score    │ │
  │  │ Tickets  │  │          │  │          │  │          │ │
  │  │   12     │  │    3     │  │  8 min   │  │  82/100  │ │
  │  └──────────┘  └──────────┘  └──────────┘  └──────────┘ │
  │                                                            │
  │  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐ │
  │  │ SLA      │  │ Auto-    │  │ False    │  │ EPS      │ │
  │  │ Compli.  │  │ Resolved │  │ Positive │  │ (Live)   │ │
  │  │  96.2%   │  │  34%     │  │  12%     │  │  3,247   │ │
  │  └──────────┘  └──────────┘  └──────────┘  └──────────┘ │
  └────────────────────────────────────────────────────────────┘

  ┌─── Aktive Security-Tickets ──────────────────────────────┐
  │                                                            │
  │  HAFS-2026-1234 │ Impossible Travel │ P1 │ 1h 23m │ InProg│
  │  HAFS-2026-1233 │ Brute Force       │ P2 │ 2h 45m │ Assign│
  │  HAFS-2026-1230 │ DLP Violation     │ P3 │ 5h 12m │ InProg│
  └────────────────────────────────────────────────────────────┘

  ┌─── MITRE ATT&CK Heatmap (30 Tage) ──────────────────────┐
  │  Initial Access   ████████░░  15 Hits                      │
  │  Credential Acc.  ██████████  22 Hits                      │
  │  Execution        ████░░░░░░   8 Hits                      │
  │  Persistence      ███░░░░░░░   5 Hits                      │
  │  Lateral Movement ██░░░░░░░░   3 Hits                      │
  │  Exfiltration     █░░░░░░░░░   2 Hits                      │
  └────────────────────────────────────────────────────────────┘

10. Compliance & Audit-Trail

10.1 Unified Audit Trail

Jeder Security-Vorgang wird systemübergreifend nachverfolgbar über Correlation IDs: siem_alert_idticket_idsoar_execution_idiam_action_id.

Speicherung: PostgreSQL (Append-Only, Hash-Chain) + Elasticsearch (Volltextsuche) + MinIO (Langzeit 5-10 Jahre)
Compliance: BaFin/BAIT, DSGVO, ISO 27001, DORA

10.2 BaFin/BAIT-konforme Dokumentation

BAIT-AnforderungUmsetzung
MeldepflichtP1-Tickets automatisch als "BaFin-meldepflichtig" markiert. AI generiert Meldungs-Draft.
Lückenlose ProtokollierungUnified Audit Trail über SIEM + Tickets + IAM/PAM
NachvollziehbarkeitJede Containment-/Remediation-Aktion als Ticket-Kommentar + SIEM-Event
Regelmäßige ÜberprüfungQuartalsweise Rule-Effectiveness-Reports automatisch generiert
Response-ZeitenMTTD, MTTR, MTTC automatisch berechnet und reportet
Lessons LearnedPost-Incident Review → Knowledge Base → Detection Rule Verbesserung

10.3 DORA ICT Incident Reporting

Major ICT Incident Workflow (DORA Art. 18/19):

1. Auto-Klassifikation: Impact-Analyse, Dauer-Prognose (AI), Cross-Border-Prüfung
2. Initial Report (4h): Auto-Draft aus Ticket-Daten
3. Interim Report: Updates während Bearbeitung
4. Final Report: Nach Incident-Closure
5. Review: CISO + Compliance (4-Augen-Prinzip)
6. Meldung an BaFin (manuell – Portal liefert Draft + Daten)

11. AI-Integration: Claude im Security-Kontext

11.1 AI-gestützte Security-Ticket-Features

FeatureBeschreibungTrigger
Incident-ZusammenfassungEnrichment-Daten in natürlicher Sprache zusammengefasstBei Ticket-Erstellung
HandlungsempfehlungPriorisierte Schritte für SOC-AnalystBei Ticket-Erstellung
Risiko-BewertungScore 0-100 mit BegründungBei Ticket-Erstellung
Ähnliche IncidentsSemantische Suche nach vergangenen IncidentsBei Ticket-Ansicht
Post-Incident ReportAutomatischer Report-DraftBei Ticket-Closure
BaFin-Meldungs-DraftRegulatorischer Meldungs-EntwurfBei P1 + meldepflichtig
Rule-TuningAnalyse von False Positives → Sigma-Rule-VorschlägeWöchentlich (Batch)
Trend-AnalyseSecurity-Trends über längere ZeiträumeMonatlich (Report)

11.2 Modell-Routing

Use CaseModellBegründung
Quick Triage, False-Positive-AnalyseClaude Haiku 4.5Schnell, kostengünstig, hoher Durchsatz
Incident-ZusammenfassungClaude Haiku 4.5Standard-Zusammenfassung
P1-Empfehlung, Post-Incident ReportClaude Sonnet 4.5Komplexe Analyse, höhere Qualität
BaFin-Meldungs-DraftClaude Sonnet 4.5Regulatorischer Kontext, Präzision
Rule-Tuning-AnalyseClaude Sonnet 4.5Pattern-Analyse, Sigma-Verständnis

11.3 PII-Filterung

Gefiltert (vor Claude API-Aufruf): Benutzernamen → Pseudonym, E-Mail → [redacted], Personalnummern, Telefon, Bankverbindungen

Nicht gefiltert (essentiell für Security-Analyse): IP-Adressen, Hostnames, Event-Details, MITRE ATT&CK, Timestamps, IoC-Daten

Mapping Pseudonym → Klartext bleibt nur On-Premises.

12. KPIs & Reporting

12.1 Integrierte Security-Operations-KPIs

KPIDatenquelleZiel
MTTD (Mean Time to Detect)SIEM< 15 min
MTTR (Mean Time to Respond)Ticket< 30 min
MTTC (Mean Time to Contain)Ticket + SIEM< 2h
MTTRE (Mean Time to Remediate)Ticket< 24h
SLA ComplianceTicket> 95%
Auto-Containment RateSOAR + Ticket> 40%
Auto-Ticket-ErstellungSIEM + Ticket> 80%
False Positive RateSIEM + Ticket< 20%
Enrichment-VollständigkeitTicket> 95%
Cross-System-LatenzEvent-Bus< 10 s

12.2 Automatisierte Reports

ReportFrequenzEmpfänger
SOC Daily SummaryTäglich 08:00SOC-Team
Security WeeklyMontags 09:00CISO, IT-Leitung
Incident TrendMonatlichManagement
BAIT Security ReportMonatlichBaFin-Beauftragter
DORA ResilienceQuartalsweiseVorstand, BaFin
MITRE CoverageQuartalsweiseSOC-Team, CISO
AI EffectivenessQuartalsweiseIT-Leitung

13. Datenmodell-Erweiterungen

Security-Ticket-Erweiterungen

Das Basis-Ticket-Datenmodell (siehe 04-Ticketsystem) wird für Security-Tickets erweitert:

Security-Ticket Datenmodell (Erweiterung)
  Security-Ticket (erweitert Basis-Ticket)
  ├── Alle Basis-Felder (04-TICKETSYSTEM.md)
  │
  ├── Security-Spezifisch
  │   ├── siem_alert_id
  │   ├── siem_severity_score (0-100)
  │   ├── mitre_tactics []
  │   ├── mitre_techniques []
  │   ├── kill_chain_phase
  │   ├── affected_users []
  │   ├── affected_assets []
  │   ├── source_ips []
  │   └── ioc_indicators []
  │
  ├── Enrichment
  │   ├── geoip_data
  │   ├── user_context
  │   ├── asset_context
  │   ├── threat_intel_matches []
  │   ├── historical_context
  │   └── ai_assessment
  │
  ├── Containment
  │   ├── containment_status
  │   ├── containment_actions []
  │   └── containment_lifted_at
  │
  ├── Forensik
  │   ├── evidence_ids []
  │   ├── chain_of_custody []
  │   └── forensic_status
  │
  ├── Compliance
  │   ├── bafin_reportable
  │   ├── dora_classification
  │   ├── dsgvo_relevant
  │   └── regulatory_reports []
  │
  └── War Room
      ├── warroom_active
      ├── warroom_channel
      ├── master_ticket_id
      └── related_ticket_ids []

14. Sicherheit & Resilience

14.1 Absicherung der Kommunikation

MaßnahmeUmsetzung
API-AuthMutual TLS (mTLS) zwischen SIEM und Portal
Service AccountsDedizierte Accounts mit minimalen Rechten
Rate-LimitingMax. 100 Ticket-Erstellungen/Minute
Payload-ValidierungJSON-Schema-Validierung aller API-Payloads
Audit-LoggingJeder API-Call protokolliert
NetzwerkSeparate VLANs (20+50), Firewall-Rules
Message-BusRabbitMQ mit TLS + SASL-Auth
SecretsAPI-Keys und Zertifikate in HashiCorp Vault
Replay-ProtectionNonce + Timestamp (Max. 5 min Skew)

14.2 Ausfallszenarien

SzenarioAuswirkungMitigation
SIEM → Portal nicht erreichbarKeine Ticket-ErstellungRetry-Queue (RabbitMQ, max. 1h), Fallback: E-Mail
Portal → SIEM nicht erreichbarKeine Log-Suche aus TicketSOC nutzt Kibana direkt
RabbitMQ-AusfallAsync Events verzögertPersistent Messages, REST-API als Fallback
Elasticsearch-AusfallKeine neuen AlertsFluent Bit File-Buffer, Status-Anzeige im Portal
Portal-AusfallTickets nicht erstellbarSIEM erstellt lokale Records, Sync nach Recovery

15. Rollout & Phasenplan

PhaseZeitraumScope
Phase 1: BasisMonat 6-7Auto-Ticket bei Critical/High Alerts
Phase 2: SOARMonat 7-8Playbooks mit Ticket-Lifecycle, Auto-Containment
Phase 3: InvestigationMonat 8-9Log-Suche aus Ticket, Forensik-Paket, Timeline
Phase 4: AIMonat 9-10Claude-Assessment, Incident-Summary, Empfehlungen
Phase 5: Cross-SystemMonat 10-11SIEM ↔ IAM/PAM ↔ Ticket vollständig integriert
Phase 6: AdvancedMonat 11-12War Room, DORA-Reporting, Trend-Analyse
Voraussetzungen:
✓ Portal Ticketsystem (Phase 1 MVP, Monat 3-6)
✓ SIEM Add-on Basis (Phase 2, Monat 6-9)
✓ IAM/PAM Add-on Basis (Phase 2, Monat 6-9)
✓ RabbitMQ / NATS Message Bus (Phase 0)
✓ HashiCorp Vault (Phase 0)
✓ Anthropic Claude API (Phase 1)

16. Gesamtübersicht

SIEM ↔ Ticketsystem im Portal-Ökosystem
  ┌──────────────────────────────────────────────────────────┐
  │              SECURITY-EVENT-QUELLEN                        │
  │  On-Prem: AD, Firewall, K8s, DNS, Vault, Portal          │
  │  Azure:   Entra ID, Defender, M365, Purview               │
  │  Extern:  CERT-Bund, MISP, Abuse.ch                       │
  └──────────────────────────┬───────────────────────────────┘
                              │
                              ▼
  ┌──────────────────────────────────────────────────────────┐
  │  SIEM ADD-ON                                               │
  │  Fluent Bit → ES → Alert Engine → Correlation → SOAR     │
  └──────────────────────────┬───────────────────────────────┘
                              │ REST API + RabbitMQ
                              ▼
  ┌──────────────────────────────────────────────────────────┐
  │  SELF-HELP SERVICE PORTAL                                  │
  │                                                            │
  │  Ticket Engine │ Security Dashboard │ AI Services (Claude) │
  │                                                            │
  │  ┌────────────────────────────────────────────────────┐   │
  │  │  UNIFIED AUDIT TRAIL                                │   │
  │  │  PostgreSQL + ES + MinIO (5-10 Jahre)               │   │
  │  └────────────────────────────────────────────────────┘   │
  └──────────────────────────┬───────────────────────────────┘
                              │
                              ▼
  ┌──────────────────────────────────────────────────────────┐
  │  IAM/PAM ADD-ON                                            │
  │  Auto-Containment, Remediation, Access Review              │
  │  Jede Aktion → Ticket-Kommentar + SIEM-Event              │
  └──────────────────────────────────────────────────────────┘
                              │
  ┌──────────────────────────────────────────────────────────┐
  │  SHARED INFRASTRUCTURE (RKE2 Cluster)                      │
  │  ES │ PostgreSQL │ Redis │ MinIO │ RabbitMQ │ Vault       │
  └──────────────────────────────────────────────────────────┘
  ┌──────────────────────────────────────────────────────────┐
  │  VMware vSphere (Rechenzentrum HAFS)                       │
  └──────────────────────────────────────────────────────────┘