JP7790165B2 - Traffic analysis device, traffic analysis program, and traffic analysis method - Google Patents

Description

This invention relates to a traffic analysis device, a traffic analysis program, and a traffic analysis method, and can be applied, for example, to a system that determines the status of IoT devices connected to the Internet based on traffic data when these devices communicate.

Traditionally, IoT devices have been used in a variety of environments, including homes, offices, and factories. However, compared to traditional communication devices such as PCs, IoT devices often lack sufficient security measures, or no security measures are implemented at all. For example, IoT devices have limited computing resources, making it impossible to deploy agent-based security products. Furthermore, IoT devices that are used without human intervention may not have their software updated for long periods of time, leaving them vulnerable to vulnerabilities.

One security measure for such IoT devices is NDR (Network Detection and Response), which installs equipment that collects and analyzes traffic on the connection path from the IoT device to the Internet, detects abnormal communications from the traffic, and blocks communications from the target device. Because NDR does not require the installation of a security agent on the device, it is useful for monitoring devices such as IoT devices that have limited computing resources and cannot implement agent-based security measures. Furthermore, while backbone network firewalls and proxy servers may not be able to detect internal criminal activity, such as connecting unauthorized devices to edge networks and stealing confidential information from other legitimate devices, NDR can detect such unauthorized activity by installing analysis equipment at the connection point of the edge network.

One conventional method for detecting anomalies with NDR is to use unsupervised machine learning, which learns the normal communication patterns of devices within the monitored network and then detects an anomaly when there is communication that deviates from the normal communication pattern. Unsupervised machine learning detects any communication pattern that differs from normal as an anomaly, making it possible to detect even unknown attacks. However, even legitimate communication can be falsely detected as an anomaly if it is used in an unusual way, resulting in a high number of false positives. Furthermore, when new devices are added to a network during operation, the system needs to learn the new device's steady-state communication patterns, which means it takes time to detect anomalies after the new device is connected.

Patent Document 1 describes a system that monitors FAN (Field Area Network) devices connected to a gateway device, learns normal values for control messages, sensor data, statistical data, etc. for each device, and detects anomalies when they deviate from the normal values. In order to reduce false positives, the system described in Patent Document 1 further analyzes the communication data for any detected anomalies by an inspection server, confirming whether there are any problems, and then ultimately determines whether there is an anomaly.

Patent Document 2 describes a system that monitors IoT devices connected to terminals such as smartphones, learns normal communication patterns for each application of the IoT device through statistical processing or machine learning, and detects an anomaly when the communication pattern of that application deviates from the normal communication pattern. The system described in Patent Document 2 supports processes to suppress false detections, such as exchanging control information between multiple smartphones to update normal communication patterns and excluding applications for which it is determined that a steady-state communication pattern cannot be learned from the detection targets.

JP 2017-163179 A Japanese Patent Application Laid-Open No. 2020-135655

However, the system described in Patent Document 1 needs to learn the normal communication patterns of a new device when it is connected (when a new communication device is connected), and it takes time before it can detect anomalies. Furthermore, the system described in Patent Document 1 uses sensor data values, etc., to detect anomalies, which may not be applicable to encrypted communications. Furthermore, the system described in Patent Document 2 needs to learn the normal communication patterns of the applications used by a new device when it is connected, and it takes time before it can detect anomalies. Furthermore, the system described in Patent Document 2 can only detect anomalies in communications of registered apps, and therefore cannot detect anomalous communications unrelated to apps, such as those that occur when a device is infected with malware.

In light of the above issues, there is a need for a traffic analysis device, traffic analysis program, and traffic analysis method that can reduce false positives and the processing required to introduce new communication devices when detecting anomalies in communication devices using a model based on machine learning of communication patterns.

A traffic analysis device according to a first aspect of the present invention comprises: a non-steady communication judgment model holding means for holding a non-steady communication judgment model for determining whether or not a communication device is in a non-steady communication state from traffic data of the communication device using a learning model that has been machine-learned on a pattern of traffic data in a steady communication state for each attribute of the communication device connected to a target network; an attribute recognition means for recognizing the attributes of each of the communication devices; and a non-steady communication judgment means for performing a non-steady communication judgment process for determining whether or not the communication device is in a non-steady communication state from traffic data of the communication device using the non-steady communication judgment model, wherein the non-steady communication judgment model holding means holds traffic data for learning from each of the communication devices, divides the held traffic data for learning by flow, classifies each of the flows by the attribute, and performs machine learning to determine the non-steady communication state for each of the attributes. the non-steady communication judgment model holding means holds a device-type-specific non-steady communication judgment model that uses a learning model that has been machine-learned to learn a pattern of traffic data in a steady communication state for each device type of the communication device to determine whether the communication device is in a non-steady communication state from the traffic data of the communication device; the non-steady communication judgment means performs the non-steady communication judgment process using at least the device-type-specific non-steady communication judgment model; the non-steady communication judgment model holding means holds a manufacturer-specific non-steady communication judgment model that uses a learning model that has been machine-learned to learn a pattern of traffic data in a steady communication state for each manufacturer of the communication device to determine whether the communication device is in a non-steady communication state from the traffic data of the communication device; and the non-steady communication judgment means further performs the non-steady communication judgment process using the manufacturer-specific non-steady communication judgment model .

A traffic analysis program according to a second aspect of the present invention causes a computer to function as: non-steady communication judgment model holding means for holding a non-steady communication judgment model for determining whether or not a communication device is in a non-steady communication state from traffic data of the communication device using a learning model that has been machine-learned to learn traffic data patterns in a steady communication state for each attribute of the communication device connected to a target network; attribute recognition means for recognizing the attributes of each of the communication devices; and non-steady communication judgment means for performing non-steady communication judgment processing for determining whether or not a communication device is in a non-steady communication state from traffic data of the communication device using the non-steady communication judgment model , wherein the non-steady communication judgment model holding means holds learning traffic data from each of the communication devices, divides the held learning traffic data for learning by flow, classifies each of the flows by the attribute, and performs machine learning to determine whether or not the flow is in a non-steady communication state for each of the attribute. the non-steady communication determination model holding means holds a device-type-specific non-steady communication determination model that uses a learning model that has been machine-learned to learn a pattern of traffic data in a steady communication state for each device type of the communication device to determine whether the communication device is in a non-steady communication state from the traffic data of the communication device; the non-steady communication determination means performs the non-steady communication determination process using at least the device-type-specific non-steady communication determination model; the non-steady communication determination model holding means holds a manufacturer-specific non-steady communication determination model that uses a learning model that has been machine-learned to learn a pattern of traffic data in a steady communication state for each manufacturer of the communication device to determine whether the communication device is in a non-steady communication state from the traffic data of the communication device; and the non-steady communication determination means further performs the non-steady communication determination process using the manufacturer-specific non-steady communication determination model .

A third aspect of the present invention is a traffic analysis method performed by a traffic analysis device, wherein the traffic analysis device comprises non-stationary communication judgment model holding means, attribute recognition means, and non-stationary communication judgment means, wherein the non-stationary communication judgment model holding means holds a non-stationary communication judgment model for determining whether or not a communication device is in a non-stationary communication state from traffic data of the communication device using a learning model that has machine-learned a pattern of traffic data in a stationary communication state for each attribute of the communication device connected to a target network, the attribute recognition means recognizes the attribute of each of the communication devices, the non-stationary communication judgment means performs non-stationary communication judgment processing for determining whether or not the communication device is in a non-stationary communication state from traffic data of the communication device using the non-stationary communication judgment model , and the non-stationary communication judgment model holding means holds learning traffic data from each of the communication devices, divides the held learning traffic data by flow, and performs a non-stationary communication judgment process for determining whether or not each of the flows is in a non-stationary communication state from traffic data of the communication device, and The non-steady communication judgment model holding means holds a device-type-specific non-steady communication judgment model that uses a learning model that has been machine-learned to learn a pattern of traffic data in a steady communication state for each device type of the communication device to determine whether the communication device is in a non-steady communication state from the traffic data of the communication device, the non-steady communication judgment means performs the non-steady communication judgment process using at least the device-type-specific non-steady communication judgment model, the non-steady communication judgment model holding means holds a manufacturer-specific non-steady communication judgment model that uses a learning model that has been machine-learned to learn a pattern of traffic data in a steady communication state for each manufacturer of the communication device to determine whether the communication device is in a non-steady communication state from the traffic data of the communication device, and the non-steady communication judgment means further performs the non-steady communication judgment process using the manufacturer-specific non-steady communication judgment model .

According to the present invention, when detecting anomalies in communication devices using a model based on machine learning of communication patterns, it is possible to reduce false positives while also reducing the processing required to introduce new communication devices when they are detected.

FIG. 2 is a block diagram showing the functional configuration of the traffic analysis device according to the first embodiment. FIG. 1 is a block diagram showing a connection configuration of devices related to the first to fifth embodiments. 10 is a flowchart showing a process of constructing an unsteady communication detection model by device type according to the first embodiment. 10A and 10B are diagrams (image diagrams) illustrating a process of extracting a flow to be learned when constructing an unsteady communication detection model by device type according to the first embodiment; 10 is a flowchart showing a process of constructing a vendor-specific unsteady communication detection model according to the first embodiment. 10 is a diagram (image diagram) showing a process of extracting a flow to be learned when building a vendor-specific unsteady communication detection model according to the first embodiment; FIG. 10 is a flowchart illustrating a process of constructing a device-specific unsteady communication detection model according to the first embodiment. 10 is a flowchart showing an operation of an unsteady communication state determination unit according to the first embodiment. 4 is a flowchart showing a process when the traffic analysis device according to the first embodiment operates in a learning mode. 4 is a flowchart showing a process when the traffic analysis device according to the first embodiment operates in an operation mode. 10 is a flowchart showing a process when the traffic analysis device according to the first embodiment operates in a mixed mode. FIG. 10 is a block diagram showing the functional configuration of a traffic analysis device according to a second embodiment. FIG. 11 is a diagram (part 1) showing the configuration of a feedback input acceptance screen according to the second embodiment; FIG. 10 is a diagram (part 2) showing the configuration of a feedback input acceptance screen according to the second embodiment; FIG. 10 is a block diagram showing the functional configuration of a traffic analysis device according to a third embodiment. FIG. 10 is a block diagram showing the functional configuration of a traffic analysis device according to a fourth embodiment. FIG. 13 is a block diagram showing the functional configuration of a traffic analysis device according to a fifth embodiment. 13 is a flowchart illustrating a process of extracting a flow to be learned when constructing an unsteady communication detection model according to the fifth embodiment.

(A) First Embodiment A first embodiment of a traffic analysis device, a traffic analysis program, and a traffic analysis method according to the present invention will be described in detail below with reference to the drawings.

(A-1) Configuration of the First Embodiment Fig. 2 is a diagram showing the connection relationships of the devices related to the first embodiment. The reference numerals in parentheses in Fig. 2 are the reference numerals used in the second to fifth embodiments described later.

Here, the traffic analysis device 10 performs processing to analyze traffic generated by IoT devices 30 (30-1, 30-2, ...) that serve as communication devices (communication terminals) connected to the monitored network N1, which is the target of monitoring (target of analysis). In the configuration example of Figure 2, the monitored network N1 is assumed to include a network switch 20 (Layer 2 switch) and a gateway 40 (e.g., a gateway that supports firewall functions) as network devices. Note that the communication devices connected to the monitored network N1 are not limited to IoT devices and may be various other devices.

In the configuration example of Figure 2, each IoT device 30 is connected to a network switch 20 (Layer 2 switch), and a gateway 40 with firewall functionality is connected between the network switch 20 and the Internet N2. Therefore, in the example of Figure 2, each IoT device 30 is able to communicate with the Internet N2 via the network switch 20 and gateway 40. Furthermore, the network switch 20 does not limit the number of IoT devices 30, etc. connected, and this description will be given assuming that this number may increase or decrease during operation.

The specific functions, configurations, and communication contents of each IoT device 30 are not limited. Here, each IoT device 30 will be described as basically performing its functions by communicating with a communication device on the Internet N2 (for example, a server that receives data from the IoT device 30, or a terminal that accesses the IoT device 30).

In the example of FIG. 2, the traffic analysis device 10 is connected to a network switch 20. Here, the network switch 20 is configured so that packets (Ethernet frames) transmitted and received at the LAN port (Ethernet port) connected to the gateway 40 are mirrored to the port to which the traffic analysis device 10 is connected (so-called port mirror connection). This allows the traffic analysis device 10 to collect traffic (packets) flowing between a connected terminal (IoT device 30) under the network switch 20 and the Internet N2. In this embodiment, the port mirror setting of the network switch 20 is used to supply the traffic analysis device 10 with data (hereinafter simply referred to as "traffic data") based on the traffic flowing between the IoT device 30 and the Internet N2. However, the specific configuration for supplying traffic data to the traffic analysis device 10 is not limited.

The traffic analysis device 10 is a device that performs analysis of each connected terminal (including IoT devices 30) based on traffic data.

Here, we will provide an overview of the traffic analysis device 10.

In general, IoT devices primarily provide one function (hereinafter referred to as the "main function"). For example, an IoT device with a network camera function corresponds to the function of taking pictures of a target area and streaming the images to a remote PC terminal, etc. In addition, for example, an IoT device such as a smart power strip corresponds to the function of remotely turning the switch on and off. In other words, it is generally thought that many IoT devices have similar main steady-state communication patterns (hereinafter referred to as the "steady-state communication patterns") for each type (hereinafter referred to as the "device type") based on their main function.

Therefore, by learning steady-state communication patterns for each device type, it is possible to construct a learning model that reflects the communication patterns when the main function provided by that device type is operating. Therefore, even for IoT devices (hereinafter referred to as "newly connected devices") that are newly connected to the monitored network N1 (here, network switch 20), the traffic analysis device 10 can detect an unsteady communication state of the newly connected device (a state in which a communication pattern different from the steady-state communication pattern occurs) by comparing the steady-state communication pattern of the newly connected device with the steady-state communication pattern of the device type of the newly connected device (e.g., the communication pattern when the main function is operating). Hereinafter, the unsteady communication state of the IoT device 30 will also be referred to simply as an "abnormal state." In other words, the traffic analysis device 10 will consider an IoT device 30 that is determined to be in an unsteady communication state to be in an abnormal state.

In addition, many IoT devices generally perform control communications specific to their vendor (manufacturer). For example, IoT devices from a certain vendor generally perform time synchronization using NTP (Network Time Protocol) at set intervals, or communicate with a cloud server owned by the vendor. In other words, it is generally believed that IoT devices from different vendors have similar steady-state control communication patterns. Therefore, by learning steady-state communication patterns for each IoT device vendor, it is possible to build a learning model that reflects vendor-specific communication patterns. Therefore, the traffic analysis device 10 can detect unsteady communication states even in newly connected devices by comparing them with the steady-state communication patterns of the vendor of the newly connected device.

In other words, the traffic analysis device 10 can determine (detect) an unsteady communication state even for a newly connected device (a communication device that has become a new target for monitoring/analysis) by comparing it with steady communication patterns for each attribute (e.g., device type, vendor, etc.). Specifically, the traffic analysis device 10 of this embodiment builds and stores a model (hereinafter referred to as an "unsteady communication detection model") that learns steady communication patterns for each attribute and detects (determines) a steady communication state/unsteady communication state. Traffic data acquired during operation is classified for each IoT device 30 (e.g., by source/destination IP address), and the unsteady communication detection model corresponding to that IoT device 30 is applied to determine the state of that IoT device 30 (e.g., determine whether or not the IoT device 30 is in an unsteady communication state (abnormal state)).

The traffic analysis device 10 of this embodiment uses the communication characteristics of each IoT device 30 to build and store a model (hereinafter also referred to as a "device-type-specific unsteady communication detection model") that learns steady communication patterns by aggregating traffic by device type (e.g., network camera, smart speaker, smart plug) as an attribute and determines (detects) whether the communication is steady or unsteady. Furthermore, when building the device-type-specific unsteady communication detection model, the traffic analysis device 10 builds and stores a model (hereinafter referred to as a "vendor-specific unsteady communication detection model") that learns steady communication patterns by aggregating traffic by vendor as an attribute and determines (detects) whether the communication is steady or unsteady.

For each IoT device 30, the traffic analysis device 10 first determines whether the device is in an unsteady communication state based on whether the device is in an unsteady communication state using a device-type unsteady communication detection model. Then, for IoT devices determined to be in an unsteady communication state based on the device-type unsteady communication detection model, the traffic analysis device 10 further determines whether the device is in an unsteady communication state based on a vendor-specific unsteady communication detection model. If the device is determined to be in an unsteady communication state, the traffic analysis device 10 detects an anomaly in the IoT device (detects that the device is in an abnormal state).

As described above, the traffic analysis device 10 performs a determination process using a device type-specific unsteady communication detection model and a vendor-specific unsteady communication detection model. This makes it possible to detect an unsteady communication state even for an IoT device 30 that has just been connected to the monitored network N1, as long as the device type and vendor of the IoT device 30 are known, thereby shortening the time required to learn a steady communication state.

Furthermore, in this embodiment, the traffic analysis device 10 constructs and stores an unsteady communication detection model (hereinafter referred to as a "device-specific unsteady communication detection model") that collectively learns traffic patterns (i.e., device-specific communication patterns) that had low accuracy even when learning the vendor-specific unsteady communication detection model as steady communication patterns. The traffic analysis device 10 then determines whether a communication pattern that could not be detected as an unsteady communication state in either the device-type-specific unsteady communication detection model or the vendor-specific unsteady communication detection model is an unsteady communication state using the device-specific unsteady communication detection model, and detects an unsteady communication state (abnormal state) if it is determined to be an unsteady communication state.

To achieve the above-described determination process, the traffic analysis device 10 (mainly the processing unit 101) in this embodiment operates in one of the following three operating modes:

When operating in the first operating mode (hereinafter also referred to as "learning mode"), the traffic analysis device 10 collects traffic data of the steady communication patterns of each IoT device 30 connected to the monitored network N1, performs a learning process, and constructs each unsteady communication state detection model (unsteady communication detection model by device type, unsteady communication detection model by vendor, and device-specific unsteady communication detection model).

When operating in the second operating mode (hereinafter also referred to as the "operational mode"), the traffic analysis device 10 acquires traffic data from the monitored network N1 in real time and performs processing to determine whether each IoT device 30 is in an unsteady communication state (abnormal state) using each unsteady communication state detection model.

When the traffic analysis device 10 detects an IoT device 30 of an unknown device type or vendor while operating in operation mode, it may operate in an operation mode (hereinafter referred to as "mixed mode") in parallel with operation in operation mode, in which the traffic analysis device 10 learns steady-state communication patterns for the device type or vendor of the unknown IoT device 30 and constructs an unsteady communication state detection model.

Next, the internal configuration of the traffic analysis device 10 will be explained using Figure 1.

Figure 1 is a block diagram showing the functional configuration of the traffic analysis device 10.

As shown in FIG. 1, the traffic analysis device 10 includes a processing unit 101, a traffic data collection unit 102, a steady-state communication pattern learning unit 103, a non-steady-state communication state determination unit 104, a device type determination unit 105, a vendor information determination unit 106, a communication control unit 107, and a memory unit 108.

The traffic analysis device 10 can be realized, for example, by installing a program (including the traffic analysis program according to the embodiment) on a computer having a processor, memory, and the like.
[Configuration of processing unit 101]
The processing unit 101 has the function of controlling the overall processing of the traffic analysis device 10. The processing unit 101 also performs a recording process for recording data notified from other elements, and a process for reading and notifying (outputting) data requested by other elements.
[Configuration of storage unit 108]
The storage unit 108 is a recording means for storing and holding data used in each process in the traffic analysis device 10 .
[Traffic Data Collection Unit 102]
The traffic data collection unit 102 captures traffic data (Ethernet frame or IP packet data) from the network switch 20, analyzes the captured content, converts it into IP packet format, and outputs it. The traffic data collection unit 102 may add additional information such as information on the Ethernet frame that is the source of the traffic data to be output (e.g., source/destination MAC addresses) and a timestamp (e.g., the time the frame/packet was captured). The traffic data collection unit 102 notifies (outputs) the traffic data in IP packet format to the processing unit 101.

When the processing unit 101 receives traffic data (IP packet data) from the traffic data collection unit 102, it requests the device type determination unit 105 to determine the device type of the IoT device 30 associated with the source or destination of the received traffic data, and obtains the determination result.

In addition, when the processing unit 101 receives traffic data from the traffic data collection unit 102, it requests the vendor information determination unit 106 to perform a determination process on the vendor information indicating the vendor of the IoT device 30 related to the source or destination of the received traffic data, and obtains the determination result.

Furthermore, when operating in learning mode, the processing unit 101 requests the steady communication pattern learning unit 103 to learn steady communication patterns and obtains the results. When operating in operation mode, the processing unit 101 requests the non-steady communication state determination unit 104 to determine an abnormality and obtains the results.

Furthermore, when the processing unit 101 is operating in mixed mode and receives traffic data for a device type/vendor that is currently being learned, it requests the steady-state communication pattern learning unit 103 to learn using that traffic data, and when it receives traffic data for a device type/vendor that is not currently being learned, it requests the non-steady-state communication state determination unit 104 to perform an abnormality determination process using that traffic data and obtains the results.

Furthermore, while operating in the operational mode or the mixed mode, the processing unit 101 may take any action depending on the determination result of the unsteady communication state determination unit 104. For example, the processing unit 101 may request the communication control unit 107 to cut off communication with the IoT device 30 for which an abnormality has been detected by the unsteady communication state determination unit 104, or may transmit or output information about the detected abnormality using one of various communication methods (e.g., email or a message in a specified method).

Furthermore, the processing unit 101 requests the memory unit 108 to store the traffic data collected by the traffic data collection unit 102, information indicating the type of each IoT device 30 (hereinafter referred to as "device type information"), information indicating the vendor (manufacturer) of each IoT device 30 (hereinafter referred to as "vendor information"), a device-type-specific unsteady communication detection model for each device type, a vendor-specific unsteady communication detection model for each vendor, and a device-specific unsteady communication detection model, and obtains the stored information from the memory unit 108 as needed.
[Configuration of device type determination unit 105]
The device type determination unit 105 has a function of determining the device type from the input traffic data.

The device type determination unit 105 may, for example, classify traffic data by device type and learn steady-state communication patterns using a machine learning device or the like, thereby retaining a model (hereinafter referred to as a "device type determination model") for determining the device type corresponding to traffic data, and may determine the device type corresponding to input traffic data based on the retained device type determination model. When operating in the learning mode, the device type determination unit 105 may pre-retain (e.g., accept and retain manual input by an operator, etc.) device type data for each IoT device 30 (e.g., data associating the device type with the IP address of each IoT device 30). Then, when operating in the learning mode, the device type determination unit 105 may classify traffic data by device type, convert the traffic data for each classified device type (data consisting of multiple IP packet sequences) into features indicative of communication patterns, and have the machine learning device learn the data, thereby constructing a device type determination model. The format of the feature indicating the communication pattern is not limited, but may be, for example, statistical values based on traffic data such as the size of each IP packet constituting the traffic data and the packet arrival interval, or service information inferred from port numbers (TCP or UDP port numbers) (for example, HTTP for TCP 80, TELNET for TCP 23, etc.). In other words, the device type determination unit 105 can acquire a device type determination model by supplying training data (device type data for each IoT device 30 and traffic data acquired when operating in learning mode) to a machine learning device and performing a learning process.

The device type determination unit 105 may store a device type determination model using the above-mentioned processing when operating in learning mode, or may store a device type determination model in advance. Here, the device type determination model may be configured to output a determination result that the device type is unknown when a communication pattern that is not similar to any of the communication patterns of learned device types is input. For example, when classifying traffic data during learning, the device type determination unit 105 may classify and learn traffic data into a class of known device types + 1 (+1 is a class representing an unknown device type), and may configure a device type determination model so that during determination, if the probability that the traffic data is in a class representing an unknown device type is equal to or greater than a certain value, the device type is determined to be an unknown device type.

When the processing unit 101 requests the device type determination unit 105 to determine the device type along with the traffic data, the device type determination unit 105 determines the device type based on the traffic data and notifies the processing unit 101 of the result (including the result that the device type is unknown).

The processing unit 101 recognizes the device type of each IoT device 30 based on the determination result of the device type determination unit 105, generates device type information for each IoT device 30, and stores the information in the storage unit 108. The specific format of the device type information is not limited, but may be, for example, information in which an identifier of the IoT device 30 (e.g., IP address, host name, arbitrary ID number, etc.) is associated with an identifier of the device type (e.g., device type name, ID number, etc.).
[Configuration of vendor information determination unit 106]
The vendor information determination unit 106 has a function of determining, from the traffic data, the vendor (manufacturer) of the IoT device 30 corresponding to the traffic data.

Each communication device that supports Ethernet is assigned a unique MAC address, and the first half of the MAC address (e.g., the first to third octets) is usually composed of a so-called vendor code (OUI: Organizationally Unique Identifier). Therefore, the vendor information determination unit 106 obtains the MAC addresses of the source and destination IoT devices 30 for each piece of traffic data (traffic data with the MAC address of the corresponding IoT device 30 added), and extracts the vendor code from the obtained MAC addresses, thereby determining the vendor of the IoT device 30 that corresponds to the traffic data.

For example, the vendor information determination unit 106 may search for and confirm the vendor identifier (e.g., vendor name, etc.) corresponding to the vendor code obtained from the traffic data from a site on the Internet N2 (e.g., a site where an identifier such as a vendor name can be searched for from a vendor code). Also, for example, the vendor information determination unit 106 may store information in advance that associates vendor codes with vendor identifiers, and confirm the vendor name corresponding to the extracted vendor code.

As described above, when the processing unit 101 requests the vendor to be determined along with traffic data (traffic data to which the MAC address of the corresponding IoT device 30 is added), the vendor information determination unit 106 obtains the vendor identifier (e.g., vendor name) corresponding to the traffic data and notifies the processing unit 101 of the result.

The processing unit 101 recognizes the vendor of each IoT device 30 based on the determination result of the vendor information determination unit 106, generates vendor information for each IoT device 30, and stores the vendor information in the storage unit 108. The specific format of the vendor information is not limited, and may be, for example, information in which a vendor identifier (e.g., a vendor name) is associated with an identifier of the IoT device 30 (e.g., an IP address, a host name, an arbitrary ID number, etc.).
[Configuration of steady-state communication pattern learning unit 103]
The steady communication pattern learning unit 103 has the function of constructing various unsteady communication detection models (unsteady communication detection model by device type, unsteady communication detection model by vendor, and unsteady communication detection model specific to device) from traffic data. Upon receiving a request from the processing unit 101 along with traffic data, the steady communication pattern learning unit 103 constructs various unsteady communication detection models and notifies the processing unit 101 of completion.

Next, we will explain the process by which the steady-state communication pattern learning unit 103 builds a non-steady-state communication detection model by device type.

Figure 3 is a flowchart showing the process for building an unsteady communication detection model by device type.

The steady-state communication pattern learning unit 103 divides the traffic data collected while operating in learning mode (traffic data supplied from the processing unit 101) into flow units (for example, flow units classified by a combination of source IP address, source port number, destination IP address, and destination port number) (S101).

Next, the steady-state communication pattern learning unit 103 classifies each divided flow by device type (device type of IoT device 30) (S102).

Next, the steady-state communication pattern learning unit 103 calculates and acquires features (statistical features) based on traffic data for each flow (S103). The format of the features acquired by the steady-state communication pattern learning unit 103 is not limited, but may be, for example, statistical values based on traffic data such as the size of each IP packet constituting each flow (traffic data) and the packet arrival interval, or service information inferred from port numbers (TCP or UDP port numbers) (for example, HTTP for TCP 80, TELNET for TCP 23, etc.).

Next, the steady-state communication pattern learning unit 103 performs a process of grouping flows with similar features (S104). The grouping method performed by the steady-state communication pattern learning unit 103 is not limited, but a method of mechanical grouping using a clustering algorithm such as k-means or DBSCAN can be applied.

Next, the steady-state communication pattern learning unit 103 checks the device types corresponding to the IoT devices 30 of the flows belonging to each group, and based on the results, extracts groups to be used for learning the non-steady-state communication detection model by device type (S105).

Figure 4 is a diagram (image) showing the process of grouping the flow in step S105 (the flow used to learn the device type-specific unsteady communication detection model).

For ease of explanation, in Figure 4, flows for any device type A, B, or C are represented by circular, triangular, or rectangular symbols, respectively, and each symbol is mapped to a position corresponding to the flow's features. In other words, Figure 4 visually indicates that flows with symbols close in distance have similar features. Figure 4 shows five symbols related to flows for device type A, two symbols related to flows for device type B, and seven symbols related to flows for device type C. Furthermore, in Figure 4, symbols with a distance less than a predetermined value are grouped together, resulting in three groups G1 to G3 (groups surrounded by dashed lines).

Here, it is assumed that the device types (hereinafter referred to as "target device types") of the IoT devices 30 that are the targets of analysis (monitoring) by the traffic analysis device 10 are all A, B, and C.

Here, the steady-state communication pattern learning unit 103 extracts each flow of a group that includes all target device types, regarding it as constituting a common communication pattern, and uses it to build a non-steady-state communication detection model by device type using a machine learning machine.

In Figure 4, groups G1 and G2 contain flows for all target device types (device types A, B, and C), while group G3 contains only flows for device types A and B, but does not contain flows for device type C. Therefore, in this case, the steady-state communication pattern learning unit 103 extracts flows for groups G1 and G2 as learning targets, but does not extract flows for group G3 as learning targets.

Next, the steady-state communication pattern learning unit 103 converts the traffic data of each extracted flow into features to be input into a machine learning machine (S106), and uses the acquired features to construct a non-steady-state communication detection model by device type in the machine learning machine (S107).

Here, the format of the features indicating the communication pattern of each flow is not limited, but it may be, for example, statistical values based on traffic data such as the size of each IP packet constituting the traffic data and the packet arrival interval, or service information inferred from port numbers (TCP or UDP port numbers) (for example, HTTP for TCP 80, TELNET for TCP 23, etc.).

The steady-state communication pattern learning unit 103 may, for example, input features for N packets from the beginning of a flow into a machine learning device and construct a learning model that predicts the features of the N+1th packet. In this case, the steady-state communication pattern learning unit 103 may also have the machine learning device learn while shifting the beginning of the flow by M packets (M is an integer greater than or equal to 1), thereby reflecting more communication patterns in the model as steady-state communication patterns. The machine learning device used in the steady-state communication pattern learning unit 103 is not limited, but an RNN (Recurrent Neural Network), for example, can be applied.

Through the above processing, the processing unit 101 uses the steady communication pattern learning unit 103 to obtain a device type-specific non-steady communication detection model for each device type and stores it in the memory unit 108.

Next, we will explain the process by which the steady-state communication pattern learning unit 103 builds a vendor-specific non-steady-state communication detection model.

Figure 5 is a flowchart showing the process for building vendor-specific unsteady communication detection models.

While operating in learning mode, the steady communication pattern learning unit 103 executes the processing of the flowchart in Figure 5 following step S107 described above, thereby constructing a vendor-specific non-steady communication detection model.

First, the steady-state communication pattern learning unit 103 acquires data (traffic data) of flows that were not used to construct the learning model for the device-type-specific non-steady-state communication detection model (flows that were not extracted in step S105 described above) (S201).

Next, the steady-state communication pattern learning unit 103 classifies the acquired flows by vendor (by vendor of the IoT device 30) (S202).

Next, the steady-state communication pattern learning unit 103 calculates and acquires features based on traffic data for each acquired flow (S203). At this time, the format of the features acquired by the steady-state communication pattern learning unit 103 is the same as that for the device type-specific non-steady-state communication detection model (step S103 described above), so a detailed explanation will be omitted.

Next, the steady-state communication pattern learning unit 103 performs a process of grouping flows with similar features (S204). At this time, the grouping process performed by the steady-state communication pattern learning unit 103 is the same as that performed in the case of the device type-specific non-steady-state communication detection model (step S104 described above), so a detailed explanation will be omitted.

Next, the steady communication pattern learning unit 103 checks the device types corresponding to the flows belonging to each group, and based on the results, extracts groups to be used for learning the vendor-specific unsteady communication detection model (S205).

The steady-state communication pattern learning unit 103 may, for example, extract a group consisting only of flows belonging to the same vendor.

Figure 6 is a diagram (image) showing the process of grouping the flow in step S205 (the flow used to learn the vendor-specific unsteady communication detection model).

In Figure 6, similar to Figure 4 above, flows for arbitrary device types A, B, and C are represented by circular, triangular, and rectangular symbols, respectively, and each symbol is mapped to a position corresponding to the flow's features. Also, in Figure 6, a symbol indicating the vendor associated with the flow of each symbol is added inside the shape of each symbol. In Figure 6, each symbol is added with α, β, and γ to represent vendors A, B, and C, respectively.

In Figure 6, symbols whose distance is less than a predetermined value are grouped together, resulting in two groups G1 and G2 (groups surrounded by dashed lines).

Here, the steady-state communication pattern learning unit 103 extracts each flow in a group consisting only of flows belonging to the same vendor, assuming that it constitutes a common communication pattern for that vendor, and uses this to build a vendor-specific non-steady-state communication detection model using a machine learning device.

In Figure 6, group G1 is composed of flows from only vendor A (symbol with α added). On the other hand, group G2 contains flows from only device types A and B, and both vendors A and B are mixed. Therefore, in this case, the steady-state communication pattern learning unit 103 extracts flows from group G1 as learning targets, but does not extract flows from group G2 as learning targets.

Next, the steady-state communication pattern learning unit 103 converts the extracted traffic data of each flow into features to be input to the machine learning machine (S206), and uses the acquired features to construct a vendor-specific unsteady communication detection model in the machine learning machine (S207). The feature extraction process and the process of creating an unsteady communication model performed by the steady-state communication pattern learning unit 103 are the same as in the case of an unsteady communication detection model by device type (steps S106 and S107 described above), so a detailed description will be omitted.

Through the above processing, the processing unit 101 uses the steady communication pattern learning unit 103 to acquire a vendor-specific unsteady communication detection model for each vendor and stores it in the storage unit 108.

Next, we will explain the process by which the steady-state communication pattern learning unit 103 constructs a device-specific unsteady-state communication detection model.

Figure 7 is a flowchart showing the process for building a device-specific unsteady communication detection model.

While operating in learning mode, the steady communication pattern learning unit 103 executes the processing of the flowchart in Figure 7 following step S207 described above, thereby constructing a vendor-specific unsteady communication detection model.

First, the steady-state communication pattern learning unit 103 acquires traffic data for flows that were not used to build the learning model for the device-type-specific unsteady-state communication detection model and the vendor-specific unsteady-state communication detection model (flows that were not extracted in either step S105 or S205 described above) (S301).

Next, the steady communication pattern learning unit 103 converts the extracted traffic data of each flow into features to be input to the machine learning machine (S302), and uses the acquired features to construct a device-specific unsteady communication detection model in the machine learning machine (S303). Here, the feature extraction process and the process of creating a device-specific unsteady communication detection model performed by the steady communication pattern learning unit 103 are the same as in the case of the device-type-specific unsteady communication detection model (steps S106 and S107 described above), so detailed explanations will be omitted.

Through the above-described processing, the processing unit 101 uses the steady communication pattern learning unit 103 to hold the device-specific unsteady communication detection model and stores it in the storage unit 108 .
[Configuration of the unsteady communication state determination unit 104]
When operating in the operation mode or the mixed mode, the unsteady communication state determination unit 104 has the function of determining whether or not each IoT device 30 is in an unsteady communication state using traffic data.

When the unsteady communication state determination unit 104 receives notification from the processing unit 101 of a process for determining whether or not an unsteady communication state is occurring (hereinafter referred to as the "unsteady communication state determination process," "abnormality determination process," or "abnormality detection process") along with traffic data, it starts the unsteady communication state determination process. When the unsteady communication state determination unit 104 starts the unsteady communication state determination process, it converts the traffic data into features to be input into each unsteady communication detection model (a device-type-specific unsteady communication detection model, a vendor-specific unsteady communication detection model, and a device-specific unsteady communication detection model), inputs the converted features into each unsteady communication detection model, and determines whether the IoT device 30 related to the traffic data is in an unsteady communication state. The unsteady communication state determination unit 104 notifies the processing unit 101 of the determination result.

Figure 8 is a flowchart showing the operation of the unsteady communication state determination process performed by the unsteady communication state determination unit 104.

When the unsteady communication state determination unit 104 starts the unsteady communication state determination process, it converts the acquired traffic data into features to be applied to each unsteady communication detection model (S401). Here, the unsteady communication state determination unit 104 accumulates as many samples (features) acquired from an arbitrary IoT device 30 (hereinafter, this IoT device 30 will be referred to as the "device of interest") as are necessary for determination by each unsteady communication detection model.

Next, the unsteady communication state determination unit 104 applies the feature sample acquired for the device of interest to an unsteady communication detection model by device type that corresponds to the device type of the device of interest (S402), and determines whether or not the device is in an unsteady communication state (whether or not an abnormality exists) (S403). If the unsteady communication state determination unit 104 determines that the device of interest is in a steady communication state based on the unsteady communication detection model by device type, it proceeds to step S409 and terminates the unsteady communication state determination process; if it determines that the device of interest is in an unsteady communication state, it proceeds to step S404, which will be described later.

If step S403 determines that the device is in an unsteady communication state, the unsteady communication state determination unit 104 applies the feature sample acquired for the device of interest to a vendor-specific unsteady communication detection model corresponding to the vendor of the device of interest (S404) to determine whether the device is in an unsteady communication state (whether an abnormality exists) (S405). If the unsteady communication state determination unit 104 determines that the device of interest is in a steady communication state based on the vendor-specific unsteady communication detection model, it proceeds to step S409 and terminates the unsteady communication state determination process; if it determines that the device of interest is in an unsteady communication state, it proceeds to step S406, which will be described later.

If an unsteady communication state is determined in step S405, the unsteady communication state determination unit 104 applies the feature sample acquired for the device of interest to the device-specific unsteady communication detection model (S406) to determine whether or not the device is in an unsteady communication state (whether or not an abnormality exists) (S407). If the unsteady communication state determination unit 104 determines that the device of interest is in a steady communication state based on the device-specific unsteady communication detection model, it proceeds to step S409 and terminates the unsteady communication state determination process; if it determines that the device of interest is in an unsteady communication state, it proceeds to step S408, which will be described later.

If an unsteady communication state is determined in step S407, the unsteady communication state determination unit 104 finally determines that the target device is in an unsteady communication state (abnormal state) (S408) and outputs the determination result (a result indicating that the target device is in an unsteady communication state (abnormal state)).

When the process proceeds to step 409, the non-steady communication state determination unit 104 determines that the communication state is steady (not an abnormal state) and outputs the determination result.

It is difficult to avoid 100% false detections even when a multi-stage determination is made using three unsteady communication state detection models in the processing of the flowchart shown in Fig. 8. For this reason, the unsteady communication state determination unit 104 may not immediately output an abnormality determination result (for example, by sending an alert) even if it detects an abnormality once for a target device in the above flowchart based on traffic data at a certain point in time, but may output a final abnormality determination only when the subsequent abnormality detection rate reaches a certain level or more (for example, when anomaly detection is repeated thereafter and the rate of abnormality detections among the number of determinations reaches a certain level or more).
[Configuration of communication control unit 107]
The communication control unit 107 has a function of controlling communication for the IoT device 30 that has been determined to be in an abnormal state (unsteady communication state) by the unsteady communication state determination unit 104 based on a notification from the processing unit 101. When the communication control unit 107 receives a request from the processing unit 101 to cut off communication with a certain IoT device 30, it may cut off communication with the IoT device 30 and notify the processing unit 101 of the result.

For example, the communication control unit 107 may perform communication control to block communication by the IoT device 30 (communication with the Internet N2). The method by which the communication control unit 107 blocks communication of a target device is not limited. For example, in the case of a network configuration such as that shown in Figure 1, if the communication control unit 107 determines that a certain IoT device 30 is in an abnormal state (unsteady communication state), it may be configured to control the gateway 40 (firewall policy management function) to add a policy (rule) that blocks communication by the IoT device 30 (for example, communication related to the IP address of the IoT device 30).

(A-2) Operation of the First Embodiment Next, the operation of the traffic analysis device 10 of the first embodiment having the above-described configuration (traffic analysis method according to the embodiment) will be described.

Figure 9 is a flowchart showing an example of the operation when traffic analysis device 10 receives traffic data while operating in learning mode.

In the traffic analysis device 10, when the traffic data collection unit 102 captures new traffic data supplied from the network switch 20 (S501), it analyzes the captured content, formats it into an IP packet, and notifies the processing unit 101.

Next, the processing unit 101 checks whether the period required to learn a steady communication pattern after the learning mode is started (hereinafter referred to as the "steady learning period") has ended (S502). For example, the processing unit 101 may determine that the steady learning period has ended when a certain period has elapsed since the start of traffic data collection (start of learning mode operation), or when a certain amount of traffic data has accumulated (for example, when a certain number of IP packets have accumulated). If the steady learning period has ended, the traffic analysis device 10 proceeds to step S506, which will be described later, and if it is still within the steady learning period, it proceeds to step S503, which will be described later.

If the device is within the steady learning period, the processing unit 101 checks the vendor information stored in the storage unit 108 to determine whether vendor information for the IoT device 30 associated with the most recently received traffic data exists (S503). If no vendor information for the IoT device 30 is stored, the processing unit 101 notifies the vendor information determination unit 106 of the traffic data and requests that the vendor information be determined and acquired (S504). At this time, the vendor information determination unit 106 extracts the MAC address from the received traffic data and acquires the vendor information based on the extracted MAC address (the OUI that constitutes the MAC address). The vendor information determination unit 106 notifies the processing unit 101 of the acquired vendor information. At this time, the processing unit 101 stores the vendor information received by the vendor information determination unit 106 in the storage unit 108.

Next, the traffic analysis device 10 (processing unit 101) saves the received traffic data (S505) and returns to step S501 described above.

If it is determined in step S502 above that the steady-state learning period has ended, the processing unit 101 acquires the traffic data accumulated in the memory unit 108 during the steady-state learning period and requests the device type determination unit 105 to construct a device type determination model (S506).

The device type determination unit 105 acquires correspondence information between devices and device types from an external source (e.g., an administrator of the traffic analysis device) (e.g., the traffic analysis device has an interface for inputting correspondence information, and the administrator enters the information there). The device type determination unit 105 converts the traffic data into features, assigns supervised labels based on the correspondence information between devices and device types, and constructs a device type determination model using a supervised machine learning engine. At this time, a class for unknown device types is created so that communication patterns that are not similar to any device type are classified into the unknown device type class. The device type determination unit 105 notifies the processing unit 101 of the constructed device type determination model. The processing unit 101 requests the storage unit 108 to store the received device type determination model. The processing unit 101 also notifies the steady communication pattern learning unit 103 of the traffic data and device type information of the monitored devices, and requests the construction of a device-type-specific unsteady communication detection model, a vendor-specific unsteady communication detection model, and a device-specific unsteady communication detection model. The steady communication pattern learning unit 103 constructs various unsteady communication detection models and notifies the memory unit 108 of the constructed unsteady communication detection models for storage (S507).

Next, the processing unit 101 transitions to operation mode (S508).

Figure 10 is a flowchart showing an example of the operation of the traffic analysis device 10 when it receives traffic data while operating in operational mode.

Here, we will assume that the traffic analysis device 10 is operating in operational mode and has captured traffic data from the monitored network N1 (network switch 20).

At this time, when the traffic data collection unit 102 captures the traffic data, it analyzes the captured content, formats it into an IP packet, and notifies the processing unit 101 (S601). Hereinafter, the IoT device 30 related to the traffic data will be referred to as the device of interest.

The processing unit 101 acquires the device type information stored in the memory unit 108 (device type information for each IoT device 30 currently being managed) and checks whether the device type of the target device has been determined (whether the device type information for the target device is stored in the memory unit 108) (S602).

If the device type of the device of interest has not yet been determined, the processing unit 101 notifies the device type determination unit 105 of the traffic data and the device type determination model, and requests that the device type of the device of interest be determined. The device type determination unit 105 then generates features from the received traffic data, applies them to the device type determination model, and returns the determination result to the processing unit 101. The processing unit 101 then stores device type information (information associating the device of interest with the device type identifier) based on the determination result of the device type determination unit 105 in the storage unit 108 (S603). At this time, if the probability that the device is an unknown device in the device type determination model is equal to or greater than a certain value, the processing unit 101 may notify the processing unit 101 that the device is an unknown device type (a device type that has not been learned in the device type-specific non-steady communication detection model); otherwise, it may notify the processing unit 101 of the determined device type.

Next, the processing unit 101 checks whether a device type-specific unsteady communication detection model exists for the device type of the device of interest (whether it is stored in the memory unit 108) (S604), and if so, proceeds to step S605, described below; if not, it assumes that an IoT device 30 of an unlearned device type has been connected, and proceeds to step S610 (transition to mixed mode) to start learning.

Next, the processing unit 101 acquires the vendor information stored in the memory unit 108 (vendor information for each IoT device 30 currently being managed) and checks whether the vendor of the target device has been determined (whether the vendor information for the target device is stored in the memory unit 108) (S605).

If the vendor of the device of interest has not yet been determined, the processing unit 101 notifies the vendor information determination unit 106 of the traffic data (traffic data with MAC address information added) and requests that the vendor of the device of interest be determined. The vendor information determination unit 106 extracts the MAC address from the received traffic data and obtains from the Internet the vendor identifier (e.g., vendor name) corresponding to the vendor code of the MAC address. The vendor information determination unit 106 notifies the processing unit 101 of the obtained vendor identifier. The processing unit 101 then stores vendor information based on the determination result of the vendor information determination unit 106 in the storage unit 108 (S606).

Next, the processing unit 101 determines whether a vendor-specific unsteady communication detection model exists for the vendor of the device of interest (whether it is stored in the memory unit 108) (S607), and if so, proceeds to step S605, described below; if not, proceeds to step S610 (transition to mixed mode) to start learning, assuming that an IoT device 30 from an unlearned vendor has been connected.

Next, the processing unit 101 acquires the device type-specific unsteady communication detection model, vendor-specific unsteady communication detection model, and device-specific unsteady communication detection model corresponding to the device of interest from the storage unit 108, and requests the unsteady communication state determination unit 104 to determine an unsteady communication state (abnormality determination). The unsteady communication state determination unit 104 performs unsteady communication state determination processing (abnormality determination processing; processing of the flowchart in Figure 8 described above) using the received traffic data and various unsteady communication detection models. The unsteady communication state determination unit 104 notifies the processing unit 101 of the results of the unsteady communication state determination processing (S608).

The processing unit 101 checks the results of the non-steady communication state determination process (abnormality determination process) (S609), and if the determination result does not indicate that the target device is not in a non-steady communication state (abnormality state), it terminates the process (a series of processes related to the target device associated with receiving traffic data) (S612).

On the other hand, if the device of interest is determined to be in an unsteady communication state (abnormal state), the processing unit 101 requests the communication control unit 107 to cut off communication with the device of interest. The communication control unit 107 sends control information to the gateway 40 (firewall) to cut off communication with the device of interest, cutting off communication with the device (S613), and ends the process (a series of processes related to the device of interest associated with receiving traffic data).

Figure 11 is a flowchart showing an example of the operation when the traffic analysis device 10 receives traffic data while operating in mixed mode.

Here, we will explain the situation assuming that the traffic analysis device 10 is operating in mixed mode and has captured traffic data from the monitored network N1 (network switch 20).

At this time, the traffic data collection unit 102 first analyzes the contents of the captured traffic data, formats it into IP packets, and notifies the processing unit 101 (S701).

The processing unit 101 acquires the device type information stored in the memory unit 108 and checks whether the device type of the device of interest has been determined (S702). If the device type of the device of interest has not been determined, the processing unit 101 notifies the device type determination unit 105 of the traffic data and the device type determination model, requests it to determine the device type of the device of interest, obtains the determination result, and stores the device type information of the device of interest based on the determination result in the memory unit 108 (S703).

Next, the processing unit 101 checks whether a device-type-specific unsteady communication detection model corresponding to the device type of the target device exists (whether it has been learned or not) (S704), and if it exists, proceeds to step S705, which will be described later; if not, it assumes that an IoT device 30 of an unlearned device type has been connected, and proceeds to step S714, which will be described later, to start/continue the learning process (construction of a device-type-specific unsteady communication detection model corresponding to the device type of the target device).

Next, the processing unit 101 acquires the vendor information stored in the memory unit 108 and checks whether the vendor information of the target device has been determined (whether the vendor information of the target device is stored in the memory unit 108) (S705).

If the vendor of the device of interest has not been determined, the processing unit 101 requests the vendor information determination unit 106 to determine the vendor of the device of interest, obtains the determination result, and stores vendor information based on the determination result in the storage unit 108 (S706).

Next, the processing unit 101 checks whether a vendor-specific unsteady communication detection model corresponding to the device of interest exists (whether it has been learned or not) (S707), and if it does exist, proceeds to step S708, which will be described later; if not, it assumes that an IoT device 30 of an unlearned vendor has been connected, and proceeds to step S716, which will be described later, to start/continue the learning process (construction of a vendor-specific unsteady communication detection model corresponding to the vendor of the device of interest).

Next, the processing unit 101 requests a determination of an unsteady communication state (abnormal state) corresponding to the device of interest, obtains the determination result, and notifies the storage unit 108 of the determination result for storage (S708). If an unsteady communication state is determined, the processing proceeds to step S710, which will be described later. On the other hand, if an unsteady communication state (abnormal state) is not determined for the device of interest, the processing unit 101 proceeds to step S711, which will be described later.

Note that the processing of steps S701 to S710 is almost identical to the processing in operational mode, so a detailed explanation will be omitted.

If the device of interest is not determined to be in an unsteady communication state (abnormal state), the processing unit 101 requests the communication control unit 107 to cut off communication with the IoT device 30 related to the traffic data, thereby cutting off communication with the device (S710).

If, in step S704 described above, there is no device-type-specific non-steady communication detection model related to the device type of the device of interest, the processing unit 101 checks whether the learning period for the steady communication pattern of that device type has ended (S714), and if the learning period has ended, proceeds to step S715 described below; if not, proceeds to step S718 described below, stores the acquired traffic data in the storage unit 108, and ends the processing (a series of processes triggered by the reception of that traffic data).

On the other hand, if the learning period has ended, the processing unit 101 acquires the accumulated traffic data for the device type from the storage unit 108, causes the steady communication pattern learning unit 103 to construct and acquire a device-type-specific unsteady communication detection model for the device type, stores the acquired device-type-specific unsteady communication detection model in the storage unit 108 (S715), and proceeds to the processing of step S705 described above. At this time, the steady communication pattern learning unit 103 may collect traffic data for the IoT device 30 for which the device-type-specific unsteady communication detection model is to be constructed, for a predetermined learning period, and apply the data to the processing of the flowchart in FIG. 3 described above, thereby obtaining a device-type-specific unsteady communication detection model corresponding to the device type of the IoT device 30. Furthermore, at this time, the steady communication pattern learning unit 103 may perform grouping processing (steps S201 to S204 in FIG. 5) for constructing a vendor-specific unsteady communication detection model, and then construct a device-specific unsteady communication detection model corresponding to the IoT device 30 by the processing of the flowchart in FIG. 7.

If, in step S707 described above, there is no vendor-specific unsteady communication detection model for the vendor of the device of interest, the processing unit 101 checks whether the learning period for the steady communication pattern of that vendor has ended (S716), and if the learning period has ended, proceeds to step S717 described below; if not, proceeds to step S718 described below, stores the acquired traffic data in the storage unit 108, and ends the processing (a series of processes triggered by the reception of that traffic data).

On the other hand, if the learning period has ended, the processing unit 101 acquires the accumulated traffic data for the vendor from the storage unit 108, causes the steady-state communication pattern learning unit 103 to construct and acquire a vendor-specific unsteady communication detection model for the vendor, stores the acquired vendor-specific unsteady communication detection model in the storage unit 108 (S717), and proceeds to the processing of step S708 described above. At this time, the steady-state communication pattern learning unit 103 may collect traffic data for the IoT device 30 for which the vendor-specific unsteady communication detection model is to be constructed for a predetermined learning period and apply the data to the processing of the flowchart of FIG. 5 described above to obtain a vendor-specific unsteady communication detection model corresponding to the vendor of the IoT device 30. In this case, the steady-state communication pattern learning unit 103 may extract flows from all traffic data acquired during the mixed mode learning period in the processing of step S201, or may execute the processing of steps S101 to S104 of the flowchart of FIG. 3 to acquire traffic data not extracted in step S104 and then execute the processing of the flowchart of FIG. 5. At this time, the steady communication pattern learning unit 103 may also construct a device-specific unsteady communication detection model corresponding to the IoT device 30 by processing the flowchart in Figure 7.

Following step S710 described above, the processing unit 101 checks whether a device type or vendor is in the learning period in the current state (mixed mode state) in order to construct any non-stationary communication detection model (S711), and if a device type or vendor is in the learning period, it transitions to operational mode; if not, it terminates the processing (a series of processes triggered by the reception of the traffic data).

(A-3) Effects of the First Embodiment According to the first embodiment, the following effects can be achieved.

In the traffic analysis device 10 of the first embodiment, a non-steady communication detection model is constructed according to the attributes of the IoT device 30, and the non-steady communication state (abnormal state) of each IoT device 30 is determined using the non-steady communication detection model. Furthermore, in the traffic analysis device 10 of this first embodiment, the non-steady communication detection models used include a device-type-specific non-steady communication detection model (a model that learns the steady communication patterns of the main functions of each device type), a vendor-specific non-steady communication detection model (a model that learns the steady communication patterns of vendor-specific control communications, etc., for each vendor), and a device-specific non-steady communication detection model (a device-specific non-steady communication detection model that learns communication patterns other than those mentioned above). As a result, in the traffic analysis device 10 of the first embodiment, even if an IoT device 30 that was not present during the initial steady-state communication learning period is connected to the monitored network N1, it is possible to determine an unsteady communication state (abnormal state) using the unsteady communication detection model for each device type/vendor, and therefore, it is possible to perform unsteady communication determination processing using the learned unsteady communication detection model in the same way as for other IoT devices 30, without requiring learning processing for the IoT device 30.

Furthermore, the device-type unsteady communication detection model can determine deviations from steady communication patterns related to the main functions of the IoT device 30, and the vendor-specific unsteady communication detection model can determine deviations from vendor-specific steady communication patterns. Therefore, the traffic analysis device 10 can improve the accuracy of anomaly detection compared to building a single unsteady communication detection model using all communications from a certain IoT device 30.

Furthermore, by applying a device-specific unsteady communication detection model at the end of the unsteady communication determination process, the traffic analysis device 10 can distinguish between device-specific normal communication patterns and other abnormal communication patterns, thereby further improving determination accuracy.

(B) Second Embodiment A second embodiment of the traffic analysis device, traffic analysis program, and traffic analysis method according to the present invention will now be described in detail with reference to the drawings.

(B-1) Configuration of the Second Embodiment The connection relationships of the devices related to the second embodiment can also be shown using Figure 2. In Figure 2, symbols ending with A are symbols used only in the second embodiment.

In the second embodiment, the traffic analysis device 10 is replaced with a traffic analysis device 10A.

Figure 12 is a block diagram showing the functional configuration of the traffic analysis device 10A of the second embodiment.

In Figure 12, parts that are the same as or correspond to those in Figure 1 above are assigned the same or corresponding reference numerals. The following describes the second embodiment, focusing on the differences from the first embodiment.

The traffic analysis device 10A differs from the first embodiment in that the processing unit 101 and the steady-state communication pattern learning unit 103 are replaced with a processing unit 101A and a steady-state communication pattern learning unit 103A, and a feedback unit 109 is further added.

The feedback unit 109 supplies the determination result by the non-steady communication state determination unit 104 to the operator terminal TE used by the operator OP, and also accepts input of feedback information regarding the determination result (e.g., feedback information regarding an erroneous determination result).

The format in which the feedback unit 109 inputs and outputs information to and from the operator terminal TE is not limited, but for example, the feedback unit 109 may present the determination result to the operator terminal TE and accept input of feedback information in the form of an operation screen (GUI screen; web screen; web content). Here, the operation screen in which the feedback unit 109 presents the determination result to the operator terminal TE and accepts input of feedback information is referred to as the "feedback input acceptance screen."

In the traffic analysis device 10A of the second embodiment, a communication pattern for which an abnormality has been detected is presented to the operator OP via the operator terminal TE, allowing the operator OP to determine whether the communication pattern is truly abnormal. The traffic analysis device 10A can then accept input of feedback information from the operator OP regarding a false detection (a determination result that a communication pattern that is not a non-steady communication state is an unsteady communication state). Hereinafter, feedback information indicating a false detection supplied from the operator terminal TE will be referred to as "false detection feedback."

Figures 13 and 14 show examples of the configuration of the feedback input reception screen.

Figure 13 shows field F101, which displays event information based on the judgment result (judgment result of the unsteady communication state judgment unit 104) in the feedback unit 109.

Field F101 contains subfields SF that display each judgment result as an event (alert). In field F101 shown in Figure 13, subfields SF111, SF112, etc. are displayed in chronological order from top to bottom.

Each subfield shown in Figure 13 contains an "Event Name" indicating the name of the event, "Device Information" indicating the IoT device 30 related to the event (displayed here as an IP address, but other display formats such as a host name may also be used), the "Occurrence Time" of the event, and a Details Confirmation button B101 for accepting the display of log information related to the event.

For example, subfield SF111 shown in FIG. 13 displays the event name "Permanent detection of non-steady communication" (an event name indicating that a non-steady communication state (abnormal state) has been detected), the device information includes "xxx.xxx.xxx.xxx" indicating the IP address of IoT device 30-1, the time of occurrence is "14:50", and a details confirmation button B101 for accepting a display of details of the traffic data (information indicating each IP packet) used to detect the event (abnormality).

When the Confirm Details button B101 in subfield SF111 is pressed in this state, the feedback unit 109 displays field F201 in FIG. 14 on the feedback input acceptance screen (e.g., as a pop-up display). Field F201 contains subfield SF201 for displaying details of the traffic data (information indicating each IP packet) used to detect the event (anomaly), and button B201 for accepting false positive feedback for the event. When button B201 in field F201 is pressed in the state shown in FIG. 14, the feedback unit 109 notifies the processing unit 101 that false positive feedback has been received for the judgment result related to the event. When displaying subfield SF201 (traffic data details), the feedback unit 109 obtains the corresponding traffic data from the memory unit 108 via the processing unit 101A.

As described above, the feedback unit 109 accepts false detection feedback, for example, on a feedback input acceptance screen configured as shown in Figures 13 and 14.

When the processing unit 101A receives notification of false positive feedback from the feedback unit 109, it notifies the steady communication pattern learning unit 103A of the device-specific unsteady communication detection model and the communication pattern for which false positive feedback has been received, and requests that the device-specific unsteady communication detection model be re-learned.

In addition to the first embodiment, when the steady communication pattern learning unit 103A receives a request from the processing unit 101 to re-learn the device-specific unsteady communication detection models, it applies the communication patterns that have been falsely detected as feedback to the device-specific unsteady communication detection models through a sequential learning process (taking into account the content of the false detection feedback) and reconstructs each unsteady communication detection model. The steady communication pattern learning unit 103A notifies the processing unit 101 of each reconstructed device-specific unsteady communication detection model.

As a result, the traffic analysis device 10A can use a machine learning machine to learn a communication pattern that has been falsely detected as feedback as a normal communication pattern, taking into consideration that the communication pattern will not be detected as an anomaly in subsequent anomaly determinations. The traffic analysis device 10A may use a sequential learning machine learning machine (a machine learning machine that updates internal parameters each time data is input and reconstructs a model) as this machine learning machine. This sequential learning machine is used in the steady communication pattern learning unit 103A of the second embodiment to build a device-specific unsteady communication detection model.

(B-2) Operation of the Second Embodiment Next, the operation of the traffic analysis device 10A in the second embodiment having the above configuration (the traffic analysis method according to the embodiment) will be described. Here, only the differences between the operation of the traffic analysis device 10A and the first embodiment will be described.

Here, we will explain the operation of the traffic analysis device 10A in the second embodiment when it receives false detection feedback from the operator terminal TE (operator OP) while operating in operational mode or mixed mode.

Here, when the processing unit 101A receives a determination result from the non-steady communication state determination unit 104 that an IoT device 30 in an abnormal state (non-steady communication state) has been detected, it controls the feedback unit 109 to additionally display the contents of the determination result on a feedback input acceptance screen (for example, an operation screen such as those shown in Figures 13 and 14) presented on the operator terminal TE, thereby enabling the input of false detection feedback to be accepted.

Here, it is assumed that the operator OP presses the details confirmation button B101 in subfield SF111 (a subfield indicating an abnormality detection event related to IoT device 30-1) shown in FIG. 13 on the operator terminal TE, and then presses button B201 in field F201 shown in FIG. 14. This enables the feedback unit 109 to receive false detection feedback regarding the results of the abnormality determination related to IoT device 30-1.

When the feedback unit 109 receives input of false detection feedback from the operator terminal TE, it notifies the processing unit 101 of the traffic data that was falsely detected as feedback. The processing unit 101 acquires the device-specific unsteady communication detection model from the memory unit 108, notifies the steady communication pattern learning unit 103A of the traffic data that was falsely detected as feedback, and requests relearning (relearning processing that takes into account the content of the false detection feedback) of each emergency communication detection model (device type-specific unsteady communication detection model, vendor-specific unsteady communication detection model, and device-specific unsteady communication detection model).

The steady communication pattern learning unit 103A reconstructs each unsteady communication detection model through a sequential learning process using traffic data that has been fed back as false positives. The steady communication pattern learning unit 103A notifies the processing unit 101 of each reconstructed unsteady communication detection model. The processing unit 101 stores each reconstructed unsteady communication detection model in the memory unit 108.

(B-3) Advantages of the Second Embodiment According to this embodiment, in addition to the advantages of the first embodiment, the following advantages can be achieved.

The traffic analysis device 10A in the second embodiment has a function for receiving false positive feedback of anomaly detection results from the operator. In order to re-learn communication patterns that have been falsely detected as normal communication, each non-steady communication detection model is constructed using a sequential learning machine learning machine, and in the event of false positive feedback, the communication pattern that has been falsely detected as normal communication is applied to the machine learning machine to reconstruct the model. As a result, even if the traffic analysis device 10A in the second embodiment falsely detects the unique communication pattern of a newly connected IoT device 30 as an anomaly, for example, the false positive feedback immediately applies it to the steady communication model, thereby preventing the false positive from continuing.

(C) Third Embodiment A traffic analysis device, a traffic analysis program, and a traffic analysis method according to a third embodiment of the present invention will now be described in detail with reference to the drawings.

The connection relationships of the devices related to the third embodiment can also be shown using Figure 2. In Figure 2, symbols ending with B are symbols used only in the third embodiment.

In the third embodiment, the traffic analysis device 10 is replaced with a traffic analysis device 10B.

Figure 15 is a block diagram showing the functional configuration of a traffic analysis device 10B according to the third embodiment. In Figure 15, parts that are the same as or correspond to those in Figure 1 described above are assigned the same or corresponding reference numerals. The following description of the first embodiment will focus on the differences from the first embodiment.

The traffic analysis device 10B differs from the first embodiment in that the processing unit 101 is replaced with a processing unit 101B, and the steady-state communication pattern learning unit 103 is excluded.

In the above embodiments, the traffic analysis devices 10 and 10A have a steady-state communication pattern learning unit 103, but this is not limited to this. For example, a configuration without a steady-state communication pattern learning unit 103, like the traffic analysis device 10B, may also be used.

The traffic analysis device 10B may acquire each unsteady communication detection model (unsteady communication detection model by device type, unsteady communication detection model by vendor, and device-specific unsteady communication detection model) from an external device (for example, an external cloud server not shown), set it in the unsteady communication state determination unit 104, and perform determination processing.

At this time, the traffic analysis device 10B may request an external device (for example, an external cloud server, not shown) to execute the processing of the steady communication pattern learning unit 103. In this way, in a cloud system that collects traffic data from traffic analysis devices 10B related to multiple edge networks (networks to be monitored) and performs learning processing, by aggregating and learning traffic data from traffic analysis devices 10B related to multiple edge networks (networks to be monitored), a non-steady communication detection model can be constructed using more data, thereby improving detection accuracy.

Furthermore, because machine learning generally requires a large amount of computational resources for learning, the third embodiment uses the above-described configuration to reduce the computational resources required for the operation of the traffic analysis device 10B.

(D) Fourth Embodiment A fourth embodiment of the traffic analysis device, traffic analysis program, and traffic analysis method according to the present invention will now be described in detail with reference to the drawings.

The connection relationships of the devices related to the fourth embodiment can also be shown using Figure 2. In Figure 2, symbols ending with C are symbols used only in the fourth embodiment.

In the fourth embodiment, the traffic analysis device 10 is replaced with a traffic analysis device 10C.

Figure 16 is a block diagram showing the functional configuration of a traffic analysis device 10C according to the fourth embodiment. In Figure 16, parts that are the same as or correspond to those in Figure 1 described above are assigned the same or corresponding reference numerals. The following description of the first embodiment will focus on the differences from the first embodiment.

The traffic analysis device 10C differs from the first embodiment in that the processing unit 101 and the unsteady communication state determination unit 104 are replaced with a processing unit 101C and an unsteady communication state determination unit 104, and further in that the vendor information determination unit 106 is excluded.

The unsteady communication state determination unit 104C of the traffic analysis device 10C of the third embodiment differs from the first embodiment in that it omits the anomaly determination process using a vendor-specific unsteady communication detection model. In other words, the unsteady communication state determination unit 104C of the traffic analysis device 10C of the third embodiment performs anomaly determination by determining anomalies using a device-type-specific unsteady communication detection model, and then determining anomalies in traffic data for which anomalies have been detected using a device-specific unsteady communication detection model. In other words, the processing unit 101C of the third embodiment differs from the first embodiment in that it does not perform any processing related to the vendor-specific unsteady communication detection model.

In the traffic analysis device 10C of the third embodiment, by eliminating the application of vendor-specific unsteady communication detection models, the time required to learn steady communication patterns and determine anomalies can be reduced.

(E) Fifth Embodiment A fifth embodiment of the traffic analysis device, traffic analysis program, and traffic analysis method according to the present invention will now be described in detail with reference to the drawings.

The connection relationships of the devices related to the fifth embodiment can also be shown using Figure 2. In Figure 2, symbols ending with D are symbols used only in the fifth embodiment.

In the fifth embodiment, the traffic analysis device 10 is replaced with a traffic analysis device 10D.

Figure 17 is a block diagram showing the functional configuration of a traffic analysis device 10D according to the fifth embodiment. In Figure 17, parts that are the same as or correspond to those in Figure 1 above are assigned the same or corresponding reference numerals. The following describes the first embodiment, focusing on the differences from the first embodiment.

The traffic analysis device 10D differs from the first embodiment in that the steady-state communication pattern learning unit 103 is replaced with a steady-state communication pattern learning unit 103D.

In the traffic analysis device 10 of the first embodiment, when extracting flows to be learned, groups to which flows from either the same device type or all devices from the same vendor belong by clustering are used as learning data targets for constructing various unsteady communication detection models, but this is not limited to this. In this embodiment, the steady communication pattern learning unit 103D of the traffic analysis device 10D sets a parameter for the ratio of the number of flows used to construct device-specific unsteady communication detection models and vendor-specific unsteady communication detection models to the total number of flows acquired in learning mode, and extracts groups to be used for learning so that this ratio is satisfied.

Specifically, the steady-state communication pattern learning unit 103D of this embodiment introduces a parameter (hereinafter referred to as the "device type group membership rate") that indicates the percentage of all target device types included when the device types of IoT devices 30 related to the flows included in a certain group are tallied, and a parameter (hereinafter referred to as the "vendor group membership rate") that indicates the proportion of the vendor with the largest number of flows (proportion to the total number of flows in the group) when the vendors of IoT devices 30 related to the flows included in a certain group are tallied. For example, when the device types of IoT devices 30 related to the flows included in a certain group are tallied, if all target devices are included, the device type group membership rate is 100%, and if 80% of all target devices are included, the device type group membership rate is 80%. Furthermore, for example, when the vendors of the IoT devices 30 related to the flows included in a group are tallied, if the IoT devices 30 related to all flows are from the same vendor, the vendor group affiliation rate is 100%, and if the number of flows from the vendor with the largest number accounts for 80% of the total number of flows in the group, the vendor group affiliation rate is 80%.

When extracting groups to be used in learning the device type-specific unsteady communication detection model, the steady communication pattern learning unit 103D in this embodiment calculates the device type group affiliation rate for each group, and extracts the group as a learning target if the device type group affiliation rate is equal to or greater than a standard (hereinafter, this standard will be referred to as the "standard device type group affiliation rate"). When extracting groups to be used in learning the vendor-specific unsteady communication detection model, the steady communication pattern learning unit 103D in this embodiment calculates the vendor group affiliation rate for each group, and extracts the group as a learning target if the vendor group affiliation rate is equal to or greater than a standard (hereinafter, this standard will be referred to as the "standard vendor group affiliation rate").

In this embodiment, the initial value of the reference device type group affiliation rate is 100%, and a reference device type group affiliation rate of 100% means that a group containing flows of all target device types is used for learning. Also, in this embodiment, the initial value of the reference vendor group affiliation rate is 100%, and a reference vendor group affiliation rate of 100% means that a group in which all devices have the same vendor is used for learning. In other words, while in the first embodiment the reference device type group affiliation rate and reference vendor group affiliation rate were fixed at 100%, in this embodiment the reference device type group affiliation rate and reference vendor group affiliation rate are variable parameters.

Furthermore, in this embodiment, the ratio of flows not extracted for learning the device type-specific unsteady communication detection model and the vendor-specific unsteady communication detection model (hereinafter referred to as "unextracted flows") to all flows of traffic data initially input for learning (hereinafter referred to as "total flows") is referred to as the "flow unextraction rate." For example, if the total flow is 100 and the unextracted flows are 10, the flow unextraction rate is 10%. In this embodiment, the steady communication pattern learning unit 103 is set to a target value for the flow unextraction rate (hereinafter referred to as the "target flow unextraction rate"). If the flow unextraction rate exceeds the target flow unextraction rate, the steady communication pattern learning unit 103 performs processing to lower the reference device type group affiliation rate and/or the reference vendor group affiliation rate until the flow unextraction rate becomes equal to or less than the target flow unextraction rate. Here, the steady communication pattern learning unit 103 does not simultaneously lower the reference device type group affiliation rate and the reference vendor group affiliation rate, but instead performs processing to confirm the flow unextraction rate by alternately lowering the reference device type group affiliation rate and the reference vendor group affiliation rate. Here, the steady communication pattern learning unit 103 is described as reducing the reference device type group membership rate (by 5% at a time) when the number of repetitions (number of times the process checks the flow unextraction rate) is odd, and reducing the vendor-specific unsteady communication detection model (by 5% at a time) when the number of repetitions (number of times the process checks the flow unextraction rate) is even, but is not limited to this. The amount by which the reference device type group membership rate and reference vendor group membership rate are reduced at one time is not limited to 5%, and other values may be applied.

Here, the parameter for adjusting (subtracting) the reference vendor group affiliation rate to achieve the target flow unextraction rate is i (i varies between 0 and 100), and the parameter for adjusting (subtracting) the vendor group affiliation rate is j (j varies between 0 and 100). In other words, the device type group affiliation rate is "100-i [%]", and the vendor group affiliation rate is "100-j [%]". Therefore, if the initial values of i and j are set to 0, the initial values of the reference device type group affiliation rate and the reference vendor group affiliation rate will be 100%. The target flow unextraction rate may be set to 1%, for example.

Figure 18 is a flowchart showing the operation of the processing unit 101D in this embodiment in learning mode.

First, the steady-state communication pattern learning unit 103D divides the communication flows of the acquired traffic data by device type (S801).

Next, the steady-state communication pattern learning unit 103D sets the standard device type group membership rate to "100-i [%]" as the extraction condition for groups to be used for learning when flows are grouped by clustering (clustering by device type) (S802), and extracts groups (flow groups) to be used for learning from the traffic data so that the standard device type group membership rate is satisfied (S803).

Next, the steady communication pattern learning unit 103D classifies flows that were not extracted in the processing of step S801 (flows that were not used to build the device type-specific unsteady communication detection model) by vendor (S804).

Next, the steady-state communication pattern learning unit 103D sets the reference vendor group affiliation rate to "100-j [%]" as the extraction condition for groups to be used for learning when flows are grouped by clustering (clustering by vendor) (S805), and extracts groups (groups of flows) to be used for learning from the traffic data so that the reference vendor group affiliation rate is satisfied (S806).

Next, the steady-state communication pattern learning unit 103D calculates the flow unextracted rate and checks whether it is equal to or less than the target flow unextracted rate (S807).

If the unextracted flow rate is equal to or less than the target unextracted flow rate, the steady communication pattern learning unit 103D completes the grouping process (S811). The steady communication pattern learning unit 103D then constructs an unsteady communication detection model by device type using the flows of the group extracted in step S801, and finally constructs an unsteady communication detection model by vendor using the flows of the group extracted in step S806.

If the unextracted flow rate is greater than the target unextracted flow rate, the steady-state communication pattern learning unit 103D checks whether the number of repetitions is even or odd (S808).

If the number of repetitions is an even number, the steady-state communication pattern learning unit 103D subtracts 5% from the reference device type group affiliation rate (adds 5 to i; i = i + 5) (S809) and returns to step S802 described above for operation. On the other hand, if the number of repetitions is an odd number, the steady-state communication pattern learning unit 103D subtracts 5% from the reference vendor group affiliation rate (adds 5 to j; j = i + 5) (S810) and returns to step S802 described above for operation. Note that the amount of subtraction of i and j is not limited to 5% at this time.

Through the above processing, the steady communication pattern learning unit 103D is able to adjust the learning difficulty of the device-specific unsteady communication detection model and the vendor-specific unsteady communication detection model.

Note that the more communication patterns the device-specific unsteady communication detection model/vendor-specific unsteady communication detection model learns, the lower the detection accuracy of the device-specific unsteady communication detection model/vendor-specific unsteady communication detection model. On the other hand, the fewer communication patterns the device-specific unsteady communication detection model/vendor-specific unsteady communication detection model learns, the higher the detection accuracy of the device-specific unsteady communication detection model/vendor-specific unsteady communication detection model. However, the learning data for the device-type-specific unsteady communication detection model/vendor-specific unsteady communication detection model becomes more complex, resulting in lower detection accuracy for these models. Therefore, in this embodiment, detection accuracy can be improved by adjusting this target value to maximize overall detection accuracy (adjusting i and j to achieve the target flow unextraction rate).

Note that the target flow unextraction rate may be set to 0 (the number of flows learned by the device-specific unsteady communication detection model is zero). This allows anomalies to be detected using only the device-type-specific unsteady communication detection model and the vendor-specific unsteady communication detection model, thereby shortening the time required for learning the device-specific unsteady communication detection model and for anomaly detection.

(F) Other Embodiments The present invention is not limited to the above-described embodiments, and modified embodiments such as those exemplified below can also be mentioned.

(F-1) In each of the above embodiments, the device type determination method in the device type determination unit 105 utilizes a determination model constructed through supervised machine learning using traffic data, but is not limited to this. For example, the traffic analysis device 10 may be configured to receive manual input of device type information (information indicating the relationship between the IoT device 30 and the device type) for the IoT device 30 from an operator each time a new IoT device 30 is connected to the monitored network N1. While the device type determination unit 105 may make erroneous detections when determining device type using a machine learning device, receiving manual input of device type information as described above allows for reliable recognition of device type.

(F-2) In each of the above embodiments, the device type determination model in the device type determination unit 105 uses a machine learning machine that classifies the device into one of several types, including unknown device types. However, this is not limited to this. For example, the device type determination unit 105 may aggregate traffic data by device type and construct a binary classifier that outputs whether the device is of that type. In this case, the device type determination unit 105 sequentially applies the binary classifiers for each device type to determine the device type. For example, if the device type determination unit 105 determines the device type using multiple binary classifiers for device types (e.g., if the binary classifier outputs a probability value indicating the device type), the device type determination unit 105 may use the binary classifier with the largest value as the determination result. Furthermore, for example, the device type determination unit 105 may determine the device type as unknown if the probability value in all binary classifiers is below a certain value. When the device type determination unit 105 applies the determination methods described in the above embodiments, it is necessary to reconstruct the entire determination model when learning a new, unknown device type. However, with the determination method of the above modified example, it is only necessary to construct a machine learning machine for only the new device type, thereby reducing the time required for learning.

(F-3) In the above embodiments, a single detection model is constructed as a device-specific unsteady communication detection model by aggregating the traffic data of the unique communication patterns of all IoT devices 30, but this is not limited to this. For example, the steady communication pattern learning unit 103 may apply a method of constructing a device-specific unsteady communication detection model for each IoT device 30. In this case, the steady communication pattern learning unit 103 needs to learn the steady communication patterns of IoT devices 30 that are newly connected during operation mode. However, because communication patterns common to the device-type-specific unsteady communication detection model and the vendor-specific unsteady communication detection model have already been learned, it is possible to shorten the time required to learn a device-specific unsteady communication detection model for each IoT device 30, while also improving detection accuracy.

(F-4) In the traffic analysis device 10A of the second embodiment, a method for reconstructing a device-specific unsteady communication detection model using sequential machine learning on traffic data that has received false positive feedback has been described. However, this is not limiting. For example, the traffic analysis device 10A may store specific field values of traffic data that has received false positive feedback as a whitelist, and the unsteady communication state determination unit 104 may prevent traffic data included in the whitelist from being detected as an anomaly. In this method, for example, when an operator OP checks traffic data on a management screen (feedback input reception screen) and provides false positive feedback, the operator OP may create a whitelist by notifying the operator of the cause of the false positive, such as the destination IP address, TCP port number, or specific words in the payload. By applying the above-described whitelist-type processing on the feedback input reception screen, it is possible to reliably prevent traffic data related to false positive feedback from being detected as an anomaly in the future. Furthermore, even in a configuration that does not have the steady communication pattern learning unit 103, such as the traffic analysis device 10B of the third embodiment, false positives due to false positive feedback can be suppressed by applying the above-described whitelist-type processing.

(F-5) In the above embodiments, the vendor information determination unit 106 acquires vendor information by querying the Internet for the vendor code (OUI) of the MAC address, but this is not limited to this method. For example, the vendor information determination unit 106 may store a combination of MAC address and vendor in advance in the traffic analysis device, and acquire vendor information for each IoT device 30 by referencing the stored information. This method allows the traffic analysis device 10 to retain vendor information without connecting to the Internet N2, making it usable even in closed environments where Internet connectivity is unavailable.

10...traffic analysis device, 101...processing unit, 102...traffic data collection unit, 103...steady communication pattern learning unit, 104...unsteady communication state determination unit, 105...device type determination unit, 106...vendor information determination unit, 107...communication control unit, 108...storage unit, 20...network switch, 40...gateway, 30 (30-1 to 30-N)...IoT device, N1...monitored network, N2...Internet.

Claims (8)

an unsteady communication determination model holding means for holding an unsteady communication determination model that uses a learning model that has been machine-learned to learn traffic data patterns in a steady communication state for each attribute of a communication device connected to a target network to determine whether the communication device is in an unsteady communication state from the traffic data of the communication device;
attribute recognition means for recognizing attributes of each of the communication devices;
an unsteady communication determination means for performing an unsteady communication determination process using the unsteady communication determination model to determine whether or not the communication device is in an unsteady communication state from traffic data of the communication device;
the non-steady communication determination model holding means holds learning traffic data from each of the communication devices, divides the held learning traffic data into flows, classifies each of the flows into the attributes, and performs machine learning to build and hold the non-steady communication determination model for each of the attributes;
the non-steady communication determination model holding means holds a device type-specific non-steady communication determination model that determines whether the communication device is in a non-steady communication state from the traffic data of the communication device using a learning model that has been machine-learned based on a traffic data pattern in a steady communication state for each device type of the communication device;
the unsteady communication determination means performs the unsteady communication determination process using at least the device type-specific unsteady communication determination model;
the unsteady communication determination model holding means holds an unsteady communication determination model for each manufacturer of the communication devices, which determines whether the communication devices are in an unsteady communication state from the traffic data of the communication devices, using a learning model that has been machine-learned based on a pattern of traffic data in a steady communication state for each manufacturer of the communication devices;
The unsteady communication determination means further performs the unsteady communication determination process using the unsteady communication determination model by manufacturer.
A traffic analysis device characterized by: 2. The traffic analysis device according to claim 1, wherein the non-steady communication determination model holding means classifies the flows divided from the learning traffic data by device type, groups the flows with similar characteristics, performs a first extraction process to extract groups including the flows of device types equal to or greater than a first criterion, and constructs the non-steady communication determination model by device type using the flows of the groups extracted by the first extraction process. 3. The traffic analysis device according to claim 2, wherein the non-steady communication determination model holding means performs a second extraction process to classify the flows not extracted by the first extraction process from the learning traffic data by manufacturer, group the flows with similar characteristics, and extract groups including flows from at least a second criterion or more of manufacturers, and constructs the non-steady communication determination model by manufacturer using the flows of the groups extracted by the second extraction process. the unsteady communication determination model holding means further constructs and holds a device-specific unsteady communication determination model that determines whether the communication device is in an unsteady communication state from traffic data of the communication device, using a learning model that has been machine-learned from the flows that were not extracted in either the first extraction process or the second extraction process;
The traffic analysis device according to claim 3 , wherein the unsteady communication determination means performs the unsteady communication determination process by further using the device-specific unsteady communication determination model. 5. The traffic analysis device according to claim 4, wherein the unsteady communication determination model holding means adjusts the first criterion and/or the second criterion and repeats the first extraction process and the second extraction process again until a flow unextraction rate indicating a ratio of the number of unextracted flows not extracted in the first extraction process and the second extraction process to the number of flows in the entire traffic data for learning becomes equal to or less than a target value, and when the flow unextraction rate becomes equal to or less than the target value, constructs the device-type-specific unsteady communication determination model using the flows of the group extracted in the first extraction process, and when the flow unextraction rate becomes equal to or less than the target value, constructs the manufacturer-specific unsteady communication determination model using the flows of the group extracted in the second extraction process. a feedback receiving unit configured to receive feedback information relating to a result of the unsteady communication determination process performed by the unsteady communication determining unit;
6. The traffic analysis device according to claim 1 , wherein the non-steady communication determination model holding means builds and holds the non-steady communication determination model in consideration of the feedback information. Computer,
an unsteady communication determination model holding means for holding an unsteady communication determination model that uses a learning model that has been machine-learned to learn traffic data patterns in a steady communication state for each attribute of a communication device connected to a target network to determine whether the communication device is in an unsteady communication state from the traffic data of the communication device;
attribute recognition means for recognizing attributes of each of the communication devices;
using the unsteady communication determination model, and causing the communication device to function as unsteady communication determination means for performing unsteady communication determination processing to determine whether or not the communication device is in an unsteady communication state from traffic data of the communication device;
the non-steady communication determination model holding means holds learning traffic data from each of the communication devices, divides the held learning traffic data into flows, classifies each of the flows into the attributes, and performs machine learning to build and hold the non-steady communication determination model for each of the attributes;
the non-steady communication determination model holding means holds a device type-specific non-steady communication determination model that determines whether the communication device is in a non-steady communication state from the traffic data of the communication device using a learning model that has been machine-learned based on a traffic data pattern in a steady communication state for each device type of the communication device;
the unsteady communication determination means performs the unsteady communication determination process using at least the device type-specific unsteady communication determination model;
the unsteady communication determination model holding means holds an unsteady communication determination model for each manufacturer of the communication devices, which determines whether the communication devices are in an unsteady communication state from the traffic data of the communication devices, using a learning model that has been machine-learned based on a pattern of traffic data in a steady communication state for each manufacturer of the communication devices;
The unsteady communication determination means further performs the unsteady communication determination process using the unsteady communication determination model by manufacturer.
A traffic analysis program characterized by: A traffic analysis method performed by a traffic analysis device,
the traffic analysis device comprises an unsteady communication determination model storage means, an attribute recognition means, and an unsteady communication determination means;
the non-steady communication determination model holding means holds a non-steady communication determination model that uses a learning model that has machine-learned traffic data patterns in a steady communication state for each attribute of a communication device connected to a target network to determine whether the communication device is in a non-steady communication state from the traffic data of the communication device;
the attribute recognition means recognizes the attributes of each of the communication devices;
the unsteady communication determination means performs unsteady communication determination processing to determine whether the communication device is in an unsteady communication state from traffic data of the communication device using the unsteady communication determination model;
the non-steady communication determination model holding means holds learning traffic data from each of the communication devices, divides the held learning traffic data into flows, classifies each of the flows into the attributes, and performs machine learning to build and hold the non-steady communication determination model for each of the attributes;
the non-steady communication determination model holding means holds a device type-specific non-steady communication determination model that determines whether the communication device is in a non-steady communication state from the traffic data of the communication device using a learning model that has been machine-learned based on a traffic data pattern in a steady communication state for each device type of the communication device;
the unsteady communication determination means performs the unsteady communication determination process using at least the device type-specific unsteady communication determination model;
the unsteady communication determination model holding means holds an unsteady communication determination model for each manufacturer of the communication devices, which determines whether the communication devices are in an unsteady communication state from the traffic data of the communication devices, using a learning model that has been machine-learned based on a pattern of traffic data in a steady communication state for each manufacturer of the communication devices;
The unsteady communication determination means further performs the unsteady communication determination process using the unsteady communication determination model by manufacturer.
A traffic analysis method comprising: