This is Part 3 (and the last one) of our blog series reviewing ENISA’s report on the importance of cybersecurity for connected cars. Continuing from where we left off in Part 1 and Part 2, in this blog we will cover the technical practices.
To receive more content on automotive cybersecurity, follow us on LinkedIn.
The report provides technical practices guidelines in nine categories:
- Protection of Networks and Protocols
- Software Security
- Cloud Security
- Access Control
- Self-Protection and Cyber Resilience
- (Semi-) Autonomous Systems Self Protection and Cyber Resilience
- Continuity of Operations
The guidelines suggest the implementation of Intrusion Detection Systems (IDS) both in vehicles and back end systems (guideline TM-01), review audit logs (TM-02) and network logs and other access controls (TM-03). It also directs that input data should be validated (TM-04). It also calls for adding the technical capabilities required for post-mortem forensics of crashes and cyber attacks (TM-05).
According to our experience, one of the key elements required for complete forensics and impact assessment is first of all maintaining a full inventory. One should maintain an updated full mapping of the software BoM at the fleet, vehicle and component levels. This mapping can then be used to identify the actual threats and how they are affecting physical assets.
2. Protection of Networks and Protocols
Interfaces should be protected using authentication and access control (TM-06). Critical in-vehicle communications should be secured (TM-07), and the same goes for all external communications (TM-08). Sessions should be protected (TM-09), as well as time synchronization sources (TM-10). Radio communications should be secured (TM-11 and TM-12). Packet filtering should be used to discard illegitimate traffic (TM-13), and secure protocols for protecting the confidentiality and integrity of sensitive data (TM-14).
We believe that the major gap today is that it is difficult to implement some of the above, especially the in-vehicle systems, but even more so, the validation that these protections are in place and operating as expected.
3. Software Security
Devices and services are configured for secure operations (TM-15). Validate that only legitimate software is installed (TM-16) and booted (TM-20), and implement configuration change management (TM-17). OTA firmware updates should be secure (TM-18 and TM-19).
For the software itself, a risk assessment should be performed to identify vulnerabilities, limitations of software dependencies. The risks should be addressed and mitigated (TM-21).
Mobile apps should be protected against reverse engineering and tampering (TM-22), and sensitive data should be secured when stored on mobile devices (TM-23).
4. Cloud Security
The report suggests to follow cloud security providers if applicable (TM-24). Implement high-availability for cloud-based applications (TM-25) but nevertheless implement critical systems in private or at least hybrid cloud setups (TM-26). Also ensure that all data in the cloud is secured, and most notably make sure that decryption keys are not stored insecurely.
The use of encryption all around is promoted (TM-28), with well-known, standardized cryptographic schemes (TM-29). Use storage encryption (TM-30) and secure key management (TM-31), with a recommendation to use Hardware Security Modules (TM-32).
6. Access Control
The guidelines suggest to apply security controls (TM-33), least privileges principle and individual access accounts (TM-34), and encourage the use of Multi-Factor Authentication (TM-36). In addition, remote communications should be controlled and monitored (TM-35).
7. Self-Protection and Cyber Resilience
Guideline TM-37 asks to implement security for Global Navigation Satellite System (GNSS). The report also recommends to apply hardening in different levels (TM-38), and make interfaces more robust (TM-39). It suggests the use of trusted software technologies for application isolation (TM-40), as well as physical and logical isolation.
8. (Semi-) Autonomous Systems Self Protection and Cyber Resilience
The guidelines recommend to protect localization data and different sensors in the system and also introduce high availability and redundancy for them (TM-42 to TM-47).
9. Continuity of Operations
The report highlights the importance of easy to understand notifications of issues and their remediation (TM-48). It suggests the creation of Business Continuity Plan and Business Recovery Plan (BRP) that should also cover third-party aspects and get regularly tested (TM-49). In addition, important parameters related to business continuity should be defined.
To summarize the Technical Practices:
To meet ENISA’s guidelines in the Technical Practices category, a solution must:
Maintain an updated inventory of hardware and software – the complete configurations, operating system details and installed open-source and proprietary software BoM of each component and vehicle within the fleet.
Validate that detection and protection mechanisms are implemented and configured correctly.
Validate that each component and its entire software stack is configured with recommended security settings.
Support secure software installations, in particular OTA updates.
Validate that decryption keys are stored and managed securely.
Validate the use of standard encryption schemes.
Validate that remote communications are secured.
Provide easy to use reporting of findings and remediation steps.
Cybellum Platform can help OEMs and automotive suppliers meet these guidelines by providing full visibility into the car’s S-BoM, operating systems, configurations, control flows, API calls, licenses and more; mapping all components and their inner connections thus arming you with the understanding of how each vulnerability impacts the car’s overall security.