Skip to content

Incident Response Planning

Jump to bottom
Alex Stojcic edited this page Apr 3, 2025 · 3 revisions

Incident Response Planning

A robust incident response plan is critical to managing security breaches effectively. This guide covers comprehensive incident response planning for web applications, focusing on preparation, detection, containment, eradication, recovery, and lessons learned.

Incident Response Framework

NIST Incident Response Lifecycle

The NIST SP 800-61 framework provides a structured approach to incident response with four main phases:

  1. Preparation - Develop and document security policies, response procedures, and controls
  2. Detection & Analysis - Identify and investigate suspicious activities
  3. Containment, Eradication & Recovery - Limit damage, eliminate threat presence, restore systems
  4. Post-Incident Activity - Document findings, improve processes, strengthen controls

1. Preparation Phase

Incident Response Team Structure

Role Responsibilities Personnel
Incident Response Manager Oversees response process, coordinates team activities Security Manager or CISO
Technical Lead Directs technical investigation and remediation Senior Security Engineer
Security Analysts Perform investigation and remediation activities Security Team Members
Communications Lead Handles internal/external communications PR or Communications Director
Legal Counsel Advises on legal obligations and liabilities In-house or External Counsel
Executive Sponsor Makes high-level decisions, approves resources CIO/CTO/CEO

External Communication Templates

Customer Data Breach Notification Example

Subject: Important Security Notice - Data Breach Notification

Dear [Customer Name],


We are writing to inform you of a data security incident that may have involved your personal information.


WHAT HAPPENED:
On [Date], we detected unauthorized access to our [system name] which contains customer information. We immediately launched an investigation with the assistance of external cybersecurity experts and law enforcement.


WHAT INFORMATION WAS INVOLVED:
Based on our investigation, the following information may have been accessed:


    

  • [List of data elements, e.g., name, email address, etc.]
    • 

  • [...]
    • 



WHAT WE ARE DOING:
We have taken immediate steps to address this incident:


    

  1. We secured our systems and eliminated the unauthorized access
    2. 

  2. We engaged cybersecurity experts to conduct a thorough investigation
    3. 

  3. We are implementing additional security measures
    4. 

  4. We are working with law enforcement
    5. 



WHAT YOU CAN DO:
We recommend you take the following precautionary measures:


    

  1. Monitor your accounts for suspicious activity
    2. 

  2. Change passwords for any accounts that shared the same password
    3. 

  3. Be vigilant against phishing attempts claiming to be related to this incident
    4. 

  4. [Additional specific recommendations based on the data involved]
    5. 



FOR MORE INFORMATION:
We have established a dedicated assistance line at [phone number], available Monday-Friday, 9 AM - 5 PM. You can also email us at [security@example.com] with questions.


We deeply regret this incident and the concern it may cause you. Protecting your information is a top priority, and we are committed to maintaining your trust.


Sincerely,


[Name]
Chief Information Security Officer
[Company Name]

Press Release Template

FOR IMMEDIATE RELEASE
[Company Name] Addresses Cybersecurity Incident

[City, Date] - [Company Name] recently detected and addressed a cybersecurity incident involving unauthorized access to certain systems. Upon discovery, we immediately implemented our incident response plan, engaged leading cybersecurity experts, and notified law enforcement.


Our investigation has determined that an unauthorized party gained access to [brief description of affected systems] between [date range]. The information potentially impacted includes [general description of data types, not specifics].


"We take the protection of information very seriously and regret any concern this incident may cause," said [Executive Name], [Title] of [Company Name]. "We moved quickly to address the situation and have taken steps to further enhance our security measures."


[Company Name] has begun notifying potentially affected individuals and is offering [credit monitoring/identity protection services] at no cost. We have also established a dedicated call center to answer questions about the incident.


For more information, visit [website URL] or call [phone number].


About [Company Name]:
[Standard boilerplate about the company]


Media Contact:
[Name, Title]
[Phone, Email]

Tabletop Exercise Scenarios

Web Application Breach Scenario

Scenario Description: A critical vulnerability in your web application has been exploited, potentially exposing customer data. Your security monitoring system detected unusual database queries from the application server at 02:15 AM.

Initial Information:

  • Alert triggered: "Suspicious SQL queries detected from web application"
  • Application affected: Customer portal
  • Database containing PII potentially accessed
  • No immediately apparent data exfiltration
  • Application logs show unauthorized admin login

Exercise Injects:

  1. T+0 hours: Security alert detected

    • Task: Assemble incident response team
    • Decision: Initial classification and notification

  2. T+1 hour: Investigation finds SQL injection vulnerability

    • Task: Assess scope and impact
    • Decision: Containment strategy

  3. T+2 hours: Evidence of data access discovered

    • Task: Determine regulatory requirements
    • Decision: External communication approach

  4. T+4 hours: Media inquires about a potential breach

    • Task: Draft initial statements
    • Decision: Information disclosure strategy

  5. T+8 hours: Security fix ready for deployment

    • Task: Plan recovery procedures
    • Decision: Deployment timing and validation process

  6. T+24 hours: Post-incident review

    • Task: Document timeline and response effectiveness
    • Decision: Identify improvements for future incidents

Ransom Demand Scenario

Scenario Description: Your DevOps team discovers that an unauthorized actor has gained access to your CI/CD pipeline and deployed malicious code that encrypts application data. They've left a ransom note demanding payment for decryption.

Exercise Injects:

  1. T+0 hours: Discovery of encryption and ransom note

    • Task: Assess initial impact
    • Decision: Team activation and escalation

  2. T+2 hours: Forensic analysis reveals compromised developer credentials

    • Task: Contain the compromise
    • Decision: Additional system isolation needed?

  3. T+4 hours: Ransom countdown timer appears on affected systems

    • Task: Evaluate ransom payment considerations
    • Decision: Communication with attacker?

  4. T+6 hours: System restore capabilities assessment

    • Task: Identify backup integrity
    • Decision: Recovery strategy selection

  5. T+12 hours: Legal team provides regulatory guidance

    • Task: Prepare notification documents
    • Decision: Notification timing and content

  6. T+36 hours: Post-incident phase

    • Task: Root cause identification
    • Decision: Security improvements prioritization

Additional Resources

# Incident Response Planning

A robust incident response plan is critical to managing security breaches effectively. This guide covers comprehensive incident response planning for web applications, focusing on preparation, detection, containment, eradication, recovery, and lessons learned.

Incident Response Framework

NIST Incident Response Lifecycle

The NIST SP 800-61 framework provides a structured approach to incident response with four main phases:

  1. Preparation - Develop and document security policies, response procedures, and controls
  2. Detection & Analysis - Identify and investigate suspicious activities
  3. Containment, Eradication & Recovery - Limit damage, eliminate threat presence, restore systems
  4. Post-Incident Activity - Document findings, improve processes, strengthen controls

1. Preparation Phase

Incident Response Team Structure

Role Responsibilities Personnel
Incident Response Manager Oversees response process, coordinates team activities Security Manager or CISO
Technical Lead Directs technical investigation and remediation Senior Security Engineer
Security Analysts Perform investigation and remediation activities Security Team Members
Communications Lead Handles internal/external communications PR or Communications Director
Legal Counsel Advises on legal obligations and liabilities In-house or External Counsel
Executive Sponsor Makes high-level decisions, approves resources CIO/CTO/CEO

Documentation & Resources

  1. Incident Response Plan Document

    • Team structure and contact information
    • Incident classification criteria
    • Response procedures for each incident type
    • Escalation procedures
    • Communication templates
    • Evidence collection guidelines

  2. Playbooks for Common Incidents

    • Web application breach
    • Data exfiltration
    • Ransomware
    • DDoS attack
    • Account compromise

  3. Technical Resources

    • Investigation tools inventory
    • System architecture diagrams
    • Network maps
    • Data flow diagrams
    • Asset inventory
    • Logging systems access

Secure Communication Channels

Establish secure communication methods that are separate from potentially compromised systems:

Primary Channel: Encrypted messaging platform (e.g., Signal, Microsoft Teams)
Backup Channel: Conference bridge with PIN access
Tertiary Channel: Corporate mobile phones (voice calls)

Incident Classification Matrix

Severity Criteria Response Time Escalation
Critical - System compromise with data breach
- Production system outage
- Financial/reputational impact		 Immediate (< 1 hour) Executive team, legal, PR
High - Limited system compromise
- Customer-facing issue
- Regulatory implications		 < 4 hours Department heads, security team
Medium - Suspicious activity
- Non-critical system affected
- No immediate data loss		 < 24 hours Security team, affected system owners
Low - Policy violation
- Isolated incident
- Minimal system impact		 < 72 hours Security analyst, system owner

2. Detection & Analysis Phase

Detection Sources and Monitoring

  1. Log Sources to Monitor:

    • Web application logs
    • Network traffic logs
    • Database audit logs
    • Authentication logs
    • API access logs
    • System logs
    • Cloud platform logs
    • WAF alerts

  2. SIEM Implementation:

# Example ELK Stack Configuration (elasticsearch.yml)
xpack.security.enabled: true
xpack.monitoring.enabled: true
xpack.watcher.enabled: true

# Example Alert Rule (Watcher)
{
  "trigger": {
    "schedule": {
      "interval": "5m"
    }
  },
  "input": {
    "search": {
      "request": {
        "indices": ["web-logs-*"],
        "body": {
          "query": {
            "bool": {
              "must": [
                {"match": {"response_code": 403}},
                {"range": {"@timestamp": {"gte": "now-5m"}}}
              ]
            }
          },
          "size": 0,
          "aggs": {
            "ips": {
              "terms": {"field": "client_ip"},
              "aggs": {
                "paths": {"terms": {"field": "uri_path"}}
              }
            }
          }
        }
      }
    }
  },
  "condition": {
    "script": {
      "source": "return ctx.payload.aggregations.ips.buckets.any(bucket -> bucket.doc_count > 20)"
    }
  },
  "actions": {
    "notify_security": {
      "webhook": {
        "scheme": "https",
        "host": "alerts.example.com",
        "port": 443,
        "method": "post",
        "path": "/api/security_alerts",
        "body": "{ \"alert\": \"Potential brute force attack detected from multiple IPs\" }"
      }
    }
  }
}
  1. Detection Examples:

Example suspicious patterns in Apache logs:

# SQL Injection attempt
192.168.1.100 - - [10/Apr/2023:13:45:15 +0000] "GET /search?q=test'%20OR%201=1-- HTTP/1.1" 200 1453

# Path traversal attempt
192.168.1.101 - - [10/Apr/2023:14:22:43 +0000] "GET /download?file=../../../etc/passwd HTTP/1.1" 403 291

# XSS attempt
192.168.1.102 - - [10/Apr/2023:15:10:22 +0000] "POST /comment HTTP/1.1" 200 342
POST data: comment=<script>alert(document.cookie)</script>

Initial Assessment Process

  1. Triage Checklist:

    • Verify alert is not a false positive
    • Determine affected systems and data
    • Assess initial impact and scope
    • Identify potential attack vector
    • Document initial findings

  2. Initial Response Actions:

    • Create incident ticket
    • Assign incident handler
    • Establish secure communications
    • Begin incident log
    • Make initial severity classification

  3. Evidence Collection:

# Capture volatile memory from affected server
sudo lime -format raw -path /mnt/evidence/server1-mem.lime

# Create disk image
sudo dd if=/dev/sda of=/mnt/evidence/server1-disk.img bs=64K conv=noerror,sync status=progress

# Collect and hash logs
sudo tar czf /mnt/evidence/logs.tar.gz /var/log/
sha256sum /mnt/evidence/logs.tar.gz > /mnt/evidence/logs.tar.gz.sha256

# Preserve network traffic
sudo tcpdump -i eth0 -s 0 -w /mnt/evidence/capture.pcap 'port 80 or port 443'

3. Containment, Eradication & Recovery

Containment Strategies

Immediate Containment Actions

For a compromised web application:

# Isolate affected server (network level)
sudo iptables -I INPUT -s 0.0.0.0/0 -j DROP
sudo iptables -I OUTPUT -d 0.0.0.0/0 -j DROP
sudo iptables -I INPUT -s 10.0.0.0/8 -j ACCEPT
sudo iptables -I OUTPUT -d 10.0.0.0/8 -j ACCEPT

# Block suspicious IP addresses at WAF/firewall
aws waf update-ip-set \
  --ip-set-id b02a5c7e-990b-4220-9cc1-3dfa5f0c5316 \
  --change-token 12cs231v1-57dz-5c10-b8e5-9c3ad8sa98as6 \
  --updates 'Action=INSERT,IPSetDescriptor={Type=IPV4,Value=192.168.1.100/32}'

# Take affected endpoints offline
kubectl scale deployment frontend-app --replicas=0
kubectl scale deployment frontend-app --replicas=3

# Rotate compromised credentials
aws secretsmanager rotate-secret --secret-id production/db/credentials

Short-term Containment

Deploy virtual patches at WAF level:

<!-- WAF rule to block SQL injection pattern -->
<rule id="1000234">
  <match>
    <param>REQUEST_URI</param>
    <pattern>.*[\"\'`;](\s*)(union|select|insert|update|delete).*</pattern>
  </match>
  <action>BLOCK</action>
</rule>

<!-- WAF rule to block path traversal -->
<rule id="1000235">
  <match>
    <param>REQUEST_URI</param>
    <pattern>.*\.\./.*</pattern>
  </match>
  <action>BLOCK</action>
</rule>

Eradication Procedures

  1. Malware Removal:
# Scan for malicious files
sudo freshclam
sudo clamscan -r --remove=yes /var/www/

# Check for unauthorized cron jobs
sudo crontab -l
sudo find /etc/cron* -type f -ls

# Inspect running processes
sudo ps aux | grep -v "^root\|^www-data"
  1. Remove backdoors and unauthorized access:
# Check for unauthorized SSH keys
sudo find /home -name "authorized_keys" -exec cat {} \;

# Look for unauthorized users
sudo grep "x:0:" /etc/passwd

# Check for unauthorized sudo access
sudo cat /etc/sudoers
sudo ls -la /etc/sudoers.d/

# Reset all web application user sessions
redis-cli FLUSHDB

Recovery Process

  1. System Recovery Checklist:

    • Restore from known clean backups
    • Apply all security patches
    • Reset all credentials
    • Restore services incrementally
    • Implement additional monitoring
    • Verify system integrity

  2. Clean Rebuild Process:

# Deploy clean application image
docker pull company/webapp:latest
docker-compose up -d

# Deploy with patches applied
kubectl apply -f deployment-patched.yaml

# Verify integrity of deployment
curl -s https://webapp.example.com/health | jq
  1. Verification Steps:
# Verify application security
cd /var/www/html
npm audit

# Run vulnerability scan
nmap -sV --script=vuln app-server.internal

# Test security controls
curl -I https://webapp.example.com/admin
# Should return 401/403 not 200

# Verify logging is working
logger -t TEST "Security verification test"
grep "Security verification test" /var/log/syslog

4. Post-Incident Activities

Post-Mortem Analysis Template

# Security Incident Post-Mortem

## Incident Summary
- **Date**: YYYY-MM-DD
- **Duration**: XX hours
- **Severity**: Critical/High/Medium/Low
- **Systems Affected**: List of affected systems
- **Data Impacted**: Types of data potentially compromised

## Timeline
- **YYYY-MM-DD HH:MM** - Initial detection
- **YYYY-MM-DD HH:MM** - Incident response team activated
- **YYYY-MM-DD HH:MM** - Containment measures implemented
- **YYYY-MM-DD HH:MM** - Root cause identified
- **YYYY-MM-DD HH:MM** - Systems restored
- **YYYY-MM-DD HH:MM** - Incident closed

## Root Cause Analysis
Detailed explanation of how the incident occurred, including:
- Attack vector
- Vulnerabilities exploited
- Missed detection opportunities

## Impact Assessment
- **Technical Impact**: Systems downtime, data loss
- **Business Impact**: Financial costs, reputation damage
- **User Impact**: Number of affected users/customers

## Response Assessment
- What went well
- What could have been improved
- Communication effectiveness
- Tool effectiveness

## Action Items
| Action | Owner | Priority | Due Date | Status |
|--------|-------|----------|----------|--------|
| Deploy WAF rule to block SQL injection | Security Team | High | YYYY-MM-DD | Completed |
| Implement input validation in search function | Development | High | YYYY-MM-DD | In Progress |
| Update incident response playbook | IR Team | Medium | YYYY-MM-DD | Pending |
| Conduct additional developer security training | Training | Medium | YYYY-MM-DD | Scheduled |

## Lessons Learned
Key takeaways and preventive measures for the future.

Root Cause Analysis Techniques

5 Whys Example

For a SQL Injection Attack:

  1. Why was there a data breach? Because attackers accessed the database.
  2. Why could attackers access the database? Because they exploited a SQL injection vulnerability.
  3. Why was there a SQL injection vulnerability? Because input validation was missing in the search feature.
  4. Why was input validation missing? Because the developer used string concatenation for SQL queries.
  5. Why did the developer use string concatenation? Because they were unaware of parameterized queries and the code review didn't catch it.

Root Cause Solution: Implement developer security training and add automated SAST checks for SQL injection.

Fishbone Diagram Example

                    ┌─────────────┐
 People             │             │              Technology
 ┌─────────────────►│             │◄─────────────────────┐
 │                  │             │                      │
 │                  │             │                      │
 │                  │  SQL        │                      │
 │                  │  Injection  │                      │
 │                  │  Attack     │                      │
 │                  │             │                      │
 │                  │             │                      │
 └─────────────────►│             │◄─────────────────────┘
 Process            │             │              Environment
                    └─────────────┘

People:
- Developer lacked security training
- Code reviewer missed vulnerability

Process:
- No security requirements in tickets
- Manual code review only

Technology:
- No WAF configured for SQL injection
- No real-time alerts for suspicious queries

Environment:
- Production database accessible from application server
- Excessive database user privileges

Incident Response Automation

Automated Response Scripts

Example Security Automation with AWS Lambda:

import boto3
import json
import re
import requests

def lambda_handler(event, context):
    # Parse GuardDuty finding
    finding = json.loads(event['Records'][0]['Sns']['Message'])
    
    if finding['detail']['type'] == 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration':
        # Extract compromised instance ID
        instance_id = finding['detail']['resource']['instanceDetails']['instanceId']
        
        # Isolate the instance
        isolate_instance(instance_id)
        
        # Revoke temporary credentials
        revoke_instance_credentials(instance_id)
        
        # Create incident ticket
        create_incident_ticket(finding)
        
        return {
            'statusCode': 200,
            'body': json.dumps(f'Response automated for {instance_id}')
        }

def isolate_instance(instance_id):
    ec2 = boto3.client('ec2')
    
    # Create isolation security group
    response = ec2.create_security_group(
        GroupName=f'ISOLATE-{instance_id}',
        Description=f'Isolation group for {instance_id}',
        VpcId='vpc-12345678'
    )
    
    isolation_group_id = response['GroupId']
    
    # Apply isolation group
    ec2.modify_instance_attribute(
        InstanceId=instance_id,
        Groups=[isolation_group_id]
    )
    
    print(f"Instance {instance_id} isolated with security group {isolation_group_id}")

def revoke_instance_credentials(instance_id):
    iam = boto3.client('iam')
    
    # Find and revoke temporary credentials associated with the instance
    # Simplified - in reality you'd need to identify the specific credentials
    
    # Example: List all instance profiles
    profiles = iam.list_instance_profiles()
    
    # Find attached profile for this instance
    ec2 = boto3.client('ec2')
    instance = ec2.describe_instances(InstanceIds=[instance_id])
    
    if 'IamInstanceProfile' in instance['Reservations'][0]['Instances'][0]:
        profile_arn = instance['Reservations'][0]['Instances'][0]['IamInstanceProfile']['Arn']
        profile_name = profile_arn.split('/')[-1]
        
        # Remove instance profile from instance
        ec2.disassociate_iam_instance_profile(
            InstanceId=instance_id,
            AssociationId=instance['Reservations'][0]['Instances'][0]['IamInstanceProfile']['AssociationId']
        )
        
        print(f"Removed IAM profile {profile_name} from instance {instance_id}")

def create_incident_ticket(finding):
    # Create ticket in your ticketing system (e.g., JIRA, ServiceNow)
    ticket_data = {
        'title': f"SECURITY INCIDENT: {finding['detail']['type']}",
        'description': f"GuardDuty finding: {finding['detail']['description']}\nAffected resource: {finding['detail']['resource']['instanceDetails']['instanceId']}",
        'priority': 'Critical',
        'assignee': 'security-team'
    }
    
    # Example API call to ticketing system
    response = requests.post(
        'https://ticketing.example.com/api/tickets',
        json=ticket_data,
        headers={
            'Authorization': 'Bearer YOUR_API_TOKEN',
            'Content-Type': 'application/json'
        }
    )
    
    print(f"Created incident ticket: {response.json()['ticketId']}")

SOAR Integration

Security Orchestration, Automation, and Response (SOAR) playbook example:

# Example SOAR playbook for web application attack

name: Web Application Attack Response
description: Automated response to detected web application attacks
triggers:
  - type: waf_alert
    conditions:
      alert_type: [sql_injection, xss, path_traversal]
      severity: [high, critical]

actions:
  - name: Gather_Attack_Data
    type: data_enrichment
    parameters:
      sources:
        - waf_logs
        - application_logs
        - web_server_logs
      timeframe: 30m
    
  - name: Analyze_Attack_Pattern
    type: analysis
    parameters:
      analyze_ip_reputation: true
      check_known_attack_patterns: true
      threshold: 3
    
  - name: Block_Attacker_IP
    type: response
    parameters:
      action: block_ip
      duration: 24h
      log: true
    condition: "{{Analyze_Attack_Pattern.reputation_score}} < 30"
    
  - name: Create_Incident_Ticket
    type: ticketing
    parameters:
      system: jira
      project: SECURITY
      title: "Web Application Attack: {{trigger.alert_type}}"
      description: "Attack detected from IP {{trigger.source_ip}} targeting {{trigger.target_url}}"
      priority: high
      
  - name: Notify_Security_Team
    type: notification
    parameters:
      channel: slack
      recipients: "#security-incidents"
      message: "Critical web application attack detected. Incident: {{Create_Incident_Ticket.ticket_id}}"
      
  - name: Assess_Data_Exposure
    type: investigation
    parameters:
      check_data_access: true
      affected_tables: "{{Gather_Attack_Data.potentially_accessed_data}}"
      
  - name: Escalate_If_Data_Breach
    type: escalation
    parameters:
      condition: "{{Assess_Data_Exposure.data_accessed}} == true"
      notify_roles: [ciso, legal, dpo]
      message: "Potential data breach detected. Immediate response required."

Compliance and Reporting

Regulatory Requirements

Regulation Incident Reporting Requirements Timeline
GDPR Report personal data breaches to supervisory authority Within 72 hours
HIPAA Report breaches of unsecured PHI 60 days (to individuals)
60 days (to HHS for smaller breaches)
60 days (to media for larger breaches)
PCI DSS Report cardholder data breaches to payment card brands As soon as possible
CCPA/CPRA Notify affected California residents of breaches Within 45 days
NIS2 Directive Report significant incidents to competent authorities Within 24 hours (initial notification)
Within 72 hours (full report)

External Communication Templates

Customer Data Breach Notification Example

Subject: Important Security Notice - Data Breach Notification

Dear [Customer Name],

We are writing to inform you of a data security incident that may have involved your personal information.

WHAT HAPPENED:
On [Date], we detected unauthorized access to our [system name] which contains customer information. We immediately launched an investigation with the assistance of external cybersecurity experts and law enforcement.

WHAT INFORMATION WAS INVOLVED:
Based on our investigation, the following information may have been accessed:
- [List of data elements, e.g., name, email address, etc.]
- [...]

WHAT WE ARE DOING:
We have taken immediate steps to address this incident:
1. We secured our systems and eliminated the unauthorized access
2. We engaged cybersecurity experts to conduct a thorough investigation
3. We are implementing additional security measures
4. We are working with law enforcement

WHAT YOU CAN DO:
We recommend you take the following precautionary measures:
1. Monitor your accounts for suspicious activity
2. Change passwords for any accounts that shared the same password
3. Be vigilant against phishing attempts claiming to be related to this incident
4. [Additional specific recommendations based on the data involved]

FOR MORE INFORMATION:
We have established a dedicated assistance line at [phone number], available Monday-Friday, 9 AM - 5 PM. You can also email us at [security@example.com] with questions.

We deeply regret this incident and the concern it may cause you. Protecting your information is a top priority, and we are committed to maintaining your trust.

Sincerely,

[Name]
Chief Information Security Officer
[Company Name]

Press Release Template

FOR IMMEDIATE RELEASE
[Company Name] Addresses Cybersecurity Incident

[City, Date] - [Company Name] recently detected and addressed a cybersecurity incident involving unauthorized access to certain systems. Upon discovery, we immediately implemented our incident response plan, engaged leading cybersecurity experts, and notified law enforcement.

Our investigation has determined that an unauthorized party gained access to [brief description of affected systems] between [date range]. The information potentially impacted includes [general description of data types, not specifics].

"We take the protection of information very seriously and regret any concern this incident may cause," said [Executive Name], [Title] of [Company Name]. "We moved quickly to address the situation and have taken steps to further enhance our security measures."

[Company Name] has begun notifying potentially affected individuals and is offering [credit monitoring/identity protection services] at no cost. We have also established a dedicated call center to answer questions about the incident.

For more information, visit [website URL] or call [phone number].

About [Company Name]:
[Standard boilerplate about the company]

Media Contact:
[Name, Title]
[Phone, Email]

Tabletop Exercise Scenarios

Web Application Breach Scenario

Scenario Description: A critical vulnerability in your web application has been exploited, potentially exposing customer data. Your security monitoring system detected unusual database queries from the application server at 02:15 AM.

Initial Information:

  • Alert triggered: "Suspicious SQL queries detected from web application"
  • Application affected: Customer portal
  • Database containing PII potentially accessed
  • No immediately apparent data exfiltration
  • Application logs show unauthorized admin login

Exercise Injects:

  1. T+0 hours: Security alert detected

    • Task: Assemble incident response team
    • Decision: Initial classification and notification

  2. T+1 hour: Investigation finds SQL injection vulnerability

    • Task: Assess scope and impact
    • Decision: Containment strategy

  3. T+2 hours: Evidence of data access discovered

    • Task: Determine regulatory requirements
    • Decision: External communication approach

  4. T+4 hours: Media inquires about a potential breach

    • Task: Draft initial statements
    • Decision: Information disclosure strategy

  5. T+8 hours: Security fix ready for deployment

    • Task: Plan recovery procedures
    • Decision: Deployment timing and validation process

  6. T+24 hours: Post-incident review

    • Task: Document timeline and response effectiveness
    • Decision: Identify improvements for future incidents

Ransom Demand Scenario

Scenario Description: Your DevOps team discovers that an unauthorized actor has gained access to your CI/CD pipeline and deployed malicious code that encrypts application data. They've left a ransom note demanding payment for decryption.

Exercise Injects:

  1. T+0 hours: Discovery of encryption and ransom note

    • Task: Assess initial impact
    • Decision: Team activation and escalation

  2. T+2 hours: Forensic analysis reveals compromised developer credentials

    • Task: Contain the compromise
    • Decision: Additional system isolation needed?

  3. T+4 hours: Ransom countdown timer appears on affected systems

    • Task: Evaluate ransom payment considerations
    • Decision: Communication with attacker?

  4. T+6 hours: System restore capabilities assessment

    • Task: Identify backup integrity
    • Decision: Recovery strategy selection

  5. T+12 hours: Legal team provides regulatory guidance

    • Task: Prepare notification documents
    • Decision: Notification timing and content

  6. T+36 hours: Post-incident phase

    • Task: Root cause identification
    • Decision: Security improvements prioritization

Additional Resources

Clone this wiki locally