Today's missions rely on highly integrated and complex technology that must operate in a dynamic and contested environment. Reliance on operational security controls alone for mission protection has proved insufficient. With today's adversaries, cybersecurity must be built into the technology to continue operating successfully, which requires the integration of cybersecurity engineering. Cybersecurity engineering applies the rigor of engineering with the knowledge of operational security into all aspects of the lifecycle to build, configure, operate, and maintain systems for secure and resilient operation. An acquisition program's cybersecurity strategy describes how this integration will be done.

The importance of cybersecurity engineering is growing as the capabilities demonstrated by our adversaries increase and systems shift from integrating "built for purpose" components to an increased reliance on multi-use components, including legacy, third-party software, open-source software, and external services (e.g., Azure Cloud and Platform One). This post, which augments a recent webcast and a forthcoming white paper, highlights the importance of the cybersecurity strategy in defining how the technology from an acquisition will be designed, built, integrated, and fielded to effectively perform a mission even when the technology is under attack.

There are six critical areas of cybersecurity engineering that a cybersecurity strategy should support to ensure mission success:

• determining risk
• defining and monitoring system and component interactions
• evaluating trusted dependencies
• anticipating and planning responses to attacks
• coordinating security throughout the lifecycle
• measuring to improve cybersecurity

A cybersecurity strategy cannot be implemented without planning, designing, monitoring, and enforcing considerations of cybersecurity at all levels. It is necessary to consider compliance requirements, mandates for an authority to operate, and good cybersecurity hygiene. These steps alone, however, are not sufficient to ensure that the composition is secure enough. These responsibilities touch on every aspect of the lifecycle and effectiveness requires a high level of collaboration across all activities. The strategy should define how this unprecedented level of collaboration will be achieved.

The owners of the cybersecurity strategy--as assigned by an acquisition program office--are responsible for defining how a system's cybersecurity performs to meet its mission, even under attack. These responsibilities include activities that achieve the following:

• Plan and design trusted relationships.
• Negotiate appropriate security requirements to ensure confidentiality, integrity, and availability with sufficient monitoring in systems and software.
• Plan and design sufficient resiliency to recognize, resist, and recover from attacks.
• Plan for operational security under all circumstances, including designed-in methods of denying critical information to an adversary to avoid or minimize mission impact.
• Evaluate alternatives to determine the level of accepted cybersecurity risk.

Integrating cybersecurity considerations into the early segments of a lifecycle affects acquisition, as well as systems and software engineering. Although program managers are ultimately responsible for cybersecurity, management must bring in resources with the specialized knowledge and operational expertise if program managers lack that specific expertise. The cybersecurity strategy should define the needed expertise and how it will be made available at each step in the lifecycle.

Cybersecurity engineering resources should focus on the following six key areas that are critical for building technology to operate in today's highly contested environments.

1 Risk determination--Cybersecurity engineering incorporates the effective consideration of threats and mission risk. Perceptions of risk drive assurance decisions, and the lack of cybersecurity expertise in risk analysis can lead to poor assurance choices. Involving individuals with knowledge about successful attacks and how threats can impact the system's operational mission can be critical in the decision-making steps for appropriate prioritization.

2 Defining and monitoring system and component interactions--Cybersecurity engineering considers risk to systems from the interaction among technology components and external systems. Highly connected systems require the alignment of cybersecurity risk across all stakeholders, system components, and connected systems; otherwise, critical threats can remain unaddressed (i.e., missed or ignored) at different points of interaction.

The following risk areas should be considered in design and process decisions:

• Interactions must be designed to be assured, and segments of the design will be scattered across various interacting components; verification that the pieces are all effectively working together must be part of the validation of this integration.
• There are costs to addressing assurance, and tradeoffs must be made among performance, reliability, usability, maintainability, etc. These costs and tradeoffs must be balanced against the impact of the risks. Then choices must be consistently applied across the range of participating components.
• Interactions occur at many technology levels (e.g., network, security appliances, architecture, applications, data storage) and are supported by a wide range of roles. The choices made at each level must be consistently applied across all levels for effective results.

3 Trusted dependencies--Cybersecurity engineering evaluates the dependencies and inherited risk to ensure that the appropriate level of trust is established. The following are key dependency considerations where trust is involved:

• Each dependency represents a risk that needs to be shared among interfacing components.
• Dependency decisions should be based on a realistic assessment of the threats, impacts, and opportunities represented by an interaction. Controls placed on the interaction should reflect this analysis.
• Dependencies are not static, and trust relationships should be reviewed periodically to identify changes that warrant reconsideration.
• Using many shared components (e.g., reuse, open source, collaboration environments) to build technology applications and infrastructure increases the dependency on others' assurance decisions that may not meet mission needs.

4 Attacker response--Cybersecurity engineering should oversee this responsibility to ensure that system capabilities are included to allow effective handling of the types of attacks that can be mission critical. A broad community of attackers has expanded their technology capabilities, enabling them to compromise the confidentiality, integrity, and availability of any and all of a system's technology assets. Moreover, this attacker profile is constantly changing and evolving in sophistication and lethality.

There are no perfect protections and attacker capabilities continue to grow, so effective coordination must consider the need to recognize, resist, and recover. Ensuring that a system will work even when under attack requires extensive planning and coordination across all components and technologies. Attacks are crafted to exploit the ways in which technology is normally used and/or designed to contrive exceptional situations where defenses are circumvented. Techniques, such as threat modeling, attack tree analysis and the development of potential misuse and abuse cases, can support this key area.

5 Coordination of security throughout the lifecycle--This area is the responsibility of cybersecurity engineering. Each step of the lifecycle should include preparing for the fielded system. Attackers often take advantage of all possible entry points, so protection must be applied broadly across people, processes, and technology. This span of protection includes acquisition decisions about software and services integrated into the system. The role of implementing a cybersecurity strategy requires coordination among systems and software engineering, architects and designers, developers, testers, verifiers, and implementers to identify potential gaps and ways of addressing them to assure the operational mission.

6 Measurement for cybersecurity improvement--Cybersecurity engineering should be responsible for coordinating data--from the various lifecycle steps, decision-making levels, and system-component evaluations--to show that the steps designed to address cybersecurity are delivering expected results. Tools can track vulnerabilities in code, testing can show defects, and architecture analyses can identify design weaknesses. Until these elements are integrated, however, the operational risk perspective is missing. All elements of the socio-technical environment (e.g., practices, processes, procedures, products) must tie together and measurements must be consistent.

Cybersecurity engineering should monitor the range of lifecycle activities needed to contribute to assurance. Monitoring these activities demonstrates how the program is progressing toward its compliance and cybersecurity operational goals. Figure 1 shows the range of activities that can be applied at various stages of the lifecycle to address design, coding, and implementation weaknesses that contribute to reduced operational risk. Cybersecurity engineering should assemble data to show that the combination of lifecycle activities produces the results needed to reduce mission impact from undetected weaknesses.

Vulnerability requirements lead naturally to a security focus, but the design of a response must be based on the potential consequences. How could a security compromise affect the intended behavior? Often adverse changes in intended behavior affect data management. Has information been disclosed or modified? Except for software-intensive mission-critical systems, the most significant effects of a security compromise likely involve changes in intended behavior related to reliability, safety, and availability. Cybersecurity engineering is needed to proactively establish how a system should respond to unexpected situations leveraging tools such as threat modeling and attack surface analysis to develop assurance.

Software assurance is the level of confidence that the software (1) is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its lifecycle, and (2) functions as intended.

Too often, an organization becomes aware of a successful security compromise only by observing the consequences of an attack. A critical security risk for mission-critical systems is that a security compromise is identified only after encountering a safety or reliability operational fault. Such a risk increases the importance of eliminating security weaknesses during the development lifecycle. The 2005 Department of Defense Guide for Achieving Reliability, Availability, and Maintainability (RAM) emphasized the importance of systems-engineering design analysis over predicting software reliability based on an analysis of faults found during integration. Engineering analysis for cybersecurity is equally important.

In particular, threat modeling is essential during detailed systems-engineering design to identify potential weaknesses and propose appropriate mitigations. The development of an attack surface guides threat modeling. Threat modeling should also generate the outline of an assurance argument. What are the most consequential threats? How will those threats be sufficiently mitigated? How will the desired level of confidence be demonstrated? Where possible, that confidence should be based on engineering analysis, such as with design reviews and inspections.

Late lifecycle activities, such as testing, static analysis, and dynamic analysis, typically offer only incomplete assurance. The design of the DevSecOps pipeline, for example, should reflect the planned assurance proposed by the cybersecurity-engineering analysis done earlier in the development lifecycle. Prioritizing requirements, selecting tools for weakness identification and removal, tracking unaddressed weaknesses, and establishing approval mechanisms for operational release should combine to deliver data that supports growing confidence in the operational assurance of the developing product.

Threat modeling incorporates engineering analysis into the design phases of the lifecycle and supports verification and validation for demonstrating assurance, as shown in Figure 2. Threat modeling identifies possible weaknesses that could be exploited and proposes mitigations if they are exploited. That engineering analysis typically provides guidance on how to validate those mitigations, such as with specific unit or integration tests.

How can we determine the level of confidence that a system will behave as expected? It is impossible to examine or test every possible combination of conditions that could affect a system. But achieving that confidence is important to those acquiring, developing, and using the system. Such confidence should be based on concrete evidence and not just on the opinions of developers or reviewers. An assurance case provides the argument mapped to available evidence. The level of confidence in a system should depend on understanding the evidence that leads to an increase in the confidence that a system property holds.

The evidence that supports increased confidence in a system property should be available at many points along the lifecycle. Organizing the evidence, which comes from every aspect of acquisition and development to support decisions about cybersecurity and software assurance, requires careful planning and analysis. The cybersecurity strategy must integrate the expertise from cybersecurity engineering with evidence of how the product was planned, built, and how it actually performs. As noted in a recent blog post by Phil Venables, a specialist in enterprise risk, information and cybersecurity, and business resilience who sits on the National Institute of Standards and Technology (NIST) Information Security and Privacy Advisory Board, cybersecurity must be carefully folded into systems delivery. This integration cannot be done in a haphazard manner if the results must meet critical operational requirements.

An assurance case can be used as a framework to connect the various elements of this analysis to show gaps and sufficiency. By mapping evidence that is appropriately generated and selected from the various steps of the lifecycle into an assurance case, considerations for how the system should function and how it should not function can be collected and analyzed. If done properly, this evidence will demonstrate that the system effectively addresses software assurance.