Repository navigation
Cybersecurity and ISO 21434
ISO 26262 asks what happens when something breaks, and SOTIF what happens when nothing breaks but the function still
gets it wrong. ISO/SAE 21434 asks the third question: what if someone attacks it? This page explains the standard
from the start for someone who has never used it, follows one real LionDriver threat through it, and shows where it
meets safety. It explains and links. The analysis is the TARA
(WP-C-09), the goals and concept
(WP-C-10), the safety–security interactions
(hatara/) and the cybersecurity case
(WP-K-03); nothing here is analysis content. No figure
shows how to carry out an attack.
Every figure is drawn at each wiki sync by tools/wiki/cyber_animations.py. The
risk map, the attack-path factors and the counts are read from the records, and every other ID, rating and status is
checked against the record it comes from. When a record changes, the build fails instead of showing old text.
Security differs from the other two in one way that shapes everything else: an attacker is not random. A broken part fails by chance; an attacker picks the worst moment and can repeat it on every car. So ISO/SAE 21434 does not count failure rates. It asks how bad the damage would be and how hard the attack is.
A threat analysis and risk assessment (TARA) works through the same questions for every asset: what we protect, what harm follows if it is broken, who could do what, how, how hard that is, how risky it is, and what we do about it. The answer to the last question is a cybersecurity goal, and its CAL (cybersecurity assurance level, 1 to 4) sets how much rigour its development gets.
Each damage scenario is rated in four categories, and its impact level is the worst of the four. Safety damage is taken from the hazard analysis (WP-C-03), so the TARA and the HARA share one hazard log. Privacy damage has no hazard at all, and ISO 26262 never sees it.
Feasibility comes from the attacker's side: time, expertise, knowledge of the item, window of opportunity and equipment. LionDriver is open source, so knowledge of the item is public for every path. A control is credited only once it is verified and the path is re-rated with it in place.
Risk is impact against feasibility, from 1 to 5. A risk of 3 or more must be treated: reduced with a control, avoided by removing the feature, shared, or retained with a reason. A risk of 4 or 5 drives a cybersecurity goal (WP-C-10).
A goal becomes requirements, the requirements become a control, and tests and a penetration test show the control holds. The results support a claim of the cybersecurity case (WP-K-03). The same lock is a safety requirement too, as on SOTIF and ISO 26262, where the torque cap serves two standards.
A measure on one side can help the other, hurt it, or be what the other rests on. LionDriver records each of these
interactions in hatara/, where a tool checks them against the HARA and
the TARA.
New attacks appear after release, so the project watches for them, handles reports and ships fixes as updates (WP-O-05). The report in the figure is an example. How to report a vulnerability is in SECURITY.md; what keeps the item safe after release in general is on After release.
- Standards at a glance: how the standards divide the work.
- What is a safety case?: the cybersecurity case is built the same way.
- Reporting a safety concern.
- Glossary for the work product and ID codes.