Cybersecurity risks and the resulting goals and requirements alone have a significant impact on development. But when cybersecurity is considered and introduced after the development has already progressed and decisions on system, hardware, or software have already been made, the impact and difficulties increase even more.
Throughout this article we want to talk about the hurdles arising from introducing cybersecurity too late into your development process that could jeopardize your entire project plan.
Five situations where late cybersecurity implementation could obstruct development projects
Platform projects
To illustrate the importance of implementing cybersecurity early during vehicle development projects, let’s take a platform project that is then used for a customer project.
In the case where decisions on hardware, software, etc. are made without incorporating cybersecurity, but the customer project requires cybersecurity to be implemented, the then resulting customer requirements would include a wide but rather generic spectrum of cybersecurity requirements. However, one must consider cybersecurity specifically for the system produced for the client.
Impact on system, software, and hardware requirements
Based on the system’s functionality and its components, the cybersecurity risks, the identified goals, and the derived cybersecurity controls and cybersecurity requirements can have significant impact on the system, software, and hardware requirements.
The already chosen and ordered hardware might not support cybersecurity but the cybersecurity requirements usually demand the protection of cryptographic keys. For instance, when a microcontroller does not have an integrated HSM or HW-support for cryptographic functions, the project must consider using a different microcontroller or supporting the functionality through software.
Failing to consider cybersecurity when selecting the necessary hardware impacts the purchasing process or requires additional effort on software development.
Cybersecurity Controls
Additionally, cybersecurity controls can be resource intensive. With respect to customer requirements for startup times, which need to be met, the question is if the hardware suffices to provide the cybersecurity functionality. For example, calculating hashes in time, which can lead to efforts in testing of timings of cybersecurity functionality and different implementation styles such as authenticated boot versus secure boot.
Distributed development
If requirements for components, software, hardware, etc. were already communicated to suppliers, without the defined cybersecurity requirements, which will be communicated later in time, the development of the suppliers can also be significantly impacted by the new cybersecurity requirements.
In turn, this would again have impact on the ordered components and software. In addition, it must be ensured that potential other components being integrated into the system do not affect the cybersecurity of the system in a significant way and that these components themselves provide enough resources and functionality to support cybersecurity requirements.
Late communicated changes to suppliers can result in extended delivery of change requests or can even mean that the ordered component is not able to be cybersecure. Further, e.g., secure communication between components within a system can be a requirement, which may be problematic to implement depending on message protocols and already defined messaging schemes.
Existing requirements
Another example is the increased effort on alignment, agreement, and changes to already existing requirements for functional safety, existing system, software, and hardware requirements and architecture. This is because cybersecurity requirements certainly impact already defined requirements.
With the potential changes in resources of components, the functionality must be rethought as it is equally important to implement functional safety and cybersecurity requirements and the fulfilment of these requirements by the system. Messages, message lengths, CRC, CMAC etc. shall be considered.
All in all, these obstacles can affect budget, time, and quality of projects and the developed item, also considering the impact of suppliers. The fact that either cybersecurity needs to be aligned with customers, that changes occur or that cybersecurity features are even lacking, aggravates the situation. Not adhering to the customer’s cybersecurity requirements will certainly have a significant impact on the project.
Recommended course of action
The solution to these anticipated issues, as we see time and time again throughout our projects at CYRES Consulting, is to implement cybersecurity as early as in the concept phase and to consider it for the entire lifecycle of the item, to prevent delays in budget, time, and quality. But most importantly, to provide a product that adheres to all requirements and fulfills all defined cybersecurity goals.
Additionally, thorough prioritizing of documentation efforts, creating an Item Definition and a TARA as well as requirements definition, alignment, and agreement help with avoiding unwanted surprises, delays, costs, and discomfort.
Jan-Peter Von Hunnius is an expert in automotive cybersecurity, with a proven track record of experience in engineering and quality management in the automotive industry, as well as a TÜV-certified Automotive Cybersecurity Expert.
Comments are closed.