As any regular reader of this blog surely must know, vehicles have become increasingly connected and reliant on software systems. Rather than harp yet again on the many basic engineering safety failures of Tesla, in this post I will dig into an International Organization for Standardization (ISO) and the Society of Automotive Engineers (SAE) standard for duty and care in security, which can easily help raise the bar on safety.
The 2021 ISO/SAE 21434 outlines 15 clauses to guide architecture of a cybersecurity program throughout the entire lifecycle of vehicle manufacturing. Let’s delve into the key aspects of each clause, with a special focus on Clause 15 – the Threat Analysis and Risk Assessment (TARA) process.
Clause 1. Scope: ISO/SAE 21434 sets the stage by defining the scope. All phases of a vehicle’s lifecycle are meant to be covered, from concept and design to production, operation, maintenance, and decommissioning.
Clause 2. Normative References: This clause lists the external standards and documents referenced in ISO/SAE 21434, providing a foundation for implementation.
Clause 3. Terms, Definitions, and Abbreviations: Here, the standard provides clear definitions for key terms, ensuring a shared understanding for special or specific terminology used throughout the document.
Clause 4. Cybersecurity Management System (CSMS): ISO/SAE 21434 emphasizes the establishment of a cybersecurity management system within organizations. This system, like the venerable ISO 27001 Information Security Management System (ISMS), drives leadership commitment, accountability, and ongoing improvement.
Clause 5. Organization Security Requirements: This section underlines the importance of developing security within an organization’s risk assessment processes. It also highlights the need for cross-functional collaboration so security gets a seat at the business table.
Clause 6. Product Security Requirements: The standard guides the development of specific cybersecurity requirements for vehicle components, systems, and interfaces. This ensures that security is a fundamental consideration in product development.
Clause 7. Cybersecurity Requirements Engineering Process: This clause details the steps for integrating security requirements into the design and development processes, ensuring engineering management is held accountable to thoroughness and traceability.
Clause 8. Cybersecurity Design Process: The standard focuses on embedding security into the design phase of vehicle components and systems. Secure architecture, threat modeling, and coding practices take center stage here.
Clause 9. Cybersecurity Verification Process: This clause outlines the process for checking implemented security measures meet clause 7 requirements. Testing, reviews, and audits are key components.
Clause 10. Cybersecurity Validation Process: ISO/SAE 21434 stresses the validation of the entire vehicle system’s safety due to application of security. Real-world testing ensures the system aligns with intended security objectives.
Clause 11. Cybersecurity Configuration Management Process: Managing security throughout the vehicle’s lifecycle is crucial. This clause covers the usual suspects in software change management, including version control, dependencies and secure updates.
Clause 12. Cybersecurity Risk Assessment Process for Production: Addressing risks introduced during the production phase is vital. The standard tackles potential manufacturing and assembly defects as they relate to systems security.
Clause 13. Incident Detection and Response Planning Process: This section covers post-operation incident detection and response planning. It includes monitoring, reporting, and preparation for incidents.
Clause 14. Cybersecurity Aspects of Decommissioning Process: The secure decommissioning of vehicles is highlighted, ensuring sensitive data removal and minimizing residual security risks. And on that point, I can’t resist mentioning some recent news from CNBC.
A Tesla Model X totaled in the U.S. late last year suddenly came back online and started sending notifications to the phone of its former owner, CNBC Executive Editor Jay Yarow, months later. The car or its computer was suddenly online in a southern region of war-torn Ukraine, he found by opening up his Tesla app and using a geolocation feature. The new owners in Ukraine were tapping into his still-connected Spotify app to listen to Drake radio playlists, he also discovered.
Don’t ask me why it was news to CNBC Executive Editor Jay Yarow that Tesla regularly fails at basic safety engineering. And that brings us to the best Clause of all…
Clause 15. Threat Analysis and Risk Assessment (TARA) Process stands out as a critical step in the standard and one that deserves considerable attention. Running the TARA process involves identifying assets, threats, vulnerabilities, assessing impact and likelihood, calculating risk, identifying existing controls, determining residual risk, setting target risk levels, planning countermeasures, implementation, reassessing risk, documentation, verification, communication, and periodic repetition.
It’s a security architect’s dream, if you ask me. Here’s a simple Step-by-Step Process example for running TARA:
Step 1: Identify Assets and Scope
Identify the assets within the vehicle system, including hardware, software, data, and communication networks. Clearly define the scope of the analysis, specifying which parts of the system will be covered.
Step 2: Identify Threats
Enumerate potential threats that could exploit vulnerabilities in the vehicle system. Consider a wide range of threats, including unauthorized access, malware attacks, physical attacks, and social engineering.
Step 3: Identify Vulnerabilities
Identify vulnerabilities in the vehicle system that could be exploited by the identified threats. These vulnerabilities could be related to software, hardware, communication protocols, or human interaction.
Step 4: Assess Impact and Likelihood
Evaluate the potential impact of each identified threat exploiting a vulnerability. Consider consequences like loss of control, privacy breaches, financial losses, etc. Assess the likelihood of each threat-vulnerability pair occurring based on factors such as the threat’s motivation and capabilities.
Step 5: Calculate Initial Risk
Calculate the initial risk for each threat-vulnerability pair using a predefined risk assessment formula. This typically involves multiplying the impact and likelihood scores.
Step 6: Identify Existing Controls
Identify any existing cybersecurity controls or countermeasures that mitigate the identified risks. Evaluate the effectiveness of these controls in reducing the risk level.
Step 7: Determine Residual Risk
Calculate the residual risk after considering the effects of existing controls. This provides an understanding of the remaining risk that needs to be addressed.
Step 8: Determine Target Risk Level
Define the desired target risk level based on organizational risk tolerance and regulatory requirements. This step helps in setting a clear goal for risk reduction.
Step 9: Plan Countermeasures
Develop a plan for implementing additional or enhanced cybersecurity measures to reduce the risk level to the target. Consider a combination of technical, procedural, and organizational measures.
Step 10: Implement Countermeasures
Put the planned countermeasures into action according to the defined plan. This could involve software updates, hardware enhancements, process changes, etc.
Step 11: Reassess Risk
Reassess the risks after implementing the countermeasures. Determine if the risk level has been effectively reduced to meet the target risk level.
Step 12: Document the TARA Process
Document all the steps taken during the TARA process, including the identified threats, vulnerabilities, risk assessments, countermeasures, and results.
Step 13: Review and Verification
Review the entire TARA process and its documentation for accuracy and completeness. Verify that the chosen countermeasures are appropriate and effective.
Step 14: Communicate Results
Communicate the TARA results and findings to relevant stakeholders within the organization. This ensures that everyone is aware of the identified risks and the measures being taken to mitigate them.
Step 15: Repeat Periodically
Perform the TARA process periodically or whenever significant changes occur in the vehicle system. New threats, vulnerabilities, and technologies may emerge, requiring a reevaluation of the cybersecurity landscape.
Finally, here’s a step-by-step example for the TARA process for a vehicle’s connected infotainment system:
Step 1: Identify Assets and Scope
Asset: Connected infotainment system
Scope: Analysis covers software, communication interfaces, and data flows.
Step 2: Identify Threats
Unauthorized remote access, malware injection, data interception, physical access
Step 3: Identify Vulnerabilities
Unpatched software, weak authentication, insecure data transmission
Step 4: Assess Impact and Likelihood
Unauthorized access could lead to data breaches, loss of control. Likelihood varies based on attacker profiles (e.g. FBI MICE) and system exposures.
Step 5: Calculate Initial Risk
Initial risk score calculated for each threat-vulnerability pair.
Step 6: Identify Existing Controls
Firewall blocks generic service port attempts, authentication and encryption are in place, as well as least privilege principle for role-based access.
Step 7: Determine Residual Risk
Residual risk is calculated considering the effectiveness of existing controls.
Step 8: Determine Target Risk Level
Target risk level set to a certain value based on risk tolerance.
Step 9: Plan Countermeasures
Plan includes implementing stronger authentication, regular software updates, integrity checking and monitoring, intrusion detection with alerting.
Step 10: Implement Countermeasures
Countermeasures are integrated into the infotainment system.
Step 11: Reassess Risk
Risks are reassessed post countermeasure implementation.
Step 12: Document the TARA Process
All steps, assessments, and decisions are documented.
Step 13: Review and Verification
TARA process and documentation are reviewed by experts and stakeholders.
Step 14: Communicate Results
Results and actions are communicated to relevant departments.
Step 15: Repeat Periodically
The whole TARA process is scheduled for regular intervals or when system changes occur, much like how any threat modeling process should be built into software engineering cultures.
Keep in mind that each organization’s TARA process may vary based on their specific context, system complexity, and risk appetite. It’s crucial to involve experts with operational and engineering security knowledge and adapt the process to suit the unique requirements of your organization and its vehicle systems.
By embracing the ISO/SAE 21434 standard significant strides can be taken in bolstering the safety of vehicles. Meticulous attention to the clauses will cultivate a more robust security posture that not only safeguards vehicles but also builds trust with consumers and industry stakeholders alike. As technology continues to evolve into more complex interconnected systems, ISO/SAE 21434 provides a roadmap for the automotive industry to navigate the security landscape with a measure of quality from threat modeling.
Now back to explaining why Tesla is unfit to be on any road…
Related: Hundreds of Brand New Teslas Piling Up in Junk Yards