Software is a growing component of systems used by Department of Defense (DoD), government, and industry organizations. As organizations become more dependent on software, security-related risks to their organizational missions are also increasing. Despite this rise in security risk exposure, most organizations follow a familiar pattern when managing those risks.

They typically delay taking aggressive action to mitigate security risks until after a software-reliant system has been deployed (i.e., during the operation and maintenance of the system). This blog post highlights the Security Engineering Risk Analysis (SERA) Framework, a new approach developed by researchers in the CERT Division at the Carnegie Mellon University Software Engineering Institute to help organizations reduce operational security risks by proactively designing security controls into software-reliant systems (i.e., building security in up front, rather than retrofitting it as an afterthought).

Three Main Causes of Operational Security Vulnerabilities

In examining the origin of operational security vulnerabilities, our team of researchers noted that they generally have three main causes:

• design weaknesses
• implementation/coding
• system configuration errors

Over the years, significant effort (e.g., research, tool development, guidance) has been directed toward addressing vulnerabilities caused by implementation/coding issues and system configuration errors. As a result, implementation/coding vulnerabilities can be corrected during system operation and maintenance through the dissemination of security patches by vendors. In addition, secure coding practices, such as those developed by researchers on CERT's Secure Coding Team, can proactively prevent the occurrence of certain implementation/coding vulnerabilities. System configuration vulnerabilities can be prevented (or corrected) by following accepted operational security practices, such as implementing appropriate authentication and authorization controls.

The SERA research team--in addition to me, the team includes Carol Woody and Audrey Dorofee--believes that it is important to focus on correcting design weaknesses because they are so pervasive. MITRE's Common Weakness Enumeration (CWE) provides a community-developed view of software weaknesses. As of February 2014, design-related issues account for 40 percent of the 940 total CWEs. In addition, 76 percent of the top 25 most-dangerous CWEs are design weaknesses.

We are also focusing on design weaknesses because security is often neglected during early lifecycle activities. Addressing design weaknesses as soon as possible is especially important because these weaknesses are not corrected easily after a system has been deployed. Remediation of design weaknesses normally requires extensive changes to the system, which is costly and often proves to be impractical. As a result, software-reliant systems with design weaknesses often are allowed to operate under a high degree of residual security risk, putting their associated operational missions in jeopardy.

Our initial research suggested that applying traditional security risk-analysis methods earlier in the lifecycle will not solve the problem because those methods cannot handle the inherent complexity of modern cybersecurity attacks. Traditional methods of identifying risk focus on the simple, linear view that assumes a single threat actor exploiting a single vulnerability in a single system to cause an adverse consequence. Our experience shows that most cyber-attacks are much more complicated.

For example, consider the Target breach of late 2013. This attack was not the result of a single vulnerability that allowed the criminals to access tens of millions of credit cards and personal information including names, addresses, and other personally identifiable information. The cybercriminals instead targeted a subcontractor in the Pittsburgh area and exploited its infrastructure to gain trusted access into the Target infrastructure. From the initial entry point, they were able to exploit vulnerabilities in multiple systems in Target's infrastructure to access the data that they wanted. Ultimately, this attack included multiple systems across two organizations.

This complexity of the Target attack is not unique. Multiple actors often exploit multiple vulnerabilities in multiple systems as part of a complex chain of events. Our research indicated that a new approach was needed to handle these types of security risks.

The solution that we developed, the Security Engineering Risk Analysis (SERA) Framework, focuses on minimizing design weaknesses by integrating two important technical perspectives: (1) system and software engineering and (2) operational security. The SERA Framework defines an engineering practice for analyzing risk in software-reliant systems that are being acquired and developed, with the ultimate goal of building security into those systems. The tasks specified in the framework are designed to be integrated with a program's ongoing system engineering, software engineering, and risk management activities.

Four Tasks of the SERA Framework

The SERA Framework specifies the following four tasks:

1. Establish operational context. The first task defines the operational context for the analysis. In this task, the Analysis Team (i.e., an interdisciplinary team of 3-5 people that leads the risk analysis) identifies the system of interest for the analysis (typically the system that is being acquired or developed) and then determines how the system of interest supports operations (or is projected to support operations if the system of interest is not yet deployed). The team develops models of the most critical workflows or mission threads that are supported by the system of interest.

Each software application or system typically supports multiple operational workflows or mission threads during operations. The goal is to (1) select which operational workflow or mission thread the team will include in the analysis and (2) document how the system of interest supports the selected workflow or mission thread. The team develops additional models that describe the technologies that support each workflow or mission thread and how data flows among those technologies. These models establish a baseline of operational performance for the system of interest. The team then analyzes security risks in relation to this baseline.

2. Identify Risk. The second task specified in the framework focuses on risk identification. In this task, the Analysis Team transforms security concerns into distinct, tangible risks that can be described and measured. Task 2 comprises the following steps:

a. The team starts by reviewing operational models generated by the first task. The team then identifies a threat that is causing concern as well as the sequence of steps required for that threat to be realized.

b. The Analysis Team then describes how each threat might affect the workflow or mission thread as well as selected stakeholders (i.e., established the consequences produced by the threat).

c. Finally, the Analysis Team creates the narrative for the security risk scenario and compiles all data related to the scenario in a usable format. It is important to note that the steps specified in the second task must be performed for each risk that is identified.

3. Analyze Risk. During this task the Analysis Team evaluates each risk in relation to predefined criteria to determine its probability, impact, and risk exposure. This evaluation involves several steps:

a. Establish probability. A risk's probability provides a measure of the likelihood that the risk will occur. In this step, the Analysis Team subjectively determines and documents the probability of the occurrence for the security risk scenario.

b. Establish impact. A risk's impact is a measure of the severity of a risk's consequence if the risk were to occur. The Analysis Team analyzes and documents the impact of the security risk scenario.

c. Determine risk exposure. Risk exposure measures the magnitude of a risk based on the current values of probability and impact. The team determines the risk exposure for the scenarios based on the individual values for of probability and impact documented in the previous two steps in this task.

4. Develop Control Plan. The fourth task in the framework focuses on establishing a plan for controlling a selected set of risks. The Analysis Team first prioritizes the security risk scenarios based on their risk measures. Once priorities have been established, the team determines the basic approach for controlling each risk based on pre-defined criteria and current constraints (e.g., resources and funding available for control activities.) For each risk that is not accepted, the Analysis Team develops a control plan that indicates

• how the threat can be monitored and the actions taken when it is occurring (recognize and respond)
• which protection measures can be implemented to reduce vulnerability to the threat and minimize any consequences that might occur (resist)
• how to recover from the risk if the consequences or losses are realized (recover)

A subset of the control actions will have implications for the software (or system) requirements and design. The team must determine which actions might affect the requirements or design of the system of interest and document them for further analysis.

Our technical note, Introduction to the Security Engineering Risk Analysis (SERA) Framework, provides examples for all four SERA tasks.

Key Differentiators

The SERA Framework incorporates three key features that differentiate it from other security risk assessments:

• Use of operational models. Traditional security-risk assessments rely on a tacit understanding of the operational context in which a software-reliant system must operate. Our experience indicates that tacit assumptions are often incorrect or incomplete, which adversely affects the results of a security risk analysis. The SERA Framework uses operational models to describe a system's operational context explicitly and establish a baseline of operational performance to inform the risk identification and analysis.
• Semantic structure to document security risks. Most traditional assessments rely on linear, simplistic formats for recording risks (e.g., if-then statements). These basic structures fail to capture the complexities and nuances of modern cybersecurity attacks. To address this deficiency, the SERA Framework uses scenarios to document a cybersecurity risk and create fairly complex risk scenarios. A security risk scenario conveys information describing how one or more threat actors can exploit multiple systems to cause adverse consequences for stakeholders. A scenario essentially chains multiple basic risks together to describe how an attack might actually occur in the real world.
• Shared view of a system, its operational context, and its associated security risks. The SERA Framework presents a view of the system that is easily understood by multiple stakeholders including system and software engineers, security experts, and program managers. As a result, complex security risks can be evaluated effectively and then prioritized based on their impact to the operational mission of the system.

These differentiators distinguish the SERA Framework from other security risk assessment of analysis approaches. They also provide the basis for analyzing complex, multi-faceted security risk scenarios early in the acquisition lifecycle.

Collaborations

We collaborated with Dr. Travis Breaux of CMU's Institute for Software Research in the School of Computer Science and a renowned expert in the fields of risk management and security requirements. One aspect of Dr. Breaux's research is exploring the roles that that expertise plays in eliciting risk. We were able to build upon this research as we developed the SERA Framework.

Looking Ahead and Future Work

Software is a growing component of systems across all government and industry sectors. The SERA Framework is a first step in our ongoing research to help program managers establish reasonable confidence that (1) a software-reliant system will function as intended when deployed and (2) its cybersecurity risk will be kept within an acceptable tolerance over time. The initial results from applying the SERA Framework are promising. However, we have many additional research and development activities to complete.

Here, we briefly highlight two of those activities. The first is using threat archetypes (i.e., a pattern or model illustrating the key characteristics of a complex threat scenario) to facilitate risk identification. The second is working to help organizations comply with new legislative mandates, such as National Institute of Standards and Technology (NIST) 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, which provides guidance for applying the NIST Risk Management Framework (RMF) to federal information systems.

We welcome your feedback on our research. Please leave feedback in the comments section below.

Additional Resources

For a more detailed explanation of our research please read our recent technical note, Introduction to the Security Engineering Risk Analysis (SERA) Framework, which is available here.