[Series] FESCARO's Automotive Cybersecurity FAQs ​ FESCARO has been operating the ‘FAQs Series’ to address cybersecurity issues for stakeholders in the automotive industry. We have conducted live webinars on four key topics, and the expert panel from FESCARO provided answers to the most commonly asked questions from industry professionals. If you missed a webinar on a topic that interests you, you can access both the recorded video and a text summary (FAQs) at the following link.   # FAQs Series 1. Cybersecurity Strategies for Tiers (Emerging-OEMs oriented) 2. Comprehensive Guide on Cybersecurity Solutions & Engineering 3. Cybersecurity Testing method based on VTA Success Stories 4. ECU Cybersecurity guidance : From production to post-mass production 5. How Korea’s Motor Vehicle Management Act Amendment impacts OEMs and Tiers The webinar, titled <How Korea’s Motor Vehicle Management Act Amendment impacts OEMs and Tiers>, held by FESCARO on Wednesday, April 3, concluded with great interest. The fact that more than 160 people pre-registered for the webinar underscores the significance of the ‘Korea’s Amendment to the Motor Vehicle Management Act’ within the industry. ​ Addressing inquiries about the Motor Vehicle Management Act, FESCARO prioritized the questions industry practitioners are most curious about. Are you interested in response strategies and practical know-how for complying with the Motor Vehicle Management Act? Please check the expert panel's clear answers in the video and text! ​ ​ ■ Expert Panels ​ ㆍDirector Ku Seong-seo (an iconic figure of the FESCARO’s webinar): 20+ years of experience in embedded system SW development, including automotive controllers and security solutions ㆍTeam leader Choi Kwang-mook (key player of the FESCARO’s grand slam): 20+ years of experience in automotive certification consulting, including CSMS, SUMS, ISO/SAE 21434, etc. ​ ​ ■ QUESTION LIST ​ 1.     Description of Korea’s amendment to the Motor Vehicle Management Act 2.     How is it different from UN certifications (R155 · R156)? 3.     Is it replaceable by UN certifications (R155 · R156)? 4.     Cybersecurity and software update-related contents in the Motor Vehicle Management Act 5.     What and how to prepare? (OEM/Tier) 6.     Does the Motor Vehicle Management Act necessitate modifications to controller software? 7.     Is it necessary to apply AUTOSAR? 8.     Can an organization implement AUTOSAR independently? 9.     What should be considered when applying AUTOSAR? ■ Video Ver. ■ Text Ver.   1. Description of Korea’s amendment to the Motor Vehicle Management Act Timeline for the Motor Vehicle Management Act Amendment Let’s begin with an explanation of the ‘Motor Vehicle Management Act’. The Motor Vehicle Management Act is a Korean law that aims to promote public welfare by overseeing vehicles operated in the country, ensuring their performance and safety. It encompasses aspects such as vehicle registration, safety standards, self-certification, and correction of manufacturing defects.   ​ Regarding this Motor Vehicle Management Act, an amendment was promulgated as of February 13, 2024. The amendment addresses the need to supplement related provisions as the focus of existing vehicles shifts from internal combustion engines and mechanical parts to software. The core of the amendment emphasizes the necessity of securing vehicle safety against cyberattacks and threats, as well as establishing a system to manage software updates that may impact vehicle safety. ​ In essence, with amendments to the Motor Vehicle Management Act concerning cybersecurity management systems and software updates being promulgated, it becomes imperative to prepare for them. While the primary subject of certification is the automaker (OEM), Tiers also need to respond to related requirements. The amendment to the Motor Vehicle Management Act is slated to take effect in August 2025 for new vehicles and in August 2027 for existing vehicles.  Motor Vehicle Management Act Amendment - Cyber security management system Now, let's delve into the main contents, starting with the cybersecurity management system. According to the Motor Vehicle Management Act, automakers and importers can only sell vehicles in Korea if they possess CSMS certification. Failure to maintain CSMS certification can result in a ban on selling vehicles. ​ CSMS, in this context, refers to a cybersecurity management system. Legally, CSMS is defined as 'a comprehensive management system encompassing administrative, technical, and physical protection measures to safeguard vehicles from cyberattacks and threats.' Here, cyberattacks and threats refer to attacks perpetrated by hackers. ​ Building a CSMS requires not only technical components but also an organizational security management system. It also entails implementing physical protection measures for workplaces and production facilities. Given that automakers are responsible for overseeing the cybersecurity supply chain to ensure the production of safe vehicles, they have no option but to mandate CSMS from their Tiers. Consequently, Tiers must be equipped to address the cybersecurity management and engineering requirements of automakers. Motor Vehicle Management Act Amendment – Software updates Next, let's discuss software updates. If an automaker updates software for functions related to safety standards, it must inform the Korean Ministry of Land, Infrastructure, and Transport in advance of such updates. Failure to comply may lead to penalties or fines. Tiers are required to furnish automakers with the results of analyzing the impact of software updates on safety standards in advance. Based on this analysis, automakers will review whether to comply with applicable laws and regulations. We'll delve into more details later. 2. How is it different from UN certifications (R155 · R156)? We will explain the amendments to the Motor Vehicle Management Act and the guidelines for CSMS (Cyber Security Management System) certification, considering that they were established based on UN R155 and R156. The certification is divided into system certification and vehicle certification. ​ ㆍSystem certification : CSMS certification and SUMS certification. Korean law requires only CSMS certification from automakers and importers. ㆍVehicle certification : Certification applicable to vehicle types sold in Korea. The certification methods include VTA certification or self-certification, and Korean law stipulates self-certification. ​ One important point to note here is that under the Motor Vehicle Management Act, vehicle certification and system certification are interconnected. The CSMS certification under the Motor Vehicle Management Act serves as a system certification for an automaker’s cybersecurity management system. Unlike existing system certifications for international standards such as ISO 9001 and IATF 16949, this certification pertains specifically to CSMS required under UN regulations and Korean laws. Without the corresponding system certification, related vehicle certification cannot proceed. Motor Vehicle Management Act vs. UN Certifications Let's briefly compare Korean law (Motor Vehicle Management Act) and European law (UN R155 · R156). Firstly, the certification body is the Korean Ministry of Land, Infrastructure and Transport under Korean law, whereas under European law, it is the approval agency designated by UNECE member countries. For CSMS certification, both Korean and European law require pre-certification, and for SUMS certification, only European law mandates pre-certification. Without CSMS certification, vehicles cannot be sold under Korean law, and similarly, European law prohibits vehicle sales without VTA certification. If the automaker's CSMS or SUMS changes, it must undergo reevaluation. ​ The validity period of system certification is up to 3 years, with a follow-up review required annually after obtaining certification. Violations of applicable laws may lead to cancellation of system certification. In the event of law violations, certification may be revoked under European law, while under Korean law, penalties or fines may be imposed depending on the violation. Lastly, regarding the vehicle certification methods, European law requires obtaining VTA certification before selling a vehicle to a UNECE member country, whereas Korean law allows sales with self-certification, but if violations are found in the sold vehicle, sales may be ordered to stop. 3. Is it replaceable by UN certifications (R155 · R156)?  Comparison of Certification Authorities In conclusion, that is not the case. For CSMS certification under the Motor Vehicle Management Act, only certificates reviewed and issued through the Korean Ministry of Land, Infrastructure and Transport are recognized. However, automakers or sales companies that have obtained CSMS certification under UN Regulation 155 will be able to obtain CSMS certification supervised by the Korean Ministry of Land, Infrastructure and Transport. This is because the Korean Motor Vehicle Management Act and its enforcement ordinance are based on UN R155. ​ Ultimately, the preparations that OEMs or Tiers must make are largely the same, allowing for adjustments to comply with the Motor Vehicle Management Act. FESCARO has achieved a grand slam in cybersecurity certification consulting and possesses a deep understanding of related topics. Therefore, if you need assistance in complying with the Motor Vehicle Management Act, please contact FESCARO.  4. Cybersecurity and software update-related contents in the Motor Vehicle Management Act Motor Vehicle Management Act Amendment - Provisions regarding cyber security management system Each provision of the amendment to the Motor Vehicle Management Act corresponding to CSMS is summarized as follows. ​ ㆍ Article 30-3: Vehicles cannot be manufactured or sold without CSMS certification (Article 30, Paragraphs 9, 10, 11, and 12 specify laws and regulations regarding CSMS.) ㆍ Article 30-9: Automakers wishing to self-certify their vehicles must establish a CSMS and obtain certification from the Minister of Land, Infrastructure and Transport. ㆍ Article 30-10: Automakers must comply with requests from the Korean Ministry of Land, Infrastructure and Transport to submit data on the establishment and operation of CSMS. ㆍ Article 30-11: Standards for cancellation of vehicle CSMS certification are specified. ㆍ Article 30-12: If an accident related to a cyberattack or threat occurs in the field, it must be reported to the Minister of Land, Infrastructure and Transport. ㆍ Article 81: (Penalty) Anyone selling a vehicle without CSMS certification is subject to imprisonment for up to one year or a fine not exceeding 10 million won (approximately $7,300). Motor Vehicle Management Act Amendment - Provisions regarding Software Updates The following are provisions related to software updates. ㆍ Article 34-5: This clause specifies the following six compliance requirements that must be observed when updating. Information on updates related to safe vehicle operation must be notified in advance to the Korean Ministry of Land, Infrastructure and Transport, and the performance test agent for the updates must be confirmed in advance. o   Update compliance requirements: ①    All functions of the vehicle must operate normally even after the update; ②    The vehicle must prove compliance with vehicle safety standards even after the update. ③    The update implementation process must be safe. ④    Update information must be delivered to vehicle users. ⑤    Update contents and history must be safely preserved. ⑥    Any other matters necessary for safe and smooth updating, as prescribed by the Ordinance of the Korean Ministry of Land, Infrastructure, and Transport. ㆍ Article 34-6: If the Korean Ministry of Land, Infrastructure and Transport deems it necessary, a performance test agent may investigate the adequacy of the automaker’s updated contents, methods, and management status. (Performance test agent refers to an organization designated as an agent by the Korean Ministry of Land, Infrastructure and Transport, such as KATRI.) ㆍ Article 35-2: Any modification, installation, addition or deletion of software that may affect the safe operation of the vehicle is prohibited. ㆍ Article 81: (Penalty) Anyone who violates ①~③ of update compliance requirements will be subject to imprisonment for up to 1 year or a fine not exceeding 10 million won (approximately $7,300). ㆍ Article 84: (Fines) Anyone who violates the provision for submitting update-related data will be subject to a fine not exceeding 20 million won (approximately $14,500) and anyone who violates ④~⑥ of the update compliance requirements will be subject to a fine not exceeding 10 million won (approximately $7,300). ​ For specific details regarding requirements and evaluations, enforcement ordinances and safety standards will be applied under the guidance of the Korean Ministry of Land, Infrastructure, and Transport, the Korea Transportation Safety Authority, and KATRI. FESCARO is also working on preparing for certification and cybersecurity testing, and we will share related news as it becomes available.  5. What and how to prepare? (OEM/Tier) Preparations for OEMs that have not obtained UN certification Firstly, we explain from the viewpoint of an automaker (OEM) that hasn't obtained UN certification. OEMs are obligated to establish a CSMS (Cyber Security Management System) compliant with ISO/SAE 21434. This system must remain operational not only during the development phase but also throughout production and field maintenance diagnosis. Specifically, OEMs need to implement TARA (Threat Analysis and Risk Assessment) alongside cybersecurity testing and validation procedures, allocating necessary resources accordingly. Additionally, OEMs must establish and maintain procedures for continuous cybersecurity monitoring, incident response, and data reporting. From an OEM perspective, the most important thing is to have a system for cybersecurity supply chain management. Preparations for Tiers that have not obtained UN certification The preparations for controller developers (Tiers) who have not obtained UN certification are similar to those of OEMs. First, Tiers must establish a cybersecurity distributed development process that incorporates CIA to address OEMs' CSMS needs. This is mainly managed by the sales and design departments. Additionally, Tiers must establish a CSMS based on ISO/SAE 21434 standards and organize a dedicated department or team for cybersecurity management and incident response. Finally, Tiers should establish TARA procedures and allocate resources in advance to meet OEM’s demands. To implement security measures based on TARA results, it is advisable to apply security technology and prepare procedures and resources for security testing. From a Tier’s perspective, it is crucial to ensure the security technology applied to the controller and establish a security testing system to ensure its quality.  Preparations for OEMs and Tiers that have obtained UN certification Lastly, an OEM or Tier that has already obtained UN certification should proceed with internalization work to review and supplement their existing CSMS based on the Motor Vehicle Management Act and CSMS certification standards. And since submissions to the Korean Ministry of Land, Infrastructure and Transport must be written in Korean, it is necessary to translate the output into Korean. ​     6. Does the Motor Vehicle Management Act necessitate modifications to controller software? Yes, it does. Also, we can say that it's imperative to select a software configuration and development plan capable of adapting flexibly to evolving cybersecurity technologies in the future. ​ The Motor Vehicle Management Act does not describe a very specific methodology. However, in Article 2 (Definition) 4-4, a cyber security management system is defined as 'a comprehensive management system including managerial, technical and physical protection measures to protect vehicles from cyberattacks and threats.' For clarity, we will show the necessary measures specified in 5.1.1 of UN R 155 that an automaker (OEM) must deploy in its vehicles to be certified.  Paragraph 5.1.1 of UN R 155 (a) : Include not only automakers but also Tiers. (b) : Reflect security measures for vehicles. (c) : Appropriately implement cybersecurity measures in the vehicle design itself. (d) : Must be able to detect and respond to cybersecurity attacks on vehicles. (e) : Need log data processing with forensic capabilities to detect and analyze cybersecurity attacks. Now, let us explain the above regulations from a SW perspective. The software must include features to protect the vehicle from external attacks and manage cybersecurity events that may occur in the vehicle. These security functions must be applied on a per-controller basis. Functions to protect the controller itself include Secure Boot, Secure Storage, Secure Debug, Runtime Tunning Protection, Memory Protection, HSM, OS Hardening, general controller security requirements, secure coding, and open-source vulnerability management. ​ There are also requirements to defend the vehicle from external attacks by protecting communication between the vehicle and the outside and between controllers within the vehicle, such as Secure Access, Secure Unlock, SecOC, TLS, IPSec, MACSec, and Firewall. Additionally, CAN-IDS, Ethernet-IDS, integrated security log, and vSOC (vehicle security operation center) established by OEMs from an operational perspective are features to detect security events that may occur in vehicles and create appropriate countermeasures. ​ Most of these requirements are realized in SW, and the requirements continue to evolve. Therefore, it is important to choose a SW configuration and SW development methodology to better respond to requirements more efficiently. In other words, OEMs and Tiers must be able to effectively manage and develop SW in order to prepare response plans. ​ So what is a suitable methodology for SW development? In fact, in terms of the methodology for effectively developing and managing SW, automotive SW has already begun to increase in importance not only from a cybersecurity perspective, but also from a long time ago. Not only standard organizations and specialized companies such as AUTOSAR, Automotive Grade Linux, Android Automotive, and QNX, but also OEMs themselves are carrying out these activities. In other industries, there's also a long history of efforts to manage and develop software effectively. These efforts often involve standardization to enhance convenience and reusability in software development processes. ​ In the automotive SW field, such activities are particularly led by AUTOSAR, which is also the most widely adopted SW platform. AUTOSAR is an organization formed by major automakers and controller developers in 2003. It stands for Automotive Open System Architecture, an automotive SW standard. ​ Given the ongoing and future necessity of cybersecurity, adopting standard SW platforms can be an effective strategy for addressing cybersecurity concerns, particularly in the automotive industry. ​     7. Is it necessary to apply AUTOSAR? Increasing importance of SW Not required, but we would like to say, ‘Shouldn’t we do it now?’ The increased importance of automotive cybersecurity, leading to legislative action, is primarily driven by the growing connectivity and electronic complexity of vehicles. This has led to an explosive increase in the importance of SW. The vehicles of the future, or rather, modern vehicles, are evolving toward C.A.S.E (Connectivity, Autonomous, Sharing, Electrification), and as a methodology to realize this, a major paradigm shift is occurring toward software-driven vehicles (SDV). ​ The increase in high-performance electric field controllers, changes in E&E architecture, increase in connectivity and electrification, and SW advancement are having a significant impact not only on automakers (OEMs) but also on controller developers (Tiers). As SW takes up an increasing proportion of vehicles, more than half of the defects that occur in vehicles are caused by SW. ​ While it's nearly impossible to entirely prevent software defects, refining the controller system, including the software structure, is essential. Preventive measures should be implemented through rigorous, effective, and repetitive verification testing. Post-mass production, it's crucial to maintain software quality activities for rapid response continuously. International Regulations and Standards Furthermore, the scope of international laws and standards applicable to vehicle and controller development is expanding, accompanied by specific requirements. These include UN regulations such as R155 and R156 concerning cybersecurity and software update management, as well as ISO/SAE 21434, the cybersecurity engineering standard, functional safety, SOTIF, and A-SPICE. It's imperative to be well-versed in and consider these standards during the development process. Preparation for Over-The-Air (OTA), which is becoming essential for vehicles, is also needed. ​ As mentioned in response to the previous question, some individuals anticipated the diverse and complex requirements and changes in software, leading to the creation of AUTOSAR. These efforts have contributed to enhancing the efficiency of automotive software development and management. Standardization in software structure provided by AUTOSAR enables greater convenience, reusability, and modularization in development, addressing challenges in adapting to various changes. AUTOSAR serves as a notable methodology for optimizing development time and cost, meeting new requirements, and enhancing quality. ​ So far, we have talked about AUTOSAR as if it is essential, but I would like to say once again that it is not essential. The decision to adopt AUTOSAR depends on various factors such as the controller's characteristics, its role in the vehicle, and the automaker's circumstances. Additionally, implementing AUTOSAR entails a certain level of cost and effort. Therefore, it's advisable to carefully assess these factors and environmental considerations before deciding whether to apply AUTOSAR. ​ FESCARO has professional capabilities not only in cybersecurity but also in AUTOSAR. We not only integrate AUTOSAR into our self-developed and mass-produced controllers but also engage in AUTOSAR-related development projects with various Tiers. With our extensive know-how in AUTOSAR, we stand ready to assist you in making the best choice. Please don't hesitate to contact us if you have any concerns.   8. Can an organization implement AUTOSAR independently? AUTOSAR Requirements Defined The short answer is yes. However, automakers or controller developers typically do not do it that way. As mentioned earlier, AUTOSAR stands for Automotive Open System Architecture and serves as an automotive software standard. Additionally, AUTOSAR is also an organization. ​ This organization defines standards aimed at achieving an automotive open standard software structure and specifies various requirements to realize this goal. While it's possible for companies to fully understand and implement these standards to create their own AUTOSAR-compliant software, they often weigh various factors such as costs and efficiency. As a result, each company tends to focus on its strengths and finds a role that best suits its capabilities. This approach allows for the development of controllers and even entire vehicles using AUTOSAR. Roles for each company For instance, semiconductor manufacturers producing MCUs and microcontrollers for controllers develop MCAL to ensure seamless compatibility with AUTOSAR on their chips. AUTOSAR solution providers develop BSW and RTE adhering to AUTOSAR standards, along with various tools for efficient software management and creation. These AUTOSAR packages enable the creation of software components tailored for the controller, known as application software, with the final integration carried out by the controller developer. ​ When developing a controller, it's prudent to choose an AUTOSAR solution that aligns with the OEM's requirements, supports the selected MCU, offers effective engineering services, and optimizes costs. FESCARO maintains close collaborations with leading AUTOSAR solution providers. If you have any questions regarding which solution to choose, please don't hesitate to contact us. We'll assist you in selecting the optimal solution. ​       9. What should be considered when applying AUTOSAR? Semiconductor Manufacturers (L)   Platform SW Developers (R) The primary consideration in applying AUTOSAR is aligning with customer requirements. Additionally, factors such as the MCU selection and associated costs are crucial. Internal development capabilities, project schedules, and proficiency levels should also be taken into account. ​ As you're aware, constructing a vehicle involves the integration of numerous controllers. The automaker (OEM) establishes requirements for controllers tailored to the vehicle's manufacturing needs and distributes them to Tiers. Upon receiving these requirements, Tiers analyze them and make decisions regarding their implementation. ​ In the past, determining the direction of controller development primarily involved reviewing controller functions. However, in today's context, additional but essential factors such as cybersecurity, functional safety, and OTA updates must also be carefully evaluated. This comprehensive review guides the selection of an appropriate MCU and platform SW. When deciding on the platform SW, various factors including the complexity of controller functions, reusability, business scalability, OEM requirements, MCU support, cost, etc. are taken into consideration. ​ In today's landscape, many companies opt for AUTOSAR as their platform software. While OEMs may request it, it's often chosen based on factors like the product's competitiveness, reusability, and scalability. However, developing AUTOSAR-compliant software in-house is not feasible, necessitating the selection of an appropriate solution. When making this decision, it's crucial to consider whether the chosen solution is compatible with the MCU, capable of meeting all customer requirements, supported by quality engineering services, and offered at a reasonable cost. AUTOSAR Purchasing Process Typically, AUTOSAR encompasses numerous functions. Even after deciding on the AUTOSAR provider, it's necessary to carefully select the services and components required for your product within the AUTOSAR BSW. When purchasing AUTOSAR, the configuration tool, BSW, and RTE are typically provided by the AUTOSAR solution provider. Additionally, the AUTOSAR MCAL may be obtained directly from the MCU supplier or included in the AUTOSAR package. ​ We've provided a brief overview of AUTOSAR and the considerations involved in controller development. More detailed technical issues will be covered in our next webinar. We appreciate your continued interest and participation. ■ Bonus Q&A ​ During pre-registration for the webinar, we received approximately 100 inquiries. In addition to the questions covered above, we have also addressed four of the most frequently asked questions. If you're curious about the expert panel's answers, please check them out in the video (starting from 37:40). ​ 1. What changes from the perspective of Tier 1, which solely provides software, and how will these changes impact Tiers 2 and 3. 2. The actual impact on cybersecurity and A-SPICE. 3. What preparations should a semiconductor supplier make? Additionally, is there an international standard that covers the amendments to the Motor Vehicle Management Act. 4. Do small-scale manufacturers who purchase, manufacture, or sell special vehicles (e.g., agricultural machinery) or unfinished vehicles also need to comply with the amendments to the Motor Vehicle Management Act? ■ Webinar Reviews ​ *​ Gyun Kim “I was confused ahead of the implementation of the Korean law, but I was able to hear a clear explanation of the work between OEMs and Tiers.” * Haeng Heo “It was beneficial to be able to see the certification items and subjects at once. I will reflect them in establishing a plan to acquire cybersecurity certification.” * Woo Lee “I wish the webinar had been longer, and I’m curious about how not only Tier 1 companies but also companies undertaking small-scale modification projects will respond.”

[Series] FESCARO's Automotive Cybersecurity FAQs ​ FESCARO has been operating the ‘FAQs Series’ to address cybersecurity issues for stakeholders in the automotive industry. We have conducted live webinars on four key topics, and the expert panel from FESCARO provided answers to the most commonly asked questions from industry professionals. If you missed a webinar on a topic that interests you, you can access both the recorded video and a text summary (FAQs) at the following link.   # FAQs Series 1. Cybersecurity Strategies for Tiers (Emerging-OEMs oriented) 2. Comprehensive Guide on Cybersecurity Solutions & Engineering 3. Cybersecurity Testing method based on VTA Success Stories 4. ECU Cybersecurity guidance : From production to post-mass production 5. How Korea’s Motor Vehicle Management Act Amendment impacts OEMs and Tiers The last webinar of the year organized by FESCARO was successfully completed. This webinar, titled <ECU Cybersecurity guidance : From production to post-mass production> took place on October and attracted approximately 80 participants from more than 50 companies. ​ Automotive controller developers should not only apply security solutions to their controllers, but also consider cybersecurity during and after the production. This webinar focused on both the KMS (Key Management System) required during production and the Security Control System required on the post-production phase.  Let’s check out the clear answers from the FESCARO’s expert panel.     ■ Expert Panels ​  • Director Ku Seong-seo & Team Leader Choi Hee-sun : 20+ years of experience in embedded system SW development, including automotive controllers and security solutions  • Director Lee Hyun-Jeong: A white hat hacker who is a question setter for 'CODE GATE CTF', an international hacking defense competition, and an IT/Automotive security expert. ​   ■ QUESTION LIST ■ Video Ver. ■ Text Ver.   1. What kind of cybersecurity do OEMs require on their production lines? Typically, OEMs rarely explicitly request cybersecurity-related precautions for manufacturing controllers. This is due to the variations in controller characteristics, semiconductor types, required security functions for each controller, and the assets that need protection. ​ From the supplier's perspective, it is crucial to establish an appropriate response strategy as they must effectively address these vague requirements. When automotive cybersecurity requirements are unclear, it is advisable to consult the international standard ISO/SAE 21434. The key is to develop a rational and consistent response plan tailored to the specific controller characteristics while aligning with OEM requirements.  The table provides a summary of ISO/SAE 21434 in its entirety. Section 12 outlines the requirements that need to be considered when manufacturing controllers or vehicles. It establishes two primary objectives: first, the application of WP-10-02, which outlines the requirements that must be met during production after development phase, and second, the prevention of new vulnerabilities from entering the controller during production process. These requirements can be broken down into in three key aspects: the establishment of a robust control plan for production, the inclusion of four specific conditions within the production control plan, and the successful execution of production in accordance with this plan.   WP-10-02, which pertains to the requirements on the production process after development includes the initialization actions such as safely injecting and activating security assets (e.g. encryption keys, passwords, certificates, etc.) used in the operation of the security solutions so that the cybersecurity solutions or controllers can operate properly in the vehicle after production. ​ The production Control Plan, mentioned in RQ-12-02, should include :   a. Procedure to meet the production requirements described above   b. Description of tools or equipment to be used for this purpose, e.g. KMS, key injection device, verification device, etc.   c. Measures to keep the production environment safe (e.g. firewall, VPN, etc.)   d. Measures to ensure reliable and proper fulfillment of production requirements ​ We looked in more detail on WP-10-02 and the four key components that must be incorporated within the Production Control Plan. In summary, two things are essential for meeting OEM’s cybersecurity requirements: One is to safely apply and activate security assets during the production process so that the cybersecurity measures applied to the controller can function effectively post-production, and the other is to provide environmental factors so that this process can be sufficiently protected from external intrusions.   2. What are security assets and KMS?  To help you understand, let me begin by explaining the terms. An asset is something that requires protection since it possesses inherent value or contributes to the overall value. In the context of a controller, assets encompass controller functions, hardware (HW), software (SW), and the data stored or utilized within the controller. The security assets mentioned in the question refer to data, software, and various information used for cybersecurity functions. These are also critical assets that need to be protected. ​ Moving on to KMS (Key Management System), it refers to a device or equipment responsible for generating, securely storing, and managing security assets used in the controller's security functions. Additionally, it facilitates the distribution and injection of security assets into the controller during the production process. For those who may not be familiar with KMS, I will provide a more detailed explanation.  The diagram above illustrates the process of applying security assets, whether provided by OEMs or independently created, to controller production. In total, there are three Key Management Systems (KMSs), all of which are responsible for managing security assets, such as certificates and security keys, and distributing them as needed. For instance, OEMs create, distribute, and manage security libraries or other keys required for security functions at the request of suppliers request. The suppliers, in turn, receive, manage, and securely maintain these assets, incorporating them into production when required. The controller suppliers themselves have to generate essential security keys, passwords, and other components, inject them into the controller, and activate the security functions, and collect, manage the information to be used when needed. ​  Therefore, it is crucial to understand the OEM's requirements, identify the assets integrated into the controller, and make informed decisions regarding the configuration of the KMS and related processes. This necessitates professional judgment grounded in expertise and experience. FESCARO possesses a track record of constructing and delivering Key Management Systems (KMS) for OEMs. The KMS incorporates processes to create/distribute/manage security assets necessary for OEMs to cooperate with suppliers, and to carry out tasks appropriate to each role within the organization.   The KMS developed for suppliers was tailored to suit the unique attributes of both the controller and the supplier, and it was seamlessly integrated with the production line. Furthermore, we furnished a key injection system that interfaces with both the KMS and the controller during the actual production phase, allowing for the injection of security assets. Additionally, we have frequently created and supplied software (SW) capable of receiving these assets from the controller, securely storing them, and triggering security functions when needed.     3. Requirements for building KMS   When selecting a Key Management System (KMS), it is vital to understand its intended purpose, namely, what data will be generated, managed, and distributed. This can differ significantly between various OEMs and controller types. This discussion outlines the fundamental factors that should be taken into account when dealing with KMS, even when their specific purposes may vary. Two key considerations must be addressed when developing KMS.   1. The robustness and reliability of the security assets generated by KMS need to be upheld. 2. The environment where the KMS is located must be very safe from external access.   First, to ensure the robustness and reliability of security assets, it is imperative that only authorized individuals have the capability to execute actions in accordance with their granted permissions. The security assets should be created and stored securely, and the recipients requiring these security assets must be accurately specified to ensure precise distribution. Moreover, effective management of their expiration dates and change cycles is essential, and they should be restored or disposed of as necessary.   We will express the above five requirements technically so that practitioners can understand them more easily. We can assess compliance with the first condition by verifying whether the system aligns with the Key Management Interoperability Protocol (KMIP). KMIP serves as a client-to-server communication protocol utilized for the storage and maintenance of security assets, including security keys and certificates. The second requirement involves the use of Hardware Security Module (HSM) certified under FIPS 140-2 standards. This certification ensures the stability and reliability of the security logic within the system. As for the third condition, it's imperative to implement redundancy measures to protect the created assets and prevent operational disruptions. Lastly, the system should offer support for functions such as dashboards, enhancing convenience in terms of management and operations.  First, to ensure the robustness and reliability of security assets, it is imperative that only authorized individuals have the capability to execute actions in accordance with their granted permissions. The security assets should be created and stored securely, and the recipients requiring these security assets must be accurately specified to ensure precise distribution. Moreover, effective management of their expiration dates and change cycles is essential, and they should be restored or disposed of as necessary.   We will express the above five requirements technically so that practitioners can understand them more easily. We can assess compliance with the first condition by verifying whether the system aligns with the Key Management Interoperability Protocol (KMIP). KMIP serves as a client-to-server communication protocol utilized for the storage and maintenance of security assets, including security keys and certificates. The second requirement involves the use of Hardware Security Module (HSM) certified under FIPS 140-2 standards. This certification ensures the stability and reliability of the security logic within the system. As for the third condition, it's imperative to implement redundancy measures to protect the created assets and prevent operational disruptions. Lastly, the system should offer support for functions such as dashboards, enhancing convenience in terms of management and operations.  Usually, as part of quality activities, a process for managing security events is defined and operated according to a manual. However, today we will focus on collecting and managing security events that occur in the field.   FESCARO is constructing security event monitoring systems for clients across the entire vehicle life cycle. The security event monitoring function is initially activated during the vehicle production on the assembly line. At this stage, details such as the software (SW) and hardware (HW) version information installed on the vehicle, and the occurrence of security events, are recorded on the server.   Once the security event monitoring function is initiated on the production line, the Central Gateway (CGW) is tasked with collecting and storing data regarding security events for controllers equipped with cybersecurity functions within the vehicle. ​ Subsequently, when a manufactured vehicle is brought to a repair shop for maintenance, diagnostic equipment is employed to ascertain whether any security events have transpired in the vehicle. In the event of a security event, the security log is gathered and transmitted to the server to update the vehicle's status. ​ In cases where a security event occurs in a connected vehicle equipped with an external communication controller, the controller communicates a security event notification to the server. The server can, if necessary, request comprehensive data from the vehicle for further analysis. Upon receiving such a request, the vehicle transmits detailed data, including CAN messages before and after a security event, to the server. Upon receiving a security event that has transpired in a vehicle through the three pathways previously described, the server undergoes an automatic process to determine the vehicle model, controller, and software (SW) in which the security event occurred. The server automatically categorizes the array of security events obtained from diverse vehicles, facilitating an environment where individuals can carry out their respective analysis tasks. The server may encounter security events of a type that it cannot classify. In such instances, these events are labeled as "Unknown" to enable human analysis.   Next, one or more security events that are related to each other are grouped and managed as one security vulnerability. For example, security events identified as abnormal messages by CAN-IDS are amalgamated into a singular security vulnerability and collectively managed until the security vulnerability is resolved.   Lastly, abnormal vehicles are managed. The status of each vehicle produced on the production line is recorded, and this status is continually updated through maintenance and connectivity activities. During this process, not only the vehicle that reported the security event but also those vehicles with a potential risk of encountering a similar security event are identified. This proactive approach enables preemptive measures to be taken, enhancing overall security.   5. Examples of building a security control system   FESCARO has successfully developed and maintained security control systems for global passenger and commercial automakers. The image above illustrates the security control system we've implemented for a global OEM. While there are numerous functions within the system, we will introduce some of the key features.   First, let's discuss the dashboard. The dashboard provides a concise overview of the current security event status. It offers real-time updates on which security events have occurred in specific vehicles and compiles statistical data. This data includes insights into which security events on which vehicle type have been most frequent. It also includes a highly regarded feature among OEMs: the ability to 'Download as Report.' This feature generates reports detailing the status of security events, organized by month, week, vehicle type, and individual vehicle, all conveniently presented in Excel format.   Next, we have a feature that allows to examine the status of security events in greater detail. It displays information about which events occurred on which vehicles, along with their timestamps, event specifics, and any mitigation actions taken. To simplify the analysis of raw data, this feature visualizes and presents CAN messages.   Furthermore, the system provides a timeline of security events for a specific vehicle. This timeline aids in easily assessing which security events have taken place in a given vehicle. Importantly, the security control system goes beyond merely collecting security events from the field; it streamlines and visualizes tasks that would otherwise require manual handling, reducing the workload for human operators. Feedback from our customers attests to the convenience and efficiency that the security control system brings to the analysis process.     6. Do Tiers necessarily need a security control system? Wouldn’t quality activities be enough?   Of course, we can manage security events through quality activities. However, there are practical limitations to manual management, especially for Tier suppliers who often work with multiple OEMs and their various vehicle variants. Instead of manually classifying and analyzing every security event, the adoption of a security control system can significantly enhance efficiency. ​ While security control systems may not be mandated for Tiers, an impact analysis process is crucial. A single security event may potentially affect multiple vehicles and vehicle types. Security control systems automatically conduct impact analysis and identify vehicles that haven't encountered a security event yet but are at risk, enabling proactive measures to prevent the propagation of damage resulting from security incidents. ​ Vehicles become increasingly interconnected with external networks and hackers' attack strategies continuously evolve. What may be cutting-edge security technology for controllers today may not be so in 10 or 20 years. Given that no security system is entirely foolproof, ongoing monitoring after production is essential. Rapid identification and analysis of security incidents, followed by appropriate mitigation actions, are vital. ​ To achieve this, an appropriate security control system must be introduced to protect against security threats throughout the vehicle's entire life cycle.   7. How is the security events of the vehicle shared?   Security events that can occur in vehicles include intrusion detection events, software tampering events, and secure storage tampering events etc. When these events occur, related information is collected and stored. ​ In the case of connected vehicles, security event data is instantly relayed to a controller equipped with a telematics unit, such as a CCU. The contents of security events and related information are gathered by the CCU and then transmitted to the server. However, since connected services are optional for vehicles, not all vehicles transmit security event data to the server in real time. ​ For vehicles that are not connected, there is currently no direct means to send security events to the server in real time. Nonetheless, the collection of security events from as many vehicles as possible is essential for addressing and preventing potential security incidents in the future. ​ To address this, non-connected vehicles rely on car repair shops to carry out this task. When a vehicle is brought to a repair shop and connected to diagnostic equipment, the diagnostic tools search for stored security events within the vehicle's gateway and subsequently transmit this information to the server. FESCARO is also actively developing and delivering a security solution for diagnostic equipment to facilitate the search and automated transmission of security events from the gateway to the server. Let's explore the details of the security event information transmitted to the server. In paragraph 7.2.2.2 of UN Regulation 155, the regulation doesn't specify the exact information to be managed. However, it does emphasize the need for a process to provide relevant data to support the analysis of attempted or successful cyberattacks. This process must be in operation and proven during the certification process. ​ To establish effective preventive measures, it is crucial to utilize security event information to understand the nature of intrusion attempts, identify issues, and pinpoint the timing of such events. Therefore, the necessary information must be collected for analysis. ​ The information sent to the server includes the Vehicle Identification Number (VIN) to determine which specific vehicle the security event occurred in, the type of security event, a timestamp to track the time it occurred, and, a freeze frame (for intrusion detection events) containing the CAN messages that were involved in triggering the event.   8. How does the gateway protect vehicles? The gateway maintains vehicle security with the following functions:    1. Primary defense against intrusion attempted through the OBD diagnostic port connected from outside the vehicle  2. Monitoring abnormal behavior of vehicle controllers and reporting detected abnormal operations to the server  3. Detecting the operation of unauthorized software other than officially certified software through the VTA certification process and reporting it to the server ​ Let's begin by examining the concept of 'defense against intrusion from outside the vehicle'. Indeed, this concept is about shielding the vehicle from external intrusions that might occur through a diagnostic port with an external contact point. This protection is achieved by implementing security measures such as Secure Unlock, Secure Access, Secure Flash, etc. For more about security features, please refer to the ‘Comprehensive Guide on Cybersecurity Solutions & Engineering’ FAQs. ​ Second is about CAN-IDS, which upholds vehicle security by focusing on the ‘detection and reporting of abnormal behavior occurring inside the vehicle’ as specified in UN R155. This encompasses the following six key activities:   · Undefined message detection · Undefined signal detection · Abnormal DLC message detection · Abnormal cycle message detection · Bus load detection · Signal rate of change detection ​ In the development of a gateway, CAN messages or signals are typically routed and processed according to a CAN DBC. The CAN-IDS function comes into play when a message is received that is not defined in the CAN DBC or when the signals fall outside the specified range. It is also utilized when the length of the actual message received differs from the DLC defined in the DBC or exceeds the defined cycle.   Expanding on this functionality, the CAN-IDS can detect as abnormal conditions if it exceeds the defined range which the bus load of the CAN network defined and gets overloaded or if signals that should change gradually, such as RPM or vehicle speed, exhibit rapid and irregular changes. However, it's important to clarify that the gateway primarily detects and reports abnormal behavior rather than immediately implementing defense mechanisms. This is because vehicles operate on a broadcast CAN network, making it exceedingly challenging to identify the specific controller responsible for an abnormal operation. Attempting to immediately control the problematic controller can be hazardous during driving. Therefore, the current approach involves detecting abnormal behavior, reporting it to the server, and subsequently addressing the issue through software modifications and updates to ensure safety.   Last is the 'detection of unauthorized software.' As previously discussed UN Regulation 155, we will now introduce UN Regulation 156, known as the Software Update Management System (SUMS). The gateway plays a vital role in maintaining vehicle security by guaranteeing that only safe and authorized software updates are applied and operated. This is achieved through a database that manages software and hardware versions, compatibility information, and other relevant data, which is linked to vehicle type certification and referred to as RxSWIN for all controllers within the vehicle. UN R156 requirements:   · 7.1 : Identify hardware and software versions and component information and check software integrity · 7.2 : Identify software (RxSWIN) related to Vehicle Type Approval (VTA) and check update compatibility; · 7.2.1.1 : Protect and prevent damage of the authenticity and integrity of software updates, and prevent invalid updates · 7.2.2 : Ensure safe execution of updates and demonstrate that vehicle users are aware of updates.   The gateway plays a crucial role in ensuring that only software specified in the RxSWIN DB can be updated. It also verifies the integrity of the software to guarantee secure execution during the updating process, utilizing methods such as Secure Flash. ​   FESCARO has proven outstanding capabilities in key management systems (KMS), security control systems, and security gateway controllers. For key management systems, we have provided security asset injection solutions to OEMs and Tiers. Additionally, we have developed and maintained security control systems for leading global automakers and commercial vehicle manufacturers. FESCARO's security gateway controller, encompassing development on both software and hardware, is employed in approximately seven vehicle models, including both passenger cars and commercial vehicles, recognizing for its reliability. ​   If you encounter challenges in meeting OEM cybersecurity requirements or face cybersecurity difficulties on production and post-production phase of controllers, please contact the FESCARO’s ‘Security Counseling Center'. Together, we can collaborate to identify and implement solutions to address your specific cybersecurity needs. ■ Webinar Reviews * Cheol Lee "I hope that more specific and honest webinars focusing on cases like this continues. I was impressed by the difference from other webinars." * Hoon Noh “I think FESCARO's guidelines are a good strategy to respond to OEMs. It was beneficial as I had no experience communicating with OEMs.” * Ki Song “The issues our company was concerned about were covered well, and it was especially helpful to my business as it was a Q&A related to practical work.” * Kyo Jeong "I was curious about the security control system for monitoring and incident response after mass production, and it was easy to understand with actual application examples." * Seok Go "I liked that it went beyond controller security, such as production lines and security control. There was a lot of new content that couldn't be found anywhere else." * Mi Seung "It was good that production and post-production responses were also covered, and that the issues tiers were concerned about were explained from the OEM's perspective." * Cheol Kang "The talk format was refreshing. It was interesting to hear things I was curious about before but found it difficult to ask questions about openly." * Jun Lee "The TALK with the host and panelists was outstanding. I would like to hear about the cybersecurity system and preparations for SDV in future webinars."

[Series] FESCARO's Automotive Cybersecurity FAQs ​ FESCARO has been operating the ‘FAQs Series’ to address cybersecurity issues for stakeholders in the automotive industry. We have conducted live webinars on four key topics, and the expert panel from FESCARO provided answers to the most commonly asked questions from industry professionals. If you missed a webinar on a topic that interests you, you can access both the recorded video and a text summary (FAQs) at the following link.   # FAQs Series 1. Cybersecurity Strategies for Tiers (Emerging-OEMs oriented) 2. Comprehensive Guide on Cybersecurity Solutions & Engineering 3. Cybersecurity Testing method based on VTA Success Stories 4. ECU Cybersecurity guidance : From production to post-mass production 5. How Korea’s Motor Vehicle Management Act Amendment impacts OEMs and Tiers The webinar, <Cybersecurity Testing method based on VTA Success Stories>, hosted by FESCARO in September, ended successfully. We welcomed over 100 pre-registered attendees from about 60 companies to our webinar, which we prepared in response to consistent requests for security testing methods. Automakers request cybersecurity tests on ECUs and vehicles as part of the Vehicle Type Approval (VTA) process. They also expect controller developer companies to ensure a reliable level of cybersecurity. Have you wondered about the ins and outs of VTA cybersecurity testing Know-how? FESCARO's Red Team, with its proven success record, is here to provide clear insights. Let's dive in together. ■ FESCARO's Red Team has,   • Achieved VTA in collaboration with global automakers   • Conducted security tests on 150 controllers and actual vehicles, both in stationary and driving environments   • Designed and implemented over 100 test items and 200 test cases, and are in continuous development ■ QUESTION LIST ■ VIDEO Ver. ■ TEXT Ver.   1. Various types of automotive security tests                  Before diving into the diverse types of automotive security tests, let's first look at the necessity of security testing. As mandated by UN R155, an international automotive cybersecurity regulation, automakers are required to secure certifications for both the Cyber Security Management System (CSMS) and Vehicle Type Approval (VTA). Section 5 of UN R155 delineates the cybersecurity requirements vehicles should adhere to and outlines the evaluation criteria. Specifically, Section 5.1.2 mandates that any approval authority (AA) that performs approval or technical service provider (TS) that performs approval on its behalf shall verify by testing of a vehicle of the vehicle type that the vehicle manufacturer has implemented the cybersecurity measures they have documented.' While security testing can be directly conducted by the AA or TS, or in collaboration with automakers, it's more typical for AA or TS to review and assess the testing performed by the automakers. In the end, the AA, TS, and automakers are required to conduct security testing. The specific tests that need to be performed are outlined in ISO/SAE 21434, a standard for automotive cybersecurity engineering. The tests are generally categorized into functional testing, vulnerability scanning, fuzzing testing, and penetration testing.  Let's begin with functional testing. Functional testing might already be familiar to many Tier companies. Tiers typically receive and analyze security requirements from OEMs, subsequently integrate it into the design, and then embody it in the software or hardware of controllers. The essence of functional testing is to validate that these requirements have been properly implemented. Some automakers offer both design and evaluation specifications, and testing is performed according to the evaluation specifications. Moving on to vulnerability scanning. This test aims to detect any remaining known vulnerabilities in the controller's software or hardware. Given the prevalent use of open-source in controller SW development nowadays, this test becomes pivotal to ascertain that open-source vulnerabilities have been adequately addressed. The fuzzing test involves introducing random, undefined data, primarily targeting the vehicle's controller or its external interfaces. The purpose of this process is to discover potential flaws or vulnerabilities in either the software or hardware.  Lastly, penetration testing is a type of mock hacking. It seeks to evaluate the robustness of existing security measures by mimicking real-world hacking attempts against vehicles or controllers.  To secure a VTA in line with UN R155, one must demonstrate that vehicle cybersecurity has undergone rigorous validation via such tests. Now, you might wonder if all controllers need to undergo all four tests. Fortunately, the answer is no. ISO/SAE 21434 Annex E delineates specific testing approaches corresponding to each cybersecurity assurance level (CAL). Controllers classified under CAL 1 are required to undergo both functional testing and vulnerability scanning. For those under CAL 2, fuzzing testing is added to the mix. Meanwhile, controllers classified under CAL 3 and 4 must additionally undergo mock hacking. For reference, T2 refers to a more advanced testing technique. The specific CAL assigned is determined through a process called TARA (Threat Analysis and Risk Assessment), conducted at the controller level. 2. Are there any security tests that examiners check for VTA? During the VTA process, what do examiners prioritize? They focus on determining if the actual vehicles have undergone testing according to the cybersecurity validation process established by the automaker and whether every activity within this validation process is traceable. They also scrutinize the validity of the previously submitted documentary evidence. Moreover, when conducting on-site inspections, they ensure that the previously submitted test results align with the actual test outcomes. Let's take a closer look at the VTA requirements as stipulated by UN R155 and what examiners focus on. UN R155 states that automakers should perform appropriate and sufficient testing to verify the effectiveness of their cybersecurity measures. Throughout the VTA process, examiners check whether automakers have performed the tests properly by posing seven questions below. The regulation doesn't offer explicit guidelines. The above questions serve as a reference, created by FESCARO based on our firsthand experiences during the VTA certification process. For those pursuing VTA, it's advisable to be well-prepared for these questions.  3. Are there any dependencies between TARA and security tests? TARA (Threat Analysis and Risk Assessment) and security testing are closely related to each other. The TARA procedure in ISO/SAE 21434 is depicted in the above illustration. Notably, the processes in the blue box evaluate asset attack scenarios, attack path, and attack feasibility. Through these processes, the CAL (Cybersecurity Assurance Level) is decided by determining risk value with the target's threat. The expertise and experience in cybersecurity testing play pivotal roles in these processes. The steps of identifying threats, formulating scenarios, charting attack paths, and assessing feasibilities are grounded in hands-on experience rather than abstract concepts. In other words, only when various experiences are integrated into TARA, the comprehensive evaluation of potential cybersecurity threats to controllers and vehicles can be conducted. Furthermore, TARA is a significant benchmark in cybersecurity testing. TARA defines various assets within the controller and identifies potential security threats. Once threats are identified from TARA, security goals are derived, followed by attempts at implementing mitigation measures. The subsequent security tests ensure the system is safeguarded from these cybersecurity threats. By leveraging various test cases crafted based on the Red Team's experience, a variety of attacks are simulated to identify any other potential threats or vulnerabilities, ensuring comprehensive protection against cybersecurity threats. Essentially, since security testing benchmarks originate from TARA, performing both TARA and security tests within the same company results in enhanced synergy. FESCARO maintains distinct teams for TARA and security testing to ensure an objective approach. 4. Trends on Attack surface Modern vehicles are equipped with diverse communication capabilities, which means they present multiple potential attack surfaces. Let me explain this with some examples. Take, for instance, the RF/LF communication employed by a vehicle's smart key. It utilizes a rolling code as a protective measure against replay attacks. Through the vulnerability of a weakly designed/developed rolling code, attackers can sniff and replicate the victim's normal door lock/unlock signals and unlock the vehicle by bypassing the rolling code security features. If this rolling code is poorly designed or implemented, it can become a vulnerability. An attacker might be able to sniff and replicate the regular signals used to lock or unlock the vehicle, effectively sidestepping the rolling code's security protocols. Furthermore, if an attacker manages to enter the vehicle, it's possible to target the navigation system via the USB port. In such a scenario, malware could be introduced to extract sensitive personal data, such as contacts, call logs, and recent destinations, from the system. These attacks are entered through external access points. Yet, our studies have highlighted instances where intrusions were orchestrated from within the vehicle itself. In a particular case, an attacker accessed the vehicle's internal network by removing its bumper and connecting to the headlamp controller. By introducing a malicious message into this controller, the body control module was deceived into thinking the smart key was inside the vehicle. Consequently, the attacker was able to unlock the vehicle, start it, and drive, all without the actual smart key. This breach was feasible because both the headlamp and body control controllers operated on the same CAN bus. Lastly, Advanced Driver Assistance Systems (ADAS), which can be viewed as the early stage of autonomous driving, have controllers such as LIDAR/RADAR/CAMERA that also represent significant attack surfaces. If compromised, these can cause abnormal behavior during driving, endangering passengers. This aspect is of particular research interest to FESCARO. 5. Automotive password-hacking scenarios/techniques The following is an explanation based on what the FESCARO's Red Team actually has done. Initially, the team accessed the CAN network within an actual vehicle and sent random messages to the remote key controller using our own CAN tool. Their actions led to a Crash out in the airbag controller, triggered by a particular message. This resulted in an issue where the cockpit indicated it as an accident and caused the emergency lights to blink without stopping. Subsequently, the team successfully infiltrated the vehicle's system via WiFi. They managed to restart the navigation system and tampered with both the video and audio through a backdoor in the navigation system. This attack revealed a vulnerability that could allow an attacker to alter every navigation function, including the Drive mode and air conditioning settings. Regarding a standard controller that lacks security at the debug port, there's a possibility of extracting its internal firmware through this port. Should someone dissect this firmware and pinpoint, modify, and then update its operational logic, it could lead to the controller malfunctioning or becoming inoperable. Furthermore, the GPS data of a vehicle in motion can be manipulated to falsely show it's in a different location. This is a grave concern; for instance, if the GPS data of an autonomously driving vehicle is changed to suggest it's in a child safety zone, the vehicle might suddenly slow down to the set limit, risking an accident. By examining all attack surfaces on the vehicle, the team designs attack scenarios. Based on these scenarios, we then develop test items and formulate test cases.  6. How is the security test carried out? The security testing process encompasses five primary stages. The first stage involves gathering relevant data, which consists of details related to MCU and AP chipsets, pinout information, functionalities tied to controller input/output, and specifics of CAN messages. These details can be sourced from functional manuals, design specifications, chipset data sheets, and discussions with staffs in charge. The subsequent stage involves identifying both attack surfaces and vectors. Attack surfaces refer to the attack points of the target controller, while attack vectors describe the techniques or methods employed for the attack. For controllers that use MCUs, attack surfaces encompass debug interfaces like JTAG, UART, and USB. Communication channels such as CAN, Ethernet, Wi-Fi, NFC, Bluetooth, and RF also serve as attack surfaces. Additionally, data storage units, including flash memory or storages can also be attack surfaces. Attack vectors include sniffing to analyze communication data, MITM to intercept messages or signals after sniffing, spoofing to falsify intercepted information, and desoldering to extract firmware. Once the firmware is accessed, a common attack vector is the reverse engineering of the binary code to uncover vulnerabilities. The third stage involves crafting a test case. This primarily encompasses details about the controller, the objective of the test, the strategies and procedures for the attack, and information about potential vulnerabilities. Furthermore, we evaluate the attainment of the cybersecurity objectives by referencing the criteria set out in TARA (Threat Analysis and Risk Assessment) and mapping them to the test case. The fourth and fifth stages are where the actual attack is performed. The objective is to gain control over the controller. After gaining this control, the aim is to breach the vehicle's internal network by altering its firmware, embedding malicious scripts and backdoors, and initiating denial-of-service attacks to broaden the scope of the attack. 7. What should be conducted during security testing? Two primary tasks are essential. Firstly, we need to ensure a conducive environment for seamless testing. Two to three controllers to be tested, including spares, are required, and in this case, controllers with cybersecurity solutions applied are helpful for verification. Furthermore, providing specifications and manuals for the controller that can aid in discerning the harness connector information and controller relevant hardware information. Additionally, sharing the controller firmware binary and CAN DB information will help with quick and smooth testing. The following is a section on event response and recording of vulnerabilities discovered as a result of testing. This approach aligns with Section 8 (Continual cybersecurity activities) of ISO/SAE 21434. It's advisable to keep track of the details and history of identified vulnerabilities, conduct vulnerability analyses, create and disseminate response strategies, and oversee version management.  8. Difference between controller-based testing and actual vehicle testing Even if the same test case is used, testing individual controllers alone and testing them in an actual vehicle may produce different results. Often, a controller is designed to activate its features or function properly only when connected to a CAN network, receiving profile signals from other related controllers. In this case, when testing individual controllers alone, the proper checking of input/output signals and messages is unattainable, making testing within a real vehicle environment more effective.I'd like to particularly highlight the importance of testing based on actual vehicle driving. In the provided graph, the green solid line represents the engine speed (RPM) measured without any attack, while the orange dotted line represents the speed measured during an attack. Testing in a driving environment by injecting abnormal messages into PCAN might cause irregular shift timings, deviating from the reference engine speed and potentially compromising user safety. However, merely injecting an abnormal message in the IGN ‘ON’ state might only confirm a delay in CAN communication, without demonstrating the tangible effects seen in a driving test.Recently, FESCARO undertook a mock evaluation under diverse conditions in anticipation of a VTA evaluation demo for electric vehicles slated for mass production by an international automaker. During a driving test, injecting an abnormal message into the E-PT (electric powertrain) resulted in the vehicle halting and the accelerator pedal becoming unresponsive. This stark contrasted with a stationary test of the same attack, which only showed minor communication delays. After promptly sharing these findings with the OEM and the controller developer, followed by technical discussions and a software patch application, we verified that the issue had been addressed. This collaboration enabled us to successfully wrap up the VTA certification demonstration.The individual testing of a controller or an actual vehicle is valuable, but the greatest synergy is achieved when testing is conducted in a combined setting. Since outcomes might vary based on the test environment, it's beneficial to approach from a variety of perspectives. At FESCARO, our Red Team, comprised of white hat hackers, conducts cybersecurity testing that adheres to international standards and regulations for cybersecurity. Recently, in collaboration with a global automaker, we successfully consulted for achieving VTA certification. We have conducted security tests on 150 controllers and vehicles in both stationary and active driving conditions. With over 100 test items and 200 test cases, we are broadening our security testing horizons to encompass vehicle controllers and EV chargers.If you find it challenging to respond to the OEM's cybersecurity requirements, or if you have difficulty managing automotive cybersecurity testing experts or organizations, then a collaboration with FESCARO could be a good solution. ■ Webinar Reviews * Hoon Noh "It was a valuable time as there had been no webinars on VTA cases before. It was interesting since the details were difficult to experience unless OEM." * Taek Jeon "The practitioners, especially the mock hacker, explained the cases in detail and were very helpful, and it was beneficial to learn how TARA and mock hacking are combined." * Gyu Kim “Through this webinar, I became motivated to understand and learn about cybersecurity in depth.” * Ki Song “It was great because it was an opportunity to ask practical questions that were not easily asked anywhere else in various industries and receive answers from experts.” * Gook Jeong "I think it would be better if the questions in advance were covered in more detail, and if the explanation of the technical aspects and the mock hacking process were also more detailed." * Gyo Jeong "I was very interested in the topic because it was highly related to the work I was doing (CSMS), and it was a helpful webinar. I would like to participate in following webinars as well." * Jun Lee "The format of the experts' answers to the preliminary questions was efficient, and I think this type of format can become a culture unique to FESCARO." * Soo Lee “In the future, I think it would be a good idea to hold paid seminars or training on more in-depth topics that are difficult to cover through webinars.”

[Series] FESCARO's Automotive Cybersecurity FAQs ​ FESCARO has been operating the ‘FAQs Series’ to address cybersecurity issues for stakeholders in the automotive industry. We have conducted live webinars on four key topics, and the expert panel from FESCARO provided answers to the most commonly asked questions from industry professionals. If you missed a webinar on a topic that interests you, you can access both the recorded video and a text summary (FAQs) at the following link.   # FAQs Series 1. Cybersecurity Strategies for Tiers (Emerging-OEMs oriented) 2. Comprehensive Guide on Cybersecurity Solutions & Engineering 3. Cybersecurity Testing method based on VTA Success Stories 4. ECU Cybersecurity guidance : From production to post-mass production 5. How Korea’s Motor Vehicle Management Act Amendment impacts OEMs and Tiers The webinar, <Comprehensive Guide on Automotive Cybersecurity Solutions and Engineering> hosted by FESCARO on August, concluded successfully. We welcomed over 100 pre-registered attendees from 60 different companies. The significant interest in the webinar seemed to stem from its focus on pressing concerns regarding the implementation of cybersecurity solutions and engineering, grounded in real examples. The webinar tackled eight prominent concerns, consolidating frequently asked questions from Tier companies and queries received during pre-registration. To offer precise insights, we assembled a panel of experts, with an average experience of over 20 years. Why not delve into the insightful responses from CEO Hong Seok-min, an authority on automotive cybersecurity, Director Ku Seong-seo, a specialist in automotive software development, and Team Leader Yang Hee-guk, an expert in automotive engineering? ​ ■ QUESTIONS LIST ■ Video Ver. ■ Text Ver. 1. How should we analyze cybersecurity specifications that vary between OEMs? Cybersecurity response strategies can also be called as security solutions, security controls, or security requirements. These cybersecurity responses have two main purposes: ​ · Protecting the content itself · Protecting the systems for content handling ​ To help you understand, I will give you an example from Netflix. They also have a security response strategy, again from two perspectives. One is a strategy to protect the content itself that Netflix distributes over the Internet, for example, applying a DRM solution such as Widevine, and the other is to protect the player device that receives and plays the content from external attacks. ​ The same concept goes for the vehicle. That is, protecting data processed inside/outside the vehicle, such as CAN communication data and FW images of ECUs, and protecting electronic device ECUs that process such data. After all, all OEMs create security requirements and specifications from these two perspectives. Remembering this will help you analyze OEM requirements, composed of slightly different terms, phrases, and items. ​ For example, diagnostic requirements such as Secure Flash and Secure Access can be interpreted as measures to protect content, while requirements such as Secure Boot and Secure Debug can be seen as measures to protect the ECU itself. If you understand the purpose of each requirement in this way, you will also be able to gain more clarity on what response your ECU should take. So, it will be of great help in establishing a strategy to respond to security requirements.​ However, we often see companies struggling with difficulties since the security specifications distributed by OEMs are generally drafted without distinction of ECUs. That is why it is very important to first determine whether the requirements are suitable for the ECU that are being made, and then distinguish between what needs to be reflected and what does not need to, and confirm it through discussion with the OEM. In the end, such a process directly influences the duration of development, resource allocation, and material costs, so it is important to discuss with the OEM in advance. ​ If you remember the explanation so far, it may help you understand the OEM's requirements, but it is still very difficult to understand and respond to them properly. If you are unable to determine what the OEM's requirements are or how to respond to them, you can contact a group of security experts like FESCARO and make a more efficient response. ​ 2. Security level and functions of ECUs At FESCARO, we have worked hand in hand with OEMs to establish security levels and have also implemented various security features as requested by various OEMs. What we learned through this is that the criteria for determining security levels are slightly different for each OEM. However, we commonly refer to the method for distinguishing whether an ECU is related to cybersecurity as described in the ISO/SAE 21434 standard. ​ · Electrical and Electronic ECUs · Safety-related ECUs · ECUs to collect/process information (Related to driver, passenger, vehicle location, etc.) · Network-based ECUs (Whether it’s connected to the vehicle’s internal network or it has external communication contact points) ​ Security ECUs are classified based on the above criteria, and their security level is determined through a process called TARA (Threat Analysis and Risk Assessment). ​ ​ Then which ECUs will be given the highest security level? There may be deviations, but we will give our opinion from a broader perspective. • Highest security level: ECUs with a communication point that directly contacts the outside, such as an OBD port, Telematics, Wi-Fi, Bluetooth, and USB • Medium security level: ECUs that are directly connected to the vehicle's internal network and directly affect vehicle driving or safety • Lowest security level: ECUs that are directly connected to the vehicle's internal network but do not directly affect driving or safety The security features are determined based on both the security level and the functions inherent to the ECU. If we look at commonly applied functions, first of all, those related to diagnosis include Secure Assess, Secure Flash, and Secure Unlock. And security functions to protect the ECU system include Secure Boot, Secure Debug, Secure Storage, Runtime tuning protection, and Memory protection. HSM is sometimes required as a way to implement these functions. ​ If you need technical support and security solutions on whether the security level determined by the OEM matches the ECU and how to determine the level of security functions that should be applied accordingly, please feel free to contact FESCARO. ​3. Must change AUTOSAR or semiconductor chips when applying new cybersecurity to existing ECUs? This question is one of the most frequently asked questions over the past year. European regulations are scheduled to be applied to new vehicles from July 2022, and to all mass-produced vehicles from July 2024. This means that vehicles produced before July 2022 must be ready for cybersecurity regulations by July 2024. To achieve this, cybersecurity functions must be integrated into existing ECUs, but in cases where existing SW platforms (e.g. AUTOSAR, etc.) suppliers or semiconductor chip manufacturers do not support cybersecurity functions, there is no choice but to develop new cybersecurity functions. I believe that new development will be a challenge as it requires additional development time and costs. In this case, it would be a good idea to look for a security solution not from a SW platform provider or a semiconductor chip manufacturer, but from a company that has: • Independent security solution • Professional personnel and organizations involved in automobile security • Experience in porting solutions to various SW platforms and semiconductor chips ​ If you collaborate with a company that meets the above conditions, you will be able to apply new cybersecurity functions without changing the AUTOSAR solution or semiconductor chip. FESCARO has experience carrying out various projects not only with global SW platform providers but also with automotive semiconductor chip manufacturers. FESCARO's security solution allows for the integration of cybersecurity features directly into the existing ECUs. This approach diminishes the expenses associated with new development and significantly cuts down the time needed for both development and validation. 4. ​What security features do OEMs require? As mentioned earlier, OEMs' security requirements are divided into requirements to protect communication data inside/outside the ECU and requirements to protect the ECU itself. ​ ECU data protection requirements include Secure Assess and Secure Flash for diagnostic communication, and Secure On-Board Communication, LS security requirements for CAN/Ethernet communication. ECU protection requirements can be divided into two aspects: firmware tamper prevention and tamper detection. Firmware tamper prevention includes a Memory Protection function that protects MCU memory and a Secure Debug function that blocks external debugging interfaces, and ECUs with OS such as Linux have OS Hardening requirements, including access control functions such as DAC/MAC. Tamper detection has the requirements of Secure Boot function that is used to assess the integrity of the boot loader, and the Run-time Tuning Protection that checks the firmware's integrity as the ECU application operates. ​ In terms of cryptographic security technology, there are requirements for AES-128/256 encryption/decryption, message authentication codes such as AES-CMAC and SHA2 HASH, signature verification techniques such as RSA-based PKCSv1.5, v2.2, ECC-based ECDSA, X.509 certificate management, and random number generation methods based on NIST SP 800-90B and BSI AIS 31 standards. Especially in recent years, OEMs are demanding more secure technologies such as the Secure Flash function based on the ECDSA signature verification technique using an elliptic curve, and also the message-based Secure Access function that verifies the integrity of the diagnostic message itself, rather than a simple Seed & key authentication technique. 5. Is it possible to apply security solutions without HSM? To conclude, it is possible. Customers with ECUs without HSM may be wondering whether they should switch to a chip with an HSM hardware core. They must be worried about the additional development period and cost burden of changing the chip. The security solutions provided by FESCARO can be divided into four types, such as diagnostic security, SW specialized solution, HSM, and HSE solutions. ​ ​ The ‘diagnostic security solution’ provides Secure Access and Secure Flash functions essential for diagnostic communication even without HSM. The ‘SW specialized solution’ is a security solution that virtualizes the HSM hardware core in software, and provides security functions equivalent to HSM, although it has a lower level of security compared to HSM hardware solution. The ‘SW specialized solution’ supports AES-128 encryption/decryption, AES-CMAC, SHA2-HMAC message authentication code, RSA PKCS v1.5 and v2.2 Signature Verification, X.509 certificate management, NIST SP 800-90B based random number generation, and Secure Storage function using Data Flash and MPU functions in MCU. ​ If FESCARO's SW specialized solution is applied to an existing mass-produced vehicle's ECU without an HSM hardware core, it has the advantage of not having to change the existing ECU hardware, thereby dramatically reducing the development period and cost. 6. Deployment process of security solutions and its impact on the ECU The following diagram illustrates the general integration process of FESCARO's security solution. The ECU supplier has to initially consult with the OEM regarding the necessary security specifications and the security level to be implemented. Once the discussion is complete, FESCARO will develop a security solution based on the security specifications to be applied to the ECU and deliver it to the supplier. Integration procedures can be classified into two types depending on the type of security solution, such as a SW specialized solution, HSM/HSE solution. ‘Diagnostic security solution’ and ‘SW specialized solution’ require the use of hardware resources such as the Data Flash within the ECU's MCU, MPU, and timer, so there may be a HAL API that needs to be implemented by the ECU supplier. FESCARO provides detailed guide manuals and verification libraries required to implement the HAL API. Once the HAL API has been implemented and verified, you can implement OEM's requirements by utilizing the security solutions deployed such as the HSM and HSE solution integration procedures. FESCARO's security solutions provide only the necessary functions specialized for the OEM's security requirements, so we can help ECU suppliers more easily integrate security solutions and implement specifications. Moreover, we offer in-depth descriptions and use cases of security solution features in a guidebook, while also providing technical support at any time during development. Meanwhile, some people are worried that applying the security solution will affect the existing ECU functions. First, the ‘diagnostic security solution’ operates only in a special environment where diagnostic equipment such as UDS diagnostic communication and reprogram are connected, so it does not affect the basic operation of the ECU. In the case of the ‘ SW specialized solution’, designed for MCUs lacking a hardware security core, the security solution has to use HOST CPU together. It aims to minimally impact the ECU's basic operations. It has been tested and validated on over 70 different mass-produced ECU's MCUs, so you can think of it as a safe security solution. For MUCs equipped with a hardware security core like ‘HSM solution’ or ‘HSE solution’, the basic operation remains largely unchanged, with the exception of a slight boot time increase of around 10ms before the HOST boot loader launch due to the activation of the Secure Boot function. 7. Validation of security solutions and hackability after application No matter how robust our cybersecurity solution is, at the moment, no solution can guarantee 100% safety due to the constant evolution of hacking techniques. Many cybersecurity experts share the same view. UN R155 also emphasizes the need to set up an organizational and procedural framework to address cybersecurity incidents that might arise even after the vehicle has been released, and requires related certifications. This is known as CSMS(Cyber Security Management System) certification. ​ This does not mean that cybersecurity solutions can be created carelessly. The law states that ‘cybersecurity solutions must use encryption algorithm standards that are internationally recognized for their safety and that this fact must be proven.’ This includes various encryption algorithms detailed earlier. Fast HSM, one of FESCARO's security solutions, is trustworthy since it includes a security module that has obtained FIPS 140-2 certification issued by NIST, a U.S. national agency. Furthermore, we can attest to its reliability as it has been implemented in approximately 150 ECUs and is currently in mass production. Even if you apply such a reliable security solution to protect the ECU, security events may occur, so you need to continuously monitor them and prepare countermeasures. These monitoring activities should be carried out continuously. For this reason, it is usually necessary to introduce an operating system. We call this system SIEM (Security Information & Event Management) or SOC (Security Operation Center). ​FESCARO has provided automotive OEMs with an operating system that streamlines a range of security-related processes. Consequently, it has contributed to obtaining certifications like CSMS in line with UN R155, SUMS in line with UN R156, and VTA. It is expected that not just OEMs, but also Tier companies are increasingly being asked to implement systems that can efficiently manage and handle these security incidents. It would be better for you to solve this problem with FESCARO rather than worrying about it alone. ​ 8. Security management after mass production of cybersecurity functions ​ It is essential to implement and operate a security management system that is closely connected with both customers and suppliers. To explain in more detail, we gather information related to cybersecurity, and through this, we identify if any security incidents have taken place. Security incidents that have been identified are assessed based on the vulnerability management process. In the vulnerability management process, the TARA methodology is employed to scrutinize identified security vulnerabilities, gauge the associated risks, and devise appropriate counteractions. Also, it tracks and manages the remediation of identified vulnerabilities throughout the entire life cycle of the vehicle. For security incidents evaluated using this approach, corrective actions will be implemented in line with the incident response procedure. Steps such as crafting an incident response plan and updating security patches will be undertaken. Currently, FESCARO is working with a passenger vehicle manufacturer to build and consistently manage a cybersecurity monitoring and incident response IT system for 7 vehicle models. Additionally, we are partnering with a commercial truck producer to create a cybersecurity monitoring and incident response IT system for 2 truck models. FESCARO has secured the reliability of the security solution itself, but also has an ‘IT management system’ as above. Through this, we can confidently offer maintenance such as ongoing security monitoring and timely security patch. ​ ​ FESCARO’s specialized security solution analyzed ECUs in a total of 7 vehicles, including internal combustion engine vehicles and electric vehicles, and mass-produced security solutions for more than 150 ECUs among those vehicles. The security solution is compatible with over 70 models in 10 leading semiconductor manufacturers worldwide. Moreover, FESCARO maintains close collaborations with global AUTOSAR providers like Vector, ETAS, and Elektrobit. FESCARO collaborates with multiple semiconductor producers and international AUTOSAR vendors, and is renowned for its expertise specialized in automotive engineering. ​ If you find it difficult to respond directly to OEM's security requirements, or if you are experiencing difficulties in managing automotive cybersecurity related professional workforce and organizations, collaborating with FESCARO might be a solution. ■ Webinar Reviews *Hoon Noh “I was able to receive a lot of inspiration from the panelists sharing their diverse and professional experiences.” * Jun Lee “I liked the format in which questions were asked in advance and answers were prepared and explained, and the detailed explanations given by experts in each field were very helpful.” * Ki Song “It was a webinar that was very helpful in practice, focusing on questions and answers.” * Il Choi “I was impressed by the message to analyze from the perspective of understanding the purpose of the requirements, and it was good to know the security function information required by OEMs.” * Mi Seung "I often felt confused and frustrated since I didn't have much information while working on cybersecurity, but I was able to learn a lot through the seminar and resolve the problem." * Geun Lee "I received a lot of help in areas I was unfamiliar with, such as the purpose and background of cybersecurity response, the ability to apply security solutions without HSM, and OEM requirements." * Tak Kim “It was a great opportunity where I could redefine facts I was usually confused about.” * Yong Lee “Thank you for your kind answers to the questions I asked during QnA. It was a useful time to understand the current state of the industry and cybersecurity.”

[Series] FESCARO's Automotive Cybersecurity FAQs ​ FESCARO has been operating the ‘FAQs Series’ to address cybersecurity issues for stakeholders in the automotive industry. We have conducted live webinars on four key topics, and the expert panel from FESCARO provided answers to the most commonly asked questions from industry professionals. If you missed a webinar on a topic that interests you, you can access both the recorded video and a text summary (FAQs) at the following link.   # FAQs Series 1. Cybersecurity Strategies for Tiers (Emerging-OEMs oriented) 2. Comprehensive Guide on Cybersecurity Solutions & Engineering 3. Cybersecurity Testing method based on VTA Success Stories 4. ECU Cybersecurity guidance : From production to post-mass production 5. How Korea’s Motor Vehicle Management Act Amendment impacts OEMs and Tiers The very first of webinar, <Cybersecurity Strategies 'TALK' (Emerging-OEMs oriented)> launched successfully on February! The response was amazing! We had about 100 participants from approximately 30 different companies pre-register for the event. We have received questions from Tier companies in advance, and also those during pre-registration. We've covered a total of 7 most common concerns today. FESCARO's experts with an average of 20 years or more of experience provided clear and insightful advice. Let's dive in and discover the valuable insights from     • CEO Hong Seok-min, an expert in automotive cybersecurity,   • Director Ku Seong-seo, an automotive software development expert,   • Team leader Choi Kwang-mook, cybersecurity consulting leader specializing in automotive security certification. ■ QUESTIONS LIST ■ Video Ver. ■ Text Ver. 1. What cybersecurity do OEMs require from tiers? The cybersecurity-related requests that both domestic and global OEMs ask to Tier companies include the following items. (Some items might vary based on each specific OEM's requirements)   · Item (ECU) level TARA · Cybersecurity engineering (applied with security solutions, verified by security testing) · Organizations and processes related to cybersecurity · CIA (Cybersecurity Interface Agreement)   In most cases, OEMs carry out TARA (Threat Analysis and Risk Assessment) at the actual vehicle level and determine cybersecurity goals and requirements for individual items beforehand. For OEMs that place a strong emphasis on cybersecurity, there are instances where they ask tiers to conduct TARA at the ECU level.  To meet security requirements, Tiers need to create various security applications like Secure Boot and Secure Flash for the ECU.  Additionally, security testing is crucial to ensure that the OEM's security requirements are effectively met through these applications.   For successful engineering activities such as cybersecurity development, verification, and operation, Tiers must establish internal cybersecurity-related teams and processes that align with business objectives.  The prerequisite for this is to engage in R&R discussions and finalize contracts for cybersecurity tasks between OEM and Tier, known as the Cybersecurity Interface Agreement (CIA).   However, sometimes OEM requirements can be hard to understand or vague. In such situations, it's best to interpret them in a way that benefits the Tier the most while still meeting the basic criteria for OEMs to achieve UN R155 certification. Therefore, initiating discussions with OEMs about cybersecurity tasks right at the project's start is crucial.  The cybersecurity manager, often responsible for this, should negotiate to benefit the Tier while meeting the minimum requirements for OEM certification. This involves negotiating properly with the OEM's representative to optimize the reuse of existing materials. To do a good job as a cybersecurity manager, complete understanding about the process of acquiring the UN R155 certification for OEM is required. To summarize, both OEMs and tiers need to establish cybersecurity-related teams and processes. Moreover, they determine cybersecurity goals and requirements through TARA activities conducted on the vehicle level, system level, and the ECU level for the specific vehicle type undergoing certification.   To ensure compliance with cybersecurity requirements, OEMs create and share precise design and validation specifications related to cybersecurity engineering with Tiers. Since these specifications are general and intended for multiple OEMs, it's often challenging to address all the unique aspects of ECUs, the specific features of new cars, and the individual characteristics of different tiers. To bridge this gap, OEMs engage in coordination and discussions with each tier. Using the outcomes of these discussions, they then move forward with the cybersecurity engineering process, ultimately leading to the Start of Production (SOP) phase.   Following the SOP, the process undergoes operational stages, including cybersecurity threat monitoring and incident response, until its scrapping(end of support). In terms of the aspects discussed earlier, the CIA plays a crucial role in defining R&R and completing the contract between the OEM and tier. To put it simply, the main approach of CIA is to maximize the reuse of existing components while ensuring the core requirements needed for the OEM's certification.     2. Do OEMs not perform TARA? Tiers also require TARA performance. Many people might think that TARA is done only once during the concept phase. However, TARA is utilized not only during the conceptual stage but also throughout the development and post-development phases. This is due to the fact that cybersecurity risks can emerge at any point during a vehicle's lifecycle.  When facing a cybersecurity incident, it's crucial to thoroughly analyze the cybersecurity threat and evaluate the associated risk. TARA represents a cybersecurity risk management approach. It classifies whether an immediate response is necessary, whether the task should be addressed promptly, whether collaboration with others is needed for a delayed response, and the appropriate level of security measures required.  As previously stated, TARA is a continuous process that must be carried out across the entirety of the project's life cycle, extending beyond the initial conceptual stage. Hence, it becomes an essential aspect that should be ingrained within the tier's internal operations.   3. Where should I begin with CSMS? From the tier's point of view, there are two ways to approach CSMS response. The first involves setting up a cybersecurity management system in accordance with the ISO/SAE 21434 standard. The second pertains to establishing a dedicated system for effectively addressing the Cybersecurity Interface Agreement (CIA) between the OEM and Tier.   The fulfillment of both aspects can be achieved through the establishment of a cybersecurity management system that aligns with the ISO/SAE 21434 standard. Setting up an appropriate cybersecurity management system encompasses the following measures:   · Drafting guidelines for handling the CIA signing process between OEM and Tier, which encompasses the cybersecurity interface agreement process. · Establishing a comprehensive cybersecurity management system along with corresponding rules, including the cybersecurity organization. · Developing guidelines for conducting cybersecurity Threat Analysis and Risk Assessment (TARA) activities. · Defining procedures for integrating and verifying OEM’s cybersecurity requirements. · Creating guidelines for the application of cybersecurity principles within production processes. · Creating a system that actively monitors cybersecurity-related information and events, while also conducting analysis and management of identified vulnerabilities. · Formulating guidelines for the appropriate response in the event of a cybersecurity incident.   By implementing this cybersecurity management system, you will be well-equipped to address a multitude of requirements coming from OEMs in the field of cybersecurity. Building a cybersecurity management system in accordance with ISO/SAE 21434 can be challenging, as knowing where to begin and how to proceed might not be straightforward. In practice, achieving this without expert guidance, such as professional consulting, can be daunting. Therefore, both OEMs and many tiers often seek assistance from specialized companies like us to navigate this complex process effectively. Ultimately, however, it is necessary to internalize this cybersecurity management system. From a professional consulting perspective, the process of establishing a cybersecurity management system can be categorized into three distinct stages. First, the consulting service conducts a gap analysis aimed at designing and constructing a cybersecurity management system tailored to the organization's existing circumstances.   Second, a cybersecurity internalization project is chosen, and the consulting service guides the organization through the process of project implementation in accordance with the established procedures. We assist in planning and setting up teams for projects related to cybersecurity response, help with the CIA contract signing process, and provide support for the TARA process. TARA experts are dispatched when necessary. We also support designing, applying, and validating security solutions during product development. The red team will be put in if necessary. Also, we provide help for ensuring security during production, and assist in monitoring events, and managing vulnerabilities throughout the entire life cycle of the vehicle.   Thirdly, ISO/SAE 21434 mandates cybersecurity audits and project assessments, and we back up this process. Addressing process audits for each project places a significant burden on development and quality teams. To counter this challenge, obtaining a dependable CSMS certification can enhance productivity significantly.     4. I want to reuse the results of previous projects in new projects. The extent of work for cybersecurity deliverables is established via the Cybersecurity Interface Agreement (CIA) established between the OEM and Tier.  Every output mentioned in the CIA can be categorized into either reusing an existing output or generating a new one.   The decision to reuse these artifacts should be made after thoroughly examining the item definition and cybersecurity specifications. When conducting an item definition review, it's important to pinpoint any alterations in item functionality, security assets, or modifications to the operating environment. Similarly, during a cybersecurity specification review, the focus should be on recognizing any shifts in security requirements or security controls. To facilitate the process of output reuse, CIA outputs can be conveniently organized and categorized as follows. The majority of cybersecurity "process" outputs are mostly suitable for reuse, whereas "management" outputs demand guided adjustments. "TARA and Verification" outputs can be reused, but it's important to factor in any modifications in cybersecurity specifications, the operating environment, and related threat scenarios or vulnerabilities. "Cybersecurity development" outputs are generally reusable, although changes to the cybersecurity specifications need consideration. In essence, with the exception of chapters 9, 10, and 11, a substantial portion of the outputs can be readily reused.   It's essential to conduct a reuse analysis specifically for the deliverables of chapters 9, 10, and 11. For example, if it’s decided to add new cybersecurity features, that means changes to the security functions in the product is necessary. And not only that, verification testcase also needs to be modified. Here's another example, even if the product specifications do not change, if the environment it's used in changes, additional TARA process is needed. Also, when we bring in an external connection, we have to include more security measures. And if the vehicle protection model changes, it affects how we assess security risks. In simple terms, based on the reuse analysis results, we can decide whether to change specifications or design.   5. How should I manage security vulnerabilities? When it comes to cybersecurity vulnerability management, there are two important aspects to consider. First, it's important to handle security vulnerabilities from the development phase to SOP, and throughout the entire life cycle after SOP. Second, we need to take care of vulnerabilities found in different sources. When it comes to cybersecurity, it's crucial to know that security breaches can happen even after the SOP (Start Of Production), when the product development is completed. This is because the development of hacking technology from hackers are faster than the development of security solutions.   So, whenever there's a security breach or a cybersecurity incident, we have to develop, verify and distribute the security measures, and this has to be repeated throughout the whole life cycle of the vehicle. Normally, when SOP duration is 5 years and the warranty covers 10 years, it will be a total of around 15 years, and in reality, it might even be closer to 20 years. But the current security technology cannot withstand throughout the whole period. That is why it's important to conduct ISO/SAE 21434 Chapter 8 ‘Ongoing cybersecurity activities. Let's see with specific examples.  This screen is an example of a vulnerability management ledger. The sources where vulnerabilities emerge are varied as in the picture. There can be vulnerabilities from cybersecurity information and event monitoring, risk list from TARA, vulnerabilities emerged from project development/verification, security breaches from the field after SOP. Just like in this example, it's important to keep a record of vulnerabilities for each project. This is because as mentioned earlier, the vulnerabilities have to be handled according to the specific project's traits. And the cybersecurity tasks need to follow the rules in Chapter 8 of ISO/SAE 21434, which is the 'Guidelines for Ongoing Cybersecurity Activities’. [ ISO/SAE 21434 Chapter 8 'Guidelines for Ongoing Cybersecurity Activities' ] · Implement/record of cybersecurity information and event monitoring · Evaluate whether an identified event is a security weakness · Check through TARA if the weakness could be a vulnerability in the project · Vulnerability management throughout the product life cycle   To internalize the management of cybersecurity vulnerabilities, it is a best practice to build and operate SIEMS (Security Information and Event Management System) system. With this system, it is possible to manage the entire cybersecurity issues and the current situation comprehensively. 6. Every meeting with OEMs leads to more follow-up work due to a lack of cybersecurity knowledge. We often come across this question when we communicate with ECU manufacturers, and it's a challenge we've faced a lot. We've covered a similar kind of response strategy earlier, and to handle the different requests from OEMs effectively, it's crucial to have standardized and strategic response processes. · Tailoring security requirements according to product characteristics · Minimizing modifications due to changes in OEM's needs by creating outputs following international standards   In general, OEMs have certain standard requirements for cybersecurity features. However, these requirements are usually a superset. Since the features of each ECUs are different, it is hard to apply in entirely. It's important to really understand what OEMs are requesting and identify what is capable of what is not. If there are things not possible to do, showing different options or explaining why it's not possible is required. And if it's needed, suggesting plans for what to do next is necessary.   OEMs will take the information provided by these ECU manufacturers to get the type certification. When we look at it from the perspective of the CIA (Cybersecurity Interface Agreement), it's tough for the ECU manufacturers to respond since each OEM's product requirements are different. To work around these challenges, It must be written based on the ISO/SAE 21434 standard and sufficiently explained that it satisfies the international standards to minimize repetition or modification of work.   But the real challenge is that a lot of ECU manufacturers don't have a dedicated cybersecurity team, which makes it tough to handle the tasks. The more you discuss with OEMs, the more confusion tends to arise, making the workload even heavier. To tackle these issues, having experts with specialized security skills would be a great help. Companies like FESCARO could be an alternative.   FESCARO currently offers CSMS consulting, security solutions, and security testing services for local OEMs. We are well-versed in what ECU manufacturers have to do in order for OEMs to achieve the UN R155 certification, and have a track record of assisting multiple ECU manufacturers with CSMS consulting, cybersecurity manager responses, security solutions, and engineering services. We are here to provide a clear guide for you to navigate these tasks effectively.   7. Are cybersecurity certifications required for tiers? In simple terms, no. To clarify, the certification is only required for car manufacturers. UN R155 states that CSMS certification must be obtained by car manufacturers. However in CSMS, it is required to manage the cybersecurity activities of the ECU manufacturers as well.   The detailed process for this is explained in Chapter 7, 'Distributed Cybersecurity Activities,' of ISO/SAE 21434. The OEM verifies if the ECU manufacturer has established CSMS by using the CIA (Cybersecurity Interface Agreement). Even though the ECU manufacturers don't directly have to get certified, it's required to create CSMS as per the OEM's requirements. Certain ECU manufacturers might even earn CSMS certification through a certification body like TS (Technical Service) and get the ISO/SAE 21434 certification.   This certification offers the reassurance that the company is well-prepared for cybersecurity, giving you an advantage when pursuing different projects or new projects with OEMs. Certification bodies currently lack formal certification qualifications or auditor qualifications. Because of this, organizations like TS are taking on the role of UN R155 certifications and carrying out ISO/SAE 21434 certifications for tiers.   FESCARO is working in collaboration with several TS companies, and there have been instances where ECU manufacturers that we have consulted achieved ISO/SAE 21434 certification. Drawing from this collaborative partnership and the experience gained, FESCARO is dedicated to providing comprehensive support to ECU manufacturers, ensuring them to successfully attain certification.   FESCARO has secured CSMS certification from OEMs and ISO/SAE 21434 certification from Tiers. Our expertise encompasses cybersecurity consulting and engineering services for a wide range of ECU used in both internal combustion engine vehicles and electric vehicles.