Connected Car Driving Change in Defect Detection

Transcription

1 2016 IoT & Embedded Technology Connected Car Driving Change in Defect Detection Exclusive License to Distribute: Synopsys By Chris Rommel, Executive Vice President with Steve Hoffenberg, Director, and André Girard, Senior Analyst

2 1 Introduction Product design is rapidly evolving. From aesthetics to functionality requirements to the underlying development disciplines, the magnitude and pace of change facing engineering organizations is challenging incumbent processes and resources. In no vector has this evolutionary trend manifested itself more than in software design. As system complexity has forced change in engineering organizations, software emerged as their primary vehicle for innovation and differentiation. This dynamic is especially acute in automotive design, in which differentiation is now equally driven by the center-stack user experience as it by the vehicle s power train. To this end, some cars now have more than 100 ECUs and greater than 100 million lines of software code. Now, the Internet of Things (IoT) has emerged as the next trend influencing OEMs design requirements and new business objectives. While connected systems are not new, the frequency and depth to which the industry is embracing this dynamic as the foundation of their systems' new value add is accelerating. For example, within the automotive industry, there is an opportunity for systems integrators, OEMs, and/or dealers to develop new revenue streams through new services, such as functionality-based upgrades, content/streaming services, and location-based/concierge services. Exhibit 1: Percent of New Vehicles with Internet Connectivity, by Connection Type (not mutually exclusive)

3 2 The benefits of connectivity, however, yield new risks many of which engineering organizations are illprepared to manage. One of the inherent challenges to securing an automobile is that security risks now extend well beyond the center stack and telematic systems. Engineering organizations must now manage a very broad potential attack surface across the dozens of ECUs found within a vehicle. In essence, each device serving as a link in the proverbial chain of the system-of-systems design must be secured. Further, each device should be itself secure from time of boot before connecting to Internet services, or V2V and V2I networks. Despite the inherent risks, the role of connectivity as a central pillar of next-generation automotive design is undeniable. As such, this white paper focuses on some of the process and technology changes that engineering organizations can adopt to augment security at the device level.

4 3 The Software Problem Software growth is fundamentally challenging and changing development processes at automotive OEMs. In fact, engineers expect lines of in-house code to grow nearly twenty percent for their next projects. This rate is not only faster than that expected within enterprise/it projects, but it far outpaces what OEMs could expect to derive from organic headcount additions or productivity gains. While software content growth rates within center-stack applications are certainly pacing the industry, horizontal content creation demands are driving code growth across all ECU types. As a result, many automotive OEMs are struggling to evolve and adapt their R&D resources. Despite efforts over the last decade, many still lack enough software engineers or institutionalized software development best practices that can effectively scale in parallel. Upper-level managers and executives at automotive OEMs are also often mechanical engineers that lack a complete understanding of the software development process. Furthermore, today s software development cycles are often at odds with the traditional, serial V-model workflows that have been used in the industry for decades and were built to cater to hardware integration milestones. These challenges are then compounded by the tiered supply chain of software development common in the automotive industry, wherein much of the end product software content is sourced from third parties. Exhibit 2: Percent of Total Software Code in Final Design of Current Project by Origin (Average of Automotive Respondents)

5 4 Development organizations need to leverage more sources to meet content creation demands. This creates additional supply chain management and potential code quality issues. Now the increasing use of open source in automotive designs yields new challenges. In-vehicle infotainment systems have been leading this with more organizations opting to use open source embedded operating systems such as Android, GENIVI and other Automotive Grade Linux-compatible distributions. Furthermore, the increasing adoption of and familiarity with virtualization is emboldening OEMs to use open source software on more ECUs which themselves are becoming more powerful and are more likely to include the on-chip memory necessary to run a more robust operating system such as Linux. Ultimately, the growing diversity of code sources, as well as the inclusion of software and system assets from a variety of tiers of ODMs in the automotive supply chain, necessitate more formal code quality check-ins and ecosystem SLAs based on specific quality process milestones. The IoT is also driving more auto organizations to develop software outside their traditional areas of expertise, such as for connectivity middleware and context-aware user interfaces. Going forward, the need and demand to support periodic firmware updates and post deployment content will only increase its influence on product requirements and further stress development resources and quality. First, the interaction between different systems common in automotive system architectures can be difficult to test at the code level. Now engineering organizations may need to coordinate field updates of multiple systems with interdependent functionality. Exhibit 3: Estimated Total Number of Defects or Software Patches Customers Report/ Require per Deployed Year in Field (Mean of Respondents) Already, automotive OEMs must contend with a large number of defects reported once their products are in the field (see Exhibit 3). Now, however, the IoT yields an opportunity for post-deployment content. Updates can be used as a means to augment functionality and the user experience, and even to deliver premium, user-customized applications or media. Unfortunately, testing practices in the automotive domain were not

6 5 designed for adaptive and evolving functionality. Periodic firmware and application software updates become an even bigger issue in the complex automotive supply chain. As a result, it will become critical for OEMs and System Integrators to extend and institutionalize the use of testing tools to help mitigate potential defects or integration issues. With the IoT exposing aforementioned software development expertise gaps, code growth rates are thus augmenting the growing security issues plaguing the industry. While security has been a longstanding consideration in IT development, it remained outside of the primary concerns of the many embedded engineers who did not previously even focus on connectivity. In practice, vehicles are especially complex on this dimension. For one, the high number of ECUs, with multiple interfaces and overlapping software controls, can create issues where the infiltration of one device can impact other systems, as recently seen when hackers bypassed the virtual firewall between Jeep s infotainment and safety-critical systems. Additionally, because of the safety-critical design implications, the auto industry is also a highly regulated one. Unfortunately, standards must, by definition, trail the pace of market evolution and the identification of a need for new industry regulation. As such, the pace of evolution in the IoT can antiquate or greatly reduce the utility of any standards introduced. Without regulation-driven obligation, OEMs must instead act proactively to preclude the introduction of unneeded risks and liabilities on their businesses.

7 6 Security Threats Increasing Embedded engineering organizations inherently understand the increasing importance of security. However, this understanding does not always translate to action or the implementation of improved security mitigation techniques. Surprisingly, only about half of surveyed automotive engineers viewed security as Important, Very Important, or Critical to their current project. The embedded engineering population at large, which includes engineers working on a wide range of device types, views security as a bigger issue [See Exhibit 4]. Traditionally, auto OEMs have been more focused on meeting functionality and time-to-market requirements and producing the minimum documentation and artifacts required to meet requisite process and safety standards. Now, however, safety and security are invariably intertwined as more cars become connected. Exhibit 4: Importance of Security in the Current Project (Percent of Respondents) In concert with the rising security risks inherent in next generation automotive system design, the breadth and magnitude of risks facing engineering organizations are also expanding. As with any system whose

8 7 failure can lead to physical harm, tort liabilities from security defects are a huge risk. The risks facing automotive system manufacturers extend far beyond this however. For one, data privacy and its compromise is becoming a bigger concern for many consumers and governments. The largest potential cost facing organizations, however, is likely the damage sustained to an organization s brand equity following a publicized breach. The challenge facing many organizations is that, since ubiquitous automotive connectivity is a relatively new phenomenon, there have been few documented security failures. This in turn makes formal risk assessment and the ensuing change and investment analyses inadequate especially since engineering organizations will generally default to the status quo with a lack of complete information. Exhibit 5: Results of Security Vulnerabilities (Percent of Respondents) In 2010, before most vehicles had built-in connectivity, overall system-level security problems were documented by technology researchers from the Center for Automotive Embedded Systems Security (CAESS). The researchers had successfully hacked numerous subsystems of a pair of test cars, including the ability to engage brakes as well as prevent braking while a vehicle was in motion. CAESS separately reported:...[w]hile each supplier does unit testing (according to the specification) it is difficult for the manufacturer to evaluate security vulnerabilities that emerge at the integration stage. Traditional kinds of automated analysis and code reviews cannot be applied and assumptions not embodied in the specifications are difficult to unravel.

9 8 Even more compelling CAESS conducted those tests before most vehicles had built-in Internet connectivity. With the addition of such connectivity, the complexity of embedded systems, the security challenges, and the potential attack vectors rise dramatically. Securing System Design There are a number of ways to improve the security of a connected system: through its design and component selection, its data storage policies, the communication technologies used, as well as the software used to manage the device once deployed. To properly mitigate risk, security cannot be addressed at the device level or infrastructure level only. Instead it must be addressed with an end-to-end view of the entire system and an understanding that the weakest link of the chain will be the most exploited entry point. Unfortunately, many security mitigation tactics are dependent on end integrators and/or end-user decisions. As a result, OEMs must focus on building a foundation of overall system security by securing the native device. One of the largest challenges facing OEMs and ODMs is that even then there a number of factors that can influence security, from runtime selection to the inclusion or exclusion of specific hardware components. Furthermore, the requirements for and applicability of these measures will vary based on the type of ECU being designed and the availability of system resources. For example, a safety-critical system s latency requirements may preclude the use of a hypervisor that could otherwise help separate and secure its OS and applications from other systems. Additionally, the lack of sufficient on-chip memory resources can likewise limit OS selection and prevent the addition of supplemental security solutions (e.g. white/black listing, agent-based system monitoring, or policy management, etc.). As such, the best place for OEMs to start to address security is often the quality of the embedded software under development. Automated software testing is becoming an increasingly valuable method for addressing both system functionality and security. The use of testing tools is certainly not new in automotive. However, their utility is gaining renewed focus at many engineering organizations given the mounting software content creation pressures. While the traditional use cases and tools in the domain can improve security, since code quality breeds security, incumbent tools and processes can fall short of providing the thorough security risk assessment OEMs need. For example, traditional code coverage analysis and cyclomatic complexity metrics do not do enough to help companies understand their software s complexity and related risk. Additionally, dynamic testing is an important part of automotive software development best practice, but the unit testing tools pervasive in the industry are not particularly helpful to the identification of security risks. (Other tools targeted at system integration testing and hardware-in-the-loop simulation are likewise a valuable part of the automotive software development cycle but are less critical for security defect detection.)

10 9 Exhibit 6: Types of Tools Used on Current Project (Percent of Respondents) Static analysis tools, however, are becoming an increasingly valuable asset for the mitigation of security vulnerabilities. Within the automotive industry, particularly within Europe, engineering organizations have been longstanding users of static analysis tools. In fact, the use rate cited by surveyed engineers is much higher than that within the overall embedded market (see Exhibit 6). Much of the traditional use within the auto industry, however, has been focused on testing adherence to MISRA coding standards. Their utility extends far beyond simple pattern checking and syntax parsing, however. The tools can be used as a valuable part of strategies to manage supply chain risk from vulnerabilities in third-party code. For example, they can also be used to address vulnerabilities identified within Common Weakness Enumeration (CWE), a project sponsored by MITRE Corporation that catalogs common weaknesses that are indicative of potential security issues. Additionally, not only can they be used to evaluate all end production code, but they can also serve as a mechanism to enforce quality standards and Service Level Agreements (SLAs) with suppliers. Many automotive engineers do not even recognize the value that static analysis can bring to security defect mitigation. Not a single surveyed static analysis tool user in that vertical reported Impact on security as one of the important factors to their selection of their static analysis tool (see Exhibit 7). Some static analysis

11 10 tools, however, are actually quite adept at identifying security vulnerabilities. For example, SQL injections and cross-site scripting, which can often be used to obtain unauthorized access to systems and other coding and memory utilization issues such as buffer overflows, can likewise be exploited by hackers. Exhibit 7: Most Important Factors in the Selection of Static Analysis Tool (Percent of Respondents) The need for software security testing tools extends beyond those tools traditionally used within the embedded market. Penetration testing and fuzzing tools, for example, were not previously important for automotive software development since they are specifically intended for connected systems (or at least those receiving a variety of external or environmental inputs). They are however, valuable additions to the automotive software QA processes given their ability to test software robustness and assess additional attack vectors and protocol implementations. Penetration testing, for example, can simulate attacks from outside communication points, replicating the threat of a man-in-the-middle attack. Meanwhile fuzz testing can simulate the effect of race conditions, malformed inputs, and other unexpected data that can lead to software failures. Ultimately, engineering organizations can best decrease their risk by implementing a comprehensive and integrated software testing suite. The combination of dynamic and static techniques generally improves the

12 11 overall quality of the testing results by allowing OEMs to identify the line of code where a security vulnerability occurred and improve the contextual understanding of code coverage. Additionally, with more automotive systems capable of running applications with Internet-connectivity, engineering organizations could likewise gain value from using Interactive Application Security Testing (IAST) solutions, which are becoming increasing common practice for enterprise application development. For example, within automotive design, engineering organizations can use these solutions to assess how malicious traffic would impact a connected IVI application at runtime and then identify where identified vulnerabilities reside in the target code or libraries. Furthermore, IAST offers developers additional efficiency improvements by eliminating the false positives common to traditional static analysis. The risks within software code bases extend far beyond simple functional code defects, SQL injections, or buffer overflows within in-house code bases. The use of open source or third-party software can also lead to the introduction of more risks. Development organizations (and security solution providers) already are under pressure to keep white and black lists up-to-date to account for the rapidly evolving threat landscape. Many times, however, organizations are also unknowingly incorporating known security vulnerabilities into their products based on compromised open source or third-party code introducing corporate risks that should be completely avoidable. In addition to the possible inclusion of outdated or unpatched third-party software components with known security vulnerabilities, there are also risks stemming from potential IP infringement. Not only can the downstream identification of such issues lead to project delays and financial damages due to IP owners, certain open source licenses (such as old versions of the GPL) can contaminate internal code assets or otherwise mandate source code distribution polices that are not practical for commercial product creation. As an example, Cisco famously was sued for an open source software (OSS) license violation pertaining to software found in routers made by a company that it had acquired (Linksys). While many early adopters of software composition analysis tools were fueled by M&A and funded by legal departments, their use is becoming a critical best practice of software development. As such, we believe that more organizations should establish policies and adopt software composition analysis tools to manage OSS assets. The use of those tools can also help ensure that the latest, most secure versions of software are being used. OSS governance policies and tools become even more important in a hierarchical supply chain such as that used for automotive design where devices and software are combined from a range of sources.

13 12 Conclusion & Recommendations Increasing system complexity necessitates change. IoT trends are rapidly redefining product design requirements and placing new pressures on engineering organizations. Organizations unable to adapt quickly to today s engineering challenges risk long-term issues and significant financial costs. Paramount among these new issues with which product development organizations must contend is growing threat of and liability from security vulnerabilities impacting connected devices. In order to adequately mitigate risk or at least fulfill due diligence requirements engineering organizations must instill changes that span people, process, and tools: 1. Evangelize Change The automotive industry is one built on a foundation of engineering and process rigor. However, this professional legacy has also established an overriding culture of conservatism that is only now beginning to break down as OEMs pursue the opportunities presented by connected car experiences. In order to both overcome initial organization inertia as well as promote broader recognition of security risks, it is critical that development organizations identify internal champions to evangelize the needed changes. Further, although security risk is intuitive, the quantification of risk is not in an industry without a long history of security issues, let alone connectivity. As such, internal advocates and ongoing training are even more critical to support investments and change that often must come before traditional risk and cost assessment models. 2. Automate and Integrate Security and Quality Testing into the Development Workflow Embedded software development processes are evolving to match the content creation and update cadences required by IoT market dynamics. With this development pressure, QA practices must also evolve. The traditional, serial delineation of development tasks has become antiquated. As such, engineering organizations must find ways to integrate and accelerate testing within the entire development cycle. Doing so can enable developers to identify and triage defects in their code before check-in and build, preventing downstream issues and, consequently, often lowering cost of their remediation. This practice is generally becoming increasingly important to support Agile development methodologies, which are now even being used in safety-critical industries such as aerospace/defense and automotive. Furthermore, the integration of multiple testing modalities and tools can improve the accuracy and actionability of testing results. For example, the integration of static and dynamic analysis can help better identify latent defects and can help improve future testing by using static analysis results to tune case development. In addition, the adoption of IT and network-centric testing solutions, such as penetration and fuzz testing, are an important complement to traditional embedded software and

14 13 system integration testing techniques in order to effectively assess the threats facing connected systems. 3. Adapt Standards and SLAs to Augment Commercial Solutions While the rapid identification of software and security vulnerabilities with testing practices is critical, engineering organizations should take further steps to preclude their introduction into code bases. Common coding standards such as MISRA-C and coding frameworks such as CERT-C and CWE can help developers better audit their own work. Additionally, the adaption of the SANS Top 20 Security Controls for IoT should help organizations align with other best practices to limit exposure to security risks. Ultimately, however, OEMs should look to establish their own internal and external based SLAs to help control the quality of software exchanged at various stages within the development process and at handoff between suppliers. Such agreements should be metricbased criteria that promote repeatable testing processes using common platforms, such as through the use of a static analysis tool with a particular custom configuration to ensure a baseline level of code integrity.

15 14 VDC Research About the Author Chris Rommel is responsible for syndicated research and consulting engagements focused on development and deployment solutions for intelligent systems. He has helped a wide variety of clients respond to and capitalize on Contact Chris: the leading trends impacting next-generation device markets, such as security, crommel@vdcresearch.com the Internet of Things, and M2M connectivity as well as the growing need for system-level lifecycle management solutions. Chris has also led a range of proprietary consulting projects, including competitive analyses, strategic marketing initiative support, ecosystem development strategies, and vertical market opportunity assessments. Chris holds a B.A. in Business Economics and a B.A. in Public and Private Sector Organization from Brown University. Steve Hoffenberg is a leading industry analyst and market research professional for Internet of Things technology. He has more than two decades of experience in market research and product management for technology products and services. Prior to joining VDC, he spent 10 years as Director of Consumer Imaging and Consumer Electronics Research at the firm Lyra Research, where he led industry advisory services providing extensive market research on consumer technology trends, user adoption, market sizing, marketing strategy, and competitive analysis for major consumer electronics manufacturers. Previously, he worked in product management for electronic design companies that developed and licensed embedded digital imaging and audio products. Steve holds an M.S. degree from the Rochester Institute of Technology and a B.A. degree from the University of Vermont. André Girard brings valuable perspective to the market research and consulting of the M2M Embedded Software & Tools team, having previously covered connected devices for both the Telecom and Embedded Hardware practices at VDC. His primary areas of expertise include lifecycle management solutions, Agile development, and cross-domain engineering integration. André s M2M technology background includes opportunity sizing and forecasting, market and technology assessments, competitive analysis, strategic marketing assistance, and M&A due diligence support. He also gained important experience as an independent consultant covering telecommunications and the smart grid. André holds a B.A. (magna cum laude) from Massachusetts College of Liberal Arts. About VDC Research Founded in 1971, VDC Research provides in-depth insights to technology vendors, end users, and investors across the globe. As a market research and consulting firm, VDC s coverage of AutoID, enterprise mobility, industrial automation, and IoT and embedded technologies is among the most advanced in the industry, helping our clients make critical decisions with confidence. Offering syndicated reports and custom consultation, our methodologies consistently provide accurate forecasts and unmatched thought leadership for deeply technical markets. Located in Natick, Massachusetts, VDC prides itself on its close personal relationships with clients, delivering an attention to detail and a unique perspective that is second to none. For more information, contact us at info@vdcresearch.com.