Log management device, log management method, log management program, and log management system
By generating and sending detection logs for live/dead monitoring, the problem of inaccurate judgment of security sensor status is solved, improving the accuracy of network attack analysis and communication efficiency.
Patent Information
- Application Number
- CN202510610670.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2024-05-17
- Filing Date
- 2025-05-13
- Publication Date
- 2025-11-18
AI Technical Summary
In existing technologies, the interruption of the survival signal of a security sensor does not necessarily indicate an anomaly, resulting in insufficient information in network attack analysis and log analysis devices being unable to accurately determine the status of the security sensor.
By generating and sending live/dead monitoring function logs, and based on the reception status of the live/dead monitoring logs, information on the start and stop of the actions of safety sensors is provided, reducing the amount of communication between the log management device and the log analysis device.
It improves the accuracy of network attack analysis, reduces unnecessary communication, and can quickly provide detailed information related to security sensor actions, supporting log analysis devices to quickly identify network attacks and formulate countermeasures.
Smart Images

Figure CN120979683A_ABST
Abstract
Description
Technical Field
[0001] This disclosure primarily relates to a device, method, procedure, and system for managing security logs that utilize live / dead monitoring logs generated by security sensors mounted on electronic control devices of mobile bodies, primarily automobiles. Background Technology
[0002] In recent years, technologies such as V2X (Vehicle-to-Everything) communication, particularly vehicle-to-everything (V2X) and road-to-everything (Road-to-Traffic) communication, have garnered significant attention for driver assistance and autonomous driving control. Along with this, vehicles have acquired communication capabilities, and the so-called "vehicle connectivity" is constantly evolving. As a result, the possibility of vehicles being subjected to cyberattacks such as unauthorized access has increased. Therefore, it is necessary to analyze cyberattacks targeting vehicles and develop countermeasures.
[0003] Various methods exist for detecting anomalies generated in vehicles and analyzing network attacks based on the detected anomalies. For example, Patent Document 1 describes a method that detects anomalies caused by network attacks, collects data on the detected anomalies, and compares combinations of detected anomaly items with a pre-determined anomaly detection pattern for each attack to determine the type of network attack corresponding to the anomaly.
[0004] Furthermore, Patent Document 2 describes how the accuracy of determination and estimation can be improved by simultaneously using the survival signal of a security sensor in determining the type of network attack and estimating the attack path.
[0005] Patent Document 1: Japanese Patent Application Publication No. 2020-123307
[0006] Patent Document 2: Japanese Patent Application Publication No. 2023-6513
[0007] Here, the inventors have discovered the following issues.
[0008] As in Patent Document 2, a survival signal is periodically sent from the safety sensor, making it useful for determining whether the safety sensor itself is functioning correctly in a device that receives the survival signal. However, in electronic control devices equipped with safety sensors where the bus has a sleep function, an interruption of the survival signal does not necessarily indicate a malfunction of the safety sensor.
[0009] Furthermore, in log analysis devices that analyze logs to analyze the threat of network attacks, not all of the liveness signals themselves are required. As long as the information related to the estimation result is sufficient, it is enough to estimate the operation of the security sensor based on the reception status of the liveness signals. Summary of the Invention
[0010] Therefore, the purpose of this disclosure is to realize a log management device, etc., that provides log analysis devices with information useful for analyzing threats of network attacks.
[0011] The log management device disclosed herein includes:
[0012] The detection log receiving unit receives detection logs that represent the detection results of safety sensors installed in the vehicle's electronic control unit;
[0013] The life / death monitoring log receiving unit receives life / death monitoring logs indicating that the aforementioned safety sensors are in operation.
[0014] The liveness / death monitoring function detection log generation unit generates a liveness / death monitoring function detection log indicating the start and stop of the operation of the safety sensor based on the received liveness / death monitoring log; and
[0015] The output unit outputs the aforementioned live / dead monitoring function detection logs, as well as the aforementioned detection logs received during the first period.
[0016] Based on the structure described above, the log management device and the like disclosed herein can provide the log analysis device with information useful for analyzing threats of network attacks. Furthermore, it can reduce the amount of communication between the log management device and the log analysis device. Attached Figure Description
[0017] Figure 1 This is an explanatory diagram illustrating the configuration of the log management device in each implementation and its relationship with related devices.
[0018] Figure 2 This is an explanatory diagram illustrating the configuration of the log management device in each implementation and its relationship with related devices.
[0019] Figure 3 This is a block diagram illustrating the structural examples of the electronic control system in each implementation.
[0020] Figure 4 This is a block diagram illustrating the structural examples of the electronic control device in each embodiment.
[0021] Figure 5 This is an explanatory diagram illustrating the safety logs generated by the safety sensors of the electronic control device in each embodiment.
[0022] Figure 6 This is a block diagram illustrating a structural example of the log management device according to Embodiment 1.
[0023] Figure 7This is an explanatory diagram illustrating the action monitoring function of the log management device in Implementation Method 1 to detect the log generation action.
[0024] Figure 8 This is an explanatory diagram illustrating an example of the grouping period setting in Implementation Method 1.
[0025] Figure 9 This is an explanatory diagram illustrating the log of the sending object in Implementation Method 1.
[0026] Figure 10 This is an explanatory diagram illustrating the log of the sending object in Implementation Method 1.
[0027] Figure 11 This diagram illustrates the information sent by the output unit of Embodiment 1.
[0028] Figure 12 This is a flowchart illustrating the operation of the log management device in Implementation Method 1.
[0029] Figure 13 This is a block diagram illustrating a structural example of the log analysis device according to Embodiment 1.
[0030] Figure 14 This is a block diagram illustrating a structural example of the log management device according to Embodiment 2.
[0031] Figure 15 This is an explanatory diagram illustrating the log of the sending object in Implementation Method 2.
[0032] Figure 16 This diagram illustrates the information sent by the output unit of Embodiment 2. Detailed Implementation
[0033] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.
[0034] In the presence of multiple implementations (including variations and embodiments, the same applies here), the structures disclosed in each implementation are not limited to each implementation, but can be combined across implementations. For example, the structure disclosed in one implementation can be combined with other implementations. Alternatively, the structures disclosed in multiple implementations can be combined in a centralized manner.
[0035] 1. Prerequisite structure for each implementation method
[0036] (1) Configuration of the log management device and its relationship with related devices.
[0037] Figure 1 as well as Figure 2This diagram illustrates the configuration of the log management device in each implementation and its relationship with related devices. For example, assuming... Figure 1 As shown, the log management device 100 or the log management device 200 (hereinafter, they are collectively referred to as the log management device 100, etc.) is "mounted" in the "vehicle" together with the electronic control device 10 constituting the electronic control system S, and so on. Figure 2 As shown, the electronic control device 10 constituting the electronic control system S is "mounted" in the "vehicle," while the log management device 100 and the like are implemented by a server device or the like located outside the vehicle. In the embodiments described later, for example... Figure 1 The following explanation addresses the scenario where the log management device 100 is installed in a vehicle. Figure 2 In the case where the log management device 100 and the like are not mounted on the vehicle, the only difference is the communication method with the electronic control device 10. Therefore, the descriptions of each embodiment are cited.
[0038] "Vehicle" refers to an object that can move at any speed. It also includes vehicles that are stationary. For example, it includes cars, motorcycles, bicycles, and the objects that carry them, but is not limited to these.
[0039] "Mounted" includes not only cases where the item is directly attached to the vehicle, but also cases where it moves with the vehicle even though it is not attached to it. Examples include items carried by passengers or goods placed on the vehicle.
[0040] The log management device 100 and the like are connected to the "electronic control unit" (hereinafter referred to as ECU (Electronic Control Unit)) that constitutes the electronic control system. The log management device 100 and the like are devices that acquire and manage safety logs generated by safety sensors mounted on the multiple ECUs 10 that constitute the electronic control system S.
[0041] Here, "electronic control device" can refer not only to a physically independent electronic control device, but also to a virtualized electronic control device implemented using virtualization technology.
[0042] The log analysis device 20 is located outside the vehicle and receives security logs from the log management device 100, etc., and performs network attack detection and analysis by analyzing the logs. The log analysis device 20 is sometimes referred to as SOC (Security Operations Center).
[0043] exist Figure 1In this system, the electronic control system S and the log analysis device 20 are connected via communication networks using wireless communication methods such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), W-CDMA (Wideband Code Division Multiple Access), HSPA (High Speed Packet Access), LTE (Long Term Evolution), LTE-A (Long Term Evolution Advanced), 4G, and 5G. Alternatively, DSRC (Dedicated Short Range Communication) can be used. When the vehicle is parked in a parking lot or housed in a repair shop, wired communication methods can be used instead of wireless communication. For example, LAN (Local Area Network), the Internet, or a landline telephone line can be used.
[0044] In addition, the line can also combine wireless and wired communication methods. For example, the electronic control system S can be connected to the base station device in the cellular system via wireless communication methods such as 4G, while the base station device and the log analysis device 20 can be connected via wired communication methods such as the backbone line of a telecommunications operator or the Internet. A gateway device can also be set at the connection point between the backbone line and the Internet.
[0045] exist Figure 2 In this system, the electronic control system S is also connected to the log management device 100 located outside the vehicle via a communication network that uses the aforementioned wireless communication method and wired communication method.
[0046] In addition, Figure 2 In this document, the log management device 100 and the log analysis device 20 are described as different devices connected by a communication network, but the log management device 100 and the log analysis device 20 can also be implemented using the same device.
[0047] (2) Structure of the electronic control system S
[0048] Figure 3 This is a diagram illustrating an example of the structure of an electronic control system S. The electronic control system S consists of multiple ECUs 10 and an onboard network connecting them. Although Figure 3Eight ECUs (ECU10a to ECU10h) are shown as examples, but the electronic control system S can of course be composed of any number of ECUs. In the following description, when describing a single or multiple electronic control devices as a whole in general, they are referred to as ECU10, each ECU10, and when describing specific electronic control devices individually, they are referred to as ECU10a, ECU10b, ECU10c, ...
[0049] exist Figure 3 In this scenario, the various ECUs 10 are connected via in-vehicle communication networks such as CAN (Controller Area Network) or LIN (Local Interconnect Network). Alternatively, they can be connected using any wired or wireless communication method, such as Ethernet, Wi-Fi, or Bluetooth.
[0050] Furthermore, connectivity refers to the state in which data can be exchanged. This includes situations where different hardware is connected via wired or wireless communication networks, as well as situations where virtual ECUs (or virtual machines) implemented on the same hardware are virtually connected to each other.
[0051] Figure 3 The electronic control system S shown includes an integrated ECU 10a, an external communication ECU 10b, regional ECUs (10c, 10d), and independent ECUs (10e to 10h).
[0052] The integrated ECU 10a is an ECU that controls the entire electronic control system S and acts as a gateway to mediate communication between various ECUs. The integrated ECU 10a is sometimes also called a gateway ECU (G-ECU) or a mobile computer (MC). Additionally, the integrated ECU 10a can also be a relay device or a gateway device.
[0053] The external communication ECU 10b is an ECU with a communication unit that communicates with the log analysis device 20 located outside the vehicle. The external communication ECU 10b uses the aforementioned wireless communication method and wired communication method.
[0054] In addition, multiple external communication ECUs 10b can be set up to achieve multiple communication methods. Alternatively, the functions of external communication ECUs 10b can be included in the integrated ECU 10a instead of setting up external communication ECUs 10b.
[0055] Area ECUs (10c, 10d) are ECUs that have gateway functions appropriately configured according to the location and function of the individual ECUs. For example, area ECU 10c is an ECU that has a gateway function to mediate communication between the individual ECUs 10e and 10f located at the front of the vehicle and other ECUs 10, and area ECU 10d is an ECU that has a gateway function to mediate communication between the individual ECUs 10g and 10h located at the rear of the vehicle and other ECUs 10.
[0056] Independent ECUs (10e to 10h) can be composed of ECUs with arbitrary functions. Examples include drive system electronic control units that control the engine, steering wheel, brakes, etc.; vehicle system electronic control units that control the instrument panel, power windows, etc.; information system electronic control units that control navigation devices, etc.; and safety control system electronic control units that control collisions with obstacles or pedestrians. Furthermore, ECUs may not operate in parallel and can be classified as master and slave ECUs.
[0057] exist Figure 3 In the electronic control system S, each ECU 10 except ECU 10h is equipped with a safety sensor (hereinafter referred to as SS in the figure). Thus, it is not necessary to equip all ECU 10 constituting the electronic control system S with a safety sensor. The logs generated by the safety sensors will be discussed later.
[0058] In each embodiment, the case where the log management device 100 or the like is installed in the integrated ECU 10a will be described as an example. However, the log management device 100 or the like can also be installed in the external communication ECU 10b, the regional ECU (10c to 10d), or the independent ECU (10e to 10h). When installed in one of the independent ECUs (10e to 10h), it is preferable that the independent ECU is a dedicated ECU for implementing the log management device 100 or the like.
[0059] (3) Detection log and live / dead monitoring log
[0060] Figure 4 This is a block diagram showing the structure of an ECU (10a-10g) equipped with safety sensors. The ECU (10a-10g) has a log generation unit 11 and a transmission unit 12.
[0061] The log generation unit 11 generates two types of security logs: detection logs and live / dead monitoring logs.
[0062] Figure 5 This is a diagram representing a specific example of a security log.
[0063] The safety log contains fields representing the identification information of the ECU10 equipped with the safety sensor (ECUID), the identification information of the safety sensor (Sensor ID), the identification information of the safety event (Event ID), a counter indicating the number of times the event occurred, a timestamp indicating the time of the event, and context data representing the detailed output of the safety sensor. The safety log may also include a header storing information indicating the protocol version and the status of each field. An event refers to an object or phenomenon detected by the safety sensor.
[0064] The detection log is a security log generated when a safety sensor detects an anomaly; it represents the detection results of the safety sensor. For example, a detection log is generated when an anomaly caused by a cyberattack targeting each ECU10 equipped with a safety sensor is detected. In other words, the timing of detection log generation is when an anomaly is detected.
[0065] However, in addition to being generated when the security sensor detects an anomaly, the detection log can also be generated when it is detected as normal.
[0066] In contrast, the live / dead monitoring log is a safety log indicating that a safety sensor is "in action." The live / dead monitoring log is a safety log generated to infer that a safety sensor is in action based on the fact that a log is being generated.
[0067] The liveness / death monitoring log is sometimes referred to as liveness signal, keep-alive information, or heartbeat information.
[0068] Here, "in action" means that it is sufficient to directly or indirectly determine that the safety sensor is in action.
[0069] It can also monitor logs in both dead and live modes. Figure 5 That's the structure. In this case, for example, by setting the event ID to a value inherent to the live / dead monitoring log, it can be determined that the safety log is a live / dead monitoring log. For example, if the event ID consists of sixteen bits, it can also be indicated as a live / dead monitoring log by setting the top four bits to 1 (i.e., 0xF*** (* is any number) in hexadecimal representation). Alternatively, a different ID can be assigned to an ID other than the event ID, such as the ECU ID, sensor ID, or any combination of the three IDs.
[0070] Alternatively, you can omit the context data field in the live / dead monitoring log. However, you can also define a live / dead monitoring log by setting a context data field and storing information indicating that it is a live / dead monitoring log within the context data. Additionally, you can store information inherent to the security sensor, security sensor configuration information, and other meaningful information within the context data.
[0071] The timing of generating the liveness / death monitoring log is independent of the detection of anomalies by the safety sensors. For example, the log can be generated at constant intervals, such as every ten seconds or every minute. Alternatively, it can also be generated at specific times, such as when the vehicle's ignition switch is turned on. Furthermore, the constant interval can be determined based on conditions, in addition to being always constant.
[0072] Although the life / death monitoring log is generated and transmitted by the safety sensor in various embodiments, it can also be generated and transmitted by other processes or other ECUs 10 that monitor the safety sensor, as the life / death monitoring log.
[0073] Back Figure 4 The sending unit 12 sends the safety log generated by the log generation unit 11 to the log management device 100, etc., via the vehicle network. When the safety sensor and the log management device 100, etc., are mounted on the same ECU 10, the log is directly output to the hardware or software implementing the log management device 100, etc., without going through the vehicle network.
[0074] Furthermore, the security logs generated by the security sensors are called SEv, and the qualified security logs that have been filtered are called QSEv. For example, when a security sensor generates an SEv and reports it to the Intrusion Detection System Manager (IdsM), the SEv passes the authentication filter in the IdsM and meets specified criteria, and is then sent as a QSEv from the Intrusion Detection Reporter to the outside of the vehicle. The security logs in each implementation include the concepts of SEv and QSEv.
[0075] In the case of security log QSEv, the scope including the intrusion detection system manager (IdsM) corresponds to the log generation unit 11, and the intrusion detection reporter corresponds to the sending unit 12.
[0076] 2. Implementation Method 1
[0077] (1) Structure of Log Management Device 100
[0078] Figure 6This is a block diagram illustrating the structure of the log management device 100 in this embodiment. The log management device 100 includes a detection log receiving unit 101, a live / dead monitoring log receiving unit 102, a storage unit 103, a control unit 104, and an output unit 108. The control unit 104 implements the live / dead monitoring function via hardware and / or software, along with a detection log generation unit 105, a threat detection unit 106, and an output target determination unit 107.
[0079] The log management device 100 can be composed of a general-purpose CPU (Central Processing Unit), volatile memory such as RAM, non-volatile memory such as ROM, flash memory, or hard disk, various interfaces, and an internal bus connecting them. Furthermore, it can be configured to perform functions by executing software on this hardware. Figure 6 The functions of each functional module are described. The log analysis device 20 and the log management device 200 of Embodiment 2 are also the same.
[0080] The detection log receiving unit 101 receives detection logs representing the detection results of the safety sensors of the ECU 10. Detection logs are obtained from safety sensors mounted on the ECU 10 other than the integrated ECU 10a equipped with the log management device 100 via the vehicle network, and from safety sensors mounted on the integrated ECU 10a directly without using the vehicle network.
[0081] The liveness / death monitoring log receiving unit 102 receives liveness / death monitoring logs. Alternatively, the detection log receiving unit 101 and the liveness / death monitoring log receiving unit 102 can also be implemented by a single receiving unit.
[0082] Storage unit 103 stores the detection logs received by detection log receiving unit 101 and the life / death monitoring logs received by life / death monitoring log receiving unit 102. Storage unit 103 can be any of an external storage device (hard disk, USB memory, CD / BD, etc.) or an internal storage device (RAM, etc.). Furthermore, it can be either volatile or non-volatile.
[0083] In addition, the storage unit 103 also stores the dead / live monitoring function detection log and detection log determined by the output object determination unit 107, which will be described later.
[0084] The liveness / death monitoring function detection log generation unit 105 generates a liveness / death monitoring function detection log indicating the start and stop of the safety sensor's operation based on the "reception status" of the liveness / death monitoring log in the liveness / death monitoring log receiving unit 102. More specifically, if the liveness / death monitoring function detection log generation unit 105 does not receive a liveness / death monitoring log during a predetermined period (equivalent to a "second period"), it generates an operation stop detection log as a liveness / death monitoring function detection log. In addition, when a liveness / death monitoring log is initially received, or when a liveness / death monitoring log is received again after the generation of the operation stop detection log, an operation start detection log as a liveness / death monitoring function detection log is generated.
[0085] Here, "reception status" can refer not only to the reception status of the liveness / death monitoring log itself, but also to the content of the liveness / death monitoring log.
[0086] Figure 7 This diagram illustrates the operation of the liveness / death monitoring function detection log generation unit 105. Figure 7 In (a), the liveness / death monitoring log receiving unit 102 receives liveness / death monitoring logs every minute. Then, if no liveness / death monitoring logs are received during a predetermined period (equivalent to the "second period"), for example, five minutes, an action stop detection log is generated.
[0087] exist Figure 7 In (b), it is assumed that the dead / live monitoring log receiving unit 102 does not receive the dead / live monitoring log for a period of time after the generation of the action stop detection log. Then, when the dead / live monitoring log receiving unit 102 receives the dead / live monitoring log again, it generates the action start detection log.
[0088] Furthermore, the specified period (equivalent to the "second period") is preferably "longer" than the grouping period (equivalent to the "first period"). However, it is preferable that the difference between the two be small. For example, if the former is five minutes and the latter is four minutes and fifty seconds, the difference should be set to within ten seconds.
[0089] Here, "relatively long" includes both cases that include the same period as the specified period (≧) and cases that do not include the specified period (>).
[0090] Action stop detection logs and action start detection logs can also be included. Figure 5 That kind of structure. For example, by setting the event ID to the inherent values of the action stop detection log and the action start detection log, it is possible to determine whether it is the action stop detection log or the action start detection log.
[0091] Additionally, it is preferable to include information about the safety sensor that caused the dead / live monitoring log to be generated in the context data of the action stop detection log and the action start detection log. For example, it may also include the ECUID, sensor ID, and event ID of the safety sensor represented by the dead / live monitoring log, or at least one of them. In this way, action stop detection logs and action start detection logs can be generated for each ECU10 or safety sensor.
[0092] Furthermore, the latest moment when the dead / live monitoring log was received can also be included in the action stop detection log. Additionally, the moment when the dead / live monitoring log was received can also be included in the action start detection log.
[0093] The threat detection unit 106 determines whether the single or multiple detection logs received by the detection log receiving unit 101 meet predetermined conditions. For example, the storage unit 103 stores a pattern matching table that records combinations of anomalies represented by the detection logs and their relationships with corresponding network attacks. Furthermore, it determines whether the single or multiple detection logs received by the detection log receiving unit 101 match the patterns recorded in the pattern matching table; if they match, it infers the existence of a network attack threat.
[0094] Examples of the conditions specified in the pattern matching table include receiving a specific combination of detection logs, receiving a specified number of detection logs within a specified period, etc., but are not limited to these.
[0095] If the threat detection unit 106 determines that the specified conditions are met, the output target determination unit 107 determines the scope of the security logs to be sent from the output unit 108 (described later). The output destination is either the log analysis device 20 or the storage unit 103; the target is determined in the former case and the target is determined in the latter case. It is possible to determine whether to send to the log analysis device 20, output, or save to the storage unit 103 based on any criteria. Although this embodiment describes the case of sending to the log analysis device 20 as an example, the operation is basically the same in the case of output to the storage unit 103.
[0096] In this embodiment, the output target determination unit 107 sets a grouping period (equivalent to a "first period") as the time range for sending detection logs. Specifically, the moment when the threat detection unit 106 determines that the detection log meets the prescribed conditions is set as the trigger moment. In the case of a combination of multiple detection logs, the moment when the last received detection log is set as the trigger moment. Then, the grouping period is set based on the trigger moment.
[0097] Figure 8This diagram illustrates an example of the grouping process. Figure 8 In this scenario, three detection logs are assumed to meet specified conditions. In this case, the reception time of the last received detection log is set as the trigger time. Then, the T1 period before the trigger time and the T2 period after the trigger time are set together as the packet duration. The lengths of the T1 and T2 periods are preferably predetermined based on the type of network attack, but can also be determined using other methods.
[0098] Then, the output object determination unit 107 determines the dead / live monitoring function detection log generated by the dead / live monitoring function detection log generation unit 105 and the detection log received by the detection log receiving unit 101 during the grouping period as the security log to be sent from the output unit 108. In this embodiment, the dead / live monitoring function detection log to be sent is set to the latest dead / live monitoring function detection log generated "before the trigger time".
[0099] Here, "before the triggering time" includes both cases that include the triggering time (≧) and cases that do not include it (>).
[0100] Figure 9 This is an example of a log used to monitor the life or death of the sending object.
[0101] First of all, Figure 9 (a)~ Figure 9 In (e), all detection logs during the grouping period are sent to the target. These detection logs naturally include those that the threat detection unit 106 determines meet the prescribed conditions.
[0102] Figure 9 (a) is the case where the latest live / dead monitoring function detection log, generated before the trigger time, was generated before the grouping period. In this case, if the live / dead monitoring function detection log is an action start detection log, it can be known that the safety sensor is in action during the grouping period; if the live / dead monitoring function detection log is an action stop detection log, it can be known that the safety sensor is stopped during the grouping period.
[0103] Figure 9 (b) is the case where the latest live / dead monitoring function detection log, generated before the trigger time, is generated during the grouping period. In this case, if the live / dead monitoring function detection log is an action start detection log, it can be seen that although the safety sensor stopped at the start of the grouping period, the safety sensor was in operation after the generation of the action start detection log.
[0104] That is, such as Figure 9 (a) and Figure 9As shown in (b), it doesn't matter whether the dead / live monitoring function detection log is generated during or before the grouping period, as long as it is before the triggering time.
[0105] In addition, Figure 9 In case (b), the latest detection log for the live / dead monitoring period, generated before the public release during the grouping period, can also be set as the sending target. That is, as Figure 9 As in (c), set the two live / dead monitoring function detection logs as the sending object.
[0106] In addition, Figure 9 Case (a) Figure 9 In case (b), other live / dead monitoring function detection logs generated during the grouping period can also be set as the sending object as the regular detection logs. For example, such as Figure 9 As in (d), the live / dead monitoring function detection log (log G in the diagram) generated during the grouping period and after the trigger time can also be set as the sending object as the normal detection log. Additionally, as... Figure 9 As in (e), the dead / live monitoring function detection log generated during the grouping period, other than the latest dead / live monitoring function detection log generated before the triggering time (log of G in the figure), can also be set as the sending object as the normal detection log.
[0107] exist Figure 9 In this case, the focus is on a single ECU10 and safety sensor, but there are usually multiple ECUs and multiple safety sensors. In this situation, the sending target is also determined for each ECU10 and safety sensor.
[0108] Figure 10 This is an example of a safety log that is sent when four ECUs (ECU10a, ECU10b, ECU10c, and ECU10d) are present. Furthermore, in the diagram, the action start detection log in the life / death monitoring function detection log is marked with the word "Start," and the action stop detection log is marked with the word "Stop." Additionally, the labels a, b, c, and d on the life / death monitoring function detection log and the detection logs indicate which ECU generated the log.
[0109] exist Figure 10In this context, the trigger time and grouping period are set based on the detection logs (ct) that meet the specified conditions. Here, for the latest live / dead monitoring function detection logs generated before the trigger time, ECU10a is the action start detection log (a), ECU10b is the action stop detection log (b), ECU10c is the action start detection log (c), and ECU10d is the action stop detection log (d), therefore these live / dead monitoring function detection logs are determined to be the transmission targets. Additionally, detection logs received during the grouping period are also determined to be the transmission targets. Figure 10 The detection logs included during the grouping process are those received from ECU10c and ECU10d. Additionally, the detection logs may also include those generated by ECU10 other than ECU10a to ECU10d.
[0110] also, Figure 10 The lower half of the function of the log analysis device 20 will be described later.
[0111] Back Figure 6 The output unit 108 outputs the security log determined by the output target determination unit 107. That is, if the output destination is the log analysis device 20, it is sent to the log analysis device 20. If the output destination is the storage unit 103, it is output to the storage unit 103 and the storage unit stores the security log. In this embodiment, the case of sending to the log analysis device 20 will be described as an example.
[0112] Furthermore, when the output unit 108 sends security logs to the log analysis device 20, all security logs determined by the output target determination unit 107 are sent, but alternatively, only a portion of them may be sent. The scope of the transmission can be determined by the output target determination unit 107 or the output unit 108, or by an external device such as a diagnostic device or an external server.
[0113] For example, when the log management device 100 is implemented by the integrated ECU 10a, the output unit 108 sends data to the log analysis device 20 via the external communication ECU 10b. In this embodiment, the dead / live monitoring function detection log and the detection log received during the grouping period (equivalent to the "first period") are sent. Preferably, the dead / live monitoring function detection log sent is the latest dead / live monitoring function detection log generated before the triggering time.
[0114] Figure 11 This is an example of the information sent by the output unit 108.
[0115] Output unit 108 first sends the liveness / death monitoring function detection log, followed by the detection log. The logs are sent in the order of their generation and receipt. Alternatively, the liveness / death monitoring function detection log and the detection log can be sent in either the order of their generation or receipt, without distinguishing between them.
[0116] The output unit 108 may also send information indicating the number of ECUs 10 or safety sensors that are among the objects of the live / dead monitoring function detection log. Figure 11 In this case, since there are four transmission sources identified by ECU10a to ECU10d, the number of ECUs / SSs is 4.
[0117] The output unit 108 can also associate the generation time of the liveness / death monitoring function detection log and the reception time of the detection log with each log and send them. Figure 11 In this case, time information indicating the generation and reception times is sent immediately after each log entry.
[0118] Furthermore, in this embodiment, since the live / death monitoring function detection log is sent, the live / death monitoring log received by the live / death monitoring log receiving unit 102 is not sent to the log analysis device 20.
[0119] In addition, the output unit 108 automatically sends the liveness / death monitoring function detection log and the detection log. However, the output unit 108 may also send the liveness / death monitoring function detection log and the detection log in response to a request from the log analysis device 20.
[0120] (2) Operation of log management device 100
[0121] Next, refer to Figure 12 The operation of the log management device 100 is explained. Figure 12 This paper not only illustrates the log management method executed by the log management device 100, but also the processing flow of a log management program that can be executed by the log management device 100. Furthermore, these processes are not limited to… Figure 12 The order shown is as follows. That is, as long as there is no constraint such as a relationship where a step utilizes the result of a previous step, the order can be changed. The same applies to other implementations.
[0122] The detection log receiving unit 101 receives a detection log (S101) indicating the detection results of the safety sensors mounted on the ECU 10 of the vehicle.
[0123] The life / death monitoring log receiving unit 102 receives the life / death monitoring log indicating that the safety sensor is in operation (S102).
[0124] The dead / live monitoring function detection log generation unit 105 generates a dead / live monitoring function detection log (S103) indicating the start and stop of the operation of the safety sensor based on the reception status of the dead / live monitoring log received in S102.
[0125] The output unit 108 outputs the dead / live monitoring function detection log generated by S103, and the detection log received by S101 during the first period (S104).
[0126] (3) Structure and operation of log analysis device 20
[0127] Figure 13 This is a block diagram showing the structure of the log analysis device 20 in this embodiment. The log analysis device 200 includes a receiving unit 201 and an event generation determination unit 202.
[0128] The receiving unit 201 receives the dead / live monitoring function detection log and detection log sent from the log management device 100.
[0129] The event occurrence determination unit 202 uses the liveness / death monitoring function detection log and detection log received by the receiving unit 201 to determine whether an event has occurred in the ECU or safety sensor. In particular, in this embodiment, the existence and likelihood of an event are determined based on whether the liveness / death monitoring function detection log is an action start detection log or an action stop detection log, and the combination of the presence and absence of detection logs.
[0130] use Figure 10 The second half explains the determination method related to the occurrence of events in the ECU and safety sensors. As already explained, the log management device 100 sends... Figure 10 The log analysis device 20 receives the recorded live / dead monitoring function detection logs and detection logs.
[0131] Moreover, according to Figure 10 ECU10a to ECU10d can make a determination based on the type of detection log and whether there is a detection log, as follows.
[0132] ECU10a generates an action start detection log, but no detection log is generated during the grouping period. That is, although the safety sensor is in action, it can be evaluated as no abnormal event has occurred based on the fact that the safety sensor is operating normally and no abnormal event has been detected. Therefore, it can be determined that no event has occurred in ECU10a.
[0133] ECU10b generates an action stop detection log, but no detection log is generated during the grouping period. That is, although no detection log is generated because the safety sensor did not act, it can be evaluated as an event that may cause an anomaly, and therefore it can be determined that an event may occur in ECU10b.
[0134] ECU10c generates an action start detection log, which is generated during the grouping process. That is, when a safety sensor is performing an action that can be evaluated as normal, it detects an abnormal event, and therefore it can be determined that an event has occurred in ECU10c.
[0135] ECU10d generates an action stop detection log during grouping. That is, although a detection log is generated regardless of whether the safety sensor has not acted, it can be determined that an event occurred in ECU10d because a safety sensor that was functioning normally detected an abnormal event. However, it can be determined that the generation and transmission / reception functions of the live / dead monitoring function detection log may have caused some malfunctions.
[0136] (4) Summary
[0137] According to this embodiment, a live / dead monitoring function detection log indicating the start and stop of a safety sensor's operation is generated based on the reception status of the live / dead monitoring log, and this log is sent to the log analysis device. Therefore, information related to the safety sensor's operation can be provided to the log analysis device, which can then make determinations related to the occurrence of events in the ECU and the safety sensor based on this information. Furthermore, since the live / dead monitoring function detection log is sent, it is unnecessary to send the live / dead monitoring log itself, thus reducing the communication load between the log management device and the log analysis device.
[0138] According to this embodiment, two types of logs, namely, action stop detection log and action start detection log, are generated and sent as detection logs for the dead / live monitoring function. Therefore, the log analysis device can use information that directly represents the action of the safety sensor to make more detailed judgments related to the occurrence of the event.
[0139] According to this embodiment, since the grouping period is set based on the trigger time, detection logs related to network attacks can be collected extensively and provided to the log analysis device. In particular, since the grouping period is set to include the period before and after the trigger time, detection logs indicating precursors to network attacks and detection logs after the network attack have occurred can be provided to the log analysis device, enabling the log analysis device to identify the correct network attack and seek countermeasures.
[0140] According to this embodiment, since the latest live / dead monitoring function detection log generated before the triggering time is sent, the live / dead monitoring function detection log that best reflects the operation status of the security sensor during the grouping period can be provided to the log analysis device.
[0141] According to this embodiment, since the liveness / death monitoring function detection log generated during the grouping period is sent, information such as the changes in the operational status of the safety sensors during the grouping period can be provided to the log analysis device.
[0142] According to this embodiment, since the liveness / death monitoring function detection log and detection log are sent spontaneously, information can be quickly provided to the log analysis device when the possibility of a network attack is high. The log analysis device can quickly identify the network attack and seek countermeasures.
[0143] 3. Implementation Method 2
[0144] The log management device 100 of Implementation 1 sets the grouping period based on the trigger time, and sets the latest dead / live monitoring function detection log generated before the trigger time as the sending object.
[0145] In the log management device 200 of this embodiment, the sending target is determined based on the travel period determined by the change in the vehicle's power state. For example, the travel period is defined as the period from when the ignition switch (IG) is turned on to when it is turned off. As another example of the travel period, the period from when the accessory power is turned on to when it is turned off can be given, but of course, other power states can also be used.
[0146] Alternatively, the recipients can be determined by focusing on regular periods such as 24 hours or 5 days, or by the usage period of any function integrated into the vehicle. In such cases, safety logs cannot be received or generated when the vehicle's power is off, so these periods can be considered as trip periods. Even if these periods span multiple trip periods, each remains a trip period.
[0147] (1) Structure of Log Management Device 200
[0148] Figure 14 This is a block diagram illustrating the structure of the log management device 200 in this embodiment. The same structure as the log management device 100 in Embodiment 1 is used. Figure 6 The same structural numbering is used, and the description and drawings of Embodiment 1 are referenced.
[0149] The log management device 200 includes a detection log receiving unit 101, a live / dead monitoring log receiving unit 102, a storage unit 103, a control unit 204, and an output unit 208. The control unit 204 implements the live / dead monitoring function through hardware and / or software, and includes a detection log generation unit 105 and an output object determination unit 207.
[0150] The output target determination unit 207 determines the range of security logs output from the output unit 208. Similar to Embodiment 1, the output destination is either the log analysis device 20 or the storage unit 103; the sending target is determined in the former case, and the storage target is determined in the latter case. Although this embodiment describes the case of sending to the log analysis device 20 as an example, the operation is basically the same when the output is to the storage unit 103.
[0151] In this embodiment, the travel period from when the vehicle's IG is turned on to when it is turned off (equivalent to the "first period") is set as the time range for the detection log sent by the output target determination unit 207.
[0152] Furthermore, the output object determination unit 207 determines the liveness / death monitoring function detection log generated by the liveness / death monitoring function detection log generation unit 105 and the detection log received by the detection log receiving unit 101 during the trip as the safety log to be sent from the output unit 208. In this embodiment, the liveness / death monitoring function detection log to be sent is set to the liveness / death monitoring function detection log generated during the trip.
[0153] Figure 15 This is an example of a safety log that is sent when two ECUs, ECU10a and ECU10b, are present. Furthermore, in the diagram, the action start detection log in the life / death monitoring function detection log is marked with the word "Start," and the action stop detection log is marked with the word "Stop." Additionally, the labels "a" and "b" on the life / death monitoring function detection log and the detection log indicate which ECU generated the log.
[0154] exist Figure 15 During the process, the following logs are generated sequentially: ECU10a's action start detection log a, ECU10b's action start detection log b, ECU10a's action stop detection log a, ECU10b's action stop detection log b, and ECU10a's action start detection log a. Therefore, these liveness / death monitoring function detection logs are determined to be the recipients of the transmission. Additionally, detection logs received during the process are also determined to be the recipients of the transmission. Figure 15 The detection logs included during the trip are two detection logs received from ECU10b.
[0155] also, Figure 15 The lower half of the function of the log analysis device 20 will be described later.
[0156] Back Figure 14 The output unit 208 sends the safety log determined by the output object determination unit 207 to the log analysis device 20. In this embodiment, the dead / live monitoring function detection log and the detection log received during the process (equivalent to the "first period") are sent.
[0157] Figure 16 This is an example of the information sent by the output unit 208.
[0158] Output unit 208 sends the liveness / death monitoring function detection log and the detection log. In this embodiment, the order in which the liveness / death monitoring function detection log and the detection log are sent is not distinguished; they are sent in the order of generation time or the order of reception time.
[0159] The output unit 208 may also send information indicating the number of ECUs 10 or safety sensors that are among the objects of the live / dead monitoring function detection log. Figure 11 In this case, since there are two transmitting sources identified by ECU10a to ECU10b, the number of ECUs / SSs is 2.
[0160] The output unit 208 can also send the generation time of the liveness / death monitoring function detection log and the reception time of the detection log in association with each log. Figure 16 In this case, time information indicating the generation and reception times is sent immediately after each log entry.
[0161] Furthermore, in this embodiment, since the live / death monitoring function detection log is sent, the live / death monitoring log received by the live / death monitoring log receiving unit 102 is not sent to the log analysis device 20.
[0162] Furthermore, the output unit 208 sends the liveness / death monitoring function detection log and the detection log according to a request from the log analysis device 20. For example, it may send the liveness / death monitoring function detection log and the detection log for one or more trips included in the past ten days. However, the output unit 208 may also send the liveness / death monitoring function detection log and the detection log automatically.
[0163] (2) Operation of log management device 200
[0164] The operation of log management device 200 is the same as that of log management device 100, therefore... Figure 12 And its explanation.
[0165] (3) Structure and operation of log analysis device 20
[0166] The log analysis device 20 of this embodiment has the same structure as the log analysis device 20 of Embodiment 1, therefore, it is referred to as... Figure 13 And its explanation.
[0167] use Figure 15 The method for detecting anomalies in security sensors is explained. As already explained, the log management device 200 sends... Figure 15 The log analysis device 20 receives the recorded live / dead monitoring function detection logs and detection logs.
[0168] Moreover, according to Figure 15 ECU10a to ECU10b can make a determination based on the type of detection log and whether there is a detection log, as follows.
[0169] ECU10a generates an action start detection log at the beginning of period t1 and at the beginning of period t3, but no detection log is generated during these periods. That is, although the safety sensor is operating, it can be evaluated as no abnormal event has occurred based on the fact that the safety sensor is operating normally and no abnormal event has been detected. Therefore, it can be determined that no event has occurred in ECU10a.
[0170] ECU10a generates an action stop detection log at the beginning of period t2, but no detection log is generated during period t2. That is, although no detection log is generated because the safety sensor did not activate, it can be evaluated as an event that may cause an anomaly, and therefore it can be determined that an event may occur in ECU10a.
[0171] ECU10b generates an action start detection log at the beginning of period t4 and a detection log during period t4. That is, if a safety sensor is performing an action that can be evaluated as normal, and the safety sensor detects an abnormal event, it can be determined that an event has occurred in ECU10b.
[0172] ECU10b generates an action stop detection log at the beginning of period t5 and a detection log during period t5. That is, although a detection log is generated regardless of whether the safety sensor has not acted, an event can be assessed as a safety sensor that is normally functioning detecting an abnormality, and therefore can be determined as an event occurring in ECU10b. However, it can be determined that the generation and transmission / reception functions of the liveness / death monitoring function detection log may have caused some malfunctions.
[0173] (4) Summary
[0174] According to this embodiment, a live / dead monitoring function detection log indicating the start and stop of a safety sensor's operation is generated based on the reception status of the live / dead monitoring log, and this log is sent to the log analysis device. Therefore, information related to the safety sensor's operation can be provided to the log analysis device, which can then make determinations related to the occurrence of events in the ECU and the safety sensor based on this information. Furthermore, since the live / dead monitoring function detection log is sent, it is unnecessary to send the live / dead monitoring log itself, thus reducing the communication load between the log management device and the log analysis device.
[0175] According to this embodiment, two types of logs, namely, action stop detection log and action start detection log, are generated and sent as detection logs for the dead / live monitoring function. Therefore, the log analysis device can use information that directly represents the action of the safety sensor to make more detailed judgments related to the occurrence of the event.
[0176] According to this embodiment, since a trip period is set, detection logs related to network attacks can be collected extensively and provided to the log analysis device.
[0177] According to this embodiment, since the liveness / death monitoring function detection log generated during the trip is sent, the changes in the operating status of the safety sensors during the trip can be provided to the log analysis device.
[0178] According to this embodiment, since the dead / liveness monitoring function detection log and detection log are sent according to the request from the log analysis device, only the security logs that the log analysis device determines are needed are sent, which can reduce the amount of communication.
[0179] 4. Summary
[0180] The features of the log management device and the like in various embodiments of the present invention have been described above.
[0181] The statements used in each implementation are exemplified, and can also be replaced with synonymous statements or statements containing synonymous functions.
[0182] The block diagrams used in the description of the implementation methods categorize and organize the structure of the device according to each function. The modules representing each function are implemented through any combination of hardware or software. Furthermore, since these block diagrams represent functions, they can also be understood as disclosures of inventions of methods and programs for implementing those methods.
[0183] For functional modules that can be mastered as the processes, procedures and methods described in each implementation, the order can be changed as long as there is no constraint such as the relationship between the result of other steps in a step and the result of the previous step.
[0184] The first, second, and Nth statements (where N is an integer) are used to distinguish between two or more structures or methods of the same kind, and do not restrict their order or superiority.
[0185] Furthermore, the following examples can be cited as examples of the log management device of the present invention.
[0186] Examples of components include semiconductor elements, electronic circuits, modules, and microcomputers.
[0187] Examples of semi-finished products include electronic control units (ECUs) and system boards.
[0188] Examples of finished products include mobile phones, smartphones, tablets, personal computers (PCs), workstations, and servers.
[0189] In addition, it includes devices with communication functions, such as cameras, still cameras, and car navigation systems.
[0190] Additionally, necessary functions such as antennas and communication interfaces can be added to the log management device.
[0191] In particular, by using the log management device of the present invention on the server side, it can be used to provide various services. Along with the provision of such services, the log management device of the present invention, the method of the present invention, and / or the program of the present invention are used.
[0192] In addition, the present invention can be implemented not only by dedicated hardware having the structure and functions described in the various embodiments, but also as a combination of a program for implementing the present invention recorded on a recording medium such as a memory or hard disk, and general-purpose hardware having a dedicated or general-purpose CPU and memory capable of executing the program. The program stored on a non-transferable physical recording medium of the dedicated or general-purpose hardware (e.g., an external storage device (hard disk, USB memory, CD / BD, etc.) or an internal storage device (RAM, ROM, etc.)) can also be provided to the dedicated or general-purpose hardware via the recording medium, or from a server via a communication line without using the recording medium. Thus, the latest functionality can always be provided through program upgrades.
[0193] The log management device of the present invention is primarily aimed at a device for analyzing cyberattacks on electronic control systems installed in automobiles, but it can also be aimed at a device for analyzing attacks on general systems not installed in automobiles.
Claims
1. A log management device, wherein, have: The detection log receiving unit receives detection logs that represent the detection results of safety sensors installed in the vehicle's electronic control unit; The life / death monitoring log receiving unit receives life / death monitoring logs indicating that the aforementioned safety sensors are in operation. The dead / live monitoring function detection log generation unit generates a dead / live monitoring function detection log indicating the start and stop of the operation of the safety sensor based on the reception status of the dead / live monitoring log. as well as The output unit outputs the aforementioned live / dead monitoring function detection logs, as well as the aforementioned detection logs received during the first period.
2. The log management device according to claim 1, wherein, For the aforementioned live / dead monitoring function detection log generation unit, If no liveness / death monitoring log is received during the second period, an action stop detection log is generated as the liveness / death monitoring function detection log. When the aforementioned life / death monitoring log is first received, or when the aforementioned life / death monitoring log is received again after the aforementioned action stop detection log is generated, an action start detection log is generated as the aforementioned life / death monitoring function detection log.
3. The log management device according to claim 1, wherein, The output unit outputs the above-mentioned live / dead monitoring function detection log and the above-mentioned detection log for each of the above-mentioned electronic control devices or the above-mentioned safety sensors.
4. The log management device according to claim 1, wherein, The output unit also sends information indicating the number of the aforementioned electronic control devices or safety sensors that are the objects of the aforementioned life / death monitoring function detection log.
5. The log management device according to claim 1, wherein, The output unit sends the detection log after the detection log of the above-mentioned life / death monitoring function.
6. The log management device according to claim 1, wherein, The output unit also sends time information as the time when the above-mentioned dead / live monitoring function detection log is generated.
7. The log management device according to claim 1, wherein, The aforementioned output unit does not send the aforementioned live / dead monitoring logs to the log analysis device.
8. The log management device according to claim 1, wherein, It also includes a threat detection unit, which determines whether one or more detection logs received by the detection log receiving unit meet the prescribed conditions. The first period is set based on the trigger time of the receiving time of the detection log, which is a condition that meets the above-mentioned requirements.
9. The log management device according to claim 8, wherein, The aforementioned first period includes the period before and after the aforementioned triggering time.
10. The log management device according to claim 9, wherein, The output section outputs the latest detection log of the aforementioned life / death monitoring function generated before the aforementioned trigger time.
11. The log management device according to claim 9, wherein, The output unit outputs the detection log of the dead / live monitoring function generated during the first period as the detection log.
12. The log management device according to claim 10 or 11, wherein, The output unit automatically sends the detection logs of the above-mentioned live / dead monitoring function and the above-mentioned detection logs to the log analysis device.
13. The log management device according to claim 8, wherein, If the aforementioned live / death monitoring function detection log generation unit does not receive the aforementioned live / death monitoring log during the second period, it generates an action stop detection log, which serves as the aforementioned live / death monitoring function detection log. The second period mentioned above is longer than the first period mentioned above.
14. The log management device according to any one of claims 1 to 11, wherein, The aforementioned first period is the travel period determined based on changes in the power supply status of the aforementioned vehicles.
15. The log management device according to claim 14, wherein, The output unit will output the detection log of the dead / live monitoring function generated during the first period as the detection log.
16. The log management device according to claim 15, wherein, In response to a request from the log analysis device, the output unit sends the dead / live monitoring function detection log and the detection log to the log analysis device.
17. The log management device according to any one of claims 1 to 11, wherein, The log management device is installed in the aforementioned vehicle.
18. The log management device according to any one of claims 1 to 11, wherein, The log management device is located on the exterior of the aforementioned vehicle.
19. A log management method, which is a log management method executed by a log management device, wherein, Receive detection logs representing the detection results of safety sensors installed in the vehicle's electronic control unit. Receive live / dead monitoring logs indicating whether the aforementioned safety sensors are in operation. Based on the received status of the aforementioned live / death monitoring logs, a live / death monitoring function detection log is generated, indicating the start and stop of the aforementioned safety sensor's operation. Output the detection logs of the aforementioned live / dead monitoring function, as well as the aforementioned detection logs received during the first period.
20. A log management program product, which is a log management program product that can be executed through a log management device, wherein, This log management program product enables the aforementioned log management device to perform the following processes: Receive detection logs representing the detection results of safety sensors installed in the vehicle's electronic control unit. Receive live / dead monitoring logs indicating whether the aforementioned safety sensors are in operation. Based on the received status of the aforementioned live / death monitoring logs, a live / death monitoring function detection log is generated, indicating the start and stop of the aforementioned safety sensor's operation. Output the detection logs of the aforementioned live / dead monitoring function, as well as the aforementioned detection logs received during the first period.
21. A log management system, comprising a log management device and a log analysis device, wherein, The above-mentioned log management device has the following features: The detection log receiving unit receives detection logs that represent the detection results of safety sensors installed in the vehicle's electronic control unit; The life / death monitoring log receiving unit receives life / death monitoring logs indicating that the aforementioned safety sensors are in operation. The dead / live monitoring function detection log generation unit generates a dead / live monitoring function detection log based on the reception status of the dead / live monitoring log. The log consists of an action start detection log indicating the start of the operation of the safety sensor and an action stop detection log indicating the stop of the operation of the safety sensor. as well as The output unit outputs the aforementioned live / dead monitoring function detection logs, as well as the aforementioned detection logs received during the first period. The above-mentioned log analysis device has the following features: The receiving unit receives the aforementioned live / dead monitoring function detection logs and the aforementioned detection logs; and The event determination unit determines the occurrence of an event in the electronic control device or the safety sensor based on whether the above-mentioned life / death monitoring function detection log is the above-mentioned action start detection log or the above-mentioned action stop detection log, or whether there is a combination of the above-mentioned detection logs.
Citation Information
Patent Citations
Security device, attack specification method, and program
JP2020123307A
Attack analysis device, attack analysis method, and attack analysis program
JP2023006513A