Presentation "Risk Assessment of Essential Product Requirements by Example" at the Torizon CRA Summit 2025

The most important, most time-consuming and least understood part of the EU CRA compliance is the risk assessment of the essential product requirements (Annex I, Part I). I'll walk you through a risk assessment using a driver terminal of a harvester as an example. We document the risk assessment with security decision records (SDRs) and add the SDRs verbatim to the Technical Documentation (Annex VII(3)).

1. Risk Assessment of Essential Product Requirements by Example Burkhard Stubert Chief Architect Embedded Use Mail: [email protected] Web: www.embeddeduse.com Helping embedded systems manufacturers control their own fate

2. What is at Stake? If your product violates any of these requirements after 11 December 2027 , you must not sell it and pay heavy penalties !

3. Risk Assessment of Essential Product Requirements by Example Legal Base Documentation with Security Decision Records Risk Assessment by Example Agenda

4. Article 13(1-2): Need for risk assessment Must perform risk assessment of essential product requirements (Annex I, Part I) Must keep it up-to-date during support period of product Legal Base Article 13(3-4): Need for documentation Documentation of risk assessment mandatory Risk assessment part of Technical Documentation (Annex VII(3)) Article 13(3): The cybersecurity risk assessment shall indicate whether and, if so, in what manner the security requirements set out in Part I, point (2), of Annex I are applicable to the relevant product with digital elements and how [they] are implemented […].

5. Risk Assessment of Essential Product Requirements by Example Legal Base Documentation with Security Decision Records Risk Assessment by Example Agenda

6. Security Decision Records (SDRs) Michael Nygard, Documenting Architecture Decisions Use SDRs for documenting risk assesment in Technical Documentation (Annex VII(3)) Title : One-liner with unique ID Status : One of “draft”, “proposed”, “accepted”, “superseded”, “deprecated” Date : Date of last status modification Author(s) : Name(s) of author(s) Context : User story or feature description Options : List of options to mitigate the risk from Context Evaluate risk for each option Decision : Selected Option(s) Consequences : Reasons for Decision Discussion how risk changed by Decision

7. Risk Assessment of Essential Product Requirements by Example Legal Base Documentation with Security Decision Records Risk Assessment by Example Agenda Adam Shostack’s The Four Question Framework for Threat Modeling Lean Six Sigma’s 5-Step Risk Assessment + = Pragmatic Risk Assessment for EU CRA

8. Step 1: Identifying Risks – List of user stories SDR-001: Modifying cutting length SDR-002: Viewing engine speed SDR-003: Connecting laptop directly to CAN bus SDR-004: Internet access point for other ECUs SDR-005: Updating terminal from USB drive SDR-006: Sending operational data to support portal SDR-007: Remote read and write access to ECU parameters SDR-008: Remote ssh login as root with one global password Status : Draft Date : 2025-09-25 Author : Burkhard Stubert Dig out stories from issue tracker Reverse-engineer stories from user manual Discover stories from using driver terminal Create an SDR for each user story

9. Step 1: Identifying Risks – SDR with Context SDR-008: Remote ssh login as root with one global password Status : Draft Date : 2025-09-25 Author : Burkhard Stubert Context : As a member of the support team, I want to log in as root from my office computer via ssh to the driver terminal so that I can debug problems during the harvest. The password is the same for all harvesters. Violated essential product requirements: Secure default configuration (§2b), access control (§2d), limit attack surfaces (§2j): Same root password for all harvesters. Confidentiality (§2e), Integrity (§2f): Root can extract or encrypt sensitive data . Availability (§2h), minimising negative impact (§2i): Root can shut down terminal and connected ECUs . Mitigating incidents (§2k), recording & monitoring (§2l): Terminal has no way to detect, mitigate or record incidents . Q2: What can go wrong?  Which requirements can the story violate? Q1: What are we working on?

10. Step 1: Identifying Risks – Data Flow in Ecosystem Use for description of system architecture (Annex VII(2a)) Extract data flow from user stories and vice versa

11. Step 2: Evaluating Risks – Do-Nothing Option SDR-008: Remote ssh login as root with one global password Options : Option 0: Doing nothing Risk: ??? (damage: ???, likelihood: ???) Once attackers have the root password and IP address, they can run ransomware and DoS attacks on all harvesters from remote. If the damage per harvester was €2,000 with 5,000 harvesters affected, the total damage would amount to 10 million Euro. Modest estimate without CRA penalties and reputational damage. Attackers could figure out the global password through a brute-force attack on one harvester or through social engineering. The badly protected support portal is the easiest way to get hold of the IP address. Likelihood Damage

12. Step 2: Evaluating Risks – Do-Nothing Option (2) SDR-008: Remote ssh login as root with one global password Options : Option 0: Doing nothing Risk: high – 15 (damage: catastrophic – 5, likelihood: possible – 3) Risk

13. Step 2: Evaluating Risks – Result for All SDRs

14. Step 3: Prioritising Risks Risk >= 8: mitigation needed; reduce or avoid Risk < 8: n o mitigation needed; accept Mitigation

15. Step 4: Mitigating Risks – Generate Mitigation Options SDR-008: Remote ssh login as root with one global password Options : Option 0: Doing nothing Risk: high – 15 (damage: catastrophic – 5, likelihood: possible – 3) Option 1: Close ssh port Risk: ??? (damage: ???, likelihood: ???) Option 2: Non-root ssh login with different passwords for each harvester Risk: ??? (damage: ???, likelihood: ???) Option 3: Driver enables ssh server on demand Risk: ??? (damage: ???, likelihood: ???) For each SDR: Generate mitigation options how to fix violations

16. Step 4: Mitigating Risks – Evaluate Risk for Option 3 SDR-008: Remote ssh login as root with one global password Options : Option 3: Driver enables ssh server on demand Risk: low – 4 (damage: minor – 2, likelihood: unlikely – 2) By default, the ssh server is not running. The driver authenticates herself with a key card to start a time-boxed support session. The terminal starts the ssh server. Support staff can log in via ssh with a one-time password. They have less privileges than root. The terminal records remote and local authentications. The damage is limited to one harvester. An attack requires one bad guy to be present on the harvester and to have a valid key card. Passwords are never stored. Best Practice : Enable security-critical features on demand only for limited time For each option: Q3: What are we going to do about the violations? Avoid, reduce, accept risk Describe security measures Re-evaluate risk

17. Step 4: Mitigating Risks – Evaluate Risk for Options SDR-008: Remote ssh login as root with one global password Options : Option 0: Doing nothing Risk: high – 15 (damage: catastrophic – 5, likelihood: possible – 3) Option 1: Close ssh port Risk: none – 0 (damage: none – 0, likelihood: none – 0) Avoid the risk. Option 2: Non-root ssh login with different passwords for each harvester Risk: medium – 9 (damage: moderate – 3, likelihood: possible – 3) Reduce the risk. Option 3: Driver enables ssh server on demand Risk: low – 4 (damage: minor – 2, likelihood: unlikely – 2) Reduce the risk It’s decision time!

18. Step 4: Mitigating Risks - Decision SDR-008: Remote ssh login as root with one global password Status : Proposed Date : 2025-10-01 Decision : We select “Option 3: Driver enables ssh server on demand”. Risk: low – 4 (damage: minor – 2, likelihood: unlikely – 2) One or more options can be selected

19. Step 4: Mitigating Risks - Consequences SDR-008: Remote ssh login as root with one global password Consequences : We would have preferred Option 1, but we cannot provide proper support at the moment without ssh login. Hence, we take the second best option 3. Option 1 remains our goal. Changes for violated essential product requirements: Secure default configuration (§2b), access control (§2d), limit attack surfaces (§2j): Better Confidentiality (§2e), Integrity (§2f): Better Availability (§2h): Same Minimising negative impact (§2i): Better Mitigating incidents (§2k), recording & monitoring (§2l): Better Risk of violations should not get worse.

20. Step 4: Mitigating Risks – Result for All SDRs Feed SDRs into Sprint planning and implement them – in order of orginal risk Risk assessment and its implementation must be done by 11 December 2027. If not, products must not be sold in EU – plus heavy penalties! It’s a gargantuan task! Start Now!

21. Continuously update risk assessment For each new story, evaluate and mitigate risks (Steps 2 and 4) Run (automated) regression tests regularly Detect increased risks early Step 5: Continuously Reviewing Risks Requirement ”Regular Testing” (Annex I, Part II(3))

22. Interaction with Torizon Vulnerability Manager Toradex Developer Community, Torizon Vulnerability Manager Overview SBoM with all vulnerabilities from all components in Torizon build Torizon security team Torizon Cloud scan Vulnerabitilies that don’t affect users with absolute certainty (30-50% of original vuln’s) Manufacturer Vulnerabilites marked as “mitigation available”, if they are unlikely to affect users Torizon security team Risk assessment

23. Q&A Presenter’s Company Logo

24. THANK YOU FOR YOUR INTEREST www. torizon .io www .toradex .com developer .toradex.com community .toradex.com