WO2022176128A1 - 分析装置、分析システム、分析方法、および、分析プログラム - Google Patents

分析装置、分析システム、分析方法、および、分析プログラム Download PDF

Info

Publication number
WO2022176128A1
WO2022176128A1 PCT/JP2021/006186 JP2021006186W WO2022176128A1 WO 2022176128 A1 WO2022176128 A1 WO 2022176128A1 JP 2021006186 W JP2021006186 W JP 2021006186W WO 2022176128 A1 WO2022176128 A1 WO 2022176128A1
Authority
WO
WIPO (PCT)
Prior art keywords
normal communication
model
communication model
cluster
sensor
Prior art date
Application number
PCT/JP2021/006186
Other languages
English (en)
French (fr)
Inventor
貴大 温品
一凡 張
幸雄 永渕
高明 小山
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to US18/276,644 priority Critical patent/US20240129202A1/en
Priority to JP2023500242A priority patent/JPWO2022176128A1/ja
Priority to PCT/JP2021/006186 priority patent/WO2022176128A1/ja
Publication of WO2022176128A1 publication Critical patent/WO2022176128A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection

Definitions

  • the present invention relates to an analysis device, an analysis system, an analysis method, and an analysis program.
  • a network traffic sensor learns a normal communication model that indicates normal communication using the number of packets sent and the number of destination IP addresses in communication from an IoT device as feature quantities. Then, the sensor uses the learned normal communication model to detect abnormal communication behavior caused by, for example, malware infection of the IoT device.
  • the normal distribution is used for each model of target IoT device to learn various feature values during normal communication.
  • the sensor starts learning a normal communication model using various feature values of the communication of the IoT device, and when it determines that the communication behavior has stabilized, it ends learning the normal communication model (see Patent Document 1). . Then, the sensor detects an abnormality in the communication of the IoT device using the learned normal communication model.
  • a sensor when a sensor detects an abnormality in IoT device communication based on a normal communication model, it investigates the detection alert information. Then, when the detected communication is found to be normal communication, the sensor administrator or the like updates the normal communication model in order to prevent the recurrence of overdetection.
  • the administrator may not be able to update the normal communication model appropriately, and over-detection may occur again.
  • an object of the present invention is to solve the above-described problems and to support the application of an appropriate normal communication model in sensors.
  • the present invention provides a normal traffic sensor used for monitoring the communication of an IoT (Internet of Things) device, which indicates the characteristics of normal communication of the IoT device, from each network traffic sensor that monitors the communication of the IoT device.
  • an acquiring unit that acquires a communication model, clusters a group of normal communication models related to the same feature value from among the group of normal communication models that have been acquired, and uses the clustering result to determine a cluster that has the largest number of normal communication models.
  • a calculation unit that calculates a group cluster and calculates an average model of a group of normal communication models belonging to the majority cluster; It is characterized by comprising a notification unit for notifying of belonging information indicating whether or not the model belongs and the average model.
  • FIG. 1 is a diagram illustrating an outline of a system including an analysis device (server) of this embodiment.
  • FIG. 2 is a diagram illustrating a configuration example of a server.
  • FIG. 3 is a diagram showing a configuration example of a sensor.
  • FIG. 4 is a diagram for explaining the generation of normal communication models and the definition of differences between normal communication models.
  • FIG. 5 is a diagram illustrating success and failure in learning a normal communication model.
  • FIG. 6 is a diagram illustrating an example of the processing procedure of the learning phase of the system when the sensor has successfully learned the normal communication model.
  • FIG. 7 is a diagram illustrating an example of the processing procedure of the learning phase of the system when the sensor fails to learn the normal communication model.
  • FIG. 1 is a diagram illustrating an outline of a system including an analysis device (server) of this embodiment.
  • FIG. 2 is a diagram illustrating a configuration example of a server.
  • FIG. 3 is a diagram showing a configuration example of a sensor.
  • FIG. 8 is a diagram illustrating an example of a processing procedure in the operation phase of the system.
  • FIG. 9 is a diagram illustrating an example of the processing procedure of the learning phase of the system when the sensor has successfully learned the normal communication model.
  • FIG. 10 is a diagram illustrating an example of the processing procedure of the learning phase of the system when the sensor fails to learn the normal communication model.
  • FIG. 11 is a diagram illustrating an example of a processing procedure in the operation phase of the system.
  • FIG. 12 is a diagram showing a configuration example of a computer that executes an analysis program.
  • An analysis system (system) 1 includes a plurality of network traffic sensors (sensors) 20 and a server 100 .
  • the sensor 20 has a normal communication model that indicates the characteristics of normal communication for each model of IoT (Internet of Things) device and for each feature amount.
  • the feature quantities used in this normal communication model are, for example, the number of packets sent per hour, the number of destination IP addresses, the port number, the number of bytes of packets, etc., in the communication of the IoT device.
  • the senor 20 learns a normal communication model for each feature value of communication for each model of the monitored IoT device, and uses the learned normal communication model to determine whether the communication of the monitored IoT device is normal. monitor what
  • the sensor 20 learns a normal communication model regarding the number of destination IPs (the number of destination IP addresses) in the communication of the IoT device of model A, and uses the learned normal communication model to determine whether the communication of the IoT device of model A is normal. Monitor whether or not
  • the server 100 acquires the normal communication model of the IoT device from each sensor 20. Then, the server 100 clusters the obtained normal communication model group so that mutually similar models belong to the same cluster.
  • the server 100 clusters the obtained normal communication model group regarding the number of destination IPs of IoT devices of model A into clusters 1, 2, and 3 shown in FIG. Then, the server 100 calculates the cluster (majority cluster) to which the largest number of normal communication model groups belong among these clusters.
  • the server 100 notifies each of the sensors 20 from which the normal communication model was obtained whether the normal communication model obtained from the sensor 20 belongs to the majority cluster.
  • the server 100 also calculates the average model of the normal communication model group belonging to the majority cluster, and notifies each of the sensors 20 of the calculated average model.
  • the server 100 can notify each sensor 20 whether or not the normal communication model held by the sensor 20 is appropriate. Also, the server 100 can notify each sensor 20 of an appropriate normal communication model.
  • the server 100 includes a communication section 110 , a storage section 120 and a control section 130 .
  • the communication unit 110 is an interface for data communication with an external device (for example, the sensor 20) via a network.
  • the storage unit 120 stores data referred to when the control unit 130 executes various processes and data generated by the control unit 130 .
  • the storage unit 120 stores the normal communication model acquired from each sensor 20 and the cluster information generated by the control unit 130 (the result of clustering the normal communication model group, the information indicating the majority cluster, etc.). do.
  • the storage unit 120 stores information on the normal communication model applied by each sensor 20 .
  • Control unit 130 controls the entire server 100.
  • Control unit 130 includes acquisition unit 131 , calculation unit 132 , determination unit 133 , and notification unit 134 .
  • the acquisition unit 131 acquires from the sensor 20 a normal communication model that is used by the sensor 20 to monitor communication of IoT devices.
  • the normal communication model for example, as indicated by reference numeral 401 in "(2) Generation of normal communication model" in FIG. be.
  • the normal communication model includes identification information of the model of the target IoT device, feature values used for calculating statistical values (for example, src_pkts (the number of transmitted IP packets)), and the distribution type of statistical values. (eg, normal (normal distribution)), parameters (eg, mean and standard deviation), and other information.
  • src_pkts the number of transmitted IP packets
  • distribution type of statistical values e.g, normal (normal distribution)
  • parameters eg, mean and standard deviation
  • the calculation unit 132 clusters a group of normal communication models related to the same model and the same feature amount among the normal communication models acquired by the acquisition unit 131 . For example, when the acquisition unit 131 acquires a new normal communication model, the calculation unit 132 clusters a group of normal communication models including the normal communication model and related to the same model and the same feature amount as the normal communication model.
  • the calculation unit 132 calculates the majority cluster, which is the cluster with the largest number of normal communication models belonging to the cluster, based on the above clustering results. Further, the calculation unit 132 calculates the average model of the normal communication model group belonging to the majority cluster. For example, the calculation unit 132 calculates the normal communication model corresponding to the center of gravity of the normal communication model group belonging to the majority cluster as the average model.
  • the calculation unit 132 clusters the normal communication model group, for example, KL divergence is used. For example, as shown in "(3) Definition of differences between normal communication models" in FIG. (KL divergence. See formula (1)). Then, the calculation unit 132 performs clustering so that mutually similar normal communication model groups belong to the same cluster.
  • the calculation unit 132 when the acquisition unit 131 acquires the normal communication model after the parameter update from the sensor 20, the calculation unit 132 includes the normal communication model after the parameter update, and calculates the The normal communication model group is clustered again. Then, the calculation unit 132 recalculates the majority cluster using the above clustering result. Further, the calculation unit 132 recalculates the average model of the normal communication model group belonging to the majority cluster after recalculation.
  • the determination unit 133 determines whether the normal communication model acquired by the acquisition unit 131 belongs to the majority cluster calculated by the calculation unit 132 .
  • the notification unit 134 transmits information indicating the result of determination by the determination unit 133 (attribution information to the majority cluster) and the average model of the group of normal communication models belonging to the majority cluster calculated by the calculation unit 132, The sensor 20 from which the normal communication model was obtained is notified.
  • the determination unit 133 determines whether each normal communication model acquired from each sensor 20 belongs to the recalculation majority cluster. Then, when the determination unit 133 determines that any normal communication model does not belong to the majority cluster after recalculation, the notification unit 134 notifies the sensor 20 from which the normal communication model was acquired that Notify that the normal communication model is out of the majority cluster and the average model after recalculation.
  • the sensor 20 includes a communication section 21 , a storage section 22 and a control section 23 .
  • the communication unit 21 is an interface for performing data communication with an external device (for example, IoT device, server 100) via a network.
  • the storage unit 22 stores data referred to when the control unit 23 executes various processes and data generated by the control unit 23.
  • the storage unit 22 stores the normal communication model generated by the control unit 23 and the average model received from the server 100 .
  • the control unit 23 includes a learning unit 231 , a monitoring unit 232 , a transmission/reception unit 233 , a determination unit 234 and a model management unit 235 .
  • the learning unit 231 is based on the characteristic amount of the communication data of the monitored IoT device acquired via the communication unit 21 (for example, the number of packets sent per hour, the IP address of the communication destination, the port number, the number of bytes in the packet, etc.). , to learn the normal communication model.
  • the learned normal communication model is stored in the storage unit 22 .
  • a learning example of a normal communication model will be described with reference to FIG.
  • learning (generating) a normal communication model regarding the number of transmission packets of an IoT device of model A will be described.
  • the learning unit 231 counts the statistics of the communication data of the model A IoT device ((1)). For example, the learning unit 231 counts the number of packets transmitted from the model A IoT device per hour.
  • the learning unit 231 generates a normal communication model based on the result of counting the statistics of the communication data of the IoT device of model A obtained in (1) ((2)). For example, the learning unit 231 obtains statistical values of the frequency of appearance of the number of packets transmitted per hour based on the number of packets transmitted per hour of the IoT device of model A obtained in (1), and the statistics are indicated by reference numerals 401 and 402. Generate a normal communication model.
  • the learning unit 231 may fail to learn the normal communication model. For example, if a temporary change occurs in communication behavior during the learning period of the normal communication model, the learning unit 231 cannot learn the normal communication model. In other words, the learning unit 231 may fail to learn the normal communication model. In this case, the transmitter/receiver 233 notifies the server 100 that the sensor 20 has failed to learn the normal communication model.
  • the monitoring unit 232 uses the normal communication model or the average model in the storage unit 22 to monitor communication of the monitored IoT device. For example, the monitoring unit 232 uses the normal communication model to monitor whether the communication of the monitored IoT device is normal. Note that the monitoring unit 232 may monitor communication by combining a normal communication model and an abnormal communication model (a model showing characteristics of abnormal communication) when monitoring the communication of the IoT device.
  • an abnormal communication model a model showing characteristics of abnormal communication
  • the transmission/reception unit 233 transmits and receives various data to and from the server 100 .
  • the transmission/reception unit 233 sends the new normal communication model or the updated normal communication model to the server 100. Send.
  • the transmitting/receiving unit 233 transmits information to the effect that learning of the normal communication model has failed to the server 100 .
  • This information is, for example, information indicating whether the learning unit 231 has failed to learn a normal communication model for which feature amount of which model of IoT device.
  • the transmitting/receiving unit 233 also receives from the server 100 a notification as to whether or not the normal communication model being applied by its own sensor 20 belongs to the majority cluster (attribution information to the majority cluster).
  • the transmitting/receiving unit 233 also receives from the server 100 the average model of the normal communication model group belonging to the majority cluster.
  • the determination unit 234 determines whether or not to change the normal communication model being applied by its own sensor 20.
  • the determination unit 234 determines that the currently applied normal communication model belongs to the majority cluster. It is determined that the normal communication model is applied as it is.
  • the normal communication model is updated or the average model received from the server 100 is applied. . Whether to update the normal communication model or apply the average model is determined, for example, by an instruction input by the administrator of the sensor 20 or the like.
  • the model management unit 235 manages the normal communication model applied by the monitoring unit 232. For example, when an administrator or the like of the sensor 20 inputs an instruction to update the normal communication model via the communication unit 21, the model management unit 235 causes the learning unit 231 to learn the normal communication model again. . Then, the model management unit 235 changes the normal communication model applied by the monitoring unit 232 to the re-learned normal communication model.
  • the model management unit 235 applies Change normal communication model to average model.
  • the learning unit 231 connects to the IoT device of model A ((1): device connection), and learns a normal communication model based on the feature amount of the communication data of the IoT device ((2): learning).
  • the learning unit 231 can generate a normal communication model ( (3): Generation of normal communication model). That is, the learning unit 231 succeeds in learning the normal communication model.
  • the learning unit 231 can generate a normal communication model. Can not. In other words, the learning unit 231 fails to learn the normal communication model.
  • the processing procedure of the system 1 is divided into (1) learning phase and (2) operation phase.
  • the learning phase is, for example, a phase in which a new sensor 20 is added to the system 1 and a normal communication model learned by the sensor 20 is added to the server 100 .
  • the operation phase is a phase in which the normal communication model is updated in the existing sensors 20 in the system 1 and the updated normal communication model is added to the server 100 .
  • the sensor 20 acquires communication data of the IoT device (model A IoT device).
  • the sensor 20 learns a normal communication model for the number of packets sent by the IoT device of model A by performing statistical processing on the feature values of the acquired communication data.
  • the sensor 20 After successfully learning the normal communication model, the sensor 20 transmits the learned normal communication model (determination target model) to the server 100 .
  • the server 100 clusters a group of normal communication models for the number of packets sent by IoT devices of model A, including the determination target model sent from the sensor 20 . Then, the server 100 uses the clustering result to calculate the majority cluster, and calculates the average model of the normal communication model group belonging to the majority cluster.
  • the server 100 notifies the sensor 20 of the following contents according to the clustering result of the normal communication model group.
  • the administrator of the sensor 20 can confirm that there is no problem in applying the normal communication model learned by the sensor 20.
  • the server 100 determines that the determination target model does not belong to the majority cluster, it notifies the sensor 20 from which the determination target model was acquired that the determination target model does not belong to the majority cluster. Notify attribution information.
  • the sensor 20 can acquire an appropriate normal communication model (average model).
  • the sensor 20 acquires communication data of the IoT device (model A IoT device).
  • the sensor 20 learns a normal communication model for the number of packets sent by the IoT device of model A by performing statistical processing on the feature values of the acquired communication data.
  • the sensor 20 transmits information to the server 100 to the effect that learning of the normal communication model has failed.
  • the information is, for example, information indicating that learning of the normal communication model regarding the number of packets transmitted by the model A IoT device has failed.
  • the server 100 clusters the normal communication model group for the number of transmitted packets of the IoT devices of model A, calculates the majority cluster using the clustering result, and calculates the number of normal communication model groups belonging to the majority cluster. Calculate the average model.
  • the server 100 transmits the average model calculated in (4) to the sensor 20 .
  • the sensor 20 can acquire an appropriate normal communication model (average model).
  • the sensor 20B updates the parameters of the normal communication model for the number of packets sent by the model A IoT device.
  • the sensor 20B transmits the updated normal communication model to the server 100.
  • the server 100 clusters again the normal communication model group of the number of transmitted packets of the IoT devices of model A, including the updated normal communication model transmitted from the sensor 20B.
  • the server 100 also uses the clustering result to recalculate the majority cluster, and recalculates the average model of the normal communication model group belonging to the majority cluster.
  • the server 100 assigns the normal communication model to the sensor 20 (for example, the sensor 20A) from which the normal communication Notify that the communication model is out of the majority cluster.
  • the server 100 notifies the calculated average model of the majority cluster to the sensor 20 (for example, the sensor 20A) from which the normal communication model was obtained.
  • the notification to the effect that the normal communication model has deviated from the majority cluster may include information indicating how much the normal communication model has deviated from the majority cluster.
  • the learning unit 231 learns a normal communication model (S11). After completing the learning of the normal communication model, the sensor 20 determines whether or not to permit cooperation with the server 100 (S12). For example, when the sensor 20 receives an input from the administrator of the sensor 20 to the effect that cooperation with the server 100 is permitted, the sensor 20 determines that cooperation with the server 100 is permitted (Yes in S12). Then, the transmitter/receiver 233 of the sensor 20 transmits the authentication information of the server 100 and the normal communication model learned in S11 to the server 100 (S13).
  • the learning unit 231 of the sensor 20 learns the normal communication model by the sensor 20 alone (S24).
  • the acquisition unit 131 of the server 100 receives the server authentication information and the normal communication model from the sensor 20, it registers the cooperation permission information of the sensor 20 in the storage unit 120 (S14). Then, the calculation unit 132 of the server 100 clusters the normal communication model group including the normal communication model transmitted in S13 (S15). The calculation unit 132 also calculates the majority cluster using the clustering result, and calculates the average model of the majority cluster. Furthermore, the determination unit 133 determines whether the normal communication model transmitted in S13 belongs to the majority cluster.
  • the notification unit 134 of the server 100 sends the result of determination by the determination unit 133 (attribution information of the normal communication model to the majority cluster) to the sensor 20 that is the transmission source of the normal communication model transmitted in S13. and the average model are transmitted (S16).
  • the transmitting/receiving unit 233 of the sensor 20 receives from the server 100 the information on belonging to the majority cluster and the average model regarding the normal communication model transmitted in S13 (S17: acquire information from the server). After that, the determination unit 234 determines whether or not to use the average model based on the belonging information to the majority cluster received in S17 (S18).
  • the determination unit 234 determines to use the average model (Yes in S18). . Then, the model management unit 235 changes the normal communication model applied by the monitoring unit 232 to the average model (S19: apply the average model). After that, the process proceeds to S21.
  • the determination unit 234 determines not to use the average model (No in S18). Then, the model management unit 235 sets the normal communication model to be applied by the monitoring unit 232 to the normal communication model learned in S11 (S20: apply the learned normal communication model). After that, the process proceeds to S21.
  • the transmission/reception unit 233 transmits the application information of the normal communication model to the server 100 (S21).
  • This normal communication model application information is, for example, information indicating whether the sensor 20 applies the normal communication model learned by the sensor 20 or the average model.
  • the sensor 20 transmits application information of the normal communication model including the learned normal communication model.
  • the acquiring unit 131 of the server 100 acquires the normal communication model information (the normal communication model applied by each sensor 20) of the storage unit 120 based on the application information of the normal communication model transmitted from the sensor 20 in S21. information) is updated (S22). After that, the process proceeds to S41 in FIG. The processing of S41 in FIG. 11 will be described later.
  • the administrator of the sensor 20 can know whether the normal communication model learned by the sensor 20 is appropriate. Also, if the normal communication model learned by the sensor 20 is not appropriate, an appropriate normal communication model (average model) can be acquired.
  • the learning unit 231 learns a normal communication model (S31).
  • the sensor 20 determines whether or not to permit cooperation with the server 100 (S32). For example, when the sensor 20 receives an input from the administrator of the sensor 20 to the effect that cooperation with the server 100 is permitted, the sensor 20 determines that cooperation with the server 100 is permitted (Yes in S32).
  • this normal communication model learning failure information is information indicating which model of IoT device and which feature value related to which normal communication model learning has failed.
  • the sensor 20 detects an abnormality of the IoT device by another means, for example (S40).
  • the acquisition unit 131 of the server 100 receives the server authentication information and the normal communication model from the sensor 20, it registers the cooperation permission information of the sensor 20 in the storage unit 120 (S34). After that, the notification unit 134 reads out the average model of the normal communication model of the model and the feature quantity indicated in the learning failure information of the normal communication model from the storage unit 120, and transmits it to the sensor 20 (S35).
  • the transmitter/receiver 233 of the sensor 20 receives the average model from the server 100 (S36: information acquisition from the server). After that, the model management unit 235 applies the average model received in S36 as the normal communication model used by the monitoring unit 232 (S37). Then, the transmission/reception unit 233 transmits application information of the normal communication model to the server 100 (S38).
  • the acquisition unit 131 of the server 100 updates the normal communication model information in the storage unit 120 based on the normal communication model application information transmitted from the sensor 20 in S38 (S39). After that, the process proceeds to S41 in FIG. The processing of S41 in FIG. 11 will be described later.
  • the system 1 can acquire an appropriate normal communication model (average model) even if the sensor 20 fails to learn the normal communication model.
  • the calculation unit 132 receives the updated normal communication model and the updated normal communication model.
  • the normal communication model group regarding the same model and the same feature value is clustered again.
  • the calculation unit 132 calculates the majority cluster again using the clustering result.
  • the calculation unit 132 also calculates the average model of the majority cluster again.
  • the determination unit 133 of the server 100 determines whether or not there is a normal communication model outside the majority cluster as a result of the processing of S42 (S43).
  • the process returns to S41.
  • the notification unit 134 sends the sensor 20, which is the transmission source of the normal communication model that is out of the majority cluster, The membership information to the majority cluster and the average model are transmitted (S44). After that, the process proceeds to S45.
  • the belonging information to the majority cluster transmitted in S44 is information indicating that the normal communication model applied by the sensor 20 is out of the majority cluster. Also, the belonging information to the majority cluster may include a value indicating how far the normal communication model deviates from the majority cluster. Since the processing of S45 to S50 is the same as the processing of S17 to S22 in FIG. 9, the description thereof is omitted.
  • the administrator of the sensor 20 can know whether or not the normal communication model learned by the sensor 20 is no longer appropriate. Also, when the normal communication model learned by the sensor 20 is no longer appropriate, the sensor 20 can acquire an appropriate normal communication model (average model).
  • the server 100 sends the majority cluster belonging information and the average model However, it is not limited to this.
  • the notification unit 134 of the server 100 notifies the majority cluster belonging information to the sensor 20 from which the normal communication model belonging to the majority cluster was acquired, and obtains the normal communication model that does not belong to the majority cluster.
  • the original sensor 20 may be informed of the majority cluster membership information and mean model.
  • the notification unit 134 of the server 100 may not notify the average model to the sensor 20 from which the normal communication model belonging to the majority cluster was acquired.
  • the notification unit 134 of the server 100 notifies the sensor 20 of the belonging information of the majority cluster, but is not limited to this. For example, the notification unit 134 notifies the sensor 20 that if the normal communication model learned by the sensor 20 belongs to the majority cluster, there is no problem in applying the normal communication model. If it does not belong, it may notify that the normal communication model needs to be re-learned or updated.
  • each constituent element of each part shown in the figure is functionally conceptual, and does not necessarily need to be physically configured as shown in the figure.
  • the specific form of distribution and integration of each device is not limited to the illustrated one, and all or part of them can be functionally or physically distributed and integrated in arbitrary units according to various loads and usage conditions. Can be integrated and configured.
  • all or any part of each processing function performed by each device can be implemented by a CPU and a program executed by the CPU, or implemented as hardware based on wired logic.
  • the server 100 described above can be implemented by installing a program on a desired computer as package software or online software.
  • the information processing device can function as the server 100 by causing the information processing device to execute the above program.
  • the information processing apparatus referred to here includes a desktop or notebook personal computer.
  • information processing devices include mobile communication terminals such as smartphones, mobile phones and PHS (Personal Handyphone Systems), and terminals such as PDAs (Personal Digital Assistants).
  • the server 100 can also be implemented as a server device that uses a terminal device used by a user as a client and provides the client with services related to the above processing.
  • the server device may be implemented as a web server, or may be implemented as a cloud that provides services related to the above processing by outsourcing.
  • FIG. 12 is a diagram showing an example of a computer that executes an analysis program.
  • the computer 1000 has a memory 1010 and a CPU 1020, for example.
  • Computer 1000 also has hard disk drive interface 1030 , disk drive interface 1040 , serial port interface 1050 , video adapter 1060 and network interface 1070 . These units are 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 BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • Hard disk drive interface 1030 is connected to hard disk drive 1090 .
  • a disk drive interface 1040 is connected to the disk drive 1100 .
  • a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100 .
  • Serial port interface 1050 is connected to mouse 1110 and keyboard 1120, for example.
  • Video adapter 1060 is connected to display 1130, for example.
  • the hard disk drive 1090 stores, for example, an OS 1091, application programs 1092, program modules 1093, and program data 1094. That is, the program that defines each process executed by the server 100 is implemented as a program module 1093 in which computer-executable code is described.
  • Program modules 1093 are stored, for example, on hard disk drive 1090 .
  • the hard disk drive 1090 stores a program module 1093 for executing processing similar to the functional configuration in the server 100 .
  • the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).
  • the data used in the processes of the above-described embodiments are stored as program data 1094 in the memory 1010 or the hard disk drive 1090, for example. Then, the CPU 1020 reads out the program modules 1093 and program data 1094 stored in the memory 1010 and the hard disk drive 1090 to the RAM 1012 as necessary and executes them.
  • the program modules 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in a removable storage medium, for example, and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program modules 1093 and program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). Program modules 1093 and program data 1094 may then be read by CPU 1020 through network interface 1070 from other computers.
  • LAN Local Area Network
  • WAN Wide Area Network

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Artificial Intelligence (AREA)
  • Environmental & Geological Engineering (AREA)
  • Databases & Information Systems (AREA)
  • Evolutionary Computation (AREA)
  • Mathematical Analysis (AREA)
  • Algebra (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computing Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

サーバ（１００）は、IoTデバイスの通信を監視するセンサ（２０）から、正常通信モデルを取得する。次に、サーバ（１００）は、取得した正常通信モデルのうち、同じ機種、同じ特徴量に関する正常通信モデル群をクラスタリングする。そして、サーバ（１００）は、クラリタリングの結果を用いて、正常通信モデルの数が最も多いクラスタである多数派クラスタを算出し、多数派クラスタに属する正常通信モデル群の平均モデルを算出する。そして、サーバ（１００）は、当該正常通信モデルの取得元のセンサ（２０）に対し、当該正常通信モデルが多数派クラスタに属するか否かを示す帰属情報および平均モデルを通知する。

Description

分析装置、分析システム、分析方法、および、分析プログラム
　本発明は、分析装置、分析システム、分析方法、および、分析プログラムに関する。
　従来、IoT（Internet　of　Things）デバイスの通信の異常を検知する技術が提案されている。例えば、ネットワークトラフィックセンサ（以下、適宜、センサと略す）が、IoTデバイスからの通信における送信パケット数や宛先ＩＰアドレス数等を特徴量として用いて、正常な通信を示す正常通信モデルを学習する。そして、センサは、学習した正常通信モデルを用いて、例えば、IoTデバイスのマルウェア感染等によって発生する、異常な通信のふるまいを検知する。
　この正常通信モデルの学習においては、対象のIoTデバイスの機種ごとに、正規分布を利用して、正常な通信を行っているときの各種特徴量を学習する。例えば、センサは、IoTデバイスの通信の各種特徴量を用いて正常通信モデルの学習を開始し、通信の振る舞いが安定したと判断すると、当該正常通信モデルの学習を終了する（特許文献１参照）。そして、センサは、学習後の正常通信モデルを用いて、IoTデバイスの通信の異常を検知する。
特開2019-213103号公報
　従来、センサにおいて、正常通信モデルに基づき、IoTデバイスの通信の異常が検知されると、検知アラートの情報を調査する。そして、検知された通信が、正常な通信であることが判明すると、センサの管理者等は、過検知の再発を防ぐため正常通信モデルを更新する。
　その際、管理者が、正常通信モデルを更新すべきか否かを検知アラートの情報のみから判断をするのは、難しい場合もある。そのため、管理者は、正常通信モデルの適切な更新ができずに、過検知が再発してしまう可能性がある。
　また、従来技術において、通信データの特徴量のうち、時間的な増減が安定している特徴量については、正常通信モデルの学習に用いることができる。しかし、本来、正常通信モデルの学習に用いることができる特徴量であっても、学習期間中に、ユーザ操作の介在等で一時的に通信の振る舞いの変化が発生すると、正常通信モデルの学習ができない。この場合、当該特徴量を監視対象外にする、正常通信モデルの再学習を実施する等の対策が必要である。
　これらの問題に対し、例えば、正常通信モデルの学習時間を長くしたり、正常通信モデルの学習時になるべく多くの通信の振る舞いを観測したりする等の改善方法が考えられる。しかし、上記の方法は、正常ではない通信の振る舞いも学習してしまうリスクが高くなる。また、学習処理に伴いマシン負荷が増大するという問題もある。
　そこで、本発明は、前記した問題を解決し、センサにおける適切な正常通信モデルの適用を支援することを課題とする。
　前記した課題を解決するため、本発明は、IoT（Internet　of　Things）デバイスの通信を監視する各ネットワークトラフィックセンサから、前記通信の監視に用いられる、当該IoTデバイスの正常な通信の特徴を示す正常通信モデルを取得する取得部と、取得した前記正常通信モデル群のうち、同じ特徴量に関する正常通信モデル群をクラスタリングし、クラスタリングの結果を用いて、正常通信モデルの数が最も多いクラスタである多数派クラスタを算出し、前記多数派クラスタに属する正常通信モデル群の平均モデルを算出する算出部と、前記正常通信モデルの取得元のネットワークトラフィックセンサに対し、当該正常通信モデルが前記多数派クラスタに属するか否かを示す帰属情報および前記平均モデルを通知する通知部とを備えることを特徴とする。
　本発明によれば、センサにおける適切な正常通信モデルの適用を支援することができる。
図１は、本実施形態の分析装置（サーバ）を含むシステムの概要を説明する図である。 図２は、サーバの構成例を示す図である。 図３は、センサの構成例を示す図である。 図４は、正常通信モデルの生成と、正常通信モデル間の差異の定義とを説明する図である。 図５は、正常通信モデルの学習に成功および失敗について説明する図である。 図６は、センサが正常通信モデルの学習に成功した場合における、システムの学習フェーズの処理手順の例を説明する図である。 図７は、センサが正常通信モデルの学習に失敗した場合における、システムの学習フェーズの処理手順の例を説明する図である。 図８は、システムの運用フェーズの処理手順の例を説明する図である。 図９は、センサが正常通信モデルの学習に成功した場合における、システムの学習フェーズの処理手順の例を説明する図である。 図１０は、センサが正常通信モデルの学習に失敗した場合における、システムの学習フェーズの処理手順の例を説明する図である。 図１１は、システムの運用フェーズの処理手順の例を説明する図である。 図１２は、分析プログラムを実行するコンピュータの構成例を示す図である。
　以下、図面を参照しながら、本発明を実施するための形態（実施形態）について説明する。本発明は、以下に説明する実施形態に限定されない。
[概要]
　まず、図１を用いて、本実施形態の分析装置（サーバ）を含む分析システムの概要を説明する。分析システム（システム）１は、複数のネットワークトラフィックセンサ（センサ）２０と、サーバ１００とを備える。
　センサ２０は、IoT（Internet　of　Things）デバイスの機種ごと、特徴量ごとに正常な通信の特徴を示す正常通信モデルを備える。なお、この正常通信モデルに用いられる特徴量は、例えば、IoTデバイスの通信における、時間あたりの送信パケット数、宛先ＩＰアドレス数、ポート番号、パケットのバイト数等である。
　センサ２０は、例えば、監視対象とするIoTデバイスの機種ごとに通信の各特徴量に関する正常通信モデルを学習し、その学習した正常通信モデルを用いて、監視対象のIoTデバイスの通信が正常か否かを監視する。
　センサ２０は、例えば、機種ＡのIoTデバイスの通信における宛先ＩＰ数（宛先ＩＰアドレス数）に関する正常通信モデルを学習し、その学習した正常通信モデルを用いて、機種ＡのIoTデバイスの通信が正常か否かを監視する。
　サーバ１００は、センサ２０それぞれからIoTデバイスの正常通信モデルを取得する。そして、サーバ１００は、取得した正常通信モデル群について、互いに類似するもの同士が同じクラスタに属するよう、クラスタリングする。
　例えば、サーバ１００は、取得した機種ＡのIoTデバイスの宛先ＩＰ数に関する正常通信モデル群を、図１に示す、クラスタ１，２，３にクラスタリングする。そして、サーバ１００は、これらのクラスタのうち、最も多くの正常通信モデル群が属するクラスタ（多数派クラスタ）を算出する。
　その後、サーバ１００は、正常通信モデルの取得元のセンサ２０それぞれに対し、当該センサ２０から取得した正常通信モデルが多数派クラスタに属するか否かを通知する。
　また、サーバ１００は、多数派クラスタに属する正常通信モデル群の平均モデルを算出し、センサ２０それぞれに対し、算出した平均モデルを通知する。
　このようにすることで、サーバ１００は、各センサ２０に、当該センサ２０に保持される正常通信モデルが適切なものであるか否かを通知することができる。また、サーバ１００は、各センサ２０に適切な正常通信モデルを通知することができる。
［構成例］
［サーバ］
　次に、図２を用いて、サーバ１００の構成例を説明する。サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを備える。通信部１１０は、ネットワーク経由で外部装置（例えば、センサ２０）とのデータ通信を行う際のインタフェースである。
　記憶部１２０は、制御部１３０が各種処理を実行する際に参照するデータや、制御部１３０により生成されたデータを記憶する。例えば、記憶部１２０は、各センサ２０から取得された正常通信モデルや、制御部１３０により生成されたクラスタ情報（正常通信モデル群のクラスタリングの結果や、多数派クラスタ等を示した情報）を記憶する。また、例えば、記憶部１２０は、センサ２０ごとに当該センサ２０が適用している正常通信モデルの情報を記憶する。
　制御部１３０は、サーバ１００全体の制御を司る。制御部１３０は、取得部１３１と、算出部１３２と、判定部１３３と、通知部１３４とを備える。
　取得部１３１は、センサ２０から、当該センサ２０においてIoTデバイスの通信の監視に用いられる正常通信モデルを取得する。
　正常通信モデルは、例えば、図４の「（２）正常通信モデルの生成」の符号４０１に示すように、IoTデバイスにおける、単位時間あたりの送信パケット数の登場頻度の統計値を示したものである。
　正常通信モデルは、例えば、符号４０２に示すように、対象のIoTデバイスの機種の識別情報、統計値の算出に用いた特徴量（例えば、src_pkts（送信ＩＰパケット数））、統計値の分布種別（例えば、normal（正規分布））、パラメータ（例えば、平均値および標準偏差）等の情報を含んでいてもよい。
　図２の説明に戻る。算出部１３２は、取得部１３１により取得された正常通信モデルのうち、同じ機種、同じ特徴量に関する正常通信モデル群をクラスタリングする。例えば、取得部１３１により新たな正常通信モデルが取得されると、算出部１３２は、当該正常通信モデルを含む、当該正常通信モデルと同じ機種、同じ特徴量に関する正常通信モデル群をクラスタリングする。
　そして、算出部１３２は、上記のクラスタリングの結果に基づき、クラスタに属する正常通信モデルの数が最も多いクラスタである多数派クラスタを算出する。また、算出部１３２は、上記の多数派クラスタに属する正常通信モデル群の平均モデルを算出する。例えば、算出部１３２は、多数派クラスタに属する正常通信モデル群の重心に相当する正常通信モデルを平均モデルとして算出する。
　なお、算出部１３２が正常通信モデル群のクラスタリングを行う際には、例えば、KL　divergenceを用いる。例えば、図４の「（３）正常通信モデル間の差異の定義」に示すように、算出部１３２は、p(x)という正常通信モデルと、q(x)という正常通信モデルとをKL　div（KL　divergence。式（１）参照）で比較する。そして、算出部１３２は、互いに似た正常通信モデル群が同じクラスタに属するように、クラスタリングを行う。
Figure JPOXMLDOC01-appb-M000001
　また、取得部１３１が、センサ２０から、パラメータ更新後の正常通信モデルを取得した場合、算出部１３２は、パラメータ更新後の正常通信モデルを含む、当該正常通信モデルの特徴量と同じ特徴量に関する正常通信モデル群を、再度クラスタリングする。そして、算出部１３２は、上記のクラスタリングの結果を用いて、多数派クラスタを再算出する。また、算出部１３２は、再算出後の多数派クラスタに属する正常通信モデル群の平均モデルを再算出する。
　図２の説明に戻る。判定部１３３は、取得部１３１により取得された正常通信モデルが、算出部１３２により算出された多数派クラスタに属するか否かを判定する。また、通知部１３４は、判定部１３３による判定の結果を示す情報（多数派クラスタへの帰属情報）と、算出部１３２により算出された多数派クラスタに属する正常通信モデル群の平均モデルとを、当該正常通信モデルの取得元のセンサ２０に通知する。
　また、算出部１３２が多数派クラスタの再算出を行った場合、判定部１３３は、各センサ２０から取得した正常通信モデルそれぞれが、再算出後の多数派クラスタに属するか否かを判定する。そして、判定部１３３により、いずれかの正常通信モデルが、再算出後の多数派クラスタに属しないと判定された場合、通知部１３４は、当該正常通信モデルの取得元のセンサ２０に対し、当該正常通信モデルが多数派クラスタから外れた旨および再算出後の平均モデルを通知する。
[センサ]
　次に、図３を用いて、センサ２０の構成例を説明する。センサ２０は、通信部２１と、記憶部２２と、制御部２３とを備える。通信部２１は、ネットワーク経由で外部装置（例えば、IoTデバイス、サーバ１００）とのデータ通信を行う際のインタフェースである。
　記憶部２２は、制御部２３が各種処理を実行する際に参照するデータや、制御部２３により生成されたデータを記憶する。例えば、記憶部２２は、制御部２３により生成された正常通信モデルや、サーバ１００から受信した平均モデルを記憶する。
　制御部２３は、学習部２３１と、監視部２３２と、送受信部２３３と、判定部２３４と、モデル管理部２３５とを備える。
　学習部２３１は、通信部２１経由で取得した監視対象のIoTデバイスの通信データの特徴量（例えば、時間あたりの送信パケット数、通信先のＩＰアドレス、ポート番号、パケットのバイト数等）に基づき、正常通信モデルの学習を行う。学習された正常通信モデルは記憶部２２に格納される。
　図４を参照しながら、正常通信モデルの学習例について説明する。ここでは、例えば、機種ＡのIoTデバイスの送信パケット数に関する正常通信モデルを学習（生成）する場合について説明する。
　まず、学習部２３１は、機種ＡのIoTデバイスの通信データの統計量のカウントを行う（（１））。例えば、学習部２３１は、機種ＡのIoTデバイスの時間ごとの送信パケット数をカウントする。
　次に、学習部２３１は、（１）で得られた機種ＡのIoTデバイスの通信データの統計量をカウント結果に基づき、正常通信モデルを生成する（（２））。例えば、学習部２３１は、（１）で得られた機種ＡのIoTデバイスの時間ごとの送信パケット数に基づき、時間あたりの送信パケット数の登場頻度の統計値を求め、符号４０１，４０２に示す正常通信モデルを生成する。
　なお、学習部２３１は、正常通信モデルの学習に失敗する場合もある。例えば、正常通信モデルの学習期間中に通信の振る舞いに一時的な変化が発生すると、学習部２３１は正常通信モデルの学習ができない。つまり、学習部２３１は、正常通信モデルの学習に失敗する場合がある。その場合、送受信部２３３は、サーバ１００へ、当該センサ２０において正常通信モデルの学習に失敗した旨を通知する。
　図３の説明に戻る。監視部２３２は、記憶部２２の正常通信モデルまたは平均モデルを用いて、監視対象のIoTデバイスの通信を監視する。例えば、監視部２３２は、正常通信モデルを用いて、監視対象のIoTデバイスの通信が正常な通信か否かを監視する。なお、監視部２３２は、IoTデバイスの通信を監視する際、正常通信モデルと異常通信モデル（異常な通信の特徴を示すモデル）とを組み合わせて監視してもよい。
　送受信部２３３は、サーバ１００との間で各種データの送受信を行う。例えば、送受信部２３３は、学習部２３１が新たな正常通信モデルを学習した場合や、正常通信モデルのパラメータが更新された場合、新たな正常通信モデルやパラメータ更新後の正常通信モデルをサーバ１００へ送信する。
　また、送受信部２３３は、学習部２３１が正常通信モデルの学習に失敗した場合、正常通信モデルの学習に失敗した旨の情報をサーバ１００へ送信する。当該情報は、例えば、学習部２３１が、どの機種のIoTデバイスの、どの特徴量に関する正常通信モデルの学習に失敗したかを示す情報である。
　また、送受信部２３３は、サーバ１００から、自身のセンサ２０で適用中の正常通信モデルが多数派クラスタに属するか否かの通知（多数派クラスタへの帰属情報）を受信する。また、送受信部２３３は、サーバ１００から、当該多数派クラスタに属する正常通信モデル群の平均モデルを受信する。
　判定部２３４は、サーバ１００から受信した多数派クラスタの帰属情報に基づき、自身のセンサ２０で適用中の正常通信モデルを変更するか否かを判定する。
　例えば、当該帰属情報が、自身のセンサ２０が学習した正常通信モデル（つまり、適用中の正常通信モデル）が多数派クラスタに属することを示すものである場合、判定部２３４は、現在適用中の正常通信モデルをそのまま適用すると判定する。
　一方、例えば、当該帰属情報が、適用中の正常通信モデルが多数派クラスタに属しないことを示すものである場合、当該正常通信モデルの更新、または、サーバ１００から受信した平均モデルの適用を行う。正常通信モデルを更新するか、平均モデルを適用するかは、例えば、当該センサ２０の管理者等の指示入力により決定される。
　モデル管理部２３５は、監視部２３２で適用する正常通信モデルの管理を行う。例えば、通信部２１経由で、センサ２０の管理者等から、正常通信モデルの更新を行う旨の指示入力が行われた場合、モデル管理部２３５は、学習部２３１に再度正常通信モデルを学習させる。そして、モデル管理部２３５は、監視部２３２で適用する正常通信モデルを再学習された正常通信モデルに変更する。
　また、例えば、通信部２１経由で、センサ２０の管理者等から、正常通信モデルの平均モデルの適用を行う旨の指示入力が行われた場合、モデル管理部２３５は、監視部２３２で適用する正常通信モデルを平均モデルに変更する。
[学習の成功と失敗について]
　ここで、学習部２３１における正常通信モデルの学習の成功と失敗について、図５を用いて説明する。ここでは、正常通信モデルの学習に用いられる特徴量が、IoTデバイスの通信における時間ごとの宛先ＩＰアドレス数である場合を例に説明する。また、学習された正常通信モデルにおいて、特徴量の値は正規分布をとるものとして説明する。
　例えば、学習部２３１は、機種ＡのIoTデバイスに接続し（（１）：デバイス接続）、当該IoTデバイスの通信データの特徴量に基づき正常通信モデルの学習を行う（（２）：学習）。ここで、当該IoTデバイスの通信における時間ごとの累積宛先ＩＰアドレス数の値が、例えば、（２）に示すフィッティング曲線にフィットする場合、学習部２３１は、正常通信モデルを生成することができる（（３）：正常通信モデルの生成）。つまり、学習部２３１は、正常通信モデルの学習に成功する。
　一方、当該IoTデバイスの通信における時間ごとの累積宛先ＩＰアドレス数の値が、例えば、図５の（２）に示すフィッティング曲線にフィットしない場合、学習部２３１は、正常通信モデルを生成することができない。つまり、学習部２３１正常通信モデルの学習に失敗する。
［処理手順の例］
［概要］
　次に、システム１の処理手順の例を説明する。システム１の処理手順は、（１）学習フェーズおよび（２）運用フェーズに分けられる。（１）学習フェーズは、例えば、システム１内に新規のセンサ２０が追加され、当該センサ２０において学習された正常通信モデルをサーバ１００に追加するフェーズである。（２）運用フェーズは、システム１内の既存のセンサ２０において正常通信モデルの更新が行われ、更新後の正常通信モデルをサーバ１００に追加するフェーズである。
［学習フェーズ（正常通信モデルの学習に成功した場合）］
　まず、図６を用いて（１）学習フェーズにおける、システム１の処理手順の例を説明する。ここでは、センサ２０が正常通信モデルの学習に成功した場合のシステム１の処理手順の例を説明する。
　（１）センサ２０は、IoTデバイス（機種ＡのIoTデバイス）の通信データを取得する。
　（２）センサ２０は、取得した通信データの特徴量の統計処理を行うことにより、機種ＡのIoTデバイスの送信パケット数の正常通信モデルを学習する。
　（３）センサ２０は、正常通信モデルの学習に成功すると、学習した正常通信モデル（判定対象モデル）をサーバ１００へ送信する。
　（４）サーバ１００は、センサ２０から送信された判定対象モデルを含む、機種ＡのIoTデバイスの送信パケット数の正常通信モデル群をクラスタリングする。そして、サーバ１００は、クラスタリングの結果を用いて、多数派クラスタを算出し、当該多数派クラスタに属する正常通信モデル群の平均モデルを算出する。
　（５）サーバ１００は、正常通信モデル群のクラスタリングの結果に応じて、以下の内容をセンサ２０に通知する。
　（５－ａ）サーバ１００が、判定対象モデルが多数派クラスタに属すると判定した場合、当該判定対象モデルの取得元のセンサ２０に対し、当該判定対象モデルが多数派クラスタに属する旨の帰属情報を通知する。また、サーバ１００は、当該センサ２０に対し、多数派クラスタの平均モデルを通知する。
　これにより、当該センサ２０の管理者は、当該センサ２０で学習した正常通信モデルの適用に問題がないことを確認することができる。
　（５－ｂ）サーバ１００が、判定対象モデルが多数派クラスタに属しないと判定した場合、当該判定対象モデルの取得元のセンサ２０に対し、当該判定対象モデルが多数派クラスタに属しない旨の帰属情報を通知する。
　これにより、センサ２０の管理者は、当該センサ２０で学習された正常通信モデルが適切なものか否かを知ることができる。また、当該センサ２０は、当該センサ２０で学習された正常通信モデルが適切なものは適切なものでない場合、適切な正常通信モデル（平均モデル）を取得することができる。
［学習フェーズ（正常通信モデルに失敗した場合）］
　次に、図７を用いて（１）学習フェーズにおいて、センサ２０が正常通信モデルの学習に失敗した場合のシステム１の処理手順の例を説明する。
　（１）センサ２０は、IoTデバイス（機種ＡのIoTデバイス）の通信データを取得する。
　（２）センサ２０は、取得した通信データの特徴量の統計処理を行うことにより、機種ＡのIoTデバイスの送信パケット数の正常通信モデルを学習する。
　（３）センサ２０は、正常通信モデルの学習に失敗した場合、サーバ１００に、正常通信モデルの学習に失敗した旨の情報をサーバ１００へ送信する。当該情報は、例えば、機種ＡのIoTデバイスの送信パケット数に関する正常通信モデルの学習に失敗したことを示す情報である。
　（４）サーバ１００は、機種ＡのIoTデバイスの送信パケット数の正常通信モデル群をクラスタリングし、クラスタリングの結果を用いて、多数派クラスタを算出し、当該多数派クラスタに属する正常通信モデル群の平均モデルを算出しておく。
　（５）サーバ１００は、センサ２０に対し、（４）で算出した平均モデルを送信する。これにより、センサ２０が正常通信モデルの学習に失敗した場合でも、当該センサ２０は適切な正常通信モデル（平均モデル）を取得することができる。
［運用フェーズ］
　次に、図８を用いて、（２）運用フェーズにおける、システム１の処理手順の例を説明する。ここでは、図８に示すセンサ２０Ｂが、機種ＡのIoTデバイスの送信パケット数の正常通信モデルのパラメータを更新した場合を例に説明する。
　（１）センサ２０Ｂが、機種ＡのIoTデバイスの送信パケット数の正常通信モデルのパラメータを更新する。
　（２）センサ２０Ｂは、更新後の正常通信モデルをサーバ１００へ送信する。
　（３）サーバ１００は、センサ２０Ｂから送信された、更新後の正常通信モデルを含む、機種ＡのIoTデバイスの送信パケット数の正常通信モデル群を再度クラスタリングする。また、サーバ１００は、クラスタリングの結果を用いて、多数派クラスタを再度算出し、当該多数派クラスタに属する正常通信モデル群の平均モデルを再度算出する。
　（４）サーバ１００は、多数派クラスタの再算出により、多数派クラスタから外れた正常通信モデルがあった場合、当該正常通信モデルの取得元のセンサ２０（例えば、センサ２０Ａ）に対し、当該正常通信モデルが多数派クラスタから外れた旨を通知する。また、サーバ１００は、算出された多数派クラスタの平均モデルを、当該正常通信モデルの取得元のセンサ２０（例えば、センサ２０Ａ）に通知する。なお、当該正常通信モデルが多数派クラスタから外れた旨の通知は、当該正常通信モデルが多数派クラスタからどの程度外れたかを示す情報を含んでいてもよい。
　これにより、センサ２０の管理者は、当該センサ２０で学習された正常通信モデルが適切なものでなくなったか否かを知ることができる。また、当該センサ２０で学習された正常通信モデルが適切なものは適切なものでなくなった場合、適切な正常通信モデル（平均モデル）を取得することができる。
［処理手順の例］
［詳細］
　次に、図９、図１０、図１１を用いて、システム１の処理手順の例を詳細に説明する。
［学習フェーズ（正常通信モデルの学習に成功した場合）］
　図９を用いて、センサ２０が正常通信モデルの学習に成功した場合における、学習フェーズの処理手順の例を説明する。
　まず、センサ２０がデバイスＡ（監視対象のIoTデバイス）に接続すると（Ｓ１０）、学習部２３１により正常通信モデルの学習を行う（Ｓ１１）。センサ２０は、正常通信モデルの学習を完了すると、サーバ１００との連携を許可するか否かを判定する（Ｓ１２）。例えば、センサ２０は、当該センサ２０の管理者からサーバ１００との連携を許可する旨の入力を受け付けると、サーバ１００との連携を許可すると判定する（Ｓ１２でＹｅｓ）。そして、センサ２０の送受信部２３３は、サーバ１００の認証情報と、Ｓ１１で学習した正常通信モデルとをサーバ１００へ送信する（Ｓ１３）。
　一方、例えば、センサ２０が、当該センサ２０の管理者からサーバ１００との連携を許可する旨の入力を受け付けなかった場合、サーバ１００との連携を許可しないと判定する（Ｓ１２でＮｏ）。この場合、センサ２０の学習部２３１は、例えば、センサ２０単独で正常通信モデルの学習を行う（Ｓ２４）。
　Ｓ１３の後、サーバ１００の取得部１３１が、センサ２０からサーバの認証情報と正常通信モデルとを受信すると、記憶部１２０に当該センサ２０の連携許可情報を登録する（Ｓ１４）。そして、サーバ１００の算出部１３２は、Ｓ１３で送信された正常通信モデルを含む正常通信モデル群をクラスタリングする（Ｓ１５）。また、算出部１３２は、クラスタリングの結果を用いて、多数派クラスタを算出し、当該多数派クラスタの平均モデルを算出する。さらに、判定部１３３は、Ｓ１３で送信された正常通信モデルが、多数派クラスタに属するか否かを判定する。
　Ｓ１５の後、サーバ１００の通知部１３４は、Ｓ１３で送信された正常通信モデルの送信元のセンサ２０に対し、判定部１３３による判定の結果（当該正常通信モデルの多数派クラスタへの帰属情報）と平均モデルを送信する（Ｓ１６）。
　Ｓ１６の後、センサ２０の送受信部２３３は、サーバ１００から、Ｓ１３で送信した正常通信モデルに関する多数派クラスタへの帰属情報および平均モデルを受信する（Ｓ１７：サーバから情報取得）。その後、判定部２３４は、Ｓ１７で受信した多数派クラスタへの帰属情報に基づき、平均モデルを利用するか否かを判定する（Ｓ１８）。
　例えば、多数派クラスタへの帰属情報が、Ｓ１３で送信した正常通信モデルが多数派クラスタに属しない旨を示す情報である場合、判定部２３４は、平均モデルを利用すると判定する（Ｓ１８でＹｅｓ）。そして、モデル管理部２３５は、監視部２３２で適用する正常通信モデルを平均モデルに変更する（Ｓ１９：平均モデルを適用）。その後、Ｓ２１へ進む。
　一方、例えば、多数派クラスタへの帰属情報が、当該正常通信モデルが多数派クラスタに属する旨を示す情報である場合、判定部２３４は、平均モデルを利用しないと判定する（Ｓ１８でＮｏ）。そして、モデル管理部２３５は、監視部２３２で適用する正常通信モデルを、Ｓ１１で学習した正常通信モデルにする（Ｓ２０：学習した正常通信モデルを適用）。その後、Ｓ２１へ進む。
　Ｓ２１において、送受信部２３３は、正常通信モデルの適用情報をサーバ１００へ送信する（Ｓ２１）。この正常通信モデルの適用情報は、例えば、当該センサ２０において、当該センサ２０が学習した正常通信モデルを適用するのか、平均モデルを適用するのかを示した情報である。なお、当該センサ２０は、当該センサ２０が学習した正常通信モデルを適用する場合、正常通信モデルの適用情報に、学習した正常通信モデルを含めて送信する。
　Ｓ２１の後、サーバ１００の取得部１３１は、Ｓ２１でセンサ２０から送信された正常通信モデルの適用情報に基づき、記憶部１２０の正常通信モデル情報（各センサ２０が適用している正常通信モデルを示す情報）を更新する（Ｓ２２）。その後、図１１のＳ４１へ進む。図１１のＳ４１の処理については、後記する。
　システム１が上記の処理を行うことにより、センサ２０の管理者は、当該センサ２０で学習された正常通信モデルが適切なものか否かを知ることができる。また、当該センサ２０で学習された正常通信モデルが適切なものでない場合、適切な正常通信モデル（平均モデル）を取得することができる。
［学習フェーズ（正常通信モデルの学習に失敗した場合）］
　次に、図１０を用いて、センサ２０が正常通信モデルの学習に失敗した場合における、学習フェーズの処理手順の例を説明する。
　まず、センサ２０がデバイスＡ（監視対象のIoTデバイス）に接続すると（Ｓ３０）、学習部２３１により正常通信モデルの学習を行う（Ｓ３１）。ここで、センサ２０は、正常通信モデルの学習に失敗すると、サーバ１００との連携を許可するか否かを判定する（Ｓ３２）。例えば、センサ２０は、当該センサ２０の管理者からサーバ１００との連携を許可する旨の入力を受け付けると、サーバ１００との連携を許可すると判定する（Ｓ３２でＹｅｓ）。
　そして、センサ２０の送受信部２３３は、サーバ１００の認証情報と、正常通信モデルの学習失敗情報（正常通信モデルの学習に失敗した旨の情報）とをサーバ１００へ送信する（Ｓ３３）。前記した通り、この正常通信モデルの学習失敗情報は、どの機種のIoTデバイスの、どの特徴量に関する正常通信モデルの学習に失敗したかを示す情報である。
　一方、例えば、センサ２０が、当該センサ２０の管理者からサーバ１００との連携を許可する旨の入力を受け付けなかった場合、サーバ１００との連携を許可しないと判定する（Ｓ３２でＮｏ）。そして、センサ２０は、例えば、別の手段でIoTデバイスの異常検知を行う（Ｓ４０）。
　Ｓ３３の後、サーバ１００の取得部１３１が、センサ２０からサーバの認証情報と正常通信モデルとを受信すると、記憶部１２０に当該センサ２０の連携許可情報を登録する（Ｓ３４）。その後、通知部１３４は、記憶部１２０から、正常通信モデルの学習失敗情報に示される機種および特徴量の正常通信モデルの平均モデルを読み出し、当該センサ２０に送信する（Ｓ３５）。
　Ｓ３５の後、センサ２０の送受信部２３３は、サーバ１００から平均モデルを受信する（Ｓ３６：サーバから情報取得）。その後、モデル管理部２３５は、監視部２３２で用いる正常通信モデルとして、Ｓ３６で受信した平均モデルを適用する（Ｓ３７）。そして、送受信部２３３は、正常通信モデルの適用情報をサーバ１００へ送信する（Ｓ３８）。
　Ｓ３８の後、サーバ１００の取得部１３１は、Ｓ３８でセンサ２０から送信された正常通信モデルの適用情報に基づき、記憶部１２０の正常通信モデル情報を更新する（Ｓ３９）。その後、図１１のＳ４１へ進む。図１１のＳ４１の処理については、後記する。
　システム１が上記の処理を行うことにより、センサ２０が正常通信モデルの学習に失敗した場合でも、適切な正常通信モデル（平均モデル）を取得することができる。
［運用フェーズ］
　図１１を用いて、運用フェーズの処理手順の例を説明する。まず、サーバ１００が、配下のセンサ２０で正常通信モデルのパラメータの変更が行われたことを検知すると（Ｓ４１）、算出部１３２は、正常通信モデル群を再度クラスタリングする（Ｓ４２）。
　例えば、サーバ１００の取得部１３１が、いずれかのセンサ２０から、パラメータ更新後の正常通信モデルを受信した場合、算出部１３２は、更新後の正常通信モデルを含む、更新後の正常通信モデルと同じ機種、同じ特徴量に関する正常通信モデル群を再度クラスタリングする。そして、算出部１３２は、クラスタリングの結果を用いて、再度多数派クラスタを算出する。また、算出部１３２は、再度多数派クラスタの平均モデルを算出する。
　Ｓ４２の後、サーバ１００の判定部１３３は、Ｓ４２の処理の結果、多数派クラスタから外れた正常通信モデルがあるか否かを判定する（Ｓ４３）。ここで、判定部１３３が多数派クラスタから外れた正常通信モデルはないと判定した場合（Ｓ４３でＮｏ）、Ｓ４１へ戻る。
　一方、判定部１３３が多数派クラスタから外れた正常通信モデルがあると判定した場合（Ｓ４３でＹｅｓ）、通知部１３４は、多数派クラスタから外れた正常通信モデルの送信元のセンサ２０に対し、多数派クラスタへの帰属情報および平均モデルを送信する（Ｓ４４）。その後、Ｓ４５へ進む。
　なお、Ｓ４４で送信される多数派クラスタへの帰属情報は、当該センサ２０で適用される正常通信モデルが多数派クラスタから外れた旨を示す情報である。また、多数派クラスタへの帰属情報は、当該正常通信モデルが多数派クラスタからどの程度外れているかを示す値を含んでいてもよい。Ｓ４５～Ｓ５０の処理は、図９のＳ１７～Ｓ２２の処理と同様なので説明を省略する。
　システム１が上記の処理を行うことで、センサ２０の管理者は、当該センサ２０で学習された正常通信モデルが適切なものでなくなったか否かを知ることができる。また、当該センサ２０で学習された正常通信モデルが適切なものは適切なものでなくなった場合、当該センサ２０は、適切な正常通信モデル（平均モデル）を取得することができる。
[その他の実施形態]
　なお、前記した実施形態において、サーバ１００は、正常通信モデルが多数派クラスタに属するか否かにかかわらず、当該正常通信モデルの取得元のセンサ２０に対し、多数派クラスタの帰属情報および平均モデルを通知することとしたが、これに限定されない。
　例えば、サーバ１００の通知部１３４は、多数派クラスタに属する正常通信モデルの取得元のセンサ２０に対しては、多数派クラスタの帰属情報を通知し、多数派クラスタに属しない正常通信モデルの取得元のセンサ２０に対し、多数派クラスタの帰属情報および平均モデルを通知してもよい。つまり、サーバ１００の通知部１３４は、多数派クラスタに属する正常通信モデルの取得元のセンサ２０に対しては、平均モデルを通知しないこととしてもよい。
　また、サーバ１００の通知部１３４は、センサ２０に対し、多数派クラスタの帰属情報を通知することとしたがこれに限定されない。例えば、通知部１３４は、センサ２０に対し、当該センサ２０で学習された正常通信モデルが多数派クラスタに属するのならば、当該正常通信モデルの適用は問題ない旨を通知し、多数派クラスタに属しないのならば、正常通信モデルの再学習または更新が必要であることを通知してもよい。
［システム構成等］
　また、図示した各部の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部又は任意の一部が、ＣＰＵ及び当該ＣＰＵにて実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
　また、前記した実施形態において説明した処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
［プログラム］
　前記したサーバ１００は、パッケージソフトウェアやオンラインソフトウェアとしてプログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、上記のプログラムを情報処理装置に実行させることにより、情報処理装置をサーバ１００として機能させることができる。ここで言う情報処理装置には、デスクトップ型又はノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機やPHS（Personal　Handyphone　System）等の移動体通信端末、さらには、PDA（Personal　Digital　Assistant）等の端末等がその範疇に含まれる。
　また、サーバ１００は、ユーザが使用する端末装置をクライアントとし、当該クライアントに上記の処理に関するサービスを提供するサーバ装置として実装することもできる。この場合、サーバ装置は、Ｗｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の処理に関するサービスを提供するクラウドとして実装することとしてもかまわない。
　図１２は、分析プログラムを実行するコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ROM（Read　Only　Memory）１０１１及びRAM（Random　Access　Memory）１０１２を含む。ROM１０１１は、例えば、BIOS（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。
　ハードディスクドライブ１０９０は、例えば、OS１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記のサーバ１００が実行する各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、サーバ１００における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、SSD（Solid　State　Drive）により代替されてもよい。
　また、上述した実施形態の処理で用いられるデータは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてRAM１０１２に読み出して実行する。
　なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（LAN（Local　Area　Network）、WAN（Wide　Area　Network）等）を介して接続される他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
１　システム
２０　センサ
２１，１１０　通信部
２２，１２０　記憶部
２３，１３０　制御部
１００　サーバ
１３１　取得部
１３２　算出部
１３３，２３４　判定部
１３４　通知部
２３１　学習部
２３２　監視部
２３３　送受信部
２３５　モデル管理部

Claims (8)

  1. 　IoT（Internet　of　Things）デバイスの通信を監視する各ネットワークトラフィックセンサから、前記通信の監視に用いられる、当該IoTデバイスの正常な通信の特徴を示す正常通信モデルを取得する取得部と、
    　取得した前記正常通信モデル群のうち、同じ特徴量に関する正常通信モデル群をクラスタリングし、クラスタリングの結果を用いて、正常通信モデルの数が最も多いクラスタである多数派クラスタを算出し、前記多数派クラスタに属する正常通信モデル群の平均モデルを算出する算出部と、
    　前記正常通信モデルの取得元のネットワークトラフィックセンサに対し、当該正常通信モデルが前記多数派クラスタに属するか否かを示す帰属情報および前記平均モデルを通知する通知部と
    　を備えることを特徴とする分析装置。
  2. 　前記通知部は、
    　前記多数派クラスタに属する正常通信モデルの取得元のネットワークトラフィックセンサに対し、前記帰属情報を通知し、前記多数派クラスタに属しない正常通信モデルの取得元のネットワークトラフィックセンサに対し、前記帰属情報および前記平均モデルを通知する
    　ことを特徴とする請求項１に記載の分析装置。
  3. 　前記取得部が、前記ネットワークトラフィックセンサから、パラメータ更新後の前記正常通信モデルを取得した場合、
    　前記算出部は、
    　前記パラメータ更新後の正常通信モデルを含む、当該正常通信モデルの特徴量と同じ特徴量に関する正常通信モデル群を、再度、クラスタリングすることにより、前記多数派クラスタを再算出し、再算出後の前記多数派クラスタに属する正常通信モデル群の平均モデルを再算出し、
    　前記通知部は、
    　いずれかの正常通信モデルが、再算出後の前記多数派クラスタから外れた場合、当該正常通信モデルの取得元のネットワークトラフィックセンサに対し、当該正常通信モデルが前記多数派クラスタから外れた旨を示す帰属情報および再算出後の前記平均モデルを通知する
    　ことを特徴とする請求項１に記載の分析装置。
  4. 　前記取得部が、前記ネットワークトラフィックセンサからIoTデバイスの正常通信モデルの学習に失敗した旨の通知を取得した場合、
    　前記通知部は、
    　当該ネットワークトラフィックセンサに対し、前記学習に失敗した正常通信モデルの特徴量と同じ特徴量に関する正常通信モデル群の多数派クラスタの平均モデルを通知する
    　ことを特徴とする請求項１に記載の分析装置。
  5. 　前記特徴量は、
    　IoTデバイスの通信における、時間あたりの送信パケット数、宛先ＩＰアドレス数、宛先ポート番号、および、パケットのバイト数のうち、少なくともいずれか１つを含む
    　ことを特徴とする請求項１に記載の分析装置。
  6. 　ネットワークトラフィックセンサと、前記ネットワークトラフィックセンサにおいて学習された正常通信モデルの分析を行う分析装置とを備える分析システムであって、
    　前記ネットワークトラフィックセンサは、
    　IoTデバイスの通信の正常な通信の特徴を示す正常通信モデルの学習を行う学習部と、
    　前記学習された正常通信モデルまたは前記分析装置から通知された正常通信モデルを用いて前記IoTデバイスの通信の監視を行う監視部とを備え、
    　前記分析装置は、
    　IoT（Internet　of　Things）デバイスの通信を監視する各ネットワークトラフィックセンサから、前記通信の監視に用いられる、当該IoTデバイスの正常な通信の特徴を示す正常通信モデルを取得する取得部と、
    　取得した前記正常通信モデル群のうち、同じ特徴量に関する正常通信モデル群をクラスタリングし、クラスタリングの結果を用いて、正常通信モデルの数が最も多いクラスタである多数派クラスタを算出し、前記多数派クラスタに属する正常通信モデル群の平均モデルを算出する算出部と、
    　前記正常通信モデルの取得元のネットワークトラフィックセンサに対し、当該正常通信モデルが前記多数派クラスタに属するか否かを示す帰属情報および前記平均モデルを通知する通知部と
    　を備えることを特徴とする分析システム。
  7. 　分析装置により実行される分析方法であって、
    　IoT（Internet　of　Things）デバイスの通信を監視する各ネットワークトラフィックセンサから、前記通信の監視に用いられる、当該IoTデバイスの正常な通信の特徴を示す正常通信モデルを取得する工程と、
    　取得した前記正常通信モデル群のうち、同じ特徴量に関する正常通信モデル群をクラスタリングし、クラスタリングの結果を用いて、正常通信モデルの数が最も多いクラスタである多数派クラスタを算出し、前記多数派クラスタに属する正常通信モデル群の平均モデルを算出する工程と、
    　前記正常通信モデルの取得元のネットワークトラフィックセンサに対し、当該正常通信モデルが前記多数派クラスタに属するか否かを示す帰属情報および前記平均モデルを通知する工程と
    　を含むことを特徴とする分析方法。
  8. 　IoT（Internet　of　Things）デバイスの通信を監視する各ネットワークトラフィックセンサから、前記通信の監視に用いられる、当該IoTデバイスの正常な通信の特徴を示す正常通信モデルを取得する工程と、
    　取得した前記正常通信モデル群のうち、同じ特徴量に関する正常通信モデル群をクラスタリングし、クラスタリングの結果を用いて、正常通信モデルの数が最も多いクラスタである多数派クラスタを算出し、前記多数派クラスタに属する正常通信モデル群の平均モデルを算出する工程と、
    　前記正常通信モデルの取得元のネットワークトラフィックセンサに対し、当該正常通信モデルが前記多数派クラスタに属するか否かを示す帰属情報および前記平均モデルを通知する工程と
    　をコンピュータに実行させるための分析プログラム。
PCT/JP2021/006186 2021-02-18 2021-02-18 分析装置、分析システム、分析方法、および、分析プログラム WO2022176128A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US18/276,644 US20240129202A1 (en) 2021-02-18 2021-02-18 Analysis device, analysis system, analysis method, and analysis program
JP2023500242A JPWO2022176128A1 (ja) 2021-02-18 2021-02-18
PCT/JP2021/006186 WO2022176128A1 (ja) 2021-02-18 2021-02-18 分析装置、分析システム、分析方法、および、分析プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/006186 WO2022176128A1 (ja) 2021-02-18 2021-02-18 分析装置、分析システム、分析方法、および、分析プログラム

Publications (1)

Publication Number Publication Date
WO2022176128A1 true WO2022176128A1 (ja) 2022-08-25

Family

ID=82930395

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/006186 WO2022176128A1 (ja) 2021-02-18 2021-02-18 分析装置、分析システム、分析方法、および、分析プログラム

Country Status (3)

Country Link
US (1) US20240129202A1 (ja)
JP (1) JPWO2022176128A1 (ja)
WO (1) WO2022176128A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015108898A (ja) * 2013-12-03 2015-06-11 日本電信電話株式会社 異常検知システム及び異常検知方法
JP2020187616A (ja) * 2019-05-16 2020-11-19 三菱電機株式会社 プラント監視モデル作成装置、プラント監視モデル作成方法およびプラント監視モデル作成プログラム
WO2020250319A1 (ja) * 2019-06-11 2020-12-17 日本電信電話株式会社 制御装置、制御方法及び制御プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015108898A (ja) * 2013-12-03 2015-06-11 日本電信電話株式会社 異常検知システム及び異常検知方法
JP2020187616A (ja) * 2019-05-16 2020-11-19 三菱電機株式会社 プラント監視モデル作成装置、プラント監視モデル作成方法およびプラント監視モデル作成プログラム
WO2020250319A1 (ja) * 2019-06-11 2020-12-17 日本電信電話株式会社 制御装置、制御方法及び制御プログラム

Also Published As

Publication number Publication date
JPWO2022176128A1 (ja) 2022-08-25
US20240129202A1 (en) 2024-04-18

Similar Documents

Publication Publication Date Title
CN109791633B (zh) 使用基于云的机器学习的静态和动态设备简档信誉
CN111835794B (zh) 防火墙策略控制方法、装置、电子设备及存储介质
US9888025B2 (en) Method and system for providing an efficient asset management and verification service
US9384114B2 (en) Group server performance correction via actions to server subset
EP3776307B1 (en) Distributed system for adaptive protection against web-service-targeted vulnerability scanners
US6557035B1 (en) Rules-based method of and system for optimizing server hardware capacity and performance
US10686807B2 (en) Intrusion detection system
US11818014B2 (en) Multi-baseline unsupervised security-incident and network behavioral anomaly detection in cloud-based compute environments
US10592266B1 (en) Dynamic consolidation of virtual machines
CN112534432A (zh) 不熟悉威胁场景的实时缓解
US10944655B2 (en) Data verification based upgrades in time series system
US20090070425A1 (en) Data processing system, method of updating a configuration file and computer program product
CN110998535B (zh) 经由对应用操作请求的分析来恢复应用功能
US20230185918A1 (en) Achieving minimum trustworthiness in distributed workloads
US10176069B2 (en) Quorum based aggregator detection and repair
WO2023197453A1 (zh) 一种故障诊断方法、装置、设备及存储介质
US10977113B2 (en) System and method for fault identification, logging, and remediation
US11765195B2 (en) Distributed network-level probabilistic attack graph generation
JP2020102671A (ja) 検知装置、検知方法、および、検知プログラム
WO2022176128A1 (ja) 分析装置、分析システム、分析方法、および、分析プログラム
AU2019277439B2 (en) Abnormality detection apparatus, abnormality detection method, and abnormality detection program
CN115086172B (zh) 一种数据网关插件更新方法、装置、电子设备及存储介质
CN110521233B (zh) 标识中断的方法、接入点、远程配置的方法、系统和介质
US20210382807A1 (en) Machine learning based application sizing engine for intelligent infrastructure orchestration
KR102180105B1 (ko) 장치에 설치된 소프트웨어에 대한 악성 소프트웨어 판단 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21926563

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023500242

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 18276644

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21926563

Country of ref document: EP

Kind code of ref document: A1