The serialization of "The Future of Vehicle Network Security" is divided into three parts: "top, middle and bottom". Previous article: The Future of Vehicle Network Security (Part 1): Threat Analysis, Risk Assessment and Safety Design , Vulnerability Analysis in Vehicle Development Specific methods such as threat analysis, risk assessment and safety design, and vulnerability analysis in vehicle development. Then, in this article, we will analyze the key points of implementing security coding in vehicle development, security testing and security measures in the manufacturing stage.
5. Key points for implementing secure coding in vehicle development
According to the threat and risk assessment in the concept stage, the security design in the development stage, the vulnerability analysis and the design documents generated by the implementation activities of measures, examine the "secure coding" that should be executed in the software implementation stage.
Secure coding refers to "writing programs that are robust against cyber-attacks." At the end of Chapter 4 of the "Part 1" of this topic series , we discussed "vulnerabilities in the design phase" and "vulnerabilities in the implementation phase", and secure coding is a measure to solve "vulnerabilities in the implementation phase".
This is the most specific activity at the "software level" in the "product development phase", which is one of the seven elements of ISO/SAE 21434 shown in Figure 1 in Chapter 1 of the Topic "Part One" .
The Importance of Secure Coding
The reason secure coding is so important is that even if you take action against a "design-phase bug," an "implementation-phase bug" due to incomplete secure coding can cause serious damage. Vulnerabilities such as buffer overflows and SQL injections, for example, can lead to unintended code execution by third parties, which are typical examples of "vulnerabilities in the implementation".
In addition, for bugs in the software as a whole, "vulnerabilities occurring in the implementation phase" are reported more than "vulnerabilities occurring in the design phase", which is also important from the perspective of the "number" of bugs.
Specific tasks for secure coding
Figure 10 lists the specific work of secure coding. Before proceeding with the coding work, an overall plan should be drawn up according to the characteristics of the project (such as the importance of information and functions handled by the product, cost, delivery time, etc.).
Figure 10: Specific operations of secure coding
*1 Peer review: A quality assurance method in which people with the same (or similar) roles and occupations verify the results for improvement.
※2 About 300 rules of CERT-C/C++ are stipulated.
*3 MISTRA-C/C++: A coding guideline for the C/C++ language created for the purpose of automotive functional safety.
Secure Coding Challenges and Solutions
Many organizations use some static analysis tools to verify program stability at the source code level, but a big challenge is "too many problems detected to deal with" and "it is difficult to judge whether the tool is false positive".
In order to solve this problem, general software development tends to respond accordingly according to the importance (such as Critical/High or Moderate/Low) shown by static analysis tools. For example, where possible, perform fixes or risk analysis on Critical/High issues and then accept the risk, without error detection on Moderate/Low issues.
In the automotive industry, on the other hand, life-threatening damage can occur even for issues judged to be of low importance by static analysis tools if the issues detected by static analysis tools are not fixed, so it is difficult to Automatically determine countermeasures based on importance and the like.
So, in automotive software development, how to solve it?
Our solution to our customers is to "solve all problems detected by the tool", so "consider actions to deal with all problems". Here, "response" means "judgment as false detection" or "correction".
The focus is on "keeping as much vulnerable code as possible" and "planning to deal with problems detected by tools".
To this end, the specific measures are as follows:
• Implement secure coding education
• Run static analysis tools early in the development phase
• Automate static analysis tools, including incorporating static analysis tools into CI tools*4
*4 CI (Continuous Integration) tool: A tool for continuous source code construction (executable file and distribution package creation process) and testing. By combining static analysis tools with tools such as Jenkins that have automated builds, it is possible to perform static analysis while automating builds.
6. Safety testing in vehicle development
This chapter describes "Safety Testing", which is a test phase measure for implemented vehicles/on-board products.
Security Testing by Objective
Security testing mainly includes two concepts of vulnerability diagnosis and penetration testing.
Vulnerability diagnosis
As mentioned in the previous chapter, security work is carried out in concept phase, development phase, and implementation phase, each phase performs threat analysis, and based on these analysis results, security design and security coding are carried out. In this way, a vulnerability diagnosis is a test that determines whether a potential threat measure in an upstream process is performing correctly as expected. Due to these properties, a vulnerability diagnosis can create a checklist etc., since it pre-identifies the assumed threat and its countermeasures and provides some explanation for its comprehensiveness.
penetration test
Penetration testing is a test to determine the goal of the attack and conduct an attack (assessment) to achieve the goal.
Penetration testing does not require comprehensiveness, its purpose is to find out whether it is possible to achieve the purpose of "executing arbitrary code on a specific ECU (Electronic Control Unit)", if not, to what extent it will achieve the goal, and what can not achieve the goal what is the reason. Since penetration testing is conducted without regard to the various efforts in the upstream process, it can effectively reveal threats that were not thought of in the upstream process, i.e. omissions in the upstream process. In other words, every test item performed in penetration testing may also be an item in vulnerability diagnosis.
This means evaluating from an attacker’s perspective, just as global attackers do everything to achieve their goals regardless of the manufacturing company’s security measures.
As shown in Figure 11, the ideas of vulnerability diagnosis and penetration testing are different, not one contains the other. It is cost-impractical to perform full security testing on all products, so it is very important to choose which projects to perform. Depending on the product model, functional differences from similar models, etc.
Figure 11: Overview of vulnerability diagnostics and penetration testing
Security testing perspective for each test subject
Both vulnerability diagnosis and penetration testing include hardware testing and software testing.
Hardware Security Testing
There are several levels of hardware testing, one is the testing of standard external interfaces provided by the product. For example, Ethernet ports (LAN ports), network interfaces (such as Wi-Fi and Bluetooth), external device interfaces (such as USB ports), media inputs (such as CD/DVD), and buttons on the case. These interfaces are the standard ones that the user can use and are the easiest to test as they are described in the manual etc, but without knowing the internal specs can lead to pointless tests and are therefore a very difficult one to test effectively area.
The next possible project is to disassemble the case and do a study and analysis of the internal printed circuit board. For example, the type and purpose of the various chips used, whether there is silk screen and content, whether there is a debugging port, and checking and analyzing the traces of pins used before leaving the factory, etc.
Such investigation and analysis are beneficial for presumption of product specifications. In addition, if it is possible to discover and identify debugging ports, etc., which is a big risk in itself, and it is possible to obtain internal information for developers, it will help Perform follow-up tests. Additionally, if these analyzes identify chips that store communications capabilities, it can be tested whether firmware can be extracted from these chips and whether the extracted firmware can be analyzed.
Software Security Testing
There are several levels of testing for software versus testing for hardware. The most basic testing involves using the user interface (UI) presented to the user to ensure that security features are bypassed or actions that pose a security risk are performed. In addition, if an interface to the network is provided, it is possible to check whether unwanted services are started, whether the running software has known vulnerabilities, and if so, to perform an actual attack, and to confirm whether an attack can be performed.
If external testing is done without knowledge of the internal specifications for these tests, it can lead to blind testing, making it more difficult to test effectively. Therefore, you may need to analyze firmware extracted during hardware testing to determine internal specifications and then test software. Figure 12 provides examples of hardware and software testing.
Figure 12: Example of hardware and software testing
The place of security testing in the entire security development lifecycle
Whether these tests are performed as vulnerability diagnostics or penetration tests depends on the extent of the threat involved in the upstream process, the extent of the threat assumed, and the extent and manner of action taken. In other words, vulnerability diagnostics are performed to confirm the adequacy of countermeasures against threats envisioned in upstream engineering, whereas penetration testing is performed to confirm the adequacy and effectiveness of the original assumptions.
Therefore, security testing should not be reviewed in terms of implementation policies and content only during the testing phase, but should be formulated according to the efforts of the entire development process.
7. Safety measures in the manufacturing stage
Our focus is on security activities in design, implementation, testing and product development. This chapter does not discuss the security of the product itself, but rather the security activities required to complete the production phases necessary for the product.
The need for safety activities in the manufacturing phase
So far, malware and other security compromises have persisted despite manufacturing plants using their own network and control system facilities. In addition, in recent years, the Internet of Things such as smart factories has developed, and various devices are connected to the network of manufacturing factories. In addition, the systems themselves increasingly use general-purpose operating systems and applications. These changes in the environment lead to greater security risks, such as being a target for malware.
In addition, as vehicles connect to the network, the application of encryption technology is expanded, such as communication encryption and message authentication. As a result, more and more electronic control units (ECUs) must store encryption keys inside, which play an important role in encryption technology. The manufacturing plant must strictly control this encryption key and ensure that it cannot be leaked or tampered with at all times.
In addition, it is as important as ISO/SAE 21434, an international standard, and is expected to become law in the future. "Draft Recommendation on Cyber Security of the Task Force on Cyber Security and Over-the-air issues of UNECE WP.29 GRVA" is under development Implementation of a CSMS*1 is required throughout the entire life cycle of a product, including the manufacturing stage, so it will be necessary to carry out safety activities at manufacturing plants in accordance with laws and international standards in the future.
Therefore, due to various aspects such as IoTization of factories, development of vehicle functions, laws and international standards, there is an increasing need for security activities at the manufacturing stage.
*1 CSMS (Cyber Security Management System): A security management system for industrial automation and control systems.
What security measures are required in each facility of a manufacturing plant
So far, the factory's production facilities are rarely connected to external networks, which may lead to some security measures not being implemented in place. If these devices are connected directly to external networks, less secure production devices will be targeted. Since the entire network is exposed to security risks, every production facility and network requires security measures.
However, the effort and cost would be significant if all equipment were securely placed at the same level. Therefore, effective security management is achieved by isolating networks, controlling connections between networks using firewalls, etc., and implementing necessary security measures for each facility (see Figure 13).
Figure 13: Example of critical system access control
Encryption key management systems require stricter measures
Data called encryption keys are used for communication encryption, message authentication, etc. (see Figure 14). Once the encryption key is illegally obtained by an attacker, it will lead to cracking the encrypted communication and impersonating the vehicle. Therefore, strict management such as safe storage must be carried out in the production equipment and vehicles.
Since it is assumed that each model or vehicle uses a different encryption key, a management system is required to bind and manage the encryption key with the vehicle or device, and write the encryption key into the device. As mentioned earlier, once the encryption key is leaked, it will seriously affect the vehicle, so the system that handles the encryption key must ensure a higher security strength than ordinary production equipment.
Examples of Security Measures for Key Management Systems
• Physical security enhancements, including server room management
•Enhanced system access control using multi-factor authentication etc.
• HSM*2 encryption key management
• Enhanced syslog monitoring related to key management
Therefore, key management systems require stronger security protections. In an environment where existing systems and key management systems are mixed on the same network, if they are not all set to the same security level, an attack on the least secure system will compromise key management on the same network system. Therefore, the above-mentioned network isolation and access control must be implemented to ensure that each system has an adequate security configuration.
*2 HSM (Hardware Security Module): Secure hardware used to store important data such as encryption keys in data centers, etc.
Figure 14: Overview of the encryption process
For more content, please pay attention to "The Future of Vehicle Network Security (Part 2): Security Measures and Security Protection Requirements after Delivery",