Incident Response Plan Template Australia

Standard Operating Procedure: Australian Cyber Security Incident Response Plan (CSIRP)

Template Registry Engineering Division

---

1. Document Control Block

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional-grade Incident Response Plan (IRP) template for operations within Australian jurisdiction. It establishes a deterministic, repeatable framework for identifying, containing, eradicating, and recovering from information security incidents. This document ensures statutory compliance with the Privacy Act 1988 (Cth), specifically the Notifiable Data Breaches (NDB) scheme administered by the Office of the Australian Information Commissioner (OAIC), alongside mandatory reporting thresholds for the Australian Cyber Security Centre (ACSC).

---

3. Scope & Prerequisites

Scope

• Applies to: All production environments, staging infrastructure, corporate networks, and SaaS platforms managed by Template Registry within the ap-southeast-2 (Sydney) AWS region and associated on-premises nodes.
• Excludes: Third-party vendor infrastructure where direct systems access is restricted (governed by respective Vendor SLA/SLOs).

Prerequisites & Required Access

• Identity & Access Management: PagerDuty administrative access, Okta Super Administrator permissions, AWS IAM Cross-Account Security Auditor role.
• Forensic Tooling: AWS GuardDuty, CrowdStrike Falcon Insight, Wireshark, Volatility Foundation (memory forensics), netcat/tcpdump.
• Communications: Out-of-band Slack Enterprise Grid channel (#inc-response-war-room), PagerDuty automated bridge, encrypted signal channel for executive escalations.

---

4. Roles & Responsibilities (RACI Matrix)

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

---

5. Step-by-Step Procedure

Phase 1: Detection, Triage, and Scoping

• 1.1 Acknowledge automated security alerts triggered via AWS GuardDuty, CrowdStrike Falcon, or manual internal ticketing within 5 minutes of paging.
• 1.2 Instantiate the out-of-band PagerDuty incident bridge and pin the primary war room Slack channel (#inc-response-war-room).
• 1.3 Assign the Incident Commander (IC) role to direct mitigation actions and establish a chronological event timeline in the Master Incident Log.
• 1.4 Triage the alert to determine classification: Sev-1 (Critical Data Exfiltration/Ransomware), Sev-2 (Isolated Host Compromise), or Sev-3 (Low-Risk Anomaly).

Phase 2: Containment (Short-Term and Long-Term)

• 2.1 Execute immediate network isolation of compromised EC2 instances or physical hosts by applying the strict sg-incident-lockdown security group (drops all ingress/egress except forensic logging ports).
• 2.2 Revoke all active session tokens and force credential rotations for compromised IAM users, service accounts, and enterprise SSO credentials via Okta API calls.
• 2.3 Preserve system state by generating memory dumps and capturing EBS snapshot volumes for forensic analysis prior to executing any reboot or modification.
• 2.4 Implement perimeter firewall rule updates or WAF (Web Application Firewall) rate-limiting rules to block malicious IP ranges or attack vectors identified during triage.

Phase 3: Eradication and System Recovery

• 3.1 Identify root cause entry vectors (e.g., zero-day vulnerability, stolen credentials, misconfigured S3 bucket) and verify that the vulnerability patch or configuration fix is staged.
• 3.2 Terminate compromised containers, EC2 instances, and execution threads. Rebuild production nodes exclusively from verified, clean golden Amazon Machine Images (AMIs) or immutable infrastructure pipelines (Terraform/Ansible).
• 3.3 Restore encrypted databases from the most recent known-good backup verified prior to the estimated initial compromise timestamp.
• 3.4 Re-enable network access incrementally while monitoring real-time metrics in Datadog/CloudWatch for anomaly patterns, unauthorized lateral movement, or recurring persistence mechanisms.

Phase 4: Australian Regulatory Compliance & Notification (OAIC/ACSC)

• 4.1 Convene the Privacy Assessment Panel (Legal Counsel, Chief Architect, Incident Commander) to evaluate data breach indicators against the Privacy Act 1988 (Cth) criteria.
• 4.2 Determine if the incident constitutes an "Eligible Data Breach" likely to result in serious harm to any affected individuals.
• 4.3 If thresholds are met, draft the formal notification statement for the Office of the Australian Information Commissioner (OAIC) within the statutory 30-calendar-day assessment window.
• 4.4 Prepare individual communications to affected Australian data subjects via secure channels containing required statutory disclosures (nature of breach, compromised data categories, recommended mitigation steps).
• 4.5 Submit incident telemetry metrics to the Australian Cyber Security Centre (ACSC) via theASSIST portal if critical infrastructure or essential services are impacted.

Phase 5: Post-Incident Review & Hardening

• 5.1 Freeze forensic evidence logs, timelines, and audit trails in a write-once-read-many (WORM) S3 bucket for legal and compliance archiving.
• 5.2 Schedule and conduct a blameless Post-Incident Review (PIR) meeting with all engineering stakeholders within 5 business days of incident closure.
• 5.3 Translate identified gaps into JIRA engineering tickets with mandatory SLAs (Sev-1 remediation targets: 72 hours).
• 5.4 Update the baseline SOP, automated detection signatures, and runbooks based on lessons learned.

---

6. Quality Assurance & Pro-Tips

Best Practices (Pro-Tips)

• Never Power Down: Never shut down or power off a compromised virtual machine or physical server before capturing volatile RAM. Doing so destroys critical forensic evidence required for root cause analysis.
• Preserve Chain of Custody: Maintain cryptographic hashes (SHA-256) of all extracted forensic images at the exact moment of acquisition to ensure legal admissibility.
• Separate Communications: If corporate email or internal Slack is compromised, immediately pivot communications to an out-of-band, pre-provisioned encrypted communication channel.

Common Pitfalls to Avoid

• Premature Eradication: Deleting malware or closing entry points before capturing forensics, which tips off attackers and leaves underlying persistence mechanisms intact.
• Delayed Legal Engagement: Waiting until full technical recovery is complete before involving Legal Counsel, thereby risking non-compliance with OAIC statutory notification timelines.

Metric Thresholds

• Mean Time to Detect (MTTD): < 15 minutes.
• Mean Time to Contain (MTTC): < 30 minutes for Sev-1 incidents.
• OAIC Assessment Window: < 72 hours from initial suspicion to formal NDB determination.

---

7. Frequently Asked Questions

Q1: What constitutes an "Eligible Data Breach" under the Australian Privacy Act requiring OAIC notification?
A: An eligible data breach occurs when unauthorized access to, unauthorized disclosure of, or loss of personal information holds a strong likelihood of resulting in serious harm (which may include physical, psychological, emotional, financial, or reputational harm) to any of the affected individuals. If remediation prevents this risk of serious harm, notification is not legally mandatory, though internal logging is still required.

Q2: Who possesses the ultimate authorization to execute network isolation on production infrastructure?
A: The designated Incident Commander (IC) or the Chief Architect (Julian Vance) holds autonomous authority to sever production networks, isolate AWS Virtual Private Clouds (VPCs), or invalidate enterprise-wide identity tokens without requiring prior executive sign-off during active Sev-1 security events.

Q3: How long must forensic logs and incident artifacts be retained within the Australian regulatory ecosystem?
A: All forensic artifacts, system logs, memory dumps, and communications must be preserved in a secure, immutable repository for a minimum of seven (7) years to satisfy corporate governance, insurance, and statutory audit mandates.