Automated security testing to provide more protection from the start
Automated software testing by Bosch
Our daily life is becoming faster, smarter and well-connected. However, between the positive developments of digitalization and the growing possibilities to connect products via the web, equally waits a challenge: Hacker attacks are not only increasing in number, they are becoming more complex. This fact alone raises the importance of cyber security. Bosch Research is working on solutions to make software more secure from the get-go, starting with the development process. This is only possible with a highly automated code analysis performed during software development.
“Smart Times“ and the answer by Bosch
IT security is a key enabler for connected products at Bosch. These products are mainly software driven ranging from a connected sensor to an autonomous car that is connected and all the way to smart home solutions. Connectivity exposes our products to cyber-attacks and the subtlest of these attacks happen remotely without needing any physical access to the product.
In practice, most attacks exploit flaws or weaknesses of the software. Software vulnerabilities are a large, and if not the largest security concern in connected products and the Internet of Things (IoT).
As modern software has several million lines of code, the manual search for vulnerabilities is impractical. Therefore, automated security tests are important to identify these software vulnerabilities that could compromise the security of our products.
For these reasons, a core objective of our research is to explore an effective methodology, tooling and infrastructure to allow us to perform automated security tests.
The solution: automated security testing
Conserving resources, optimal use of capacities and competencies – this has never been more relevant. The same goes for the field of automated discovery of security vulnerabilities, where existing code analysis workflows are optimized. Or simply put: to automate – while developing. Approaches such as automated bug search, automated code analysis and automated security testing are at the core of further development at Bosch Research.
For this, a Bosch research project named “Software Dependability Assurance” – short: SoDA – is focusing on automated security testing.
Bosch Research is working on a solution for the automated security testing of software, specifically tailored to Bosch connected products. This solution is based on a platform that enables continuous security analysis and testing throughout all phases of software development. The main focus of the platform is the automated discovery of software vulnerabilities within the source code. Software testing and the correlated discovery of security vulnerabilities in the source code are already fully automated and autonomous during the development phase. This is what we call “automated security testing” and it offers noticeable added value. As soon as the automated bug search is incorporated in the development process, work becomes more efficient and it is possible to react faster to the discovery of security vulnerabilities, leading to increased safety and a more efficient process.
In a nutshell, for developers automated code testing means:
Thus, according to Heise: “Things decide what action makes economic sense from their perspective and that of the person on whose behalf they are acting.” This is the economy of things at its most basic. “Our prototype demonstrates how things can negotiate and exchange real numbers back and forth. Being connected delivers economic value.”
Automated security testing allows us to perform industrial-scale bug detection early on in the development process. This, in turn, can significantly increase the software quality.
Automated security testing and the associated automated discovery of security vulnerabilities offers a comprehensible advantage to developers: The automated search for security vulnerabilities reduces manual effort significantly. As errors can be identified during the development process, automated code testing also helps increase the overall security of the systems.
The goal of our research
“IT giants like Microsoft, Google have white hat teams to test their products for security vulnerabilities internally before release. Within the SoDA project, the experts in my team have built a prototype that allows us to perform such kind of testing for Bosch’s connectivity-based products at scale.“
Our research goal is to find the sweet spot in terms of automation when it comes to security testing Bosch’s connected product family. For this, we are prototyping a platform that continuously inspects software for vulnerabilities throughout all phases of software development. We strive to automate the discovery of software vulnerabilities in order to ease software development. For software development, it means that the teams can continue focusing on functionality while benefiting from our automated security testing pipeline. This forms the basis for secure, reliable and innovative Bosch products.
Learn more about software analysis methods and hacker attacks
In the automotive domain, the source code must adhere to best practices, coding rules, and guidelines, such as the automotive-specific MISRA standard. State-of-the-art static code analysis methods can be used to validate the source code indeed adherences to such guidelines.
Code property graphs [1] provide the basis for advanced static source code analysis methods. The basic idea is to integrate graphs which are well-known in compiler construction – like abstract syntax trees, control flow graphs, and program dependency graphs – into a single graph, the Code Property Graph (CPG). A graph query language can then be used to search for patterns in the CPG, thereby uncovering hard-to-find security vulnerabilities. For instance, CPG can be used to find vulnerabilities where the attacker-controlled program input is used as an argument to a critical function..
---
[1] F. Yamaguchi, N. Golde, D. Arp and K. Rieck, "Modeling and Discovering Vulnerabilities with Code Property Graphs," 2014 IEEE Symposium on Security and Privacy, San Jose, CA, 2014, pp. 590-604. doi: 10.1109/SP.2014.44 Databases}, URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6956589&isnumber=6956545
Software fuzzing is a dynamic testing method where a program is executed many times with seemingly random input in order to find issues with robustness, for instance crashes. Coverage-guided fuzzers try to maximize code coverage during the test executions by instrumenting the source code during compilation (to obtain coverage information later on) and then varying the fuzzing input during test runs according to some heuristics based on previous inputs and coverage information. To fuzz software components such as the implementation of an API, a test harness has to be written that takes inputs from the fuzzer and injects it into the software component in such a way that the fuzzing input can be processed.
The Mirai botnet launched several high-profile, massive Distributed Denial-of-Service (DDoS) attacks in late 2016, causing a breakdown in some parts of the Internet infrastructure. The preliminary Mirai scan occurred on August 1, 2016 from an IP address belonging to DataWagon, a U.S.-based bulletproof hosting provider [2]. This bootstrap scan lasted approximately two hours (01:42–03:59 UTC), and about 40 minutes later (04:37 UTC) the Mirai botnet emerged. Within the first minute, 834 devices began scanning, and 11,000 hosts were infected within the first 10 minutes. Within 20 hours, Mirai infected 64,500 devices. In September 2016, 200,000–300,000 devices we infected; a peak of 600,000 infection was observed at the end of November 2016 [2]. So, for the first two months, this corresponds to 2.2–3.4 infected devices per minute or 17.6–27.2 seconds to infect a single device.
---
[2] Manos Antonakakis, Tim April, Michael Bailey, Matt Bernhard, Elie Bursztein, Jaime Cochran, Zakir Durumeric, J Alex Halderman, Luca Invernizzi, Michalis Kallitsis, et al. Understanding the mirai botnet. In 26th USENIX Security Symposium (USENIX Security 17), pages 1093-1110, 2017.
