Preface

Throughout my career, I have been challenged to find ways to present the computer security, then the information security, and now the cybersecurity landscape to those outside the profession. Newcomers to the field of cybersecurity generally start in low‐level positions where it is hard for them to see the ubiquitous reach of a cybersecurity program within the larger enterprise. One of my first attempts to explain this in a formal setting is illustrated in Figure 1 (Bayuk 1996). The outer circle of the figure depicts components that would be applicable to a variety of management domains holistically at the business process level, with the inner circle of cybersecurity operations support nested firmly within it. This diagram was adopted by the Information Systems Audit and Control Association (ISACA) when it developed the Certified Information Security Manager (CISM) program, and some form of it has been in ISACA CISM training materials ever since (Bayuk 2004).

As in any risk management discipline (credit risk, for example), a cybersecurity program composition starts with strategy. In consultation with business objectives, roles and responsibilities for accomplishing cybersecurity risk reduction will be assigned, and business leadership in those areas will formulate a strategy for making it happen. That strategy is communicated to stakeholders to formally enlist their cooperation, and, just as with any other risk management discipline, this ends up as management mandates in a cybersecurity policy. That policy is then supplemented with awareness activities (e.g., training) so that people who need to implement the policy, both cybersecurity staff and others, understand what they need to do to comply with the policy. Following the implementation of a policy, operations processes are developed to support the business with standards, automation, and procedures that accomplish risk reduction. Activities are monitored to make sure the cybersecurity operations have the desired effect of accomplishing cybersecurity policy and reducing cybersecurity risk.

If policies are monitored for gaps, such as blatant violations of policy and/or successful cybersecurity attacks, when gaps are discovered, the cybersecurity team should fall into a compliance mode or a remediation process. A remediation might entail a simple fix of broken software to ensure the enterprise is in compliance with policy and at lower risk for a security breach. In more serious cases, it may be that the policy adopted at the executive level did not result in a strategy that worked. So we may have to go back and look at our strategy. This iterative cycle is the same in any business operations, articulated by the familiar Drucker and Deming strategy taught in business schools, namely, plan‐do‐check‐act management by observation, process, and controls. Cybersecurity uses all the same strategies common to any type of management activity. It is unique in that the domain is technically challenging and constantly changing, and the goal is to maintain cybersecurity and internet safety.

Figure 1 Cybersecurity Processes.

Of course, given that the discipline of cybersecurity is relatively historically new, decisions on cybersecurity strategy are not easy. However, steady increases in the number and breadth of cybersecurity attacks have placed increased focus on the process by which business management decides to implement security measures. Therefore, decision theorists often step in and try to help with cybersecurity problems. There is not as much debate on the actual process of decision analysis. A common method of analyzing decisions presents it as a five‐step process (Keeney and Raiffa 1993):

1. Pre‐analysis: decision‐maker identification,
2. Structural analysis: the decision‐maker structures the problem as a series of decisions and events, where the certainty level of events is affected by decisions,
3. Uncertainty analysis: event probabilities are assigned,
4. Utility or value analysis: consequences are identified for alternative decision/event sequences, and the values of those consequences are estimated, and
5. Optimization analysis: the strategy that maximizes utility.

Though the cybersecurity field itself has yet to yield a standard on decision‐making or even a set of preferred decision theories, decision theories tailored to other fields have been applied to computer security, information security, and cybersecurity for decades. A wide variety of academic papers have been devoted to applying the decision theory of the moment to information security. Virtually none have been adopted by experts in the field, but some that have been proposed are portfolio theory, value‐focused thinking, prospect theory, game theory, marketplace models, utility theory, and Markov models. Though influential and to some degree successful in solving problems in domains other than cybersecurity, when applied to cybersecurity, the experiments varied widely with respect to (1) where the alternative decision choices should come from, (2) methods of reducing uncertainty, and (3) criteria for optimization analysis.

Through all this academic analysis of cybersecurity decision‐making methods, the cybersecurity profession itself has held firm to a common approach, one based on the application of safety risk analysis to security risk (Bennett et al. 1975). This appears to be a straightforward reliance on probabilities of incidents based on historical data and seems to be the origin of the cost‐benefit analysis equation so common in information security publications and standards. In this example (Endorf 2004), it is summarized in mathematical terms as follows:

F = expected frequency of attempts to produce an event that may cause damage

P = probability of success of the event if attempted

I = quantified consequences (i.e., cost) of a successful event

Specifically, F is calculated by estimating the likelihood of a given type of security threat enactment in a given period of time; P is calculated by estimating the extent to which threat actors will achieve attack objectives, given the existing security measures; and I is calculated by estimating the monetary losses that could arise from that security event. Note that the resulting value is not actually a risk as defined in professional risk management standards. In that community, “risk” is defined as the probability that an event in a certain category may occur (positive or negative) and is measured in probability, not cost (COSO 2017). This cybersecurity equation, viewed in the light of risk management standards, refers instead to an estimate of the comparable value at risk.

In cybersecurity, the variables in this risk calculation are often renamed to reflect the nomenclature of the domain. Frequency is referred to as Threat; Probability is Vulnerability; and Consequences as Impact. The result is an equation that looks like:

The calculation is typically made in the context of annualized loss versus future return on investment in cybersecurity technology (Borg 2009). The resulting Risk value is then compared to the cost of a countermeasure. The Vulnerability is a subjective probability of the effectiveness of current security controls. Where vulnerability is sufficiently low, risk is deemed acceptable. If the estimated countermeasure costs are deemed to be more than the expected annual impact of a successful attack (the risk), then a decision‐maker may instead decide to accept the risk. That is, a standard recommendation follows that:

This “traditional approach” to measuring cybersecurity risk is widely used and is still included as a correct answer on some cybersecurity certification examinations on how to make cybersecurity decisions. However, as a decision criteria, this value at risk calculation is extremely problematic. Even if the subjectivity of the vulnerability estimate was ignored, there is not one agreed‐upon dollar amount that will stop a given cybersecurity breach. Any change to technology architecture has the potential to introduce risk even if intended to reduce it. Cybersecurity software solutions constantly evolve and are often incompatible with legacy technology architecture. Many changes have unintended operational consequences. Cybersecurity software, like all software, is plagued with bugs and design flaws.

Even if the minimum dollar amount for technology improvements was agreed upon between enterprise business and technology leaders, resisting attack is accomplished only through close collaboration among business and technology management, collaborating through changes in both business process and technology, in conjunction with collaborative continuous monitoring of adversaries, internal controls, and validation testing. It is very difficult to reduce such abstract oversight to a dollar amount without strategic analysis, which is absent from the equation. For a risk to be accepted based on estimated cost and impact alone would be suspect if the threat domain were fire or fraud. To trust it would be like buying a fire extinguisher without putting in a fire alarm or sprinkler system, checking on the capabilities of the local fire department, automating alerts to them, and/or installing fireproof insulation materials. In the absence of a well‐planned cybersecurity governance and corresponding technology architecture, any single countermeasure is practically useless. Yet unfortunately, for many if not most cybersecurity...