WO2024209608A1 - Monitoring device, monitoring method, and monitoring program - Google Patents

Abstract

A monitoring device (10) includes a feature generation unit (11), an open port determination unit (12), an equipment state determination unit (13), and an infection determination unit (14). The feature generation unit (11) generates a feature of an equipment on the basis of sampled traffic, which is any one of traffic in a direction of transmission from the equipment and traffic in a direction of transmission to the equipment. The open port determination unit (12) determines, on the basis of the feature, whether or not an open port of the equipment exists. When an open port exists in the equipment, the equipment state determination unit (13) and the infection determination unit (14) determine a state regarding abnormality of the equipment on the basis of the feature.

Description

Monitoring device, monitoring method, and monitoring program

The present invention relates to a monitoring device, a monitoring method, and a monitoring program.

Many devices, including IoT devices, are connected to the Internet. This allows users to provide and use a variety of services.

On the other hand, now that it is easy to connect to the Internet, users may not be aware that connected devices are inadvertently exposing services or that the devices have vulnerabilities.

As a result, situations are occurring where devices connected to the Internet inadvertently expose services, have vulnerabilities exploited, become infected with malware, and connect to suspicious destinations. To prevent such situations, it is necessary to monitor devices and implement early countermeasures.

Traditionally, a method for monitoring devices involves passively analyzing traffic information circulating on the Internet to understand the status of connected devices.

"Portscan Detection with Sampled NetFlow", [online], [Retrieved March 22, 2023], Internet (https://people.ac.upc.edu/pbarlet/papers/portscan-sampling.pdf)

However, conventional techniques have the problem that they may not be able to effectively monitor devices using sampled traffic.

For example, when passively collecting information about traffic circulating on the Internet, because the total amount of traffic is enormous, it is common to roughly sample and collect only packet headers.

Traditional methods rely on collecting all traffic without missing anything, so coarse sampling does not allow for effective monitoring.

In order to solve the above-mentioned problems and achieve the objective, the monitoring device is characterized by having a feature generation unit that generates features of the device based on sampled traffic, which is at least one of traffic sent from the device and traffic sent to the device, an open port determination unit that determines whether or not the device has an open port based on the features, and an abnormality determination unit that determines an abnormality-related state of the device based on the features if an open port is present on the device.

The present invention makes it possible to effectively monitor devices using sampled traffic.

FIG. 1 is a diagram illustrating an example of the configuration of a network system according to the first embodiment. FIG. 2 is a diagram illustrating an example of the configuration of a monitoring device according to the first embodiment. FIG. 3 is a diagram showing an example of a traffic record. FIG. 4 is a diagram showing an example of an outgoing traffic record. FIG. 5 is a diagram showing an example of an incoming traffic record. FIG. 6 is a flowchart showing a flow of processing of the monitoring device according to the first embodiment. FIG. 7 is a diagram illustrating an example of the configuration of an open port determining unit according to the second embodiment. FIG. 8 is a diagram illustrating an example of the configuration of a device state determining unit according to the second embodiment. FIG. 9 illustrates an example of a computer that executes a monitoring program.

Below, embodiments of the monitoring device, monitoring method, and monitoring program according to the present application are described in detail with reference to the drawings. Note that the present invention is not limited to the embodiments described below.

[Configuration of the network system according to the first embodiment]
1 is a diagram showing an example of the configuration of a network system according to the first embodiment. As shown in Fig. 1, the network system 1 includes a monitoring device 10, a device 21, a device 22, a device 23, and a device 24 connected to a network N. For example, the network N is the Internet.

Device 21 is a camera equipped with a communication function. Device 21 transmits captured images. The images transmitted by device 21 are intended to be viewed only by the user of device 22.

On the other hand, images sent by device 21 may be viewable from devices other than device 22, despite the user's intention. This state is called service disclosure.

For example, if an open port exists in device 21, images may be obtained through that open port. Furthermore, device 21 may be subject to attacks such as DDoS attacks and brute force attacks through the open port. Furthermore, device 21 may be infected with malware through the open port.

The monitoring device 10 determines whether or not the devices included in the network system 1 have open ports. Furthermore, the monitoring device 10 determines whether or not the devices that have open ports are in an abnormal state.

[Configuration of the first embodiment]
The configuration of the monitoring device will be described with reference to Fig. 2. Fig. 2 is a diagram showing an example of the configuration of the monitoring device according to the first embodiment.

As shown in FIG. 2, the monitoring device 10 has a feature generation unit 11, an open port determination unit 12, an equipment status determination unit 13, an infection determination unit 14, and a display unit 15. The monitoring device 10 also stores a rule DB 16.

The feature generation unit 11 generates the feature of the device based on the sampled traffic, which is at least one of the traffic sent from the device and the traffic sent to the device.

The open port determination unit 12 determines whether or not an open port exists on the device based on the characteristics.

If an open port exists in the device, the device status determination unit 13 and the infection determination unit 14 determine the abnormality status of the device based on the characteristics. The device status determination unit 13 and the infection determination unit 14 are examples of an abnormality determination unit.

The display unit 15 displays on a screen the status of the device regarding abnormalities determined by the device status determination unit 13 and the infection determination unit 14. For example, the display unit 15 displays the IP address of the target device, and information indicating whether or not the device is under attack and whether or not the device is infected with malware.

The following describes in detail each step of the process executed by the monitoring device 10 and the operation of each unit. Here, the monitoring device 10 performs each process on one of the devices (e.g., device 21) included in the network system 1.

[Traffic feature generation]
2, sampled traffic data is input to the monitoring device 10. The traffic data is captures of sampled packets, header information of sampled packets, or a flow of sampled packets.

The monitoring device 10 may receive traffic data (honeypot data) for honeypots. A honeypot is a system that intentionally accepts unauthorized access from an attacker. A honeypot may be a device equipped with an open port.

The feature generation unit 11 generates traffic features from the input traffic data. Here, as shown in Figure 3, it is assumed that the traffic data is input in a record format (traffic record). Figure 3 is a diagram showing an example of a traffic record.

Traffic is generated by the sending and receiving of one or more packets. As shown in Figure 3, a traffic record includes the following items: "Time", which is the time or period when the traffic occurred; "SrcIP", which is the IP address of the source of the packet; "SrcPort", which is the port of the source of the packet; "DstIP", which is the IP address of the destination of the packet; "DstPort", which is the port of the destination of the packet; "Protocol", which indicates the protocol; "TCPFlag", which indicates the TCP protocol flag; "Packets", which indicates the number of packets; and "Bytes", which indicates the communication volume.

In addition, each traffic record corresponds to a flow, which is statistical information about packets that have multiple items in common (source IP address, source port number, destination IP address, destination port number, protocol, etc.). However, each traffic record may also correspond to a single packet.

The feature generation unit 11 extracts, from the input traffic records, traffic records corresponding to traffic sent from the target device and traffic sent to the target device. Here, the IP address of the target device is "TA".

Figure 4 shows a traffic record for traffic sent from the target device, i.e., outgoing traffic. Figure 4 shows an example of an outgoing traffic record. As shown in Figure 4, the traffic data for outgoing traffic all have a "SrcIP" value of "TA."

Figure 5 shows a traffic record for traffic sent to the target device, i.e., inbound (incoming) traffic. Figure 5 shows an example of an incoming traffic record. As shown in Figure 5, the traffic data for incoming traffic all have a "DstIP" value of "TA."

Furthermore, there may be multiple target devices. In that case, the feature generation unit 11 extracts outgoing direction traffic records and incoming direction traffic records for each target device.

The feature generation unit 11 generates features for each of the outgoing and incoming directions, including the presence of traffic records, filtering of each value, and the results of aggregation or calculation. The feature generation unit 11 may generate features that combine the features of the outgoing and incoming directions.

The feature generation unit 11 generates features as shown below. The feature generation unit 11 generates a numeric or binary (TRUE or FALSE) variable that indicates each feature. Note that the features generated by the feature generation unit 11 are not limited to those included in the examples below.

(Characteristics based on the existence of records)
Incoming_srcport_80: A binary value indicating whether or not a traffic record with an incoming SrcPort of 80 exists.
Incoming_srcport_80_tcpflag_ack: A binary value indicating whether or not there is a traffic record with TCPFlag set to ACK for incoming SrcPort 80.

(Features based on filter or aggregation results)
Incoming_srcport_80_count: Number of traffic records for incoming SrcPort 80.
Incoming_srcport_80_rate: Percentage of traffic records for Incoming SrcPort 80.
Incoming_srcport_80_srcip_num: Number of SrcIP types in traffic records with incoming SrcPort 80.

(Characteristics based on the results of calculations)
Incoming_bps: bps (bits per second) calculated from the incoming Byte, Packets, and Time values.

(Combination of outgoing and incoming features)
Incoming_Outgoing_byte_rate: The ratio of byte values in the incoming and outgoing directions.

The open port determination unit 12 uses the features generated by the feature generation unit 11 to determine whether or not an open port exists in a device. If the rules stored in the rule DB 16 are satisfied, the open port determination unit 12 determines that an open port exists. Furthermore, "TP" is the port to be determined. Below, the conditional expressions are shown and each rule is explained. However, if only a variable is written in a conditional expression, it means that the variable (flag, etc.) is TRUE.

If both incoming and outgoing traffic records exist, the open port determination unit 12 makes a determination based on rules 1-1 to 1-5 below.

(Rule 1-1)
There is a traffic record in which the outgoing SrcPort is TP and a SYN/ACK response (TCPFlag is SYN or ACK) is observed.
Conditional expression: Outgoing_SrcPort_TP_TCPFlag_SYNACK

(Rule 1-2)
There is an incoming SYN communication addressed to port number TP, and an outgoing ACK response addressed to port number TP is observed.
Conditional expression: Incoming_DstPort_TP_TCPFlag_SYN AND Outgoing_SrcPort_TP_Outgoing_TCPFlag_ACK

(Rule 1-3)
In the incoming direction, ACK communications are received from SrcIPs addressed to port number TP in a number equal to or greater than threshold T1, and in the outgoing direction, ACK responses from port number TP are observed addressed to DstIPs in a number equal to or greater than threshold T2.
Conditional expression: Incoming_DstPort_TP_TCPFlag_ACK_srcip_num>T1 AND Outgoing_SrcPort_TP_TCPFlag_ACK_dstip_num>T2
In rules 1-3, in addition to srcip_num (the total number of source IP addresses), byte_count (the total number of bytes), packet_count (the total number of packets), flow_count (the number of records), etc. may be used.

(Rule 1-4)
The number of incoming traffic records destined for port number TP is equal to or greater than threshold T3, the number of outgoing records (number of flows) from port number TP is equal to or greater than T4, and the usage rate of port TP is equal to or greater than threshold T5.
Conditional expression: Incoming_DstPort_TP_flow_num>T3 AND Outgoing_SrcPort_TP_flow_num>T4 AND Outgoing_SrcPort_TP_rate>T5
Rules 1-4 are valid when TCPFlag does not exist (when a protocol other than the TCP protocol, such as the UDP protocol, is used).

The open port determination unit 12 can determine whether a port is open even if the sampled traffic does not contain any response traffic conforming to the TCP protocol from the device's IP address, or if there is traffic of a protocol other than the TCP protocol with the device's IP address as the source or destination (destination).

(Rule 1-5)
The number of outgoing flows is equal to or greater than the threshold T6, the TP that is the outgoing SrcPort is not a dynamic port, the outgoing DstPort is a dynamic port, and the proportion of the port numbers TP is equal to or greater than the threshold T7.
Conditional expression: Outgoing_flow_count>T6 AND Outgoing_SrcPort_TP_NOT_DynamicPort AND Outgoing_DstPort_IS_DynamicPort AND Outgoing_SrcPort_TP_rate>T7
Rules 1-5 become more effective as the sampling rate for sampling traffic increases.

If only incoming traffic records exist, the open port determination unit 12 makes a determination according to rule 2-1 below. However, the conditional expression in parentheses is optional and does not have to be used.

(Rule 2-1)
The number of incoming flows is equal to or greater than the threshold T8, the TCPFlag of the incoming flow whose Destination Port is TP includes both SYN and TCP, and the proportion of the port number TP is equal to or greater than the threshold T9.
Conditional expression: Incoming_flow_count>Threshold T10 AND Incoming_DstPort_TP_TCPFlag_SYN AND Incoming_DstPort_TP_TCPFlag_ACK AND Incoming_DstPort_TP_rate>Threshold T11 (AND Outgoing_flow_count=0)

If only outgoing traffic records exist, the open port determination unit 12 makes a determination according to rule 3-1 below. However, the conditional expression in parentheses is optional and does not have to be used.

(Rule 3-1)
The number of outgoing flows is equal to or greater than the threshold T12, the TCPFlag of a flow whose outgoing SrcPort is TP includes both SYN and ACK, and the proportion of port number TP is equal to or greater than the threshold T13.
Conditional expression: Outgoing_flow_count>T12 AND Outgoing_SrcPort_TP_TCPFlag_SYN AND Outgoing_SrcPort_TP_TCPFlag_ACK AND Outgoing_SrcPort_TP_rate>T13 (AND Incoming_flow_count=0)

Rules 2-1 and 3-1 are effective when asymmetric routing exists or when the conditions at the observation point make it impossible to collect traffic data for both the incoming and outgoing directions.

In this way, the open port determination unit 12 can determine whether a port is open even if there is only traffic sent from the device's IP address or traffic sent to the device's IP address.

When the open port determination unit 12 determines that an open port exists in a device, it may actually send a scan packet to the port determined to be an open port and determine whether or not the port is an open port. This allows the open port determination unit 12 to more reliably determine whether or not a port is an open port.

Note that a method of actually scanning all ports to determine whether they are open ports requires a large amount of resources (processing time, etc.). By combining rule-based determination and determination by actual scanning, the open port determination unit 12 can make highly accurate determinations using limited resources.

[Device status determination]
The device state determination unit 13 determines whether an attack is being carried out on the device based on the characteristics of traffic that is sent to the device and is generated by accessing an open port.

The device status determination unit 13 determines whether the target device is under attack according to the following rules 4-1 and 4-2.

(Rule 4-1)
If the bps of incoming traffic to an open port is equal to or greater than the threshold T31, the device status determination unit 13 assumes that persistent scanning has been carried out for a long period of time and determines that an attack such as a vulnerability attack or a brute force attack is occurring.
Conditional expression: Incoming_DstPort_OP_bps > Threshold T31

(Rule 4-2)
If the incoming traffic volume for a short period of time is equal to or greater than the threshold T31, the device status determination unit 13 determines that the device is the target of a DDoS attack. Note that the device status determination unit 13 may add a condition that the outgoing traffic ratio is equal to or greater than the threshold T32, for example, and determine that the device is the target of a DDoS attack if the incoming traffic volume is relatively large compared to the outgoing traffic ratio.
Conditional expression: Incoming_DstPort_OP_bps>T31 (AND Incoming_Outgoing_byte_rate>T32)

If the short-term traffic volume in the outgoing direction is equal to or greater than the threshold T33, the device status determination unit 13 determines that the device is a springboard for a DDoS attack. Note that the device status determination unit 13 may add a condition that the traffic ratio in the incoming direction is equal to or greater than the threshold T34, for example, and determine that the device is a springboard for a DDoS attack if the traffic volume in the outgoing direction is relatively large compared to the traffic ratio in the incoming direction.
Conditional expression: Outgoing_SrcPort_OP_bps>T33 (AND Outgoing_Incoming_byte_rate>T34)

[Infection determination]
When it is determined that an attack is being performed on the device, the infection determination unit 14 determines whether or not the device is infected with malware.

If the sampled traffic contains traffic that originates from the IP address of the device and is destined for an IP address in a pre-specified block (e.g., the IP address of a suspicious server suspected of being malicious), the infection determination unit 14 determines that the device is infected with malware.

Even if a device is communicating with a malicious IP address, this does not necessarily mean that the device is infected with malware. For example, a device may only be subject to scans, vulnerability attacks, or DDoS attacks from a malicious IP address, and may not be infected.

The infection determination unit 14 can determine whether or not a device is infected with malware by focusing on callbacks from malicious IP addresses using rule-based determination based on the following rules 5-1 to 5-4.

(Rule 5-1)
If traffic data with TCPFlag=SYN is present in the direction of MA, which is a malicious IP address (outgoing direction), the infection determination unit 14 determines that the device is infected. The infection determination unit 14 may also add a condition that the IP address of the device is not operating as a scanner (the ratio of TCPFlag=SYN in the outgoing direction is less than a threshold T41).
Conditional expression: Outgoing_DstIP_MA_TCPFlag_SYN (AND Outgoing_TCP_Flag_SYN_rate<T41)

(Rule 5-2)
If traffic data with TCPFlag=SYN or ACK from the malicious IP address MA (incoming direction) exists, the infection determination unit 14 determines that the device is infected. The infection determination unit 14 may also add a condition that the malicious IP address is not performing a SYN/ACK scan (the proportion of TCPFlags destined for the malicious IP address in the outgoing direction that exist is less than the threshold T42).
Conditional expression: Incoming_SrcIP_MA_TCPFlag_SYNACK (AND Outgoing_SrcIP_MA_TCPFlag_rate<T42)

(Rule 5-3)
If the number of traffic records with TCPFlag=ACK for both the device's IP address TA and the malicious IP address MA is greater than the thresholds (T43, T44), the infection determining unit 14 determines that the device is infected.
Conditional expression: Outgoing_DstIP_MA_TCPFlag_ACK_flow_num>T43 AND Incoming_SrcIP_MA_TCPFlag_ACK_flow_num>T44

(Rule 5-4)
If the amount of communication between the device's IP address TA and the malicious IP address MA is greater than the thresholds (T45, T46), the infection determination unit 14 determines that the device is infected. This is because it is considered that actual data transmission and reception has occurred, not just a connection attempt.
Condition: Outgoing_DstIP_MA_Bytes>T45 OR Incoming_SrcIP_MA_Bytes>T46

The processing flow of the monitoring device 10 will be explained using FIG. 6. FIG. 6 is a flowchart showing the processing flow of the monitoring device according to the first embodiment.

As shown in FIG. 6, first, the monitoring device 10 generates characteristics of the sampled traffic data (step S101).

Next, the monitoring device 10 determines whether or not the target device has an open port based on the characteristics (step S102).

If no open port exists (step S103, No), the monitoring device 10 outputs the result of the determination (step S107). In this case, the monitoring device 10 outputs information to notify that no open port exists.

If an open port exists (step S103, Yes), the monitoring device 10 determines whether the target device is under attack based on the characteristics (step S104).

If the monitoring device 10 determines that the target device is not under attack (step S105, No), it outputs the result of the determination (step S107). In this case, the monitoring device 10 outputs information to notify that the target device is not under attack, even though an open port exists.

If the monitoring device 10 determines that the target device is under attack (step S105, Yes), it determines whether the target device is infected with malware based on the characteristics (step S106). Then, the monitoring device 10 outputs the results of each determination (step S107).

[Effects of the First Embodiment]
As described above, the monitoring device 10 has a feature generation unit 11, an open port determination unit 12, an equipment status determination unit 13, and an infection determination unit 14. The feature generation unit 11 generates equipment features based on sampled traffic, which is at least one of traffic sent from the equipment and traffic sent to the equipment. The open port determination unit 12 determines whether or not the equipment has an open port based on the features. If the equipment has an open port, the equipment status determination unit 13 and the infection determination unit 14 determine the abnormality status of the equipment based on the features.

In this way, the monitoring device 10 determines open ports from the characteristics of the traffic. This allows the monitoring device 10 to perform more detailed abnormality determinations for devices suspected of having open ports from the limited traffic information obtained by sampling. As a result, the monitoring device 10 can effectively monitor devices using the sampled traffic.

The open port determination unit 12 determines whether or not an open port exists on the device when the sampled traffic does not contain any response traffic conforming to the TCP protocol from the device's IP address, when there is traffic of a protocol other than the TCP protocol with the device's IP address as the source or destination, or when there is only traffic sent from the device's IP address or traffic sent to the device's IP address.

As a result, the monitoring device 10 can determine whether a port is open even when there is insufficient TCP protocol traffic, or when only outgoing or incoming traffic is available.

The device status determination unit 13 determines whether an attack is being carried out on the device based on the characteristics of traffic sent to the device and generated by accessing an open port.

In this way, the monitoring device 10 can improve the efficiency of processing by determining the presence of a previous open port and determining whether an attack has occurred on a device suspected of having an open port.

If the infection determination unit 14 determines that an attack is being made on the device, it determines whether the device is infected with malware. For example, if the sampled traffic contains traffic whose source is the IP address of the device and whose destination is an IP address in a pre-specified block, the infection determination unit 14 determines that the device is infected with malware.

In this way, the monitoring device 10 can make processing more efficient by determining whether a previous attack has occurred before determining whether an infection has occurred.

Second Embodiment
In the first embodiment, the monitoring device 10 determines the presence of an open port and whether or not the device is under attack by a rule-based method, whereas in the second embodiment, the monitoring device 10 determines the presence of an open port and whether or not the device is under attack by using a machine learning technique.

FIG. 7 is a diagram showing an example of the configuration of an open port determination unit according to the second embodiment. As shown in FIG. 7, the open port determination unit 12 has a learning unit 121, detection model information 122, a detection unit 123, and an extraction unit 124.

The detection model information 122 is information for constructing a detection model, which is a machine learning model for detecting anomalies. Here, the detection model is, for example, one-class SVM, isolation forest, etc. The detection model information 122 is parameters for constructing the detection model.

The learning unit 121 learns the detection model using the characteristics of a device that is known to have an open port, or the characteristics of a device that is known to not have an open port. The learning unit 121 updates the detection model information 122 through learning.

The detection unit 123 inputs the traffic characteristics of a device, for which it is unknown whether or not an open port exists, into a detection model constructed based on the detection model information 122, and obtains the result of anomaly detection. The result of anomaly detection is whether or not an open port exists.

When the detection model detects the presence of an open port, the extraction unit 124 extracts the port number from the features that contributed to the detection. For example, the detection model uses the features generated by the feature generation unit 11 as explanatory variables. At this time, the extraction unit 124 identifies the feature with the highest contribution rate among the features related to the source port number in the outgoing direction (for example, features whose variable name includes "Outgoing_SrcPort"). The extraction unit 124 then extracts the port number based on that feature.

For example, if the extraction unit 124 identifies the feature Outgoing_SrcPort_TP_TCPFlag_SYNACK, it extracts port numbers that satisfy the conditions related to this feature. In this case, the extraction unit 124 extracts source ports of traffic records in the outgoing direction where the TCPFlag is SYN or ACK.

FIG. 8 is a diagram showing an example of the configuration of the device state determination unit according to the second embodiment. As shown in FIG. 8, the device state determination unit 13 has a learning unit 131, determination model information 132, and a determination unit 133.

The judgment model information 132 is information for constructing a judgment model, which is a machine learning model for making judgments. Here, the judgment model makes two patterns of judgment, success or failure, so it may be a model similar to a detection model that detects anomalies (e.g., one-class SVM, isolation forest, etc.). The judgment model information 132 is parameters for constructing the judgment model.

The learning unit 131 learns the judgment model using traffic data when it was possible to log in to the honeypot (when the vulnerability attack was successful) and traffic data when it was impossible to log in to the honeypot (when the vulnerability attack failed). The learning unit 131 updates the judgment model information 132 through learning.

The determination unit 133 inputs the characteristics of the traffic of a device, for which it is unknown whether it is under attack or not, or whether the attack has been successful or unsuccessful, into a determination model constructed based on the determination model information 132, and obtains a determination result. The determination result is whether or not the device is under attack.

In this way, the device status determination unit 13 can determine whether the sampled traffic was a successful attack on a device by using a machine learning model that has learned the characteristics of traffic that resulted in successful attacks on a honeypot and the characteristics of traffic that resulted in unsuccessful attacks on a honeypot.

[System configuration, etc.]
In addition, each component of each device shown in the figure is functionally conceptual, and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or a part of it can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc. Furthermore, each processing function performed by each device can be realized in whole or in part by a CPU (Central Processing Unit) and a program analyzed and executed by the CPU, or can be realized as hardware by wired logic. Note that the program may be executed not only by the CPU but also by other processors such as a GPU.

Furthermore, among the processes described in this embodiment, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods. In addition, the information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified.

[program]
In one embodiment, the monitoring device 10 can be implemented by installing a monitoring program that executes the above-mentioned collection process as package software or online software on a desired computer. For example, the above-mentioned monitoring program can be executed by an information processing device, causing the information processing device to function as the monitoring device 10. The information processing device here includes desktop or notebook personal computers. In addition, the information processing device also includes mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone Systems), as well as slate terminals such as PDAs (Personal Digital Assistants).

The monitoring device 10 can also be implemented as a scan server device that treats a terminal device used by a user as a client and provides services related to the above-mentioned scan processing to the client. For example, the scan server device is implemented as a server device that provides a scan service that takes seed information and IPv4 statistical information as input and outputs scan results. In this case, the scan server device may be implemented as a web server, or as a cloud that provides services related to the above-mentioned scan processing through outsourcing.

FIG. 9 is a diagram showing an example of a computer that executes a monitoring program. The computer 1000 has, for example, a memory 1010 and a CPU 1020. The computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. Each of these components is connected by a bus 1080.

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

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

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

The program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a LAN (Local Area Network), WAN (Wide Area Network)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.

N network 1 network system 10 monitoring device 11 feature generation unit 12 open port determination unit 13 device state determination unit 14 infection determination unit 15 display unit 16 rule DB
121, 131 Learning unit 122 Detection model information 123 Detection unit 124 Extraction unit 132 Judgment model information 133 Judgment unit

Claims (8)

a feature generation unit that generates a feature of the device based on at least one of sampled traffic, the sampled traffic being in a direction from the device and a direction to the device;
an open port determination unit that determines whether or not an open port exists in the device based on the characteristics;
an anomaly determination unit that determines an anomaly state of the device based on the characteristics when an open port exists in the device;
A monitoring device comprising: The monitoring device described in claim 1, characterized in that the open port determination unit determines whether or not an open port exists on the device when the sampled traffic does not contain any response traffic according to the TCP protocol from the IP address of the device, when there is traffic of a protocol other than the TCP protocol with the IP address of the device as the source or destination, or when there is only traffic sent from the IP address of the device or traffic sent to the IP address of the device. The monitoring device according to claim 1, characterized in that the abnormality determination unit determines whether an attack is being made against the device based on characteristics of traffic that is sent to the device and is generated by accessing the open port. The monitoring device according to claim 3 , wherein the abnormality determination unit, when determining that an attack is being performed on the device, determines whether or not the device is infected with malware. The monitoring device according to claim 4, characterized in that the abnormality determination unit determines that the device is infected with malware when the sampled traffic contains traffic whose source is the IP address of the device and whose destination is an IP address in a pre-specified block. The monitoring device according to claim 1, characterized in that the anomaly determination unit determines whether the sampled traffic has successfully attacked the device using a machine learning model that has learned the characteristics of traffic that has resulted in successful attacks on a honeypot and the characteristics of traffic that has resulted in unsuccessful attacks on a honeypot. A monitoring method performed by a monitoring device, comprising:
a feature generation step of generating a feature of the device based on at least one of the sampled traffic, the sampled traffic being in a direction away from the device and in a direction towards the device;
an open port determination step of determining whether or not an open port exists in the device based on the characteristics;
an anomaly determination step of determining an anomaly state of the device based on the characteristics when an open port exists in the device;
A monitoring method comprising: a feature generation step of generating a feature of the device based on at least one of the sampled traffic, the sampled traffic being in a direction away from the device and/or in a direction towards the device;
an open port determination step of determining whether or not an open port exists in the device based on the characteristics;
an anomaly determination step of determining an anomaly state of the device based on the characteristics if an open port exists in the device;
A monitoring program that causes a computer to execute the above.

Images