(Story continued from previous post Justin, the OEM and the cybersecurity requirements)
Justin is wondering how to deal with the cybersecurity requirements that he has received from the OEM. He calls Alex, an automotive Security Specialist working at Riscure.
When Alex got the call from Justin, Justin’s first question was “What does it mean that ‘The ECU debug system should be disabled in the production units’, how do I disable it? Do I set the microcontroller lock fuses? Or is it enough to remove the ECU debug header?”
Justin did the right thing asking for help on how to meet such a requirement, because the answer is not necessarily straightforward. When discussing and implementing security requirements, one of the prerequisites is to have a common understanding of the considered cybersecurity context. In Justin’s case, Chris, the requirements engineer from the OEM, explicitly said that the debug system should not be available to any user in production. However, the technical solutions available to implement this requirement depend on the attacker potential such as tooling, expertise, time, physical access, and so on. Justin and Chris did not align on the security context (formally known as the Threat Model), but I needed it in order to be able to address his initial question.
I proposed to Justin to revisit the process that Chris used to come up with cybersecurity requirements. This process is sometimes referred to as TARA (Threat Analysis and Risk Assessment), as defined by the SAE J3061 standard.
Would you like to know more about how this process works? Let’s have a look together:
Step 0 – Threat model:
The system concept designer needs to describe the cybersecurity activities and properties needed for the ECU, and summarize them in a cybersecurity concept. To achieve this, you will need to first describe what the relevant assets in the system are, and which attackers are considered (in terms of attacker capabilities, tooling, time, access to information, etc.). These details are the foundation to discuss what is required in the system, and should be summarized in a document called Threat Model. A good Threat Model will enable an efficient and effective TARA process.
Step 1 – Threat Analysis:
Given a Threat Model, you can assess what could the considered attackers do to the assets (according to their attack potential). Such a threat analysis will give you guidance on what the risks in your system are, as well as a ranking for the protection level that is required for each component.
There are several methodologies to perform a TARA assessment; you can check out our recorded webinar about TARA methodologies here. An example approach (popular in the US) is MITRE TARA. The first step (Cyber Threat Susceptibility Analysis, CTSA) finds and analyzes threats for the assets using a tool called “Attack trees”, and summarizes all the relevant attacks in a ranked list, called Threat Matrix.
Figure 1 – Example Attack tree
Step 2 – Risk assessment:
After obtaining a ranked list of possible threats to assets, during the risk assessment step you would identify which threats need attention based on the threat model. In addition, you typically would propose mitigations to reduce (or eliminate when possible) the risk posed by the relevant threats.
If you use the MITRE TARA approach, this step is called Cyber Risk Remediation Analysis (CRRA). In this activity, you would look at countermeasures available for mitigating the identified threats, and propose the best combination of them: maximize the utility of them, while minimizing the cost.
After I explained how a TARA process works, Justin realized he probably did not understand the requirement because he and Chris did not agree on the considered threat model. He wrote on his agenda “action point: contact Chris – discuss threat model”. He had a further question: “I understand this process, but I see a gap between these recommendations and the “shall/must”-like phrasing of requirements that we typically get. How do they do it?”
The list of mitigation recommendations from a TARA process can be mapped to security requirements in your system. Collecting all these security requirements for your security goals will conform your security concept. However, how do you translate mitigation recommendations into precise security requirements?
Do you want to hear more about Justin’s adventures in understanding security requirements? In the next blogpost we will see the pitfalls of performing a TARA and see how can you perform the final step of getting a security concept: from TARA recommendations to security requirements.
Would you like to receive updates about new blogposts? Then feel free to sign up by entering your e-mail in the form below. We will notify you once a month about new blog posts and articles from Riscure Security Training. If you would like to start embedding security requirements in your automotive development today, check out this online course.