Detection device

Abstract

A detection server (10) is a detection device that detects the presence or absence of an abnormal communication with respect to a plurality of devices, the detection server (10) including: a detection unit (135) that uses a detection model for detecting an abnormal device communication to detect the presence or absence of an abnormal communication for a detection target device, and issues an alert if an abnormal communication is detected; a software bill of materials (SBOM) acquisition unit (131) that acquires SBOM information for each device; an identification unit (136) that, on the basis of the alert occurrence state among the plurality of devices and software configuration information for each device, identifies, from among alerts, an alert having a high possibility of excessive detection, in which a normal communication is erroneously determined to be abnormal; and a notification unit (137) that outputs the processing results of the detection unit (135) and / or the identification unit (136).

Description

Detection device

[0001] The present invention relates to a detection device.

[0002] A wide variety of devices are now connected to the Internet and are being used in a variety of ways. Accordingly, some security measures for these devices use estimators based on unsupervised learning. However, estimators can sometimes produce false positives. For example, a false positive is an over-detection, where normal communication is mistakenly determined to be abnormal.

[0003] As a method for preventing overdetection among alerts generated during operation, there is a method for preventing overdetection by feeding back information on overdetection among alerts to a detection model (Patent Document 1).

[0004] One method for eliminating fraudulent communications during the learning stage is to prepare reliable equivalent devices and communication environments separate from the operational devices, reproduce the communication conditions, and use these to create a reliable detection model (Patent Document 2).

[0005] Patent No. 6767434 Patent No. 7047636

[0006] For example, when detecting anomalous communication in an environment where many devices with the same software configuration are operating, such as a factory, immediately after operation or a configuration change, many similar alerts may be generated from multiple devices, resulting in a large number of alerts. When many alerts are generated from multiple devices in this way, it is difficult to identify false positives from the alerts and provide feedback using the method described in Patent Document 1. Therefore, in reality, all alerts generated within a certain period of time must be considered false positives and suppressed, but this can lead to genuine alerts being overlooked, creating a security risk.

[0007] Furthermore, in the method described in Patent Document 2, it is expected that when operating a device, it may be difficult in terms of cost and workload to prepare equivalent devices and communication environments, reproduce communication conditions, and maintain the environment. Also, in a network anomalous communication detection method using unsupervised learning, it is difficult to detect anomalous communication from devices that are already infected with malicious programs at the communication learning stage.

[0008] The present invention has been made in view of the above, and aims to provide a detection device that can distinguish true alerts from a large number of false detections when a large number of alerts are generated.

[0009] In order to solve the above-mentioned problems and achieve the object, the detection device of the present invention is a detection device that detects the presence or absence of anomalous communication for multiple devices, and is characterized by having: a detection unit that uses a detection model that detects anomalous communication for each device to detect the presence or absence of an abnormality in the communication information of the device to be detected, and issues an alert if an abnormality is detected; an acquisition unit that acquires software configuration information of each device; an identification unit that identifies, from the alerts, alerts that are likely to be overdetections in which normal communication has been mistakenly judged to be abnormal, based on the alert occurrence status between the multiple devices and the software configuration information of each device; and an output unit that outputs the processing results of the detection unit and / or the identification unit.

[0010] According to the present invention, when a large number of alerts are generated, it is possible to distinguish true alerts from a large number of false positives.

[0011] FIG. 1 is a diagram illustrating an example of the configuration of a communication system according to an embodiment. FIG. 2 is a diagram illustrating a processing flow in the communication system illustrated in FIG. 1. FIG. 3 is a diagram illustrating a processing flow in the communication system illustrated in FIG. 1. FIG. 4 is a diagram illustrating an example of the configuration of a detection server illustrated in FIG. 1. FIG. 5 is a diagram illustrating an example of the data configuration of device information illustrated in FIG. 4. FIG. 6 is a diagram illustrating an example of the data configuration of first combination data illustrated in FIG. 4. FIG. 7 is a diagram illustrating an example of the data configuration of second combination data illustrated in FIG. 4. FIG. 8 is a diagram illustrating a relationship between devices and anomaly scores of each alert. FIG. 9 is a diagram illustrating a relationship between devices and anomaly scores of each alert. FIG. 10 is a diagram illustrating the processing of the detection unit and the identification unit illustrated in FIG. 4. FIG. 11 is a diagram illustrating a relationship between devices and anomaly scores of each alert. FIG. 12 is a diagram illustrating a protocol ratio for each alert. FIG. 13 is a flowchart illustrating a processing procedure for detection model generation processing according to an embodiment. FIG. 14 is a flowchart illustrating a processing procedure for detection processing according to an embodiment. FIG. 15 is a flowchart illustrating a processing procedure for first identification processing illustrated in FIG. 14. FIG. 16 is a flowchart illustrating a processing procedure for second identification processing illustrated in FIG. 14. Fig. 17 is a flowchart illustrating a processing procedure of a prediction process according to an embodiment. Fig. 18 is a diagram illustrating an example of a computer that implements a detection server by executing a program.

[0012] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited to this embodiment. In addition, in the description of the drawings, the same parts are designated by the same reference numerals.

[0013] In this embodiment, for alerts of communication anomalies detected by a detection model, alerts that are likely to be overdetections are identified based on the occurrence status of alerts between multiple devices and the software configuration information of each device. An overdetection is an alert that mistakenly identifies normal communication as an anomaly.

[0014] In the embodiments, a case will be described in which, for example, a software bill of materials (SBOM), which is a database of software components, is used as the software configuration information of a device. The SBOM is a file containing information such as the components that make up the software included in a product, their interdependencies, and license data. Specifically, the SBOM contains information indicating the full path, software name, and version relationships of the software, as well as CPE (Common Platform Enumeration) information. The SBOM information is an example, and other software configuration information may also be used.

[0015] [Communication System] A communication system 1 according to an embodiment will be described below. Fig. 1 is a diagram showing an example of the configuration of the communication system 1 according to an embodiment.

[0016] The communication system 1 includes a detection server 10, a communication device 20, and multiple devices 30A to 30C to be monitored. The number of devices 30A to 30C is an example, and may be three or more or less than three. The devices 30A to 30C are collectively referred to as devices 30.

[0017] The device 30 is a communication device that communicates with, for example, an external device via the communication device 20 and the network 40. The device 30 is equipped with various types of software.

[0018] The communication device 20 transmits the communication packets of each device 30 to a destination via the network 40 , and also mirrors the communication packets of each device 30 and transmits them to the detection server 10 .

[0019] The detection server 10 uses the detection model to detect the presence or absence of anomalous communication among the multiple devices 30, and issues an alert if an abnormality is detected. The detection server 10 identifies overdetection alerts that are likely to be overdetections from the detected alerts based on the alert occurrence status among the multiple devices 30 and the SBOM information of each device 30.

[0020] [Processing Overview] FIGS. 2 and 3 are diagrams showing the flow of processing in the communication system 1 shown in FIG.

[0021] As shown in FIG. 2, the detection server 10 acquires SBOM information of the monitored devices 30A to 30C ((1) in FIG. 2).

[0022] The communication device 20 mirrors the communication packets of each device 30 to be monitored and transmits them to the detection server 10 ((2) in FIG. 2).

[0023] The detection server 10 acquires communication packets from the communication devices 20, learns the communications of the devices 30, and generates a detection model. The detection server 10 uses machine learning (e.g., unsupervised learning) to learn the detection model for each device 30. The detection server 10 uses the detection model to start detecting anomalous communications on the network ((3) in FIG. 2 ).

[0024] When an alert occurs, the detection server 10 determines whether the alert is an overdetection based on the SBOM information of the device 30 and other similar alerts ((4) in FIG. 2). Next, the detection server 10 notifies the operator of alerts that are likely to be overdetections ((5) in FIG. 2). Alternatively, the detection server 10 may automatically suppress alerts that are likely to be overdetections by determining them as overdetections.

[0025] In this way, the detection server 10 performs overdetection identification using the alert occurrence status of multiple devices 30 and the software configuration information of the devices 30 when detecting anomalous communication on a network using unsupervised learning.

[0026] The detection server 10 extracts combinations of information based on the SBOM information and overdetection alerts, and stores them in a database (DB) ((6) in FIG. 2).

[0027] When a new device 30 is added in the future, the detection server 10 will predict overdetection in advance by combining the SBOM information of the device 30 to be added, information based on the SBOM information stored in the DB, and overdetection alerts, and will prevent overdetection from occurring ((7) in Figure 2).

[0028] The detection server 10 predicts overdetection alerts in newly added devices 30 by extracting and accumulating the relationship between information about software configuration, such as SBOM information, and overdetection alerts issued due to abnormal communication detection.

[0029] 3, when the detection server 10 receives a communication packet from the device 30 ((1) in FIG. 3), it performs anomalous communication detection for the monitored device 30 using a detection model of another device 30 having the same SBOM information configuration as the monitored device 30 ((2) in FIG. 3). Note that the detection model is a detection model learned from communication with one device other than the monitored device 30 and having the same SBOM information as the monitored device 30, or a detection model learned from communication with multiple devices having the same SBOM information as the monitored device 30.

[0030] If, based on the alert occurrence status over a certain period of time, the monitored device 30 generates more alerts than other devices 30 that have the same SBOM information as the monitored device 30 ((3) in Figure 3), the detection server 10 determines that there is a communication abnormality in the monitored device 30 and notifies the administrator ((4) in Figure 3).

[0031] In this way, when detecting anomalous network communications using unsupervised learning, the detection server 10 detects anomalous communications from devices that are already infected with malicious programs at an early stage, such as the learning stage.

[0032] [Detection Server] Next, a description will be given of the detection server 10. Fig. 4 is a diagram showing an example of the configuration of the detection server 10 shown in Fig. 1 .

[0033] As shown in FIG. 4 , the detection server 10 includes a communication unit 11 , a storage unit 12 , and a control unit 13 .

[0034] The communication unit 11 is realized by a NIC (Network Interface Card) or the like, and controls communication between the control unit 13 and external devices via telecommunication lines such as a LAN (Local Area Network) or the Internet.

[0035] The storage unit 12 stores data, programs, etc. that are referenced when the control unit 13 executes various processes. The storage unit 12 is realized by a semiconductor memory element such as a random access memory (RAM) or a flash memory, or a storage device such as a hard disk or an optical disk. The storage unit 12 has device information 121, SBOM information 122, a communication packet group 123, a detection model group 124, and a DB 125.

[0036] The device information 121 is information relating to the monitoring target device 30. Fig. 5 is a diagram showing an example of the data structure of the device information 121 shown in Fig. 4 .

[0037] As shown in FIG. 5 , the device information 121 includes items such as a device ID, identification information of the SBOM information of the device 30, software installed in the device 30 and its version, the SBOM group to which the device 30 belongs, the port number and IP address of the device 30, and identification information of a detection model used when detecting an abnormality in the device 30. The identification information of the SBOM information of the device 30 is registered by the SBOM acquisition unit 131 (described later). The software installed in the device 30 and its version can be determined by referring to the SBOM information. The SBOM group is group information assigned by grouping devices with the same configuration using SBOM. The identification information of the detection model is information indicating a detection model for each device 30, generated by the detection model generation unit 134 (described later).

[0038] The SBOM information 122 is the SBOM information of each device 30 to be monitored.

[0039] The communication packet group 123 includes communication packets of each device 30 transmitted by mirroring from the communication device 20 .

[0040] The detection model group 124 stores detection models generated for each device 30 to be monitored. Each detection model in the detection model group 124 detects anomalous communication in the corresponding device 30. Each detection model in the detection model group 124 is generated, for example, by unsupervised learning using communication information (communication packets) of the corresponding device 30 as learning data. For example, the detection model 124A corresponds to the device 30A, the detection model 124B corresponds to the device 30B, and the detection model 124C corresponds to the device 30C. Note that each detection model may be generated by a detection model generation unit 134 (described below) or by another device.

[0041] The DB 125 stores first combination data 12511 and second combination data 1252, which associate an overdetection alert determined to have a high probability of being an overdetection alert with information about the software configuration of the device in which the overdetection alert was detected. The first combination data 1251 is data that associates an overdetection alert with a common part of the software of the device 30 in which the overdetection alert was detected. The second combination data 1252 is data that associates an overdetection alert with a unique part of the software of the device 30 in which the overdetection alert was detected.

[0042] Fig. 6 is a diagram showing an example of the data configuration of the first combination data 1251 shown in Fig. 4. As shown in Fig. 6, the first combination data 1251 associates alert data of an overdetection alert, an SBOM group, software, and a common part of the software. For devices 30 that share a common part of software described in the first combination data 1251, if a detected alert is similar to the overdetection alert described in the first combination data 1251, it can be determined that there is a high possibility that this alert is an overdetection.

[0043] Fig. 7 is a diagram showing an example of the data configuration of the second combination data 1252 shown in Fig. 4. As shown in Fig. 7, the second combination data 1252 associates alert data of an overdetection alert, an SBOM group, software, and a characteristic part of the software. For a device 30 equipped with software having a characteristic part described in the second combination data 1252, if a detected alert is similar to the overdetection alert described in the second combination data 1252, it can be determined that there is a high possibility that this alert is an overdetection.

[0044] The control unit 13 is responsible for overall control of the detection server 10. The control unit 13 has an internal memory for storing programs that define various processing procedures and required data, and executes various processes using these. Here, the control unit 13 may be, for example, an electronic circuit such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), or an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).

[0045] The control unit 13 includes an SBOM acquisition unit 131 , a grouping unit 132 , a communication packet collection unit 133 , a detection model generation unit 134 , a detection unit 135 , an identification unit 136 , a notification unit 137 (output unit), and a prediction unit 138 .

[0046] The SBOM acquisition unit 131 acquires SBOM information of each device 30 by communicating with each device 30 that is a monitoring target of the detection server 10. The SBOM acquisition unit 131 stores the acquired SBOM information in the storage unit 12, and registers identification information of the SBOM information of each device 30 in the device information 121 in association with the device 30.

[0047] The grouping unit 132 groups multiple devices 30 into groups of devices with the same software configuration based on the SBOM information of each device 30. The grouping unit 132 references the SBOM information, groups devices 30A, 30B, 30C, and 30D with the same software and version into group G1, and registers this in the device information 121 ( FIG. 5 ). The grouping unit 132 references the SBOM information, groups devices 30E, 30F, and 30G with the same software and version into group G2, and registers this in the device information 121 ( FIG. 5 ).

[0048] The communication packet collection unit 133 collects communication packets from each device 30. The communication packet collection unit 133 collects communication packets from each device 30 by mirroring using the communication device 20.

[0049] The detection model generation unit 134 learns the communication packets collected by the communication packet collection unit 133 for each device 30, and generates a detection model that detects anomalous communication in each device 30. The detection model generation unit 134 uses machine learning (e.g., unsupervised learning) to perform detection model learning for each device 30. The detection model generation unit 134 stores the generated detection model in the storage unit 12. For example, the detection model generation unit 134 learns the communication packets of device 30A and generates the detection model 124A. For example, the detection model generation unit 134 learns the communication packets of device 30B and generates the detection model 124B.

[0050] The detection unit 135 detects whether or not there is anomalous communication in the monitored device 30, using the detection model for each device 30. When the detection unit 135 detects an anomaly, it outputs identification information of the device 30 in which the communication anomaly was detected and an alert indicating that anomalous communication has occurred.

[0051] The detection unit 135 performs a first detection process and a second detection process. The first detection process is a process of detecting the presence or absence of anomalous communication in the detection target device 30 using a detection model corresponding to the detection target device 30. The second detection process is a process of detecting the presence or absence of anomalous communication in the detection target device 30 using the detection models of other devices in the group to which the detection target device 30 belongs, i.e., the detection models of other devices 30 in the same group as the detection target device 30. Each group is formed by the grouping unit 132 based on SBOM information.

[0052] The identification unit 136 identifies overdetection alerts that are highly likely to be overdetections from among the alerts, based on the alert occurrence status among the multiple devices 30 and the SBOM information of each device 30. The identification unit 136 causes the notification unit 137 to notify the operator of the identified overdetection alerts from among the alerts. The identification unit 136 automatically suppresses, as overdetections, alerts that are identified as being highly likely to be overdetections from among the alerts. The identification unit 136 performs a first identification process and a second identification process.

[0053] The identification unit 136 associates an overdetection alert that has been identified as having a high probability of being an overdetection alert with information about the software configuration of the device 30 in which the overdetection alert was detected, and stores the information in the DB 125 .

[0054] The notification unit 137 outputs the processing results of the detection unit 135 and / or the identification unit 136. The notification unit 137 notifies the operator of, for example, an alert and an overdetection alert.

[0055] When a new device is added as a device 30 to be detected, the prediction unit 138 searches the DB 125 based on the SBOM information of the new device, and predicts an alert that may be an overdetection in the new device based on the search results.

[0056] [Processing Details] The processing of the identification unit 136 and the prediction unit 138 will be specifically described. The identification unit 136 performs a first identification process and a second identification process. The first identification process is a process of identifying, from among the alerts, alerts that are likely to be overdetections, using the detection results of the first detection process. The second identification process is a process of identifying, from among the alerts, overdetection alerts that are likely to be overdetections, using the detection results of the second detection process.

[0057] First, the first identification process will be described with reference to Figures 8 and 9. Figures 8 and 9 are diagrams showing the relationship between the devices 30 and the anomaly scores of each alert. Here, the devices 30A to 30G are grouped by the grouping unit 132 based on the SBOM information. The devices 30A to 30D belong to group G1, and the devices 30E to 30F belong to group G2. The software configuration within the same group is the same, but the software configuration differs partially between different groups. Examples of cases where the software configuration differs partially include cases where the version is different due to a software update, etc.

[0058] As shown in FIG. 8 , similar alerts R11 and R12 are generated in multiple devices 30A-30F across groups G1 and G2 of devices 30. In this case, there is a high possibility that the alerts are overdetections due to a common part of the software configuration of the devices 30 (e.g., the same operating system (OS) is used in groups G1 and G2). Therefore, the identification unit 136 identifies alerts R11 and R12 as being overdetections and notifies the operator. Alternatively, the detection server 10 automatically suppresses alerts R11 and R12 as overdetections. For example, the identification unit 136 calculates the similarity between the alerts based on an anomaly score used in anomalous communication detection.

[0059] In this way, when similar alerts occur among multiple groups grouped by the grouping unit 132, the identification unit 136 identifies that the similar alerts that have occurred are likely to be overdetections caused by common parts of the software configurations of the devices 30 belonging to the multiple groups.

[0060] The identification unit 136 then extracts combinations of the common parts of the software configurations and the corresponding overdetection alerts, and stores them as first combination data 1251 ( FIG. 6 ). For example, as shown in FIG. 6 , for alert R11, the identification unit 136 associates G1 and G2, which are the identification information of the SBOM groups, W1-1 and W1-2, which are the software names of the groups G1 and G2, and a common part Q1 between the software W1-1 and W1-2, and registers the associated alert R11 in the first combination data 1251.

[0061] When a new device 30 is added that is equipped with software having a common part described in the first combination data 1251, the prediction unit 138 predicts and prevents overdetection in advance for this device 30. In this way, when a new device 30 is added that is equipped with software having a common part that corresponds to an overdetection alert, the detection server 10 can predict and prevent overdetection in this new device 30 in advance by referring to the first combination data 1251.

[0062] The identification unit 136 identifies the network in which each device 30 is located, and if similar alerts are occurring not only for devices 30 in the same network but also for devices 30 in other networks, the identification unit 136 determines that there is a high possibility of an overdetection and issues a notification. One such case may be when there are many malware-infected devices in a particular network.

[0063] A case will be described in which a unique similar alert occurs in either group G1 or G2, as shown in Fig. 9. For example, a case will be described in which a unique alert R21 occurs in devices 30A to 30D of group G1, and a case will be described in which a unique alert R22 occurs in devices 30E to 30G of group G2, as shown in Fig. 9.

[0064] In this case, alert R21 is likely to be an overdetection caused by the unique software configuration of the devices 30A-30D in group G1. Alert R22 is likely to be an overdetection caused by the unique software configuration of the devices 30E-30G in group G2. Therefore, the identification unit 136 identifies alerts R21 and R22 as likely overdetections and notifies the operator. Alternatively, the detection server 10 automatically determines this to be an overdetection and performs control to suppress alert R11 for the devices 30A-30D in group G1 and control to suppress alert R12 for the devices 30E-G in group G2. Note that software configurations differ between groups G1 and G2 when, for example, middleware is different between groups G1 and G2, or when some software versions differ before and after an update to device software.

[0065] In this way, when a unique similar alert occurs in any of the groups grouped by the grouping unit 132, the identification unit 136 identifies that the unique similar alert that has occurred is likely to be an overdetection caused by the unique software configuration of the device 30 that belongs to the group in which this unique similar alert has occurred.

[0066] Next, the identification unit 136 extracts combinations of the unique parts of the software configuration and the corresponding overdetection alerts, and stores them as second combination data 1252 ( FIG. 7 ). For example, as shown in FIG. 7 , for alert R21, the identification unit 136 associates G1, which is the identification information of the SBOM group, W1-1, which is the name of each piece of software in group G1, and the unique part V1 of the software W1-1, and registers this in the second combination data 1252. Also, as shown in FIG. 7 , for alert R22, the identification unit 136 associates G2, which is the identification information of the SBOM group, W1-2, which is the name of each piece of software in group G2, and the unique part V2 of the software W1-2, and registers this in the second combination data 1252.

[0067] When a new device 30 is added that is equipped with software having a characteristic part described in the second combination data 1252, the prediction unit 138 predicts and prevents overdetection in advance for this device 30. In this way, when a new device 30 is added that is equipped with software having a characteristic part that corresponds to an overdetection alert, the detection server 10 can predict and prevent overdetection in this new device 30 in advance by referring to the second combination data 1252.

[0068] In addition to the anomaly score, the identification unit 136 may use the port number, source and / or destination IP address, packet size, protocol, etc. of the device 30 that issued the alert to calculate the similarity between alerts.

[0069] Next, the second identification process will be described with reference to Fig. 10 to Fig. 13. Fig. 10 is a diagram illustrating the processing of the detection unit 135 and the identification unit 136 shown in Fig. 4. Fig. 11 is a diagram illustrating the relationship between the device 30 and the anomaly score of each alert. Fig. 12 is a diagram illustrating the protocol ratio for each alert.

[0070] 10, for example, in the case of group G1, detection is performed using the detection model 124A of device 30A for device 30A, the detection model 124B of device 30B for device 30B, and the detection model 124C of device 30A for device 30C ((1-1) in FIG. 10). In the first identification process, alerts generated by each detection model are tallied for each of groups G1 and G2 ((2) in FIG. 10). If similar alerts occur across groups G1 and G2, or if a similar alert specific to a group occurs ((3) in FIG. 10), these similar alerts are identified as false positives ((4) in FIG. 10).

[0071] 10, the second detection process detects whether or not there is an anomaly in the communication information of the target device 30 by using the detection models of the other devices 30 in the group to which each device 30 belongs. For example, in the case of group G1, detection is performed using the detection model 124B corresponding to device 30B in group G1 for device 30A, the detection model 124C corresponding to device 30C in group G1 for device 30B, and the detection model 124B corresponding to device 30B in group G1 for device 30C ((1-2) in FIG. 10).

[0072] Then, as a second identification process, the identification unit 136 tallyes up, for each device 30, alerts that detected abnormal communication using a detection model other than its own device based on the results of the second detection process ((5) in Figure 10).

[0073] For example, if the tabulation results show that alert R31 has occurred only in a specific device 30A in group G1 ((6) in FIG. 10), as shown in FIG. 11, it is likely that there is some kind of problem with device 30A. For example, it is highly likely that device 30A is experiencing anomalous communication due to software that is different from that used by the other devices 30B to 30D. Specifically, it is possible that device 30A has been infected with a malicious program or the like at an early stage, such as at the time of learning, and that this malicious program was present in device 30A. This malicious program cannot be detected by detection model 124A trained on device 30A's communications, but can be detected by detection models of the same group G1 trained on communications other than device 30A (e.g., detection model 124B and detection model 124C).

[0074] For this reason, when an alert has occurred only in device 30A, the identification unit 136 determines that the alert occurred only in device 30A is due to anomalous communication ((7) in FIG. 10 ), and notifies the operator. When making the notification, the identification unit 136 may provide the operator with a relationship diagram between the devices 30 and the anomaly scores, as shown in FIG. 11 , and may also provide the operator with information that visualizes the protocol ratio for each alert of each device 30, as shown in FIG. 12 , so that the operator can clearly recognize the difference between device 30A and the other devices 30B to 30D.

[0075] The detection model used in the second detection process may be a model that has learned communication information from one device other than the own device in the same group, or communication information from multiple devices other than the own device in the same group.

[0076] In this way, in the second identification process, if an alert occurs only in one of the devices in the same group grouped by the grouping unit 132, the identification unit 136 determines that the alert is due to anomalous communication in the device in which the alert was detected. By performing the second identification process, the detection server 10 can detect anomalous communication even in devices that are infected with malicious programs or the like at an early stage, such as at the time of learning, by using a detection model of another device with the same configuration. Note that the detection server 10 may perform both the first detection process and first identification process and the second detection process and second identification process, or may perform only one of them.

[0077] [Detection Model Generation Process] Next, a description will be given of the processing procedures of each process performed by the detection server 10. First, a description will be given of the processing up to generation of a detection model. Fig. 13 is a flowchart showing the processing procedures of the detection model generation process according to the embodiment.

[0078] The detection server 10 communicates with each device 30 to be monitored, and acquires device information such as the device ID, port number, and IP address of each device 30, as well as SBOM information of each device 30 (steps S11 and S12).

[0079] The detection server 10 groups the devices 30 into groups of devices with the same software configuration based on the SBOM information of each device 30 (step S13).

[0080] The detection server 10 collects communication packets from each device 30 (step S14), learns the communication packets for each device 30, and generates a detection model (step S15).

[0081] [Detection Process] Next, a process for detecting a communication anomaly will be described. Here, a process for detecting an anomalous communication of each device 30 and identifying an overdetection alert from the detected alerts will be described. Fig. 14 is a flowchart showing the processing procedure of the detection process according to the embodiment.

[0082] 14 , the detection server 10 collects communication packets from each device 30 (step S21). The detection server 10 performs a first detection process to detect whether or not there is an anomaly in the communication information of the detection target device 30 using a detection model corresponding to the detection target device 30 (step S22). The detection server 10 performs a second detection process to detect whether or not there is an anomaly in the communication information of the detection target device 30 using a detection model for other devices 30 in the same group as the detection target device 30 (step S23).

[0083] The detection server 10 performs a first identification process to identify overdetection alerts that are likely to be overdetections using the results of the first detection process (step S24), and a second identification process to identify anomalous communication from the device 30 using the results of the second detection process (step S25).

[0084] The detection server 10 notifies the operator of alerts that are likely to be overdetections based on the detection results of steps S22 and S23 and the identification results of steps S24 and S25 (step S26). Alternatively, the detection server 10 automatically suppresses alerts that are likely to be overdetections, out of the alerts, that are identified as being likely to be overdetections.

[0085] The detection server 10 associates the overdetection alert that has been identified as having a high probability of being an overdetection alert with information about the software configuration of the device 30 in which the overdetection alert was detected, and stores the information in the DB 125 (step S27).

[0086] [First Classification Processing] FIG. 15 is a flowchart showing the processing procedure of the first classification processing shown in FIG.

[0087] The detection server 10 acquires the first detection process result (step S31). Based on the first detection process result, the detection server 10 determines whether similar alerts have occurred among multiple groups among the groups grouped in step S13 (step S32).

[0088] If similar alerts occur across multiple groups (step S32: Yes), the detection server 10 identifies that the alerts are likely to be false positives caused by common parts of the software configurations of the devices 30 belonging to the multiple groups (step S33).

[0089] If no similar alerts have occurred among multiple groups (step S32: No), or after step S33 is completed, the detection server 10 determines, based on the results of the first detection process, whether a unique similar alert has occurred in any of the groups grouped in step S13 (step S34).

[0090] If no unique similar alert has occurred in any group (step S34: No), the detection server 10 ends the first identification process. If a unique similar alert has occurred in any group (step S34: Yes), the detection server 10 identifies that the alert is likely an overdetection caused by the unique software configuration of the device 30 belonging to the group in which the unique similar alert occurred (step S35). Note that the identification unit 136 may perform both steps S32 and S33 and steps S34 and S35 as the first identification process, or may perform either one of steps S32 and S33 or steps S34 and S35.

[0091] [Second Classification Processing] FIG. 16 is a flowchart showing the processing procedure of the second classification processing shown in FIG.

[0092] The detection server 10 acquires the results of the second detection process (step S41). The detection server 10 aggregates the alerts for each device (step S42). The detection server 10 then determines whether an alert has occurred in only one specific device in the same group (step S43).

[0093] If an alert has not occurred in only one specific device in the same group (step S43: No), the detection server 10 ends the second identification process. If an alert has occurred in only one specific device in the same group (step S43: Yes), the detection server 10 determines that the alert is due to abnormal communication in the device 30 in which the alert was detected (step S44), and notifies the operator.

[0094] [Prediction Process] Next, a process for predicting a communication abnormality will be described. Fig. 17 is a flowchart showing the procedure of the prediction process according to the embodiment.

[0095] The detection server 10 determines whether a new device has been added as a detection target device (step S51). If a new device has not been added (step S51: No), the detection server 10 ends the prediction process.

[0096] If a new device 30 is added (step S51: Yes), the detection server 10 acquires device information of the added device 30 and SBOM information of this device 30 (steps S52 and S53).

[0097] The detection server 10 searches the first combination data 2151 and the second combination data 2152 in the DB 215 based on the SBOM information of the new device 30 (step S54), and if the search returns a hit, predicts that the hit overdetection alert may be generated in this new device 30 (step S55). For example, the detection server 10 performs control to automatically suppress the hit overdetection alert for this new device 30.

[0098] Effects of the embodiment In this way, the detection server 10 according to the embodiment identifies, from among the alerts, those alerts that are likely to be overdetections, based on the alert occurrence status among the multiple devices 30 and the SBOM information of each device 30.

[0099] Therefore, even when a large number of alerts are generated from multiple devices 30 with similar configurations, the detection server 10 can accurately identify whether the alerts are false positives or not by using the software configuration information of each device 30. This allows the detection server 10 to identify true alerts from a large number of false positives. Furthermore, by automatically preventing identified false positives, the detection server 10 allows the network operator to focus on responding to alerts that truly require attention, thereby enabling efficient network operation.

[0100] Furthermore, the detection server 10 extracts combinations of information based on the SBOM information and overdetection alerts, and stores them in DB 15. By searching the data stored in DB 15 based on the SBOM information of a newly added device 30, the detection server 10 can predict overdetection that is likely to occur in this device 30 in advance, and can prevent overdetection in advance for the newly added device 30. Therefore, according to the embodiment, only anomalous communications that truly require a response are notified to the operator as an alert, allowing the operator to focus on responding to necessary alerts.

[0101] The detection server 10 also applies the detection model to other devices in the same group that have the same software configuration to detect anomalous communication. The detection server 10 then detects anomalous communication that does not occur in other devices as an alert, thereby enabling it to detect anomalous communication in devices 30 that have already been infected with malicious programs or the like.

[0102] [System Configuration of the Embodiment] The detection server 10 is a functional concept and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of the functions of the detection server 10 is not limited to that shown in the figure, and all or part of the detection server 10 can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc.

[0103] Furthermore, all or any part of the processes performed by the detection server 10 may be realized by a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), and a program analyzed and executed by the CPU and GPU. Furthermore, each process performed by the detection server 10 may be realized as hardware using wired logic.

[0104] Furthermore, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually. Alternatively, all or part of the processes described as being performed manually can be performed automatically using a known method. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters described above and illustrated can be changed as appropriate unless otherwise specified.

[0105] 18 is a diagram showing an example of a computer in which the detection server 10 is realized by executing a program. The computer 1000 has, for example, a memory 1010 and a CPU 1020. The computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0106] The memory 1010 includes a ROM 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

[0107] The hard disk drive 1090 stores, for example, an operating system (OS) 1091, an application program 1092, a program module 1093, and program data 1094. That is, the programs that define each process of the detection server 10 are implemented as program modules 1093 in which code executable by the computer 1000 is written. The program modules 1093 are stored, for example, in the hard disk drive 1090. For example, the program modules 1093 for executing processes similar to those of the functional configuration of the detection server 10 are stored in the hard disk drive 1090. Note that the hard disk drive 1090 may be replaced with an SSD (Solid State Drive).

[0108] Furthermore, setting data used in the processing of the above-described embodiment is stored as program data 1094, for example, in memory 1010 or hard disk drive 1090. Then, CPU 1020 reads out program module 1093 or program data 1094 stored in memory 1010 or hard disk drive 1090 into RAM 1012 as necessary and executes them.

[0109] The program module 1093 and program data 1094 may not necessarily be stored in the hard disk drive 1090, but may also be stored in a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a local area network (LAN) or a wide area network (WAN)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.

[0110] Although the present invention has been described above as an embodiment, the present invention is not limited to the descriptions and drawings that form part of the disclosure of the present invention. In other words, other embodiments, examples, and operational techniques that can be made by those skilled in the art based on the present invention are all included in the scope of the present invention.

[0111] REFERENCE SIGNS LIST 1 Communication system 10 Detection server 11 Communication unit 12 Storage unit 13 Control unit 20 Communication device 30, 30A, 30B, 30C, 30D, 30E, 30F, 30G Device 40 Network 121 Device information 122 SBOM information 123 Communication packet group 124 Detection model group 124A, 124B, 124C Detection model 125, 215 DB 131 SBOM acquisition unit 132 Grouping unit 133 Communication packet collection unit 134 Detection model generation unit 135 Detection unit 136 Identification unit 137 Notification unit 138 Prediction unit

Claims

1. A detection device that detects the presence or absence of anomalous communication in multiple devices, comprising: a detection unit that uses a detection model that detects anomalous communication in each device to detect the presence or absence of anomalous communication in the device being detected, and issues an alert if anomalous communication is detected; an acquisition unit that acquires software configuration information for each device; an identification unit that identifies, from among the alerts, alerts that are likely to be overdetections in which normal communication has been mistakenly determined to be anomalous, based on the alert occurrence status between the multiple devices and the software configuration information of each device; and an output unit that outputs the processing results of the detection unit and / or the identification unit.

2. The detection device according to claim 1, further comprising a grouping unit that groups the plurality of devices into groups of devices with the same software configuration based on software configuration information of each device, wherein the detection unit detects whether or not anomalous communication is occurring in the devices to be detected using the detection model corresponding to each device, and wherein the identification unit, when a similar alert occurs among multiple groups grouped by the grouping unit, identifies that the generated similar alert is likely to be an overdetection caused by a common part of the software configuration of the devices belonging to the multiple groups, and / or, when a unique similar alert occurs in any of the groups grouped by the grouping unit, identifies that the generated unique similar alert is likely to be an overdetection caused by a unique software configuration of the device belonging to the group in which the unique similar alert occurred.

3. The detection device according to claim 1, further comprising a grouping unit that groups the plurality of devices into groups of devices with the same software configuration based on the software configuration information of each device, wherein the detection unit uses the detection model of other devices in the group to which each device belongs to detect whether or not there is an abnormality in the anomalous communication of the device to be detected, and wherein the identification unit, when an alert occurs only in one of the devices in the same group grouped by the grouping unit, determines that the alert is due to anomalous communication of the device in which the alert was detected.

4. The detection device described in claim 1, characterized in that the identification unit associates alerts identified as having a high probability of being overdetection with information regarding the software configuration of the device in which the alert was detected and stores the associated information in a database, and the detection device has a prediction unit that, when a new device is added as a device to be detected, searches the database based on the software configuration information of the new device and predicts alerts in the new device that may be overdetection based on the search results.

Images