JP2023106103A - Traffic analysis apparatus, traffic analysis program, and traffic analysis method - Google Patents

Abstract

An object of the present invention is to suppress erroneous detection when detecting an abnormality in a communication device using a machine-learned model of a communication pattern, and to suppress processing required for introduction when a new communication device is detected.
SOLUTION: The present invention relates to a traffic analysis device. Then, the traffic analysis apparatus of the present invention uses a learning model obtained by machine-learning a pattern of traffic data in a steady communication state for each attribute of a communication device connected to the target network, and determines whether the communication device Non-stationary communication decision model holding means for holding a non-stationary communication decision model for deciding whether or not it is in a steady communication state, attribute recognition means for recognizing the attributes of each communication device, and the non-stationary communication decision model a non-stationary communication determination means for performing non-stationary communication determination processing for determining whether or not the communication device is in a non-stationary communication state from the traffic data of the communication device.
[Selection diagram] Fig. 1

Description

The present 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 state of IoT devices connected to the Internet based on traffic data when these IoT devices communicate.

IoT devices have been used in various environments such as homes, offices, and factories. However, in many cases, IoT devices cannot take sufficient security measures, or do not take sufficient security measures, compared to conventional communication devices such as PCs. For example, since IoT devices have limited computational resources, it may not be possible to introduce agent-type security countermeasure products. In addition, in the case of IoT devices that are used without human intervention, the software may not be updated for a long period of time and may have vulnerabilities.

As a security measure for such IoT devices, a device that collects and analyzes traffic is installed on the connection path from the IoT device to the Internet, and an NDR (Network (Detection and Response). NDR does not require a security agent to be installed in the device, so it is useful for monitoring devices such as IoT devices that lack computing resources and cannot be introduced with agent-type security measures. In addition, internal criminal acts such as connecting unauthorized devices to the edge network and stealing confidential information from other legitimate devices may not be detected by the firewall or proxy server of the backbone network, but NDR is the connection point of the edge network. Such fraud can be detected by installing an analysis device in

Conventionally, one of the methods of detecting anomalies with NDR is an unsupervised machine that learns the normal communication patterns of devices in the monitored network and detects anomalies when there is communication that deviates from the normal communication pattern. There is a way to use learning. Unsupervised machine learning detects any unusual communication pattern as an anomaly, so even unknown attacks can be detected. On the other hand, even if it is legitimate communication, it may be misdetected as abnormal when it is used in a way that is different from usual, and the number of false positives is large. In addition, when a new device is added to the network during operation, it is necessary to learn the regular communication pattern of the new device, and the problem is that it takes time to detect anomalies after the new connection.

In Patent Document 1, FAN (Field Area Network) devices connected to a gateway device are monitored, normal values of control messages, sensor data, statistical data, etc. are learned for each device, and abnormal values are detected when deviations from the normal values are made. A detection system is described. In the system described in Patent Document 1, in order to suppress erroneous detection, the inspection server further analyzes the communication data for the communication in which an abnormality is detected, confirms whether there is a problem, and finally determines whether it is abnormal. It is designed to

In Patent Document 2, an IoT device connected to a terminal such as a smartphone is targeted for monitoring, normal communication patterns are learned by statistical processing or machine learning for each application of the IoT device, and the communication pattern of the application is a normal communication pattern. A system for detecting anomalies when deviating from is described. In the system described in Patent Document 2, control information is exchanged between multiple smartphones to update normal communication patterns, and applications that are determined to be unable to learn regular communication patterns are excluded from detection targets, thereby preventing false detections. It corresponds to the processing to suppress.

JP 2017-163179 A JP 2020-135655 A

However, in the system described in Patent Document 1, it is necessary to learn the normal communication pattern of the device when connecting a new device (when connecting a new communication device), and it takes time to be able to detect anomalies. Further, in the system described in Patent Document 1, sensor data values and the like are used for anomaly detection, and there are situations where encrypted communication cannot be applied. Furthermore, in the system described in Patent Literature 2, when a new device is connected, it is necessary to learn the normal communication pattern of the application used by the device, and it takes time to be able to detect anomalies. Furthermore, the system described in Patent Literature 2 can only detect anomalies in communication of registered applications, and therefore cannot detect anomalous communications unrelated to applications that occur, for example, when a device is infected with malware.

In view of the above problems, when detecting anomalies in communication devices using a machine-learned model of communication patterns, it is possible to reduce false detections and the processing required to introduce new communication devices. What is desired is a traffic analysis apparatus, a traffic analysis program and a traffic analysis method that can

A traffic analysis apparatus according to a first aspect of the present invention uses a learning model obtained by machine-learning a pattern of traffic data in a steady communication state for each attribute of a communication device connected to a target network, and analyzes the communication data from the traffic data of the communication device. non-stationary communication determination model holding means for holding a non-stationary communication determination model for determining whether or not a device is in a non-stationary communication state; attribute recognition means for recognizing attributes of each of said communication devices; and said non-stationary communication non-stationary communication determination means for performing non-stationary communication determination processing for determining whether or not the communication device is in a non-stationary communication state from traffic data of the communication device using a determination model. .

A traffic analysis program according to a second aspect of the present invention uses a learning model obtained by machine-learning traffic data patterns in a steady communication state for each attribute of a communication device connected to a target network to analyze the traffic data of the communication device. non-stationary communication determination model holding means for holding a non-stationary communication judgment model for judging whether the communication device is in the non-stationary communication state from the Using a non-stationary communication decision model, from the traffic data of the communication device, to function as a non-stationary communication decision means for performing non-stationary communication decision processing to decide whether the communication device is in the non-stationary communication state. Characterized by

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-steady communication determination model holding means, attribute recognition means, and non-steady communication determination means, and the non-steady communication The determination model holding means uses a learning model obtained by machine-learning a pattern of traffic data in a steady communication state for each attribute of the communication device connected to the target network, and determines whether the communication device is in non-steady communication from the traffic data of the communication device. a non-stationary communication determination model for determining whether or not the communication device is in a state of and performing non-steady communication determination processing for determining whether or not the communication device is in a non-steady communication state from the traffic data of the communication device.

According to the present invention, when an abnormality in a communication device is detected using a machine-learned model of a communication pattern, it is possible to suppress erroneous detection and also suppress processing required for introduction when a new communication device is detected. can.

1 is a block diagram showing the functional configuration of a traffic analysis device according to a first embodiment; FIG. FIG. 3 is a block diagram showing a connection configuration of devices related to the first to fifth embodiments; FIG. 7 is a flowchart showing processing for constructing a non-stationary communication detection model by device type according to the first embodiment; FIG. FIG. 7 is a diagram (image diagram) showing processing for extracting a flow to be learned when constructing a non-stationary communication detection model by device type according to the first embodiment; FIG. 9 is a flowchart showing processing for constructing a vendor-specific non-stationary communication detection model according to the first embodiment; FIG. FIG. 10 is a diagram (image diagram) showing processing for extracting a flow to be learned when constructing a vendor-specific non-stationary communication detection model according to the first embodiment; 7 is a flowchart showing processing for constructing a device-specific non-stationary communication detection model according to the first embodiment; 4 is a flow chart showing the operation of an unsteady communication state determination unit according to the first embodiment; 4 is a flowchart showing processing when the traffic analysis device according to the first embodiment operates in learning mode; 4 is a flowchart showing processing when the traffic analysis device according to the first embodiment operates in operation mode; 7 is a flowchart showing processing when the traffic analysis device according to the first embodiment operates in mixed mode; FIG. 9 is a block diagram showing the functional configuration of a traffic analysis device according to the second embodiment; FIG. FIG. 11 is a diagram (part 1) showing the configuration of a feedback input reception screen according to the second embodiment; FIG. 12 is a diagram (part 2) showing the configuration of a feedback input reception screen according to the second embodiment; FIG. 12 is a block diagram showing the functional configuration of a traffic analysis device according to the third embodiment; FIG. FIG. 12 is a block diagram showing the functional configuration of a traffic analysis device according to the fourth embodiment; FIG. FIG. 12 is a block diagram showing the functional configuration of a traffic analysis device according to the fifth embodiment; FIG. FIG. 16 is a flowchart showing processing for extracting a flow to be learned when constructing an unsteady communication detection model in the fifth embodiment; FIG.

(A) First Embodiment Hereinafter, 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 with reference to the drawings.

(A-1) Configuration of First Embodiment FIG. 2 is a diagram showing the connection relationship of each device related to the first embodiment. Symbols in parentheses in FIG. 2 are symbols used in second to fifth embodiments described later.

Here, the traffic analysis device 10, from the IoT devices 30 (30-1, 30-2, . It is assumed that the processing to analyze the generated traffic is performed. In the configuration example of FIG. 2, it is assumed that a network switch 20 (layer 2 switch) and a gateway 40 (for example, a gateway corresponding to a firewall function) are arranged as network devices in the monitored network N1. The communication device connected to the monitored network N1 is not limited to the IoT device, and may be various devices.

In the configuration example of FIG. 2, each IoT device 30 is connected to a network switch 20 (layer 2 switch), and a gateway 40 having a firewall function is connected between the network switch 20 and the Internet N2. Therefore, in the example of FIG. 2, each IoT device 30 is in a state capable of communicating with the Internet N2 via the network switch 20 and the gateway 40. FIG. Also, the number of IoT devices 30 and the like connected to the network switch 20 is not limited, and the 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 basically performs its function by communicating with a communication device (for example, a server that receives data from the IoT device 30, a terminal that accesses the IoT device 30, etc.) on the Internet N2. described as.

In the example of FIG. 2, the traffic analysis device 10 is assumed to be connected to the network switch 20 . Here, in the network switch 20, packets (Ethernet frames) transmitted and received by the LAN port (Ethernet (registered trademark) port) connected to the gateway 40 are mirrored to the port connected to the traffic analysis device 10 (so-called port mirror connection). As a result, the traffic analysis device 10 can collect traffic (packets) flowing between the connection terminal (the IoT device 30) under the control of the network switch 20 and the Internet N2. In this embodiment, data based on traffic flowing between the IoT device 30 and the Internet N2 (hereinafter simply referred to as "traffic data") is supplied to the traffic analysis device 10 by port mirror setting of the network switch 20. 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 analyzes each connection terminal (including the IoT device 30) based on traffic data.

Here, an overview of the traffic analysis device 10 will be described.

In general, many IoT devices mainly provide one function (hereinafter referred to as "main function"). For example, an IoT device equipped with a network camera function supports the function of capturing a target area and streaming it to a remote PC terminal or the like. Also, for example, if it is an IoT device such as a smart power tap, it corresponds to the function of remotely turning ON/OFF the switch. In other words, in general, IoT devices have similar main regular communication patterns (hereinafter referred to as “steady communication patterns”) for each type (hereinafter referred to as “device type”) according to their main functions. It is thought that there are many things to do.

Therefore, by learning a regular communication pattern for each device type, it is possible to construct a learning model that reflects the communication pattern during operation of the main function provided by the device type. Therefore, in the traffic analysis device 10, even if an IoT device (hereinafter referred to as a "newly connected device") newly connected to the monitored network N1 (here, the network switch 20), the normal time of the newly connected device By comparing the communication pattern of the new connection device with the regular communication pattern of the device type of the new connection device (for example, the communication pattern when the main function is in operation), the non-steady communication state of the new connection device (communication different from the regular communication pattern) state in which a pattern occurs) can be detected. Hereinafter, the non-stationary communication state of the IoT device 30 is also simply referred to as "abnormal state". In other words, the traffic analysis device 10 regards the IoT device 30 determined to be in an irregular communication state as being in an abnormal state.

In general, many IoT devices perform vendor (manufacturer)-specific control communication. For example, there are IoT devices of a certain vendor that generally perform time synchronization using NTP (Network Time Protocol) at predetermined time intervals or communicate with a cloud server owned by the vendor. In other words, it is generally considered that many IoT devices have similar regular communication patterns of control communication for each vendor. Therefore, by learning regular communication patterns for each vendor of IoT devices, it is possible to build a learning model that reflects vendor-specific communication patterns. Therefore, the traffic analysis device 10 can detect an unsteady communication state even for a newly connected device by comparing it with the steady communication pattern of the vendor of the newly connected device.

In other words, in the traffic analysis device 10, even a newly connected device (communication device newly monitored/analyzed) can be compared with regular communication patterns for each attribute (for example, device type, vendor, etc.). , it is possible to determine (detect) an unsteady communication state. Specifically, in the traffic analysis device 10 of this embodiment, a model (hereinafter referred to as "non-stationary communication detection model ”) is constructed and stored, traffic data acquired during operation is classified for each IoT device 30 (for example, classified by source/destination IP address), and corresponding to the IoT device 30 Applying the non-steady communication detection model, the state of the IoT device 30 is determined (for example, whether or not it is in the non-steady communication state (abnormal state)).

The traffic analysis device 10 of this embodiment utilizes the characteristics of the communication of each IoT device 30, and aggregates traffic for each device type (for example, network camera, smart speaker, smart plug unit) as an attribute to generate a steady communication pattern. is learned, and a model for judging (detecting) a steady communication state/non-steady communication state (hereinafter also referred to as "non-steady communication detection model by device type") is constructed and stored. In addition, when constructing the non-stationary communication detection model by device type, the traffic analysis device 10 collects traffic for each vendor as an attribute and learns a steady communication pattern for a traffic pattern whose accuracy at the time of learning is low. A model for judging (detecting) a steady communication state/unsteady communication state (hereinafter referred to as "unsteady communication detection model by vendor") shall be constructed and retained.

The traffic analysis device 10 first determines whether each IoT device 30 is in a non-steady communication state based on whether or not it is in a non-steady communication state using the non-steady communication detection model by device type. Then, the traffic analysis apparatus 10 further determines whether the IoT device determined to be in the non-steady communication state based on the non-steady communication detection model by device type is in the non-steady communication state based on the non-steady communication detection model by vendor. If the IoT device is also determined to be in an unsteady communication state, an abnormality is detected (detected as being in an abnormal state).

As described above, the traffic analysis device 10 performs determination processing using the device-type-specific non-stationary communication detection model and the vendor-specific non-stationary communication detection model. Even so, if the device type and vendor of the IoT device 30 are known, it is possible to detect the non-steady communication state, so it is possible to shorten the period for learning the steady communication state.

Furthermore, in the traffic analysis apparatus 10 of this embodiment, in addition to the above, the traffic patterns (that is, device-specific communication patterns) whose accuracy was low even when the vendor-specific non-steady communication detection model was learned are collectively learned as steady communication patterns. A non-stationary communication detection model (hereinafter referred to as "device-specific non-stationary communication detection model") shall be constructed and retained. Then, in the traffic analysis apparatus 10, the device-specific non-steady communication pattern for which the non-steady communication state could not be detected in any of the determination processing using the non-steady communication detection model by device type and the non-steady communication detection model by vendor. It is assumed that the steady communication detection model determines whether or not the communication state is in the non-steady state, and detects the non-steady state (abnormal state) when the state is determined to be the non-steady state.

In order to realize the determination process as described above, the traffic analysis device 10 (mainly the processing unit 101) of this embodiment shall operate in one of the following three operation modes.

When the traffic analysis device 10 operates in a first operation mode (hereinafter also referred to as a “learning mode”), the traffic analysis device 10 collects and learns traffic data of steady communication patterns of the IoT devices 30 connected to the monitored network N1. Processing is performed to construct each non-stationary communication state detection model (non-stationary communication detection model by device type, non-stationary communication detection model by vendor, and device-specific non-stationary communication detection model).

When operating in a second operation mode (hereinafter also referred to as an "operation mode"), the traffic analysis device 10 acquires traffic data from the monitored network N1 in real time, and detects each irregular communication state for each IoT device 30. A model is used to perform processing for determining whether or not there is an unsteady communication state (abnormal state).

When the traffic analysis device 10 detects an unknown device type or vendor IoT device 30 while operating in the operational mode, the traffic analysis device 10 detects the device type or vendor of the unknown IoT device 30 in parallel with the operation in the operational mode. It is also possible to operate in an operation mode (hereinafter referred to as "mixed mode") in which steady communication patterns are learned for vendors and an unsteady communication state detection model is constructed.

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

FIG. 1 is a block diagram showing the functional configuration of the traffic analysis device 10. As shown in FIG.

As shown in FIG. 1, the traffic analysis device 10 includes a processing unit 101, a traffic data collection unit 102, a regular communication pattern learning unit 103, an unsteady communication state determination unit 104, a device type determination unit 105, a vendor information determination unit 106, It has a communication control unit 107 and a storage unit 108 .

The traffic analysis device 10 can be realized by, for example, 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 a function of controlling the overall processing of the traffic analysis device 10 . The processing unit 101 also performs recording processing for recording data notified from other elements, and processing for reading and notifying (outputting) data requested from other elements.
[Configuration of Storage Unit 108]
The storage unit 108 is 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 collector 102 captures traffic data (Ethernet frame or IP packet data) from the network switch 20, analyzes the captured content, converts it into an IP packet format, and outputs it. The traffic data collection unit 102 collects additional information such as Ethernet frame information (for example, source/destination MAC addresses, etc.) and time stamps (for example, the time when the frame/packet was captured), which is the source of traffic data to be output. may be added as The traffic data collection unit 102 notifies (outputs) IP packet format traffic data to the processing unit 101 .

When the processing unit 101 receives traffic data (IP packet data) from the traffic data collection unit 102, the processing unit 101 instructs the device type determination unit 105 to determine the device type of the IoT device 30 related to the source or destination of the received traffic data. Make a request and get the judgment result.

Further, when the processing unit 101 receives traffic data from the traffic data collection unit 102, the processing unit 101 requests the vendor information determination unit 106 to determine vendor information indicating the vendor of the IoT device 30 related to the transmission source or destination of the received traffic data. to obtain the judgment result.

Further, when operating in the learning mode, the processing unit 101 requests the steady communication pattern learning unit 103 to learn the steady communication pattern, and obtains the result. When operating in the operation mode, the processing unit 101 requests the abnormal communication state determination unit 104 to make an abnormality determination, and obtains the result.

Furthermore, when the processing unit 101 is operating in the mixed mode, upon receiving the traffic data of the type of device/vendor being learned, the processing unit 101 requests the regular communication pattern learning unit 103 to perform learning using the traffic data. When traffic data of a device type/vendor that is not medium is received, the non-steady communication state determination unit 104 is requested to perform abnormality determination processing using the traffic data, and the result is obtained.

Furthermore, the processing unit 101 may perform any action according to the determination result of the unsteady communication state determination unit 104 while operating in the operational mode or the mixed mode. For example, the processing unit 101 requests the communication control unit 107 to cut off communication with the IoT device 30 for which an abnormality is detected by the non-steady communication state determination unit 104, or notifies the abnormality detection using various communication methods (e.g., electronic communication). It may be transmitted and output as either an e-mail or a telegram (message) of a predetermined method.

Furthermore, the processing unit 101 collects 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”), and the vendor (manufacturer) of each IoT device 30. information (hereinafter referred to as "vendor information"), non-steady communication detection model by device type for each device type, non-steady communication detection model by vendor for each vendor, and device-specific non-steady communication detection model are stored in the storage unit. 108 and acquires the saved information from the storage 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.

For example, the device type determination unit 105 classifies traffic data for each device type and learns regular communication patterns using a machine learning device or the like, thereby forming a model for determining the device type corresponding to the traffic data (hereinafter referred to as “device type determination model"), and the device type corresponding to the input traffic data may be determined based on the retained device type determination model. When operating in the learning mode, the device type determination unit 105 holds in advance device type data for each IoT device 30 (for example, data in which the device type is associated with the IP address of each IoT device 30) (for example, operator The input may be manually received and held by, for example. Then, when operating in the learning mode, the device type determination unit 105 classifies the traffic data for each device type, and the classified traffic data (data composed of a plurality of IP packet sequences) of each device type is transmitted. A device type determination model may be constructed by converting into a feature quantity indicating a pattern and having a machine learning device learn. Although the format of the feature quantity indicating the communication pattern is not limited, for example, statistical values based on traffic data such as the size of each IP packet that constitutes the traffic data, packet arrival interval, etc., port number (TCP or UDP Service information (for example, HTTP for TCP number 80, TELNET for TCP number 23, etc.) estimated from the port number) may be applied. That is, the device type determination unit 105 supplies training data (device type data for each IoT device 30 and traffic data acquired when operating in the learning mode) to the machine learning device to perform learning processing. A device type determination model can be acquired.

Note that the device type determination unit 105 may retain the device type determination model through the above-described processing when operating in the learning mode, or may store the device type determination model in advance. Here, the device type determination model may be configured to output a determination result indicating that the device type is an unknown device type when a communication pattern that is not similar to any of the learned communication patterns of the device type is input. For example, when classifying traffic data during learning, the device type determination unit 105 learns by classifying the traffic data into a class of known device type + 1 (+1 is a class representing an unknown device type). The device type determination model may be configured such that if the probability of being 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 together with the traffic data, the device type determination unit 105 determines the device type based on the traffic data. including) is notified to the processing unit 101 .

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 device type information in the storage unit 108 . Although the specific format of the device type information is not limited, for example, the identifier of the IoT device 30 (eg, IP address, host name, arbitrary ID number, etc.) is combined with the identifier of the device type (eg, , ID number, etc.).
[Configuration of Vendor Information Determination Unit 106]
The vendor information determination unit 106 has a function of determining the vendor (manufacturer) of the IoT device 30 corresponding to the traffic data from the traffic data.

A unique MAC address is assigned to a communication device that supports Ethernet, and the first half of the MAC address (for example, the first to third octets) is usually composed of a so-called vendor code (OUI: Organizationally Unique Identifier). It is Therefore, the vendor information determination unit 106 acquires the MAC address of the source/destination IoT device 30 for each traffic data (traffic data to which the MAC address of the corresponding IoT device 30 is added), and from the acquired MAC address By extracting the vendor code, the vendor of the IoT device 30 corresponding to the traffic data can be determined.

For example, the vendor information judging unit 106 can search a site on the Internet N2 for a vendor identifier (eg, vendor name, etc.) corresponding to the vendor code acquired from the traffic data (eg, vendor code, identifier such as vendor name) site) to check. Further, for example, the vendor information determining unit 106 may hold information in which vendor codes and vendor identifiers are associated in advance, and may confirm the vendor name corresponding to the extracted vendor code.

As described above, when the processing unit 101 requests the vendor information determination unit 106 to determine a vendor together with traffic data (traffic data to which the MAC address of the corresponding IoT device 30 is added), the vendor information determination unit 106 responds to the traffic data. The identifier of the vendor (for example, the vendor name) is obtained, and the processing unit 101 is notified of the result.

The processing unit 101 recognizes the vendor for 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 . Although the specific format of the vendor information is not limited, for example, the identifier of the IoT device 30 (eg, IP address, host name, arbitrary ID number, etc.) corresponds to the identifier of the vendor (eg, vendor name, etc.). It may be the attached information.
[Configuration of regular communication pattern learning unit 103]
The steady communication pattern learning unit 103 has a function of constructing each non-steady communication detection model (non-steady communication detection model by device type, non-steady communication detection model by vendor, and device-specific non-steady communication detection model) from traffic data. I am in charge. When the regular communication pattern learning unit 103 receives a request from the processing unit 101 together with the traffic data, it constructs various non-regular communication detection models and notifies the processing unit 101 of completion.

Next, the process of constructing the device type non-steady communication detection model by the steady communication pattern learning unit 103 will be described.

FIG. 3 is a flow chart showing the flow of processing for constructing the non-stationary communication detection model for each device type.

The regular communication pattern learning unit 103 classifies traffic data (traffic data supplied from the processing unit 101) collected while operating in the learning mode into flow units (for example, source IP address, source port number, destination IP (S101).

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

Next, the regular communication pattern learning unit 103 calculates and acquires a feature amount (statistical feature amount) based on traffic data for each flow (S103). Although the format of the feature quantity acquired by the regular communication pattern learning unit 103 is not limited, for example, statistical values based on traffic data such as the size of each IP packet constituting each flow (traffic data), packet arrival interval, etc. , service information estimated from the port number (TCP or UDP port number) (for example, HTTP for TCP number 80, TELNET for TCP number 23, etc.) or the like may be applied.

Next, the regular communication pattern learning unit 103 performs a process of grouping flows having similar feature amounts (S104). Although the method of grouping performed by the regular communication pattern learning unit 103 is not limited, for example, a method of mechanically grouping by a clustering algorithm such as k-means or DBSCAN can be applied.

Next, the steady communication pattern learning unit 103 confirms the device type corresponding to the IoT device 30 of the flow belonging to each group, and based on the result, extracts the group used for learning the non-steady communication detection model by device type. (S105).

FIG. 4 is a diagram (image diagram) showing the process of grouping the flow (flow used for learning the non-stationary communication detection model by device type) in step S105.

In FIG. 4, in order to simplify the explanation, flows of arbitrary device types A, B, and C are represented by circular, triangular, and square symbols, respectively, and each symbol is mapped to a position corresponding to the feature amount of the flow. there is In other words, FIG. 4 visually shows that symbol flows having close distances have close feature amounts. In FIG. 4, five symbols related to the device type A flow, two symbols related to the device type B flow, and seven symbols related to the device type C flow are illustrated. In FIG. 4, as a result of grouping symbols whose distance is equal to or less than a predetermined distance, the symbols are divided into three groups G1 to G3 (groups surrounded by dashed lines).

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

Here, the regular communication pattern learning unit 103 extracts each flow of a group that includes all target device types assuming that it constitutes a common communication pattern, and extracts the device type using a machine learning device. It shall be used for constructing another non-stationary communication detection model.

In FIG. 4, groups G1 and G2 include flows of all target device types (device types A, B, and C), and group G3 includes only flows of device types A and B. Flows for device type C are not included. Therefore, in this case, the regular communication pattern learning unit 103 extracts the flows of groups G1 and G2 as learning targets, and does not extract the flows of group G3 as learning targets.

Next, the regular communication pattern learning unit 103 converts the extracted traffic data of each flow into a feature quantity to be input to the machine learning device and acquires it (S106). A detection model is constructed using a machine learning device (S107).

Here, the format of the feature quantity indicating the communication pattern of each flow is not limited, but for example, statistical values based on traffic data such as the size of each IP packet that constitutes the traffic data, packet arrival interval, etc., port Service information (for example, HTTP for TCP number 80, TELNET for TCP number 23, etc.) estimated from the number (TCP or UDP port number) may be applied.

The regular communication pattern learning unit 103 may, for example, input the feature values of N packets from the beginning of the flow into a machine learning device, and construct a learning model that predicts the feature value of the (N+1)th packet. . Also, at this time, the steady communication pattern learning unit 103 makes the machine learning machine learn while shifting the head of the flow by M packets (M is an integer equal to or greater than 1), thereby modeling more communication patterns as steady communication patterns. may be reflected in The machine learning device used in the regular communication pattern learning unit 103 is also not limited, but for example, an RNN (Recurrent Neural Network) can be applied.

Through the above-described processing, the processing unit 101 uses the regular communication pattern learning unit 103 to acquire the non-steady communication detection model by device type for each device type, and stores it in the storage unit 108 .

Next, a process of constructing a vendor-specific non-steady-state communication detection model by the steady-state communication pattern learning unit 103 will be described.

FIG. 5 is a flowchart showing the flow of processing for constructing a vendor-specific non-stationary communication detection model.

While operating in the learning mode, the regular communication pattern learning unit 103 builds a vendor-specific non-regular communication detection model by executing the process of the flowchart in FIG. 5 following step S107.

First, the regular communication pattern learning unit 103 acquires the data (traffic data) of the flow that was not used for constructing the learning model of the non-regular communication detection model by device type (the flow that was not extracted in step S105 described above). (S201).

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

Next, the regular communication pattern learning unit 103 calculates and acquires feature amounts based on the traffic data for each acquired flow (S203). At this time, the format of the feature quantity acquired by the regular communication pattern learning unit 103 is the same as in the case of the non-regular communication detection model by device type (step S103 described above), so detailed description thereof will be omitted.

Next, the regular communication pattern learning unit 103 performs processing for grouping flows having similar feature amounts (S204). At this time, the grouping process performed by the regular communication pattern learning unit 103 is the same as that for the non-regular communication detection model by device type (step S104 described above), so detailed description thereof will be omitted.

Next, the regular communication pattern learning unit 103 confirms the device type corresponding to the flow belonging to each group, and based on the result, extracts the group used for learning the vendor-specific non-regular communication detection model (S205).

The regular communication pattern learning unit 103 may, for example, extract a group composed only of flows belonging to the same vendor.

FIG. 6 is a diagram (image diagram) showing the process of grouping the flows (flows used for learning the vendor-specific non-stationary communication detection model) in step S205.

In FIG. 6, as in FIG. 4 described above, the flows of 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 feature amount of the flow. ing. Also, in FIG. 6, a symbol indicating a vendor related to the flow of the symbol is added inside the figure of each symbol. In FIG. 6, α, β, and γ are appended to each symbol as symbols representing vendors A, B, and C, respectively.

In FIG. 6, as a result of grouping symbols whose distance is equal to or less than a predetermined distance, the symbols are divided into two groups G1 and G2 (groups surrounded by dashed lines).

Here, the regular communication pattern learning unit 103 extracts each flow of a group composed only of flows belonging to the same vendor, regarding it as constituting a common communication pattern of the vendor, and uses the machine learning device to extract the flow. It shall be used to build the vendor-specific non-stationary communication detection model used.

In FIG. 6, in group G1, the vendor of all flows consists only of the flows of vendor A (a is added to the symbol). On the other hand, group G2 includes only flows of device types A and B, and two vendors A and B are mixed. Therefore, in this case, the regular communication pattern learning unit 103 extracts the flows of the group G1 as learning targets, and does not extract the flows of the group G2 as learning targets.

Next, the regular communication pattern learning unit 103 converts the extracted traffic data of each flow into feature values to be input to the machine learning device (S206), and uses the acquired feature values to detect unsteady communication by vendor. A model is constructed with a machine learning device (S207). The feature quantity extraction process and the process of creating the non-stationary communication model performed by the regular communication pattern learning unit 103 are the same as in the case of the non-stationary communication detection model by device type (above-mentioned steps S106 and S107), so a detailed explanation is omitted. do.

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

Next, a process of constructing a device-specific non-steady-state communication detection model by the steady-state communication pattern learning unit 103 will be described.

FIG. 7 is a flowchart showing the flow of processing for constructing a device-specific non-stationary communication detection model.

While operating in the learning mode, the regular communication pattern learning unit 103 builds a vendor-specific non-regular communication detection model by executing the process of the flowchart in FIG. 7 following step S207.

First, the steady communication pattern learning unit 103 selects flows that have not been used to build the learning model of the non-steady communication detection model by device type and the non-steady communication detection model by vendor (the the other flow) is acquired (S301).

Next, the regular communication pattern learning unit 103 converts the extracted traffic data of each flow into a feature amount to be input to the machine learning device (S302), and uses the acquired feature amount to detect device-specific non-stationary communication. A model is constructed with a machine learning device (S303). Here, the feature quantity extraction process and the process of creating the device-specific non-stationary communication detection model performed by the regular communication pattern learning unit 103 are the same as in the case of the non-stationary communication detection model by device type (above-mentioned steps S106 and S107). Therefore, detailed description is omitted.

Through the above processing, the processing unit 101 uses the regular communication pattern learning unit 103 to hold the device-specific non-stationary communication detection model and store it in the storage unit 108 .
[Configuration of Unsteady Communication State Determination Unit 104]
The unsteady communication state determination unit 104 has a function of determining whether or not each IoT device 30 is in an unsteady communication state using traffic data when operating in the operational mode or the mixed mode.

The non-steady communication state determination unit 104 receives from the processing unit 101 a process for determining whether or not the traffic data is in the non-steady communication state (hereinafter referred to as “non-steady communication state determination processing”, “abnormality determination processing” or “abnormal detection process"), the unsteady communication state determination process is started. When the non-steady communication state determination process is started, the non-steady communication state determination unit 104 sets the traffic data to each non-steady communication detection model (non-steady communication detection model by device type, non-steady communication detection model by vendor, and device-specific non-steady communication detection model). steady communication detection model), input the converted feature quantity to each non-steady communication detection model, and determine whether the IoT device 30 related to the traffic data is in the non-steady communication state. . The unsteady communication state determination unit 104 notifies the processing unit 101 of the determination result.

FIG. 8 is a flow chart showing the operation of the non-steady communication state determination processing performed by the non-steady communication state determination unit 104 .

When the non-steady communication state determination process is started, the non-steady communication state determination unit 104 converts the acquired traffic data into a feature quantity to be applied to each non-steady communication detection model (S401). Here, in the non-steady communication state determination unit 104, samples (feature amounts) obtained from an arbitrary IoT device 30 (hereinbelow, this IoT device 30 is referred to as a "device of interest") can be determined by each non-steady communication detection model. is assumed to be accumulated.

Next, the non-stationary communication state determination unit 104 applies the sample of the feature quantity acquired for the device of interest to the non-stationary communication detection model by device type corresponding to the device type of the device of interest (S402). It is determined whether it is in a state (whether it is abnormal) (S403). If the non-steady communication state determination unit 104 determines that the device of interest is in the steady communication state based on the non-steady communication detection model by device type, the process proceeds to step S409 to end the non-steady communication state determination process. If it is determined to be in an unsteady communication state, the process proceeds to step S404, which will be described later.

In step S403, when the non-steady communication state is determined, the non-steady communication state determination unit 104 applies the sample of the feature quantity acquired for the device of interest to the vendor-specific non-steady communication detection model corresponding to the vendor of the device of interest. (S404), it is determined whether or not it is in an unsteady communication state (whether or not there is an abnormality) (S405). If the non-steady communication state determination unit 104 determines that the device of interest is in the steady communication state based on the vendor-specific non-steady communication detection model, the process proceeds to step S409 to end the non-steady communication state determination process. If it is determined that the communication is in an unsteady state, the process proceeds to step S406, which will be described later.

In step S405, when the non-steady communication state is determined, the non-steady communication state determination unit 104 applies the sample of the feature amount acquired for the device of interest to the device-specific non-stationary communication detection model (S406). It is determined whether or not the communication state is normal (whether or not there is an abnormality) (S407). If the non-steady communication state determination unit 104 determines that the device of interest is in the steady communication state based on the device-specific non-steady communication detection model, the process proceeds to step S409 to end the non-steady communication state determination process. If it is determined to be in an unsteady communication state, the process proceeds to step S408, which will be described later.

When it is determined in step S407 that the non-steady communication state is determined, the non-steady communication state determining unit 104 finally determines that the device of interest is in the non-steady communication state (abnormal state) (S408). A result indicating that the device of interest is in an unsteady communication state (abnormal state) is output.

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

It should be noted that it is difficult to avoid erroneous detection 100% even when multistage determination is made using three non-stationary communication state detection models in the processing of the flowchart shown in FIG. Therefore, the non-steady communication state determination unit 104 immediately outputs an abnormality determination result (e.g., sending an alert) even if an abnormality is once detected in the above flowchart based on the traffic data at a certain point in time for the device of interest. After that, when the rate of anomaly detection reaches a certain level or higher (for example, when anomaly detection is repeated after that and the rate of anomaly detection among the number of judgments reaches or exceeds a certain level), the final decision is made. An abnormality determination may be output.
[Configuration of communication control unit 107]
The communication control unit 107 has a function of controlling communication related to the IoT device 30 determined to be in an abnormal state (unsteady communication state) by the unsteady communication state determination unit 104 based on the notification from the processing unit 101 . When the communication control unit 107 receives a request to cut off the communication of an IoT device 30 from the processing unit 101 , the communication control unit 107 may cut off the communication of 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 cuts off the communication of the device of interest is not limited. For example, in the case of the network configuration as shown in FIG. 1, the communication control unit 107 controls the gateway 40 (firewall policy management function) when it is determined that an IoT device 30 is in an abnormal state (unsteady communication state). , a configuration may be adopted in which a policy (rule) is added to block communication of the IoT device 30 (for example, communication regarding the IP address of the IoT device 30).

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

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

In the traffic analysis device 10 , the traffic data collection unit 102 supplied from the network switch 20 newly captures traffic data ( S<b>501 ), analyzes the captured content, shapes it into an IP packet, and notifies the processing unit 101 .

Next, the processing unit 101 confirms whether or not a period required for learning a steady communication pattern after the start of the learning mode (hereinafter referred to as a "steady learning period" has ended (S502). may determine that the stationary learning period has ended when a certain period of time has elapsed since the start of traffic data collection (start of learning mode operation), or when a certain amount of traffic data has been accumulated. (For example, when a certain number of IP packets are accumulated), the traffic analysis device 10 determines that the steady learning period has ended. If it is within the steady learning period, the operation starts from step S503, which will be described later.

If it is within the steady learning period, the processing unit 101 confirms the vendor information held by the storage unit 108, confirms whether there is vendor information of the IoT device 30 related to the latest received traffic data (S503), If the vendor information of the IoT device 30 is not held, the traffic data is notified to the vendor information determination unit 106 to request and acquire vendor information determination (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 (OUI forming 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 causes the storage unit 108 to store the vendor information received by the vendor information determination unit 106 .

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

If it is determined in step S502 that the steady learning period has ended, the processing unit 101 acquires the traffic data accumulated in the storage unit 108 during the steady learning period, and sends the device type determination model to the device type determination unit 105. Request construction (S506).

The device type determination unit 105 acquires correspondence information between devices and device types from the outside (for example, the administrator of the traffic analysis device) (for example, the traffic analysis device has an interface for inputting the correspondence information, and the administrator inputs there). do. The device type determination unit 105 converts the traffic data into a feature quantity, performs supervised labeling based on correspondence information between devices and device types, and constructs a device type determination model using a supervised machine learning device. At this time, an unknown device type class is provided 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. In addition, the processing unit 101 notifies the steady communication pattern learning unit 103 of the traffic data and the device type information of the monitoring target device, and the non-steady communication detection model by device type, the non-steady communication detection model by vendor, and the device-specific non-steady communication detection model. Request the construction of a communication detection model. The regular communication pattern learning unit 103 constructs various types of non-regular communication detection models, and notifies and stores the constructed non-regular communication detection models in the storage unit 108 (S507).

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

FIG. 10 is a flow chart showing an example of the operation when the traffic analysis device 10 receives traffic data while operating in the operational mode.

Here, it is assumed that the traffic data of the monitored network N1 (network switch 20) is captured while the traffic analysis device 10 is operating in the operation mode.

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

The processing unit 101 acquires device type information (device type information of each IoT device 30 currently managed) stored in the storage unit 108, and determines whether or not the device type of the target device has been determined (target device type information). (S602).

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, and requests determination of the device type of the device of interest. Then, the device type determination unit 105 generates a feature amount from the received traffic data, applies it to the device type determination model, and returns the determination result to the processing unit 101 . Then, the processing unit 101 causes the storage unit 108 to store device type information (information in which the device of interest and the device type identifier are associated with each other) based on the determination result of the device type determination unit 105 (S603). At this time, the processing unit 101 treats the device as an unknown device type (a device type that has not been learned in the non-stationary communication detection model by device type) if the probability of the device being unknown in the device type determination model is equal to or greater than a certain value. In other cases, the determined device type may be notified to the processing unit 101 .

Next, the processing unit 101 checks whether or not there is a non-stationary communication detection model by device type for the device type of the device of interest (whether or not it is stored in the storage unit 108) (S604). The process proceeds to step S605, which will be described later. If not, it is assumed that an IoT device 30 of an unlearned device type has been connected, and the process proceeds to step S610 (shift to mixed mode) to start learning.

Next, the processing unit 101 acquires vendor information stored in the storage unit 108 (vendor information of each IoT device 30 currently managed), and determines whether or not the device of interest has been vendor-determined (vender information of the device of interest). (S605).

If the device of interest has not been determined as a vendor, the processing unit 101 notifies the vendor information determination unit 106 of traffic data (traffic data to which MAC address information is added) and requests determination of the vendor of the device of interest. The vendor information determination unit 106 extracts the MAC address from the received traffic data and acquires the vendor identifier (for example, vendor name) corresponding to the vendor code of the MAC address from the Internet. The vendor information determination unit 106 notifies the processing unit 101 of the acquired identifier of the vendor. Then, the processing unit 101 causes the storage unit 108 to store the vendor information based on the determination result of the vendor information determination unit 106 (S606).

Next, the processing unit 101 determines whether a vendor-specific non-stationary communication detection model exists for the vendor of the device of interest (whether or not it is stored in the storage unit 108) (S607). The process moves to step S605, and if not, the process moves to step S610 (shifts to mixed mode) in order to start learning assuming that an unlearned vendor's IoT device 30 is connected.

Next, the processing unit 101 acquires the non-steady communication detection model by device type, the non-steady communication detection model by vendor, and the device-specific non-steady communication detection model corresponding to the device of interest from the storage unit 108, The determination unit 104 is requested to determine an unsteady communication state (abnormality determination). The non-steady communication state determination unit 104 uses the received traffic data and various types of non-steady communication detection models to perform non-steady communication state determination processing (abnormality determination processing; processing of the above-described flowchart of FIG. 8). The non-steady communication state determination unit 104 notifies the processing unit 101 of the result of the non-steady communication state determination processing (S608).

The processing unit 101 checks the result of the non-steady communication state determination process (abnormal state determination process) (S609), and if the device of interest is not determined to be in the non-steady communication state (abnormal state), the process (traffic data reception (S612).

On the other hand, when 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 the communication of the device of interest. The communication control unit 107 transmits control information for blocking communication of the device of interest to the gateway 40 (firewall), blocks communication of the device (S613), and performs processing (a series of processes related to the device of interest accompanying reception of traffic data). processing).

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

Here, it is assumed that the traffic data of the monitored network N1 (network switch 20) is captured while the traffic analysis device 10 is operating in the mixed mode.

At this time, the traffic data collection unit 102 first analyzes the content of the captured traffic data, shapes it into an IP packet, and notifies the processing unit 101 (S701).

The processing unit 101 acquires the device type information stored in the storage unit 108, and checks whether or not 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 determination of the device type of the device of interest, and obtains the determination result. , the device type information of the target device based on the determination result is stored in the storage unit 108 (S703).

Next, the processing unit 101 checks whether or not there is a non-stationary communication detection model by device type corresponding to the device type of the device of interest (whether or not learning has been completed) (S704). If not, it is assumed that an IoT device 30 of an unlearned device type has been connected, and the processing shifts to step S714 to be described later to perform learning processing (device type non-learning corresponding to the device type of the attention device). construction of steady-state communication detection model) is started/continued.

Next, the processing unit 101 acquires the vendor information stored in the storage unit 108, and determines whether or not the vendor information of the device of interest has been determined (whether or not the vendor information of the device of interest is held in the storage unit 108). (S705).

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

Next, the processing unit 101 checks whether or not there is a vendor-specific non-stationary communication detection model corresponding to the device of interest (whether or not learning has been completed) (S707). If not, it is assumed that the IoT device 30 of the unlearned vendor has been connected, and the processing proceeds to step S716 described later to perform learning processing (a vendor-specific non-steady communication detection model corresponding to the vendor of the attention device construction) is started/continued.

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

Note that the processing itself of steps S701 to S710 is almost the same as the processing in the operation mode, so a detailed description will be omitted.

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

In step S704 described above, if there is no non-stationary communication detection model by device type 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 the device type has ended (S714). If the learning period has ended, the process proceeds to step S715, which will be described later. If not, the process proceeds to step S718, which will be described later. A series of processes triggered by the reception of

On the other hand, when the learning period has ended, the processing unit 101 acquires the accumulated traffic data of the device type from the storage unit 108 and stores the steady communication pattern learning unit 103 in the non-steady traffic data of the device type for each device type. A communication detection model is constructed and acquired, and the acquired non-steady communication detection model by device type is stored in the storage unit 108 (S715), and the process proceeds to step S705 described above. At this time, the regular communication pattern learning unit 103 collects the traffic data of the IoT devices 30 for which the device-type non-regular communication detection model is to be constructed for a predetermined learning period, and applies it to the processing of the above-described flowchart of FIG. By doing so, a non-stationary communication detection model by device type corresponding to the device type of the IoT device 30 may be obtained. At this time, the regular communication pattern learning unit 103 performs the grouping process (steps S201 to S204 in FIG. 5) for constructing the vendor-specific non-stationary communication detection model, and then performs the process of the flowchart in FIG. A device-specific non-stationary communication detection model corresponding to the IoT device 30 may be constructed by.

In step S707 described above, if there is no vendor-specific non-stationary communication detection model related to the vendor of the device of interest, the processing unit 101 checks whether the learning period for the steady communication pattern of the vendor has ended (S716). has been completed, the process proceeds to step S717, which will be described later; otherwise, the process proceeds to step S718, which will be described later. (a series of processes to be triggered) ends.

On the other hand, if the learning period has ended, the processing unit 101 acquires the accumulated traffic data of the vendor from the storage unit 108 and stores the steady communication pattern learning unit 103 in the vendor-specific non-steady communication detection model of the vendor. is constructed and acquired, the acquired vendor-specific non-stationary communication detection model is stored in the storage unit 108 (S717), and the process proceeds to step S708 described above. At this time, the regular communication pattern learning unit 103 collects the traffic data of the IoT devices 30 for which the vendor-specific non-stationary communication detection model is to be constructed for a predetermined learning period, and applies it to the processing of the above-described flowchart of FIG. , a vendor-specific non-stationary communication detection model corresponding to the vendor of the IoT device 30 may be obtained. In this case, in the process of step S201, the regular communication pattern learning unit 103 may extract flows from all the traffic data acquired during the mixed mode learning period. The process of S104 may be executed to acquire the traffic data that was not extracted in step S104, and then the process of the flowchart of FIG. 5 may be executed. Also, at this time, the regular communication pattern learning unit 103 may construct a device-specific non-regular communication detection model corresponding to the IoT device 30 through the processing of the flowchart of FIG.

Next to step S710 described above, the processing unit 101 determines whether there is a device type or vendor during the learning period in order to construct any non-stationary communication detection model in the current state (mixed mode state). (S711), and if there is a device type or vendor during the learning period, shift to the operation mode; otherwise, terminate the processing (a series of processing triggered by the reception of the traffic data).

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

In the traffic analysis device 10 of the first embodiment, an unsteady communication detection model according to the attributes of the IoT devices 30 is constructed, and the unsteady communication state (abnormal state) of each IoT device 30 is detected using the unsteady communication detection model. judge. In addition, in the traffic analysis device 10 of the first embodiment of this embodiment, as the non-steady communication detection model, the non-steady communication detection model by device type (for each device type, the steady communication pattern of the main function of the device type is learned models), vendor-specific non-stationary communication detection models (models that have learned steady communication patterns such as vendor-specific control communication for each vendor), and device-specific non-stationary communication detection models (devices that have learned communication patterns other than the above unique non-stationary communication detection model) is adopted. As a result, in the traffic analysis device 10 of the first embodiment, even if the IoT device 30 that did not exist during the learning period of the initial steady communication is connected to the monitored network N1, Since it is possible to determine the non-steady communication state (abnormal state) using the steady communication detection model, learning processing for the IoT device 30 is not required, and the learned non-steady communication is performed in the same way as the other IoT devices 30. It becomes possible to perform determination processing of non-stationary communication using a detection model.

In addition, the non-stationary communication detection model by device type can determine deviation from the regular communication pattern related to the main function of the IoT device 30, and the non-stationary communication detection model by vendor can determine deviation from the vendor-specific steady communication pattern. is. Therefore, the traffic analysis device 10 can improve the accuracy of anomaly detection compared to the case where one non-steady communication detection model is constructed using all communications of a certain IoT device 30 .

Furthermore, in the traffic analysis device 10, by applying a device-specific non-stationary communication detection model at the end of the non-stationary communication determination process, a device-specific normal communication pattern and other abnormal communication patterns can be distinguished. Therefore, it is possible to further improve the determination accuracy.

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

(B-1) Configuration of Second Embodiment The connection relationship of each device related to the second embodiment can also be shown using FIG. Codes ending in A in FIG. 2 are codes used only in the second embodiment.

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

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

In FIG. 12, the same or corresponding reference numerals are given to the same or corresponding parts as in FIG. The second embodiment will be described below, focusing on the differences from the first embodiment.

Traffic analysis device 10A differs from the first embodiment in that processing unit 101 and regular communication pattern learning unit 103 are replaced with processing unit 101A and regular communication pattern learning unit 103A, and feedback unit 109 is added. there is

The feedback unit 109 supplies the determination result by the unsteady communication state determination unit 104 to the operator terminal TE used by the operator OP, and also accepts input of feedback information on the determination result (for example, feedback information on the erroneous determination result). conduct.

The format in which the feedback unit 109 inputs and outputs information to and from the operator terminal TE is not limited. The determination result may be presented and the input of feedback information may be accepted. Here, the operation screen when the feedback unit 109 presents the determination result to the operator terminal TE and receives the input of the feedback information shall be referred to as a "feedback input reception screen".

In the traffic analysis device 10A of the second embodiment, the communication pattern detected as abnormal is presented to the operator OP via the operator terminal TE, so that the operator OP can determine whether or not the communication pattern is truly abnormal. be. Then, the traffic analysis device 10A can receive input of feedback information from the operator OP regarding erroneous detection (determination result that a communication pattern that is not non-stationary communication is in the non-stationary communication state). Feedback information indicating an erroneous detection supplied from the operator terminal TE is hereinafter referred to as "erroneous detection feedback".

13 and 14 are diagrams showing configuration examples of feedback input acceptance screens.

FIG. 13 shows a field F101 for displaying event information based on the determination result (determination result of the unsteady communication state determination unit 104) in the feedback unit 109. FIG.

The field F101 has a subfield SF that displays an event (alert) for each determination result. In the field F101 shown in FIG. 13, subfields SF111, SF112, . . . are displayed in chronological order from the top.

Each subfield shown in FIG. 13 includes an “event name” indicating the name of the event, and “device information” indicating the IoT device 30 related to the event (the IP address is displayed here, but other information such as the host name is displayed). display format), the “occurrence time” of the event, and a detailed confirmation button B101 for receiving the display of the log information related to the event.

For example, in the subfield SF111 shown in FIG. 13, the event name is "non-stationary communication permanent detection" (event name indicating detection of non-stationary communication state (abnormal state)), and the device information is the IoT device 30-1. "xxx.xxx.xxx.xxx" indicating the IP address of the event, "14:50" as the time of occurrence, and the details of the traffic data (information indicating each IP packet) used to detect the event (abnormality). A detailed confirmation button B101 for accepting the is arranged.

In this state, when the detail confirmation button B101 of the subfield SF111 is pressed, the feedback unit 109 displays (for example, pops up) the field F201 of FIG. 14 on the feedback input acceptance screen. The field F201 contains a subfield SF201 for displaying the details of the traffic data (information indicating each IP packet) used to detect the event (abnormality), and a button B201 for accepting false detection feedback for the event. are placed. In the state of FIG. 14, when the button B201 of the field F201 is pressed, the feedback unit 109 notifies the processing unit 101 that there is false detection feedback regarding the determination result related to the event. When displaying subfield SF201 (traffic data details), feedback unit 109 acquires the corresponding traffic data from storage unit 108 via processing unit 101A.

As described above, the feedback unit 109 accepts erroneous detection feedback on the feedback input acceptance screens configured as shown in FIGS. 13 and 14, for example.

Upon receiving the false detection feedback notification from the feedback unit 109, the processing unit 101A notifies the steady communication pattern learning unit 103A of the device-specific unsteady communication detection model and the communication pattern for which the false detection was fed back, and performs the device-specific unsteady communication. Request retraining of the detection model.

In addition to the first embodiment, the steady communication pattern learning unit 103A, when receiving a re-learning request for the device-specific non-steady communication detection model from the processing unit 101, feeds back an erroneous detection to the device-specific non-steady communication detection model through sequential learning processing. Applying the determined communication pattern (considering the content of false positive feedback), reconstruct each non-stationary communication detection model. The steady communication pattern learning unit 103A notifies the processing unit 101 of the reconstructed non-steady communication detection model specific to each device.

As a result, in the traffic analysis device 10A, the machine learning device can learn the communication pattern as a normal communication pattern, taking into consideration that the communication pattern that is fed back as an erroneous detection will not be detected as a normal communication pattern in the subsequent abnormality determination. In the traffic analysis device 10A, a sequential learning type machine learner (a machine learner in which a model is reconstructed by updating internal parameters each time data is input) may be used as the machine learner. This sequential learning type machine learning device is used in the steady communication pattern learning unit 103A of the second embodiment to build a device-specific non-steady communication detection model.

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

Here, the operation when receiving false detection feedback from the operator terminal TE (operator OP) while the traffic analysis device 10A in the second embodiment is operating in the operational mode or the mixed mode will be described.

Here, when the processing unit 101A obtains a determination result indicating that the IoT device 30 in an abnormal state (unsteady communication state) has been detected from the non-steady communication state determination unit 104, the processing unit 101A controls the feedback unit 109 and controls the operator terminal TE. The content of the determination result is additionally displayed on the feedback input reception screen (for example, the operation screens shown in FIGS. 13 and 14) to be presented to make it possible to receive input of false detection feedback.

Here, in the operator terminal TE, the operator OP presses the details confirmation button B101 of the subfield SF111 (subfield indicating an abnormality detection event related to the IoT device 30-1) shown in FIG. 13, and then the field shown in FIG. Assume that the button B201 is pressed in F201. As a result, the feedback unit 109 can receive false detection feedback regarding the result of abnormality determination relating to the IoT device 30-1.

The feedback unit 109, upon receiving an input of false detection feedback from the operator terminal TE, notifies the processing unit 101 of the traffic data for which the false detection feedback was received. The processing unit 101 acquires the device-specific non-stationary communication detection model from the storage unit 108, notifies the regular communication pattern learning unit 103A together with the traffic data for which the false detection is fed back, and obtains each emergency communication detection model (non-stationary communication by device type). request re-learning of the detection model, vendor-specific non-stationary communication detection model, and device-specific non-stationary communication detection model) (re-learning processing considering the content of false detection feedback).

The steady-state communication pattern learning unit 103A reconstructs each non-steady-state communication detection model by successively learning the traffic data fed back as false detection. The regular communication pattern learning unit 103A notifies the processing unit 101 of each reconstructed non-regular communication detection model. The processing unit 101 stores each reconstructed non-steady-state communication detection model in the storage unit 108 .

(B-3) Effects of Second Embodiment According to this embodiment, the following effects can be obtained in addition to the effects of the first embodiment.

The traffic analysis device 10A in the second embodiment has a false positive feedback function of anomaly detection results from the operator, and in order to re-learn the communication pattern for which the false positive feedback is fed back as normal communication, each non-steady communication detection A model is constructed by a sequential learning type machine learner, and in the case of false positive feedback, the model is reconstructed by applying the communication pattern of the false positive feedback to the machine learner. As a result, even if the traffic analysis device 10A in the second embodiment erroneously detects, for example, the unique communication pattern of the newly connected IoT device 30 as being abnormal, the erroneous detection feedback immediately applies to the steady communication model. Therefore, it is possible to suppress the continuation of false detection.

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

The connection relationship of each device related to the third embodiment can also be shown using FIG. Codes ending in B in FIG. 2 are codes used only in the third embodiment.

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

FIG. 15 is a block diagram showing the functional configuration of the traffic analysis device 10B of the third embodiment. In FIG. 15, the same or corresponding reference numerals are given to the same or corresponding parts as in FIG. 1 described above. The first embodiment will be described below, focusing 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 regular communication pattern learning unit 103 is omitted.

In each of the above embodiments, the traffic analysis devices 10 and 10A have the regular communication pattern learning unit 103, but are not limited to this. For example, like the traffic analysis device 10B, a configuration without the regular communication pattern learning unit 103 may be employed.

In the traffic analysis device 10B, for each non-stationary communication detection model (non-stationary communication detection model by device type, non-stationary communication detection model by vendor, device-specific non-stationary communication detection model), an external device (for example, an external cloud not shown) server), set it in the non-stationary 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 regular communication pattern learning unit 103 . In this way, in a cloud system that collects traffic data from traffic analysis devices 10B associated with a plurality of edge networks (monitored networks) and performs learning processing, traffic analysis devices 10B associated with a plurality of edge networks (monitored networks) By aggregating and learning traffic data, it is possible to build an unsteady communication detection model using more data, so detection accuracy can be improved.

In addition, since machine learning generally requires a large amount of computational resources for learning, in the third embodiment, with the configuration described above, it is possible to reduce the computational resources required for the operation of the traffic analysis device 10B. can.

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

The connection relationship of each device related to the fourth embodiment can also be shown using FIG. Codes ending in C in FIG. 2 are codes used only in the fourth embodiment.

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

FIG. 16 is a block diagram showing the functional configuration of the traffic analysis device 10C of the fourth embodiment. In FIG. 16, the same or corresponding parts as those in FIG. 1 described above are denoted by the same or corresponding reference numerals. The first embodiment will be described below, focusing on the differences from the first embodiment.

In the traffic analysis device 10C, the processing unit 101 and the non-steady communication state determination unit 104 are replaced with the processing unit 101C and the non-steady communication state determination unit 104, and the vendor information determination unit 106 is excluded. different from the form.

The non-stationary communication state determination unit 104C of the traffic analysis device 10C of the third embodiment differs from that of the first embodiment in that the abnormality determination process based on the vendor-specific non-stationary communication detection model is omitted. In other words, the non-stationary communication state determination unit 104C of the traffic analysis device 10C of the third embodiment makes an abnormality determination using the device type-specific non-stationary communication detection model, and uses the device-specific non-stationary communication detection model to process the traffic data detected as abnormal. Anomaly judgment is performed by making an anomaly judgment. That is, 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 non-stationary communication detection model.

In the traffic analysis device 10C of the third embodiment, by removing the application of the vendor-specific non-steady-state communication detection model, it is possible to shorten the time required for learning the steady-state communication pattern and abnormality determination.

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

The connection relationship of each device related to the fifth embodiment can also be shown using FIG. Codes ending in D in FIG. 2 are codes used only in the fifth embodiment.

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

FIG. 17 is a block diagram showing the functional configuration of the traffic analysis device 10D of the fifth embodiment. In FIG. 17, the same or corresponding reference numerals are given to the same or corresponding parts as in FIG. 1 described above. The first embodiment will be described below, focusing on the differences from the first embodiment.

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

In the traffic analysis device 10 of the first embodiment, when extracting a flow to be learned, clustering is used to classify groups to which flows belonging to either the same device type or all devices of the same vendor belong, etc., for constructing various non-stationary communication detection models. Although the learning data is targeted, it is not limited to this. In the steady communication pattern learning unit 103D of the traffic analysis device 10D of this embodiment, the device-specific non-steady communication detection model and the vendor-specific non-steady communication detection model can be constructed with respect to the total number of flows acquired in the learning mode. The ratio of the number of flows to be used is set by a parameter, and groups to be used for learning are extracted so as to satisfy the ratio.

Specifically, in the regular communication pattern learning unit 103D of this embodiment, when the device types of the IoT devices 30 related to the flows included in a certain group are tabulated, what percentage of all the target device types are included? and the ratio of the vendor with the largest number of flows when the vendors of the IoT devices 30 related to the flows included in the group are tabulated (the total number of flows in the group A parameter (hereinafter referred to as "vendor group affiliation rate") that indicates the ratio of For example, when the device types of the IoT devices 30 related to the flows included in a certain group are aggregated, if all target devices are included, the device type group belonging rate is 100%, and 8 out of all target devices If a target device for allocation is included, the device type group affiliation rate is 80%. Further, for example, when the vendors of the IoT devices 30 related to the flows included in the group are tabulated, if the IoT devices 30 related to all the flows are the same vendor, the vendor group affiliation rate is 100%, which is the highest number. If the number of flows of a large vendor accounts for 80% of the entire group, the vendor group affiliation rate is 80%.

The steady communication pattern learning unit 103D of this embodiment calculates the device type group belonging rate for each group when extracting groups to be used for learning the non-steady communication detection model by device type, and the device type group belonging rate is If the standard is equal to or higher than the standard (hereinafter, this standard is referred to as "standard device type group belonging rate"), the group is extracted as a learning target. Further, the regular communication pattern learning unit 103D of this embodiment calculates the vendor group belonging rate for each group when extracting groups to be used for learning the vendor-specific non-stationary communication detection model, and the vendor group belonging rate is used as a reference. If the above (this criterion is hereinafter referred to as "reference vendor group affiliation rate"), the group is extracted as a learning target.

In this embodiment, the initial value of the reference device type group affiliation rate is 100%, and when the reference device type group affiliation rate is 100%, the groups that include flows of all target device types are used for learning. means In this embodiment, the initial value of the standard vendor group affiliation rate is 100%, and when the standard vendor group affiliation rate is 100%, it is recommended that a group in which all devices have the same vendor be used for learning. means. In other words, in the first embodiment, the reference device type group membership rate and the standard vendor group membership rate were fixed at 100%, but in this embodiment, the reference device type group membership rate and the standard vendor group membership rate are variable parameters. It is assumed that

Furthermore, in this embodiment, for all flows of traffic data initially input for learning (hereinafter referred to as "total flow"), the non-steady communication detection model by device type and the non-steady communication detection model by vendor The ratio of flows not extracted for learning (hereinafter referred to as "unextracted flows") shall be referred to as "flow unextracted rate". For example, if the total flow is 100 and the unextracted flow is 10, the flow unextracted rate is 10%. In the steady-state communication pattern learning unit 103 of this embodiment, a target value of the flow unextracted rate (hereinafter referred to as "target flow unextracted rate") is provided, and the flow unextracted rate is equal to the target flow unextracted rate. If it becomes larger, the process of lowering the reference device type group belonging rate and/or the reference vendor group belonging rate is performed until the flow unextracted rate becomes equal to or less than the target flow unextracted rate. Here, the regular communication pattern learning unit 103 does not simultaneously lower the reference device type group membership rate and the reference vendor group membership rate, but alternately lowers the reference device type group membership rate and the reference vendor group membership rate, A process for confirming the non-extraction rate shall be performed. Here, the regular communication pattern learning unit 103 reduces the rate of belonging to the reference device type group (reduces by 5% each time) when the number of repetitions (the number of times of processing for checking the flow unextracted rate) is an odd number, and repeats If the number of times (the number of times of processing to check the flow unextracted rate) is an even number, the vendor-specific non-stationary communication detection model will be reduced (5% reduction at a time), but it is limited to this. not a thing The range of decreasing the reference device type group belonging rate and the reference vendor group belonging rate at once is not limited to 5%, and other values may be applied.

Here, the parameter for adjusting (subtracting) the reference vendor group belonging rate to achieve the target flow unextracted rate is i (i varies in the range of 0 to 100), and the vendor group belonging rate is adjusted (subtracted). ) is j (j varies in the range of 0 to 100). That is, the device type group belonging rate is "100-i [%]" and the vendor group belonging 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 belonging rate and the reference vendor group belonging rate are 100%. The target flow unextracted rate may be, for example, 1%.

FIG. 18 is a flow chart showing the operation of the processing section 101D of this embodiment in the learning mode.

First, the regular communication pattern learning unit 103D divides the communication flow of the acquired traffic data by device type (S801).

Next, the regular communication pattern learning unit 103D sets the reference device type group belonging rate to "100-i [% ]” (S802), and a group (flow group) to be used for learning is extracted from the traffic data so as to satisfy the reference device type group belonging rate (S803).

Next, the regular communication pattern learning unit 103D classifies the flows that were not extracted in the process of step S801 (the flows that were not used to construct the non-regular communication detection model by device type) by vendor (S804). ).

Next, the regular communication pattern learning unit 103D sets the reference vendor group affiliation rate to "100-j [%]" as a group extraction condition used for learning when flows are grouped by clustering (clustering by vendor). (S805), and a group (flow group) to be used for learning is extracted from the traffic data so as to satisfy the reference vendor group belonging rate (S806).

Next, the regular 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 flow unextracted rate is equal to or less than the target flow unextracted rate, the regular communication pattern learning unit 103D completes the grouping process (S811). Then, the steady communication pattern learning unit 103D finally uses the flow of the group extracted in step S801 to construct a non-steady communication detection model by device type, and finally uses the flow of the group extracted in step S806 to construct the non-steady communication detection model by vendor. An unsteady communication detection model shall be constructed.

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

If the number of repetitions is an even number, the regular communication pattern learning unit 103D subtracts 5% from the reference device type group belonging rate (adds 5 to i; i=i+5) (S809), and returns to step S802 described above. Operate. On the other hand, if the number of repetitions is an odd number, the regular communication pattern learning unit 103D subtracts 5% from the reference vendor group belonging rate (adds j to 5; j=i+5) (S810), and returns to step S802. works. At this time, the width of subtraction between i and j is not limited to 5%.

With the above processing, the steady communication pattern learning unit 103D can adjust the learning difficulty level of the device-specific non-steady communication detection model and the vendor-specific non-steady communication detection model.

Note that the more communication patterns learned by the device-specific non-stationary communication detection model/vendor-specific non-stationary communication detection model, the lower the detection accuracy in the device-specific non-stationary communication detection model/vendor-specific non-stationary communication detection model. On the other hand, the fewer the communication patterns learned by the device-specific non-stationary communication detection model/vendor-specific non-stationary communication detection model, the higher the detection accuracy in the device-specific non-stationary communication detection model/vendor-specific non-stationary communication detection model. Since the learning data for the type-specific non-stationary communication detection model/vendor-specific non-stationary communication detection model becomes complicated, the detection accuracy of these models decreases. Therefore, in this embodiment, the detection accuracy can be improved by adjusting this target value to maximize the overall detection accuracy (i and j are adjusted to achieve the target flow unextracted rate).

Here, the target flow non-extraction rate may be set to 0 (the number of flows learned by the device-specific non-stationary communication detection model is 0). As a result, it becomes possible to detect anomalies using only the non-stationary communication detection model by device type and the non-stationary communication detection model by vendor, reducing the time required for learning the device-specific non-stationary communication detection model and for anomaly judgment. can be done.

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

(F-1) The device type determination method in the device type determination unit 105 of each of the above embodiments uses a determination model constructed by supervised machine learning using traffic data, but is not limited to this. . For example, in the traffic analysis device 10, every time a new IoT device 30 is connected to the monitored network N1, the operator manually manually displays the device type information of the IoT device 30 (indicating the relationship between the IoT device 30 and the device type). information) input may be accepted. In the device type determination unit 105, erroneous detection may occur when the device type is determined by a machine learning device. can be done.

(F-2) The device type determination model in the device type determination unit 105 in each of the above embodiments uses a machine learning device that classifies into any device type including unknown device types, but is limited to this. not a thing For example, the device type determination unit 105 may conceivably construct a binary classifier that aggregates traffic data for each device type and outputs whether or not it is of that device type. In this case, the device type determination unit 105 determines the device type by sequentially applying the binary classifier for each device type. For example, in the device type determination unit 105, when the device type is determined by a binary classifier of a plurality of device types (for example, when the probability value of the device type is output as the output of the binary classifier), the most The device type of the binary classifier with a large value may be used as the determination result. Further, for example, the device type determination unit 105 may determine that the device type is unknown if the probability value of any binary classifier is equal to or less than a certain value. In the device type determination unit 105, when applying the determination method described in each of the above embodiments, it was necessary to reconstruct the entire determination model when learning a new unknown device type. can shorten the time required for learning because it only needs to build a machine learner for the new device type.

(F-3) In each of the above embodiments, as a device-specific non-stationary communication detection model, traffic data of unique communication patterns of all IoT devices 30 are collected to build a single detection model, but the present invention is limited to this. not a thing For example, the regular communication pattern learning unit 103 may apply a method of constructing a device-specific non-regular communication detection model for each IoT device 30 . In this case, the steady communication pattern learning unit 103 needs to learn the steady communication pattern for the IoT device 30 newly connected during the operation mode. Since the common communication pattern in the model has already been learned, the detection accuracy can be improved while maintaining the effect of shortening the time required for learning the device-specific non-stationary communication detection model for each IoT device 30.

(F-4) In the traffic analysis device 10A of the second embodiment, a method of reconstructing a device-specific non-stationary communication detection model by sequential machine learning of traffic data fed back with false detection has been described, but the method is limited to this. not to be For example, in the traffic analysis device 10A, a specific field value of traffic data fed back as an erroneous detection is held as a whitelist, and the irregular communication state determination unit 104 does not detect anomalies in the traffic data included in the whitelist. I can think of a way. In this method, for example, when the operator OP checks the traffic data from the management screen (feedback input reception screen) and gives false detection feedback, the false detection is performed in units such as the destination IP address, the TCP port number, and the specific word of the payload. A white list may be created by notifying the factors considered to be. By applying the whitelist type processing as described above to the feedback input reception screen, it is possible to ensure that the traffic data relating to the false positive feedback will not be detected as an anomaly thereafter. In addition, even in a configuration that does not have the regular communication pattern learning unit 103, as in the traffic analysis device 10B of the third embodiment, by applying the whitelist type processing as described above, false detection suppression by false detection feedback can be executed.

(F-5) In each of the above embodiments, the vendor information determination unit 106 uses a method of querying the Internet for the vendor code (OUI) of the MAC address as a method of acquiring vendor information, but it is not limited to this. do not have. For example, in the vendor information determining unit 106, the combination of the MAC address and the vendor may be stored in the traffic analysis device in advance, and the vendor information for each IoT device 30 may be obtained by referring to the stored information. According to this method, the vendor information can be retained even if the traffic analysis device 10 does not connect to the Internet N2, so that it can be used even in a closed environment where Internet connection is not possible.

10 Traffic analysis device 101 Processing unit 102 Traffic data collection unit 103 Regular 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 Monitoring target network N2 Internet.

Claims (11)

Whether or not the communication device is in an unsteady communication state from the traffic data of the communication device using a learning model obtained by machine-learning traffic data patterns in a steady communication state for each attribute of the communication device connected to the target network. a non-stationary communication decision model holding means for holding a non-stationary communication decision model for determining
attribute recognition means for recognizing attributes of each of the communication devices;
non-steady communication determination means for performing non-steady communication determination processing 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 determination model. A traffic analysis device characterized by: The non-stationary communication determination model holding means holds learning traffic data from each of the communication devices, divides the held learning traffic data by flow, and classifies each of the flows by the attribute. 2. The traffic analysis apparatus according to claim 1, wherein the non-stationary communication determination model for each attribute is constructed and held by performing machine learning. The non-steady communication determination model holding means uses a learning model obtained by machine-learning traffic data patterns in a steady communication state for each device type of the communication device to determine whether the communication device determines whether the non-steady communication is performed based on the traffic data of the communication device. Holds a non-stationary communication judgment model for each device type that judges whether or not it is in a state,
The traffic analysis apparatus according to claim 2, wherein the non-steady communication determination means performs the non-steady communication determination process using at least the non-steady communication determination model by device type. The non-steady communication determination model holding means uses a learning model obtained by machine-learning patterns of traffic data in a steady communication state for each manufacturer of the communication device to determine whether the communication device is in the non-steady communication state from the traffic data of the communication device. Holds a manufacturer-specific non-stationary communication judgment model for judging whether or not
4. The traffic analysis apparatus according to claim 3, wherein said non-stationary communication determination means further uses said manufacturer-specific non-stationary communication determination model to perform said non-stationary communication determination processing. The non-stationary communication determination model holding means classifies the flows divided from the learning traffic data by device type, groups the flows having similar characteristics, and classifies the flows having similar characteristics into groups, and classifies the flows divided from the learning traffic data into groups. A first extraction process for extracting a group including the flow is performed, and the device type-specific non-steady communication determination model is constructed using the flow of the group extracted by the first extraction process. The traffic analysis device according to claim 4. the non-stationary communication determination model holding means classifies the flows that have not been extracted in the first extraction process from among the learning traffic data by manufacturer, and groups the flows having similar characteristics; performing a second extraction process of extracting a group including the flows of at least a number of manufacturers equal to or greater than a second reference, and using the flows of the group extracted by the second extraction process, the non-steady communication by manufacturer 6. The traffic analysis device according to claim 5, wherein a judgment model is constructed. The non-steady communication determination model holding means further uses a learning model obtained by performing machine learning on the flow that has not been extracted in either the first extraction process or the second extraction process to determine the traffic of the communication device. constructing and holding a device-specific non-stationary communication determination model for determining whether the communication device is in a non-stationary communication state from data;
7. The traffic analysis apparatus according to claim 6, wherein said non-stationary communication determination means also uses said device-specific non-stationary communication determination model to perform said non-stationary communication determination processing. The non-stationary communication determination model holding means indicates the 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 learning traffic data. Adjusting the first criterion and/or the second criterion and repeating the first extraction process and the second extraction process again until the unextracted flow rate becomes equal to or less than the target value, constructing the non-stationary communication determination model by device type using the flows of the group extracted in the first extraction process when the flow unextracted rate is equal to or less than a target value, and the flow unextracted rate is equal to or less than the target value; 8. The traffic analysis apparatus according to claim 7, wherein the flow of the group extracted in the second extraction process is used to construct the manufacturer-specific non-stationary communication determination model. further comprising feedback receiving means for receiving input of feedback information regarding the result of the non-steady communication determination process by the non-steady communication determination means;
9. The traffic analysis apparatus according to claim 2, wherein said non-stationary communication decision model holding means constructs and holds said non-stationary communication decision model in consideration of said feedback information. the computer,
Whether or not the communication device is in an unsteady communication state from the traffic data of the communication device using a learning model obtained by machine-learning traffic data patterns in a steady communication state for each attribute of the communication device connected to the target network. a non-stationary communication decision model holding means for holding a non-stationary communication decision model for determining
attribute recognition means for recognizing attributes of each of the communication devices;
Functioning as non-steady communication determination means for performing non-steady communication determination processing for determining whether the communication device is in the non-steady communication state from the traffic data of the communication device using the non-steady communication determination model. A traffic analysis program characterized by: In the traffic analysis method performed by the traffic analysis device,
The traffic analysis device comprises non-stationary communication determination model holding means, attribute recognition means, and non-stationary communication determination means,
The non-steady communication determination model holding means uses a learning model obtained by machine-learning a pattern of traffic data in a steady communication state for each attribute of the communication device connected to the target network, and extracts the traffic data of the communication device from the traffic data of the communication device. Holds a non-stationary communication decision model for deciding whether is in a non-stationary communication state,
The attribute recognition means recognizes attributes of each of the communication devices,
The non-stationary communication determination means uses the non-stationary communication determination model to perform non-stationary communication determination processing for determining whether or not the communication device is in a non-stationary communication state from the traffic data of the communication device. A traffic analysis method characterized by:

Images