Automotive Cybersecurity Documentation

Vehicular connectivity, software defined vehicles, self-driving cars. These mega trends increase the importance of software in cars more and more. On the other hand, vehicles become a more vulnerable and valuable target for malicious actors. Threats range from activating subscription-based features without paying to controlling safety critical functions such as steering or braking. Together these lead to challenges in the field of automotive cybersecurity.

The key to solving these challenges is to identify risks posed by malicious actors and afterwards mitigate these risks. Regulations such as the UN R 155 recognize the importance of this and require evidence of a car’s cybersecurity before national authorities can grant a type approval (for new vehicle types starting from July 2022, for any other vehicle starting from July 2024). Proper cybersecurity documentation plays a key role in providing the necessary evidence for UN R 155’s type approval.

Threat Analysis and Risk Assessment

A well-structured automotive cybersecurity documentation assists the development of the system in various ways:

• Providing a common understanding for the development team,
• Drawing a clear picture of the risks the system might face during operation,
• Demonstrating how these risks are mitigated.

Finally, documentation is equally crucial in providing evidence of cybersecurity to an auditor, a national authority or other stakeholders.

As a starting point the system’s intended use and its provided functions are described to define the system’s scope. Additionally, the documentation gives an overview of the system’s context. The context describes the operating environment and the interfaces between the system and its environment. After the system’s scope and context has been established the starting point of all cybersecurity activities is documented: the Threat Analysis and Risk Assessment (TARA). It contains the identified risks for the system and answers the questions:

• What are the assets we need to protect?
• How could a threat actor damage these assets?
• In what manner could the damage be realized by an attacker?

Based on the answer to these questions the risks are rated according their damage potential and their attack feasibility. This can be achieved by applying a risk rating method such as the Common Vulnerability Scoring System (CVSS) or ISO 21434’s impact and feasibility rating. The identified risks need to be mitigated to achieve the cybersecurity goals. These goals describe high level requirements which need to be fulfilled for a secure car. They are explicitly stated within the security documentation and trace back to risks threatening them.

Cybersecurity Controls

After completing the TARA, cybersecurity controls need to be designed and implemented. Requirements are derived from the cybersecurity goals and describe the problem space. Based on these requirements architects and engineers select appropriate cybersecurity controls to fulfill the cybersecurity requirements. This includes communication patterns and technologies, the update strategy and trusted execution platforms. A well-written cybersecurity documentation provides a rationale how cybersecurity controls address an identified risk. This rationale demonstrates why the mitigation is appropriate and how its effectivity is validated. ISO 21434 explicitly requires this argumentation to be documented during the system’s design. Ideally each cybersecurity rationale traces bidirectionally to the risks it addresses and a verification and validation measure that provides confidence in the correct implementation of the control.

Software Bill of Materials

Another key component for secure system development and achieving automotive cybersecurity is the Software Bill of Materials (SBOM). The SBOM contains a list of the system’s software configuration. What software and which libraries are used in the system? What version of a library is used for a specific system version? Based on this information a vulnerability scanner can check for known weaknesses or vulnerabilities, for example by cross-referencing the SBOM with Mitre’s Common Vulnerability and Exposures (CVE) portal. This information is not only useful during development but for incident response and vulnerability management after production. Common formats for SBOMs are SPDX and SWID. Finally, UN R 155’s type approval requires the submission of a SBOM.

Cybersecurity Documentation Creators …

As stated above a lot goes into good automotive cybersecurity documentation. But who is involved in its creation and use? There are three main audiences: Engineers, Management and Auditors.

In traditional system development hierarchies a person with a title such as „Cybersecurity Manager“ would be responsible for documenting the cybersecurity of the system with all its aspects. With the emergence of agile development structures this should change. Such a role is often a bottleneck in the creation of the documentation, as it usually bears additional obligations. On the other hand they are seldom experts in all domains that a modern vehicle system integrates. These span from networking over embedded operating systems to autonomous algorithms.

The architects and developers of the system on the other hand have that specialized domain knowledge. They design the business logic of the applications as well as the cybersecurity controls based on the requirements. As a result architects and developers are especially suited for documenting the cybersecurity controls and rationals that address the risks. But with developers being used to development tools such as their IDEs, text editors, text-based version control systems, few of them feel at home in DOORs documents, Word files or Excel.

… and Consumers

On the other side of the spectrum are consumers of the documentation: new hires, managers and auditors. For them the documentation needs to provide a clear understanding of the identified risks and evidence that these risks have been appropriately addressed. Bidirectional traceability from the risks down to the controls needs to be available. This makes it easy to navigate through the documentation. The document’s structure should provide an obvious guidance on how to approach the documentation. In addition it never hurts if the document looks clean and professional.

Documentation as Code

These requirements might seem at odds. On the one hand easy accessibility to developers by using a code-like approach and on the other hand a traceable, professionally looking document that is easy to understand. But following a Docs-as-code approach these requirements can be achieved in addition to other benefits. Traceability to the system configuration, modular documentation generation, access control and SBOM integration.

For more Safety and Security related topics go to Safety und Security | Method Park by UL or see our ParkCheck for Cybersecurity.