Posted on by Software Assurancein
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 Instituteto 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:
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:
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.
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.
• 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.
The SERA Framework incorporates three key features that differentiate it from other security risk assessments:
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.
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.
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.