Cyber Incident Response Plan Template Australia

Standard Operating Procedure: Cyber Incident Response Plan (CIRP)

Document ID: TR-SEC-SOP-001
Effective Date: 2024-05-22
Version: 2.1.0
Review Cadence: Bi-annual (or post-incident)

---

1. Executive Summary & Purpose

This document establishes the mandated framework for identifying, containing, and eradicating cyber threats within Template Registry operations. It aligns with the ACSC Essential Eight and the Australian Privacy Principles (APP). The purpose is to minimize service downtime, maintain data integrity, and ensure mandatory compliance with the Security of Critical Infrastructure Act 2018 (SOCI) and the Privacy Act 1988.

---

2. Scope & Prerequisites

• Scope: All digital assets, cloud infrastructure, and endpoint devices managed by Template Registry.
• Required Tools:
  • SIEM/Log Management (e.g., Splunk/Sentinel).
  • Out-of-band communication (e.g., Signal, encrypted hardened Slack channels).
  • Forensic imaging toolkit (FTK Imager).
  • Isolated "Clean Room" network VLAN.
• Prerequisites: Validated offline backups (3-2-1 rule), immutable audit logs, and pre-negotiated retainer with an external IR firm (e.g., CrowdStrike/Mandiant).

---

3. Roles & Responsibilities (RACI)

---

4. Step-by-Step Procedure

Phase 1: Detection & Analysis

• Verify alert veracity via SIEM correlation.
• Confirm scope of impact (Assets, Data classification, PII involved).
• Declare incident status (Severity 1-4) and activate the Crisis Response Team.

Phase 2: Containment (Short-term)

• Isolate affected VLANs/Endpoints from the production network.
• Revoke compromised credentials/API keys.
• Block malicious IPs/Domains at the edge firewall.

Phase 3: Eradication & Recovery

• Perform root-cause analysis (RCA) via forensic snapshots.
• Rebuild affected servers from verified "Known Good" backups.
• Patch vulnerabilities exploited during the breach.
• Reset all administrative credentials across the environment.

Phase 4: Post-Incident Activity

• Conduct "Lessons Learned" meeting within 72 hours.
• File mandatory notification to the OAIC (Office of the Australian Information Commissioner) if PII is breached.
• Update IR playbooks based on identified control gaps.

---

5. Quality Assurance & Pro-Tips

• Best Practice: Always assume your primary communication channel (email/Teams) is compromised. Maintain a "Break-Glass" out-of-band communication platform.
• Common Pitfall: Over-reliance on automation. Automated containment can trigger "Dead Man's Switches" in ransomware variants. Always have a human supervisor authorize mass-isolation.
• Metric Thresholds:
  • MTTD (Mean Time to Detect): < 1 hour.
  • MTTC (Mean Time to Contain): < 4 hours.

---

6. Frequently Asked Questions

Q: When must I notify the OAIC?
A: Under the Notifiable Data Breaches (NDB) scheme, you must notify the OAIC and affected individuals if a breach is likely to result in "serious harm." If in doubt, consult Legal immediately.

Q: Can I reboot the affected server to fix the issue?
A: No. Rebooting wipes volatile memory (RAM), destroying critical forensic evidence. Always perform a memory dump before any power-state changes.

Q: Who speaks to the media?
A: Only the designated Communications lead. Technical staff are strictly prohibited from discussing incidents outside of the incident command structure to prevent legal liability.

---

Authorized by: Julian Vance, Chief Architect, Template Registry