Connected Car Driving Change in Defect Detection€¦ · vehicle’s power train. To this end, some...

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

| 1

© VDC Research | 679 Worcester Road, Suite 2 | Natick, MA 01760 | (508) 653-9000 | vdcresearch.com

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)

| 2


The benefits of connectivity, however, yield new risks – many of which engineering organizations are ill-

prepared 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.

| 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)

| 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

| 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.

| 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

| 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.”

| 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.)

| 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

| 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

| 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.

| 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

| 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 metric-

based 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.

| 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

the leading trends impacting next-generation device markets, such as security,

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 [email protected].

Contact Chris:

[email protected]

Connected Car Driving Change in Defect Detection€¦ · vehicle’s power train. To this end, some...

Documents

Transcript of Connected Car Driving Change in Defect Detection€¦ · vehicle’s power train. To this end, some...