Each new cyber system creates new opportunities and causes new risks. Knowledge of specific risks, including unique threats and undesired events related to the system of interest is critical for the system assurance process, as described in Chapters 2 and 3. Risk assessment produces an estimate of the risk of security incidents involving the cybersystem of interest. It answers the following questions:

Answers to these questions produce a measure of risk that is used to prioritize risks during the risk management process. Should the management of this risk be through reduction, then the safeguard selection process provides answers to the question:

The key to justified cybersecurity is the connection between traditional risk assessment and assurance to create an end-to-end argument that the risk of security incidents during the operation of the system is made as low as reasonably practicable by implementing safeguards that are effective against the risks identified. Confidence in the security posture of the system largely depends on understanding the risks that are specific to the system. Systematic and repeatable identification of risks is therefore essential for justifiable cybersecurity. While it is true to say that risks arise from uncertainty, justifiable cybersecurity focuses on such components of risk that are deterministic and predictable.

The two fundamental questions of identifying risks are “What is the risk to?” and “From what sources does the risk originate?” Assets are the targets of risk. Threats are the sources of risk. Threats are different from both threat agents and attacks. An attack is a particular scenario of how a given threat materializes and turns into a security incident. Detailed understanding of the components of cyber threats is required for making comprehensive threat statements, selecting countermeasures, and formulating clear and comprehensive claims regarding the effectiveness of these countermeasures. Knowledge of threats determines the structure of the assurance argument as described earlier in Chapter 3.

It is a common understanding that development teams that collectively have detailed knowledge of the design and implementation of the system are not well suited to identify threats. Developers focus on features, on building and creating, not on breaking things apart and finding flaws. There is a conceptual gap between what a development team knows about the system and what needs to be known about the ways the system can be attacked. In order to adequately identify threats, the risk assessment team must have comprehensive knowledge of the shady landscape of cyber crime, the experience of the incidents and attacks. Consequently, one risk analysis team performs better than another. What matters is the security experience, including knowledge of attacks that were successful. Are the former hackers the best people to perform risk assessment? Several risk analysis textbooks, especially those aiming at improving the security skills of developers, recommend brainstorming as the method for identifying threats. Of course, at the end each team produces a set of risks to manage and provides some recommendations on additional countermeasures. Yet there is a need for justified confidence that no more threats of the same or larger magnitude exist.

Some organizations favor penetration testing as the method of assessing their security posture. The so-called ‘red team’ of ethical hackers may be contracted to identify security risks. However in order to be comprehensive, penetration testing depends on the same knowledge that is required to identify threats by reviewing the design and implementation artifacts. As a result, penetration testing is plagued by the same subjectivity. A more experienced team may identify more problems but nevertheless leaves open the question of what problems may still be remain unidentified.

Ad hoc methods for identifying security holes in cybersystems are sufficient for hackers; however, the risk assessment process underlying cyberdefense must be systematic.

So how can risk assessment be made more systematic, repeatable, and objective to provide a solid foundation for system assurance? One approach is to accumulate cybersecurity knowledge and distribute it to the defenders. Accumulating attack knowledge can make risk assessment more repeatable by applying accredited and up-to-date checklists, so that even an unexperienced risk analyst can be systematic in the process—for example, when a list of the key words describing the system can be used to query a comprehensive attack knowledge repository—and produce a credible list of threats. When such a resource is available early in the system's life cycle, many mistakes and inconsistencies in the downstream processes can be avoided. The OMG Software Assurance Ecosystem emphasizes development of the standard protocols for exchanging cybersecurity knowledge based on the system facts, which facilitate the transformation of cybersecurity knowledge into machine-readable content that can be accumulated, exchanged, and used as input into automated assurance tools. Accumulation and distribution of cybersecurity knowledge from more experienced analysts all the way down to the defenders of individual systems require more attention to the exchange standards. Cybersecurity knowledge should be systematically collected and accumulated, unlocked from the tools, and distributed from the few experts onto the larger community. This means knowledge should be turned into a commodity, in very much the same way as electricity was unlocked from disconnected closed-circuit proprietary systems that included production, transmission, and consumption into a normalized, interconnected “grid” that led to the explosive growth of how electricity is utilized.

Currently, there is a large knowledge gap between attackers and defenders. Collaborative cybersecurity and accumulation of cybersecurity knowledge is the starting point for closing this gap. Once collaboration in the area of cybersecurity picks up, risk assessments will become more repeatable, but will this also lead to more affordable cybersecurity? Many believe that it will. Once the cyberdefense community understands what knowledge has to be accumulated and exchanged, then standards and other protocols for communicating the knowledge will become progressively more efficient and automated tools will appear.

The complementary approach to more systematic risk assessment is through the development of an integrated assurance case that extends claims and arguments to the identification of threats. System assurance focuses on the justification aspect of both engineering and risk assessment. Justified identification of threats provides the foundation for selecting security countermeasures and contributes to justification of the countermeasures' effectiveness. In particular, during the identification of threats it is important that the risk assessment team provide clear and defendable justification that sufficient threats have been identified (commensurate with the selected security criteria).

Since it is prohibitively expensive—and probably impossible—to safeguard information and assets against all threats, modern security practice is based on assessing threats and vulnerabilities with regard to the risk each presents, and then selecting appropriate, cost-effective countermeasures. Systematic identification of threats is particularly important in justifying such a balance, which otherwise leads to unknowingly accepting high risks.

Assessing the level of threat is even more difficult than identifying the threat itself. The level of threat is the measure of the probability of the threat event and the measure of the associated impact. The threat and its level are often collectively referred to as an individual “risk”. Without access to reliable, consistent, and comprehensive data on previous incidents, little useful guidance can be provided on the probability of the threat materializing. Several people have added that in the dynamic landscape of the cybersecurity threats and new attack methods, observation of past events is not necessarily a good guide to future accidents. Another way to access threats is to gather intelligence information related to identifying possible attackers and their capability, motivations, and plans from a network of agents, as is done in law enforcement and national security agencies. However, intelligence gathering only applies to certain types of threats and is unrealistic for most organizations. As a result, there is a tendency to base risk management on assessing vulnerabilities and their associated impact, or the level of damage that your organization would sustain if a threat event successfully exploited vulnerability. This is believed to be much easier, since both factors are within the scope of the organization. Consequently, a certain “mythification” of the concept of vulnerability occurs, as some condition that can be systematically detected in the system. The vulnerability approach is explored in more detail in Chapters 6 and 7. The current chapter focuses at deterministic strategies for systematic identification of threats as a precursor for systematic detection of vulnerabilities.

The framework for cybersecurity is defined in several international standards and recommendations such as ISO/IEC 13335 Guidelines for the Management of IT Security [ISO 13335], ISO-IEC 15443 A Framework for IT Security Assurance [ISO 15443], ISO/IEC 17779 A Code of Practice for Information Security Management [ISO 17779], ISO/IEC 27001 Information Security Management Systems [ISO 27001], ISO-IEC 15026 Systems and Software Assurance [ISO 15026], ISO/IEC 15408 Evaluation Criteria for IT security [ISO 15408], and NIST SP800-30 Risk Management Guide [NIST SP800-30]. The following six terms—assets, impacts, threats, safeguards, vulnerabilities, and risks—describe at a high level the major elements involved in cybersecurity assurance. The terminology is based on ISO/IEC 13335. These elements are illustrated at Figures 1 and 2. Precise fact-oriented vocabulary of discernable noun and verb phrases is described in the next section.

In order to systematically build assurance cases and reason about the effectiveness of security countermeasures, it is necessary to have a conceptualization of threats as something against which we build countermeasures. Such a concept must provide that knowledge of threats be aligned with the system facts and can be turned into machine-readable content able to be exchanged using a standard protocol for the purposes of system assurance. The goal of this chapter is to describe a discernable conceptualization that can support repeatable and systematic assurance and automation.

How far is the community from normalizing knowledge of cyber threats and collaborating by exchanging machine-readable documents? In 2008, the NATO report titled “Improving Common Security Risk Analysis” [NATO 2008] mentioned that the different methods used by various NATO countries such as EBIOS for France, NIST Risk Management SP800-30 and CRAMM for UK, ITSG-04 for Canada, and MAGERIT for Spain differ in their knowledge bases (assets, threats, vulnerabilities, etc.) and type of results (quantitative or qualitative), which makes it difficult or impossible to compare risk assessments when different methods have been used.

Our ability to identify cyber threats for a given system in a systematic and repeatable way depends on a common understanding of the threat theory and, in particular, understanding the locations that can be systematically covered during the search for threats. The cause of the incompatibilities between diverse risk assessment methodologies, reported by the NATO report, is that the definitions of threats and risks currently used in the cybersecurity community are rather high level and do not have the required precision that allows establishing traceability links to the system facts. High-level non-discernable definitions are often responsible for higher levels of subjectivity in applying a particular risk assessment methodology and for the larger variation between the outcomes, produced by different teams. The lack of discernable definitions was one of the challenges reported by the IDEAS Group during the Defense Enterprise Architecture Interoperability project [McDaniel 2008]. This issue is addressed by analyzing original vocabularies and applying the vocabulary disambiguation methodology, such as the BORO methodology (described in more detail in Chapter 9) to identify the basic discernable concepts for inclusion into the common vocabulary and establishing the mappings between the individual original vocabularies and the common vocabulary. In the rest of this chapter we use the so-called SBVR Structured English. You will recognize it by a distinctive typesetting. This notation is fully explained in Chapter 10. Chapter 9 explains the OMG Common Fact Model approach which provides guidance to building common vocabularies as contracts for information exchange including how to generate XML schema for information exchange from this notation and how it defines fact-based repositories.

The systematic threat identification process is essential for producing stronger claims for the assurance case and building defendable assurance arguments and evidence. One of the characteristics of the threat identification process that is specific to its use in system assurance is the set of activities that lead to assurance of the process itself, by performing verification and validation tasks, and collecting evidence that justifies completeness of the list of identified threats that all sufficient threats have been identified.

Threat identification is the cognitive process of matching the components of the threat against the multitude of system facts (available as the integrated system model, as described in Chapter 3).

Systematic, repeatable, and objective identification of threats involves the “security threat” patterns that utilize “security threat” components as follows:

In addition, security threat identification can use key failure state questions and evaluations of the threat-triggering mechanisms.

The discernable threat concept provides the best threat recognition resource by evaluating individually each of the four threat component categories (threat agent, entry point, asset, and injury) against the systems facts. This means, for example, identifying and evaluating all of the unique entry point components in the system design as the first step [Swiderski 2004]. Subsequently, all system assets are evaluated for injuries and undesired events, then all causal factors.

Threat agent category and threat activity checklists are examples of cybersecurity content that is key to the justifiable identification of the threat agents of the security threats and further evaluation of the likelihood of the threat based on the capabilities and motivations of the identified threat agent. This is similar to using the industry standard hazardous source checklists, such as explosives, fuel, batteries, electricity, acceleration, and chemicals to identify safety hazards. System components that match the elements of one of the hazard source checklists may lead to identification of a potential safety hazard in the system. In the area of cybersecurity, threat agents are external to the system, so this knowledge cannot be turned into patterns that can be recognized in the system facts, but they are nevertheless important for systematic threat identification. Once the four threat components have been identified, knowledge of attack pattern can be used to further investigate the possible attack scenarios. Accumulating and exchanging the certified machine-readable threat agent category and threat activity checklists is required for distributing cyberdefense knowledge across the defender community.

Threats can be recognized by focusing on known or preestablished undesired events (the injury to asset component of a security threat). This means considering and evaluating known undesired events within the system. By following these undesired events backward, certain threats can be more readily recognized. A similar systematic approach is used in system safety for systematic identification of safety hazards [Clifton 2005]. For example, a missile system has certain undesired events that are known right from the conceptual stage of system development. In the design of missile systems, it is well accepted that an inadvertent missile launch is an undesired mishap. Therefore any conditions contributing to this event would formulate a hazard, such as autoignition, switch failures, and human error.

Another method for recognizing threats is through the use of key state questions. This method involves a set of clue questions that must be answered, each of which can trigger the recognition of a threat. The key states are potential states or ways the subsystem could fail or operate incorrectly and thereby result in creating a threat. For example, when evaluating each subsystem, answering the question “What happens when the subsystem fails to operate?” may lead to recognition of a security threat. A similar approach is the foundation for the HAZOP technique for systematic safety hazard identification.

Certain threats can be recognized by focusing on known causal threat-triggering mechanisms. In cybersecurity many threats involve the control- and data-flow path from some entry point to the “point of injury,” which is a particular location in the system capable of producing potential injury and the common safeguards in the form of data filters. In particular, this approach focuses at known safeguards and their components, and the possibilities of bypass. Similar techniques are applied in system safety. For example, in the design of aircraft it is common knowledge that fuel ignition sources and fuel leakage sources are initiating mechanisms for fire/explosion hazards. Therefore, the systematic safety hazard recognition would benefit from detailed review of the design for ignition sources and leakage sources when fuel is involved. Component failure modes and human error are common triggering modes for both safety hazards and security threats, for example, when system design indicates a human decision point used as a safeguard that mitigates a certain triggering mechanism.

Use of the integrated system model allows automation of several tasks of the systematic threat identification, based on the central concept of a vertical traceability link, as follows. The integrated system model contains detailed system facts (automatically derived from the system artifacts, such as binary and source code by knowledge discovery tools) as well as the high-level threat facts (identified and imported into the integrated system model, such as threat agents and asset classes). The high-level threat facts are linked to the low-level system facts through chains of vertical traceability links. Entry points, physical assets (especially the information assets and capability assets), and “points of injury” can be identified by automated pattern recognition against the detailed system facts, and then propagated to the high-level threat facts by using vertical traceability links. Similar to standard protocols for exchanging checklists for identifying external components of threats, accumulating and exchanging certified machine-readable patterns is required for distributing cyberdefense knowledge across the defender community. The key enabler for the exchange of cybersecurity patterns is the availability of a standard protocol for exchanging system facts, supporting traceability links, and integration of multiple vocabularies because both the facts about the system of interest (extracted by knowledge discovery tools) and the patterns must use the same protocol, the same conceptual commitment to the predefined common vocabulary. Cybersecurity patterns are further addressed in Chapter 7. The standard protocol for exchanging system facts is described in Chapter 11. The underlying mechanisms for fact-based integration of multiple vocabularies are described in Chapter 9. Finally, Chapter 10 describes the standard protocol for managing and exchanging vocabularies and defining new patterns. These components provide the foundation for the OMG Assurance Ecosystem described in more detail in Chapter 8.

Let's look at threat identification in the context of the system assurance strategy. First of all, we want to stress the point that assurance is a complex collection of activities throughout the life cycle of the system that contributes to governance of the system [ISO 15288]. This determines the overall system assurance strategy, including the integration of assurance activities with other system life cycle processes and the scope of individual system assurance projects. These considerations lead to the particular structure of the assurance case, which is tailored to the governance needs of the life cycle of the system of interest. However, within the complex mosaic of system life-cycle processes, the assurance activities follow certain steps based on the logical dependencies between inputs and outputs of these steps, as outlined in Chapter 3. The central goal of the assurance case developed in Chapter 3 is the so-called safeguard effectiveness claim. This claim involves one or more threats. Assurance strategy provides guidance on how to manage multiple safeguard effectiveness claims within the assurance case. With this understanding, systematic threat identification involves several distinct approaches, based on the particular threat component that is identified first. Selected strategy determines the structure of the collection of threats and consequently determines the detailed structure of the assurance argument and the goal structure of the assurance activities. Although multiple approaches are possible, the following five strategies are noteworthy:

Assurance evidence for threat identification is derived primarily from the use of relevant checklists and from traceability links between the elements of the integrated system model. Individual threat identification strategies (injury argument, entry point argument, threat argument, and vulnerability argument) all provide unique perspectives on threat. Assurance of threat identification is done by cross-correlating the results of these approaches. In addition, the identified components of threats are linked to the system elements, which allows for additional cross-correlation. (If a certain system element is associated with one of the threat components, are all similar elements also associated with threat components?) An additional backing argument is based on using qualified and experienced personnel to perform threat identification.

The threat identification activity involves verification and validation tasks, as well as the assurance task. For example, in Table 1 the threat identification activity (TIA) is summarized as consisting of the following steps: