ISO/SAE 21434 The Guide For Cyber Physical Systems: Cybersecurity Planning, Threat Assessment and Risk Analysis (TARA)

Concept Phase.

The Internet of Things, sounds simple enough right? What about when we integrate embedded devices into the IoT. If not already, in the near future, homes, sidewalks, vehicles, and just about anything else you may be able to think of will be connected with IoT and have an embedded device. With embedded devices being integrated into our daily lives, a major concern will lie in securing those same devices particularly in industries where lives are on the line.

For example, think about the medical device or automotive sectors. Securing embedded devices should start at the development phase and continue onwards after the product is released. With technology being integrated into our daily lives the threat remains imminent and over time the targeted breaches will become much more automated as well as easier to conduct. Loss of life can be avoided by partaking in a proactive lens when it comes to securing cyber physical systems.

Previously, we discussed the phases of J3061, the Concept Phase being a vital part of the equation. The phase starts with a Threat Assessment and Risk Analysis (TARA), the deliverable from a TARA enables you to prioritize threats and mitigation strategies in parallel. Some prerequisites of a TARA is to develop a plan and define features of your system.

Feature Definition

In accordance with J3061, a feature is defined as the system being developed to which the process will be applied to. J3061 goes on to identify the physical boundaries, perimeter, and trust boundaries to encapsulate a holistic perimeter of the feature.

Cybersecurity Planning

When putting together a Cybersecurity plan, keep in mind that this will be the guiding light for any initiative within a project. Future project plans should require a Cybersecurity plan moving forward.

An analysis of each asset and feature of a system must be categorized depending on the particular stage an asset is at during feature development. In order to categorize or break down the features please refer to the CIA(Confidentiality, Integrity, & Availability) model.

Asset identification might even require attack scenarios to be outlined in the TARA. For example, let’s take a look at what that would look like for a connected vehicle. The asset /feature would refer to the vehicle’s camera-base side-view mirrors, this would then connect to an insurance provider’s cloud architecture utilized to monitor accident prevention metrics. The attack scenario could like look a spotty connection interfering with communication between the vehicle, the mirrors, or the cloud architecture. This spotty connection reflects the availability (A in the CIA Model) of this feature.

Once features are categorized, the next step is to break down the categories into smaller-incremental cybersecurity initiatives. An initiatives will drive your cybersecurity plan and used in coordination for a project plan (a good example of this would be a SDLC, software development life cycle). The progression of your project plan will be dependent on the outcome of your initiatives from your cybersecurity plan.

J3061 provides vague guidelines on specifics of forming a cybersecurity plan but it does suggest to use spreadsheets to organize initiatives. To expand further on this, the early draft of ISO/SAE 21434 list the following overarching initiatives:

Define the goal for the initiative
What information and environment does your initiative depend on?
Who is responsible for executing this initiative?
What are the resources required for the initiative (compliance, man hours, etc.)?
Establishing the beginning, middle, end, duration and gate reviews/milestones for the initiative

A cybersecurity plan will dictate what your features and assets are. It will also outline how the features can effect other assets within the system, how many resources will be required to effectively apply the cybersecurity plan, and who will be responsible for executing the cybersecurity plans.

Threat Analysis and Risk Assessment (TARA).

The objective of conducting a TARA is self-explanatory, it aims to break down your system into threats and assessing the risks from the threats discovered. Conducting a TARA is a crucial step after asset identification. Afterwards, begin funneling your selected assets and features down a TARA pipeline in order to generate risk documentation of each asset. As you can imagine corporations will have thousands of assets each with their own TARA, maintaining such documentation in a secure way is a topic for another time. Upon completion, three phases will follow.

1. Establishing cybersecurity goals

2. Developing strategies within the cybersecurity concept to tackle goals

3. Establishing what functional cybersecurity requirements will need to comply with your concept

A TARA will help drive all reasoning for cybersecurity initiatives within the organization. Threat Analysis starts from the inception of the cybersecurity plan. Organizations will need to draw inspiration from the cybersecurity plan in order to produce a document yielding a list of threats associated to features and assets identified throughout the process. This information will then be utilized for threat analysis.

Risk Assessment

The goal of a risk assessment is to determine the likelihood of potential scenarios from the threat analysis model. The attack potential of a feature is determined and risk reduction measures are implemented to reduce risk to an acceptable level.

Methods

These methods will provide a high-level overview of possible risk assessments an organization can utilize. J3061 calls out risk assessment methods to use but organizations may even come up with their own derivative of a risk assessment to better suite their needs. The methods below should provide a baseline for your risk assessment endeavors.

EVITA Method

Also known as E-Safety Vehicle Intrusion Protected Applications (EVITA), it is one of the most common risk assessments used in automotive for assessing in-vehicle systems. This method aims to take a holistic approach to analyzing hardware and software. The goal for a EVITA is for designing security into on-board vehicle architecture. It ensures that proper security controls are implemented to uphold Confidentiality, Integrity, and Availability by referencing all features of the system to the CIA model.

EVITA Using THROP

Since J3061 adopted it’s approach from ISO 26262, this version of EVITA is based on using hazard metrics. Threats using Threat and Operability Analysis (THROP) will take a functionality-first approach in determining potential threats. According to J3061, THROP sets out to:

Identify the primary functions of the feature
Apply guide words to the functions to identify potential threats
Determine potential worst-case scenario outcomes from potential malicious behavior

TVRA

Threats, Vulnerabilities, and Risk Analysis. Assets are first identified in your system (see Asset Identification), their threats and risk are modeled around likelihood and impact. The following are steps outlined in TVRA according to J3061:

Identify target system assets, goal, purpose, and scope (Feature definition)
Identify objectives and cybersecurity issues to resolve
Identify requirements
Classify and categorize assets and add specific descriptions to assets and features from step 1
Identify threats, attack vectors and consequences of exploitation
Determine occurrence, likelihood, and impact
Determine risks
Identify controls to reduce risk
Perform cost-benefit analysis to identify controls
Detail requirements for implementing services and capabilitiesA

OCTAVE

Operationally Critical Threat, Asset, and Vulnerability Evaluation used for enterprise security risk assessments. This approach will use workshops and informational training to have a centralized understanding of enterprise risk.

Risk Analysis

At this stage the threats outlined in your threat analysis are ranked from highest risk threat to lowest risk threats. The STRIDE approach is used to identify the threats from your asset categorization.

The STRIDE approach categorizes your asset based on security attributes from CIA, and possible threats such as tampering and exposed data. For example, a software on an infotainment unit (asset) stores log data about driver behavior. The log data uses weak encryption, a potential threat given this asset is sensitive data exposure, the security attribute this pertains to is confidentiality because data that is meant to be encrypted at storage or in-transit is at risk of being exposed to an unrelated party.

HEAVENS

A systematic approach for cybersecurity requirements for vehicle E/E systems. Consisting of four modules, target of evaluation, threat analysis, risk assessment, and identifying security requirements.

For supporting documentation and our Threat Assessment and Risk Analysis templates subscribe to our J3061 Series below.

Up Next.

Next, we will dive in to establishing processes to tackle high risk threats from your Threat Assessment and Risk Analysis endeavors. The next steps are to identify and state your cybersecurity goals, deriving a concept from your goals and developing a functional requirements document.