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
Commentary
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
Edge-DRsplash-10-edge-articles
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
News
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-34390
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel function where a lack of checks allows the exploitation of an integer overflow on the size parameter of the tz_map_shared_mem function.
CVE-2021-34391
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel�s tz_handle_trusted_app_smc function where a lack of integer overflow checks on the req_off and param_ofs variables leads to memory corruption of critical kernel structures.
CVE-2021-34392
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel where an integer overflow in the tz_map_shared_mem function can bypass boundary checks, which might lead to denial of service.
CVE-2021-34393
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in TSEC TA which deserializes the incoming messages even though the TSEC TA does not expose any command. This vulnerability might allow an attacker to exploit the deserializer to impact code execution, causing information disclosure.
CVE-2021-34394
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in all TAs whose deserializer does not reject messages with multiple occurrences of the same parameter. The deserialization of untrusted data might allow an attacker to exploit the deserializer to impact code execution.