Patent Description:
Conventionally, there have been monitoring/detecting software and monitoring/detecting appliances installed on devices such as IoT (Internet of Things) devices; control devices of IoT devices that control industrial machines such as robots; or network devices that manage connections among these (hereafter, simply referred to as "devices" collectively), to detect cyber-attacks. Also, detection logs of cyber-attacks detected by these devices are uploaded to an analysis server installed at a center.

Such monitoring/detecting software and monitoring/detecting appliances monitor communication logs and system logs obtained from the devices to detect cyber-attacks. Also, the center analyzes the detection logs of cyber-attacks in detail to recognize detailed contents of the cyber-attacks in terms attacking methods and the like.

<CIT> describes an event-based attack detection.

<CIT> describes systems and methods for detecting distributed attacks.

<CIT> describes distributed detection of malicious cloud actors.

However, there are events that are difficult to detect simply by individually analyzing logs from the devices. For example, in individual analysis, it is difficult to detect events occurring across multiple devices (e.g., large-scale cyber-attacks, etc.).

The present invention has been made in view of the above points, and has an object to be capable of detecting events occurring across multiple devices.

According to a first aspect of the present invention there is provided an analysis apparatus according to claim <NUM>.

According to a second aspect of the present invention there is provided an analysis system according to claim <NUM>.

According to a third aspect of the present invention there is provided an analysis method according to claim <NUM>.

According to a fourth aspect of the present invention there is provided a program according to claim <NUM>.

It is possible to detect events occurring across multiple devices.

In the following, embodiments according to the present invention will be described based on the drawings. <FIG> is a diagram illustrating an example of a system configuration in an embodiment according to the present invention. In <FIG>, multiple vehicles <NUM> are automobiles (connected cars) connected to various servers (monitoring server <NUM>, car company's official server 30a, service providing server 30b, etc.) via a network N1 such as the Internet. For example, each vehicle <NUM> is connected to the network N1 via a wireless network such as a mobile communication network, to communicate with the various servers.

The car company's official server 30a is one or more computers to provide services via the network N1, which is operated by a car company of the vehicles <NUM>, to manage the vehicles <NUM> (connected cars) and to provide official services of the car company. For example, the car company's official server 30a may provide telematics services.

The service providing server 30b is one or more computers operated by a third party to provide various services to the users of the vehicles <NUM> for increasing the convenience of the vehicles <NUM>.

The monitoring server <NUM> is one or more computers to detect an occurrence of events across multiple vehicles <NUM>, based on data transmitted (uploaded) from the vehicle <NUM>.

<FIG> is a diagram illustrating an example of a hardware configuration of the monitoring server <NUM> in an embodiment according to the present invention. In <FIG>, the monitoring server <NUM> includes a drive device <NUM>, an auxiliary storage device <NUM>, a memory device <NUM>, a CPU <NUM>, an interface device <NUM>, and the like, which are connected with each other via a bus B.

A program that implements processing on the monitoring server <NUM> is provided with a recording medium <NUM> such as a CD-ROM. Once the recording medium <NUM> on which the program is stored is set in the drive device <NUM>, the program is installed in the auxiliary storage device <NUM> from the recording medium <NUM> via the drive device <NUM>. However, installation of the program does not need to be executed from the recording medium <NUM> necessarily, and may be downloaded from another computer via the network. The auxiliary storage device <NUM> stores the installed programs, and stores necessary files, data, and the like.

The memory device <NUM> reads and stores the program from the auxiliary storage device <NUM> when receiving a start command of the program. The CPU <NUM> executes functions related to the monitoring server <NUM> according to the program stored in the memory device <NUM>. The interface device <NUM> is used as an interface for connecting to the network.

<FIG> is a diagram illustrating an example of a hardware configuration of the vehicle <NUM> in an embodiment according to the present invention. In <FIG>, the vehicle <NUM> includes a communication device <NUM>, an information subsystem <NUM>, a control subsystem <NUM>, a gateway <NUM>, and the like.

The communication device <NUM> includes a communication module for connecting to the network N1, a communication module for communicating with the other vehicles <NUM> or devices on roads, a communication module for connecting to smartphones and the like via a wireless LAN or short-distance wireless communication, and the like.

The information subsystem <NUM> is a part to execute information processing according to the installed programs, which includes a CPU <NUM>, a memory device <NUM>, an auxiliary storage device <NUM>, a display device <NUM>, an input device <NUM>, and the like. The auxiliary storage device <NUM> stores the installed programs and various items of data used by the programs. The memory device <NUM> reads and stores a program to be activated from the auxiliary storage device <NUM>. The CPU <NUM> executes functions related to the information subsystem <NUM> according to the program stored in the memory device <NUM>. The display device <NUM> displays a GUI (Graphical User Interface) or the like according to the program. The input device <NUM> is constituted with operational parts such as buttons and a touch panel to be used for inputting various operation commands. Note that, for example, in-vehicle devices such as a car navigation system and a head unit of a car audio system are examples of the information subsystem <NUM>.

The control subsystem <NUM> is a part to control the behavior of the vehicle <NUM>, which includes multiple microcomputers <NUM> and the like for various types of control. For example, an ECU (Electronic Control Unit) is an example of the microcomputer <NUM>.

The gateway <NUM> is a gateway (e.g., CGW (Central Gateway)) for connecting the information subsystem <NUM> with the control subsystem <NUM>. In other words, the communication protocol handled in the information subsystem <NUM> is, for example, an IP protocol; and a communication protocol used for communication between the microcomputers <NUM> in the control subsystem <NUM> is a non-IP protocol specialized for control (e.g., CAN (Controller Area Network)). Therefore, the gateway <NUM> is provided to absorb differences between these communication protocols.

Note that the hardware configuration illustrated in <FIG> is merely an example. The hardware configuration of the vehicle <NUM> is not limited to any particular one, as long as the functions described later can be implemented.

<FIG> is a diagram illustrating an example of a functional configuration of the vehicle <NUM> and the monitoring server <NUM> in an embodiment according to the present invention. In <FIG>, the information subsystem <NUM> of the vehicle <NUM> includes a connection information management unit <NUM>, an management function execution unit <NUM>, a service function execution unit <NUM>, a function execution management unit <NUM>, an anomaly determination unit <NUM>, a log transmitter unit <NUM>, and the like. These units are implemented by one or more programs installed in the information subsystem <NUM> that cause the CPU <NUM> to execute processing. The information subsystem <NUM> also includes databases (storage unit) such as a log DB <NUM> and a detection DB <NUM>. These databases (storage unit) can be implemented by using, for example, the memory device <NUM> or the auxiliary storage device <NUM>.

The management function execution unit <NUM> accesses the car company's official server 30a that manages the vehicle <NUM> via the Internet or the like, to execute processing, for example, for remote control of the vehicle <NUM> and update of the software, using a remote access terminal such as a tablet or a smartphone.

The service function execution unit <NUM> and the management function execution unit <NUM> implement the respective functions via an external network (a network outside of the vehicle <NUM>). The service function execution unit <NUM> is a group of applications that use the services provided by the service providing server 30b by accessing the service providing server 30b via the Internet or the like without going through the car company's official server 30a. For example, a video distribution service or the like may be considered as an example of the service. In this case, the service function execution unit <NUM> executes downloading and playing back of videos.

Although access to the management function execution unit <NUM> involved in the control of the vehicle <NUM> from the service function execution unit <NUM> cannot be executed, the service function execution unit <NUM> and the management function execution unit <NUM> are implemented on the same operating system. Therefore, threats of unauthorized device control via the management function execution unit <NUM> by attacking the vulnerability of an application of the service function execution unit <NUM> or the OS are assumed.

The connection information management unit <NUM> sequentially collects (upon each communication event) log data such as an external communication log, a control communication log, and the like (hereafter, referred to as the "communication log" in the case of not distinguishing the respective logs), and stores the collected log data in the log DB <NUM>, to collectively manage the communication logs.

The external communication log includes a communication log between the management function execution unit <NUM> or the service function execution unit <NUM>, and an external network such as IP communication; a wireless communication log by Wi-Fi (trademark registered), Blutooth (trademark registered), or the like; a communication log of connection of a physical device to the USB; and the like.

The control communication log corresponds to a non-IP communication log transmitted and received by a protocol such as CAN (Controller Area Network) between the microcomputers <NUM> of the control subsystem <NUM>.

For example, the communication log is constituted with information on requests and responses that includes a vehicle ID; a timestamp (date and time information); information on a connection source (a subsystem constituting the vehicle <NUM>); information on an external connection destination (an external server such as the car company's official server 30a or the service providing server 30b, a device to be connected by short-distance wireless communication, or a device physically connected through the USB or the like); and an execution command. Alternatively, the communication log may be data of communication contents (communication data including the header information) to which information on date and time (time stamp) is given. Note that the vehicle ID is identification information on a vehicle <NUM>.

The function execution management unit <NUM> sequentially collects a system log, an application log, a sensor log, and an error log, and stores the collected logs in the log DB <NUM>, to collectively manage these logs. The system log and the application log correspond to log data related to operations and the like of the OS constituting the information subsystem <NUM> and applications running on the OS. Therefore, log data that includes information on processing other than communication executed by the service function execution unit <NUM> and the management function execution unit <NUM> is also included in the system log or application log. The sensor log corresponds to log data that includes positional information (latitude and longitude) on the vehicle <NUM> measured by a GPS (Global Positioning System) receiver of the vehicle <NUM>; and values measured by various sensors installed on the vehicle <NUM> such as the speed of the vehicle <NUM>, the acceleration of the vehicle <NUM>, and the like. The error log corresponds to log data that includes information on errors (anomalies) output by the microcomputers <NUM> constituting the control subsystem <NUM>.

Note that the system log and the application log include, for example, information on the vehicle ID, timestamps, processes of the OS and applications constituting the information subsystem <NUM> in the vehicle <NUM>; information on actions (operations on objects such as creation, deletion, and modification); information on objects (files, communications, and (child) processes); and the like. Also, the sensor log includes the vehicle ID, time stamps, values measured by the sensors, and the like. Also, the error log includes, for example, the vehicle ID, timestamps, error codes, and the like.

The log DB <NUM> stores the various logs described above in a time series.

The anomaly determination unit <NUM> determines whether or not an anomaly occurs in the vehicle <NUM>, based on the log data (the external communication log, control communication log, system log, application log, sensor log, and error log) stored in the log DB <NUM>. However, the resources of the vehicle <NUM> are limited; therefore, in the case of having detected some anomaly, the anomaly determination unit <NUM> generates a log presenting a detection result of the anomaly (hereafter, referred to as a "detection log"), and stores the detection log in the detection DB <NUM>. Note that determination (calculation) of the presence or absence of an anomaly based on the log data can be executed by using known techniques. For example, an anomaly score may be determined by inputting the log data into a predetermined trained anomaly detection learning model (e.g., a neural network) that receives log data as input, and outputs an anomaly score. The anomaly score may be <NUM> or <NUM> indicating the presence or absence of an anomaly, or may be a value indicating the degree of anomalousness within a range from a minimum value (e.g., "<NUM>") to a maximum value (e.g., "<NUM>"). In this case, it may be determined that an anomaly has occurred in the case where the anomaly score exceeds a threshold value. Note that in this way, the anomaly determination unit <NUM> only determines the presence or absence of some anomaly, and does not analyze the anomaly in detail, such as the cause of the anomaly being a cyber-attack or the like.

The log transmitter unit <NUM> transmits the log data stored in the log DB <NUM> or the detection DB <NUM> to the monitoring server <NUM>. The timing of the transmission of the log data may be every time when any item of the log data is stored in the log DB <NUM> or the detection DB <NUM> (i.e., in real time), or may be at regular intervals with a batch of data items. Alternatively, when the detection log is stored in the detection DB <NUM>, among the log data items stored in the log DB <NUM>, only log data items used for detecting the anomaly related to the detection log may be transmitted.

Meanwhile, the monitoring server <NUM> includes a log receiver unit <NUM>, an analysis unit <NUM>, and the like. These units are implemented by one or more programs installed in the monitoring server <NUM> causing the CPU <NUM> to execute processing. The monitoring server <NUM> also uses databases such as an integrated log DB <NUM>, a failure determination DB <NUM>, an attack determination DB <NUM> and an erroneous detection determination DB <NUM>. These databases can be implemented by using, for example, the auxiliary storage device <NUM> or a storage device that can be connected to the monitoring server <NUM> via a network.

The log receiver unit <NUM> receives log data transmitted from the log transmitter unit <NUM> of each vehicle <NUM>, and stores the received log data in the integrated log DB <NUM>. The integrated log DB <NUM> may store the log data separately for each vehicle ID.

The analysis unit <NUM> executes correlation analysis of the log data stored in the integrated log DB <NUM>, to detect an occurrence of events across multiple vehicles <NUM>. Specifically, based on the log data transmitted from each vehicle <NUM>, the analysis unit <NUM> determines which one of multiple types of events (in the present embodiment, failure, cyber-attack, erroneous detection of anomaly, or the other) corresponds to the event occurring in the vehicle <NUM> (classifies the event into one of these types). A determination result indicating a failure is stored in the failure determination DB <NUM>. A determination result indicating a cyber-attack is stored in the attack determination DB <NUM>. A determination result indicating an erroneous detection is stored in the erroneous detection determination DB <NUM>.

Further, based on comparison between the log data items of the respective vehicle <NUM> related to multiple events classified into the same type, the analysis unit <NUM> detects an occurrence of events across multiple vehicles <NUM>. Note that the computational resources provided on the monitoring server <NUM> are ample (large-scale) compared to the computational resources individually provided on each vehicle <NUM>. Therefore, by providing the analysis unit <NUM> on the monitoring server <NUM>, it is possible for the analysis unit <NUM> to execute processing using the ample computational resources.

In the following, processing steps executed by the monitoring server <NUM> will be described. <FIG> is a flow chart illustrating an example of the processing steps executed by the monitoring server <NUM>. Note that the processing steps in <FIG> can be executed in parallel for multiple vehicles <NUM>.

In response to receiving a group of log data items (hereafter, referred to as the "group of logs (to be processed)") transmitted (uploaded) from the log transmitter unit <NUM> of a certain vehicle <NUM> (hereafter, referred to as "the target vehicle <NUM>") (YES at Step S101), the log receiver unit <NUM> stores the group of logs in the integrated log DB <NUM> at Step S102.

Next, based on the presence or absence of the detection log in the group of logs, the analysis unit <NUM> determines the presence or absence of an anomaly related to the target vehicle <NUM> at Step S103. Note that in the present embodiment, although an example is described in which a detection log is generated only in the case where an anomaly is detected by the anomaly determination unit <NUM>, in the case where the anomaly determination unit <NUM> generates a detection log indicating that no anomaly is detected even in the case where no anomaly is detected, the analysis unit <NUM> may refer to the detection log to determine the presence or absence of an anomaly.

If the group of logs does not include a detection log (or if the detection log included in the group of logs indicates that no anomaly is detected) (NO at Step S103), the process returns to Step S101. If the group of logs includes the detection log (or if the detection log included in the group of logs indicates that the anomaly has been detected) (YES at Step S103), the analysis unit <NUM> determines whether there is a likelihood of a failure in the target vehicle <NUM> at Step S104. Whether there is a likelihood of a failure may be determined depending on whether the group of logs includes an error log. Alternatively, whether there is a likelihood of a failure may be determined based on whether or not an error log that includes the same vehicle ID as in the detection log, and includes a timestamp indicating date and time within a predetermined period before the date and time of the timestamp of the detection log, is stored in the integrated log DB <NUM>. In other words, if there is a corresponding error log, the analysis unit <NUM> determines that there is a likelihood of a failure, or if there is no corresponding error log, determines that there is no likelihood of a failure.

If it is determined that there is a likelihood of a failure (i.e., if the event that has occurred in the target vehicle <NUM> is classified as a failure) (YES at Step S104), the analysis unit <NUM> stores a determination result of the failure (hereafter, referred to as the "failure determination result") in the failure determination DB <NUM> at Step S105. The failure determination result includes the vehicle ID of the target vehicle <NUM>, a timestamp indicating the current time, the group of logs, and the like.

Next, the analysis unit <NUM> searches for a group of failure determination results related to the other vehicles <NUM> of the same model and model year as the target vehicle <NUM> that are traveling near the current position of the target vehicle <NUM> (e.g., within a radius of N km) in the failure determination DB <NUM> at Step S106. In the present embodiment, it is assumed that the model and model year of each vehicle <NUM> is included in the vehicle ID. Therefore, it is possible to identify a group of failure determination results of the other vehicles <NUM> that have the same model and model year as the target vehicle <NUM> (hereafter, referred to as the "group A of failure determination results"), by comparing the model and model year of the vehicle ID of the target vehicle <NUM> with the model and model year of the vehicle ID of each of the failure determination results of the other vehicles <NUM> stored in the failure determination DB <NUM>.

Also, the current position of the target vehicle <NUM> can be identified based on the latest positional information in the sensor log included in the group of logs. Also, the position of the vehicle <NUM> related to each failure determination result can be identified based on the latest positional information in the sensor log included in the failure determination result. Therefore, the group of failure determination results of the other vehicles <NUM> traveling near the current position of the target vehicle <NUM> that have the same model and model year as the target vehicle <NUM> corresponds to, among the group A of failure determination results, a set of failure determination results having time stamps different within a threshold value from the time stamp in the failure determination result of the target vehicle <NUM>, in which the difference between the position according to the positional information indicated in the sensor log and the position according to the positional information indicated in the sensor log of the failure determination result of the target vehicle <NUM> is within N km (hereafter, referred to as the "group B of failure determination results").

Next, the analysis unit <NUM> determines whether or not the number of failure determination results included in the group B of failure determination results is greater than or equal to a threshold value 'a' at Step S107. Note that at Step S107, it may be determined whether or not the number of failure determination results included in the group A of failure determination results is greater than or equal to the threshold value 'a'. In other words, it may be determined such that the positional relationship with the target vehicle <NUM> is not taken into account.

If the number of failure determination results is less than the threshold value 'a' (NO at Step S107), the process returns to Step S101. In this case, the failure of the target vehicle <NUM> is treated as an individual event.

If the number of failure determination results is greater than or equal to the threshold value 'a' (YES at S107), the analysis unit <NUM> compares each corresponding failure determination result with the failure determination result of the target vehicle <NUM> at Step S108, and among the corresponding failure determination results, determines whether or not the number of failure determination results showing a similar tendency with respect to the failure determination result of the target vehicle <NUM> is greater than or equal to a threshold value 'b' at Step S109. In other words, for the failure determination results of multiple vehicles <NUM>, comparative analysis is performed with reference to the logs of the multiple vehicles <NUM>. For example, various log data items included in each corresponding failure determination result may be compared with the various log data items included in the failure determination result of the target vehicle <NUM>. The log data items to be compared may be limited to the error log and the control communication log. Whether or not there is a similarity may be determined using a known method of calculating the degree of similarity of multiple parameters. Alternatively, similarity of the two may be evaluated based on whether or not an anomaly pattern that does not normally occur is observed in both of the system log or control communication log included in the failure determination result of the target vehicle <NUM>, and the system log or control communication log included in the failure determination result of a vehicle to be compared.

If the number of failure determination results is less than the threshold value 'b' (NO at Step S109), the process returns to Step S101. In this case, the failure of the target vehicle <NUM> is treated as an individual event.

If the number of failure determination results is greater than or equal to the threshold value 'b' (YES at S109), the analysis unit <NUM> detects that failures are occurring in units of lots at Step S110. Failures in units of lots correspond to, for example, failures in the vehicle <NUM> having the same model and model year. In other words, an occurrence of the same failures is detected across multiple vehicles <NUM> in units of lots. In this case, the analysis unit <NUM> may transmit a notice indicating a likelihood of the failure in units of lots, which includes the model; model year; and the like of the target vehicle <NUM>, for example, to the car company's official server 30a or the like. Based on the notice, the car company may replace physical components of the vehicle <NUM> that may be causing the failure.

Alternatively, if having determined at Step S104 that there is no likelihood of a failure (NO at Step S104), the analysis unit <NUM> determines whether or not there is a likelihood of a cyber-attack at Step S111. Whether or not there is a likelihood of a cyber-attack may be determined, for example, with reference to the external communication log among the group of logs. As an example, the analysis unit <NUM> analyzes the degree of maliciousness of a connection destination presented by information on the external connection destination in the external communication log. The degree of maliciousness may be analyzed with reference to a blacklist held in the monitoring server <NUM>; may be analyzed by focusing on transitions of HTTP transmission to detect a connection to a malicious web site caused by a malicious redirection, by using techniques of machine learning; or may be analyzed by using any other known techniques. Also, in the case where the degree of maliciousness of the connection destination is high, the analysis unit <NUM> may determine the presence or absence of a cyber-attack based on whether or not the system log, application log, or the like of the information subsystem <NUM> as the connection source matches a predetermined pattern.

If it is determined that there is a likelihood of a cyber-attack (i.e., if the event that has occurred in the target vehicle <NUM> is classified as a cyber-attack) (YES at Step S111), the analysis unit <NUM> stores a determination result of the cyber-attack (hereafter, referred to as the "attack determination result") in the attack determination DB <NUM> at Step S112. The attack determination result includes the vehicle ID of the target vehicle <NUM>, a timestamp indicating the current time, the group of logs, and the like.

Next, the analysis unit <NUM> searches for a group of attack determination results related to the other vehicles <NUM> of the same model and model year as the target vehicle <NUM> that are traveling near the current position of the target vehicle <NUM> (e.g., within a radius of N km) in the attack determination DB <NUM> at Step S113. The method of identifying the group of attack determination results may be substantially the same as in Step S106.

If the number of attack determination results is less than a threshold value 'c' (NO at Step S114), the process returns to Step S101. In this case, the cyber-attack on the target vehicle <NUM> is treated as an individual event.

If the number of attack determination results is greater than or equal to the threshold value 'c' (YES at S114), the analysis unit <NUM> compares each corresponding attack determination result with the attack determination result of the target vehicle <NUM> at Step S115, and among the corresponding attack determination results, determines whether or not the number of attack determination results showing a similar tendency with respect to the attack determination result of the target vehicle <NUM> is greater than or equal to a threshold value 'd' at Step S116. In other words, for the attack determination results of multiple vehicles <NUM>, comparative analysis is performed with reference to the logs of the multiple vehicles <NUM>. For example, various log data items included in each corresponding attack determination result may be compared with the various log data items included in the attack determination result of the target vehicle <NUM>. Whether or not there is a similarity may be determined using a known method of calculating the degree of similarity of multiple parameters. Alternatively, similarity of the attack determination results may be determined based on whether or not an anomaly pattern that does not normally occur (e.g., a search for a file structure in the system, an execution of a shell command resulting in an upgrade of permission, etc.) is observed in both of the system log included in the attack determination result of the target vehicle <NUM> and the system log included in the attack determination result of a vehicle to be compared; or whether or not anomaly patterns of control communication that do not normally occur (e.g., incoming, etc.) are observed in both of the external communication log included in the attack determination result of the target vehicle <NUM> and the external communication log included in the attack determination result of the vehicle to be compared; or whether or not anomaly patterns that do not normally occur (e.g., transmission timings, payload values, etc.) are frequently observed in both of the control communication log included in the attack determination result of target vehicle <NUM> and the control communication log included in the attack determination result of the vehicle to be compared. In other words, if any of the above anomaly patterns is observed in both, the two may be determined to be similar.

If the number of attack determination results is less than the threshold value 'd' (NO at Step S116), the process returns to Step S101. In this case, the attack on the target vehicle <NUM> is treated as an individual event.

If the number of attack determination results is greater than or equal to the threshold value 'd' (YES at S116), the analysis unit <NUM> detects an occurrence of a large-scale cyber-attack (across the multiple vehicles <NUM>) at Step S117. In this case, the analysis unit <NUM> may transmit a notice indicating detection of a likelihood of a large-scale cyber-attack, which includes the attack determination result of the target vehicle <NUM>; attack determination results determined to be similar to the attack determination result; information indicating a connection destination that has been determined to have a high degree of maliciousness; and the like, for example, to the car company's official server 30a or the like. In response to the notice, the car company's official server 30a may quickly deter the spread of the cyber-attack, by blocking external communication of each vehicle <NUM> identified by the vehicle ID according to the attack determination result included in the notice, or by blocking external communication to the connection destination.

Alternatively, if having determined at Step S111 that there is no likelihood of a cyber-attack (NO at Step S111), the analysis unit <NUM> determines whether or not there is a likelihood of an erroneous detection at Step S118. An erroneous detection means an error in a determination of an anomaly by the anomaly determination unit <NUM> of the target vehicle <NUM>. Whether or not there is a likelihood of an erroneous detection may be determined, for example, with reference to the detection log and the control communication log of the group of logs. As an example, the analysis unit <NUM> may compare feature information extracted from the control communication log that was determined to be an erroneous detection in the past (i.e., the control communication log that has been known to include an erroneous detection), with feature information extracted from the control communication log in the group of logs, to determine whether or not there is a likelihood of an erroneous detection based on a similar pattern of communication intervals and transitions of values. Note that "determined to be an erroneous detection in the past" means, for example, a fact that as a result of an investigation performed manually or in any other ways, the event turned out to be an erroneous detection in the past.

If it is determined that there is a likelihood of an erroneous detection (i.e., if the event that has occurred in the target vehicle <NUM> is classified as an erroneous detection) (YES at Step S118), the analysis unit <NUM> stores a determination result of the erroneous detection (hereafter, referred to as the "erroneous detection determination result") in the erroneous detection determination DB <NUM> at Step S119. The erroneous detection determination result includes the vehicle ID of the target vehicle <NUM>, a timestamp indicating the current time, the group of logs, and the like.

Next, the analysis unit <NUM> searches for a group of erroneous detection determination results related to the other vehicles <NUM> of the same model and model year as the target vehicle <NUM> that are traveling near the current position of the target vehicle <NUM> (e.g., within a radius of N km) in the erroneous detection determination DB <NUM> at Step S120. The method of identifying the group of erroneous detection determination results may be substantially the same as in Step S106.

If the number of erroneous detection determination results is less than the threshold value 'e' (NO at Step S121), the process returns to Step S101. In this case, the erroneous detection of the target vehicle <NUM> is treated as an individual event.

If the number of erroneous detection determination results is greater than or equal to the threshold value 'e' (YES at S121), the analysis unit <NUM> compares each corresponding erroneous detection determination result with the erroneous detection determination result of the target vehicle <NUM> at Step S122, and among the corresponding erroneous detection determination results, determines whether or not the number of erroneous detection determination results showing a similar tendency with respect to the erroneous detection determination result of the target vehicle <NUM> is greater than or equal to a threshold value 'f' at Step S123. In other words, for the erroneous detection determination results of multiple vehicles <NUM>, comparative analysis is performed with reference to the logs of the multiple vehicles <NUM>. For example, various log data items included in each corresponding erroneous detection determination result may be compared with the various log data items included in the erroneous detection determination result of the target vehicle <NUM>. Whether or not there is a similarity may be determined using a known method of calculating the degree of similarity of multiple parameters. Alternatively, a pattern of control communication represented by the control communication log included in the erroneous detection determination result of the target vehicle <NUM> (e.g., communication intervals, transition of communication data, etc.) may be may be compared with a pattern of control communication represented by the control communication log in the erroneous detection determination result of a vehicle to be compared, to evaluate the similarity (e.g., similarity may be calculated by a known method). An erroneous detection determination result of a vehicle to be compared, in which the degree of similarity of the pattern of control communication is greater than or equal to a threshold value, may be determined as an erroneous detection determination result in which the tendency is similar to the erroneous detection determination result of the target vehicle <NUM>.

If the number of erroneous detection determination results is less than the threshold value 'f' (NO at Step S123), the process returns to Step S101. In this case, the erroneous detection of the target vehicle <NUM> is treated as an individual event. By treating in this way, for example, in the case where an anomaly occurs in control communication due to the influence of electromagnetic waves or the like, and the erroneous detection occurs only in a certain area, there is a high likelihood of the number of erroneous detection determination results being less than the threshold value 'f'; therefore, it is possible to avoid determining that the anomaly detection learning model includes a defect.

If the number of erroneous detection determination results is greater than or equal to the threshold value 'f' (YES at S123), the analysis unit <NUM> detects that the anomaly detection learning model used by the anomaly determination unit <NUM> includes a defect in the multiple vehicles <NUM> at Step S124. In this case, the analysis unit <NUM> may transmit a notice indicating detection of a likelihood of a defect in the anomaly detection learning model, which includes the erroneous detection determination result of the target vehicle <NUM>; erroneous detection determination results determined to be similar to the erroneous detection determination result; and the like, for example, to the car company's official server 30a or the like. In response to the notice, the car company's official server 30a may update the anomaly detection learning model of each vehicle <NUM>, or may update the program that causes the CPU <NUM> to function as the management function execution unit <NUM>.

Note that in the present embodiment, although the vehicles <NUM> have been described as examples of devices, the present embodiment may be applied to any other devices having communication functions. For example, the present embodiment may be applied to industrial control devices such as robots in factories; sensors, audio devices, home appliances, communication terminals (smartphones, tablet terminals, etc.) installed in various areas; and devices commonly called IoT (Internet of Things) devices.

As described above, according to the present embodiment, based on log data from multiple devices (vehicles <NUM>), devices in which events having a similar tendency are identified, and by comparing and analyzing the identified multiple items of log data, it is possible to detect a cyber-attack executed in a wide area, a defect in an anomaly detection learning model, a failure occurring in units of manufacturing lots, and the like, which are events that cannot be understood by simply analyzing a single device in detail. In other words, it is possible to detect events occurring across multiple devices.

Note that in the present embodiment, the monitoring server <NUM> is an example of an analysis apparatus. The log receiver unit <NUM> is an example of a receiver unit. The analysis unit <NUM> is an example of a determination unit and a detection unit.

As described above, embodiments according to the present invention have been described in detail; note that the present invention is not limited to such specific embodiments, and various modifications and alterations can be made within the scope of the subject matters of the present invention described in the claims.

Claim 1:
An analysis apparatus comprising:
a receiver unit configured to receive log data transmitted from each device among a plurality of devices connected to a network, via the network;
a determination unit configured to determine, for each device, which one of a plurality of types of events corresponds to an event that has occurred in each device, based on the log data transmitted from each device;
the determination unit is further configured to store a determination result, including associated log data, for each event that has occurred in a device;
the determination unit is further configured to search for a group of determination results of the same event type relating to other devices among the plurality of devices having similar characteristics to the device; and
a detection unit configured to detect an occurrence of events across the plurality of devices, based on a comparison of the log data of the determination results of the group of determination results as determined by the determination unit.