Diadrom Generic Security Engineering Process (SEP)

1 Introduction

This document goes through the Security Engineering Process and how cyber security is handled by Diadrom during the Diadrom Autotech Bootloader project for a tier 1 and Original Equipment Manufacturer (OEM).

The document will only focus on the software for the bootloader, not the hardware nor the application.

2 Overall process

The security concepts and security requirements are developed by the OEM and the tier 1. The OEM requirements are defined in a OEM specific Software Requirements Specification (SWRS) and the corresponding test cases are defined in a Software Test Description (SWTD). Further requirements defined by the tier 1 need to be delivered to Diadrom in a separate requirement specification and agreed upon. Diadrom will use these documents as inputs to the project and will implement them as specified.

In order to both validate and verify the implementation of the requirements a number of automated test cases are implemented. The test cases will follow the SWTD, which also specifies the test coverage provided by each test case. For requirements lacking a test case, a different verification method is needed. Diadrom will specify and implement automated test cases as far as possible, but if this is not possible (or if specified by the OEM) a reviewing of the code will be made, and the result will be documented and shall be included in the Software Requirement Traceability matrix (SWRT) for each release. In this way Diadrom can provide the tier 1 a good level of assurance for the implementation.

In Figure 1, the process of implementing cyber security is shown.

Figure 1: Security Engineering Process, with explanation of the different steps

3 Tier 1 requirements

Diadrom will only implement the security concepts in such a way that the implementation is compliant with the OEM SWRS. No concept will be disregarded. Any potential deviations will be communicated with the tier 1 for approval using the SWRT. In this communication a reason of deviation will be provided, and a proposal of solution will be given.

Diadrom will not develop any new concepts for security. The OEM and the tier 1 have developed the security concepts and assessed the security threats and considered these in the specifications. Since this is the case, the development phase of the concepts is not Diadrom’s responsibility.

4 Lifecycle management

The lifecycle of the product can be divided into 4 phases; Design-, Implementation-, Verification & validation – and Maintenance phase.

4.1 Design phase

During the design phase the security objectives are formulated, and a thorough threat analysis and risk assessment is performed. It is during this phase the different security concepts are developed.

This phase is handled by the OEM and the tier 1 and the security concepts are defined in the OEM SWRS or the tier 1 SWRS.

4.2 Implementation phase

During the implementation phase, the designed concepts are implemented in software. By constantly doing testing and reviewing of the implementation of the requirements, a secure design can be assured.

Diadrom will use MISRA 2012 as static code analysis tool in our internal process in order to assure that the code is following a god form and will catch potential security risks. The deviations will be analysed and a report shall be provided to the tier 1.

4.3 Verification & validation

As described in chapter 3, as much of the concepts as possible will be tested by automated test cases. This ensures that the implementation is done correct and the test cases can be used for regression testing. If no automated test cases are available or possible to implement, reviewing of the code will be performed and the result will be documented.

4.4 Maintenance

The concepts in the OEM SWRS dictates how software updates shall be performed in a safe way, so that no ECU is made non-recoverable (i.e. “bricked”). The bootloader is based on a well-known two-level solution, primary- and secondary bootloader. If any security threats are unveiled during the maintenance phase of the product, the software can be updated to patch the security breach.