Vaxa Cyber Incident Response Plan
Purpose
Vaxa’s Cyber Incident Response Plan (CIRP) provides a structured approach to detecting, responding to, and recovering from cyber incidents.
The goal is to minimise damage, restore normal operations quickly, and prevent future incidents. Cyber-attacks can escalate rapidly, so a clear and coordinated response is critical.
Scope
This plan covers cyber and information security incidents that impact Vaxa’s IT systems, data, or digital assets. These incidents may include:
- Data breaches (e.g. unauthorised access or data leaks)
- Unauthorised system access (e.g. compromised accounts, privilege escalation)
- Malware outbreaks (e.g. ransomware, viruses, spyware)
- Phishing & social engineering attacks
- Denial of Service (DoS) attacks
Technically speaking, cybersecurity incidents are a subset of Information Security incidents (for example, the loss of a physical document containing sensitive information would be an Information Security incident, but not a Cybersecurity incident). In practice, we treat these the same way so we can respond quickly and effectively without the overhead of maintaining many separate plans.
What’s not covered in this plan?
General IT issues don’t fall part of this plan unless they’re suspected to be caused by a cyber incident. This therefore excludes things like:
- Hardware failures
- Software bugs
- Software updates
- General system outages
If you’re experiencing one of these, you should use the usual process to report to the IT team who may enact the Disaster Recovery policy and plans as required.
Roles & Responsibilities
Everyone at Vaxa
All employees play a role in keeping Vaxa’s systems secure. As part of the team, you should:
- Follow security policies when using company systems and handling data
- Report any suspicious activity or potential incidents immediately
- Complete cyber security training to stay aware of risks
Managers
Managers are responsible for ensuring their teams understand and follow security policies. Specifically, managers should:
- Promote secure system use and data protection
- Ensure employees know how to report incidents
- Assist with investigations if required
Cyber Incident Response Team (CIRT)
The CIRT is responsible for managing incidents and coordinating response efforts. Their responsibilities include:
- Assessing, containing, and investigating incidents
- Coordinating with third-party IT providers when needed
- Keeping senior management and stakeholders informed
- Reviewing security measures to prevent future incidents
The CIRT structure will vary based on incident severity, but typically includes:
- Response Controller (CTO) – Leads response efforts
- IT Service Provider – Assists with containment and remediation
- Legal & Compliance – Ensures regulatory reporting and legal steps are taken
- Finance & Business Continuity – Assesses business impact
As Vaxa doesn’t engage a permanent IT Service Provider, the CTO will be responsible for coordinating with external IT providers if required.
CTO
Ownership of these plans and their review/update sits with the CTO. They are responsible for ensuring the plans are up to date. Particular importance is placed on the responsibility of keeping contact details up to date.
Cyber Incident Response Stages
1. Preparation
Proactive preparation reduces risk and ensures Vaxa is ready to respond effectively. This includes:
- Regular security assessments and penetration testing
- Keeping security policies and recovery plans up to date
- Monitoring cyber threat intelligence (e.g. reports from the Australian Cyber Security Centre)
- Employee training to identify and report threats
2. Detection & Reporting
Actual or suspected incidents must be identified quickly to reduce potential damage.
If you suspect a cyber incident:
- Report it immediately to your manager or IT team
- Provide as much detail as possible, such as:
- What happened?
- What systems/data were affected?
- When was it detected?
- Any visible impact?
- Who else knows about it?
- What do you think caused it?
- Did anything unusual happen before the incident?
Failure to report an incident may result in disciplinary action.
Once a report of an incident is received and validated, the CIRT will be activated. The CIRT can place a priority on the incident.
Incident management occurs in our Grafana incident response management system.
3. Containment
Once an incident is confirmed, the CIRT will take action to prevent further damage. This may involve:
- Isolating affected systems from the network
- Disabling compromised accounts and resetting credentials
- Blocking malicious traffic or connections
- Engaging external IT security specialists if required
As part of containment, forensic evidence should be gathered where appropriate. Our approach generally keeps logs in a place where they can’t be tampered with, but still, care should be taken to ensure that evidence is preserved as much as possible. General guidance for forensic evidence preservation includes:
- Don’t turn off the system unless absolutely necessary
- Log all actions taken
- Don’t access or modify files unless necessary
- Keep a record of all places where evidence was or could be found.
Our External First Response Advisor
Once initial containment is complete, the CIRT must contact our First Response provider:
- First Response Advisor: Clyde & Co, Norton Rose Fulbright
- First Response Contact: [1800 290 982](tel:1800 290 982) or [1800 316 349](tel:1800 316 349)
The First Response Advisor:
- Will point an approved IT Specialist to assist with the incident response if required. They will form part of the CIRT, under the command of the Response Controller.
- Will advise on initial legal advice including our obligations to regulators and individuals.
- May appoint a Public Relations Advisor to prevent reputational damage.
- Staff should be advised to route all inquiries from the public towards this advisor.
- May appoint a Cyber Extortion Advisor to assist with ransomware or other extortion attempts.
- In this case, all contact with the attacker should be routed through this advisor first.
The advise of the First Response Advisor should generally be followed as they are experts in the field of cyber incident response, and are familiar with the legal and regulatory environment in which we operate. Our cyber insurance policy recommends that we follow their advice.
4. Investigation & Impact Assessment
The CIRT will perform the initial triage and investigate the source, method, and impact of the attack. This includes:
- Reviewing logs and system activity
- Determining how the attack occurred
- Assessing data loss or system compromise
- Engaging external security experts if necessary
The incident severity will be determined based on:
- Threat Level (e.g. untargeted malware vs. targeted attack)
- System Criticality (e.g. finance system vs. general file storage)
- Business Impact (e.g. operational disruption, financial loss)
- Suspected Source (e.g. external attacker vs. internal error)
The severity will guide the response and recovery efforts.
5. Remediation
Once the issue is understood, the next step is to fix vulnerabilities and prevent recurrence. This may involve:
- Removing malware or compromised accounts
- Updating security controls and patching vulnerabilities
- Strengthening access controls (e.g. enforcing multi-factor authentication)
- Reviewing and adjusting security policies.
We try to develop a range of playbooks that can be used to respond to common incidents. You can find this in the Playbooks & Plans section, and in Grafana.
6. Recovery
Restoring systems and monitoring for lingering threats. Recovery actions include:
- Restoring affected services & verifying system integrity
- Ensuring no further unauthorised access
- Conducting vulnerability scans
- Monitoring for any recurrence of the attack
Communication & Reporting
Managing stakeholders is an important part of our incident response. This section outlines the communication and reporting requirements for different types of incidents.
Externally
Some incidents require notification to external parties. Our First Response Advisor will usually advise on this as the expert.
Generally, if we have a CRITICAL or HIGH incident, we will need to notify the following parties (each has their own specifics though):
- Third-party IT/security providers – if additional expertise is needed
- Australian Cyber Security Centre (ACSC) – must be notified within 12 hours for major incidents
- Office of the Australian Information Commission (OAIC) – required for serious data breaches affecting personal information
- Impacted customers/stakeholders – must be informed within 24 hours
Internally
- Senior Management – must be kept updated on high-severity incidents
- Relevant Business Units – need to understand potential operational impact
- IT Teams – coordinate response and prevention measures
Quick Reference Contacts
For urgent support, contact:
- IT Provider: Envisage Technology – support@envisageit.com.au
- Cyber Security Provider: Holocron Cyber – info@holocroncyber.com.au and 1300 650 263
- First Response Advisor (via our cyber insurance): Clyde & Co / Norton Rose Fulbright – 1800 290 982 or 1800 316 349
If there is a threat to life or risk of harm, call 000.
For suspected incidents, use the internal email notification template to report details to your manager and the CIRT team.
Appendices
Appendix A - Types of Incidents
| Incident Type | Description |
|---|---|
| Installation or execution of unauthorised or malicious software | Suspected, attempted or actual installation or execution of unauthorised or malicious software on a Vaxa device. Includes malware detections by anti-malware software (even if mitigated successfully) and detections by application whitelisting solutions. |
| Network intrusion, enumeration, or another probe | Suspected, attempted or actual network intrusion, enumeration, or probe. Includes intrusion alerts generated by network security equipment such as firewalls or IDS/IPS. |
| Physical loss, theft, or damage of an IT asset | Suspected, attempted or actual physical loss, theft or damage of any IT asset containing Vaxa data. Includes the loss or theft of laptops, tablets, smartphones, or removable media (USB sticks, CDs, DVDs, DATs, etc.). |
| Physical loss, theft, or damage of hardcopy information | Suspected, attempted or actual physical loss, theft, or damage of any Vaxa information in hardcopy. |
| User impersonation | Suspected, attempted or actual instance of user impersonation. Includes password-sharing, attacks on authentication controls, impossible log-on scenarios, etc. |
| Suspicious privilege amendment | Suspected, attempted or actual instances where a genuine user appears to have been placed in an inappropriate user group or to otherwise have gained excessive privileges. |
| Suspicious use of legitimate privileges | Suspected, attempted or actual instances where user appears to have abused legitimate access privileges, e.g., by accessing large number of files, e-mailing data to unauthorised recipients, copying data to removable media or unusual network locations, etc. |
| Eavesdropping on a legitimate comms channel | Suspected, attempted or actual instances where Vaxa data appears to have been intercepted by an unauthorised party. Includes instances where sensitive data is transferred to authorised recipients in unencrypted form. |
| Service spoofing | Suspected, attempted or actual instances where a data service belonging to, or used by, Vaxa is spoofed by a third party. Includes fake websites. |
| DoS or excessive resource consumption | Suspected, attempted or actual instance where an entity places an excessively high demand on an information system or asset. Includes Denial of Service and spam. |
| Phishing | Suspected, attempted or actual instances where: - Email received that claims to be something, or from someone, that it is not. - Persons outside receive email which claims to be from Vaxa but is not. |
| Social Engineering | Suspected, attempted or actual instances where an unauthorised person attempts to gain access to Vaxa data or IT systems by deception or extortion of authorised users (staff, customers or third parties). |
| Inappropriate use of IT facilities (including inappropriate web browsing) | Suspected, attempted or actual instance where user uses system which they have authorised access in an illegal manner, breach policy or contrary to workplace norms. This includes browsing websites that are inappropriate for workplace; sending threatening, obscene or harassing communication; or accessing/storing illegal material. |
| Other harmful mode not listed | Any event that is deemed to be a security event that falls within the remit of the CIRT, but which does not fall into any of the above categories. |
Appendix B – Incident Threat Levels
The following is an explicit description of Incident Threat Levels in descending order of criticality (worst at the top):
| Incident Threat Level | Description |
|---|---|
| Threat Level 1 | Human-Controlled Root-Level Compromise: - Unauthorised external personnel (cyber intrusion). - Partner organisation exceeding authority. - Internal personnel exceeding authority. - Close-access breach (physical penetration of a site). - Rogue wireless access point. - Router re-direct. |
| Threat Level 2 | Human-Controlled User-Level Compromise: - Unauthorised external personnel (cyber intrusion). - Partner organisation exceeding authority. - Internal personnel exceeding authority. |
| Threat Level 3 | Automated (malware-controlled) Root-Level Compromise |
| Threat Level 4 | Automated (malware-controlled) User-Level Compromise |
| Threat Level 5 | Denial of Service |
| Threat Level 6 | Focused Scanning or Unmanaged Malware |
Appendix C – System or Information Criticality
The criticality of systems and information that is potentially at risk is the second component to guiding the assessment of the severity of an incident. The following is an explicit description of these system or information criticalities in descending order of importance (most important first):
| System/Information Criticality | Description |
|---|---|
| Criticality Level 1 | Company-Wide Network Resources (Revenue-Generating Services, Routers, Switches, DNS, Proxies, Firewalls etc.). |
| Criticality Level 2 | Highly Critical Information – Confidential Information (Intellectual Property, PII, PHI). |
| Criticality Level 3 | High Criticality Systems (Active Directory, Exchange, Web Services etc.). |
| Criticality Level 4 | Sensitive Information – Restricted Information (Sensitive Corporate Information, non-PII, Financial Transaction Information etc.). |
| Criticality Level 5 | Non-Critical Multi-Use Systems (File Servers, SharePoint etc.). |
| Criticality Level 6 | Individual Systems and Non-Sensitive Information. |
Appendix D – Incident Severity Matrix
The following table outlines the severity of incidents based on the combination of Incident Threat Level and System or Information Criticality.
| System or Information Criticality | Threat Level 1 | Threat Level 2 | Threat Level 3 | Threat Level 4 | Threat Level 5 | Threat Level 6 |
|---|---|---|---|---|---|---|
| Criticality Level 1 | Critical | Critical | Critical | High | High | Medium |
| Criticality Level 2 | Critical | Critical | High | High | Medium | Medium |
| Criticality Level 3 | Critical | High | High | Medium | Medium | Medium |
| Criticality Level 4 | High | High | Medium | Medium | Medium | Low |
| Criticality Level 5 | High | Medium | Medium | Medium | Low | Low |
| Criticality Level 6 | Medium | Medium | Medium | Low | Low | Low |