As our world becomes increasingly software-reliant, reports of security issues in the interconnected devices that we use throughout our day (i.e., the Internet of Things) are also increasing. This blog post discusses how to capture security requirements in architecture models, use them to build secure systems, and reduce potential security defects. This post also provides an overview of our ongoing research agenda on using architecture models for the design, analysis, and implementation of secure cyber-physical systems and to specify, validate, and implement secure systems.

Why Secure Software Matters

Some security breaches are less concerning, while others require immediate attention and can even be life-threatening. For example, in July 2015, Miller and Valasek reported a software vulnerability in the Jeep Cherokee that eventually urged Chrysler to recall 1.4 million cars. A software defect caused Ford to recall 433,000 cars the same year when a defect raised concerns about both theft and safety. But these are not isolated cases, and security problems are not specific to the automotive industry: malware and viruses also impact critical medical software . The FDA reported that 24 percent of medical device recalls are due to software issues, and that the industry must emphasize locating security problems and detecting malware. These cases show a general trend: as our world increasingly relies on software, more software-related issues will be reported, and security issues will continue to grow until we change the way we design software, especially when it is integrated in devices that are critical to safety and health.

Current software development processes used for cyber-physical systems are not appropriate to handle the new security challenges of the Internet of Things (IoT). Stories of breaches and defects are evidence that existing development processes and tools no longer scale. We need new methods that consider security from the very beginning. We need to capture security characteristics early in the development process, when designing the system architecture and validating the security policy, instead of later when end users are experiencing security problems. We also need to ensure the use of appropriate isolation methods, prevent data leaks, and avoid covert channels.

Model-Based Development Approach for Secure Systems

The SEI has led the design of the Architecture Analysis and Design Language (AADL) for 15 years and has been a key contributor to several extensions to the language, including the Error Model Annex and the ARINC653 Annex). The AADL community, which includes a team of SEI researchers, has used the language for the design, analysis, and implementation of cyber-physical systems in which collaborating computational elements control physical entities. Developing a new security-specific extension in AADL is an important next step in this work. By extending an existing standardized language (rather than creating a new language from scratch), we provide the ability for AADL practitioners to extend their existing models with security annotations, use analysis tools (such as for latency and scheduling), and take advantage of new, security-specific tools.

Our AADL security annex details how to use the core AADL semantics to specify security and isolation mechanisms. The annex also uses the AADL property extension mechanisms to add the following capabilities:

1. Specification of physical exposure: Can someone access and impact the component? For example, can someone replace the memory?
2. Specification of trust: Is a component verified so that it can be trusted (no propagation of fault or vulnerability)?
3. Security levels and domains: What are the criticality levels and domains of components? Does a component handle several domains or levels?
4. Specification of encryption mechanism: Is data encrypted when it is transported between two components? Is the encryption mechanism strong enough?
5. Specification of authentication mechanism: Does the system use an authentication mechanism (user/password, password, etc.)? Can we trust it?

Using the AADL core semantics and the security-specific extensions, system designers and developers can detect potential vulnerabilities in the system and analyze how they would propagate in the architecture before building it. Analyzing the software architecture offers the opportunity to detect vulnerabilities early in the design process and change the architecture either to mitigate or avoid them. For example, when a system will execute components in different security domains, the designer might want to avoid cross-domain interaction and isolate each domain by isolating components in partitions using a separation kernel.

We started by designing two analysis methods for AADL, the attack surface and the attack impact:

1. The attack surface is a list of all vulnerabilities of all system components. This analysis method infers vulnerabilities using the core AADL semantics (e.g., time and space partitioning through different memory or virtual components for each security domain) and the security extension (e.g., authentication, encrypted connections). The result of this analysis is a spreadsheet listing the vulnerabilities of each component of the AADL model.
2. The attack impact shows how a vulnerability affects other components and propagates through the architecture via buses, shared resources, and other pathways. For example, if a process is compromised, it can then affect all the other processes executed on the same processor, unless there is a security measure to avoid this (such as isolating processes using a separation kernel). The attack impact representation shows the AADL components, their associated vulnerabilities, and their impacts on other components. We designed a new Eclipse tool using the Sirius framework to represent and edit the attack impact.

These methods have been implemented in OSATE so that users can generate analysis reports from the AADL model. Beyond the generation of reports, we are also working on the generation of code--specifically the security policy--from the AADL model. In particular, the new code generator will automate the development of security policies, such as the configuration and use of encryption or authentication protocols or the deployment of software components in isolated partitions. This research has many benefits and will help OSATE users

1. simplify the development of secure systems: Engineers will not need to learn the specific configurations and deployment aspects of secure operating systems.
2. ensure development process consistency: By using the same artifact (the AADL model) for the analysis and implementation of the system, we ensure that the implemented system will comply with the validated specification.
3. avoid manual and error-prone manual code production: By using predefined code generation patterns that transform one high-level representation (an AADL model) into a low-level one (C code), we avoid mistakes of traditional code development (syntax and semantic errors, misunderstanding security requirements, etc.).

reduce re-engineering efforts due to a post-mortem security discovery: By helping users discover security issues early, this approach reduces potential post-mortem security defects and avoids recalls and updates that incur expensive costs and impact an organization's reputation.

Application to an Automotive System

Miller and Valasek published a technical report in 2014 that lists the attack surface and attack impact of several automotive systems. SEI researchers reused the data analysis from this report, established AADL models for several of these systems, and generated the attack surfaces and attack impacts automatically from these models. Our goal was to demonstrate that these analyses can be automatically derived from the AADL model and the results are similar to those established manually by Miller and Valasek Once these analyses are quickly and automatically derived from architecture models, engineers can use the same models for other analysis purposes as well.

Figure 1 shows a high-level representation of the electronic control units (ECUs) for a 2006 Toyota Prius and their interconnections using different buses in an AADL model, as shown in the technical report. This model contains only the ECUs and their connections to the physical networks; it does not detail software and other implementation components.

One aspect of this system is that the gateway component (shown in the center of the system) is inter-connected to all other networks. We assumed that such a component would be carefully designed, analyzed to ensure separation across networks, and configured to avoid any propagation of data from one network to another. Hence, we annotated this component as verified by the system designer.

Figure 2 below shows an extract from the spreadsheet representation of the attack impact for this system. Specifically, the figure shows how an attack on the Bluetooth or radio system would be propagated through the system. Because these networks are physically accessible, attackers could gain entry and try to compromise the device driver (these are complex protocols with a lot of code that might contain errors so that drivers or network stacks might be vulnerable to remote attacks). An attack could propagate through the navigation components and other connected ECUs, but it would not go beyond the gateway ECU. As the gateway ECU is validated and trusted, it would not be affected by the attack.

We also implemented a graphical representation of the attack impact; Figure 3 below shows an extract. Using this tool, we can graphically show the impact of a vulnerability on the overall architecture by changing the background of affected components to red. In this example, we show the impact of a vulnerability of the Bluetooth bus, which affects all components sharing the physical resource (in this case, the network). On the other hand, the propagation stops at the gateway component: Because this component is verified, we expect that it will stop the propagation of the vulnerability. Readers can check that this graphical representation is consistent with the spreadsheet representation in Figure 2.

After generating the attack impacts, the next step is to generate configuration and deployment code of the execution platform. Our research efforts are moving toward that goal, and we are investigating an opportunity to generate code that targets seL4, which is a microkernel that has been formally verified and used for the High-Assurance Cyber Military Systems (HACMS) program. By automating the production of seL4 code from high-level models, we plan to make the development of secure applications easier, faster, and more accessible.

Conclusion and Future Work

Recent reports of vulnerabilities have shown that IoT and cyber-physical systems domains need new development methods and tools to develop secure systems. This blog post presented how we are enhancing AADL to support the design, analysis, and implementation of secure systems. Using the AADL approach to model-based engineering, we can specify security requirements in a model, analyze the model to check the security policy before implementation, and generate the implementation from the model so that we are sure the code matches the validated requirements. We will present our new AADL-specific security extension at the spring 2016 meeting of the AADL standardization committee. We will also release the analysis tools during 2016, and we are working on a code generator to automate the configuration and deployment of software on top of secure platforms, such as the formally verified seL4 microkernel.

We are also working on a case study that will demonstrate the complete development process, from design to implementation. We are targeting an affordable hardware platform, with a total cost of hardware under $200, and will release all necessary software and models under an open-source license so that students, teachers, and hobbyists can start learning (and potentially improving) these technologies. This case study will be a platform to learn, study, and practice the development of cyber-physical systems using model-based engineering methods. We expect to release the models and tools by the end of the year.

Additional Resources

Learn more about AADL.

View our SEI Webinar Architecture Analysis with AADL.

Read all of our SEI Blog posts on AADL.