Sicherheitsüberwachung und Incident Response mit KI einrichten

Design a centralized log collection architecture for [cloud provider/hybrid environment] running [application types]. Include:
- Log sources by category (infrastructure, application, security, identity, network)
- Collection methods (agent-based, agentless, API-based, syslog)
- Log format standardization (CEF, JSON, syslog RFC 5424)
- Transport security (TLS encryption, mutual authentication)
- Retention periods mapped to compliance requirements (ISO 27001 A.8.15, SOC 2 CC7.2, GDPR Art. 5(1)(e))
- Storage tiering (hot/warm/cold) with cost optimization
- Integrity protection for log data (hashing, write-once storage)

Our compliance scope includes [ISO 27001/SOC 2/NIST CSF/GDPR]. Output as architecture document with data flow diagram description.

Compare SIEM architecture options for a [organization size] organization with [cloud environment]. Evaluate:
- Cloud-native SIEM (Microsoft Sentinel, Chronicle, AWS Security Lake + OpenSearch)
- Commercial SIEM (Splunk, QRadar, LogRhythm)
- Open-source SIEM (Wazuh, Elastic Security, Graylog)

For each option, assess: log ingestion capacity, detection rule capabilities, compliance reporting, retention management, integration ecosystem, and total cost of ownership. Our primary frameworks are [list frameworks].

Recommend an architecture that satisfies ISO 27001 A.8.15-A.8.16 and SOC 2 CC7.1-CC7.3 requirements.

Create a MITRE ATT&CK detection coverage matrix for our SIEM deployment covering [log sources available]. For each ATT&CK tactic:
- Map available log sources to detectable techniques
- Identify coverage gaps where we lack visibility
- Prioritize gap remediation based on threat intelligence relevant to [industry]
- Cross-reference detection capabilities to ISO 27001 A.8.16 and NIST DE.CM (Continuous Monitoring) requirements

Output as a matrix with coverage status (Detected/Partial/Gap) and remediation priority.

Generate SIEM detection rules for [SIEM platform] that address the following ISO 27001 and SOC 2 controls:

1. A.5.17 / CC6.1 - Authentication information: Detect brute force attacks, credential stuffing, password spraying
2. A.8.2 / CC6.3 - Privileged access: Detect privilege escalation, unusual admin activity, after-hours privileged access
3. A.8.16 / CC7.2 - Monitoring activities: Detect log source failures, SIEM health anomalies, collection gaps
4. A.5.7 / CC3.2 - Threat intelligence: Detect connections to known malicious IPs, domains, and file hashes
5. A.8.12 / CC6.8 - Data leakage prevention: Detect unusual data exfiltration patterns, large file transfers, unauthorized cloud storage uploads

For each rule, provide: rule logic (query/SPL/KQL), threshold values, severity rating, false positive tuning guidance, and the specific control it satisfies.

Output in [SIEM query language] format.

Design alert correlation rules for [SIEM platform] that reduce alert fatigue while maintaining detection fidelity. Include:
- Multi-stage attack detection (reconnaissance → exploitation → lateral movement → exfiltration)
- User behavior analytics baselines and anomaly thresholds
- Asset criticality-weighted alerting (higher severity for crown jewel assets)
- Time-window correlation (related events within configurable periods)
- Suppression rules for known-good patterns (maintenance windows, authorized scanners)
- Alert enrichment with threat intelligence and asset context
- Escalation triggers for correlated incidents

Map correlation rules to SOC 2 CC7.2 (anomaly detection) and NIST DE.AE (Security event analysis). Define tuning procedures and false positive review cadence.

Create a detailed ransomware incident response playbook for [organization type] with [infrastructure description]. Include:

Detection and initial assessment:
- Indicators of compromise (file extensions, ransom notes, encryption behavior)
- Initial severity assessment criteria
- Decision tree for declaring a ransomware incident

Containment (immediate, within first 60 minutes):
- Network isolation procedures (endpoint, segment, full)
- Identity system lockdown (disable compromised accounts, rotate service credentials)
- Backup verification (confirm backups are unaffected, air-gapped)
- Communication lockdown (preserve evidence, avoid tipping off attacker)

Eradication:
- Forensic imaging before cleanup
- Malware removal and persistence mechanism identification
- IOC sweep across all endpoints and servers
- Active Directory integrity verification

Recovery:
- Prioritized system restoration sequence
- Clean rebuild vs. restore decision criteria
- Data integrity validation post-restoration
- Monitoring intensification during recovery

Map each phase to ISO 27001 A.5.24-A.5.28 and NIST RS.RP, RS.AN, RS.MI, RS.IM requirements.

Create a data breach response playbook that addresses regulatory notification requirements. Include:

Detection and scoping:
- Data classification of affected records (PII, financial, health, credentials)
- Volume estimation and affected data subject identification
- Attack vector and timeline reconstruction

Containment and evidence preservation:
- Data flow interruption procedures
- Forensic evidence collection and chain of custody
- Third-party breach coordination (if vendor-originated)

Regulatory notification timeline management:
- GDPR Article 33: 72 hours to supervisory authority, Article 34 to data subjects
- DORA Article 19: 4 hours initial notification, 72 hours intermediate, 1 month final report
- NIS2 Article 23: 24 hours early warning, 72 hours incident notification, 1 month final report
- SEC Rule: 4 business days for material cybersecurity incidents (Form 8-K)
- State breach notification laws: [specify applicable states]

Notification templates for each regulatory body and data subject communication.

Map to ISO 27001 A.5.24-A.5.28, SOC 2 CC7.3-CC7.5, and GDPR Articles 33-34.

Create incident response playbooks for the following scenarios. For each, include detection criteria, containment steps, eradication procedures, recovery actions, and compliance control mappings:

1. Unauthorized access to privileged systems:
   - Insider threat vs. external compromise differentiation
   - Session termination and credential rotation procedures
   - Access log forensic analysis
   - ISO 27001 A.5.15, A.8.2, SOC 2 CC6.1-CC6.3

2. DDoS attack response:
   - Traffic analysis and attack vector classification (volumetric, protocol, application layer)
   - CDN/WAF mitigation activation procedures
   - ISP and cloud provider escalation contacts
   - Service degradation communication to customers
   - ISO 27001 A.8.6, SOC 2 CC7.4, NIST RS.MI

For each playbook, define roles (Incident Commander, Technical Lead, Communications Lead), decision points requiring management approval, and evidence collection requirements for post-incident reporting.

Design an incident severity classification matrix for [organization type] subject to [GDPR/DORA/NIS2/SOC 2/ISO 27001]. Define four severity levels:

For each level (Critical/High/Medium/Low), specify:
- Impact criteria (data subjects affected, systems impacted, financial exposure, operational disruption)
- Example incident types at that severity
- Response time SLA (time to acknowledge, time to contain, time to resolve)
- Escalation requirements (who must be notified and within what timeframe)
- Regulatory notification triggers and applicable deadlines:
  * GDPR: 72 hours to DPA (Article 33)
  * DORA: 4 hours initial, 72 hours intermediate, 1 month final (Article 19)
  * NIS2: 24 hours early warning, 72 hours notification, 1 month final (Article 23)
- Communication requirements (internal stakeholders, customers, regulators, law enforcement)
- Evidence preservation requirements

Output as a structured matrix suitable for inclusion in our incident response policy document. Map to ISO 27001 A.5.25 (Assessment and decision on information security events) and SOC 2 CC7.4.

Create escalation path diagrams and communication templates for security incidents at [organization type]. Include:

Escalation paths by severity:
- Level 1 (SOC analyst) → Level 2 (IR team) → Level 3 (CISO/executive) → Level 4 (Board/external)
- On-call rotation integration
- Vendor and third-party escalation (cloud provider, MSSP, legal counsel, forensics firm)
- Regulatory body notification paths by jurisdiction

Communication templates for:
- Internal incident declaration (technical audience)
- Executive briefing (non-technical summary with business impact)
- Customer notification (transparent, actionable, compliant with breach notification laws)
- Regulatory notification (GDPR Article 33 template with required fields: nature of breach, categories of data subjects, approximate number affected, DPO contact, likely consequences, measures taken)
- Law enforcement referral (when and how to engage)
- Media holding statement (if public disclosure is required or likely)

Ensure templates meet DORA Article 19 reporting requirements (initial notification within 4 hours of classification as major ICT-related incident) and NIS2 Article 23 (24-hour early warning to CSIRT).

Create a post-incident review report template that meets ISO 27001 A.5.27 and NIST RS.IM requirements. Include sections for:

Incident summary:
- Incident ID, classification, severity, and timeline (detection → containment → eradication → recovery → closure)
- Systems, data, and business processes affected
- Duration and total business impact (financial, operational, reputational)

Root cause analysis:
- Technical root cause (vulnerability, misconfiguration, control failure)
- Contributing factors (process gaps, training deficiencies, tooling limitations)
- 5 Whys analysis template
- Attack chain reconstruction (MITRE ATT&CK mapping where applicable)

Response effectiveness assessment:
- Detection time (how long the threat was present before detection)
- Response time vs. SLA targets
- Playbook adherence (did responders follow documented procedures?)
- Communication effectiveness (were the right people notified on time?)
- Tooling gaps identified during response

Corrective and preventive actions:
- Immediate fixes already implemented
- Short-term improvements (30 days)
- Long-term improvements (90 days)
- Owner, deadline, and tracking mechanism for each action
- Control updates required (policy, procedure, technical)

Compliance documentation:
- Regulatory notifications sent (with timestamps and recipients)
- Evidence of notification compliance (GDPR 72h, DORA 4h, NIS2 24h)
- Audit trail completeness verification

Format as a document template ready for use after any security incident.

Design a corrective action tracking system for post-incident improvements. Include:
- Action item registry with fields: ID, source incident, description, owner, priority, deadline, status, evidence of completion
- Integration points with risk register (new risks identified during incidents)
- Link to management review process (ISO 27001 Clause 9.3)
- Metrics: mean time to close corrective actions, overdue action escalation, recurrence rate
- Quarterly reporting template for management review showing trending data

Map to ISO 27001 Clause 10.1 (Nonconformity and corrective action) and A.5.27 (Learning from information security incidents).

Review our current logging and monitoring architecture: [describe your log sources, SIEM, and retention periods]. Identify gaps against ISO 27001 A.8.15-A.8.16 and SOC 2 CC7.1-CC7.3. For each gap, recommend a specific remediation with implementation priority and estimated effort.

Generate 10 high-priority detection rules for [SIEM platform] covering: brute force authentication, privilege escalation, data exfiltration, lateral movement, and log source failure. For each rule, provide the query logic, threshold, severity, and the ISO 27001 or SOC 2 control it satisfies.

Draft an incident response policy for [organization type] that complies with ISO 27001 A.5.24-A.5.28, SOC 2 CC7.3-CC7.5, and [GDPR/DORA/NIS2] notification requirements. Include scope, roles and responsibilities, severity classification, escalation procedures, notification timelines, and post-incident review requirements.

Design a tabletop exercise scenario for our incident response team simulating a ransomware attack on [critical system]. Include the inject timeline (15 injects over 2 hours), expected decisions at each stage, evaluation criteria for team performance, and a facilitation guide. The exercise should test our compliance with GDPR 72-hour notification and DORA 4-hour initial reporting requirements.

We experienced [describe incident]. Help me structure a post-incident review report covering: timeline reconstruction, root cause analysis using the 5 Whys method, response effectiveness assessment against our SLAs, corrective actions with owners and deadlines, and regulatory notification compliance verification. Format for presentation to management review per ISO 27001 Clause 9.3.

Create a compliance evidence checklist for our security monitoring and incident response capabilities. For each ISO 27001 control (A.5.24-A.5.28, A.8.15-A.8.16) and SOC 2 criterion (CC7.1-CC7.5), list the specific evidence artifacts an auditor will request, where to collect them from, and how to format them for audit submission.