Cybersecurity meets automotive business

Click for: original source

The automotive industry is well known for its security standards regarding the road safety of vehicles. All processes regarding vehicle development – from drawing board to sales – were standardized and refined over the years. Both internal tests, as well as globally renowned companies like NHTSA or EuroNCAP, are working hard on making the vehicle safe in all road conditions – for both passengers and other participants of road traffic. By Adam Kozłowski and by Marcin Wiśniewski.

Safety engineering is currently an important part of automotive engineering and safety standards, for example, ISO 26262 and IEC 61508. Techniques regarding safety assessment, like FTA (Fault Tree Analysis), or FMEA (Failure Mode and Effects Analysis) are also standardized and integrated into the vehicle development lifecycle.

But the security is not limited to crash tests and driver safety. In parallel to the new ADAS systems, the connected car concept, remote access, and in general, vehicle connectivity moved forward. Secure access to the car does not only mean car keys but also network access and defense against cybersecurity threats.

And the threat is real. 6 years ago, in 2015, two security researchers hacked Jeep Cherokee driving 70mph on a highway by effectively disabling its breaks, changing the climate control and the infotainment screen display. The zero-day exploit allowing that is now fixed, but the situation immediately caught the public eye and changed the OEMs mindset from “minor, unrealistic possibility” to “very important topic”.

All of these resulted in the definition of the new standard called ISO 21434 Road vehicles — cybersecurity engineering. The work started last year, but currently, it’s at the “Approval” phase, so we can quickly go through the most important topics it tackles.

The document also lists the best practices regarding cybersecurity design:

  • Principle of least privilege
  • Authentication and authorization
  • Audit
  • E2E security
  • Architectural Trust Levels
  • Segregation of interfaces
  • Protection of Maintainability during service
  • Testability during development (test interface) and operations10
  • Security by default

The requirements do not end on the architectural and design level. They can go as low as the hardware (identification of security-related elements, documentation, and verification for being safe, as they are potential entry points for hackers), and source code, where specific principles are also listed. Nice one!

[Read More]

Tags miscellaneous infosec robotics