By Bill Graham
In the previous posts in this series, Part 1: Automation is the Key and Part 2: Security Improvement and the Software Development Lifecycle, I talked about the connection between the typical embedded device development process and the 5+1 improvement framework for embedded security. Figure 1 is an illustration of this connection (and discussed in more detail in a previous post).
In this post, I’m going to map out the tools that can help improve security and where they fit in the development lifecycle. Tools have different parts to play at each phase of the lifecycle, in some cases they are used throughout, and in others, their role is key in one phase and less so in others. In terms of security improvement, many of the tools and processes mentioned are not unique. In fact, the ideal situation is where security is considered a first class citizen in the priorities of a project. In this respect, tools for requirements, modeling and change management are meant to be used in the same fashion and don’t represent unique capabilities required in the 5+1 improvement framework. Again, the better the requirements and risk management, the better the security solution (assuming that security is given the right priority.)
Figure 2 illustrates roughly where each class of tool plays a role in the embedded device lifecycle. In each case, the unique capabilities required for improving security are called out but these don’t preclude the tools used in other areas.
High fidelity, system-wide, comprehensive simulation is an invaluable software development too. State of the art simulators are more than just processor emulators, today they provide full networked system, board, peripheral and processor simulation. The key benefit of system simulation is pulling in your integration and test cycles much early than previously possible. Secure design and system vulnerability can be tested earlier and more often. In addition, simulators offer unique features that real hardware can’t do and the ability to arbitrarily inject faults at any part of the system. An example of a system simulation tool is Wind River’s Simics product.
Integrated Development Environment
The Integrated Development Environment (IDE) is the developer’s desktop. Most developers’ tools integrate into the IDE in order to be visible and usable from this desktop. All of the tools discussed here are integrated with the IDE. IDE’s also provide many tools that are useful in improving security. For example, memory (runtime) analysis tools are critical for finding buffer overflow errors that are the root cause of many security vulnerabilities. System behavior and analysis tools are critical for tracing complex defects – essential for detecting and debugging security issues. An example of an IDE is Wind River Workbench.
Static analysis tools analyze source (and sometimes binary) code to find defects, security vulnerabilities and other programming issues. These tools can work on existing code bases and on new source as it is written by the developer. The key advantage of using static analysis is that security vulnerabilities are found as soon as the code is written – the cheapest and least riskiest time to find and fix them. In addition, vulnerabilities can be found in “hidden” parts of the code – code that is not executed during traditional testing. Static analysis tools can be run individually within each developer’s IDE and singularly on the project build providing a distributed and centralized analysis capability. Examples of static analysis tools include Coverity’s Security Advisor, Klocwork’s Insight, Programming Research’s QA-C/C++, and Grammatech’s Codesonar products.
Build and Continuous Integration Tools
Modern iterative and agile development methods require more frequent build and test cycles. Proper tools support for high frequency build and test in order for the productivity and quality gains of new methods to pay off. These tools provide the same benefits for security assessment and testing – security vulnerabilities can be found, fixed and test in a short cycle. As development methods evolve to include secure development, the return on investment for state of the art build and integration tools increases. An example in this area of tools would Electric Cloud’s ElectricAccelerator and ElectricCommander products.
Test Automation and Management Tools
Increased testing effort of developing an embedded device is the largest factor in its schedule and cost impact of improving security. Typically, testing for security vulnerabilities requires additional testing that differs from functional testing in that is attempting to break the system. Most functional testing is looking at most common usage patterns of the device. Security testing is often looking at edge cases, erroneous input, and misuse. In addition, test automation tools are required to improve test efficiency and effectiveness. Security testing will add risk, cost and effort to the testing effort for an embedded device. However, innovation in testing tools has made this impact significantly smaller. An example tool in this category would be Wind River Test Management.
Robustness and Fuzz Testing Tools
Due to the nature of security testing – often requiring out of range and erroneous data - new tools are required. Fuzz testing tools are designed to send malformed data to the device to induce errors. These tools use knowledge of various communication protocols (including specialized embedded control protocols) to create incorrectly formed packets, bad data and various extreme cases. Often this data is enough to induce runtime errors in the device – exposing potential vulnerabilities. These vulnerabilities are previously unknown (so called zero-day vulnerabilities) are especially critical to find and fix. Fuzz testing can be applied well before the device is in final form. Leveraging system simulation, fuzz testing can used in a simulated environment as effectively as it is in the lab. An example of a fuzz testing product is the security content package for Wind River Test Management (with technology licenses from Codenomicon).
Risk and Threat Management Tools
It’s likely that few embedded development projects are currently using automated risk and threat management tools. These tools are often used in highly safety critical projects where risk management processes are stringent and detailed traceability is required. However, these tools can prove valuable to any team that needs to maintain detailed information about their risk and security threat management plan. Automating the management security threats from early threat assessments all the way through the device lifecycle is important as a way to organize and retain the details, record the threat analysis, drive security test and fix priority, and end-to-end traceability. In addition, as security requirements start to become part of various industrial standards, threat management tools become increasingly essential. An example of this would be RSA Archer Threat Management.
Application Lifecycle Management Tools
Application Lifecycle Management (ALM) tools cover a wide variety of tools that are aimed at improving software development productivity and quality while managing and limiting schedule and budget risk. Requirements and change management, modeling and analysis tools, test management, product portfolio management and more. These tools are important for productivity, quality, compliance and security. Although not specific to security, incorporating security requirement management, secure design and security testing into the ALM scope is critical. In other words, the tools manage the security design lifecycle as they do the mainstream software development lifecycle. Examples of the ALM tools would be the IBM Rational suite of tools.
Tools are key to developer productivity and critical in improving security in embedded devices. In this age of increased scrutiny of security (and certainly other quality characteristics) and increased pressure for more features and tight schedules and budgets, the need for tools is greater now then ever. In this post I’ve mapped the tools to the embedded device development lifecycle and to the 5+1 step security improvement framework and what role each class of tool plays in the security improvement framework. I’d like to hear if there are other classes I’ve missed in the list and what tools you’ve found to be the most useful for improving your product security.
For additional information from Wind River, visit us on Facebook.