Vehicle risk management procedures and servers for them

Abstract

In a vehicle risk management process performed by a server, the process may include: identifying a predicted threat scenario by analyzing a variety of the vehicle's plant elements, deriving an impact scenario according to the predicted threat scenario and deriving an attack path based on the impact scenario, and setting a vehicle hazard mitigation target based on the attack path and the predicted threat scenario.

Description

CROSS-REFERENCE TO A RELATED REGISTRATION

[0001] This application claims the benefits of Korean patent applications No. 10-2024-0180767, filed on December 6, 2024, and 10-2025-0187545, filed on December 1, 2025, with the Korean Intellectual Property Office, the disclosure of which is incorporated herein by reference. BACKGROUND 1. Technical field

[0002] The present invention relates to a vehicle risk management method and a server for carrying out the same. 2. Description of the state of the art

[0003] Among the various sectors of the automotive industry, electrical and electronic systems have been the most innovative and rapidly evolving since the 2000s. In particular, control devices that regulate vehicle behavior have significantly contributed to road safety, enabling more stable driving through more precise control made possible by advancements in semiconductors and embedded software. Furthermore, the marketability of vehicles has been enhanced by the provision of comfort features for drivers. Beyond controlling engines and brakes, vehicles today feature smart keys, navigation systems, and various infotainment systems. Consequently, multiple control devices within a vehicle communicate and exchange information via the onboard network.

[0004] In parallel with these advances, the complexity of vehicle systems and the importance of safety continue to increase, but dangerous accidents are repeatedly reported that are caused by compound failures of electrical and electronic components designed to ensure the invisibility and availability of the software.

[0005] With the increasing robustness of individual vehicle control devices and advances in communication technology, cooperative control between vehicle control devices has rapidly evolved, and with the further development of infotainment systems, the exposure of the systems to potential threats has also increased.

[0006] To prevent such threats, the cybersecurity standard ISO / SAE 21434 was introduced. ISO / SAE 21434 is closely based on ISO 26262, which is one of its successful predecessors, significantly contributing to its rapid adoption.

[0007] ISO / SAE 21434 is an international standard that deals with the cybersecurity of vehicles and defines security requirements and development processes to protect a vehicle's electronic systems from external attacks.

[0008] ISO / SAE 21434 requires a comprehensive cybersecurity management framework that includes the analysis of threat mitigation risks to vehicles, risk assessment, security design, and the development of response plans. For example, ISO / SAE 21434 requires the identification and assessment of threats at the vehicle and component levels, such as systems, software, and hardware (also referred to as elements), in order to respond to external cyberattacks. In other words, it requires conducting a threat analysis and risk assessment (TARA).

[0009] With the establishment of these standards, compliance has become an essential requirement throughout the automotive industry. Accordingly, companies manage functional safety and cybersecurity activities separately to fulfill the specific tasks required by each standard.

[0010] Particularly in the area of ​​cybersecurity, some companies have dedicated departments to respond quickly to newly established European regulations. Furthermore, the distribution of requirements for vehicle development is carried out by various parties at different times.

[0011] Because ISO 26262 and ISO / SAE 21434 differ in their requirements and approaches, companies traditionally manage HARA and TARA separately to perform specific work for each international standard.

[0012] Although more and more companies are developing and marketing special software tools for TARA, most people still create and manage TARA using Excel forms.

[0013] Regardless of TARA, creating a Fail-Safe Management Document (FSM) for a vehicle is often necessary, depending on the needs of a company or its customers. The FSM document is a resource that organizes detection and response strategies for various product failures and summarizes aspects related to elements that can affect the product, such as failures of internal components and failures of external interfaces. DEMOLITION

[0014] The problem to be solved by the present invention is to provide a vehicle risk management method and a server for the same, which can integrate a threat analysis and risk assessment (TARA), a fail-safe management (FSM), and basic information of the vehicle system, including interfaces and architectures of a project.

[0015] The object of the present invention is to provide a method for vehicle risk management and a server for it, which provide a software tool to support the implementation of the TARA method.

[0016] The object to be solved by the present invention is to provide a vehicle risk management method and a server for it that improve the integrated management and reusability of data generated and used during the TARA analysis process and manage common data required for the analysis of hazard mitigation threats in a standardized format.

[0017] The object to be solved by the present invention is to provide a vehicle risk management method and a server for the same, which automatically output TARA results as different types of reports or documents depending on their intended use.

[0018] The object to be solved by the present invention is to provide a vehicle risk management method and a server for the same which can output results in a format required by an OEM for a DTC (Diagnostic Trouble Code) related analysis, such as GMRDB or in an OEM-specific TARA template based on an integrated database.

[0019] According to one aspect of the disclosed invention, a method for vehicle risk management can include the analysis of a multitude of system elements of the vehicle to identify a predicted threat scenario, the derivation of an impact scenario corresponding to the predicted threat scenario, the derivation of an attack path based on the impact scenario, and the determination of a hazard mitigation target of the vehicle based on the attack path and the predicted threat scenario.

[0020] The multitude of system elements can include a system to be protected, a function of the system, and a property of the system, and the function of the system corresponds to the function of the vehicle, and a safety risk caused by a malfunction of the function of the vehicle corresponds to a hazard prevention risk caused by an impairment of the function of the system.

[0021] The impact scenario is generated by deriving a damage scenario according to the multitude of system elements and simulating the influence of the damage scenario on a driver or the vehicle.

[0022] The attack path is determined based on an impact assessment, which is determined according to at least one security element, one financial element, one operational element and one data protection element for the impact scenario.

[0023] The safety element can be derived from a safety level, and the safety level can be determined by assessing exposure, severity, and controllability of the hazardous situation according to a predetermined assessment criterion and combining the assessment results of exposure, severity, and controllability.

[0024] The threat prevention objective can be generated based on a risk value according to the attack path and the predicted threat scenario.

[0025] Based on the hazard prevention objective, a hazard prevention control measure and an alternative hazard prevention measure can be determined to fulfill a condition of a safe state.

[0026] The procedure may further include setting the diagnostic control logic to achieve the vehicle's hazard mitigation objective, wherein setting the diagnostic control logic includes: defining a hazard mitigation threat state of the vehicle and setting parameters used to determine the hazard mitigation threat, the parameters being stored in a database, and deriving diagnostic information and response-related information associated with the vehicle's hazard mitigation threat based on the parameters, and storing the diagnostic information and response-related information in the database for use as input data for threat assessment.

[0027] For the same or a similar predicted threat scenario, the results of the application of the diagnostic control logic are compared with each other in order to link or manage them in the database.

[0028] As a technical means of achieving the aforementioned technical objectives, a computer program according to one aspect of the present invention can be stored in a medium so that the program can be executed by a computer device to carry out the vehicle risk management method described above.

[0029] A server according to one aspect of the disclosed invention can include a database configured to store a variety of data for vehicle risk management, a communication module configured to communicate with an external device, and a processor electrically or communicatively connected to the database and the communication module, wherein the processor is configured to analyze a variety of system elements of the vehicle in order to identify a predicted threat scenario, derive an impact scenario according to the predicted threat scenario, derive an attack path based on the impact scenario, and determine a hazard mitigation target of the vehicle based on the attack path and the predicted threat scenario.

[0030] The multiple system elements can include a system to be protected, a function of the system and a property of the system, whereby the function of the system can correspond to a function of the vehicle and a safety risk caused by a malfunction of the function of the vehicle can correspond to a hazard prevention risk caused by the impairment of the function of the system.

[0031] The impact scenario is generated by deriving a damage scenario according to the multitude of system elements and simulating the influence of the damage scenario on a driver or the vehicle.

[0032] The attack path can be determined according to an impact assessment, which is based on at least one security element, one financial element, one operational element and one data protection element for the impact scenario.

[0033] The safety element can be derived from a safety level, and the safety level can be determined by assessing the exposure, severity, and controllability of a hazardous situation according to predetermined assessment criteria and combining the results of the assessment of exposure, severity, and controllability.

[0034] The threat prevention objective can be generated based on a risk value according to the attack path and the predicted threat scenario.

[0035] The processor can be configured to determine hazard control measures and alternative hazard control measures to satisfy a safe state condition based on the hazard control objective.

[0036] The processor can be configured to set a diagnostic control logic to achieve the vehicle's hazard prevention objective, define a condition for the vehicle's hazard prevention threats, set parameters used to determine the hazard prevention threat and store the parameters in the database, and derive diagnostic and response-related information associated with the vehicle's hazard prevention threat based on the parameters and store the diagnostic and response-related information in the database for use as input data for hazard prevention assessment, thereby setting the diagnostic control logic.

[0037] The processor can be configured to compare the results of the application of the diagnostic control logic for identical or similar predicted threat scenarios in order to link or manage them in the database.

[0038] Certain embodiments of the present invention aim to address, mitigate, or at least partially solve at least one of the problems and / or disadvantages associated with the prior art. Certain embodiments are intended to offer at least one of the advantages described below.

[0039] According to one aspect of the present invention, a vehicle risk management method and a server for the same perform a threat analysis and risk assessment (TARA) method, thereby enabling safety-related risks to be managed in a more systematic and efficient manner.

[0040] Furthermore, according to the present invention, a software tool that supports the execution of the TARA procedure automates a series of processes, including threat identification, the derivation of hazardous events, the setting of hazard mitigation objectives, and the determination of the risk level. Moreover, the consistency and reliability of the TARA results can be ensured by sharing fundamental information such as DTC information and the vehicle architecture.

[0041] According to the present invention, the common data generated within the TARA process are managed in a standardized integrated database format, thereby improving the reusability and traceability of the data required for the analysis of hazard mitigation threats.

[0042] According to the present invention, TARA result data can be output in different templates depending on the intended use, thereby enabling the creation of result reports that include hazard control objectives, hazardous events and safety mechanisms. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] These and / or other aspects of the revelation will become clearer and more easily understood from the following description of the exemplary embodiments in conjunction with the accompanying drawings: Fig. Figure 1 is a representation showing a vehicle risk management system according to one embodiment; Fig. Figure 2 is a representation that depicts a step-by-step analysis procedure and a relationship diagram of hazard mitigation threats according to one embodiment; Fig. Figure 3 is a representation for displaying threat prevention data according to the embodiment of Fig. 2; Fig. 4 is a block diagram of a vehicle risk management system according to one embodiment; Fig. 5 is a flowchart representing a control operation of a server according to one embodiment; and Fig. Figure 6 is a flowchart illustrating a control procedure of a server to achieve a hazard prevention objective of a vehicle according to one embodiment. DETAILED DESCRIPTION

[0044] Throughout the patent application, the same reference numerals refer to the same components. The description does not detail every element of the embodiments, and general or overlapping content within the technical scope of the disclosed invention is omitted. The terms "unit, module, element, block" used in the specification may be implemented in software or hardware. Depending on the embodiment, several "units, modules, elements, blocks" may be implemented as a single component, or a "unit, module, element, block" may comprise several components.

[0045] When, in this description, one part is referred to as being “connected” to another part, this includes not only cases where they are directly connected, but also cases where they are indirectly connected, with the indirect connection including connection via a wireless communication network.

[0046] When a part is described as “inclusive” of an element, this means that, unless explicitly stated otherwise, the part may contain additional elements rather than excluding other elements.

[0047] When the description refers to an element that is "on" another element, this refers not only to cases where the element is in contact with the other element, but also to cases where another element is located between the two.

[0048] The terms "first", "second", etc. are only used to distinguish the individual components and do not restrict the components.

[0049] Singular expressions include plural forms unless the context clearly indicates otherwise.

[0050] The numbers for the individual steps are for ease of description and do not indicate the order of the steps. Unless the context explicitly prescribes a specific order, the steps can also be performed in a different order than described.

[0051] TARA primarily analyzes threat prevention in the field of cybersecurity, focusing on attack paths and external interfaces, while HARA focuses on system malfunctions and their impact on security.

[0052] The most important result, which is generally required as preliminary work in both TARA and HARA, is the element definition. This document defines the functional and physical properties of the system to be analyzed and the boundary conditions of the vehicle system and can be used as an essential basis for carrying out TARA and HARA.

[0053] The primary components of the element definition can include a definition of the element's boundaries, the operational environment, legal requirements, and a functional description of the element.

[0054] For both TARA and HARA, it is crucial to clearly define the boundaries and interfaces of the vehicle system. This is necessary to determine the extent to which malfunctions can have an impact and to understand precisely how external factors can affect the vehicle system. It is particularly important for assessing how the interactions between vehicle systems affect overall safety.

[0055] To achieve this, the probability of an attack must be assessed for each possible attack path, and all external interfaces must be carefully identified. It is particularly important to clearly define the purpose and nature of each interface, as a lack of understanding of the information flow associated with communication or control processing components makes it difficult to assess the severity and priority of threats. In both TARA and HARA, identifying system boundaries and interfaces is a core task required for a comprehensive assessment of system and operational security.

[0056] Furthermore, a system's various operating modes and its environmental conditions significantly influence both the probability and severity of potential hazardous situations. For example, the risk factors may differ when driving at high speed compared to driving at low speed, and operating the vehicle under certain environmental conditions, such as adverse weather, can present additional hazards. Therefore, it is crucial to identify all possible operating modes and environmental conditions of the vehicle and to thoroughly understand how the system behaves in each scenario. This provides essential information for assessing the frequency and controllability of exposure.

[0057] In practice, the functions an object performs can vary depending on the operating environment and situation. During this process, the object may also be exposed to various cybersecurity threats arising from communication between control devices or from connections to external systems. For example, in certain operating modes or under specific circumstances in the vehicle's lifecycle, access to or manipulation of certain information may be restricted, thus varying the likelihood of threats. Some modes may only be active for short periods, while functions like FOTA (Firmware Over the Air) occur at regular intervals but may not be vulnerable to real-time threats.Therefore, before implementing TARA, the critical information and communication channels for each operating mode must be identified, as this is an essential preparatory measure to ensure system and operational safety.

[0058] TARA analyzes malicious threats that can arise from deliberate attacks. Accordingly, TARA assesses the dangers that could occur during intentional manipulation or an attack on the system and focuses on implementing appropriate countermeasures.

[0059] The functional description applicable to TARA within the element definition can serve as an important basis for the systematic identification of potential hazard control threats and the setting of corresponding hazard control objectives.

[0060] Furthermore, TARA has its limitations in that it is difficult to identify assets and understand data flows at the preliminary architecture level alone. Software-based assets are difficult to identify internally, and without a clear understanding of data flows, the significance of threats cannot be accurately assessed. To achieve this, external interfaces and communication paths must be clearly identified, and the principles of defense in depth should be applied.

[0061] In practice, TARA encounters significant limitations when identifying assets during the preliminary architecture phase. This is because cybersecurity assets are highly software-based, making it particularly difficult to identify assets such as specific encryption algorithms or cryptographic keys.

[0062] For example, if an element is part of a vehicle black box, there may be limitations in identifying internal systems beyond interfaces with external elements. This leads to limitations in isolating systems and requires more detailed system information. Furthermore, TARA may encounter limitations in assessing threat significance if data streams are not clearly identified.

[0063] If data flows are not clearly defined, it becomes difficult to assess the significance of threats. TARA requires an evaluation of the probability of attacks for each possible attack path, and for this purpose, all external interfaces must be identified and the purpose and nature of each interface clearly defined. Without identifying the communication and control processing paths, the severity and significance of threats cannot be accurately assessed.

[0064] Furthermore, TARA must also consider the hierarchy of communication signals when a single signal affects multiple functions, as an accurate assessment is otherwise impossible. Therefore, according to the principles of "Defense in Depth," the location of the control devices in each layer of the vehicle network must be clearly determined, enabling the implementation of effective cybersecurity controls at the vehicle level.

[0065] Cybersecurity control functions are introduced via TARA as measures to reduce the risks associated with certain facilities and are often applied as new functions. Based on the functions defined in the element definition, hazardous events that can occur if these functions malfunction must therefore be derived.

[0066] This process requires a recursive analysis, where it is important to analyze the vehicle behavior and the associated risks when a cybersecurity function fails, and to identify the resulting events.

[0067] The impact scenarios conducted in TARA are closely related to the malfunctions and hazardous events identified in HARA, as well as the severity characteristics used to assess them. To ensure that these relationships can be evaluated as common product characteristics, it is necessary to establish a unified assessment framework for both methods through a single system.

[0068] Attack-induced failures ultimately lead to dangerous events, and because of this connection, a unified assessment method using a single, integrated database was needed. This enables consistent risk assessment within the system and is essential for effectively linking the results of the individual analysis methods.

[0069] Considering functional safety features such as systematic errors or random hardware failures in threat analysis and preventing malicious hacking attacks in hazard analysis ultimately serve the same purpose: preventing system failures.

[0070] The functional principles and embodiments of the disclosed invention are described below with reference to the accompanying drawings.

[0071] Fig.Figure 1 is a representation showing a vehicle risk management system according to one embodiment.

[0072] As in Fig. As shown in Figure 1, the vehicle risk management system 1 can include a server 10 and one or more clients 30, e.g. the first to fifth electronic devices 31, 32, 33, 34 and 35.

[0073] Server 10 can provide a web-based service that enables consistent assessment of common areas through integrated management of TARA and FSM documents.

[0074] Server 10 can store predefined and registered systems, functions, system elements of a vehicle and interface information (also known as connection information).

[0075] Server 10 can contain a database 20, and database 20 can store vehicle systems, functions, system elements and interface information.

[0076] The systems can be one or more and can include hardware and software configurations of the vehicle. They can also be registered or deleted. Examples of systems can include vehicle data systems, communication systems, control systems, hardware systems, software systems, authentication and security systems, and user interface systems.

[0077] It may involve one or more functions that are made available to the user by the vehicle or its configuration (hardware and / or software).

[0078] The system elements can be one or more and can include hardware and / or software components of the vehicle.

[0079] The interface information may contain information that represents the connection relationships between the vehicle's systems and / or functions and the system elements.

[0080] Server 10 can structure text-based data and link the individual data (also referred to as information) together, organizing the relationships and structured information of the linked data into viewsets. The server can then transmit the resulting data to electronic devices 31, 32, 33, 34, and 35.

[0081] For example, server 10 can structure each text-based data element with respect to facilities, functions and / or system elements, and organize the relationships and structured information of each text-based data element in a viewset based on interface information, and then transfer it to electronic devices 31, 32, 33, 34 and 35.

[0082] In response to the information (also referred to as data) received by the electronic devices 31, 32, 33, 34 and 35, the server 10 can generate and output TARA and / or FSM output data based on the equipment, functions, system elements and / or interface information.

[0083] For example, if Server 10 receives plant or function information and additional user input data (also referred to as user input information) from an electronic device 31, 32, 33, 34 or 35 that has received the data provided by the Viewset, Server 10 can generate TARA and / or FSM output data corresponding to the plant or function in question and transmit the generated output data to that electronic device.

[0084] TARA assesses the cybersecurity of a vehicle, more precisely, the threats and risks within the vehicle. It can analyze these by considering the functions of the relevant components within the vehicle (e.g., the control unit involved) and / or signals (e.g., CAN signals).

[0085] For example, TARA can identify impacts related to financial losses, safety issues that could lead to accidents and / or injuries to vehicle occupants, operational disruptions that could affect the operation and / or functionality of the vehicle, and risks to data privacy through the disclosure and / or compromise of personal data.

[0086] Among the threat factors in TARA, the security-relevant factors can be analyzed with reference to the dangerous events identified in HARA.

[0087] The ultimate purpose of TARA is to determine hazard mitigation objectives for the hazards identified in the system and to derive safety control techniques that can mitigate these hazards.

[0088] An FSM document organizes the detection and response strategies for various product defects and describes the elements that can affect the product, such as errors in data elements or errors in external interfaces.

[0089] The FSM document may contain information on security mechanisms resulting from the cybersecurity controls identified via TARA.

[0090] There may be common areas for the TARA documentation and the FSM documentation, but also areas that are specific to each of the two documentations.

[0091] In the meantime, Server 10 can predefine and store the following data usage conditions to ensure the integrity of the work data. < Conditions > 1. General users among the predefined users cannot enter data. 2. General users cannot write any data other than the data already entered. 3. Only a master user with write permission can enter data.

[0092] Server 10 can pre-store data connection information. Accordingly, if a specific piece of information is selected by an electronic device 31, 32, 33, 34, or 35, the associated information can be automatically provided and displayed on that electronic device. Alternatively, all the properties in the table that are linked to the selected information can be provided and displayed on the electronic device 31, 32, 33, 34, or 35, and the user of that electronic device can select the properties directly.

[0093] Furthermore, the server can store 10 pieces of information that require calculation, as well as formulas to be associated with this information. For information requiring calculation, the server can automatically calculate the result using the stored formulas and provide and display the result on the electronic devices 31, 32, 33, 34, and 35.

[0094] Server 10 can offer an approval service.

[0095] For example, Server 10 can provide an approval service to confirm that the completed information has no further changes after review and control by a general user and a master user.

[0096] Once the approval process is complete, the relevant information (e.g., an approved viewset) can no longer be changed. If changes are necessary, a data release request must be submitted.

[0097] Server 10 can offer a mail delivery service.

[0098] As a notification function, a mail delivery service for at least one piece of information can be predefined in Server 10, and the server can provide the mail delivery service by communicating with a predefined mail server.

[0099] Server 10 can perform data visualization. Server 10 can display analytical information, such as functional and fault analysis, in a structure tree and make it available to electronic devices 31, 32, 33, 34, and 35.

[0100] Server 10 can set and save different user permissions for each user.

[0101] Users can include, for example, administrators, master users, general users, and associated users. Each user can be distinguished by a user ID (identifier).

[0102] The administrator can have permissions that allow all possible user activities. For example, the administrator can register or delete users, change user rights, and manage data changes. On the administrator page, the administrator can also enter, edit, and delete bulk data. Furthermore, the administrator can perform a rollback operation, which cancels ongoing transactions and reverts modified data to its original state. The administrator can also modify the dashboard that appears as the first screen upon login.

[0103] A master user can configure permissions to allow reading or modifying data within their assigned project. Depending on the project, the master user's rights to view or edit data may be restricted, and they may not have delete permissions. The master user can also be granted separate permissions to review views created by general users.

[0104] A general user may have permission to view and modify data within their assigned project. However, for projects where no permissions are granted, the general user's ability to view or modify data may be restricted, and they may not be granted delete permissions. The general user may also be granted separate permissions to review views created by the master user.

[0105] An associated user may only have permission to read and export viewsets. For example, the associated user may only be allowed to read and export views and may not perform any other functions.

[0106] For example, Server 10 can set and save a predefined permission configuration for each user type, as shown in Table 1. [Table 1] User type User permissions Administrator Read, write, modify, delete, import, export, submit and approve Master User Read, modify (limited to the master database), export and approve General User Read, modify, export and approve Associated User Read and export

[0107] In Table 1, “Read” means that the user can read data from projects for which they have been granted permission.

[0108] "Write" means that the user can add new entries to the data of a project for which write permissions have been granted. However, according to the predefined settings, data can only be added to the "supergroup".

[0109] “Modify” means that the user can change existing data in a project for which change approval has been granted. For example, the user can select and change data via a drop-down list among the graphical user interface (GUI) elements displayed on the screen of electronic devices 31, 32, 33, 34, and 35.

[0110] "Delete" means that the user can delete data, including cases where data is deleted within a supergroup project.

[0111] “Importing” means that data can be loaded into the supergroup project via a file in a predefined format, such as an Excel file or a CSV file.

[0112] “Exporting” means that the content of a viewset of a project for which permission has been granted can be output or saved in a predefined format, e.g. Excel, Word or PDF.

[0113] "Submit" means that after completing the assessment for TARA, the user can submit the corresponding viewset to request approval. For example, once a functional safety activity is completed, the viewset for that activity can be submitted for approval.

[0114] “Approve” means that the evaluated TARA viewset can be reviewed and approved.

[0115] Each of the electronic devices 31, 32, 33, 34 and 35 can receive web-based services from server 10. A web browser 311, 321, 331, 341 and 351 can be installed on each electronic device, through which the user can access and use the web-based services of server 10.

[0116] Each of the first to fifth electronic devices (31, 32, 33, 34, 35) can receive TARA and / or FSM output data relating to the system or function of the vehicle from the server and display the data on a screen or output the TARA and / or FSM as output data.

[0117] The individual steps of the TARA process according to one embodiment of the present invention are linked together, as shown in Fig. 2 is shown so that the vehicle system can take both safety and security into account simultaneously.

[0118] TARA also includes a procedure that evaluates the individual pieces of information and / or data by focusing on the respective information and / or data based on the interconnected information and / or data.

[0119] As in the Fig. 2 and Fig.As shown in Figure 3, TARA can be divided into common information and / or data that is shared by HARA and TARA and that can be standardized or generalized, and TARA-specific information and / or data that is tailored to TARA and can be predefined.

[0120] Fig. Figure 2 is a representation that depicts a step-by-step analysis procedure and a relationship diagram of hazard mitigation threats according to one embodiment.

[0121] As in Fig. Figure 2 shows a method for analyzing the hazard prevention risk for vehicles according to one embodiment, comprising a data flow structure for defining a hazard prevention target based on the analysis results of the TARA (threat analysis and risk assessment) for vehicle cybersecurity.

[0122] The in Fig.The data flow shown in Figure 2 can represent the TARA cybersecurity analysis procedure, and the data analysis flow shown can be divided into general data and threat data, which can establish reference and linking relationships with each other.

[0123] The data relating to the multiple plant elements—that is, the plant to be protected, the plant's function, and the plant's characteristics—can be defined as common data referenced jointly in both HARA and TARA. In this case, the plant's functionality corresponds to the vehicle's function, and the safety risk caused by a malfunction of a vehicle function can be assessed in conjunction with the hazard mitigation risk caused by an impairment of the plant's functionality.

[0124] Specifically, each plant element can contain the following elements.

[0125] The system can be a physical or logical component within the system that needs protection, such as information like vehicle diagnostic data or control signals. The system's function can be an operation performed by the system or a service provided by the system, such as reading or writing vehicle diagnostic data. The system's property can be characteristic information, such as the communication interface to which the system belongs, the direction of data flow, or the level of access authorization. For example, the property could be defined as "transmitting data to an external device via an internal communication network."

[0126] The data on the plant elements described above can be used as input information for evaluating a plant's cybersecurity characteristics from a TARA perspective. For example, a plant's security attributes can be defined as at least confidentiality, integrity, availability, non-repudiation, and authentication, and the specific security properties to be protected can vary depending on the characteristics of each plant.

[0127] For certain data services within the vehicle, such as reading vehicle diagnostic data, the data can be accessed from an external device. Therefore, confidentiality can be defined as a primary security feature to prevent data leaks. Through such analysis, the system can define potential damage scenarios, such as a data leak, based on the system's characteristics and implement appropriate mitigation measures.

[0128] The data for the system components can now be referenced not only in TARA but also in HARA. For example, while the vehicle's "data query function" can be analyzed in TARA as a security risk related to external access, the same function in HARA can be assessed as a malfunction that could pose a security risk to the system. Therefore, even if it is one and the same system, it can be analyzed as a single, coherent risk factor from both security and security perspectives, depending on its functionality and characteristics.

[0129] According to one embodiment, the system can identify a likely threat scenario by analyzing the multitude of system elements. In other words, by analyzing information about the various system components within the vehicle, the system can anticipate situations that could lead to security vulnerabilities or external attacks. For example, if an internal diagnostic data processing function of the vehicle is defined as a "data read" function and the function is structured to transmit data to an external device via the vehicle's communication network, the system can assess whether this process poses a risk of data leakage. For instance, if the function's security is insufficiently reinforced or authentication procedures are lacking along the communication path, there is a possibility that an external party could gain unauthorized access to the vehicle's data.Accordingly, the system can identify such a case as a predicted threat scenario of the data leak type.

[0130] Furthermore, the system can analyze the relationships between multiple systems to derive new threat scenarios from their interconnected functions or data flows. For example, if one system performs a "data request" function and another performs a "data response" function, the system can identify potential attacks such as message manipulation, spoofing, or replay within the communication segment between the two systems as new threat scenarios.

[0131] Here, the predicted threat scenario can be derived based on a threat type. The threat type could be, for example, spoofing, manipulation, denial, information disclosure, denial of service, or escalation of privileges. However, these examples are for illustrative purposes only and should not be interpreted as limitations.

[0132] Thus, the system of the present invention can automatically derive a likely threat scenario at the system level by analyzing the relationships between the functional elements, communication paths and cybersecurity properties of the multiple plant elements, starting from damage scenarios at the plant level.

[0133] Another example: If the predicted threat scenario is "Data leak due to loss of confidentiality of the diagnostic data query function (ReadData service)," the system can define an impact scenario such as "a situation in which internal diagnostic data or vehicle configuration information can be leaked, resulting in a security breach." In this case, the type of threat can be classified as "data leak," and the extent of the confidentiality loss can serve as an important evaluation factor for the corresponding impact scenario.

[0134] Based on the derived impact scenario, the system can classify the degree of impact of each hazard or threat on the overall system. Furthermore, the impact scenario can be used as a common data basis for linking the results of the hazard analysis (HARA) and the threat analysis (TARA). By integrating the safety-related impacts derived from the target hazard scenario and the safety-related impacts derived from the predicted threat scenario into a single impact scenario dataset, the system can comprehensively analyze the interdependence of safety and protection. In this way, the system of the present invention can predict the impacts that may arise from situations derived from hazards and threats and store the corresponding analysis results in the database.

[0135] More precisely, the system can analyze the role, behavioral path, and relationships between individual functional elements by referring to the target hazard scenario data stored in the database. For example, although the vehicle's "acceleration request" function normally operates by requesting appropriate drive torque based on the driver's pedal input, if this function malfunctions, the system can detect the abnormal condition where "excessive acceleration torque is being requested beyond the requested level."

[0136] If the system detects such a malfunction, it can assess the hazardous event that may result from it. For example, if an excessive acceleration request causes the vehicle to move forward regardless of the driver's intention, the system can define this condition as a hazardous event of "unintended longitudinal acceleration of the vehicle." The system can then analyze the impact of the hazardous event on the driver and the vehicle through simulations. By inputting variables such as vehicle speed, road conditions, distance to the vehicle ahead, and the driver's reaction time, the system can, for instance, evaluate the outcomes that the hazardous event could produce in the actual driving environment.

[0137] Such a simulation can yield results such as "the vehicle moves forward uncontrollably," "increased probability of collision due to a reduction in distance to the vehicle ahead," and "inability to avoid a collision within the driver's steering or braking reaction time." The system can comprehensively analyze the simulation results to determine the impact of the hazardous event on driver safety, vehicle control stability, and occupant protection, and can define these results as an impact scenario.

[0138] According to one embodiment, an attack path can be created for the impact scenario based on at least one of the following elements: security element, financial element, operational element, and data protection element. Specifically, the system can analyze the data contained in the impact scenario to identify a path by which a particular threat can enter and spread within the vehicle system and derive a corresponding attack path. For example, if the impact scenario corresponds to "data leakage due to loss of confidentiality of data in an onboard network," the system can analyze the connectivity structure of the vehicle's systems to derive possible routes by which an attacker could gain access via an external device such as a diagnostic tool, a communication module, or a gateway.

[0139] Creating such an attack path can be approached from different perspectives, depending on the characteristics of the impact scenario. From a safety element's perspective, for example, an attack or threat can be assessed in terms of its impact on safety-relevant functions such as vehicle stability, braking systems, and steering systems, and a path can be defined through which such functions can be disrupted or manipulated. For instance, if a specific control unit is compromised and a brake control signal is altered, a sequence of intrusion steps can be identified as an attack path.

[0140] In one embodiment, the safety element can be derived from the safety level. That is, the system can determine the required safety level for each function within the vehicle system based on a safety level determined by assessing exposure, severity, and controllability according to predetermined evaluation criteria. For example, if a function has a high safety level, its malfunction is more likely to directly affect driver safety or vehicle control, and the system can identify such a function as a critical safety element and configure additional safeguards to be applied to the system encompassing the function.

[0141] The financial element is an element that considers the possibility of economic loss as a result of an attack or threat. Financial elements can be defined, for example, as pathways through which data from paid communication services, over-the-air (OTA) update information, or vehicle payment systems can be compromised.

[0142] The operational element represents pathways through which functions may be interrupted or malfunction during vehicle operation or the provision of vehicle services. For example, if access via a remote control system or diagnostic equipment for maintenance is blocked or restricted, the system can identify such cases as attack paths that correspond to an operational disruption.

[0143] The data protection element is an element that defines the paths by which sensitive information stored in the vehicle, such as driver data, passenger information, or driving behavior, can be accessed externally. For example, a situation in which vehicle log data is transmitted without authorization via an external communication module can be assessed as an attack path that includes a data protection element.

[0144] Each of the above elements can be evaluated independently or combined into a composite attack path. A composite attack path that both compromises privacy and disrupts operations can be defined, for example, as a path where an external attacker exfiltrates diagnostic data through a vehicle communication interface while simultaneously disabling communication functions, thus preventing the transmission of normal control signals.

[0145] The system can store the derived attack paths in the database and calculate a risk score by comprehensively evaluating factors for each path, such as the feasibility of the attack, the difficulty of the attack, and the potential extent of the impact. The calculated risk score and the associated evaluation results can serve as a basis for defining threat mitigation objectives and can be used to identify, derive, and prioritize appropriate threat control measures and alternative threat mitigation strategies for each attack path.

[0146] According to one embodiment of the present invention, the system can derive one or more attack paths based on the impact scenario and assess the feasibility of the attack and the impact assessment for each derived attack path, thereby calculating the final risk score. The calculated risk score can be used to determine threat mitigation objectives and to select threat mitigation countermeasures according to priority.

[0147] The system can assess the feasibility of attacks for each attack path, and the assessment can consist of several detailed elements. For example, elapsed time can represent the time required to carry out the attack; expertise can represent the technical level required to execute the attack; knowledge of the object or component can represent the attacker's understanding of the system, protocol, or interface; the time window can represent the temporal or environmental conditions under which the attack is possible; and equipment can represent the physical or software tools required to execute the attack.

[0148] The system can assign qualitative or quantitative points to each of the aforementioned elements and calculate the feasibility score of the attack through weighted summation, rule-based evaluation, or arithmetic combination. The system can combine the calculated attack feasibility score with the impact assessment to derive the risk score for each attack path.

[0149] The derived risk score can then be used to prioritize mitigation measures, define mitigation goals, and select specific mitigation control measures during the design and operational phases. The system can store the attack feasibility score, impact assessment, risk score, and associated metadata for each attack path in the database and perform subsequent operations based on these stored values.

[0150] Based on the calculated risk score, the system can determine the priority of mitigation countermeasures for each attack path and recommend appropriate countermeasures or submit the results for manual review. The system can also verify the consistency between the determined security level and the mitigation objectives, and analyze and resolve potential conflicts between security requirements and mitigation goals. Furthermore, by assigning appropriate mitigation control measures and alternative mitigation measures for each attack path, the system can derive and manage specific response measures for the identified threats.

[0151] According to one embodiment of the present invention, the system can define the vehicle's security objectives based on the derived attack paths and the predicted threat scenario. In one embodiment, the security objectives can be defined to meet the integrity and availability requirements defined by the security objectives. Furthermore, when defining the security objectives, the system can not only identify risks but also consider the characteristics of each risk and the interdependencies within the vehicle system, thereby defining appropriate security control measures such as access control, encrypted communication, and data integrity verification.The threat mitigation objectives defined in this way can be applied throughout the entire design and operational phase of the vehicle system, so that certain attack paths can be blocked in advance or the system can be set up to return to a safe state even if a threat is realized.

[0152] According to one embodiment, threat mitigation control measures and alternative threat mitigation measures necessary to meet the conditions of a secure state can be determined based on threat mitigation objectives. For identical or similar threat scenarios, the results of applying threat mitigation control measures and the results of applying security mechanisms can be linked and managed in an integrated database. Furthermore, the results of such risk assessment and mitigation can serve as reference information for subsequent risk tracking and reassessment, thereby ensuring the ongoing cybersecurity and security of the system.

[0153] Consequently, the step of defining a threat mitigation objective according to the present invention, based on the analysis results of the attack path and the predicted threat scenario, can define a threat mitigation objective and / or a threat mitigation level (CAL) for the protection of critical systems within the vehicle. Depending on the required cybersecurity level, suitable threat mitigation control measures and alternative risk reduction procedures can be derived, thereby improving the overall reliability of the vehicle's cybersecurity and establishing an integrated framework for threat mitigation management that combines both safety and cybersecurity.

[0154] Fig. Figure 3 is a diagram for displaying hazard prevention threat data according to the embodiment of Fig. 2.

[0155] Referring to Fig.Section 3 presents the information and / or data required to define a hazard prevention objective for vehicle risk management. Fig. 3. The data used to define the threat mitigation objective can be referred to as threat data, which may be TARA-specific data. Risk data and threat data, i.e., data to which both HARA and TARA refer, can be referred to as common data.

[0156] The threat data referenced in TARA can contain information about a wide variety of plant elements. This information about the various plant elements can include sub-data about the plants, their functions, and their properties. In this case, the data about the plants, their functions, and their properties can be the common data referenced by both HARA and TARA.

[0157] The common data for the safety level can correspond to the data for the ASIL (Automotive Safety Integrity Level). The safety level can be determined, for example, based on data regarding exposure to the hazardous situation, the severity of the hazardous situation, and the controllability of the hazardous situation. Here, the data on exposure, severity, and controllability can correspond to the hazard data referenced only in HARA. The safety objective can be derived from the safety level data referenced jointly in HARA and TARA.

[0158] The shared impact scenario data may include data on potential impacts derived from the predicted threat scenarios. As in Fig.As shown in Figure 3, the impact scenario data can include sub-data relating to security elements, operational elements, financial elements, and data protection elements. In other words, the impact of the anticipated threats can indicate the extent of losses or damages in terms of security, financial aspects, operational aspects, and data protection aspects. The impact scenario data can also serve as a basis for quantifying the functional, financial, operational, or data protection-related impacts on the vehicle in the event of a threat scenario. The security element data can correspond to the common data derived from the security level. The operational, financial, and data protection element data can correspond to threat data referenced only in TARA.

[0159] The data relating to the threat mitigation objective, which is common data, can be derived from at least one of the common data points and the threat data. For example, by analyzing data relating to the predicted threat scenario and attack path, referenced only in TARA, the system can assess the impact of the corresponding threat on the vehicle's systems, functions, or services. Based on the assessment result, a threat mitigation objective can be established to ensure the integrity, availability, confidentiality, and authentication of the vehicle system.

[0160] Fig. Figure 4 is a block diagram of a vehicle risk management system according to one embodiment.

[0161] According to Fig.4. The server 10 of the vehicle risk management system 1 can comprise a database 20, a communication unit 110 and / or a control device 120.

[0162] Database 20 can store information and / or data required to define a hazard mitigation target for vehicle risk management. For example, data used to define the hazard mitigation target can be referred to as threat data. This threat data can be TARA-specific data or data that is jointly referenced by both TARA and HARA.

[0163] Database 20 can store at least some of the predefined threat data required for conducting TARA during the vehicle risk management process. For example, database 20 can store TARA-exclusive data. This TARA-exclusive data can consist of a variety of data elements, each representing a successive step of a predefined TARA procedure. The TARA-exclusive data can also include at least a subset of other data.

[0164] Database 20 can store a predefined set of common data that is frequently referenced in both the HARA and TARA procedures. For example, database 20 can contain the information contained in the Fig. 2 and Fig. The 3 common data shown are stored, which are referenced in both HARA and TARA.

[0165] Meanwhile, at least some of the threat data, the data subordinate to it, and the common data may have a hierarchical structure in which the data elements are dependent on or linked to each other, and a change or update of certain data may be linked to the update of other related data.

[0166] Database 20 can store information about connection relationships that define hierarchical relationships between the TARA-exclusive data, i.e., the threat data according to the sequential phases of TARA.

[0167] Database 20 can store information about connection relationships that represent the stepwise or hierarchical relationships between the common data referenced jointly in HARA and TARA.

[0168] Database 20 can store information that indicates the relationships between threat data and shared data. For example, database 20 can store information about connection relationships that allow at least one of the TARA-specific data points and the data that both TARA and HARA reference to form a linked or referenceable hierarchical structure.

[0169] The communication unit 110 can establish a communication channel between the server 10 and external devices, e.g., the one in Fig.The communication unit 110 comprises the first to fifth electronic devices 31, 32, 33, 34 and 35 shown in Figure 1, and can send and receive data via the specified communication channel. The communication unit 110 can include a communication circuit and a control circuit configured to control the operation of the communication circuit to support such communication functions.

[0170] For example, the communication unit 110 can contain a wireless communication module such as a cellular module, a Wi-Fi communication module, a short-range wireless communication module or a global navigation satellite system communication module and / or a wired communication module and can send and receive data with external devices via the appropriate module.

[0171] The control device 120 can be electrically connected to any component of the server 10, e.g. the database 20 and the communication unit 110, and can control each component.

[0172] The control device 120 can control the database 20 to store TARA-exclusive data and common data from HARA and TARA.

[0173] The control device 120 can be communicatively connected to the electronic devices 31, 32, 33, 34 and 45 via the communication unit 110. Although in Fig. 4 only a first electronic device 31 is shown, this serves only for explanation, and the possibility of communicating with several electronic devices does not limit the scope of the present invention.

[0174] The control device 120 can receive a user ID from the first electronic device 31 and, based on the received user ID, set and assign user rights for the electronic device 31.

[0175] The control device 120 can receive evaluation target information from the first electronic device 31 via the communication unit 110, which corresponds to a system or function of the vehicle.

[0176] In response to receiving the evaluation target information, the control device can generate and output 120 TARA result data for the evaluation target information based on the TARA-exclusive data and / or the common data of HARA and TARA.

[0177] The control device 120 can generate TARA result data for the evaluation target information based on user input data (or user data) for at least a portion of the TARA-exclusive data and / or the common data of HARA and TARA received via the communication unit 110. The user-input information can, for example, include a user-configured value for the corresponding data, i.e., a parameter. The control device 120 can generate TARA result data corresponding to the evaluation target information based on a specific template for TARA (e.g., a dynamic template) stored in memory 122. The generated TARA result data can be transmitted to the first electronic device 31 via the communication unit 110.

[0178] The control device 120 can identify data among the TARA result data that are preset for inclusion in an FSM document, and can generate FSM document data based on a specific FSM template (e.g., a dynamic template) stored in memory 122, and can output the generated FSM document data. The generated FSM document data can also be transmitted to the electronic device 31 via the communication unit 110.

[0179] The control device 120 may contain a control circuit that is set up to control the execution of the above-mentioned functions.

[0180] The control device 120 can be implemented as a micro control unit (MCU) and contain the memory 122 and a processor 121.

[0181] Memory 122 can store programs and / or data for processing individual data (e.g., data from external devices such as those in Fig.1 shown first to fifth electronic devices 31, 32, 33, 34 and 35 were received) store.

[0182] Memory 122 can temporarily store individual data or temporarily store the processing result of the data processed by processor 121.

[0183] The memory 122 can contain both volatile memory such as S-RAM or D-RAM and non-volatile memory such as flash memory, ROM, EPROM and / or EEPROM.

[0184] The processor 121 can process any part of the received data and, based on the processing result, output signals to control the communication unit 110 and / or the database 20.

[0185] The first electronic device 31 can comprise a communication unit 310, an input unit 320, an output unit 330 and a control device 340.

[0186] The communication unit 310 can establish a communication channel between the first electronic device 31 and an external device, for example, the server 10, and send and receive data via the established communication channel. The communication unit 310 can include a communication circuit and a control circuit configured to control the operation of the communication circuit.

[0187] For example, the communication unit 310 can contain a wireless communication module, such as a cellular module, a Wi-Fi communication module, a wireless short-range communication module or a global navigation satellite system communication module, and / or a wired communication module, and can send and receive data with an external device via the appropriate communication module.

[0188] The input unit 320 can receive information according to user operation and pass the information on to a connected device such as the control device 340.

[0189] The 320 input unit can, for example, contain input devices such as buttons, switches, a touchscreen and / or a microphone.

[0190] The output unit 330 can output visual and / or acoustic information so that a user of the first electronic device 31 can perceive the information. The output unit 330 can, for example, include a display and / or a loudspeaker.

[0191] The control device 340 can be electrically connected to any component of the first electronic device 31, e.g., to the communication unit 310, the input unit 320 and / or the output unit 330, and can control the operation of the respective components.

[0192] The control device 340 can communicate with the server 10 via the communication unit 310. The control device 340 can receive a service for managing TARA documents from the server 10 via the communication unit 310.

[0193] For example, the control device 340 can receive at least some of the TARA-exclusive data and / or the common data of HARA and TARA from the server 10 and output the received data via the output unit 330, e.g. a display.

[0194] The control device 340 can acquire evaluation target information via the input unit 320, which corresponds to a system or function of the vehicle according to a user operation.

[0195] The control device 340 can acquire information about user inputs, e.g. a parameter, via the input unit 320 for at least part of the TARA-exclusive data and / or the common data of HARA and TARA.

[0196] The control device 340 can transmit the user input data acquired via the input unit 320 to the server 10 via the communication unit 310 for at least part of the TARA-exclusive data and / or the common data of HARA and TARA.

[0197] The control device 340 can receive TARA result data for the evaluation target information from the server 10 via the communication unit 310 and output the received result data to the user via the output unit 330, e.g. a display.

[0198] In addition, the control device 340 can receive result data for the FSM document from the server 10 via the communication unit 310 and output the data via the output unit 330, e.g. a display.

[0199] The control device 340 can also contain a control circuit.

[0200] The control device 340 can be designed as a micro control unit (MCU) and contain a memory 342 and / or a processor 341.

[0201] Memory 342 can store programs and / or data for processing individual data, e.g., data received from an external device such as server 10, or data corresponding to information entered via input unit 320.

[0202] Memory 342 can temporarily store received data or the results of data processed by processor 341.

[0203] The memory 342 can include volatile memory such as S-RAM and / or D-RAM and non-volatile memory such as flash memory, ROM (Read Only Memory), EPROM (Erasable Programmable Read Only Memory) and / or EEPROM (Electrically Erasable Programmable Read Only Memory).

[0204] The processor 341 can process all received or input data and provide control signals for the respective components to control the communication unit 310, the input unit 320 and the output unit 330 based on the processing result.

[0205] Although in Fig. Not shown in section 4, the second electronic device 32, the third electronic device 33, the fourth electronic device 34 and the fifth electronic device 35 can be distinguished from Fig. 1 comprising a communication unit, an input unit, an output unit and a control device similar to those of the first electronic device 31, and capable of performing operations similar to those of the first electronic device 31.

[0206] Fig. Figure 5 is a flowchart that illustrates a control process of a server according to one embodiment.

[0207] As in Fig.As shown in Figure 5, the server can analyze a variety of system elements of the vehicle and identify a predicted threat scenario (501).

[0208] According to one embodiment, the multitude of plant elements can be TARA-related cybersecurity data that may include a plant to be protected, a function of the plant, and a property of the plant. Here, the data about the plant, the function of the plant, and the property of the plant can be data to which both HARA and TARA jointly refer.

[0209] An installation can be a physical or logical component within the system that requires protection and can consist of information such as vehicle diagnostic data or control signals. The installation's function can be an operation performed by the installation or a service provided by the installation, such as reading or writing vehicle diagnostic data. The installation's characteristics can be information such as the communication interface to which the installation belongs, the direction of data transmission, or the access authorization level. The installation's function can correspond to the vehicle's function, and a security risk caused by a malfunction of the vehicle's function can correspond to a hazard prevention risk caused by an impairment of the installation's function.

[0210] The server can infer an impact scenario that matches the predicted threat scenario and derive an attack path based on the impact scenario (502).

[0211] According to one embodiment, the impact scenario can be generated by deriving a damage scenario corresponding to the multitude of system elements and by simulating the effects of the damage scenario on the driver or the vehicle. The impact scenario can represent data that quantitatively or qualitatively expresses the impact on the overall system, vehicle functions, the driver, or the external environment when a specific risk or threat actually occurs. The impact scenario can also be used as a common database for linking the results of the hazard analysis (HARA) and the safety analysis (TARA).

[0212] According to one embodiment, the attack path can be constructed for the impact scenario based on at least one security element, one financial element, one operational element, and one data protection element. The security element can be derived from a security level.

[0213] The level of security can be determined by assessing the exposure, severity, and controllability of the hazardous situation according to a predetermined evaluation criterion and by combining the evaluation results for exposure, severity, and controllability. In particular, the server can analyze the data contained in the impact scenario, determine how a specific threat can penetrate and propagate within the vehicle system, and derive a corresponding attack path.

[0214] The server can determine a hazard mitigation target for the vehicle based on the attack path and the predicted threat scenario (503).

[0215] According to one embodiment, the threat mitigation goal can be created based on a risk score for the attack path and the predicted threat scenario. The process of creating the threat mitigation goal can be described as follows: Fig. 2. According to one embodiment, based on the hazard control objective, hazard control measures and alternative hazard control measures can be determined to fulfill the conditions for a safe state.

[0216] Fig. Figure 6 is a flowchart illustrating a control procedure of a server to achieve a hazard prevention objective of a vehicle according to one embodiment.

[0217] As in Fig.As shown in Figure 6, the server can define the conditions for the vehicle's security threats and set parameters used to determine these threats, storing them in database (601). For example, the server can set various security diagnostic data as parameters, such as abnormal communication patterns, fluctuations in message cycles, authentication failures, abnormal access attempts, communication delays, and packet loss rates, and use these parameters to determine whether a potential security threat has occurred.

[0218] The server can extract diagnostic and response-related information related to the vehicle's security threat, based on the parameters used to determine the security threat (602). The server can create threat detection logic by referencing parameter thresholds, normal communication characteristics, and conditions for the occurrence of abnormal events, and by defining response steps to be applied when a threat occurs, such as generating alerts, blocking messages, restricting permissions, or switching to a protective mode. In this way, the server can extract reference information necessary for managing the vehicle's cybersecurity threats.

[0219] The server can store diagnostic and response-related information related to the vehicle's security threats in the database and use this information as input for threat assessment (603). The server can structure and store various types of analytical data in the database, such as threat detection results, threat occurrence times, frequency of occurrence or number of attempts, changes in system state, applied response measures, and their effectiveness, obtained through the diagnostic procedure defined in step 602. This allows the stored analytical data to serve as reliable evidence in the risk assessment process related to vehicle cybersecurity.This means that information such as the cause of each threat, attack techniques, the probability of a successful attack, and the effectiveness of countermeasures can be incorporated into the risk assessment for each threat scenario during a subsequent TARA analysis.

[0220] The server can configure diagnostic control logic to achieve the vehicle's threat prevention goal (604). The server can create diagnostic control logic that includes threat detection criteria, rules for determining anomalous behavior, and response policies that meet the threat prevention goal, and can deploy or update the logic in conjunction with a vehicle control device or network gateway. Furthermore, the server can enhance the vehicle system's ability to respond to threat prevention by automatically adjusting or supplementing the parameters of the configured logic based on real-time security monitoring data and communication protocols collected from the vehicle.

[0221] According to one embodiment, in identical or similar threat scenarios, the server can compare the application results of the diagnostic control logic and manage them integratively in the database.

[0222] Meanwhile, the implementations described above offer a unified framework that enables risk management activities to be carried out without information gaps. This framework eliminates resource waste and redundancy that can occur in the execution and management of cybersecurity activities. This framework has been validated using a vehicle braking system example, demonstrating the improved efficiency of cybersecurity management procedures. In particular, the following Fig.The embodiment shown in Figure 6 provides a basis for defining optimization strategies for cybersecurity management throughout the entire vehicle lifecycle through a recursive analysis that begins with element definition. It is expected that the use of this framework will reduce development costs, lower quality-related costs through quality improvements, and ultimately contribute to improved productivity and increased sustainability for the company.

[0223] Furthermore, in the embodiments described above, the focus was placed on identifying the relationships between the TARA data and standardizing risk mitigation measures through the newly identified control devices and security mechanisms for cybersecurity. However, the quality of the risk mitigation results can depend on the level of detail in the planning and analysis. Therefore, tools such as fault tree analysis, attack path analysis, and failure mode and impact analysis can be further developed as part of the cybersecurity management framework in the embodiments described above.

[0224] Another aspect is that the disclosed embodiments can be implemented in the form of a recording medium that stores instructions which can be executed by a computer. The instructions can be stored as program code and, when executed by a processor, generate program modules that perform the operations of the disclosed embodiments. The recording medium can be implemented as a computer-readable recording medium.

[0225] Computer-readable recording media encompasses any type of medium on which instructions are stored that can be interpreted by a computer. Examples include read-only memory (ROM), random-access memory (RAM), magnetic tapes, magnetic disks, flash memory, and optical data storage.

[0226] The machine-readable storage medium can be provided as a non-transferable storage medium. The term "non-transient" simply means that the storage medium is a tangible device that does not contain signals such as electromagnetic waves, and does not distinguish whether the data is stored permanently or temporarily. A non-transferable storage medium can, for example, contain a buffer in which data is temporarily stored.

[0227] The disclosed embodiments have been described above with reference to the accompanying drawings. Those skilled in the art will understand that various modifications and other embodiments are possible without departing from the technical spirit or the essential features of the present invention. The embodiments shown are therefore to be considered illustrative and not restrictive. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] KR 10-2024-0180767

[0001] KR 2025-0187545

[0001] Cited non-patent literature

[0000] ISO / SAE 21434 [0006, 0007, 0011] ISO 26262 [0006, 0011]

Claims

[1] Vehicle risk management procedures, comprehensive: Analyzing a large number of the vehicle's system components to identify a predicted threat scenario; Deriving an impact scenario based on the predicted threat scenario and deriving an attack path based on the impact scenario; and Defining a hazard mitigation objective for the vehicle based on the attack path and the predicted threat scenario. [2] Method according to claim 1, wherein the multitude of plant elements includes a plant to be protected, a function of the plant and a property of the plant, and where the function of the system corresponds to a function of the vehicle and a safety risk caused by a malfunction of the function of the vehicle corresponds to a hazard prevention risk caused by an impairment of the function of the system. [3] Method according to claim 1 or 2, wherein the impact scenario is generated by deriving a damage scenario according to the plurality of plant elements and simulating an influence of the damage scenario on a driver or the vehicle. [4] Method according to any one of claims 1 to 3, wherein the attack path is determined on the basis of an impact assessment determined according to at least one security element, one financial element, one operational element and one privacy element for the impact scenario. [5] Method according to claim 4, wherein the safety element is derived from a safety level and the safety level is determined by evaluating exposure, severity and controllability of the hazardous situation according to a predetermined evaluation criterion and combining the evaluation results of exposure, severity and controllability. [6] Method according to any one of claims 1 to 5, wherein the hazard prevention objective is generated on the basis of a risk value according to the attack path and the predicted threat scenario. [7] Method according to any one of claims 1 to 6, wherein, on the basis of the hazard prevention objective, a hazard prevention control measure and an alternative hazard prevention measure are determined to fulfill a condition of a safe state. [8] Method according to any one of claims 1 to 8, furthermore, comprehensively adjusting the diagnostic control logic to achieve the vehicle's hazard prevention objective, which includes setting the diagnostic control logic: Defining a hazard control threat state of the vehicle and setting parameters used to determine the hazard control threat, wherein the parameters are stored in a database (20), and Deriving diagnostic information and response-related information associated with the vehicle's hazard mitigation threat based on the parameters, and storing the diagnostic information and response-related information in the database (20) for use as input data for threat assessment. [9] Method according to claim 8, wherein for the same or a similar predicted threat scenario the results of the application of the diagnostic control logic are compared with each other in order to link or manage them in the database. [10] Computer program stored in a medium to cause a computer device to execute the method according to any one of claims 1 to 9. [11] Server (10), comprising: a database (20) which is set up to store a variety of data for vehicle risk management; a communication module (110) configured to communicate with an external device; and a processor (121) that is electrically or communicatively connected to the database and the communication module, where the processor (121) is configured to: Analyzing a large number of the vehicle's system components to identify a predicted threat scenario, Deriving an impact scenario based on the predicted threat scenario and deriving an attack path based on the impact scenario, and Defining a hazard mitigation objective for the vehicle based on the attack path and the predicted threat scenario. [12] Server (10) according to claim 11, wherein the multitude of plant elements includes a plant to be protected, a function of the plant and a property of the plant, and where the function of the system corresponds to a function of the vehicle and a safety risk caused by a malfunction of the function of the vehicle corresponds to a hazard prevention risk caused by the impairment of the function of the system. [13] Server (10) according to claim 11 or 12, wherein the impact scenario is generated by deriving a damage scenario according to the plurality of plant elements and simulating an influence of the damage scenario on a driver or the vehicle. [14] Server (10) according to one of claims 11 to 13, wherein the attack path is determined according to an impact assessment which is determined on the basis of at least one security element, one financial element, one operational element and one privacy element for the impact scenario. [15] Server (10) according to claim 14, wherein the safety element is derived from a safety level and the safety level is determined by evaluating exposure, severity and controllability of a hazardous situation according to predetermined evaluation criteria and combining the results of the evaluation of exposure, severity and controllability. [16] Server (10) according to one of claims 11 to 15, wherein the threat prevention target is generated on the basis of a risk value according to the attack path and the predicted threat scenario. [17] Server (10) according to any one of claims 11 to 16, wherein the processor is configured to determine hazard control measures and alternative hazard control measures to satisfy a condition of a safe state based on the hazard control objective. [18] Server (10) according to any one of claims 11 to 17, wherein the processor (121) is configured to: Setting the diagnostic control logic to achieve the vehicle's hazard prevention goal, defining a hazard prevention threat state of the vehicle, Setting parameters used to determine hazard mitigation threats and storing the parameters in the database (20), and Deriving diagnostic information and response-related information associated with the vehicle's hazard mitigation threat based on the parameters, and storing the diagnostic information and response-related information in the database (20) for use as input data for threat assessment, thereby setting the diagnostic control logic. [19] Server (10) according to claim 18, wherein the processor (121) is configured such that for the same or a similar predicted threat scenario, the results of the application of the diagnostic control logic are compared with each other in order to link or manage them in the database (20).

Images