With over 2000 incidents reported to CERT NZ each quarter, New Zealand is facing an increasing number of cybersecurity attacks. Every organisation, from the smallest business to the largest government department or organisation must now have a plan for how it will respond to a cybersecurity incident. In the last year, data breaches and other attacks have cost New Zealand around $20 million.
The degree of incident planning each organisation will require depends on the resources it has on hand, the level of available technical expertise and the specific risks and threats it faces. Regardless of these constraints, there are five steps every organisation in New Zealand can follow to ensure they are ready to respond should they become the victim of a cyberattack.
Choose Your Incident Response Team
Incident response is a team sport. As you work your way through the incident planning process, consider who will be responsible for executing specific tasks. Assign one person to be the incident manager and look for people who will be able to work under pressure.
You need a combination of technical and business knowledge. For example, senior managers may be more valuable for managing relationships with key stakeholders such as external agencies, customers or suppliers. An accounts payable team member might be a great person to have as they understand their systems and processes. Remember to include crisis communications and external PR support in your incident response team along with legal counsel.
For each role in your plan, ensure there is a backup – criminals don’t care if your incident manager is on leave.
Assess your risks
Before you create an incident response plan you need to determine what incidents you might face. For example, if you only use cloud systems and don’t operate your own servers or data centre, then it’s unlikely you’ll need a response plan to deal with a Distributed Denial of Service (DDoS) attack. On the other hand, the likelihood of a ransomware attack is much higher.
List all the different cybersecurity incidents and rank according to severity and likelihood. For each type of incident, estimate how likely you are to face that issue and how severe its impact might be. Some typical types of incidents you might need to consider are DDoS, ransomware, rogue employee stealing data, email fraud or extortion where data is stolen and there’s a threat to publicly release it.
Plan For The High-risk Incidents
For each of the highest risk incidents you’ll need a response and communications plan. That plan should include how you will minimise the impact, eradicate the threat, recover to a normal operating state, and document who is responsible for each stage in the response.
As well as the business and technical response, you will need a communications plan. This should include prepared templates for how you will communicate with customers, employees, suppliers and law enforcement. Depending on the incident, you may also be subject to mandatory reporting to the Privacy Commissioner or other agencies.
Test the Incident Response Plan
The only way to know if your plans will work is to test them. Testing accomplishes two major outcomes. It enables you to assess whether your plan is effective and enables your incident response team to practice and perfect their roles in a less pressured environment.
As you test the plan, take careful notes of what worked, where people found the plan interfered with effective response and how it can be improved. You may find multiple tests, that focus on specific areas of the plan, are useful. You should schedule tests at least twice a year.
Update the Plan Regularly
Following each incident response test, review the plan and update it with what you learned. It’s important your incident response team conducts regular reassessments of the threats and risks your organisation faces. If you learn that email fraud or business email compromise attacks are an increasing risk, then your plan should be adjusted.
An incident response plan is not a static document that gathers dust in the hope that a cybersecurity incident never occurs. It is a living document that is regularly tested and reviewed to ensure it is ready should an attacker target your organisation.