Over the past six months, we have developed new security-focused modeling tools that capture vulnerabilities and their propagation paths in an architecture. Recent reports (such as the remote attack surface analysis of automotive systems) show that security is no longer only a matter of code and is tightly related to the software architecture. These new tools are our contribution toward improving system and software analysis. We hope they will move forward other work on security modeling and analysis and be useful to security researchers and analysts. This post explains the motivation of our work, the available tools, and how to use them.

Motivation

In recent years, the focus on cybersecurity has grown significantly. People are starting to realize that cybersecurity no longer impacts only virtual worlds and the number of Pokeballs you have, but can have significant, life-threatening impacts. In 2015, Miller and Valasek demonstrated that an attacker can remotely take control of a Jeep and override the pilot commands by sending acceleration or braking commands from a laptop connected to the Internet. Similarly, the FDA advised hospitals to avoid some infusion pumps because a security vulnerability could allow cyber attackers to take remote control of these vulnerable systems. Why so many issues? The reasons are a mix--lack of education, tools, and standardization/regulations. The reality is that we are in a software-reliant world; engineers often do not receive the training needed to design for safety and security, and actual development tools do not provide enough support for designing secure systems. Moreover, in many domains (such as medical device or automotive domains), we are in the early stage of defining standards for safe and secure embedded systems.

Much work is being done to detect code issues, avoid data leaks, and make the implementation safer (e.g., learning how to detect coding problems due to bugs such as Heartbleed). But recent stories (like the Jeep attack mentioned above) show that security issues are no longer only a matter of code. Many vulnerabilities are rooted in the software and system architecture--software deployment, configuration, resource sharing, for example. We have focused our research efforts in this area, specifically on trying to capture security concerns in an architecture and detect vulnerabilities and their impact. In that context, we have developed new modeling tools to represent and analyze an architecture with respect to its security constraints.

Before beginning this effort, we reviewed existing research work and evaluated popular security analysis tools. We identified three important types of analysis: the attack tree, attack impact, and attack surface. We then designed two modeling tools: the attack tree and attack impact. We did not design a specific attack surface tool because the attack surface can be derived from the attack impact. The following section presents each tool.

Attack Impact

The attack impact is an analysis tool that shows how a vulnerability can reach a given component. This analysis is similar to the failure mode and effect analysis done from a safety perspective. Results from such an analysis can be provided under various representations: text file, spreadsheet, or graphical version. For example, with a spreadsheet, we can show a report; each line represents a propagation path from the vulnerability to the impacted component. A graphical representation will show the vulnerabilities, the components, and how they are connected (using data flow, bus connections, etc.).

We illustrate the attack impact analysis with a simple example of a temperature controller. In this architecture, two sensors (Sensor 1 and Sensor 2) are connected to a controller. The controller then activates the heater or cooler components based on the temperature.

There is a data flow between each sensor (Sensor 1 and Sensor 2) and the actuators (heater and cooler). The sensors are physically exposed to attackers and can be tampered with or altered. From a security perspective, this would allow injection of compromised data to the controller to ultimately alter the heater or cooler.

We capture the vulnerability (physical exposure) and the data flow relation between the sensors and actuators (cooler and heater). We remove the intermediate controller: the components that are ultimately impacted are the actuators (cooler and heater). This graphical model provides the ability to analyze the impact of a vulnerability (physical exposure in the present case) and how it impacts other components (cooler and heater). Propagation includes data flow, bus connections, shared processor, and memories.

Attack Impact, Graphical Version

Attack Tree

The attack tree is a top-down analysis tool that shows all vulnerabilities that might compromise a component. It is similar to fault-tree analysis that is often conducted for safety purposes. Our concept of an attack tree leverages the fault-tree analysis notation from a security perspective. An attack tree shows each propagation path that will eventually reach the component under analysis. The following figure shows the attack tree for the cooler component in our previous attack impact.

In the present case, the cooler component can be compromised in two ways:

1. attack on sensor1 (using physical access)
2. attack on sensor2 (using physical access)

Of course, the vulnerability propagations on our example model seem simple and obvious. The real interest lies in where such tools go, beyond what an engineer can do or detect, and generate all propagation paths automatically. The engineer can then identify which path can impact the critical infrastructure and must be mitigated and handled.

Our analysis tools include a standalone attack tree editor to create attack trees from scratch. It is possible to start an attack tree without any existing system design. In that case, the user will start an empty attack tree and start to design it from the top (root node that is eventually compromised) to the bottom (vulnerabilities and components that contribute to propagate attacks). On the other hand, some users prefer to start designing an attack impact with the overall architecture and then create the attack tree. For that reason, we included a functionality that generates, for a given component, an attack tree generator from the attack impact.

Attack Tree - Graphical Version

Using the tool

Our new analysis tools are based on Eclipse and the Sirius graphical framework. These tools are currently available under the BSD license and free to download and use. If you are using the AADL OSATE modeling platform, you can install them using the Eclipse installation mechanism and the update site at http://aadl.info/aadl/osate/experimental/. If you are not familiar with the installation mechanism, we have installation guidelines available.

Extending the tool

We are dedicated to contributing to the research community, and we release our software under open-source as much as possible. All of these tools have been released under the BSD license on the SEI github account. You can check out the sources and use them and, even better, modify them for your own use.

The tools rely intensively on Eclipse technologies, especially

1. the EMF meta-model to capture the attack surface and attack tree meta-model
2. the Sirius graphical framework to provide a graphical representation of the meta-model

Wrapping up

This blog post introduced our new modeling tools with a focus on security. They provide a graphical way to capture a system architecture with the component, its connections, and related vulnerabilities. Our tools support two analyses: the attack impact and attack surface. Both provide a graphical representation of how vulnerabilities can ultimately compromise a component.

The tools are publicly available under an open source license, and downloaders can use or modify them for their own use. If you want to try the tool, you can easily use our experimental Eclipse update-site and install the tool from Eclipse.

We are now focusing on how to generate the attack impact and attack tree with our architecture design tools. We have been working intensively on AADL, and one of our objectives is to bridge these technologies and automate the production of security-specific analysis models (attack tree or attack impact) from more general models, such as AADL. We already have a preliminary implementation that was presented during our AADL tutorial at Embedded System Week, and we are now working to consolidate it.

Additional Resources

View a tutorial on security modeling with AADL at Esweek 2016.

The security modeling tools are currently available under the BSD license and free to download and use. If you are using the AADL OSATE modeling platform, you can install them using the Eclipse installation mechanism and the update site at http://aadl.info/aadl/osate/experimental/. If you are not familiar with the installation mechanism, we have installation guidelines available.