28 July 2017

Everyone gets breached, so you’ll need an response plan when it happens

Liam Tung

Your organization has just discovered a serious data breach. Does it have a well-oiled plan to respond without ruining forensic evidence, creating a public relations nightmare, or frightening customers?

The last thing an organization needs is hysteria when coordinating a response to a major data breach. There may be unwanted press coverage, questions from regulators and shareholders, and jittery customers and partners. It will require a cool-headed response coordinated among cyber security, legal, communications, IT, business and others.

A bungled response will only make the situation worse, possibly resulting in lost evidence, damaged trust and a waste of critical response time. Poor incident response can include ignoring vulnerability reports from security researchers, suing people who report bugs, and the all too common problem of failing to grasp the full extent of a breach. 

Recent breaches highlight that organizations of all sizes in every sector can be hacked, whether it’s manufacturing firms, telecoms, finance or tech. Yahoo only discovered last year that breaches in 2013 and 2014 affected a billion users. The breaches resulted it a $350 million discount in the Verizon merger, illustrating the risks to finances, reputation, intellectual property, and customer data.

While an organization may be judged on its security defenses, a good incident response plan could minimize the overall impact of a breach. On cost alone, the IBM and the Ponemon Institute 2016 Data Breach Study: Australia found that having an incident response plan reduced the $128.50 cost per person by $12.70 per person. The only other single factor that could have reduced the cost by more was extensive use of encryption.

Unfortunately, many organizations still lack even a basic incident response plan. Ernst and Young’s 2016-17 Global Information Security Survey found that 79 percent of organizations test employees with phishing, and that more than 80 percent did threat intelligence analysis and incident investigation. Yet just 24 percent had an incident response plan for a cyber breach.

Organizations need to have a well-oiled incident response plan that not only looks good on paper but is tested to withstand the pressures and uncertainties of a real incident. Yet this is where many organizations fail.

“Either they don’t have an incident response plan and haven’t done the basics, or if they have a plan they haven’t tested it recently,” Aaron Sharp, a security solutions consultant with Verizon Enterprise Solutions told CSO Australia.

“Some of the less well-resourced organizations don’t have clear roles and ownership. When you have an incident, the person responsible is playing it part time, so they’re not necessarily well-versed on what they need to do, and it also means they’re distracted by their day job,” he said.

Fail to do the groundwork with stakeholders, and a breach will likely result in panic and avoidable errors.

“Things rarely go well when the response becomes a panic drill and it often leads to number of mistakes,” Jeremiah Dewey, director of incident response at Rapid7, told CSO Australia.

“Two big ones we see frequently are hasty remediation of the event, driven by incomplete scoping, and late or insufficient notifications to internal and external stakeholders.”

“A lot of the time, organizations do not take the time to prepare properly for an incident, and as a result, they inevitably go into panic mode when an incident occurs,” he added.

A lack of preparation can also result in basic errors that hamper the investigation and later forensics, says Ty Miller, CEO of Australian security firm Threat Intelligence. 

“The most common mistakes include unintentionally destroying evidence by turning systems off or reinstalling servers, insufficient log collection meaning that malicious activities cannot be tracked, missing threat detection capabilities, and baseline security controls to monitor attacks,” Miller told CSO Australia.

“When a security breach occurs, it is common for organizations to scramble around to buy hard drives for evidence storage, and buy software for server image captures and forensic analysis. This delay in getting started can lead to evidence being deleted and larger impacts to the organization,” he added.

Avoiding a ham-fisted response

To get the ball rolling on an incident response plan, Verizon Enterprise’s Sharp recommends organizations undertake cyber-war gaming or post-breach simulation. This will help the business understand the impact on different attacks as well as help define who, when and where key people should become involved. 

“Organizations need to know at what decision points they need to involve other parties, both internal and external, whether it’s legal counsel or law enforcement. One useful way for them to do that is through breach simulations, so you can take scenarios that are relevant to a business and war-game it in a room,” said Sharp. 

Cyber war-games could also have other benefits. Many boards still don’t recognize that cybersecurity can impact more than just IT, nor that it involves more than investing in security controls. Developing and testing an incident response plan could help engage the business and board by clearly demonstrating the links between incidents and their consequences.

The World Economic Forum (WEF) recently recommended using cyber war-gaming covering incident response, disaster recovery and business continuity to educate and involve board members. It would give executives insight into how cyber attacks unfold, the range of their impacts, and what could be expected of them in dealing with law enforcement, regulators, shareholders, employees, and customers, the WEF noted.

It also offers a chance to look at cybersecurity through the framework of profit and loss, liabilities to the company and board members after a breach, and ask what systems are in place to respond to a breach. 

These war-gaming exercises could look at a number of different incident types to understand the likely impact on the business and risk areas.

Sharp says Verizon Enterprise Solution’s top six incident patterns included insider and privilege misuse, cyber-espionage and targeted attacks, web application attacks, criminal malware, such as banking malware and ransomware, point of sale attacks leading to payment card data, and denial of service attacks.

While these terms are commonly known among cyber-security professionals, it could help draw the connection between more commonly understood risks, such as that fraudsters can and do trick employees into wiring money offshore, remote tech support scams do target employees, and that public relations problems can lead to a hacktivist campaign against the organization.

Developing an incident response plan will depend on each organization’s requirements and risks, but Rapid 7’s Dewey notes there are common goals that all organizations should work towards. 

“Ultimately you are looking to achieve confidence and peace of mind for your organization’s leadership and customers. It’s always important to check the compliance boxes to meet control requirements, but that should not be the only goal. Plans should also be crafted with the goal of protecting the organization’s critical assets and enabling effective sharing of information when incidents do happen,” he said.

Threat Intelligence’s Miller said the plan should aim to minimize the impact of a security breach to the organization. 

“This is achieved by defining prerequisites to ensure that all data required for the investigation is available, creating a dedicated incident response team who are trained in how to respond, and defining clear procedures for each team member on what they need to do to contain and eradicate the breach whilst minimising the impact to the organisation.”

For Verizon Enterprise Solution’s Sharp, the incident response plan should clearly define each stakeholder’s roles and responsibilities, communication paths, and escalation procedures. A potential good start for organizations creating on a new plan is to borrow the structure from other incident response areas, such as health and safety. 

“What we see is many organizations have physical health and safety incident response plans, and they align their cyber response plans to these processes albeit with different stakeholders. If you already have a corporate process in place, it’s better to modify that to fit cyber than to start from scratch,” he said.

Exactly who should be responsible for incident response really depends on the size of the business.

“Where large companies will have a dedicated SIRT Manager with a team of specialised staff, and smaller organisations will assign responsibility to the IT manager and support team,” said Miller.

Dewey adds that while it is a good for the information security team to initially develop the plan, execution should be a shared responsibility, involving legal, a cyber insurance provider and external incident response providers if an organization has these. It should also involve the IT department, which could isolate or confiscate equipment, and the communications team for keeping an eye on external chatter, answering media inquiries, and crafting notifications. 

Allocating responsibilities across teams could help avoid the problem of incident response plans becoming lost in documentation that is too generic, or too narrowly defined for being useful across multiple groups. The other risk is that too much knowledge lies with too few people.

“It sounds cliché, but creating an incident response plan really is a shared responsibility,” said Dewey.

How do you know if the incident response plan will hold up? 

The post-WIkiLeaks concept that there is no such thing as security anymore has seen many organizations adopt the so-called ‘assume breach’ mentality. While it’s been adopted in marketing, it remains a useful concept for recognizing that organizations shouldn’t only spend money on hardening the perimeter, but also need to monitor the effectiveness of system security and focus on people and processes, including incident response. 

“Putting some resources into prevention is still important, but security teams are learning have to dedicate resources to detection and response as well. Ultimately, organizations are coming around to the idea that they can’t simply prevent being stung by an attacker, but they can take measures to reduce the pain when that sting does happen,” said Dewey.

Factoring this mentality into an incident response plan will require the organization clearly define what events or incidents will warrant exploring the response. Dewey argues that since events are likely always occurring, triaging of these events should be happening on an ongoing basis. 

“Successful incident response teams are good at triaging those events to determine what are benign and what require investigation. This process is vital to knowing when the response process should be activated. Incident response plans can include event triage and incident scoping in their workflows, so in many cases they are actually activated continuously,” he said. 

Miller adds that specific indicators that point to say a distributed denial of service attack, a spear phishing campaign, or a physical breach should be mapped to the relevant response.

But no matter how well the incident response plan is documented, its ultimate test is whether it is used during a crisis.

“I have seen some very impressive plans that cover many areas and obviously took significant resources to create, yet organizations do not actually use them,” said Dewey.

Two useful metrics for evaluating how well the organization handles a crisis include the time to contain an infection, and the number of re-infections. This means looking at response with project management concepts, such as critical path items, to help determine the speediest alternative route to complete a project. 

“If you can time each step within the process, you can eventually compile metrics that tell you how efficient your team is. I always caution against making judgements solely based on these metrics, though, because each incident can vary greatly in scope and complexity,” said Dewey.

Miller says that organizations really need to develop a business impact analysis that illustrates the impact of a disruption to a critical business operation, such as the impact of an outage on revenues, and privacy breaches that lead to fines and compliance impacts.

No comments: