Big Breaches: Cybersecurity Lessons for Everyone

By Neil Daswani and Moudy Elbayadi

The cybersecurity industry has seen an investment of over $45 billion in the past 15 years. Hundreds of thousands of jobs in the field remain unfilled amid breach after breach, and the problem has come to a head. It is time for everyone—not just techies—to become informed and empowered on the subject of cybersecurity.

In engaging and exciting fashion, Big Breaches covers some of the largest security breaches and the technical topics behind them such as phishing, malware, third-party compromise, software vulnerabilities, unencrypted data, and more. Cybersecurity affects daily life for all of us, and the area has never been more accessible than with this book.

You will obtain a confident grasp on industry insider knowledge such as effective prevention and detection countermeasures, the meta-level causes of breaches, the seven crucial habits for optimal security in your organization, and much more. These valuable lessons are applied to real-world cases, helping you deduce just how high-profile mega-breaches at Target, JPMorgan Chase, Equifax, Marriott, and more were able to occur.

Whether you are seeking to implement a stronger foundation of cybersecurity within your organization or you are an individual who wants to learn the basics, Big Breaches ensures that everybody comes away with essential knowledge to move forward successfully. Arm yourself with this book’s expert insights and be prepared for the future of cybersecurity.

Who This Book Is For

Those interested in understanding what cybersecurity is all about, the failures have taken place in the field to date, and how they could have been avoided. For existing leadership and management in enterprises and government organizations, existing professionals in the field, and for those who are considering entering the field, this book covers everything from how to create a culture of security to the technologies and processes you can employ to achieve security based on lessons that can be learned from past breaches.

• Language: English
• Publisher: Apress
• Release date: Feb 24, 2021
• ISBN: 9781484266557

Book preview

Part IBig Breaches

© Neil Daswani and Moudy Elbayadi 2021

N. Daswani, M. ElbayadiBig Breacheshttps://doi.org/10.1007/978-1-4842-6655-7_1

1. The Root Causes of Data Breaches

Neil Daswani¹   and Moudy Elbayadi²

(1)

Pleasanton, CA, USA

(2)

Carlsbad, CA, USA

What are the root causes that have allowed attackers to break into so many organizations? This chapter mainly focuses on six technical root causes. Before delving into those, we first discuss three of the meta-level root causes: failure to prioritize security, failure to invest in security, and failure to execute on security initiatives. For anything important in life or business, one may argue that these three types of failures (to prioritize, invest, and execute) can apply to almost anything, but we will cover some of the specifics to security in this chapter.

Pragmatic Root Causes

In our practice as security and technology professionals, we arrive at root causes by asking why several times in postmortem meetings after things go wrong. We have been trained to not stop after the first answer, even if it is the easy and obvious one, but not thorough enough to get to the core of the issue.

The Six Sigma system used by General Electric and other companies proposes asking why five times, but one critical point of root cause analysis is knowing when to stop asking why.¹ If one asks why a breach occurs enough times, say five, a meta-level root cause of security not getting prioritized, invested in, or executed on sufficiently at an organization may result. However, even in organizations where security was generally getting some level of prioritization, on perhaps the third or fourth why being asked, one might find a more technical root cause—for instance, an employee fell susceptible to a phishing attack, and understanding the technical root causes can help organizations that prioritize security put in place appropriate countermeasures.

If you ask why too many times, it may reveal a cause such as authentication was not designed into SMTP. (SMTP stands for Simple Mail Transfer Protocol and is one of the most basic protocols used for sending email on the Internet.) However, redesigning the Internet is not practical, and a cause at that level is not practically useful for most security leaders or professionals in any organization. Hence, in our analysis of big breaches and the 9,000 other reported breaches that have taken place over the past 15 years, we focus on asking why enough times to produce root causes that are practical and useful that most organizations can do something about. With that disclaimer, we now delve into our discussion of both meta-level root causes and six technical root causes that are at the core of most breaches.

Meta-Level Root Causes: Prioritization, Investment, and Execution

In Chapter 6, we will learn in detail about the breach that occurred in 2015 at the US Government’s Office of Personnel Management (OPM), the organization that holds the personnel records of a majority of US government employees and contractors. The OPM’s 21.5 million personnel records are made up of, in part, detailed SF-86 background check forms used for national security positions. SF-86 forms, to start with, contain social security numbers, names, addresses, places and dates of birth, and employment history. They also contain intimate details about the employee’s personal life, family members, college roommates, foreign contacts, drug use, mental health and psychological information, and adjudication information. Adjudication information encompasses a very significant amount of extra vetting information for employees who need access to classified information. The adjudication information includes data on sexual behavior, some polygraph (lie detector test) examination results, and any potential evidence of foreign influence.

Although some government agencies (e.g., the Central Intelligence Agency) maintain their own personnel records, a foreign nation-state that had possession of the OPM data could simply look at which people stationed in their country were on file with the State Department and deduce that a particular person was a CIA agent (and potentially a spy) by observing that a corresponding record was not present in the OPM data set.

The stolen data also contained over five million fingerprints, and such data could be used to potentially dupe biometric authentication systems. Unlike password credentials, which can be changed if and when they are stolen, people cannot change their fingerprints. Even if secret agents can change their names, they cannot change their fingerprints. The stolen fingerprint data can be useful to the attackers or to buyers of the data for years.

The stolen records not only contained data about the individual government employee but their family, their friends, and even their neighbors. Although we leave the bulk of the case study of that breach to Chapter 6, one of the meta-level root causes was OPM’s failure to prioritize its own security, as per the House Oversight Committee report that was published after the breach:

Despite this high value information maintained by OPM, the agency failed to prioritize cybersecurity and adequately secure high value data.

The result was:

The intelligence and counterintelligence value of the stolen background investigation information for a foreign government cannot be overstated, nor will it ever be fully known.²

In more colloquial terms, the stolen data could potentially be used to allow the attackers to identify US spies operating in a foreign nation-state, monitor or track US spies operating internationally, or even be used to attempt to mint spies of their own in our country by using the stolen identity metadata to have their spies apply for government jobs in US organizations.

In 2017, a Chinese national by the name of Yu Pingan suspected of creating the malware used in part to conduct the OPM breach was arrested by the FBI, and in 2018 National Security Advisor John Bolton confirmed that the foreign nation-state suspected to have conducted the attack was China:

You may recall seeing about the hacking of the Office of Personnel Management by China, where potentially millions of personnel records—my own included, and maybe some of yours, from former government employees—has now found a new residence in Beijing.³

Chapter 6 covers in detail how a meta-level lack of prioritization of security at OPM led to many technical root causes exploited by the Chinese.

Once a goal is prioritized, a commensurate level of investment can then be allocated to it. But the goal needs to be prioritized first. Prioritization requires getting buy-in and agreement from stakeholders. The top-level prioritization of initiatives at a company comes from its Chief Executive Officer (CEO), with input from the company’s board of directors. Company-level priorities may often include revenue goals, product and feature launch commitments, and growth of active users or increased number of customers. Security goals and initiatives can be complementary to such goals, but may compete. A penetration test that is conducted on a product in development before its launch may uncover a critical vulnerability that may take some time to fix. If the launch of the product was originally promised on a particular date, that date may need to be delayed if it is to be launched free of vulnerabilities.

When it comes to prioritization of security, there may also be bottom-up influence that may come from a Chief Information Officer (CIO), Chief Technology Officer (CTO), or Vice President of Engineering. Upon asking for such prioritization from a bottom-up source, the CEO may provide appropriate support, including funding. Any of the members of a C-Suite (as well as a board of directors) may also be influenced by federal regulation or by events that are taking place in the market landscape. Irrespective of how security goals get prioritized, once prioritized, the goal needs to be funded.

One of the first things that should be funded once the goal of security is prioritized significantly enough within an organization is hiring an information security leader, such as a Chief Information Security Officer (CISO),⁴ if one is not already employed by the organization. However, simply hiring or having such an executive is not enough if the individual is not set up or empowered to succeed. Funding may also be required for an adequately sized information security team, tools and technology, and other capital and operational expenditures (e.g., consultants or contractors, a security operations center, etc.) to support the security team and its goals.

We would also like to note that there are four different types of CISOs and security teams, as per a research report led by Dr. Gary McGraw, Sammy Migues, and Dr. Brian Chess, entitled the CISO Report: Four CISO tribes and where to find them.⁵ In the report, an organization can view the security team and its leader (1) as an enabler, (2) as a technology function, (3) as a compliance function, or (4) as a cost center.

Organizations that are most mature with regard to how they view security have a CISO that is a seasoned senior executive, who may have a deep technical past, but focuses their time on how good security can help enable positive results for the business. Organizations that view security as a technology function may have a CISO with solid business skills, but is known primarily for their technical work. A technology-focused CISO will often implement technical countermeasures to achieve security as they continue along the path of becoming a more seasoned executive. Organizations that view security as a compliance function often have a CISO that is an excellent administrator and may not have a deeply technical past. Finally, organizations that view security as a cost center have a security leader (who may or may not have the title of CISO) that is primarily a technology person and may report into the information technology department. Leading organizations typically view security as an enabler or as a technology function and have a corresponding type of CISO.

We’ll first cover some things that can be done to help best set up a CISO for success for organizations that don’t just view security as a compliance function or as a cost center. To start:

1)

Have the CISO report to the CEO (at least dotted line reporting if not solid line reporting). If an organization truly believes that security is a top priority, say just as high a priority as its finances, its human resources, its technology, and so on, then a CISO should report to a CEO just as a Chief Financial Officer, a Chief Human Resources Officer (CHRO), or a Chief Technology Officer does.

2)

Have the CISO present to the Audit Committee (or ideally a separate cybersecurity-focused, board-level committee) at least once per quarter. The Audit Committee is usually a subset of the board of directors that receives reports on a company’s financial audits. In the wake of the Enron scandal in 2001, the Sarbanes-Oxley (SOX) regulation requires companies to have controls in place to ensure the data integrity of financial reporting and accounting, as well as audits of those controls. The role of the Audit Committee typically broadened in most companies after the creation of SOX