IT emergency management: incident response and crisis management

Summary: A simulated crisis exercise in which a security team runs through a hypothetical attack or incident during a meeting - without affecting any actual systems. Tabletop exercises identify gaps in incident response plans before a real incident occurs.

IT Incident Management is the organized preparation for, response to, and recovery from IT security incidents. The difference between a disaster and a successfully managed incident often lies solely in the existence of a good plan.

The NIST Incident Response Framework

The NIST (National Institute of Standards and Technology) defines 4 phases:

Phase 1: PREPARATION

• Create an incident response plan
• Define the team, clarify roles
• Provide tools (forensic software, backup systems)
• Conduct regular drills (tabletop exercises)

Phase 2: DETECTION & ANALYSIS

• Detect the incident (SIEM alert, user report, external report)
• Assess scope and severity
• Back up logs (do not overwrite!)
• Document timestamps

Phase 3: CONTAINMENT, ERADICATION & RECOVERY

• Stop the spread of damage
• Remove the attacker from the system
• Gradually restore systems

Phase 4: POST-INCIDENT ACTIVITIES

• Root Cause Analysis
• Lessons Learned
• Improve processes
• Finalize regulatory reports

The Incident Response Plan

Core Elements of an IR Plan

1. Incident Classification Matrix

P1 - CRITICAL: Ongoing ransomware attack, complete system/network failure, active APT compromise. Response: immediate escalation to C-level, fully activate crisis team.

P2 - HIGH: Compromised admin account, loss of sensitive data, malware on multiple systems. Response: notify IT management and CISO, activate forensic service provider.

P3 - MEDIUM: Compromised standard user account, malware on a single endpoint (isolated), phishing email opened. Response: standard IT security process.

P4 - LOW: Spam campaign (no clicks), suspicious email reported. Response: documentation, standard response.

2. RACI Matrix (Roles and Responsibilities)

R=Responsible, A=Accountable, C=Consulted, I=Informed

3. Contact List (24/7)

Internal:

• CISO/IT Manager: [Name] [Mobile] [Signal]
• CEO: [Name] [Mobile]
• Data Protection Officer: [Name] [Mobile]
• IT Emergency Hotline: [Number] (24/7)

External - On-call (contractual):

• Forensics/IR Service: [Company] [Number] [SLA: 4-hour response]
• Cyber Lawyer: [Law Firm] [Contact Person]
• Cyber Insurance: [Policy No.] [Claims Hotline]

Authorities:

• BSI / CERT-Bund: 0800 274 1000 (toll-free)
• LKA Cybercrime: [relevant LKA]
• Data Protection Authority: [enter state authority]

The First 72 Hours - Timeline

Hours 0-1: Detection and Initial Response

• 0:00 - Alert received (SIEM, user, external report)
• 0:05 - IT administrator notified - Initial assessment
• 0:15 - CISO/IT director notified
• 0:20 - Determine scope: How many systems? What data?
• 0:30 - Decision: Severity level P1/P2/P3/P4?
• 0:45 - P1/P2: Convene crisis team, notify management
• 1:00 - Initial containment measures (isolate affected systems)

Hours 1-4: Containment

First goal: Stop the spread, don’t fix it!

For ransomware/malware:

• Disconnect affected systems from the network (physically disconnect cables)
• DO NOT shut down (forensic data in RAM will be lost)
• Back up logs BEFORE isolating systems
• Change passwords for all affected accounts
• Lock admin accounts - recreate with new credentials

For compromised accounts:

• Deactivate account (do not delete: forensic evidence)
• Invalidate all sessions
• Check all of the user’s devices
• What data did the account have access to? - Define scope

Hours 4-24: GDPR Reporting Obligation

GDPR Art. 33 deadlines:

• 24h: Initial assessment of whether personal data is affected
• 72h: If affected - report to data protection authority

Report form includes:

• Type of incident (ransomware, data breach, etc.)
• Categories and approximate number of affected individuals
• Likely consequences
• Measures taken

If unclear: a preliminary notification ("precautionary notification") is possible - "Incident detected, scope still unclear, update to follow."

Hours 24-72: NIS2 reporting obligation (for affected companies)

NIS2 Art. 23 deadlines:

• 24h: Early warning to BSI - incident type, initial assessment, no full report required
• 72h: Full report - cause (if known), impact and countermeasures
• 30 days: Final report

Reporting office: BSI / CERT-Bund (online portal)

Forensics: Securing evidence

Important: Secure forensic evidence before systems are cleaned or reset.

Memory (RAM):

• Memory dump before shutdown (contains running processes, credentials)
• Tools: DumpIt, WinPmem, LiME (Linux)

Hard drives:

• Forensic copy (bit-for-bit copy) BEFORE cleaning
• Hash value (SHA256) for chain of evidence
• Tools: dd, FTK Imager, EnCase

Logs:

• Windows Event Logs (System, Security, Application)
• PowerShell logs (Module Logging, Script Block Logging)
• Firewall logs, proxy logs, DNS logs
• SIEM export for the last 30-90 days

Network:

• All outbound connections from the last few hours/days
• PCAP captures if available

Business Continuity During the Incident

Communication:

• How does the company communicate during the incident?
• Email may be compromised - Signal/Threema as a backup?
• External communication: who speaks with customers, the press, and authorities?

Operations:

• Can critical processes continue to run manually?
• Which systems are critical vs. non-critical?
• Are there hot-standby systems?

Backup:

• When was the last clean backup?
• Have backups also been encrypted by the attacker?
• Recovery Time Objective (RTO): When must operations be back up and running?

Tabletop Exercise - Practicing Incident Response

The best preparation is practice - before things get serious:

Format: Duration 2-4 hours, participants from IT, management, communications, and legal. Scenario is read aloud; team discusses the response.

Sample Scenario: "Monday, 6:30 a.m. Employees call in: all servers display encrypted files and a ransom demand. What will you do in the next 60 minutes?"

Evaluation:

• How long did it take until the first alert?
• Were all contacts reachable?
• Did everyone know their role?
• What gaps in the plan were discovered?

Lessons Learned and Continuous Improvement

After each incident (P1-P3):

Post-Incident Review (within 1-2 weeks):

• Reconstruct the incident timeline
• Root Cause Analysis: How did the attacker gain access?
• What worked? What didn’t?
• What controls could have prevented this or detected it earlier?

Typical findings:

• "MFA was missing on the VPN - Immediate action: Implement MFA"
• "SIEM had no rule for this attack - Create new SIEM rule"
• "Backup restoration took 8 hours - RTO not met - Revise backup strategy"
• "Communication paths unclear - Update RACI"

IT incident management is not a one-time project - it is a continuous process consisting of preparation, practice, response, and improvement.

Preparation (1 week in advance)

• Define the objective: What do we want to test?
• Invite participants: IT, management, HR, Legal, Marketing, external partners if applicable
• Select scenario: Ransomware attack (most common use case)
• Distribute materials: IR plan, contact lists, BCP documents
• Brief the moderator: Prepare injection cards

Preparation

• Define objective and scope (What are we testing? What are we NOT testing?)
• Participants: all relevant roles (not just IT!)
• Select scenario: ransomware / data breach / DDoS / insider threat
• Write injection cards (5-8 are sufficient for a 4-hour exercise)
• Facilitator: internal or external (external facilitator = more objective)
• Materials: IR plan, emergency checklist, insurance policy
• Set timeframe (4-6 hours for a medium-sized TTX)