This curriculum spans the full lifecycle of automotive threat modeling, equivalent to a multi-workshop program embedded within a vehicle development organization’s cybersecurity governance, covering governance setup, cross-supplier collaboration, and integration with safety and compliance workflows.
Module 1: Establishing Threat Modeling Governance in Automotive Programs
- Define cross-functional threat modeling ownership between systems engineering, cybersecurity, and safety teams within vehicle development programs.
- Select and institutionalize a threat modeling methodology (e.g., STRIDE, TARA) aligned with ISO/SAE 21434 and OEM-specific cybersecurity management system (CSMS) requirements.
- Integrate threat modeling milestones into phase-gate reviews for ECU and vehicle platform development to enforce compliance.
- Develop artifact retention and versioning policies for threat models to support auditability and traceability during type approval processes.
- Negotiate access controls and data handling protocols for threat models containing sensitive vehicle architecture details across suppliers and internal departments.
- Establish escalation paths for unresolved high-risk threats that impact functional safety or regulatory compliance.
Module 2: Asset Identification and System Boundary Definition
- Map electronic control units (ECUs), communication buses (e.g., CAN, Ethernet), and wireless interfaces (e.g., Bluetooth, cellular) to identify all in-scope assets.
- Document data flows between ECUs and external entities, including cloud services and mobile applications, using data flow diagrams (DFDs) at appropriate abstraction levels.
- Classify assets based on safety impact (e.g., steering, braking) and regulatory relevance to prioritize threat modeling efforts.
- Define trust boundaries at physical and logical interfaces, such as between domain controllers and zonal networks, to scope threat analysis.
- Resolve discrepancies between network topology documentation and actual vehicle implementations through engineering collaboration.
- Identify third-party components (e.g., infotainment modules) with limited interface specifications and assess their impact on boundary completeness.
Module 3: Threat Enumeration Using Industry Frameworks
- Apply ISO/SAE 21434 threat categories (e.g., unauthorized access, spoofing) to systematically enumerate threats at each trust boundary.
- Customize STRIDE per attack vector (e.g., OBD-II port, OTA update server) to generate actionable threat statements with specific preconditions.
- Use attack trees to decompose high-level threats (e.g., remote vehicle takeover) into feasible attacker paths based on known vehicle vulnerabilities.
- Correlate identified threats with known vulnerabilities in automotive components (e.g., CVEs in telematics control units) to validate realism.
- Document assumptions about attacker capabilities (e.g., physical access vs. remote) to ensure consistent threat severity scoring.
- Iterate threat lists with red team findings and penetration test results to close detection gaps.
Module 4: Risk Assessment and Prioritization
- Implement a risk matrix that combines likelihood (based on attacker access level and exploit complexity) and impact (on safety, privacy, brand) to score threats.
- Adjust risk ratings based on existing controls (e.g., secure boot, firewall rules) and avoid double-counting mitigations in likelihood estimates.
- Resolve conflicts between functional safety (ISO 26262) and cybersecurity risk rankings when a component affects both domains.
- Document residual risk decisions for high-severity threats where mitigation is technically or economically infeasible.
- Use attack feasibility timelines (e.g., immediate vs. long-term) to prioritize near-term mitigations for production vehicles.
- Present risk treatment options (accept, mitigate, transfer, avoid) to technical steering committees for formal approval.
Module 5: Mitigation Strategy Development and Integration
- Design mitigations that align with OEM security requirements, such as encrypted ECU-to-ECU communication or intrusion detection system (IDS) deployment.
- Specify cryptographic key management approaches (e.g., PKI, symmetric key provisioning) for secure communication mitigations.
- Coordinate with hardware teams to ensure mitigations like Hardware Security Modules (HSMs) are included in ECU designs before tape-out.
- Define secure update mechanisms for software-based mitigations to ensure patchability in the field.
- Validate that mitigations do not introduce unacceptable performance degradation on time-critical vehicle networks.
- Document mitigation ownership and implementation timelines across supplier and internal engineering teams.
Module 6: Supplier Collaboration and Threat Model Exchange
- Define threat modeling deliverables and review cycles in supplier contracts for tier-1 and tier-2 vendors.
- Standardize threat model formats (e.g., JSON-based, Visio templates) to enable integration of supplier models into vehicle-level analyses.
- Conduct joint threat modeling workshops with key suppliers to resolve interface threats and align on trust boundaries.
- Audit supplier threat models for completeness, especially for components with limited OEM visibility (e.g., camera modules).
- Negotiate intellectual property constraints when sharing threat models that contain proprietary architecture details.
- Track supplier mitigation implementation through integration testing and vehicle-level validation campaigns.
Module 7: Continuous Threat Model Maintenance and Reassessment
- Trigger threat model updates based on change requests, such as new ECU features or connectivity additions (e.g., V2X).
- Reassess threat models after field incidents or emerging threats (e.g., new attack tools targeting specific ECUs).
- Integrate threat model updates into software configuration management systems to maintain version consistency.
- Align threat model refresh cycles with vehicle software release schedules for connected features.
- Use automated tools to detect deviations between implemented systems and documented models during integration phases.
- Archive legacy threat models with metadata to support forensic analysis during incident investigations.
Module 8: Integration with Broader Cybersecurity and Safety Workflows
- Link threat model outputs to security test cases in validation plans for compliance with UNECE WP.29 R155.
- Map identified threats to intrusion detection rules and SOC monitoring use cases for operational visibility.
- Coordinate with functional safety teams to ensure cybersecurity threats affecting ASIL-rated components are jointly assessed.
- Feed threat intelligence from fleet monitoring back into threat models to improve future designs.
- Align threat model documentation with cybersecurity documentation required for vehicle type approval.
- Use threat model data to inform cybersecurity bill of materials (CBoM) generation for vulnerability management.