# Incident Response Runbook **VantagePoint Networks** --- | Field | Value | |--------------------|--------------------------------------------| | Document ID | VPN-IR-RB-001 | | Version | 1.0 | | Classification | | | Author | | | Approved By | | | Effective Date | | | Review Date | | | Organisation | | | Department | | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [References and Standards](#2-references-and-standards) 3. [Roles and Responsibilities](#3-roles-and-responsibilities) 4. [Severity Classification Matrix](#4-severity-classification-matrix) 5. [Incident Response Lifecycle](#5-incident-response-lifecycle) 6. [Playbook 1: DDoS Attack](#6-playbook-1-ddos-attack) 7. [Playbook 2: Ransomware](#7-playbook-2-ransomware) 8. [Playbook 3: Unauthorised Access](#8-playbook-3-unauthorised-access) 9. [Playbook 4: Data Breach](#9-playbook-4-data-breach) 10. [Playbook 5: Network Outage](#10-playbook-5-network-outage) 11. [Communication Templates](#11-communication-templates) 12. [Escalation Matrix](#12-escalation-matrix) 13. [Post-Incident Review Template](#13-post-incident-review-template) 14. [Appendix A: Tools List](#appendix-a-tools-list) 15. [Appendix B: Evidence Checklist](#appendix-b-evidence-checklist) 16. [Appendix C: Chain of Custody Form](#appendix-c-chain-of-custody-form) --- ## 1. Purpose and Scope ### 1.1 Purpose This Incident Response Runbook provides with a structured, repeatable framework for detecting, responding to, containing, and recovering from cybersecurity and infrastructure incidents. It is aligned with NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide) and designed to minimise business impact, preserve evidence, and ensure regulatory compliance. ### 1.2 Scope This runbook applies to: - All information systems owned or operated by - All employees, contractors, and third-party service providers - All environments: production, staging, development, and disaster recovery - Cloud infrastructure (), on-premises data centres, and hybrid deployments - Network infrastructure including firewalls, switches, routers, and wireless access points ### 1.3 Out of Scope - Physical security incidents (refer to ) - Health and safety emergencies (refer to ) - Business continuity and disaster recovery beyond IT scope (refer to ) ### 1.4 Document Maintenance This document shall be reviewed or after any P1/P2 incident, whichever comes first. The is responsible for maintaining and distributing updates. --- ## 2. References and Standards | Reference | Description | |------------------------------------|------------------------------------------------------| | NIST SP 800-61 Rev. 2 | Computer Security Incident Handling Guide | | NIST SP 800-53 Rev. 5 | Security and Privacy Controls | | ISO/IEC 27001:2022 | Information Security Management Systems | | ISO/IEC 27035 | Information Security Incident Management | | MITRE ATT&CK Framework | Adversary Tactics, Techniques, and Procedures | | GDPR / UK GDPR | Data Protection Regulations | | | Sector-specific compliance requirements | | | Organisation security policy | --- ## 3. Roles and Responsibilities ### 3.1 Incident Response Team (IRT) | Role | Name / Team | Responsibilities | |---------------------------|---------------------------|---------------------------------------------------------------------| | Incident Commander (IC) | | Overall incident coordination, decision authority | | Deputy IC | | Assumes IC role if primary is unavailable | | Security Analyst (L1) | | Initial triage, alert validation, data collection | | Security Analyst (L2) | | Deep-dive investigation, forensic analysis | | Security Analyst (L3) | | Advanced threat hunting, malware analysis | | Network Engineer | | Network isolation, traffic analysis, firewall changes | | Systems Administrator | | Server isolation, system recovery, patching | | Communications Lead | | Internal/external communications, media handling | | Legal Counsel | | Regulatory obligations, law enforcement liaison | | Executive Sponsor | | Strategic decisions, resource authorisation | | Third-Party IR Provider | | External forensic support, surge capacity | ### 3.2 RACI Matrix | Activity | IC | L1 | L2 | L3 | Network | SysAdmin | Comms | Legal | Exec | |-----------------------------------|-----|-----|-----|-----|---------|----------|-------|-------|------| | Alert triage | I | R | C | C | I | I | - | - | - | | Incident declaration | R | I | C | C | I | I | I | I | I | | Evidence collection | A | R | R | R | C | C | - | I | - | | Containment actions | A | C | R | R | R | R | I | I | I | | External communication | A | - | - | - | - | - | R | C | I | | Regulatory notification | A | - | - | - | - | - | C | R | I | | Recovery execution | A | C | C | C | R | R | I | - | I | | Post-incident review | R | C | C | C | C | C | C | C | I | **Key:** R = Responsible, A = Accountable, C = Consulted, I = Informed --- ## 4. Severity Classification Matrix ### 4.1 Priority Definitions | Priority | Name | Description | Examples | |----------|------------|---------------------------------------------------------------------------------------------------|-------------------------------------------------------------------| | P1 | Critical | Complete loss of critical business service, active data breach, or confirmed destructive attack | Ransomware encryption active, mass data exfiltration, core network down | | P2 | High | Significant degradation of critical service, confirmed compromise with limited spread | Single server compromised, partial service outage, targeted phishing success | | P3 | Medium | Non-critical system affected, suspicious activity under investigation | Malware on isolated endpoint, failed brute force attempts, minor outage | | P4 | Low | Informational alerts, policy violations, minor anomalies | Vulnerability scan findings, blocked phishing attempt, log anomalies | ### 4.2 Response Time Requirements | Priority | Acknowledge | Triage Complete | Containment Target | Update Frequency | Resolution Target | |----------|-----------------|-----------------|---------------------|-----------------------|---------------------| | P1 | 15 minutes | 30 minutes | 1 hour | Every 30 minutes | 4 hours | | P2 | 30 minutes | 1 hour | 4 hours | Every 2 hours | 24 hours | | P3 | 2 hours | 4 hours | 24 hours | Every 8 hours | 72 hours | | P4 | 8 hours | 24 hours | 72 hours | Daily | 5 business days | ### 4.3 Escalation Triggers Escalation from a lower to higher priority occurs when: - The blast radius expands beyond initial assessment - Additional systems or data categories are confirmed affected - Threat actor activity is confirmed as ongoing - Regulatory notification thresholds may be met - Media or public attention is identified - Business leadership determines elevated business impact --- ## 5. Incident Response Lifecycle Based on NIST SP 800-61 Rev. 2, the lifecycle consists of six phases: ### 5.1 Phase 1: Preparation **Objective:** Establish and maintain the capability to respond to incidents effectively. Actions: 1. Maintain up-to-date asset inventory (refer to ) 2. Ensure all IRT members have completed annual incident response training 3. Conduct tabletop exercises quarterly and full simulations annually 4. Verify jump bag contents monthly (see Appendix A) 5. Validate out-of-band communication channels () 6. Ensure forensic workstations are operational and tools are current 7. Maintain retainer agreement with 8. Review and update this runbook per the maintenance schedule 9. Validate backup integrity through scheduled restore tests 10. Ensure threat intelligence feeds are active and integrated with SIEM ### 5.2 Phase 2: Detection and Analysis **Objective:** Identify potential incidents and determine their nature, scope, and impact. Data Sources: - SIEM: - EDR: - NDR: - Firewall logs: - Cloud security: - Email gateway: - Threat intelligence: - User reports: Detection Workflow: 1. Alert received or anomaly identified 2. L1 analyst validates alert (true positive vs. false positive) 3. If true positive, create incident ticket in with: - Timestamp (UTC) - Affected systems (hostnames, IPs) - Alert source and rule that fired - Initial severity assessment - Affected data classification 4. Assign initial priority using the matrix in Section 4 5. Notify Incident Commander if P1 or P2 6. Begin evidence preservation immediately (see Appendix B) 7. Document all actions in the incident timeline ### 5.3 Phase 3: Containment **Objective:** Limit the scope and impact of the incident. Short-Term Containment (immediate): - Isolate affected endpoints from the network (disable switch port, quarantine in EDR) - Block malicious IPs/domains at perimeter firewall and DNS - Disable compromised user accounts - Revoke compromised API keys or tokens - Enable enhanced logging on adjacent systems - Preserve volatile evidence before containment where possible Long-Term Containment (sustained): - Move affected systems to isolated VLAN () - Deploy temporary monitoring on adjacent network segments - Apply emergency patches if a known vulnerability is being exploited - Implement additional access controls (MFA enforcement, conditional access) - Coordinate with for cloud-specific containment ### 5.4 Phase 4: Eradication **Objective:** Remove the threat and its artefacts from the environment. Actions: 1. Identify and remove all malware, backdoors, and persistence mechanisms 2. Reset credentials for all affected accounts (including service accounts) 3. Patch exploited vulnerabilities across all affected and adjacent systems 4. Remove unauthorised accounts or access modifications 5. Validate removal using IOC scans across the full environment 6. Update firewall rules and detection signatures with new IOCs 7. Confirm eradication with a secondary scan using an independent tool ### 5.5 Phase 5: Recovery **Objective:** Restore systems to normal operation and validate their integrity. Actions: 1. Restore systems from verified clean backups (verify backup integrity hashes) 2. Rebuild compromised systems from gold images where possible 3. Reintroduce systems to the network incrementally, starting with least critical 4. Implement enhanced monitoring for days 5. Validate system functionality against baseline configuration 6. Confirm with business owners that services are operating normally 7. Remove temporary containment measures only after validation 8. Update CMDB and asset inventory to reflect any changes ### 5.6 Phase 6: Lessons Learned **Objective:** Improve future incident response capability based on experience. Actions: 1. Conduct post-incident review within of incident closure 2. Complete the Post-Incident Review Template (Section 13) 3. Identify gaps in detection, response, and recovery 4. Create action items with owners and deadlines 5. Update this runbook with any procedural improvements 6. Share sanitised findings with the broader security community if appropriate 7. Update training materials to incorporate lessons learned 8. Brief executive leadership on findings and recommendations --- ## 6. Playbook 1: DDoS Attack ### 6.1 Description A Distributed Denial-of-Service (DDoS) attack aims to overwhelm network infrastructure, servers, or applications with malicious traffic, rendering services unavailable to legitimate users. ### 6.2 Severity Initial: P2 (escalate to P1 if customer-facing services are impacted for more than minutes) ### 6.3 Detection Indicators - Sudden spike in inbound traffic volume exceeding baseline by >300% - Increased latency or timeouts on public-facing services - Firewall or load balancer connection table exhaustion alerts - ISP notification of volumetric attack - CDN rate limiting or scrubbing centre activation - Unusual geographic distribution of source traffic ### 6.4 Triage Steps 1. Confirm attack is in progress (not a legitimate traffic spike such as marketing campaign) 2. Identify attack type: volumetric, protocol, or application layer 3. Identify target: IP address, service, URL, or API endpoint 4. Determine current attack bandwidth and packet rate 5. Assess business impact: which services are degraded or offline? ### 6.5 Containment and Response 1. Activate DDoS mitigation service () 2. Enable upstream scrubbing via ISP () or CDN () 3. Implement rate limiting and geo-blocking rules at the edge 4. Enable BGP blackhole routing for targeted IPs if service sacrifice is acceptable 5. Scale infrastructure horizontally if cloud-based (auto-scaling policies) 6. Block identified source IP ranges at perimeter (with caution for spoofed IPs) 7. Move DNS to point at scrubbing centre if not already in path 8. Monitor for secondary attacks that may be masked by the DDoS ### 6.6 Recovery 1. Gradually disable mitigation measures and monitor for attack resumption 2. Restore any services that were taken offline defensively 3. Review and baseline normal traffic patterns post-attack 4. Update DDoS response thresholds based on attack characteristics 5. Conduct lessons learned session within --- ## 7. Playbook 2: Ransomware ### 7.1 Description Ransomware encrypts data and/or threatens to leak stolen data, demanding payment for decryption keys or to prevent publication. This is always treated as a P1 incident. ### 7.2 Severity P1 -- Critical (always) ### 7.3 Detection Indicators - EDR alert for ransomware behaviour (mass file encryption, shadow copy deletion) - Ransomware note discovered on affected systems - Unusual file extension changes across multiple files - Spike in file system write operations - Deletion of Volume Shadow Copies (vssadmin delete shadows) - Unusual outbound data transfer preceding encryption (double extortion) - Reports from users unable to access files ### 7.4 Triage Steps 1. Immediately identify all affected systems and the ransomware variant 2. Determine encryption status: actively encrypting or complete? 3. Check for lateral movement indicators 4. Assess backup availability and integrity 5. Determine if data exfiltration occurred (double extortion) 6. Identify initial access vector if possible (phishing, RDP, vulnerability) ### 7.5 Containment and Response **CRITICAL: Do not power off affected systems. Isolate at the network level instead to preserve volatile memory for forensics.** 1. Immediately isolate affected endpoints via EDR network quarantine or switch port disable 2. Disable affected user accounts in Active Directory / identity provider 3. Block known ransomware C2 infrastructure at firewall and DNS 4. Disable SMB, RDP, and WMI across network segments where not essential 5. Check for scheduled tasks, GPO modifications, or other persistence mechanisms 6. Engage for forensic analysis 7. Preserve memory dumps and disk images of representative affected systems 8. Notify regarding potential regulatory obligations 9. Do NOT pay the ransom without explicit executive and legal approval 10. Check NoMoreRansom.org and vendor resources for known decryptors 11. Assess and validate all backup systems before beginning restoration ### 7.6 Recovery 1. Rebuild affected systems from gold images 2. Restore data from verified clean backups (test restore on isolated system first) 3. Reset ALL domain credentials (user, admin, service accounts, KRBTGT) 4. Rebuild domain controllers if compromise is suspected at that level 5. Reintroduce systems to network incrementally with enhanced monitoring 6. Monitor for re-infection indicators for minimum days 7. Validate no persistence mechanisms remain using threat hunt --- ## 8. Playbook 3: Unauthorised Access ### 8.1 Description Unauthorised access involves an individual gaining access to systems, networks, or data without proper authorisation. This includes compromised credentials, privilege escalation, and insider threat scenarios. ### 8.2 Severity Initial: P2 (escalate to P1 if privileged accounts are compromised or sensitive data is at risk) ### 8.3 Detection Indicators - Authentication from unusual geographic location or IP address - Impossible travel alerts (logins from geographically distant locations in short timeframe) - Multiple failed login attempts followed by a success - Login outside normal business hours for the user - Access to resources outside the user's normal pattern - New MFA device registered without user's knowledge - Privilege escalation events (e.g., user added to admin group) - VPN connection from unrecognised device ### 8.4 Triage Steps 1. Identify the compromised account(s) 2. Determine method of access (credential theft, brute force, session hijacking) 3. Review authentication logs for the account over the past days 4. Identify all systems and data accessed by the compromised account 5. Determine if the account has been used for lateral movement 6. Check if the account has access to sensitive data or administrative functions ### 8.5 Containment and Response 1. Disable or suspend the compromised account immediately 2. Revoke all active sessions and tokens for the account 3. Reset the account password and MFA registration 4. Block the source IP address(es) at the perimeter 5. Review and revoke any permissions changes made by the attacker 6. Check for new accounts created, scheduled tasks, or persistence mechanisms 7. Review email rules for forwarding or deletion rules added by attacker 8. Audit all actions performed by the account during the compromise window 9. Notify the legitimate account holder through a verified channel 10. If insider threat is suspected, coordinate with HR () and Legal ### 8.6 Recovery 1. Re-enable the account only after full credential reset and MFA re-enrollment 2. Implement conditional access policies to prevent recurrence 3. Monitor the account closely for days 4. Review access permissions and apply least-privilege adjustments 5. Conduct a broader credential audit if the access method suggests wider compromise --- ## 9. Playbook 4: Data Breach ### 9.1 Description A data breach involves the confirmed unauthorised access to, or exfiltration of, personal data or sensitive business information. This playbook addresses regulatory notification requirements and evidence preservation. ### 9.2 Severity P1 -- Critical (always when personal data is involved) ### 9.3 Detection Indicators - DLP alerts for large data transfers to external destinations - Unusual database query volumes or patterns - Large file uploads to cloud storage, email, or file-sharing services - DNS tunnelling or covert channel indicators - Alerts from CASB for unusual cloud application data movement - Third-party notification of data exposure (e.g., data found on dark web) - Customer or partner notification of receiving unexpected data ### 9.4 Triage Steps 1. Confirm data has been accessed or exfiltrated (not just attempted) 2. Identify the data categories affected: - Personal data (names, emails, addresses) - Special category data (health, biometric, financial) - Credentials or authentication data - Intellectual property or trade secrets - Payment card data (triggers PCI DSS obligations) 3. Determine the volume of records affected 4. Identify the data subjects affected (employees, customers, partners) 5. Determine if the data was encrypted at rest and in transit 6. Identify the threat actor and method of exfiltration ### 9.5 Containment and Response 1. Block the exfiltration channel immediately 2. Follow Unauthorised Access playbook (Section 8) for access containment 3. Preserve all evidence related to the data access and exfiltration 4. Engage immediately for regulatory assessment 5. Determine notification obligations: - **GDPR/UK GDPR:** 72-hour notification to ICO () - **:** - **Contractual:** Review customer contracts for breach notification clauses 6. Prepare data breach impact assessment 7. Engage for forensic investigation if needed 8. Begin preparing notification communications (see Section 11) ### 9.6 Regulatory Notification Checklist - [ ] Legal counsel engaged and briefed - [ ] Data categories and volume determined - [ ] Supervisory authority notification prepared (within 72 hours of awareness) - [ ] Data subject notification assessed (high risk to rights and freedoms?) - [ ] Contractual notification obligations reviewed - [ ] Insurance carrier notified () - [ ] Law enforcement notification considered (if criminal activity suspected) - [ ] Record of breach documented in breach register ### 9.7 Recovery 1. Remediate the vulnerability or access path that enabled the breach 2. Implement additional DLP controls to prevent recurrence 3. Monitor for misuse of the breached data 4. Complete all regulatory notifications within required timeframes 5. Notify affected data subjects if required 6. Offer credit monitoring or identity protection if personal financial data was breached 7. Update data handling procedures based on lessons learned --- ## 10. Playbook 5: Network Outage ### 10.1 Description A network outage involves the partial or complete loss of network connectivity affecting business operations. This covers both planned (failed maintenance) and unplanned outages. ### 10.2 Severity - P1: Core network infrastructure failure affecting all users or customer-facing services - P2: Significant segment or site outage affecting multiple teams - P3: Localised outage affecting a single team or non-critical service - P4: Intermittent connectivity issues with minimal business impact ### 10.3 Detection Indicators - Network monitoring alerts (NMS: ) - Multiple users reporting connectivity issues - Ping/traceroute failures to critical infrastructure - BGP session drops or OSPF adjacency changes - Interface error counters incrementing rapidly - STP topology change notifications - ISP outage notifications ### 10.4 Triage Steps 1. Determine scope: which sites, VLANs, or segments are affected? 2. Identify the affected network devices (switches, routers, firewalls) 3. Check for recent changes (cross-reference with change management log) 4. Verify ISP connectivity status () 5. Check power status of network infrastructure 6. Review NMS for device health, interface status, and error logs 7. Determine if security incident may be the cause (rule out DDoS, compromised device) ### 10.5 Containment and Response 1. Implement workaround routing if redundant paths are available 2. Failover to backup ISP circuit if primary is affected 3. If device failure: replace or restore from backup configuration 4. If configuration error: roll back to last known good configuration 5. If ISP issue: escalate with ISP and implement traffic engineering to backup path 6. If power issue: verify UPS status and engage facilities team 7. Communicate impact and ETA to affected users (see Section 11) ### 10.6 Recovery 1. Restore full connectivity and validate with end-to-end testing 2. Verify all dependent services are operational 3. Monitor for stability over the next hours 4. Update network diagrams if topology has changed 5. Document root cause and update change management procedures if applicable 6. Review and improve redundancy if single point of failure is identified --- ## 11. Communication Templates ### 11.1 Internal Notification -- Initial **Subject:** [] Security Incident -- -- ``` INCIDENT NOTIFICATION Incident ID: Priority: Time Detected: UTC Incident Type: SUMMARY CURRENT IMPACT - Affected systems: - Affected users/customers: - Business services impacted: CURRENT STATUS ACTIONS TAKEN 1. 2. 3. NEXT UPDATE Expected at UTC or upon significant development. INCIDENT COMMANDER -- DISTRIBUTION This communication is classified as . Do not forward outside the distribution list. ``` ### 11.2 Management Briefing **Subject:** [] Executive Briefing -- Incident ``` EXECUTIVE BRIEFING Incident ID: Priority: Business Impact: SITUATION <2-3 sentence plain-language summary of the incident> BUSINESS IMPACT - Revenue impact: - Customer impact: - Regulatory risk: - Reputational risk: RESPONSE STATUS - Phase: - Team engaged: - External support: DECISIONS REQUIRED ESTIMATED RESOLUTION NEXT UPDATE UTC ``` ### 11.3 External Customer Notification **Subject:** Service Update -- ``` Dear , We are writing to inform you of a service disruption affecting . WHAT HAPPENED WHAT WE ARE DOING WHAT THIS MEANS FOR YOU CURRENT STATUS We will provide updates every until this matter is resolved. For urgent enquiries, please contact . Regards, <ORGANISATION_NAME> ``` ### 11.4 Data Breach Notification to Supervisory Authority ``` DATA BREACH NOTIFICATION Organisation: <ORGANISATION_NAME> DPO Contact: <DPO_NAME> -- <DPO_EMAIL> Date of Awareness: <AWARENESS_DATE> Date of Breach: <BREACH_DATE> (if known) NATURE OF THE BREACH <Description of the breach including categories of data and approximate number of records affected> DATA CATEGORIES AFFECTED - [ ] Names - [ ] Email addresses - [ ] Postal addresses - [ ] Phone numbers - [ ] Financial data - [ ] Health data - [ ] Credentials/passwords - [ ] Other: <SPECIFY> APPROXIMATE NUMBER OF DATA SUBJECTS: <NUMBER> APPROXIMATE NUMBER OF RECORDS: <NUMBER> LIKELY CONSEQUENCES <Assessment of likely consequences for data subjects> MEASURES TAKEN <Measures taken or proposed to address the breach and mitigate adverse effects> DPO RECOMMENDATION <Whether data subjects should be notified directly> ``` --- ## 12. Escalation Matrix ### 12.1 Escalation Path | Level | Role | Contact | Trigger | |---------|--------------------------|--------------------------|----------------------------------------------------| | Level 1 | SOC Analyst (L1) | <L1_PHONE> | Initial alert triage | | Level 2 | Senior Analyst (L2) | <L2_PHONE> | Confirmed true positive | | Level 3 | Incident Commander | <IC_PHONE> | P1/P2 incident declared | | Level 4 | CISO / Head of Security | <CISO_PHONE> | P1 incident, data breach, regulatory involvement | | Level 5 | CEO / Executive Board | <CEO_PHONE> | Major business impact, media involvement, ransom | ### 12.2 Out-of-Hours Escalation | Time Period | Primary Contact | Secondary Contact | Method | |--------------------------|--------------------------|--------------------------|----------------------------| | Business hours | <PRIMARY_BH> | <SECONDARY_BH> | <TICKETING_SYSTEM>, phone | | Evenings (18:00-22:00) | <PRIMARY_EVE> | <SECONDARY_EVE> | Phone, <OOB_COMMS_TOOL> | | Nights (22:00-06:00) | <PRIMARY_NIGHT> | <SECONDARY_NIGHT> | Phone, <OOB_COMMS_TOOL> | | Weekends / Bank Holidays | <PRIMARY_WEEKEND> | <SECONDARY_WEEKEND> | Phone, <OOB_COMMS_TOOL> | ### 12.3 Third-Party Escalation Contacts | Provider | Contact | SLA | Account Reference | |-------------------------------|--------------------------|------------------------------|----------------------------| | ISP | <ISP_CONTACT> | <ISP_SLA> | <ISP_ACCOUNT_REF> | | Cloud Provider | <CLOUD_SUPPORT_CONTACT> | <CLOUD_SLA> | <CLOUD_ACCOUNT_REF> | | DDoS Mitigation | <DDOS_CONTACT> | <DDOS_SLA> | <DDOS_ACCOUNT_REF> | | IR Retainer | <IR_RETAINER_CONTACT> | <IR_RETAINER_SLA> | <IR_RETAINER_ACCOUNT_REF> | | Cyber Insurance | <INSURANCE_CONTACT> | <INSURANCE_SLA> | <INSURANCE_POLICY_REF> | | Law Enforcement (Non-Emergency) | <LE_CONTACT> | N/A | N/A | --- ## 13. Post-Incident Review Template ### 13.1 Review Meeting Details | Field | Value | |------------------------|------------------------------------| | Incident ID | <INCIDENT_ID> | | Review Date | <REVIEW_DATE> | | Facilitator | <FACILITATOR_NAME> | | Attendees | <ATTENDEE_LIST> | | Duration | <DURATION> | ### 13.2 Incident Summary | Field | Value | |------------------------|------------------------------------| | Incident Type | | | Priority | | | Detection Time (UTC) | | | Declaration Time (UTC) | | | Containment Time (UTC) | | | Eradication Time (UTC) | | | Recovery Time (UTC) | | | Closure Time (UTC) | | | Total Duration | | | Business Impact | | ### 13.3 Timeline of Events | Time (UTC) | Event Description | Actor/System | Evidence Reference | |------------|-------------------|--------------|--------------------| | | | | | | | | | | | | | | | ### 13.4 What Went Well 1. 2. 3. ### 13.5 What Could Be Improved 1. 2. 3. ### 13.6 Root Cause Analysis **Immediate Cause:** **Contributing Factors:** **Root Cause:** ### 13.7 Action Items | ID | Action | Owner | Priority | Deadline | Status | |-----|---------------------------------|--------------------|---------|--------------------|----------| | 1 | | | | | | | 2 | | | | | | | 3 | | | | | | ### 13.8 Metrics | Metric | Value | Target | Met? | |--------------------------------------|---------|---------|---------| | Time to detect | | | | | Time to acknowledge | | | | | Time to contain | | | | | Time to resolve | | | | | Number of systems affected | | | | | Data records affected | | | | | Estimated financial impact | | | | --- ## Appendix A: Tools List ### Forensic and Analysis Tools | Category | Tool | Location / Access | Purpose | |-----------------------|---------------------------|----------------------------------|------------------------------------------| | Disk Imaging | FTK Imager | <FORENSIC_WORKSTATION> | Forensic disk image acquisition | | Disk Imaging | dd / dc3dd | <FORENSIC_WORKSTATION> | Linux-based disk imaging | | Memory Capture | WinPMEM / LiME | <FORENSIC_WORKSTATION> | Volatile memory acquisition | | Memory Analysis | Volatility 3 | <FORENSIC_WORKSTATION> | Memory forensic analysis | | Log Analysis | <SIEM_PLATFORM> | <SIEM_URL> | Centralised log search and correlation | | Network Capture | Wireshark / tcpdump | <FORENSIC_WORKSTATION> | Packet capture and analysis | | Malware Analysis | Any.Run / VirusTotal | Cloud | Dynamic and static malware analysis | | Malware Analysis | Ghidra / IDA Free | <FORENSIC_WORKSTATION> | Binary reverse engineering | | EDR | <EDR_PLATFORM> | <EDR_CONSOLE_URL> | Endpoint detection, isolation, response | | Vulnerability Scanner | <VULN_SCANNER> | <VULN_SCANNER_URL> | Vulnerability identification | | Threat Intel | MISP / OpenCTI | <THREAT_INTEL_URL> | IOC management and sharing | | Password Audit | Hashcat / John the Ripper | <FORENSIC_WORKSTATION> | Credential analysis (authorised only) | ### Jump Bag Contents | Item | Quantity | Last Verified | |---------------------------------------|----------|---------------------| | Forensic laptop (write-blocker equipped) | 1 | <LAST_VERIFIED> | | External hard drives (sanitised) | 3 | <LAST_VERIFIED> | | USB write blocker | 1 | <LAST_VERIFIED> | | Bootable forensic USB (CAINE/SIFT) | 2 | <LAST_VERIFIED> | | Network tap | 1 | <LAST_VERIFIED> | | Ethernet cables (various lengths) | 5 | <LAST_VERIFIED> | | Console cable (RJ45 to USB) | 1 | <LAST_VERIFIED> | | Evidence bags and tamper-evident seals | 20 | <LAST_VERIFIED> | | Chain of custody forms (printed) | 20 | <LAST_VERIFIED> | | Permanent markers and labels | 5 | <LAST_VERIFIED> | | Camera (for photographing evidence) | 1 | <LAST_VERIFIED> | | Notebook and pens | 2 | <LAST_VERIFIED> | --- ## Appendix B: Evidence Checklist ### Digital Evidence Collection Checklist - [ ] Photograph the physical setup before touching anything - [ ] Record date, time (UTC), and location of evidence collection - [ ] Capture volatile data first (memory, running processes, network connections) - [ ] Create forensic disk image using write-blocked source - [ ] Calculate and record hash values (SHA-256) for all evidence - [ ] Collect relevant log files (system, application, security, firewall, SIEM) - [ ] Export relevant SIEM alerts and correlation results - [ ] Capture network traffic if attack is ongoing - [ ] Collect email headers and attachments if phishing-related - [ ] Export cloud audit logs (AWS CloudTrail, Azure Activity Log, GCP Audit Log) - [ ] Preserve DNS query logs - [ ] Capture screenshots of relevant console output or error messages - [ ] Document all user interviews and observations - [ ] Store all evidence in <EVIDENCE_STORAGE_LOCATION> with restricted access - [ ] Complete chain of custody form for each evidence item ### Evidence Priority Order 1. Volatile memory (RAM) 2. Running processes and network connections 3. Temporary files and swap space 4. Disk images 5. Log files (remote/centralised) 6. Network traffic captures 7. Physical evidence --- ## Appendix C: Chain of Custody Form ``` CHAIN OF CUSTODY FORM VantagePoint Networks Incident ID: ____________________________ Evidence ID: ____________________________ Description: ____________________________ ____________________________ Collection Details: Collected By: ____________________________ Date/Time (UTC): ____________________________ Location: ____________________________ Method: ____________________________ Hash (SHA-256): ____________________________ Transfer Record: | # | Released By (Print) | Signature | Date/Time (UTC) | Received By (Print) | Signature | Date/Time (UTC) | Purpose | |---|---------------------|-----------|------------------|---------------------|-----------|------------------|------------------| | 1 | | | | | | | | | 2 | | | | | | | | | 3 | | | | | | | | | 4 | | | | | | | | | 5 | | | | | | | | Storage Location: ____________________________ Access Restrictions: ____________________________ Disposal Date: ____________________________ Disposal Method: ____________________________ Disposal Witnessed By: ___________________________ Notes: _________________________________________________ _________________________________________________ _________________________________________________ ``` --- **Document End** *This document is the intellectual property of VantagePoint Networks. Unauthorised reproduction or distribution is prohibited.* *VantagePoint Networks -- Professional Network Security Solutions*