WO2022190408A1 - 分析装置 - Google Patents

分析装置 Download PDF

Info

Publication number
WO2022190408A1
WO2022190408A1 PCT/JP2021/031266 JP2021031266W WO2022190408A1 WO 2022190408 A1 WO2022190408 A1 WO 2022190408A1 JP 2021031266 W JP2021031266 W JP 2021031266W WO 2022190408 A1 WO2022190408 A1 WO 2022190408A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
notification
abnormality
analysis device
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2021/031266
Other languages
English (en)
French (fr)
Inventor
伸義 森田
康広 藤井
正 矢野
幹雄 片岡
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Astemo Ltd
Original Assignee
Hitachi Astemo Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Astemo Ltd filed Critical Hitachi Astemo Ltd
Priority to CN202180084765.6A priority Critical patent/CN116635275A/zh
Priority to EP21930257.7A priority patent/EP4307145B1/en
Priority to US18/257,961 priority patent/US12306953B2/en
Publication of WO2022190408A1 publication Critical patent/WO2022190408A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection

Definitions

  • the present invention relates to analyzers. More specifically, the present invention relates to an analysis device that detects anomalies based on monitoring results of monitoring target devices mounted on a vehicle, and more particularly, an analysis device that determines whether or not to output an anomaly notification to the outside of the vehicle. Regarding.
  • a SOC Security Operation Center
  • SOC Security Operation Center
  • the SOC collects logs related to security events from vehicles, and SOC operators and analysts analyze the situation of the vehicle and the impact on other vehicles based on the logs, and formulate and implement countermeasures.
  • As security events collected from vehicles it is conceivable to use detection results of attack detection devices mounted on vehicles.
  • the number of connected cars is increasing more and more, and the number of vehicles monitored by the SOC is becoming larger.
  • the more erroneous detections made by the attack detection device the more unnecessary work load is placed on operators and analysts.
  • Patent Literature 1 discloses a technique for controlling a communication method to the outside of a vehicle according to the depth of intrusion of an unauthorized attack on an in-vehicle device.
  • the conventional technology has the problem of not being able to output anomaly notifications appropriately.
  • Patent Document 1 it is expected that the attack accuracy will be increased according to the penetration depth of the unauthorized attack on the in-vehicle device, that is, false detection will be reduced.
  • another attack event is detected after some time has passed since the first detected attack event, it becomes difficult to determine whether it is an erroneous detection or an attack. For example, in the period (trip time) from when the vehicle starts until it stops (trip time), an attack event detected at a certain trip time and an attack event detected at several trip times or dozens of trip times later may not be actual attacks. It does not disclose how to determine whether it is a false positive or a false positive.
  • the present invention has been made in view of the above problems, and aims to provide an analysis device that appropriately outputs anomaly notifications by reducing erroneous detection of attack events.
  • An example of the analyzer according to the present invention is In an analysis device configured to be able to communicate with a plurality of monitoring target devices, The analysis device is collecting monitoring results for each of the monitored devices; determining whether or not an abnormality has occurred in each of the monitored devices based on the monitoring results; Based on the determination result and the code verification result of each monitored device, it is determined whether or not to output an abnormality notification indicating an abnormality.
  • This specification includes the disclosure of Japanese Patent Application No. 2021-037773, which is the basis of priority of this application.
  • the analysis device can appropriately output anomaly notifications by reducing false detections of attack events.
  • FIG. 1 is a diagram showing the configuration of an analysis apparatus according to Example 1 of the present invention
  • Diagram showing an example of immediate notification rules based on log type
  • a diagram showing an example of situation information for the entire vehicle A diagram showing an example of the result of determination of the vehicle situation by the analysis device
  • the analysis device executes a method of determining the timing of notification to the outside of the vehicle based on the abnormal log information acquired from the in-vehicle device.
  • the technical idea of the present invention is not limited to this example. For example, it is possible to apply the function of detecting an abnormality and the function of determining the timing of notification to the outside of the vehicle to the same device.
  • FIG. 1 shows the configuration of the analysis device 1 in this embodiment.
  • the analysis device 1 is, for example, a device that is mounted on a vehicle 50 and that analyzes information related to the vehicle 50 .
  • the analysis device 1 may not be mounted on the vehicle 50 , and may be a device that analyzes information related to a target other than the vehicle 50 .
  • the analysis device 1 is connected to the in-vehicle device 3 via the communication bus 2 .
  • the in-vehicle device 3 is a device mounted on the vehicle 50, and is a monitoring target device monitored by the analysis device 1 in this embodiment.
  • the analysis device 1 is communicably connected to a plurality of in-vehicle devices 3 .
  • the communication bus 2 may physically include a plurality of communication buses, and the standards of each communication bus may be the same or different.
  • the standards of these communication buses include CAN (registered trademark), LIN (registered trademark), FlexRay (registered trademark), and Ethernet (registered trademark).
  • the analysis device 1 includes computing means (not shown) and storage means (not shown).
  • the computing means comprises, for example, a CPU.
  • the storage means comprise, for example, ROM and RAM.
  • the analysis device 1 implements the functions described in this specification by executing the program stored in the storage means by the calculation means.
  • the analysis device 1 includes, as its functional units, a log collection unit 12, a log analysis unit 13, an immediate notification pertinence determination unit 14, a predictive activity determination unit 15, a vehicle state update unit 16, an attack detection determination unit 17, a notification information generation unit 18 , a notification determination unit 19 , an instruction content analysis unit 20 , and a notification timing control unit 21 .
  • the processing executed by the CPU or these functional units can also be said to be executed by the analyzer 1 .
  • the storage means includes a storage unit 100.
  • the storage unit 100 may be wholly nonvolatile, or partly volatile.
  • the analysis device 1 also includes a communication unit 11 that is a communication interface and performs calculations necessary for communication.
  • the functional block diagram shown in FIG. 1 is an example, and the units and names of functions are not limited to this.
  • the functions realized by the log analysis unit 13 in this embodiment may be realized by other functional units shown in FIG. 1, or may be realized by functional units not shown in FIG.
  • the communication unit 11 receives messages from the in-vehicle device 3 via the communication bus 2 and transmits messages to the in-vehicle device 3 via the communication bus 2 .
  • the analysis device 1 uses the communication unit 11 to collect information (for example, information for determining an abnormal state) from each in-vehicle device 3 . Logs detected not only by the in-vehicle device 3 but also by the analysis device 1 itself may be collected and stored.
  • the log collection unit 12 stores the information collected from the in-vehicle device 3 in the vehicle log information 101.
  • the log analysis unit 13 analyzes information collected from the in-vehicle device 3 for the presence or absence of information indicating an abnormality.
  • the immediate notification applicability determination unit 14 determines whether or not information indicating an abnormality corresponds to the immediate notification rule 102 .
  • the predictive activity determination unit 15 determines whether information indicating an abnormality is registered in the vehicle situation information 104 for a predetermined period (for example, the latest completed trip time).
  • the vehicle state update unit 16 updates the vehicle condition information 104 based on the information indicating the abnormality.
  • the attack detection determination unit 17 determines confirmation of attack detection based on the vehicle situation information 104 and updates the situation judgment result 105 .
  • the notification information generator 18 generates information to be notified to the outside of the vehicle 50 .
  • the notification determination unit 19 determines whether or not to notify the outside of the vehicle 50 based on the situation determination result 105 .
  • the instruction content analysis unit 20 analyzes the instruction content regarding notification control received from the outside of the analysis device 1 .
  • the notification timing control unit 21 notifies information about the detected abnormality to the outside of the vehicle 50 at a predetermined timing.
  • the storage unit 100 has the following functional units. - vehicle log information 101 that holds information acquired from the in-vehicle device 3; - An immediate notification rule 102 for determining whether or not to immediately output the detected abnormality to the outside of the vehicle 50 . - Inter-apparatus influence information 103 indicating mutual influence relationships among the in-vehicle apparatuses 3 . For example, the relationship between the in-vehicle device 3 related to the abnormality and another in-vehicle device 3 that may be attacked is shown. -Vehicle situation information 104 that holds the presence or absence of infringement of each in-vehicle device 3 and the infringement status. - Situation judgment result 105 indicating the state of the vehicle 50 based on the vehicle situation information 104;
  • the functional block diagram shown in FIG. 1 is also an example, and the units and names of the functions are not limited to this.
  • the information held by the vehicle log information 101 in this embodiment may be held by other functional units shown in the storage unit 100 in FIG. good too.
  • FIG. 2 is a flowchart showing the processing when the analysis device 1 determines the timing for notifying the outside of the vehicle 50 of an abnormality.
  • An execution entity of each step described below is, for example, a CPU (not shown) of the analysis device 1 .
  • the log collection unit 12 uses the communication unit 11 to collect the monitoring results of each in-vehicle device 3 and stores them in the vehicle log information 101 of the analysis device 1 .
  • Monitoring results are collected as log information, for example.
  • the log information may be collected periodically after the analysis device 1 is activated, or the log information may be collected at an arbitrarily set timing in advance, or at a timing determined by each in-vehicle device 3. You may receive the log information transmitted from the vehicle-mounted apparatus 3 by .
  • the log collection unit 12 may collect logs for a predetermined period. This determined period of time may include multiple trip times (or portions thereof), and may span multiple trip times, for example.
  • the code verification result indicates that the program has not been tampered with.
  • the previously collected logs eg, anomaly logs
  • the previous log may be left as it is regardless of the code verification result, and may be deleted after notifying the outside of the vehicle 50 of the log.
  • FIG. 5 shows an example of vehicle log information 101 holding log information collected in step 201 above.
  • Each log included in the vehicle log information 101 is configured for each in-vehicle device.
  • the log includes an error log (a log indicating that an error has occurred), and the error log includes the following information.
  • - Error ID 1011 which is an identifier assigned to each error log type.
  • - Anomaly content 1012 which is text data indicating the content of the anomaly log.
  • - Abnormal location 1013 indicating a location where an abnormality has occurred in the in-vehicle device 3 .
  • - Time 1014 indicating the time when the abnormality was detected.
  • This time 1014 indicates whether the log is included in any of the operation periods of the analysis device 1 or in any of the operation periods of the vehicle 50 .
  • the operation period of the analysis apparatus 1 may be, for example, the period from when the analysis apparatus 1 is started until it is stopped, and the operation period of the vehicle 50 is, for example, from when the vehicle 50 is started to when it stops. may be a period of
  • each in-vehicle device 3 can generate a log based on known technology or the like. For example, when there is an access from a terminal that is not registered as an external device via the communication channel Ch1 monitored by the in-vehicle device A, the in-vehicle device A writes an error content 1012 "unregistered terminal access" in the log. ', the abnormality ID "0x001" of the abnormality, the abnormality location 1013 "Ch1", and the detected time "2020/02/01 11:10:20" are registered. This log is collected in step 201 .
  • the log analysis unit 13 extracts an anomaly log by determining whether an anomaly log is included in the vehicle log information 101 stored at step 201 above. That is, the log analysis unit 13 determines whether or not an abnormality has occurred in each in-vehicle device 3 based on the monitoring result of the in-vehicle device 3 . In this embodiment, only the error log is held, but other log information may be held, and in that case, an identifier that can identify the error log may be provided. This determination can be made based on the abnormality ID 1011, for example.
  • the log information may also include code verification results. For example, the code verification result may include information indicating that it was determined that there was tampering, that it was determined that there was no tampering, and the like.
  • step 203 if an error log is included in step 202 above, proceed to step 204. On the other hand, if no error log is included, this processing flow ends. After completion, the process may proceed to step 201 at a predetermined timing. In addition, as a modified example, the process may be configured to proceed to step 204 even when the log indicating the code verification result is included. In that case, the process may proceed to step 204 when it is determined that the code has not been tampered with as a result of code verification.
  • step 204 the immediate notification pertinence determination unit 14 determines whether or not there is an abnormality log that should be immediately notified to the outside of the vehicle 50 in the abnormality logs included in the vehicle log information 101 based on the immediate notification rule 102. do.
  • FIG. 6A shows an example of the immediate notification rule 102 referred to by the immediate notification appropriateness determination unit 14 in step 204 above. This example is based on the anomaly device 1021 . For example, if the in-vehicle device 3 related to the error log corresponds to the error device 1021 in the immediate notification rule 102, the immediate notification appropriateness determination unit 14 determines to output an immediate notification for that error log.
  • Immediate notification is a type of notification indicating an abnormality (abnormality notification). Determining to output an immediate notification for a certain error log corresponds to determining to output an error notification for that error log.
  • the immediate notification pertinence determining unit 14 determines whether to output an abnormality notification based on the content of an abnormality (for example, a single abnormality) that has occurred in any of the in-vehicle devices 3. (example of in-vehicle device I). By doing so, it is possible to reliably output an abnormality notification when a serious abnormality occurs.
  • an abnormality for example, a single abnormality
  • the immediate notification rule 102 may include as a condition that an error log corresponding to the error device 1021 occurs multiple times.
  • the immediate notification pertinence determining unit 14 may further determine to output an immediate notification based on the number of times an abnormality has occurred in any one of the in-vehicle devices 3 within a predetermined period. For example, if there are a plurality of error logs relating to the same vehicle-mounted device 3 within a predetermined period of time, those error logs may be determined to be subject to immediate notification. In this way, frequent anomalies are not overlooked.
  • FIG. 6B shows another example of the immediate notification rule 102 referred to by the immediate notification appropriateness determination unit 14 in step 204 above. This example is based on the type of error log.
  • the immediate notification pertinence determining unit 14 determines to output an immediate notification when the abnormality ID 1011 corresponds to the abnormality ID 1022 subject to immediate notification.
  • the immediate notification pertinence determination unit 14 can determine whether to output an abnormality notification based on the details of a single abnormality that has occurred in any of the in-vehicle devices 3 .
  • the immediate notification rule 102 may include as a condition that an abnormality log corresponding to the immediate notification target abnormality ID 1022 occurs multiple times.
  • the immediate notification pertinence determination unit 14 may further determine to output an immediate notification based on the number of times the same abnormality has occurred within a predetermined period. For example, if there are multiple error logs associated with the same error ID within a predetermined period of time, those error logs may be determined to be subject to immediate notification. In this way, frequent anomalies are not overlooked.
  • Either one of the rules shown in FIG. 6A and the rules shown in FIG. 6B may be used for determination, or both may be used for determination. When both are used, it may be determined to output an immediate notification for an error log that corresponds to either one, or it may be determined to output an immediate notification only for an error log that corresponds to both.
  • step 205 the immediate notification pertinence determining unit 14 proceeds to step 208 if it determines to output an immediate notification in step 204, and proceeds to step 206 if it determines not to output an immediate notification.
  • step 206 the attack detection determination unit 17 determines whether or not there is an attack in the abnormality log extracted in step 202 based on the vehicle situation information 104, which will be described later, and determines whether or not to notify the outside of the vehicle. do. Details of this determination will be described later with reference to FIG.
  • the attack detection determination unit 17 determines whether or not to output an anomaly notification based on the situation determination result 105 (described later with reference to FIG. 9, etc.).
  • the situation determination result 105 is generated based on whether or not an abnormality has occurred in each on-vehicle device 3 (step 203 described above) and the code verification result of each on-vehicle device 3 (step 302 described later). Therefore, the attack detection determination unit 17 determines whether or not to output an abnormality notification based on the determination result regarding whether or not an abnormality has occurred in each in-vehicle device 3 and the code verification result of each in-vehicle device 3. can decide.
  • determining that the attack detection determination unit 17 outputs an abnormality notification corresponds to determining that either the vehicle 50 or the in-vehicle device 3 is under attack.
  • the determination that the attack detection determination unit 17 does not output an abnormality notification corresponds to determination that neither the vehicle 50 nor the in-vehicle device 3 is attacked, or the determination that the vehicle 50 or the in-vehicle device 3 Although there is a possibility that is under attack, it corresponds to the determination that it should be monitored continuously as a wait-and-see.
  • the situation judgment ID 1051 (described later with reference to FIG. 9, etc.) of the situation judgment result 105 is "0x00" or "0x01"
  • it is determined not to output an abnormality notification and if it is "0x10" or "0x11” If there is, it decides to output an anomaly notification.
  • the content of the output abnormality notification can be, for example, the immediate notification described above or the accumulated notification described later.
  • step 208 If it is determined to output an abnormality notification, proceed to step 208, and if it is determined not to output an abnormality notification, end this processing flow.
  • the notification information generation unit 18 generates an abnormality notification as information to be notified to the outside of the vehicle.
  • the anomaly notification may include information based on vehicle log information 101, vehicle situation information 104, and situation determination result 105.
  • the anomaly notification may include information indicating that an attack has been detected.
  • the notification determination unit 19 outputs the abnormality notification generated at step 208 to the outside of the vehicle 50 .
  • the output destination may be a device outside the vehicle 50 , in which case communication may be performed via any one of the in-vehicle devices 3 . Further, the output destination may be a device mounted on the vehicle 50. For example, by turning on a lamp mounted on the vehicle 50, detection of an attack may be recognized from the outside of the vehicle 50. .
  • the analysis device 1 shifts to a countermeasure mode for security countermeasures for the vehicle 50 based on the situation determination result 105 .
  • the specific contents of the operation in the coping mode can be appropriately designed by those skilled in the art based on known techniques and the like. Note that step 210 may be omitted.
  • the analysis device 1 can notify the outside of the vehicle of an abnormality at an appropriate timing when an attack is detected.
  • FIG. 3 is a detailed flowchart of the processing in step 206 above.
  • An execution entity of each step described below is, for example, a CPU (not shown) of the analysis device 1 .
  • the processing of FIG. 3 is executed for each error log, for example, except step 307, and step 307 is executed in response to the execution of the processing of FIG.
  • step 301 the predictive activity determination unit 15 refers to the vehicle situation information 104 and determines whether or not an attack predictive activity is recorded.
  • a specific processing example of step 301 will be described below with reference to FIGS. 7, 8A, and 8B.
  • FIG. 7 shows an example of the inter-device influence information 103 that associates the in-vehicle device 3 (victim device 1031) related to the anomaly log with the in-vehicle device 3 (affected device 1032) affected by the anomaly.
  • the affected device 1032 is related to the victim device 1031 in which an abnormality has occurred, and may be affected by the attack. Also, the monitoring target group ID 1033 is identification information for specifying a group consisting of the victim device 1031 and the affected device 1032 .
  • the affected device 1032 “vehicle device D” corresponding to the vehicle device A in the victim device 1031 of 103 is specified.
  • FIG. 8A shows an example of vehicle situation information 104 in which predictive activity is recorded.
  • the vehicle situation information 104 includes an in-vehicle device ID 1041 that identifies the in-vehicle device 3 mounted in the vehicle 50, and an infringement presence/absence 1042 that indicates whether or not the in-vehicle device has been infringed.
  • the vehicle situation information 104 in FIG. 8A can be generated prior to execution of step 301. For example, "1" can be recorded for the vehicle-mounted device 3 in which an abnormality occurred within a predetermined period (situation information recording period), and "0" can be recorded for the other vehicle-mounted device 3.
  • the start point and end point of the situation information recording period can be arbitrarily designed, but may be, for example, the operation period of vehicle 50 (for example, the period from start to stop of vehicle 50), or the operation period of analysis device 1. (for example, a period from when the analyzer 1 is started until it is stopped). By doing so, it is possible to match the recording of the abnormality log with the operation period of the analysis device 1 or the vehicle 50, and to make a more appropriate determination.
  • this situation information recording period may be a period determined based on a specific event signal, or may be a period based on a predetermined time.
  • the vehicle situation information 104 can be designed to be updated at any timing. For example, it may be updated according to the end of the situation information recording period. For example, if the vehicle situation information 104 holds information relating to the first situation information recording period, when the second situation information recording period ends, the vehicle situation information 104 corresponds to the second situation information recording period. Content may be updated.
  • the situation determination result 105 can be initialized at any timing. For example, when the trip time changes (that is, when the previous trip time ends and a new trip time starts), the situation judgment result 105 may be maintained, or the situation judgment result 105 may be initialized. may be set to "0x00".
  • the situation determination result 105 may be initialized when a predetermined procedure from outside the vehicle 50 (for example, the SOC confirms that there is no problem, the problematic program is corrected, etc.) is performed. Alternatively, the situation judgment result 105 may be initialized when a log indicating that there was no tampering as a code verification result is collected from all the vehicle-mounted devices 3 or the corresponding vehicle-mounted device 3 .
  • step 301 for example, for an anomaly log having an anomaly ID 1011 of "0x002" shown in FIG. determine whether For example, if the value of the presence/absence of infringement 1042 corresponding to the in-vehicle device A is "1", it is determined that there was predictive activity, and if it is "0", it is determined that there was no predictive activity. In this example, since the value of the infringement existence 1042 corresponding to the in-vehicle device ID 1041 which is "in-vehicle device A" is "0", it is determined that there was no predictive activity for the in-vehicle device A.
  • the predictive activity determination unit 15 identifies the in-vehicle device D as the influence destination based on the inter-device influence information 103 as described above, and determines whether or not there is predictive activity in the in-vehicle device D. For example, if the value of the presence/absence of infringement 1042 corresponding to the in-vehicle device D is "1", it is determined that there was predictive activity, and if it is "0", it is determined that there was no predictive activity. In this example, since the value of infringement presence/absence 1042 corresponding to the in-vehicle device ID 1041, which is “in-vehicle device D”, is “1”, it is determined that the in-vehicle device D has a predictive activity.
  • the error log related to the in-vehicle device C if the victim device 1031 is the in-vehicle device C in FIG. associated with the containing group. Therefore, as for the error log related to the in-vehicle device C, if either or both of the infringement presence 1042 corresponding to the in-vehicle device D and the infringement presence 1042 corresponding to the in-vehicle device E are “1”, the in-vehicle It is determined that there was predictive activity for device D or onboard device E, or both, and if both are "0", it is determined that there was no predictive activity for onboard device D and onboard device E.
  • the predictive activity determination unit 15 may determine the presence or absence of predictive activity for all anomaly logs as described above. Further, in step 202, the predictive activity determination unit 15 identifies the damaged device in which the abnormality is occurring based on the abnormality log extracted from the vehicle log information 101, and uses the inter-device influence information 103 to identify the damaged device. It is also possible to specify the range of influence, refer to the infringement presence/absence 1042 for the vehicle-mounted apparatus ID 1041 corresponding to the affected vehicle-mounted apparatus and the vehicle-mounted apparatus included in the area of influence, and determine whether or not there is a sign of attack.
  • step 301 if it is determined that there was predictive activity in any of the in-vehicle devices, the process proceeds to step 302, and if it is determined that there was no predictive activity, the process proceeds to step 303.
  • the attack detection determination unit 17 refers to the code verification result.
  • the code verification result of the in-vehicle device 3 determined to have the predictive activity in step 301 is referred to.
  • a specific example of the code verification result is not shown, it indicates, for example, whether or not the program executed by the in-vehicle device 3 has been tampered with, and can be generated based on a known technique or the like. Note that if the log acquired in step 201 is a log representing the code verification result of the in-vehicle device 3 (for example, the presence or absence of tampering), in step 302, the content of the log indicates that tampering has occurred.
  • the analysis device 1 collects the code verification results (whether or not there is falsification) of each on-vehicle device 3 from each on-board device 3 in step 201, In this step 302, the code verification result may be determined.
  • Code verification results are generated by secure boot processing, for example.
  • the secure boot process is a process for determining whether or not a program executed by the in-vehicle device 3 has been tampered with when starting execution of the program.
  • the code verification result is not limited to the result of the secure boot process, and may be the result of verification executed at any timing after the start of execution of the program.
  • step 304 If it is determined that the program executed by the in-vehicle device 3 with predictive activity has been tampered with, the process proceeds to step 304 . Otherwise, processing proceeds to step 305 .
  • the vehicle state update unit 16 updates the vehicle situation information 104 based on the new abnormality log extracted from the vehicle log information 101 .
  • FIG. 8B shows an example of the vehicle situation information 104 updated in step 303 above.
  • the vehicle situation information 104 includes both the information shown in FIG. 8A and the information shown in FIG. 8B, but these pieces of information are contained in different areas (for example, different databases, RAMs, and data flashes). good too.
  • the vehicle situation information 104 shown in FIG. 8B includes the following information. - Monitored Group ID 1043, which identifies a group of related devices. - Associated Devices 1044 indicating the on-vehicle devices included in each group. The relationship between devices included in each group may correspond to the inter-device influence information 103 in FIG. In this embodiment, the relationships shown in FIG. 8B correspond to the relationships shown in FIG. 7, but they need not correspond in the modified example. - Infringement Status 1045 showing the infringement status in each onboard device. - A threshold value 1046 indicating a threshold value used when determining whether or not to output an anomaly notification based on the infringement situation 1045 .
  • the vehicle status update unit 16 updates the presence or absence of infringement 1042 corresponding to the in-vehicle device (for example, in-vehicle device A) related to the abnormality log from "0" to "1". For example, for the anomaly log related to in-vehicle device A, the ID ⁇ 0x01 ⁇ of the group whose victim device 1031 is in-vehicle device A is obtained from the monitoring target group ID 1033 in FIG. If state 1045 (which is ⁇ 1,1 ⁇ in the example of FIG. 8B) is ⁇ 0,0 ⁇ , update it to ⁇ 1,0 ⁇ .
  • state 1045 which is ⁇ 1,1 ⁇ in the example of FIG. 8B
  • the attack detection determination unit 17 compares the infringement situation 1045 in the vehicle situation information 104 with the threshold 1046 . For example, for each group, compare the sum of the numbers contained in the infringement landscape 1045 to a threshold. If the sum exceeds the threshold, it is determined to output the cumulative notification. A cumulative notification is a kind of anomaly notification. If the sum does not exceed the threshold, it is determined not to output an abnormality notification.
  • the determination in step 306 may be omitted, in which case it may be determined not to output an abnormality notification (similar to the case where the sum does not exceed the threshold).
  • the vehicle state update unit 16 updates the situation determination result 105 according to the results of steps 303, 304, or 306.
  • the situation judgment result 105 includes a situation judgment ID 1051 that identifies the situation of the vehicle and a status 1052 that indicates the content of the situation of the vehicle.
  • the situation determination ID 1051 is "0x00" and the status 1052 is "normal".
  • step 303 If step 303 has been executed before step 307, the situation judgment ID 1051 will be "0x01" and the status 1052 will be "continuous monitoring".
  • step 304 If step 304 has been executed before step 307, the situation judgment ID 1051 will be "0x11" and the status 1052 will be "immediate notification".
  • step 306 has been executed before step 307 and the threshold has been exceeded, the situation determination ID 1051 will be "0x10” and the status 1052 will be “cumulative notification”. Also, if step 306 has been executed before step 307 and the threshold has not been exceeded, the situation determination ID 1051 will be "0x01” and the status 1052 will be "continuous monitoring”.
  • the situation judgment ID 1051 with the largest value among the results is prioritized. For example, if a certain error log is determined to be “continuous monitoring” (situation judgment ID 1051 is "0x01”) and another error log is judged to be “immediate notification” (situation judgment ID 1051 is "0x11”), the result As a result, the situation judgment ID 1051 becomes "0x11".
  • the anomaly notification includes a cumulative notification of the number of times an anomaly has occurred and an immediate notification of the content of the anomaly that has occurred.
  • the anomaly notification may include information indicating whether the anomaly notification is a cumulative notification or an immediate notification. By doing so, it is possible to output the content of the abnormality in more detail.
  • the analysis device 1 can determine whether to output an abnormality notification to the outside of the vehicle. When it is decided to output an abnormality notification, it is possible to notify the outside of the vehicle at an appropriate timing for early countermeasures.
  • the analysis device 1 determines that there is an indication activity (that is, an abnormality has occurred within a predetermined period) and that there has been tampering with any of the in-vehicle devices 3. is determined to output an anomaly notification. Therefore, more appropriate determination can be made based on the past predictive activity and the latest code verification result.
  • FIG. 4 is a flow chart showing an example of processing in which the analysis device 1 outputs the information of the in-vehicle device to the outside of the vehicle.
  • the analyzer 1 may output an abnormality notification by the process shown in FIG. 4 in addition to or instead of step 209 shown in FIG.
  • FIG. 4 a case of outputting as a regular report and a case of outputting according to an instruction from the outside of the vehicle will be described.
  • An execution entity of each step described below is, for example, a CPU (not shown) of the analysis device 1 . Further, this processing flow is executed, for example, when the vehicle 50 is started. Furthermore, this processing flow may be executed at a predetermined timing, may be repeatedly executed periodically, or may be executed after an abnormality is notified.
  • the instruction content analysis unit 20 confirms whether or not a notification instruction has been received from outside the vehicle. move on.
  • the instruction content analysis unit 20 analyzes the instruction content received from the outside of the vehicle.
  • the instruction content includes information designating information to be output to the outside of the vehicle.
  • the instruction content includes designation for a specific on-vehicle device, designation for specific log information, designation for log information to be additionally collected from other on-board devices, designation for other information held in the vehicle, and the like. It's okay.
  • the instruction content may also include information for changing the function or configuration of the analyzer 1 .
  • step 403 the notification information generation unit 18 collects necessary information from the analysis device 1 or the in-vehicle device 3 based on the contents analyzed in step 402 above.
  • the notification information generation unit 18 generates information to be output to the outside of the vehicle from the information collected at step 403 above.
  • the notification timing control unit 21 confirms whether the current time has reached the predetermined notification timing.
  • the predetermined timing may be the timing at which a predetermined event or process occurs (for example, at startup), or a predetermined date and time.
  • step 406 the notification timing control unit 21 proceeds to step 407 if it determines that the current time is the predetermined timing based on the confirmation result in step 405, otherwise the processing flow ends. do.
  • the notification information generation unit 18 generates fixed form data to be output to the outside of the vehicle. For example, information consisting of part or all of the information held in the storage unit of the analysis device 1 is generated.
  • the notification determination unit 19 outputs the information generated at step 404 or step 407 to the outside of the vehicle.
  • the output destination can be designed in the same way as in step 209 of FIG.
  • the analysis device 1 determines whether or not to output an abnormality notification based on the result of determination regarding whether or not an abnormality has occurred in each in-vehicle device 3 and the code verification result of each in-vehicle device 3. to decide.
  • predetermined information can be notified periodically at a timing that considers the operation load and data communication cost on the center side, and in a situation such as when it is determined that an attack has occurred, it can flexibly follow request instructions from outside the vehicle. to provide additional information.
  • the analysis device 1 can output an anomaly notification to the outside of the vehicle at an appropriate timing based on the anomaly log acquired from the in-vehicle device and the immediate notification rule.
  • the analysis device 1 can determine that the vehicle is under attack based on the anomaly log and predictive activity, and output an anomaly notification to the outside of the vehicle.
  • an anomaly notification can be output to the outside of the vehicle based on the degree of vehicle intrusion.
  • an error notification can be output immediately.
  • the first embodiment it is possible to reduce the number of cases in which notification is made when no attack is underway, and on the other hand, it is difficult to overlook cases in which there is a high possibility of an attack. Therefore, it is possible to optimize the load when cooperating with a center service such as SOC.
  • the code verification result can be generated by the secure boot process, so the result of the secure boot process can be effectively used.
  • the analysis device 1 determines not to output an abnormality notification when it is determined that none of the in-vehicle devices 3 have been tampered with. In this case, erroneous detection of attacks based on the error log can be suppressed.
  • the processes in FIGS. 2 and 3 are examples, and can be changed as appropriate.
  • the criteria for determination in step 204, the criteria for determination in step 302, etc. can be arbitrarily changed.
  • step 301 may be omitted, and step 302 may always be executed in step 206 .
  • the format of the information used for judgment can be added, omitted, or changed as appropriate.
  • the information in FIGS. 6A, 7, and 8B may be omitted, in which case the victim device and the affected device may be the same device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Alarm Systems (AREA)
  • Traffic Control Systems (AREA)

Abstract

攻撃事象の誤検知を低減することにより、異常通知を適切に出力する分析装置を提供する。　複数の監視対象装置に対して通信可能に構成される分析装置において、前記分析装置は、各前記監視対象装置の監視結果を収集し、前記監視結果に基づき、各前記監視対象装置の異常が発生したか否かを判定し、前記判定の結果と、各前記監視対象装置のコード検証結果とに基づき、異常を示す異常通知を出力するか否かを決定する。

Description

分析装置
　本発明は分析装置に係る。より具体的には、本発明は車両に搭載された監視対象装置の監視結果に基づく異常検知を行う分析装置に係り、特に、車外に対して異常通知を出力するか否かを決定する分析装置に関する。
　車両の出荷後における運用中のセキュリティを管理するために、自動車向けＳＯＣ（Security Operation Center）が検討されている。ＳＯＣでは、車両からセキュリティイベントに関するログを収集し、ＳＯＣのオペレータや分析官が当該ログに基づいて、当該車両の状況や他車両への影響を分析し、対策方針の策定および実行を行う。車両から収集するセキュリティイベントとして、車両に搭載された攻撃検知装置の検知結果を利用することが考えられる。
　コネクテッドカーは益々増加しており、ＳＯＣが監視する車両の台数は大規模になってくる。このような環境では、攻撃検知装置の誤検知が多ければ多いほど、オペレータや分析官に対する不要な作業負荷が増大してしまう。
　このため、攻撃検知技術として、誤検知の低減が求められる。攻撃検知の精度を高める技術として、特許文献１では、車載装置に対する不正な攻撃の侵入の深度に従って、車両の外部への通信方法を制御する技術が開示されている。
特開２０１９－１２５３４４号公報
　しかしながら、従来の技術では、異常通知を適切に出力することができない課題があった。
　特許文献１の技術によれば、車載装置に対する不正な攻撃の侵入の深度に従って攻撃の確度を高める、すなわち誤検知を低減することが期待される。しかしながら、最初に検知した攻撃事象からいくらかの時間が経過した後に別の攻撃事象が検知された場合には、誤検知なのか攻撃なのかの判定は困難となる。例えば、車両が起動してから停止するまでの期間（トリップタイム）において、あるトリップタイムで検知した攻撃事象と、数回あるいは数十回後のトリップタイムで検知した攻撃事象が、実際の攻撃なのか誤検知なのかを判断する方法については開示されていない。
　本発明は、以上の問題に鑑みなされたものであり、攻撃事象の誤検知を低減することにより、異常通知を適切に出力する分析装置を提供することを目的とする。
　本発明に係る分析装置の一例は、
　複数の監視対象装置に対して通信可能に構成される分析装置において、
　前記分析装置は、
　各前記監視対象装置の監視結果を収集し、
　前記監視結果に基づき、各前記監視対象装置の異常が発生したか否かを判定し、
　前記判定の結果と、各前記監視対象装置のコード検証結果とに基づき、異常を示す異常通知を出力するか否かを決定する。
　本明細書は本願の優先権の基礎となる日本国特許出願番号2021-037773号の開示内容を包含する。
　本発明に係る分析装置は、攻撃事象の誤検知を低減することにより、異常通知を適切に出力することができる。
本発明の実施例１に係る分析装置の構成を示す図 車両外部への通知タイミングを判定する処理の概要処理フローを示す図 図２のステップ２０６の詳細フローを示す図 車両外部への通知処理の概要処理フローを示す図 車載装置から収集するログ情報の例を示す図 異常装置に基づく即時通知ルールの例を示す図 ログの種類に基づく即時通知ルールの例を示す図 車載装置の影響範囲の例を示す図 各車載装置の侵害有無の例を示す図 車両全体の情勢情報の例を示す図 分析装置による車両情勢の判断結果の例を示す図
　以下、本発明の実施形態について、実施例を用い、図面を参照しながら詳細に説明する。
　本実施例に係る分析装置は、車載装置から取得した異常なログ情報に基づいて、車両の外部に通知するタイミングを判定する方法を実行する。ただし、本発明の技術的思想は、この実施例に限定されるものではない。例えば、異常を検知する機能と、車両の外部に通知するタイミングを判定する機能とを、同一の装置に適用することも可能である。
　図１は、本実施例における分析装置１の構成を示す。分析装置１は、たとえば車両５０に搭載され、車両５０に関連する情報を分析する装置である。ただし、分析装置１は車両５０に搭載されないものであってもよく、車両５０以外の対象に関連する情報を分析する装置であってもよい。
　分析装置１は、通信バス２を介して車載装置３に接続されている。車載装置３は、車両５０に搭載される装置であり、本実施例において分析装置１によって監視される監視対象装置である。分析装置１は、複数の車載装置３に対して通信可能に接続される。
　通信バス２は物理的には複数の通信バスを含んでもよく、各通信バスの規格はすべて同一でもよいし異なっていてもよい。これら通信バスの規格はＣＡＮ（登録商標）、ＬＩＮ（登録商標）、ＦｌｅｘＲａｙ（登録商標）、イーサネット（登録商標）などである。
　分析装置１は、不図示の演算手段および不図示の記憶手段を備える。演算手段はたとえばＣＰＵを備える。記憶手段はたとえばＲＯＭおよびＲＡＭを備える。記憶手段に格納されたプログラムを演算手段が実行することにより、分析装置１は本明細書に記載される機能を実現する。
　たとえば分析装置１はその機能部として、ログ収集部１２、ログ解析部１３、即時通知該否判定部１４、予兆活動判定部１５、車両状態更新部１６、攻撃検知判定部１７、通知情報生成部１８、通知判断部１９、指示内容解析部２０、通知タイミング制御部２１を備える。本明細書において、ＣＰＵまたはこれらの機能部が実行する処理は、分析装置１が実行するということもできる。
　また、記憶手段は、記憶部１００を備える。記憶部１００は、全体が不揮発性であってもよいし、一部が揮発性であってもよい。また、分析装置１は、通信インタフェースであり通信に必要な演算を行う通信部１１を備える。
　図１に示す機能ブロック図は例示であり、機能の単位および名称はこれに限らない。たとえば、本実施例においてログ解析部１３が実現する機能は、図１に示す他の機能部によって実現されてもよく、図１に示さない機能部によって実現されてもよい。
　通信部１１は、通信バス２を介して車載装置３からのメッセージを受信するとともに、通信バス２を介して車載装置３に対してメッセージを送信する。分析装置１は、通信部１１を用いて各車載装置３からの情報（たとえば異常状態を判断できる情報）を収集する。なお、車載装置３だけでなく、分析装置１自身が検知したログを収集および格納してもよい。
　ログ収集部１２は、車載装置３から収集された情報を車両ログ情報１０１に格納する。ログ解析部１３は、車載装置３から収集した情報において、異常を示す情報の有無を解析する。即時通知該否判定部１４は、異常を示す情報が即時通知ルール１０２に該当するかどうかを判定する。予兆活動判定部１５は、所定期間（たとえば完了している最新のトリップタイム）において車両情勢情報１０４に異常を示す情報が登録されているかどうかを判定する。車両状態更新部１６は、異常を示す情報に基づいて車両情勢情報１０４を更新する。攻撃検知判定部１７は、車両情勢情報１０４に基づいて攻撃検知の確定を判定し、情勢判断結果１０５を更新する。通知情報生成部１８は、車両５０の外部に対して通知する情報を生成する。通知判断部１９は、情勢判断結果１０５に基づいて車両５０の外部に対して通知するかどうかを決定する。指示内容解析部２０は、分析装置１の外部から受信した通知制御に関する指示内容を解析する。通知タイミング制御部２１は、所定のタイミングに基づいて車両５０の外部に検知した異常に関する情報を通知する。
　記憶部１００は、以下の機能部を備える。
　‐車載装置３から取得した情報を保持する車両ログ情報１０１。
　‐検知した異常について即時に車両５０の外部に出力するか否かを判定するための即時通知ルール１０２。
　‐車載装置３相互の影響関係を示す装置間影響情報１０３。たとえば、異常に係る車載装置３と、攻撃対象となる可能性のある他の車載装置３との関係を示す。
　‐各車載装置３の侵害有無および侵害状況を保持する車両情勢情報１０４。
　‐車両情勢情報１０４に基づいた車両５０の状態を示す情勢判断結果１０５。
　記憶部１００についても同様に、図１に示す機能ブロック図は例示であり、機能の単位および名称はこれに限らない。たとえば、本実施例において車両ログ情報１０１が保持する情報は、図１の記憶部１００に示す他の機能部によって保持されてもよく、図１の記憶部１００に示さない機能部によって保持されてもよい。
　図２は、分析装置１が車両５０の外部に異常を通知するタイミングを判定する際の処理を示すフローチャートである。以下に説明する各ステップの実行主体は、たとえば分析装置１の不図示のＣＰＵである。
　ステップ２０１では、ログ収集部１２は通信部１１を用いて各車載装置３の監視結果を収集し、分析装置１の車両ログ情報１０１に格納する。監視結果はたとえばログ情報として収集される。例えば、分析装置１が起動してから周期的にログ情報を収集してもよく、或いは事前に任意に設定されたタイミングでログ情報を収集してもよく、或いは各車載装置３が決定するタイミングで車載装置３から送信されるログ情報を受け取ってもよい。また、ログ収集部１２は、決められた期間の間、ログを収集してもよい。この決められた期間は、複数のトリップタイム（またはそれらの一部）を含んでもよく、たとえば複数のトリップタイムを跨いでもよい。複数のトリップタイムを跨いだ場合、車両５０、或いは分析装置１が起動した後、各車載装置３から最初にログを取得する際に、コード検証結果としてプログラムの改ざんがなかったことが示された場合には（または、改ざんがあったことが示されなかった場合には）、前回に収集されたログ（たとえば異常ログ）を消去してもよい。或いは、トリップタイムを跨いだ場合でも、コード検証結果に関わらず前回のログはそのまま残しておき、当該ログを車両５０の外部に通知した後に消去してもよい。
　図５に、上記ステップ２０１において収集されるログ情報を保持する車両ログ情報１０１の例を示す。車両ログ情報１０１に含まれる各ログは車載装置ごとに構成される。ログは異常ログ（異常が発生したことを示すログ）を含み、異常ログは以下の情報を含む。
　‐異常ログの種類ごとに割り振られる識別子の異常ＩＤ１０１１。
　‐異常ログの内容を示すテキストデータである異常内容１０１２。
　‐当該車載装置３において異常が発生した箇所を示す異常箇所１０１３。
　‐異常を検知した時刻を示す時刻１０１４。この時刻１０１４は、そのログが分析装置１の動作期間のいずれかに含まれるか否か、または、車両５０の動作期間のいずれかに含まれるか否かを示す。なお、分析装置１の動作期間とは、たとえば分析装置１が起動してから停止するまでの期間であってもよく、車両５０の動作期間とは、たとえば車両５０が起動してから停止するまでの期間であってもよい。
　ステップ２０１に先立ち、各車載装置３は、公知技術等に基づいてログを生成することができる。例えば、車載装置Ａが監視する通信チャンネルＣｈ１を経由して、車外装置として登録されていない端末からのアクセスがあった場合には、車載装置Ａは、ログにおいて、異常内容１０１２「未登録端末アクセス」、当該異常の異常ＩＤ「０ｘ００１」、異常箇所１０１３「Ｃｈ１」、検知した時刻「２０２０／０２／０１　１１：１０：２０」を登録する。このログがステップ２０１において収集される。
　ステップ２０２では、ログ解析部１３は上記ステップ２０１で格納した車両ログ情報１０１に、異常ログが含まれているかどうかを判定することにより、異常ログを抽出する。すなわち、ログ解析部１３は、車載装置３の監視結果に基づき、各車載装置３の異常が発生したか否かを判定する。本実施例では、異常ログのみが保持されているが、他のログ情報を保持してもよく、その場合は、異常ログを特定できる識別子を備えてもよい。この判定は、たとえば異常ＩＤ１０１１に基づいて行うことができる。また、ログ情報は、コード検証結果を含んでもよい。たとえば、コード検証結果として、改ざんがあったと判定された、改ざんがなかったと判定された、等を示す情報を含んでもよい。
　ステップ２０３では、上記ステップ２０２で異常ログが含まれていた場合、ステップ２０４に進む。一方、異常ログが含まれていなかった場合には、本処理フローを終了する。終了後、所定のタイミングでステップ２０１に進んでもよい。なお、変形例として、コード検証結果を示すログが含まれていた場合にも、ステップ２０４に進むように構成してもよい。その場合には、コード検証結果として改ざんがなかったと判定された場合に、ステップ２０４に進むように構成してもよい。
　ステップ２０４では、即時通知該否判定部１４は即時通知ルール１０２に基づいて、車両ログ情報１０１に含まれる異常ログに、車両５０の外部に即時に通知すべき異常ログが存在するかどうかを判定する。
　図６Ａに、上記ステップ２０４において即時通知該否判定部１４が参照する即時通知ルール１０２の例を示す。この例は、異常装置１０２１に基づくものである。例えば、即時通知該否判定部１４は、異常ログに係る車載装置３が、即時通知ルール１０２における異常装置１０２１に該当する場合、その異常ログについて即時通知を出力すると判定する。即時通知とは、異常を示す通知（異常通知）の一種である。ある異常ログについて即時通知を出力すると判定することは、その異常ログについて異常通知を出力すると決定することに対応する。
　図６Ａの例では、車載装置Ｉに係る異常ログについては、即時通知を出力すると判定される。また、車載装置Ｇに係る異常ログと、車載装置Ｈに係る異常ログとが、同時刻または所定時間内に存在する場合には、それらの異常ログについて即時通知を出力すると判定される。
　なお、図６Ａの例では、即時通知該否判定部１４は、車載装置３のいずれかについて発生した異常（たとえば単一回の異常）の内容に基づき、異常通知を出力するか否かを決定することができる（車載装置Ｉの例）。このようにすると、重大な異常が発生した場合に確実に異常通知を出力することができる。
　また、即時通知ルール１０２は、異常装置１０２１に該当する異常ログが複数回発生することを条件として含んでもよい。たとえば、即時通知該否判定部１４は、さらに、所定期間内に車載装置３のいずれかについて異常が発生した回数に基づき、即時通知を出力すると判定してもよい。たとえば、所定期間内に、ある同一の車載装置３に係る異常ログが複数存在する場合に、それらの異常ログを即時通知対象と判定してもよい。このようにすると、頻発する異常を見逃すことがなくなる。
　図６Ｂに、上記ステップ２０４において即時通知該否判定部１４が参照する即時通知ルール１０２の別の例を示す。この例は、異常ログの種類に基づくものである。例えば、上記ステップ２０４において即時通知該否判定部１４は、異常ＩＤ１０１１が、即時通知対象異常ＩＤ１０２２に該当する場合、即時通知を出力すると判定する。
　なお、図６Ｂの例では、即時通知該否判定部１４は、車載装置３のいずれかについて発生した単一の異常の内容に基づき、異常通知を出力するか否かを決定することができる。ただし、変形例として、即時通知ルール１０２は、即時通知対象異常ＩＤ１０２２に該当する異常ログが複数回発生することを条件として含んでもよい。たとえば、即時通知該否判定部１４は、さらに、所定期間内に同一の異常が発生した回数に基づき、即時通知を出力すると判定してもよい。たとえば、所定期間内に、ある同一の異常ＩＤに係る異常ログが複数存在する場合に、それらの異常ログを即時通知対象と判定してもよい。このようにすると、頻発する異常を見逃すことがなくなる。
　図６Ａに示すルールと、図６Ｂに示すルールとは、いずれか一方のみを判定に使用してもよいし、双方を判定に使用してもよい。双方を使用する場合には、いずれか一方に該当する異常ログについて即時通知を出力すると判定してもよいし、双方に該当する異常ログのみ即時通知を出力すると判定してもよい。
　ステップ２０５では、即時通知該否判定部１４は上記ステップ２０４で即時通知を出力すると判定した場合、ステップ２０８に進み、即時通知を出力しないと判定した場合、ステップ２０６に進む。
　ステップ２０６では、攻撃検知判定部１７は上記ステップ２０２で抽出した異常ログに対して、後述する車両情勢情報１０４に基づいて攻撃の有無を判定し、車両の外部に対して通知するかどうかを判定する。この判定の詳細は図３等に関連して後述する。
　ステップ２０７では、攻撃検知判定部１７は、情勢判断結果１０５（図９等に関連して後述）に基づいて、異常通知を出力するか否かを決定する。なお、情勢判断結果１０５は、各車載装置３の異常が発生したか否か（上述のステップ２０３）と、各車載装置３のコード検証結果（後述するステップ３０２）とに基づいて生成されるものであるため、攻撃検知判定部１７は、各車載装置３の異常が発生したか否かに関する判定の結果と、各車載装置３のコード検証結果とに基づき、異常通知を出力するか否かを決定するということができる。
　ここで、攻撃検知判定部１７が異常通知を出力すると決定することは、車両５０または車載装置３のいずれかが攻撃を受けていると判定することに対応する。また、攻撃検知判定部１７が異常通知を出力しないと決定することは、車両５０または車載装置３のいずれも攻撃を受けていないと判定することに対応するか、または、車両５０または車載装置３が攻撃を受けている可能性はあるが、様子見として継続監視すべきと判定することに対応する。
　たとえば、情勢判断結果１０５の情勢判断ＩＤ１０５１（図９等に関連して後述）が「０ｘ００」または「０ｘ０１」である場合には異常通知を出力しないと決定し、「０ｘ１０」または「０ｘ１１」である場合には異常通知を出力すると決定する。出力される異常通知の内容は、たとえば上述の即時通知または後述の累積通知とすることができる。
　異常通知を出力すると決定した場合にはステップ２０８に進み、異常通知を出力しないと決定した場合には本処理フローを終了する。
　ステップ２０８では、通知情報生成部１８は車両の外部に通知する情報として異常通知を生成する。例えば、異常通知は車両ログ情報１０１、車両情勢情報１０４、情勢判断結果１０５に基づく情報を含んでもよい。また、異常通知は、攻撃を検知したことを表す情報を含んでもよい。
　ステップ２０９では、通知判断部１９は上記ステップ２０８で生成した異常通知を車両５０の外部に対して出力する。出力先は車両５０の外部にある装置であってもよく、その場合には車載装置３の何れかを経由して通信してもよい。また、出力先は車両５０に搭載された装置であってもよく、たとえば車両５０に搭載されたランプを点灯させることにより、攻撃を検知したことを車両５０の外部から認識できるようにしてもよい。
　ステップ２１０では、分析装置１は情勢判断結果１０５に基づいて、車両５０のセキュリティ対応を行うための対処モードに移行する。対処モードにおける動作の具体的な内容は、公知技術等に基づいて当業者が適宜設計することができる。なおステップ２１０は省略してもよい。
　以上のステップによって、分析装置１は攻撃を検知した適切なタイミングで車両の外部に異常を通知できる。
　図３は、上記ステップ２０６における処理の詳細なフローチャートである。以下に説明する各ステップの実行主体は、たとえば分析装置１の不図示のＣＰＵである。図３の処理は、たとえばステップ３０７を除いて異常ログごとに実行され、ステップ３０７は図２の処理が実行されることに応じて実行される。
　ステップ３０１では、予兆活動判定部１５は車両情勢情報１０４を参照し、攻撃の予兆活動が記録されているかどうかを判定する。以下、図７、図８Ａおよび図８Ｂを用いて、ステップ３０１の具体的な処理例について説明する。
　図７に、異常ログに係る車載装置３（被害装置１０３１）と、その異常によって影響を受ける影響先となる車載装置３（影響先１０３２）とを関係付ける装置間影響情報１０３の例を示す。
　影響先１０３２は、異常が発生している被害装置１０３１と関連性があり、攻撃の影響を受ける可能性がある。また、監視対象グループＩＤ１０３３は、被害装置１０３１と影響先１０３２とからなるグループを特定する識別情報である。
　例えば、図５に示す異常ＩＤ１０１１が「０ｘ００２」の異常ログについて、予兆活動判定部１５は、当該異常ＩＤが登録されている車載装置「車載装置Ａ」を被害装置として特定し、装置間影響情報１０３の被害装置１０３１における車載装置Ａに該当する影響先１０３２「車載装置Ｄ」を特定する。
　図８Ａに、予兆活動が記録される車両情勢情報１０４の例を示す。車両情勢情報１０４は、車両５０に搭載される車載装置３を識別する車載装置ＩＤ１０４１と、当該車載装置に侵害があったかどうかを示す侵害有無１０４２とを含む。
　図８Ａの車両情勢情報１０４は、ステップ３０１の実行に先立って生成しておくことができる。たとえば、所定の期間（情勢情報記録期間）内に異常が発生した車載装置３については「１」を記録し、そうでない車載装置３については「０」を記録しておくことができる。
　異常の発生は、攻撃の予兆活動の可能性を示唆するものであるため、情勢情報記録期間内に異常が発生したか否かを表す情報は、各車載装置３について攻撃の予兆活動があったか否かを表す情報であるということもできる。
　情勢情報記録期間の始点および終点は任意に設計可能であるが、たとえば車両５０の動作期間（たとえば車両５０が起動してから停止するまでの期間）であってもよく、分析装置１の動作期間（たとえば分析装置１が起動してから停止するまでの期間）であってもよい。このようにすると、異常ログの記録と、分析装置１または車両５０の動作期間とを整合させ、より適切な判定を行うことができる。
　また、この情勢情報記録期間は、特定のイベント信号に基づいて決定される期間であってもよく、予め定められた時刻に基づく期間であってもよい。
　車両情勢情報１０４は、任意のタイミングで更新されるよう設計することができる。たとえば情勢情報記録期間が終了することに応じて更新されてもよい。たとえば、車両情勢情報１０４が第１の情勢情報記録期間に関する情報を保持している場合に、第２の情勢情報記録期間が終了すると、車両情勢情報１０４は第２の情勢情報記録期間に対応する内容に更新されてもよい。なお、情勢判断結果１０５は、任意のタイミングで初期化することができる。例えば、トリップタイムが変わった場合（すなわちそれまでのトリップタイムが終了し、新たなトリップタイムが開始された場合）には、情勢判断結果１０５を維持してもよいし、情勢判断結果１０５を初期化すなわち「０ｘ００」に設定してもよい。車両５０外部からの所定の手続き（たとえば、ＳＯＣによって問題ないことが確認された、問題のあったプログラムが修正された、等）が行われた場合に情勢判断結果１０５を初期化してもよい。或いは、すべての車載装置３または該当する車載装置３から、コード検証結果として改ざんがなかったことを示すログが収集された場合に、情勢判断結果１０５を初期化してもよい。
　ステップ３０１において、たとえば図５に示す異常ＩＤ１０１１が「０ｘ００２」の異常ログについて、予兆活動判定部１５は、まず当該異常ログに係る車載装置（この場合には車載装置Ａ）に予兆活動があったか否かを判定する。たとえば、車載装置Ａに対応する侵害有無１０４２の値が「１」であれば予兆活動があったと判定し、「０」であれば予兆活動がなかったと判定する。この例では「車載装置Ａ」となる車載装置ＩＤ１０４１に該当する侵害有無１０４２の値が「０」であるので、車載装置Ａについて予兆活動がなかったと判定される。
　次に、予兆活動判定部１５は、上記のように装置間影響情報１０３に基づいて影響先を車載装置Ｄとして特定し、車載装置Ｄに予兆活動があったか否かを判定する。たとえば、車載装置Ｄに対応する侵害有無１０４２の値が「１」であれば予兆活動があったと判定し、「０」であれば予兆活動がなかったと判定する。この例では「車載装置Ｄ」となる車載装置ＩＤ１０４１に該当する侵害有無１０４２の値が「１」であるので、車載装置Ｄについて予兆活動があったと判定される。
　また、たとえば車載装置Ｃに係る異常ログについて、図７において被害装置１０３１が車載装置Ｃである場合には、影響先１０３２として、車載装置Ｄおよび車載装置Ｅを含むグループと、車載装置Ｆのみを含むグループとが関連付けられている。このため、車載装置Ｃに係る異常ログについては、車載装置Ｄに対応する侵害有無１０４２と、車載装置Ｅに対応する侵害有無１０４２とがいずれかまたは双方が「１」である場合には、車載装置Ｄ或いは車載装置Ｅ、或いは双方について予兆活動があったと判定され、双方とも「０」である場合には、車載装置Ｄおよび車載装置Ｅについて予兆活動がなかったと判定される。また、車載装置Ｆに対応する侵害有無１０４２が「１」である場合には、車載装置Ｆについて予兆活動があったと判定され、「０」である場合には、車載装置Ｆについて予兆活動がなかったと判定される。
　予兆活動判定部１５は、すべての異常ログについて上記のように予兆活動の有無を判定してもよい。また、予兆活動判定部１５は、上記ステップ２０２で、車両ログ情報１０１から抽出した異常ログに基づき、異常が発生している被害装置を特定し、装置間影響情報１０３を用いて当該被害装置の影響範囲を特定し、当該被害車載装置と影響範囲に含まれる車載装置に該当する車載装置ＩＤ１０４１について侵害有無１０４２を参照し、これによって攻撃予兆の有無を判定してもよい。
　ステップ３０１における判定の結果、いずれかの車載装置において予兆活動があったと判定した場合にはステップ３０２に進み、予兆活動がなかったと判定した場合にはステップ３０３に進む。
　ステップ３０２では、攻撃検知判定部１７はコード検証結果を参照する。たとえば、ステップ３０１において予兆活動があったと判定された車載装置３のコード検証結果が参照される。コード検証結果の具体例はとくに図示しないが、たとえば車載装置３によって実行されるプログラムの改ざんがあったか否かを示すものであり、公知技術等に基づいて生成可能である。なお、上記ステップ２０１で取得したログが、車載装置３のコード検証結果（たとえば改ざんの有無）を表すログである場合には、ステップ３０２において、当該ログの内容が、改ざんがあったことを示すか否かを判定してもよい。例えば、分析装置１は、車両５０起動時（或いは分析装置１の起動時）に、上記ステップ２０１において、各車載装置３から、各車載装置３のコード検証結果（改ざんの有無）を収集し、本ステップ３０２において、コード検証結果を判定してもよい。
　コード検証結果は、たとえばセキュアブート処理によって生成される。セキュアブート処理は、車載装置３によって実行されるプログラムの改ざんがあったか否かを、当該プログラムの実行開始に際して判定するための処理である。なお、コード検証結果はセキュアブート処理によるものに限らず、プログラムの実行開始後の任意のタイミングで実行される検証の結果であってもよい。
　予兆活動があった車載装置３によって実行されるプログラムの改ざんがあったと判定された場合には、処理はステップ３０４に進む。そうでない場合には、処理はステップ３０５に進む。
　ステップ３０３、３０４および３０５において、車両状態更新部１６は車両ログ情報１０１から抽出した新規の異常ログに基づいて、車両情勢情報１０４を更新する。
　図８Ｂに、上記ステップ３０３において更新する車両情勢情報１０４の例を示す。なお、本実施例では、車両情勢情報１０４が図８Ａに示す情報および図８Ｂに示す情報の双方を含むが、これらの情報はそれぞれ異なる領域（たとえば異なるデータベース、ＲＡＭ、データフラッシュ）に含まれてもよい。
　図８Ｂに示す車両情勢情報１０４は、以下の情報を含む。
　‐互いに関連する装置のグループを特定する監視対象グループＩＤ１０４３。
　‐各グループに含まれる車載装置を示す関連装置１０４４。各グループに含まれる装置間の関係は、図７の装置間影響情報１０３と対応するものであってもよい。本実施例において、図８Ｂに示す関係は図７に示す関係と対応するが、変形例においてはこれらが対応する必要はない。
　‐各車載装置における侵害状況を示す侵害情勢１０４５。
　‐侵害情勢１０４５に基づいて、異常通知を出力するか否かを判定する際に用いる閾値を示す閾値１０４６。
　車両状態更新部１６は、異常ログに係る車載装置（たとえば車載装置Ａ）に該当する侵害有無１０４２を「０」から「１」に更新する。たとえば、車載装置Ａに係る異常ログについては、当該車載装置Ａを被害装置１０３１とするグループのＩＤ｛０ｘ０１｝を図７の監視対象グループＩＤ１０３３から取得し、図８Ｂにおいてこれに対応するグループの侵害情勢１０４５（図８Ｂの例では｛１、１｝となっている）が｛０、０｝であれば、これを｛１、０｝に更新する。
　ステップ３０６では、攻撃検知判定部１７は、車両情勢情報１０４における侵害情勢１０４５と閾値１０４６とを比較する。たとえば、各グループについて、侵害情勢１０４５に含まれる数の和と、閾値とを比較する。和が閾値を超過している場合には、累積通知を出力すると判定する。累積通知とは異常通知の一種である。和が閾値を超過していない場合には、異常通知を出力しないと判定する。
　なお、変形例としてステップ３０６の判定を省略してもよく、その場合には異常通知を出力しないと決定してもよい（和が閾値を超過していない場合と同様）。
　ステップ３０７では、車両状態更新部１６はステップ３０３、３０４または３０６の結果に応じて情勢判断結果１０５を更新する。
　図９に、情勢判断結果１０５の例を示す。情勢判断結果１０５は、車両の情勢を識別する情勢判断ＩＤ１０５１と、車両の情勢内容を示すステータス１０５２とを含む。
　例えば、初期状態（たとえば、いかなる異常ログも記録されていない状態）として、情勢判断ＩＤ１０５１は「０ｘ００」であり、ステータス１０５２は「通常」である。
　ステップ３０７の前にステップ３０３が実行されていた場合には、情勢判断ＩＤ１０５１は「０ｘ０１」となり、ステータス１０５２は「継続監視」となる。
　ステップ３０７の前にステップ３０４が実行されていた場合には、情勢判断ＩＤ１０５１は「０ｘ１１」となり、ステータス１０５２は「即時通知」となる。
　ステップ３０７の前にステップ３０６が実行されており、閾値を超過していた場合には、情勢判断ＩＤ１０５１は「０ｘ１０」となり、ステータス１０５２は「累積通知」となる。また、ステップ３０７の前にステップ３０６が実行されており、閾値を超過していなかった場合には、情勢判断ＩＤ１０５１は「０ｘ０１」となり、ステータス１０５２は「継続監視」となる。
　なお、複数の異常ログについて結果が異なる場合には、情勢判断ＩＤ１０５１は結果のうち最大の値が優先される。たとえば、ある異常ログについて「継続監視」（情勢判断ＩＤ１０５１は「０ｘ０１」）と判定され、別の異常ログについて「即時通知」（情勢判断ＩＤ１０５１は「０ｘ１１」）と判定された場合には、結果として情勢判断ＩＤ１０５１は「０ｘ１１」となる。
　図９に示すように、本実施例において、異常通知は、異常が発生した回数に係る累積通知と、発生した異常の内容に係る即時通知とを含む。
　異常通知は、当該異常通知が累積通知であるか、または即時通知であるかを示す情報を含んでもよい。このようにすると、異常の内容をより詳細に出力することができる。
　以上の処理によって、分析装置１は、異常通知を車両の外部に出力するか否かを決定できる。異常通知を出力すると決定された場合には、早期対処につなげるための適切なタイミングで車両の外部に通知できる。
　図３のステップ３０１、３０２および３０４によれば、分析装置１は、車載装置３のいずれかについて、予兆活動があり（すなわち所定期間内に異常が発生しており）、かつ改ざんがあったと判定された場合に、異常通知を出力すると決定する。このため、過去の予兆活動と、最新のコード検証結果とに基づいて、より適切な判定を行うことができる。
　図４は、分析装置１が車両の外部に対して車載装置の情報を出力する処理の一例を示すフローチャートである。分析装置１は、図２に示すステップ２０９に加えて、またはこれに代えて、図４に示す処理によって異常通知を出力してもよい。
　図４では、特に、定時報告として出力するケースと、車両の外部からの指示に従って出力するケースとについて説明する。以下に説明する各ステップの実行主体は、たとえば分析装置１の不図示のＣＰＵである。また、本処理フローは、たとえば車両５０の起動に際して実行される。さらに本処理フローは、所定のタイミングで実行してもよく、定期的に繰り返し実行してもよく、異常を通知した後に実行してもよい。
　ステップ４０１では、指示内容解析部２０は車両の外部からの通知指示を受信したかどうかを確認し、通知指示を受信した場合はステップ４０２に進み、通知指示を受信していない場合はステップ４０５に進む。
　ステップ４０２では、指示内容解析部２０は車両の外部から受信した指示内容を解析する。例えば、指示内容は、車両の外部に出力する情報を指定する情報を含む。たとえば、指示内容は、特定の車載装置に対する指定、特定のログ情報に対する指定、他の車載装置から追加で収集すべきログ情報に対する指定、車両において保持されている他の情報に対する指定、等を含んでもよい。また、指示内容は、分析装置１の機能または構成を変更するための情報を含んでもよい。
　ステップ４０３では、通知情報生成部１８は上記ステップ４０２で解析した内容に基づいて、必要な情報を分析装置１、或いは車載装置３から収集する。
　ステップ４０４では、通知情報生成部１８は上記ステップ４０３で収集した情報から車両の外部に出力する情報を生成する。
　ステップ４０５では、通知タイミング制御部２１は、現時刻が所定の通知タイミングになっているかどうかを確認する。例えば、所定のタイミングは、所定のイベント或いは処理が発生したタイミング（たとえば起動時）、或いは所定の日時でもよい。
　ステップ４０６では、通知タイミング制御部２１は、上記ステップ４０５の確認結果に基づいて、現時刻が所定のタイミングである判定した場合にはステップ４０７に進み、それ以外の場合には本処理フローを終了する。
　ステップ４０７では、通知情報生成部１８は車両の外部に出力する定型データを生成する。例えば、分析装置１の記憶部に保持する情報の一部あるいはすべてからなる情報を生成する。
　ステップ４０８では、通知判断部１９は上記ステップ４０４、或いは上記ステップ４０７で生成した情報を車両の外部に出力する。出力先は図２のステップ２０９と同様に設計することができる。
　以上の処理によれば、分析装置１は、各車載装置３の異常が発生したか否かに関する判定の結果と、各車載装置３のコード検証結果とに基づき、異常通知を出力するか否かを決定する。
　また、たとえば、センタ側の運用負荷やデータ通信コストを考慮したタイミングで定期的に所定の情報を通知できるとともに、攻撃が発生したと判断したような事態において、車両の外部からの要求指示に従って柔軟に追加の情報を通知できる。
　このため、分析装置１は車載装置から取得した異常ログと即時通知ルールに基づいて、車両の外部に対して適切なタイミングで異常通知を出力できる。
　より具体的には、分析装置１は、異常ログと予兆活動に基づいて、攻撃を受けていると判定し、車両の外部に対して異常通知を出力できる。
　また、コード検証結果に関わらず、車両情勢の侵害度に基づいて、車両の外部に対して異常通知を出力できる。これにより、緊急性を要する異常ログを検知した場合は即時に異常通知を出力できる。
　また、実施例１によれば、攻撃を受けていないときに通知するケースを低減でき、一方で、攻撃の可能性が高いケースを見逃しにくくなる。このため、ＳＯＣのようなセンタサービスと連携する際の負荷を適正化できる。
　また、実施例１によれば、コード検証結果はセキュアブート処理によって生成することができるので、セキュアブート処理の結果を有効に活用することができる。
　また、実施例１のステップ３０６を省略する変形例によれば、分析装置１は、車載装置３のいずれについても改ざんがなかったと判定された場合に、異常通知を出力しないと決定する。この場合には、異常ログに基づく攻撃の誤検知を抑制することができる。
　実施例１において、図２および図３の処理は例であり、適宜変更することができる。たとえば、ステップ２０４における判定の基準、ステップ３０２における判定の基準、等は任意に変更可能である。また、たとえばステップ３０１を省略し、ステップ２０６においては常にステップ３０２を実行するようにしてもよい。
　また、判定に用いる情報の形式は、適宜追加、省略または変更することができる。たとえば図６Ａ、図７、図８Ｂの情報を省略してもよく、その場合には被害装置と影響先の装置とを同一の装置としてもよい。
　１…分析装置、３…車載装置（監視対象装置）
　本明細書で引用した全ての刊行物、特許および特許出願はそのまま引用により本明細書に組み入れられるものとする。

Claims (8)

  1. 　複数の監視対象装置に対して通信可能に構成される分析装置において、
    　前記分析装置は、
    　各前記監視対象装置の監視結果を収集し、
    　前記監視結果に基づき、各前記監視対象装置の異常が発生したか否かを判定し、
    　前記判定の結果と、各前記監視対象装置のコード検証結果とに基づき、異常を示す異常通知を出力するか否かを決定する、
    分析装置。
  2. 　請求項１に記載の分析装置であって、
    　各前記監視対象装置は車両に搭載されており、
    　前記コード検証結果は、前記監視対象装置によって実行されるプログラムの改ざんがあったか否かを当該プログラムの実行開始に際して判定する、セキュアブート処理によって決定される、
    分析装置。
  3. 　請求項２に記載の分析装置であって、
    　前記分析装置は、前記監視対象装置のいずれかについて、所定期間内に異常が発生しており、かつ改ざんがあったと判定された場合に、前記異常通知を出力すると決定する、
    分析装置。
  4. 　請求項２に記載の分析装置であって、
    　前記分析装置は、前記監視対象装置のいずれについても改ざんがなかったと判定された場合に、前記異常通知を出力しないと決定する、
    分析装置。
  5. 　請求項１に記載の分析装置であって、
    　前記分析装置は、さらに、所定期間内に前記監視対象装置のいずれかについて異常が発生した回数または所定期間内に同一の異常が発生した回数に基づき、前記異常通知を出力するか否かを決定する、
    分析装置。
  6. 　請求項１に記載の分析装置であって、
    　前記分析装置は、さらに、前記監視対象装置のいずれかについて発生した異常の内容に基づき、前記異常通知を出力するか否かを決定する、
    分析装置。
  7. 　請求項３に記載の分析装置であって、
    　前記所定期間は、前記監視対象装置が搭載された車両の動作期間または前記分析装置の動作期間である、
    分析装置。
  8. 　請求項１に記載の分析装置であって、
    　前記異常通知は、異常が発生した回数に係る累積通知と、発生した異常の内容に係る即時通知とを含み、
    　前記異常通知は、当該異常通知が前記累積通知であるか、または前記即時通知であるかを示す情報を含む、
    分析装置。
PCT/JP2021/031266 2021-03-09 2021-08-26 分析装置 Ceased WO2022190408A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202180084765.6A CN116635275A (zh) 2021-03-09 2021-08-26 分析装置
EP21930257.7A EP4307145B1 (en) 2021-03-09 2021-08-26 Analysis device
US18/257,961 US12306953B2 (en) 2021-03-09 2021-08-26 Intrusion anomaly monitoring analysis device in vehicle environment that detects and responds to secure boot processing tampering

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-037773 2021-03-09
JP2021037773A JP7564022B2 (ja) 2021-03-09 2021-03-09 分析装置

Publications (1)

Publication Number Publication Date
WO2022190408A1 true WO2022190408A1 (ja) 2022-09-15

Family

ID=83227776

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/031266 Ceased WO2022190408A1 (ja) 2021-03-09 2021-08-26 分析装置

Country Status (5)

Country Link
US (1) US12306953B2 (ja)
EP (1) EP4307145B1 (ja)
JP (2) JP7564022B2 (ja)
CN (1) CN116635275A (ja)
WO (1) WO2022190408A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7517223B2 (ja) * 2021-03-29 2024-07-17 株式会社デンソー 攻撃分析装置、攻撃分析方法、及び攻撃分析プログラム
US12615272B2 (en) * 2022-09-30 2026-04-28 Denso Corporation Log determination device, log determination method, log determination program, and log determination system
JP7834695B2 (ja) * 2023-09-19 2026-03-24 株式会社東芝 システムおよびプログラム
JP2025075389A (ja) 2023-10-31 2025-05-15 Ｎｔｔセキュリティ・ジャパン株式会社 車両セキュリティ分析システム、車両セキュリティ分析方法、及びプログラム
KR20250066277A (ko) * 2023-11-06 2025-05-13 국방과학연구소 다중 도메인에서 수집된 행위 이벤트 기반의 관계 데이터를 이용한 사이버 공격 추적 방법 및 장치
JP2025152799A (ja) * 2024-03-28 2025-10-10 株式会社デンソー ログ分析装置、ログ分析方法、及びログ分析プログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04107631A (ja) * 1990-08-28 1992-04-09 Seiko Epson Corp 情報処理装置
JP6184575B1 (ja) * 2016-10-17 2017-08-23 三菱電機株式会社 プログラム書き換え及び検証システム
JP2017167916A (ja) * 2016-03-17 2017-09-21 株式会社デンソー 情報処理システム
JP2021037773A (ja) 2020-12-10 2021-03-11 大日本印刷株式会社 複合プリフォームの製造装置、複合プリフォームおよびその製造方法、ならびに複合容器およびその製造方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4668656B2 (ja) * 2005-03-24 2011-04-13 日立オートモティブシステムズ株式会社 プログラムの書き換えシステム及びプログラムの書き換え方法
JP6684690B2 (ja) * 2016-01-08 2020-04-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 不正検知方法、監視電子制御ユニット及び車載ネットワークシステム
US10673880B1 (en) * 2016-09-26 2020-06-02 Splunk Inc. Anomaly detection to identify security threats
CN113595888A (zh) * 2016-12-06 2021-11-02 松下电器（美国）知识产权公司 信息处理装置以及信息处理方法
JP6490879B2 (ja) 2016-12-06 2019-03-27 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 情報処理装置及び情報処理方法
US12438894B2 (en) * 2017-05-30 2025-10-07 Plaxidityx Ltd System and method for providing fleet cyber-security
CN107454117A (zh) * 2017-09-30 2017-12-08 中国联合网络通信集团有限公司 一种车联网的入侵检测方法及系统
JP6761793B2 (ja) * 2017-10-13 2020-09-30 日立オートモティブシステムズ株式会社 車両用制御装置
JP7113337B2 (ja) 2018-01-12 2022-08-05 パナソニックＩｐマネジメント株式会社 サーバ装置、車両装置、車両用システム及び情報処理方法
JP2020067904A (ja) 2018-10-25 2020-04-30 キヤノン株式会社 情報処理装置及びその制御方法、並びにプログラム
JP7138043B2 (ja) * 2018-12-28 2022-09-15 日立Astemo株式会社 情報処理装置
JP2021022787A (ja) 2019-07-25 2021-02-18 トヨタ自動車株式会社 通信システム
JP2021034881A (ja) 2019-08-23 2021-03-01 株式会社デンソー 監視装置
US11503053B2 (en) * 2019-12-20 2022-11-15 Beijing Voyager Technology Co., Ltd. Security management of an autonomous vehicle
CN112345858B (zh) * 2020-11-03 2021-06-01 西华大学 一种计及量测篡改攻击引发虚假故障的电网故障诊断方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04107631A (ja) * 1990-08-28 1992-04-09 Seiko Epson Corp 情報処理装置
JP2017167916A (ja) * 2016-03-17 2017-09-21 株式会社デンソー 情報処理システム
JP6184575B1 (ja) * 2016-10-17 2017-08-23 三菱電機株式会社 プログラム書き換え及び検証システム
JP2021037773A (ja) 2020-12-10 2021-03-11 大日本印刷株式会社 複合プリフォームの製造装置、複合プリフォームおよびその製造方法、ならびに複合容器およびその製造方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4307145A4

Also Published As

Publication number Publication date
EP4307145A4 (en) 2025-01-08
JP2022138009A (ja) 2022-09-22
US20240045970A1 (en) 2024-02-08
JP2024174057A (ja) 2024-12-13
EP4307145A1 (en) 2024-01-17
JP7804735B2 (ja) 2026-01-22
JP7564022B2 (ja) 2024-10-08
CN116635275A (zh) 2023-08-22
EP4307145B1 (en) 2026-04-22
US12306953B2 (en) 2025-05-20

Similar Documents

Publication Publication Date Title
JP7804735B2 (ja) 分析装置
JP7573585B2 (ja) 不正検知サーバ、および、制御方法
US12107876B2 (en) Intrusion path analysis device and intrusion path analysis method
CN115361212B (zh) 不正当检测服务器及其所执行的方法
US11829472B2 (en) Anomalous vehicle detection server and anomalous vehicle detection method
CN113348111B (zh) 车辆安全监视装置、方法以及程序记录介质
CN110463142B (zh) 车辆异常检测服务器、车辆异常检测系统及车辆异常检测方法
US8850582B2 (en) Security monitoring system and security monitoring method
US9921938B2 (en) Anomaly detection system, anomaly detection method, and program for the same
JP7573513B2 (ja) 異常検知方法及び異常検知装置
CN108881267A (zh) 车辆异常检测方法、车载终端、服务器及存储介质
US11595431B2 (en) Information processing apparatus, moving apparatus, and method
RU2018111478A (ru) Система и способ создания правил
US12375504B2 (en) Analysis device and analysis method
EP3848806A1 (en) Information processing device, log analysis method, and program
JP2019073102A (ja) 車両用制御装置
CN113163369A (zh) 一种车辆入侵防御处理方法、装置及汽车
CN106899977B (zh) 异常流量检验方法和装置
CN120825309A (zh) 一种车载网络的安全检测方法、车辆及介质
CN115668191B (zh) 控制系统
CN115879162B (zh) 一种数据库监测的违规操作告警阻断系统
JP7471532B2 (ja) 制御装置
JP7226248B2 (ja) 通信装置および異常判定装置
CN114531269A (zh) 一种Tbox裁决方法及装置
CN120143797A (zh) Can总线异常检测方法、装置、车辆、介质及程序产品

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21930257

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180084765.6

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 18257961

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2021930257

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021930257

Country of ref document: EP

Effective date: 20231009

WWG Wipo information: grant in national office

Ref document number: 18257961

Country of ref document: US

WWG Wipo information: grant in national office

Ref document number: 2021930257

Country of ref document: EP