EN 
DE Does that fit together?
Author: Dr. Ralf Huuck, Synopsys
Contribution – Embedded Software Engineering Congress 2016
Modern software processes are strongly driven by short product cycles, modularity, and rapid time to market. This is reflected in so-called DevOps processes as well as in the trend toward increasingly agile approaches that provide a flexible response to changing requirements. On the other hand, security requirements, particularly in the embedded software sector, have increased significantly. Security, however, requires thorough planning, a sound security architecture, and specialized knowledge, which preclude an ad hoc approach. This presentation will examine these apparent contradictions and their resulting consequences.
Introduction
Software security is a major challenge for the development of embedded systems. In particular, the security of systems that interact with the outside world requires expert knowledge that is often scarce [1]. Furthermore, application security was not originally a focus in the design and implementation decisions of embedded systems. However, this is changing as software gains prominence and security requirements increase. As a result, the systems industry is also increasingly transforming into a software industry.
Changed development processes: Agile and DevOps
One of the major trends in the software industry is to shorten product cycles in order to be faster and more flexible in the market. Software often allows for the continuous addition of new capabilities as upgrades, improving and further developing the product beyond its software features. Shortening product cycles is often accompanied by a so-called agile development process. This means that new capabilities are defined in quick succession, the architecture may be expanded accordingly, and an implementation takes place that extends the existing product and can be tested, in some cases incrementally, against the previous version. The goal is to offer continuous product improvement while simultaneously responding flexibly to customer feedback.
The agile development approach is nowadays complemented by the so-called DevOps expanded, whereby not only is software development handled in an agile manner, but also the business process, including the compilation of the software and its delivery to the customer, is largely automated.
DevOps and its automation present an additional challenge to software security. Unlike the waterfall development model, development cycles are often extremely short, the actual implementation is constantly changing, and the testing process is often performed concurrently rather than as a separate, subsequent process. This contradicts fundamental security requirements, which demand a stable, secure architecture and an often lengthy and manual testing process that, for example, enables security-relevant penetration testing.
DevOps and Application Security
To address the security challenges in the DevOps process, it is essential to incorporate a high degree of automation into the security testing process. This requires the use of software tools that not only run automatically but can also be used directly within the development process. As a consequence, the security testing process is increasingly shifting from separate, specialized test teams to software developers.
Below, we describe some of the tools and methods suitable for security testing by software developers. Some of these methods are already familiar from quality assurance, while others have recently been developed specifically for software security.
Tool classes for safety testing
The following overview lists some examples of tools that can be used fully automatically and can therefore particularly support the DevOps process. We distinguish between the following tool classes:
Static program analysis
Static program analysis helps to detect and fix programming errors directly during development. These include errors such as SQL injections, memory overflows, or unvalidated input. Static analysis often helps program development to identify and prevent security vulnerabilities early on [3]. Typically, static analysis runs directly within the development process (see Fig. 1, PDF)
Embedded runtime monitors
Runtime monitors observe the behavior of a system during execution. They are capable of automatically detecting certain classes of errors, such as suspicious input. Runtime monitors are suitable both for complementing functional tests and for providing protective monitoring during program execution. Furthermore, there are active runtime monitors that can actively test inputs and observe their responses. This can be particularly helpful for web applications to uncover the behavior of potential attackers.
Automatic fuzzing of protocols
Fuzzing involves testing systems with a large number of pseudo-random inputs and data [5]. It is frequently used in penetration testing and can simulate attacker behavior. Protocol fuzzing goes a step further: it uses background knowledge about the actual protocols to automatically generate targeted inputs that test for potential weaknesses in the protocol implementation (see Fig. 2, PDF).
Binary analysis of third-party components
A major challenge in the DevOps process is integrating and testing third-party software. This can include open-source applications and libraries as well as binary components from vendors. To address this challenge, automated scanners for both source and binary code exist, checking software against a list of known faulty libraries and code. These lists often include CVEs and CWEs [4] maintained by NIST or other organizations.
challenges
Despite this array of new automated tools for improving software security, a residual risk remains, which is sometimes higher in the DevOps context than in the traditional approach. This is partly due to the fallibility and limitations of these tools, or rather, the fact that they often don't cover all scenarios, meaning human testing is still essential. Furthermore, these tools neglect the overall architecture, which, if not designed correctly, can dictate a flawed security concept. Therefore, human intervention remains indispensable for designing and testing secure software.
Summary
The processes and tools presented here make it possible to drastically improve the overall software security of embedded systems. The ability to run these tools fully automatically opens up the option of integrating them directly into the DevOps process. While these tools cannot cover the entire security process, they do allow for more targeted and effective use of human resources.
References
[1] John Viega & Gary McGraw. Building Secure Software. Addison Wesley – ISBN 0-201-72152-X.
[2] James D. Brown. Mythbusting: DevOps and Security. Wired Magazine, 2013.
https://www.wired.com/insights/2013/10/mythbusting-devops-and-security/
[3] Ralf Huuck, Ansgar Fehnker, and Rodiger Wolf. Model Checking Dataflow for Malicious Input. Proceedings of the 6th Workshop on Embedded Systems Security Taipei, Taiwan, Oct 2011. ACM, Article 4, 10 pages, ISBN: 978-1-4503-0819-9.
[4] Common Weakness Enumeration. https://cwe.mitre.org/
[5] Barton Miller. In Ari Takanen, Jared DeMott and Charlie Miller, Fuzzing for Software Security Testing and Quality Assurance, 2008, ISBN 978-1-59693-214-2
Agile & Scrum – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Agile & Scrum.
Training & coaching on the other topics in our portfolio can be found here. here.
Agile & Scrum – Expertise
Valuable expertise on the topic of Agile & Scrum is available here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
