How should one calculate the cost of a cybersecurity breach? Is it through brand and reputation damage, loss of important data, paying a ransom, or impact on operations? These factors all depress a company's bottom line. But recovery is the real financial dark horse of a breach, and most organisations are unprepared for such an event.
If you want to judge an organisation's security readiness, ask to see its response plan. They may have installed the best and most expensive systems, but the lack of a plan shows they aren't prepared for the worst.
Let's say the targeted company's security systems uncover a breach attempt. Now what happens?
Hunting cybercriminals is a cat-and-mouse game. They expect to be caught (in fact, in a ransom, they have told you they are in). Discovering a breach is only the start. Now we must determine the extent of the breach, the damage already done, the affected systems, the data exfiltrated, and any persistence the attackers may have installed and how all of these impact business operations and the recovery of those systems.
The criminals will accelerate their assault. There is no time to waste. Much like a sports team facing determined opponents, winning requires being ready.
A famous boxer once said, "Everyone has a plan until they get punched in the face." But a plan is, in reality, one of the best mechanisms to respond to a breach, evict the attacker and recover the business. Companies with a response plan can react and get ahead of the attackers. They spend less on forensics and incident response, and they have better data to grasp the scope of the breach.
Hence why every business should have a security response plan.
What does this plan look like? The National Institute of Standards and Technology (NIST) defines four stages: preparation and prevention; detection and analysis; containment, eradication, and recovery; and post-incident activity. But what are the specific ingredients?
Objectives: The primary goal of a plan is to keep people safe and minimise the harm caused by an incident. Start by defining the plan's objectives, such as minimising the incident's impact, restoring systems and data, and containing the breached systems. Plan for worst-case scenarios, such as losing backups (a step often taken for granted), and look at required resources; for example, do you have sufficient network and firewall bandwidth for disaster recovery traffic, do those firewalls have more restrictive and secure rules so you're not restoring into an even-less secure environment?
Response team: A breach affects multiple areas of a business, and recovery is not solely the responsibility of technology teams. Establish a response team with members with the necessary expertise and authority to execute the plan. Team members include IT, security, legal, communications, and finance. Train these members for their roles in the team, and conduct regular tests to ensure they are confident of their contributions.
Incident Response process: Incident Response (IR) is a nuanced part of a breach response. It has two components. The first consists of IR professionals; due to their specialised skills, they are typically outsiders working through a security partner. The second is the IR process, which includes steps for identifying the type and scope of the incident, containing and isolating the affected systems, investigating the incident, and restoring systems and data.
Skills & partners: Leveraging security partners and their skills are often crucial to incident response plans. Most organisations do not keep specific security and incident response skills in-house. The right security partner can bring those capabilities to the table. But engaging such services will become significantly more expensive if there are no prior arrangements and preparations with the partner. IR and recovery is a marathon, not a sprint; it will quickly drain your existing team's capacity through network, desktop, patching, and management demands. It's best to ensure you have access to additional technical skills you can call on as needed.
Communication plan: Companies must communicate the breach situation's progress to insiders, such as business leaders, shareholders or affected staff, and outsiders, such as regulators and the media. A communication plan covers these requirements. It states who has the authority to determine the proper communications and protocols for engaging with regulators and law enforcement. Communication should be done clearly, early and continually while protecting the company's interests during a high-pressure and fast-changing crisis.
Reporting requirements: Aside from communications, the plan should define reporting standards to record the incident. Standard elements include incident reporting procedures, timelines, and formats. There will also be different reporting requirements and intervals for business audiences, IR teams and regulators, and the response team should understand reporting expectations. Don't forget about post-incident reports; these will help prepare for future incidents.
Review: A good incident response plan is a living document. Once created, it benefits from regular reviews and updates—ideally quarterly, but annually can also be sufficient. Revise the plan whenever there are changes to the organisation's systems or key personnel. Also, revisit the plan if new security risks emerge from the investigations. In many cases, we see IR containment efforts limited to only treating the symptoms of the initial attack vectors. They don't fully leverage the business support received during an incident to harden the environment or maintain that new standard on an ongoing basis. This can be a recipe for disaster, but regular planning reviews ensure an effective and lasting response.
Comments