Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

8/17/2016
10:30 AM
Art Dahnert
Art Dahnert
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Security Must Become Driving Force For Auto Industry

Digital security hasn't kept pace in this always-connected era. Is infosec up to the challenge?

Automotive security can trace its roots back to the earliest beginnings of the automobile itself. Once cars became targets of theft, manufacturers responded to the demand for more security. As techniques were developed to circumvent those early locks, the industry stepped up with newer technology such as ignition locks and designs to fight the use of “slim jims” to open doors. In the second half of the last century, the public demanded alarm systems both from the aftermarket and as factory-installed options. Safety followed a similar path, from bumpers on early models to modern crash avoidance and protections such as airbags that are now mandatory.

As we’ve entered the “always on, always connected” digital age, however, digital security has failed to keep up. The auto industry is in a constant struggle to respond to problems encountered in the real world. While this isn’t new (manufacturers have been dealing with recalls for decades), what is new is that, in many instances, these problems are now tied to software. Toyota’s 2010 hybrid anti-lock brake software recall, Fiat-Chrysler’s 2015 recall of over a million vehicles to fix a software security flaw discovered by an independent researcher, and, most recently, the case of the first fatality in an autonomously driven vehicle, a Tesla, are some examples. More broadly, a report from financial advisory firm Stout Risius Ross showed that the percentage of vehicle recalls attributed to software problems tripled between 2011 and 2015.

This isn’t surprising--cars today are run almost entirely on software. The age-old problem of software development failing to “build security in” is leading to insecurity in automobiles today. The problem starts at a fundamental level: Technology is usually designed around functional requirements. Security faults arise from nonfunctional requirements--preventing bad things from happening. Without secure design expertise injected into the development of automotive software, the game of cat and mouse between attackers and defenders will initially be won by the attackers.

Beyond secure design, there is also the problem of implementation. Even a strong design can fall victim to mistakes made during coding. And, like most software developers, automotive and embedded-software engineers aren’t always concerned about security. They aren’t trained to think about how their code can be used in ways that challenge their assumptions about the way it’s intended to work. This is normal; software developers are trained and paid to build software, to create new features and functionality. They normally aren’t trained how to break it. This can result in software that fails in unexpected ways on the road.

The auto industry needs to start thinking like today’s attackers. As early as possible, engineering teams must bring in security experts who can help point out problems in design and requirements. Teams must perform detailed security analysis on new and existing designs, using recognized software security techniques such as threat modeling. By including security experts in the software development life cycle, the teams will get a different perspective on how their software can be abused once it lands on showroom floors. This effort can then be validated through the use of penetration testing prior to final production, to catch any implementation-level mistakes.

Many new initiatives in the industry will revolutionize the way the public uses vehicles. These include automated self-parking, self-driving cars, and computer-based ride-sharing technology, to name a few examples. These new technologies will require software to communicate with vehicles that are on the road as well as detect and avoid pedestrians, road debris, highway infrastructure, etc. All of this will require software to interpret and respond to millions of pieces of data per mile traveled. If the design of this software can’t keep out malicious data, or if choices made by the designers don’t stand up to real-world testing, then lives can be lost.

In the past, automotive companies would invent technology to offer as optional equipment. If the technology demonstrated increased safety, it might end up as a government-mandated standard feature, such as airbags and anti-lock brakes. However, doing the same for a purely software-based features might be very difficult. That’s because software weaknesses (design flaws, implementation bugs) can go undiscovered until the proper conditions exist to bring them to light, which may not happen as part of standardized regulation or certification.

In other words, the automotive industry needs to embrace a new culture of security, much like other industries have done to reduce risk to their customers. (Microsoft, with its Security Development Lifecycle effort, is one example.) Now more than ever, the security of a vehicle is directly tied to its safety. Understanding how other industries have addressed the software security challenge is a first step, which will allow the auto industry to head off some of the problems that are beginning to show up more frequently (such as Volkswagen’s poorly designed remote key fobs). Some of the manufacturers are already moving in this direction; however, it’s a slow progression and it won’t be enough to keep pace with current technology. This cultural shift needs to happen as fast the technological shift. Is the auto industry up to the challenge?

Related Content:

Art Dahnert is a managing consultant with over 19 years of experience in the software industry, including over 8 years in application security. Dahnert has completed hundreds of security risk assessments, penetration tests and vulnerability assessments of web applications, ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Exploiting Google Cloud Platform With Ease
Dark Reading Staff 8/6/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-8904
PUBLISHED: 2020-08-12
An arbitrary memory overwrite vulnerability in the trusted memory of Asylo exists in versions prior to 0.6.0. As the ecall_restore function fails to validate the range of the output_len pointer, an attacker can manipulate the tmp_output_len value and write to an arbitrary location in the trusted (en...
CVE-2020-8905
PUBLISHED: 2020-08-12
A buffer length validation vulnerability in Asylo versions prior to 0.6.0 allows an attacker to read data they should not have access to. The 'enc_untrusted_recvfrom' function generates a return value which is deserialized by 'MessageReader', and copied into three different 'extents'. The length of ...
CVE-2020-12106
PUBLISHED: 2020-08-12
The Web portal of the WiFi module of VPNCrypt M10 2.6.5 allows unauthenticated users to send HTTP POST request to several critical Administrative functions such as, changing credentials of the Administrator account or connect the product to a rogue access point.
CVE-2020-12107
PUBLISHED: 2020-08-12
The Web portal of the WiFi module of VPNCrypt M10 2.6.5 allows command injection via a text field, which allow full control over this module's Operating System.
CVE-2020-7374
PUBLISHED: 2020-08-12
Documalis Free PDF Editor version 5.7.2.26 and Documalis Free PDF Scanner version 5.7.2.122 do not appropriately validate the contents of JPEG images contained within a PDF. Attackers can exploit this vulnerability to trigger a buffer overflow on the stack and gain remote code execution as the user ...