Vic Gov-cyber-incident-response-plan-template

Standard Operating Procedure: Victorian Government Cyber Incident Response Plan (CIRP) Operationalization

1. Document Control Block

• Document ID: SOP-TR-VIC-CIRP-042
• Effective Date: October 24, 2023
• Version: 2.4.0
• Review Cadence: Semi-Annual / Post-Incident Review
• Owner: Julian Vance, Chief Architect, Template Registry

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional framework and tactical execution steps for operationalizing the Victorian Government Cyber Incident Response Plan (VIC CIRP) template within enterprise infrastructure. The objective is to establish a standardized, repeatable, and auditable lifecycle for detecting, containing, eradicating, and recovering from cyber security incidents in alignment with the Victorian Protective Data Security Standards (VPDSS) and state-mandated reporting thresholds.

---

3. Scope & Prerequisites

3.1 Scope

• Applies to all information systems, cloud environments, on-premises infrastructure, and third-party SaaS integrations managed or utilized by Victorian Government entities and registered template consumers.
• Covers the full incident lifecycle from initial telemetry anomaly detection through post-incident forensic validation.

3.2 Prerequisites & Required Tools

• Security Information and Event Management (SIEM): Splunk Enterprise Security / Microsoft Sentinel configured with Victorian Government telemetry parsers.
• Endpoint Detection and Response (EDR): CrowdStrike Falcon / Microsoft Defender for Endpoint with live isolation capabilities.
• Incident Management Platform: Jira Service Management / ServiceNow configured with pre-approved VIC CIRP workflows.
• Forensic Capture Suite: Volatility 3, FTK Imager, and Velociraptor for volatile and non-volatile artifact collection.
• Out-of-Band Communications: Threema Work or Signal enterprise instances (isolated from primary O365/Google Workspace tenants).

---

4. Roles & Responsibilities

---

5. Step-by-Step Procedure

Phase 1: Triage, Scoping, and Severity Classification

• 1.1 Ingest security alerts from SIEM/EDR and execute an initial verification query to eliminate confirmed false positives within 15 minutes of trigger.
• 1.2 Populate the VIC CIRP Incident Ticket with raw telemetry hashes, affected IP/MAC addresses, and impacted asset classifications.
• 1.3 Assign an initial severity rating (Sev 1 - Catastrophic to Sev 4 - Minor) using the Victorian Government Cyber Incident Severity Matrix.
• 1.4 If Severity 1 or 2 is declared, immediately page the Incident Response Commander (IRC) via the out-of-band paging gateway.

Phase 2: Containment and Eradication

• 2.1 Authorize and execute surgical network isolation (EDR host containment) for all identified patient-zero endpoints without rebooting systems to preserve volatile memory.
• 2.2 Revoke active OAuth tokens, session cookies, and compromised Active Directory/Entra ID credentials associated with compromised accounts.
• 2.3 Implement emergency firewall block rules (deny-all egress/ingress) at the perimeter and virtual private cloud (VPC) security group levels for Command & Control (C2) IPs.
• 2.4 Deploy forensic collectors (Velociraptor) to capture memory dumps ($MFT, registry hives, and running processes) from suspected hosts prior to remediation.
• 2.5 Patch vulnerabilities, remove unauthorized persistence mechanisms (scheduled tasks, daemon modifications), and rotate administrative secrets.

Phase 3: Notification and Mandatory Reporting

• 3.1 Draft the preliminary notification brief for the Victorian Cyber Security Service (VCSS) within 2 hours of confirming a Severity 1 or 2 incident.
• 3.2 Notify the Office of the Victorian Information Commissioner (OVIC) if the incident involves a confirmed or suspected compromise of Victorian Public Sector (VPS) personal or sensitive data.
• 3.3 Convene the crisis management cell every 4 hours to review containment progress, legal obligations, and stakeholder communications.

Phase 4: Recovery and Validation

• 4.1 Restore affected file systems, databases, and application states from immutable, air-gapped backups verified to be free of malware artifacts.
• 4.2 Execute comprehensive vulnerability scans and targeted penetration testing scripts against restored assets to confirm eradication.
• 4.3 Gradually restore network connectivity while maintaining heightened SIEM correlation rule sensitivity for a minimum of 72 hours post-recovery.
• 4.4 Formally sign off on system clearance with the CISO and transition the operational status back to "Business as Usual" (BAU).

---

6. Quality Assurance & Pro-Tips

6.1 Best Practices

• Preserve Evidence Integrity: Never power down a compromised virtual machine or physical server before capturing volatile memory; rely exclusively on logical network isolation.
• Maintain Out-of-Band Channels: Assume primary corporate communication channels (Email, Teams, Slack) are compromised during advanced persistent threat (APT) incursions.

6.2 Common Pitfalls

• Premature Eradication: Deleting malware binaries or killing suspicious processes before isolating the host, which tips off threat actors and triggers counter-incident behaviors (e.g., ransomware deployment).
• Communication Silos: Failing to involve legal counsel early, leading to potential breaches of statutory reporting windows or waiver of legal privilege.

6.3 Metric Thresholds

• Mean Time to Detect (MTTD): < 15 minutes for Sev 1/2 anomalies.
• Mean Time to Isolate (MTTI): < 30 minutes from severity confirmation.
• Statutory Reporting Compliance: 100% adherence to VCSS/OVIC notification SLAs.

---

7. Frequently Asked Questions (FAQ)

Q1: What triggers an immediate escalation to the Victorian Cyber Security Service (VCSS)?
A: Any incident classified as Severity 1 (Critical) or Severity 2 (Major)—such as active ransomware deployment, widespread data exfiltration of citizen PII, or disruption of critical Victorian Government infrastructure—mandates notification to VCSS within 2 hours of validation.

Q2: Can system administrators delete malicious persistence mechanisms immediately upon discovery?
A: No. Deleting persistence mechanisms (e.g., cron jobs, registry run keys) without capturing forensic evidence destroys crucial attribution data. Always capture state snapshots and notify the Lead Forensic Investigator prior to remediation steps.

Q3: How should logs and artifacts be stored during an active forensic investigation?
A: All captured memory dumps, disk images, and SIEM exports must be written to an encrypted, write-once-read-many (WORM) storage bucket with strict Access Control Lists (ACLs) restricted to members of the Incident Response Team and legal counsel.