“Never confuse a single defeat with a final defeat.”
—Scott Fitzgerald
On May 31, 2017, OneLogin, a San Francisco–based software security company that specializes in managing logins to applications and multiple websites, reported a data breach where threat actors allegedly may have attempted unauthorized access to OneLogin data and networks. The full extent of this breach is currently not known. However, OneLogin is sold as software to help increase a person’s overall security. There is no doubt that people started questioning the effectiveness of OneLogin security solutions after the data breach occurred. Evidence of this can be seen on Reddit discussions found on discussion forums at www.reddit.com/r/technology/comments/6emqwz/password_manager_onelogin_admits_data_breach_in/.
Fool.com reported in an article posted on May 27, 2014, how a cyberattack exposed 233 million registered eBay accounts. The article criticizes eBay’s handling of the breach, claiming it took nearly three months to notice the breach and two additional weeks to report it (www.fool.com/investing/general/2014/05/27/ebay-data-breach-response-teaches-everyone-how-not.aspx).
An article in TechCrunch on February 2, 2017, reported that Verizon knocked off $350 million US in its offer to purchase Yahoo!, after Yahoo! suffered two massive data breaches. Many security professionals questioned how well Yahoo! was handling security for its own users after these breaches were disclosed (techcrunch.com/2017/02/21/verizon-knocks-350m-off-yahoo-sale-after-data-breaches-now-valued-at-4-48b/).
These examples show how critical it is to respond to a breach correctly and effectively. Many organizations have completely tarnished their reputation, lost customers, and in some cases, never been able to fully recover after a large-scale data breach. Many of these pitfalls could have been avoided with the proper incident response plans and techniques.
Digital forensic network engineers are involved in part of the process of responding to a data breach. In many cases, their role is much more technical in providing the details around the breach. However, in this chapter, we look at the full scope that is normally required when organizations respond to a breach. This allows a network engineer to fully understand the process and ensure specific tasks meet the needs of the organization during an incident. It is important to point out that incident response is different from digital forensics; however, many incident response plans include using forensics to understand what occurred, proving theories about the incident, or preparing for potential future legal action.
This chapter provides an overview of the incident response process from a managerial point of view rather than a technical one. As a network engineer, you will be engaged in a small portion of the entire incident response process, but we believe it is important for you to understand the challenges that organizations face when building an incident response team (IRT) and engaging in the process. Remember that technical services should always track back to a business goal to be relevant. Understanding this will help maintain funding and support for your forensic practice.
The goal of this chapter is to make sure you understand why organizations fail at the process when responding to a breach and examine the techniques used by organizations that have a successful incident response plan. We have combined several accepted frameworks published on building a successful incident response team to develop the content for this chapter. We have additionally added our own experience as well as an overview on industry-proven components required to build an incident response process within your organization.
In Chapter 5, “Investigations,” we go into the technical details for an investigation that are relevant to network engineers. This includes software used by network engineers when responding to a breach and how to use that software when collecting, preserving, and analyzing evidence. You will use the techniques in Chapter 5 to provide detailed evidence and telemetry data needed by incident response teams at different stages of their investigation, which are outlined in this chapter. Before we do that, let’s step back and examine the basic concepts for proper incident response procedures.
Why Organizations Fail at Incident Response
Any organization or business that has had to deal with a cyberbreach understands the stress that accompanies the process, no matter how well prepared or rehearsed it is for cyber events. All breaches come with their unique set of challenges and requirements. The stakes are high because the public can lose complete trust in a company brand, liability can hurt an organization financially, and being complacent may lead to criminal neglect. With so much at stake, you may think that organizations would be well prepared to deal with cyberbreaches. The sad truth is that they are not. Many organizations don’t want to deal with the problems, efforts, and cost required to develop a true response plan for a potential data breach. The idea of a data breach scares organizations, and many of them would rather bury their head in the sand rather than face the reality, which is that they need significant work to prepare a proper incident response plan. We have questioned hundreds of organizations about their incident response plan while evaluating their security and have received answers such as “What incident response plan?” or “We call John in IT and he handles everything.”
When Hollywood Presbyterian Medical Center paid approximately $17,000 US in early 2016 to remove ransomware, it did so because it could not provide the best patient care services to its customers (www.latimes.com/business/technology/la-me-ln-hollywood-hospital-bitcoin-20160217-story.html). The medical center, its reputation, and the public’s trust for the organization are immediately put at risk after these types of attacks occur. Some organizations believe that hiring a security services company and keeping it on standby as much preparation as they might need for a future incident. Organizations simply cannot rely on having an expert on retainer and buying cyber insurance as their method to respond to a breach. Not having an incident response process could represent a lack of due diligence for enforcing the minimal level of required security and could cause the company to be legally liable regardless of what services are outsourced. Many insurance companies engage a third-party auditor to validate existing controls, which means you need to ensure that you have not only technology in place, but also an acceptable incident response plan.
Many organizations see information technology (IT) investments and, by extension, IT security as costs they can reduce. With the intention of creating better efficiencies, some organizations implement defensive solutions that consolidate or eliminate security programs. This includes sacrificing a complete IT data security program responsible for security awareness, incident response, and breach reaction components because they do not think they will need it or are under the impression that their existing solutions and polices already address these problems. Many enterprise corporations have been guilty of failing to budget a plan because they believe the massive amounts of investments they have made in regulatory and compliance practices, such as HIPAA and PCI DSS, have given them adequate protection and responsive capabilities to deal with a breach. If you recall from our previous chapters, compliance should be your minimum level of security, which means it should not be where you stop your investment, because many of these programs use dated material and just are not good enough to prepare you for real-world threats. The truth is that many compliance programs are not risk based but are written as a one-size-fits-all approach. Every organization is different and so are the vulnerabilities, so you need a tailored program based on your business requirements to be successful.
It is common for organizations to simply overestimate how capable they are in responding to a breach. Many branches of the US government run “tabletop” exercises to practice their incident response capabilities. According to Ready.gov, “Tabletop exercises are discussion-based sessions where team members meet in an informal, classroom setting to discuss their roles during an emergency and their responses to a particular emergency situation. A facilitator guides participants through the discussion of one or more ‘scenarios’” (www.ready.gov/business/testing/exercises). These simulation exercises can include situations such as a major power outage, outbreak of diseases, and even cyberattacks. The idea behind tabletop exercises is well intentioned, meaning it is designed to prepare for a real event, but it is not close to a true penetration test or what a red-team-blue-team (attack and defend) training program would offer. In some cases, using tabletop conversations as the only training could provide a false sense of how prepared an organization is for a real cyber incident.
Organizations fail at adequately preparing their programs by not havening continuous, ongoing training. Training exercises should not be treated as special events. Organizations should build continuous training and response procedures that are embedded into an organization’s standard operating procedure. Training should combine the practical, technical, and business aspects of responding to a breach by all team members involved. When should organizations train their incident response teams to respond to a breach? All the time.