Joint standardization effort by two organisations, published final version in 2021. Motivation: vehicles offer more connectivity features, this increses cybersecurity risks. Safety engineering methods are now industry standards, there is a need for a similar in cybersecurity. Achieving a system that is cybersecure by design, requires an appropriate lifecycle process analogous to the framework in ISO 26262.
In the standard neither the specifics of cybersecurity technologies, nor solutions and remediation methods are given.
In an ideal world of engineers, we would be always building systems that meet measurable and testable set of criteria. We set up a list of requirements, that will guarantee that the end product aligns with the intended design and functionality. Requirements are by definition verifiable.
Cybersecurity is about protecting digital assets from being compromised. To achieve this goal we can try to define requirements but the problem with security requirements is that everything can be exposed given sufficient resources (time, money, expertise). This means security requirements cannot always be verified. Every cyber system inherently carries a risk of its assets being compromised.
We need to accept a certain risk tolerance, or upper risk limit, established by the organization. The goal of risk assessment is to identify what needs to be done. What security measures needs to be taken in order to mitigate risks and achieve a tolerated level.
A security measure reduces exposure, exploiatability or impact of security risks.
How to identify risks? We cannot mitigate all risks, we need to find a way to compare them.
Risk level = likelihood x impact (damage potential)
How many risk levels (categories) do we need? Depends of how we deal with risks, who should be responsible for what: eg. major risks must be considered by top management, minor can be treated optionally by product owner.
We perform a procedure that organises risks, and identifies what should be done about them. The output of this process is the threat and risk list.
Threat and risk list = threat catalogoue + impact + mitigation
The purpose of a threat and risk list is to:
Where to start? A risk is a product of likelihood and impact. What connects a potential attack and the impact? The asset that needs to be protected.
System modeling
The workflow described below is inspired by MoRA (Modular Risk Assessment).
Standards require secure by design approach. Before building anything, we need to identify system scope: what belongs to this system, where are the boundaries. We can work with simple component diagrams, describing data flow is also useful. ISO21434 calls this part the Item Definition.
System components can be:
We need a list of assets that needs protection. With the help of the system model, we associate assets with system components. Potentially multiple components can access the same asset and we can say that a system component is an asset in itself. But what is an asset? Asset is something that a potential attack can target to violate its protection goals.
Use the CIA triad to discover potential violations for each asset:
Some example on assets:
Estimating impact
With the list of assets in place, we can now start listing violation scenarios. Estimate the potential impact of violation for each protection goal. We need another categorisation here, consider 3-4 levels: negligable, moderate, critical, disastrous.
Organise impact categorise and try to describe each impact level, example:
Now fill in the impact matrix: assign an impact level to each violation.
Estimating likelihood
Likelihood = exposure x explotability
How to compose risk level and likelihood matrix? How many risk levels do we need? Depends on how we should deal with risks (risk treatment): define who is responsible for what. How many exposure levels? Depends on system architecture, consider level of access needed, risk of getting caught.
Build a threat catalogue.
Build a threat and risk list
Combine the threat catalogue with impact matrix.
List element includes:
Process summary
tooling:
concept:
my comment: