As hackers seek to access electronic systems and data, government mandates have intensified cybersecurity regulations for OEMs.
In an increasingly online world, the automotive industry has found itself in a position, like many others, that is almost entirely reliant on technology. Cars today can contain up to 150 electronic control units and about 100 million lines of software code – that’s four times more than a fighter jet in 2020. By 2030, this number is projected to rise to 300 million lines of code. With all that programming, how, and why, are OEMs supposed to keep track of what’s inside?
Speaking to Adam Boulton, chief technology officer for BlackBerry Technology Solutions, it becomes clear – the digital security performance of vehicles all “comes down to how the standards and regulations are followed”, and he draws attention to one regulation in particular: “WP.29 R155 is an automotive regulation that has come into Europe from the United Nations Economic Commission for Europe which OEMs have to follow by law.”
As the first-ever internationally harmonized cybersecurity regulation, WP.29 R155, which was introduced in early 2021, stipulated that all digitalized passenger cars, vans, trucks and buses needed to be capable of verifying that cybersecurity risks have been managed. This framework was to be built into the vehicle design process, specifically during testing. “It’s one of the most recent, prevalent legal requirements to emerge in the industry in Europe. It focuses on the testing [of vehicles], the processes and assuring the production of safe and secure vehicles. Governments now have the authority to close down OEMs’ manufacturing plants if it has been deemed that you are releasing insecure and therefore unsafe vehicles onto the roads.”
BlackBerry’s real-time operating system, QNX, is designed to increase the security of embedded systems that have been developed to manage the computer hardware and software resources installed in vehicles. Boulton explains, “What makes QNX ideal for automotive is its ability to build a safety system. QNX is an ASIL D-certified real-time operating system. There’s often confusion about this as people assume that it is just very fast. However, that’s not what a real-time operating system is. What’s most important about this type of operating system is that it has a built-in reliability to do what it says it’s going to, on time. That encompasses everything in the SDLC [systems development life cycle] from safety testing and secure code reviews to threat modeling, functional safety requirements and binary static analysis.”
In particular, timeframes play a crucial role in these digital safety procedures. “If you don’t deliver those jobs on time, it has the potential to cause damage to life or limb,” Boulton says. “For example, it’s regulation that when you put a vehicle into reverse, the reverse camera has to come up in 1,750ms. So it’s important to test that timing and give as many assurances as possible. But you don’t typically do this for security-critical systems.”
Explaining his point, Boulton brings up Facebook. Though the platform can be considered a security-critical system due to the amount of personally identifiable information (PII) data that it holds, it doesn’t place the same timing demands on its system as a vehicle. “With security-critical systems like Facebook, the timing is not crucial. It doesn’t matter if there’s a five-second delay when you post your status updates, but you can imagine how different that is in automotive safety-critical systems.”
Broken into five key areas, QNX incorporates active security enforcement, secure boots, runtime monitoring, data protection and network security. However, when asked how QNX juggles security and safety and performance, Boulton highlights runtime monitoring – the process that looks for threatening intrusions and anomalies in protected data. In particular, he emphasizes isolation, a familiar concept, in an unexpected context: “Making sure that things run on time always comes down to isolation. When people talk about defense in depth, you’ll often hear the medieval castle analogy. While that’s fine for [most] security systems, it’s not something that I like to use anymore. Instead, I like to think that we’re building Alcatraz.”
Alcatraz (the island in California known for its fortified federal prison) has been heralded as the ultimate maximum-security prison, holding everyone from criminals who had a history of escapes to famous offenders like Al Capone. “Alcatraz is a better framework because prisons are set up with degrees of separation and the timing of functions [is crucial]. This is massively significant for safety systems – isolation of processes and policies and mandatory access controls.”
“With prisons, there’s also controls, CCTV monitoring systems, keys and audit logs to separate guards and cell mates. That design architecture rings so much more true for the complexity of an automotive software system and the ongoing management of that separation. It’s key not just for security, but also safety, that things are running on time. After all, if one process hogs an entire CPU or memory, there’s nothing left to run another safety-critical process. For example, you don’t want that reverse camera coming up in 10 seconds [rather than 1,750 milliseconds], just because some other process soaked up all the resources.”
However, to know how to monitor a process, OEMs first have to know what is actually in each piece of software. “This is related to the Executive Order 14028 of the Software Bill of Materials (SBOM),” Boulton says. President Biden’s Executive Order stipulated that “any vendor, supplier or provider of technology solutions to the US government must provide a full software bill of materials to ensure that any security vulnerabilities in the software supply chain are identified and remediated immediately”. In response to the new standard, BlackBerry QNX added new features to BlackBerry Jarvis on January 5, 2022, to enable users to analyze their software and generate a comprehensive SBOM report.
Boulton’s brainchild, BlackBerry Jarvis, works by reverse-engineering existing code that OEMs are considering before they implement it. The tool, therefore, removes the danger of downloading unknown, perhaps contaminated, software into vehicles by providing a comprehensive list of ingredients, or ‘bill of materials’. Boulton imagines the situation like a restaurant asking if you have a nut allergy. Without a bill of materials, how could they know which dishes had the lethal ingredient?
“It wouldn’t matter about your response, because (without SBOM) they wouldn’t know if anything potentially dangerous was there anyway, because they didn’t know their bill of materials. That’s what it’s all come down to for software suppliers and for OEMs,” Boulton says. Yet, in a vehicle’s software, you can be faced with all different kinds of unrecognizable file types. “The big problem with automotive, and it’s somewhat of a unique challenge, is that the software supply chain is so large, complex and varied, that producing that software bill of materials, or ‘nutrition label’, upfront is never done.”
Say a vehicle under development needed a database. That database would most likely be obtained from open-source software – a program design that is publicly accessible and available for free use. “Everybody relies on open-source software,” Boulton says. A database built for a web application could have components that, though totally harmless in its original home, are dangerous in an automotive. “Most of the open-source software falls down at the ISO 26262 standard called Safety Element out of Context (SEooC) because that component was never built to be used in automotive. There’s a million things to think about when you bring these components in – Does it meet all the requirements in order to build this system? How does it perform? What testing has taken place for that? What assurances do I have about that?”
That’s where BlackBerry Jarvis comes in. “With Jarvis, we can take that component and build it ourselves to compile its contents. We then do a binary static analysis to examine, deconstruct and reverse engineer the entire module that has just been built and look at all its characteristics. We can even assess things like compiler defensive technologies and see how well they’re used, what platform it was built for and if developers used secure code practices.”
This is particularly pertinent when investigating systems’ common vulnerabilities and exposures (CVE), known vulnerabilities published online that are available to any wannabe attacker. “Once we’ve identified upfront what CVE a system has, we can add all the defenses in,” Boulton says. In a vehicle, this could mean the difference between OEMs attempting to manually compile an exhaustive bill of materials for every present mechanism – or having one presented to them.
“When you’re reverse-engineering, you need to understand that component from the automated perspective. Even a car’s braking controller and near-field sensing unit have different instruction sets. You might see a tri-core processor for a certain chip sensor but then [contrastingly] you may find Intel and arm [microprocessor architecture] on another key component of the car.”
These subtle differences could pile on countless hours to the development process. “Just testing the infotainment system means 120,000 files that you want to do a full assessment of,” Boulton says. “That’s why we get assurances on open-source software through BlackBerry Jarvis.”
