ISO/SAE 21434 The Guide For Cyber Physical Systems: Introduction

In the following decade, billions of internet connected devices are coming online. Currently we’re seeing many seep into our households: smart speakers, thermostats, and fridges to name a few. In mobility, autonomous fleets and vehicles are being simulated and driven all over the US. While innovation in these technologies are exciting, vulnerabilities will always follow. This blog series will focus on breaking down the J3061 document to help suppliers and OEMs understand what is expected for cyberphysical security in the coming years.

The goal of J3061 is to aid engineers, developers, and managers utilize a framework for integrating cybersecurity with cyberphysical systems. It’s viewed as a “Lifecycle process framework that can be tailored for any organization through concept – production- operation – service – decommissioning.”

What J3061 provided was The Cybersecurity Guidebook for Cyber-Physical Vehicle Systems. The evolution of this guidebook is translated to ISO Compliance 21434 which will come out later in 2020. While J3061 is a digestible first step, how does an automotive supplier or OEM approach an initiative as large as this? What are the requirements and deliverables? While J3061 provides a high-level overview, ISO 21434 will provide actionable steps/requirements for compliance, processes to management of cybersecurity processes, and a global specification everyone will abide by. Til then, our series in Breaking Down The Guide For Cyber Physical Systems With ISO/SAE 21434 will fill this void of uncertainty. By the end of the series, expect to have a grasp on what it takes to implement J3061 for ISO 21434 compliancy. We’ll provide examples, frameworks, and processes that can be actualized as a business.

As of writing, ISO 21434 has not been released in the public, it’s currently in the stages of drafting.

The Motivation.

It any enterprise landscape, it’s common to see a bolt-on approach to cybersecurity. J3061 and SAE/ISO 21434 is reframing the argument by incorporating cybersecurity processes throughout the entire lifecycle instead of a reactive, bolt-on approach. It requires processes, management of security, and culture to sustain it. It develops a stable foundation so products cannot be tampered with or manipulated in any way that strays from it’s original purpose.

The issue we see time and time again is that technology and innovation move at such a rate that the security posture of a product or infrastructure will start to crumble due to it’s implementation (cybersecurity at the end approach). By using J3061 as a guide for cyberphysical security, products will be created on a foundation that is much more resilient to change and the dynamics of technology.

The area of mobility in particular, is a focal point to implement J3061 due to the idea that a breach or hack on mobility will steal much more than data, where the physical and cyber worlds start converging to cause physical harm and damage. The Automotive Industry in of itself has spent years developing a similar framework for properly testing it systems, Safety.

Safety vs. Cybersecurity.

As previously stated, cybersecurity is starting to converge on the physical realm. J3061 takes a page out of ISO 26262 to guide efforts for cyberphysical safety. To learn more about the core of J3061, take a look at ISO 26262.

Safety critical systems are defined as systems that may cause harm to life or property. While cybersecurity critical systems lead to losses such as financial, operational, and privacy. What J3061 is communicating is that safety and cybersecurity can be approached similarly and the processes that are developed should be held to the same degree as well.

Once a system is properly assessed (Using a TARA), a model of the overarching goals and preventative measures are created. From this, a matrix of mitigation strategies are developed and executed on. Even though these compliances have similar goals, the results that each produce are much different.

The key takeaway is that an assessment initializes the process, from there, cybersecurity can be tied in systematically along the product lifecycle.

Getting Started With J3061.

The first step in developing a “J3061 approach” is understanding the potential of your system. Conceptualize the attack scenarios and attack surfaces that come with the features and how they will evolve over time. The best way to orchestrate this is to organize a high-level meeting between the parties involved, this is the precursor to developing the Cybersecurity Process.

Cybersecurity Process

A key step in building your Cybersecurity framework, you need to fully understand your system, doing so will develop effective cybersecurity strategies to properly handle potential risks. Communcation between safety and cybersecurity parties should be consistent to ensure all potential risks are assessed. Questions to ask your teams in determining cybersecurity related risks:

What data is exposed in parts of the vehicle? What type of PII, PHI, or sensitive information is it?
How is this data stored?
How is this data exposed and written?
Who are the players of your system and how do they interact with it?
What are safety-critical functions of this device and how does it interact with other systems?
If breached, what mechanisms of safety and cybersecurity will it expose?
How does your system communicate to all other parts of the system?
When breached, how far can someone pivot in your system?

Implementing checkpoints (gate reviews) are another vital step in developing cybersecurity processes, what are the checkpoints in the product lifecycle where cybersecurity and safety teams communicate? Establishing these gate reviews will enable the two parties to exchange information on potential risks. The key is enabling the cybersecurity team to have an over-encompassing view of the product lifecycle while improving cybersecurity knowledge in parallel. Having this ability allows them to draft and improve their threat models and security processes indefinitely.

Concept Phase

One of the most important phases in the lifecycle as it lays a foundation and direction for the following phases. This phase should result with a Threat Assessment and Risk Analysis (TARA), generation of a cybersecurity model, and cybersecurity goals which all come together to form your cybersecurity concept.

Product Development Phase

The encapsulation of software, hardware, and system development. This phase covers planning, specification, and design when the product will be assessed, tested, validated and released. It is a collaboration between system engineers and cybersecurity professionals to ensure that the right security controls are being developed and baked in.

Gate Reviews

Gate reviews are checkpoints in the product lifecycle. They are witnessed after a certain milestone is crossed, such as the finishing of a concept phase. The goal is to ensure that the requirements are being upheld throughout the entire process. A gate review team should be delegated and organized by the project lead. When closing a gate review, there are two approaches used in the guide.

First Approach

The ‘gate’ approach where the review is similar to waterfall in SDLC. It requires a passed review to go to the next phase. Some advantages of this approach is that it allows teams to locate inconsistencies and issues holistically after all the reviews are done. Disadvantages are that since the reviews are done in the end of a development cycle, small nuances in design and implementation can be easily forgotten and ignored.

Second Approach

The agile approach is when there is a gate review after each sub-phase of the development life-cycle.

Advantages of this approach is that discrepancies and issues can be caught earlier in the cycle, and the overall logistics of the review will take less energy and time. Disadvantages are that the reviews may not be consistent, due to the fact that there are so many reviews initiated. A simple fix is to cross reference each sub-review with previous reviews to ensure its consistency.

There are disadvantages and advantages to both approaches, and it depends on what works best for your teams. A good approach is to start with the agile approach for non security-savvy teams and as the experience builds, move towards the first approach.

Up Next.

Deep dive into the cybersecurity processes and breaking down the concept phase.