Cybersecurity and software update management for vehicles and their suppliers, from start to finish: the cybersecurity management system, item definition, the cybersecurity plan and interface agreements with suppliers, threat analysis and risk assessment, cybersecurity goals and concept, specification and design, implementation and verification, validation and penetration testing, the cybersecurity case, assessment and type approval under UN R155, production and release for post-development, software update management and update campaigns under UN R156, monitoring and vulnerability management, incident response, and the end of cybersecurity support, following ISO/SAE 21434 and ISO 24089 in practice.
Vehicle cybersecurity and software update lifecycle: 13 stages, 18 gates of its own and 1 hand-off to the Product lifecycle, from Cybersecurity Management System & Organisation to End of Cybersecurity Support & Decommissioning.
13 stages, 18 gates of its own and 1 hand-off to the Product lifecycle. Each stop opens its stage; each sign opens its gate. Point at a stop or tab to it to read what the stage is for. What the codes mean
In collaboration with The Digital Electronics Blog (opens in a new tab)
An outlined sign with an arrow is a hand-off: the gate is owned by the Product lifecycle, where this lifecycle hands its work on.
In collaboration with The Digital Electronics Blog (opens in a new tab)
Setting up the organisation's cybersecurity management system before any one project relies on it: the cybersecurity policy and governance, roles and responsibilities, the processes for risk management, development, production, monitoring, incident response and updates, competence and awareness, tool and information security management, supplier management, and organisational audits.
Describing the item or component: its function, boundary, interfaces, operational environment and the assumptions it relies on, then planning the project's cybersecurity activities, tailoring them, deciding what is reused or bought off the shelf, and agreeing with each customer and supplier who does which cybersecurity activity and which work products pass between them in a cybersecurity interface agreement.
An outlined sign with an arrow is a hand-off: the gate is owned by the Product lifecycle, where this lifecycle hands its work on.
Identifying the assets of the item and the damage that could follow if their security properties were lost, describing threat scenarios, rating the impact on safety, finances, operation and privacy, analysing the attack paths and how feasible each is, determining the risk value, and deciding for each risk whether to avoid, reduce, share or retain it, using the methods described in ISO/SAE 21434 and the threats and mitigations UN R155 asks vehicle makers to consider.
Turning the risks to be reduced into cybersecurity goals, recording cybersecurity claims for risks that are retained or shared, and writing the cybersecurity concept: the requirements on the item and its operational environment that achieve the goals, allocated to the vehicle architecture and to suppliers, and checked for conflicts with the functional safety concept.
Refining the concept into an architecture and component requirements: the hardware security module or secure element, secure boot, key management, secure onboard communication, gateway and firewall rules, secure diagnostics and debug, intrusion detection, logging and the secure update path, with the security requirements each chip, IP block and software component must meet, flowed down to suppliers.
Building the security functions and the code around them under secure design and coding rules, checking them with reviews, static analysis, unit and integration testing, interface and fuzz testing, and analysing the development for weaknesses, so that each cybersecurity requirement is shown to be met before the item is validated.
Showing at vehicle or item level that the cybersecurity goals are achieved and the claims hold: penetration testing against the attack paths in the TARA, testing of the mitigations UN R155 asks for, review of residual risk, and confirmation that the item in its real operational environment behaves as the concept assumes.
Bringing the evidence together in a cybersecurity case, having it assessed independently, and, for a vehicle maker, presenting the vehicle type to the approval authority or technical service under UN R155 with its CSMS certificate, risk assessment, mitigations and test results.
Cybersecurity assessment complete gateType approval granted gate
Making sure the item is built as designed and secured: the production control plan for cybersecurity, secure key and certificate provisioning, end-of-line configuration, locking of debug and test access, protection of production tools and data, and the release for post-development, which confirms that monitoring, incident response and updates are ready before vehicles reach customers.
Running the software update management system: identifying every software version that bears on type approval, assessing each update for its effect on safety, cybersecurity and approved functions, building, signing and verifying update packages, checking compatibility with each vehicle configuration, informing users, delivering updates over the air or in the workshop safely, and recording each campaign, as UN R156 and ISO 24089 describe.
Watching for cybersecurity information that bears on vehicles in the field: supplier and researcher notices, public vulnerability databases, threat intelligence and vehicle security events, evaluating each event, analysing vulnerabilities against the TARA, deciding how each is managed, and reporting the results of monitoring to the approval authority where UN R155 requires it.
Monitoring and response ready gateVulnerability management review gate
Handling a cybersecurity incident from first detection to closure: triage, containment, root cause analysis with suppliers, remediation through an update or another measure, communication with customers, authorities and partners, and lessons learned fed back into the TARA, the concept and the next projects.
Announcing and reaching the end of cybersecurity support for an item or vehicle type: telling customers what support ends and when, completing final updates and advisories, handing over or retiring keys and back-end services, providing guidance for decommissioning and deleting personal data, and archiving the cybersecurity records for the retention period.
End of cybersecurity support notice gateEnd of cybersecurity support gate, owned by the Product lifecycle (End of support)
The full lifecycle detail, with its charts, flows, tables and every section, is for registered members. Registration is free and takes a minute. You come back to this page afterwards.