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.
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 U.S. Government’s Office of Personnel Management (OPM), the organization that holds the personnel records of a majority of U.S. 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 Department of State 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 employees 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 U.S. spies operating in a foreign nation-state, monitor or track U.S. 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 U.S. 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 Federal Bureau of Investigation, 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.
Investing in Security
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, 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, chief technology officer 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, if one is not already employed by the organization. While we use CISO here, the security leader could be a CSO (chief security officer). One potential difference between a CSO and a CISO is that a CSO typically is also responsible for physical security. For the purposes of the discussion here, we use CISO and CSO interchangeably, as for most such security leaders, the bulk of the time in their role is spent on information security.
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.
Empowering a 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 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 regulations.
Although the audit committee is part of the management structure that is tasked with reviewing financial audits, a review of cybersecurity audits has also become a key part of the audit committee’s purview. When the audit committee gets a view into the state of an organization’s information security program, it can have significant influence on the CEO’s prioritization and the top-level approval of budget to fund information security initiatives. Hopefully, in the future, more companies will adopt cybersecurity-specific board-level committees to focus on the topic.
3. Have the CISO present to the entire board of directors (typically a superset of the audit committee or a cybersecurity-focused committee) at least once per year, if not more often as needed. If a company is about to launch significant, new products or services that may alter its security exposure, is facing potential regulatory action or has recently had significant security incidents or breaches, having the CISO spend more time with the entire board of directors is likely warranted.
4. Give the CISO their own budget, team, and decision-making authority. Some CISOs, especially when the profession was younger, may only have been “influencers” with a title but not budget or decision-making authority. Such CISOs typically had an uphill battle executing on security initiatives.
Beyond hiring a security executive, and setting them up to succeed as mentioned earlier, we cover additional information regarding how a typical information security team is organized in Chapter 16.
How Much Is Enough?
How much should an organization invest in security, including the security executive, their team and additional tools and technology support? The answer to that question is more art than science, but there are data-driven ways to approach it. For instance, for any given organization, look at how much similar types of organizations invest in security. In 2019, as an example, financial services companies spent, on average, 10 percent of their information technology budget on security, as per data from Deloitte and Touche.
Of course, if the average organization is getting breached, and an organization is only spending the same amount as the average organization in a particular sector, chances are that organization is going to get breached as well. So, while statistics from firms such as Deloitte and Touche can be used as a benchmark, one might consider spending more (or even significantly more) than the averages if one wants to be more secure than their peers and/or have a shot at not getting breached as easily. That said, simply spending more may not achieve the goal of lowering the probability of breach if the money is not getting spent in the right areas. Focusing spending on addressing root causes of breaches is likely worthwhile in helping lower the probability of a breach. Every organization, though, is unique, and understanding what is the level of maturity of different aspects of its information security program is a good precursor to determining where further spending is likely to make the biggest difference. Once a baseline understanding of a program’s maturity level is done along areas such as governance, application security, operations and incident management is done, then gaps or additional capabilities needed can be identified, and further investment can be made to address those gaps or additional capabilities needed.
What particular areas and functions of a business may require investment to achieve better security? That depends on, as covered in the introduction, what an organization’s crown jewels are, what it is trying to protect the most and what is the organization’s current level of maturity with regard to protecting against those threats, among other factors.
One can look at how much revenue a company earns, what is its valuation and what is the risk posed to the organization due to information security threats and make a back-of-the-envelope calculation as to how much should potentially be spent on security. Once security has been prioritized and been allocated enough investment, it is then a matter of execution.
Execution in the area of security bears enough similarity to execution in other areas, though, that we will not spend much time discussing it. Execution on security initiatives may typically involve a significant amount of cross-functional effort. Depending upon the initiative, the CISO’s team will have to partner very closely with the CIO’s team, legal, and program management, among other departments. The CISO’s team may typically comprise mostly experts in different aspects of information security and may need to significantly influence other teams to get work done toward achieving security goals.
The CISO’s team may or may not directly have the tactical horsepower that is required to actually do all the execution on any particular project. One analogy to keep in mind may be to think of the CISO’s team as the Jedi from Star Wars. There are relatively few of them in number, and while they may have deep mastery of their art (or religion), they can only help lead the clone army and other disciplines in battle. There are typically not enough Jedi or security professionals to actually fight all the battles themselves.
* * *
Excerpted from Big Breaches: Cybersecurity Lessons for Everyone by Neil Daswani and Moudy Elbayadi, to be published on March 11, 2021, by Apress. Copyright © 2021 by Neil Daswani and Moudy Elbayadi. Excerpted by permission of Apress. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
