In this webinar, “Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System”, learn about the implementation of the Threat and Risk Analysis (TARA), the centerpiece of the new Automotive Cybersecurity standard ISO 21434.
Many companies currently use spreadsheets to develop TARAs, which can be challenging when managing large sets of requirements across distributed teams and car line variants. In this webinar, we’ll examine why a requirement management system (RMS) is well-suited to manage the TARA work product and can make a significant impact on managing this data across teams, supporting compliance audits, and assessments.
Attendees will gain insights into TARA’s complexities and how the right tooling solution can make a difference in managing this data across teams, supporting compliance audits and assessments.
- The Threat and Risk Analysis or TARA is the centerpiece of the ISO 21434 Automotive Cybersecurity standard
- Overview of TARA
- ISO 21434 compliance requirements when implementing TARAs
- Why an RMS is well-suited to manage TARAs
Below is an abbreviated transcript and a recording of our webinar.
Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System
Kevin Dibble: Thanks, Juliet. Okay. I’m going to just go through the agenda and then get right into 21434. I’ll start with a high-level introduction and then get into the focus of our topic today, which is the threat and risk analysis, which is a centerpiece of 21434, also known as the TARA. And then make an argument for the management of a TARA using an RMS or a requirement management tool. And then Steve will take over and talk about what that would look like in Jama software and summarize with some key points of managing TARAs in Jama versus some traditional methods. And then we’ll have time for some questions.
So with that, again, this is going to be a very high-level overview of 21434. I have a feeling that some of you have worked in cybersecurity for some time, others are just brand new to the term. And so, I want to touch on this as a basis for the rest of the discussion.
And so, first, what is 21434? It is the automotive industry standard for developing cyber secure systems. After several years of review, it was approved in August of 2021 as the method for developing cyber secure systems. In terms of the standard itself, it’s structured and uses a lot of the same terminology as the functional safety standard called ISO 26262. So if you’re familiar with functional safety, then this standard will make a lot of sense the way that it’s organized. Some of the terms such as an item definition, a concept phase, a cybersecurity goal, even TARA parallels functional safety terms like functional safety concept, functional safety goals, or the HARA, Hazard and Risk Analysis. And so, that’s just a reference point as you’re learning about this new standard. Now as far as its scope, it covers or it applies to passenger vehicles and cargo vehicles.
So just a little bit different than ISO 262 there, passengers would include buses, commercial or non-commercial. I think even tripods and some of those other types of motorcycle hybrid type of devices are in or vehicles are in scope as well. It applies to series production and it uses a lifecycle that starts at the request for a quotation for an item. And I’ll define that in a little bit and goes all the way through to the end of cybersecurity support. So like functional safety, we’re not talking about supporting the risks and the hazards associated in this case with threats from attackers leading up to SOP, but it extends far past that. In fact, in 21434, instead of using the term SOP or start of production, which is a critical milestone in any automotive product development program, they call that milestone the release to post-development.
RELATED: Functional Safety (FuSA) Explained: The Vital Role of Standards and Compliance in Ensuring Critical Systems’ Safety
Dibble: And I want to camp on that for just a second because it raises a really important point and it’s very relevant to what we’re going to talk about regarding the TARA. Release to post-development. So the automotive industry is under a lot of change and OEMs want to be or are becoming mobility providers and services will be sold after the car is released. And some of those services weren’t even imagined at the time the car was sold. That’s so different than where the automotive industry was even five years ago. And this standard recognizes that and embraces it along with another important concept, which is that the world of cybersecurity and the landscape for threats and the technologies and the tools that are used to attack vehicles is constantly changing. And so, at the release to production, what is assumed to be protected in terms of say a set of cryptographic keys or a communication bus might be more vulnerable in five years than it was when the car was released because of new techniques, new methods, new tricks, new hacks, and other things that have been discovered.
And so, that’s an important concept because it feeds to our idea that we’re going to get into about the TARA as a living document, as a living asset that begins all the way at the concept phase at the beginning of the high-level architectures of the item or the system in the car. And extends all the way until the end of life for cybersecurity support, which is 10, 15 years down the road. Now, the 21434 has both requirements for developing cyber secure systems, is kind of what I’m showing you on the right, but it also has process requirements. And to that end, there is an audit of the process and an assessment of the results of your project according to 21434. That assessment piece is important for our discussion because when we think about the TARA and the pieces of it or the items of the TARA, then we have to think in terms of what are the evidences we need to leave behind and produce in order to pass an assessment, very important consideration.
Dibble: And so, we have audits for the processes and then assessments for the end result. So that’s very brief overview of 21434. I want to make sure I leave you with the… If you remember anything about 21434 besides the TARA, you’ll hopefully remember this, is to manage unreasonable risk of damage to road users due to a malicious attack to a vehicle or a vehicle data, confidentiality, integrity and availability. Let me unpack that for just a second. Unreasonable risk, this is when you get into a car, when you operate a vehicle, you assume some risk. But that risk doesn’t include driving down the highway at 70 miles an hour, turning right and the car going left or the headlights going off while you’re on the highway at night. It applies to road users. That’s the people that use the road, the driver, the passengers, and the people surrounding it.
All of that is our scope for how we’re going to define threats according to 262 and then mitigate them against malicious attack due to… That’s the cyber aspect of this. And then what’s being attacked and what are we protecting? We’re protecting vehicle systems, functions, data, et cetera. We call them assets according to their properties, confidentiality, integrity and availability. There could be more properties, that’s the CIA that we’re protecting. Why is cyber such a hot topic? Well, I would say there’s several reasons, but here’s two of the big ones. On the left of my slide, the advent of the connected car coupled with the automated driving functions. I’m not going to read through all the stats here, but the connected car is here. It’s 2 billion in terms of the market in 2021 to grow to $5.3 billion in 2026. And the connected car is accessible via the internet, accessible via Bluetooth and other network interfaces, which all result in attack services. It also has a lot more software.