WO2022195887A1 - トラフィックセンサ、分析方法、および、分析プログラム - Google Patents

トラフィックセンサ、分析方法、および、分析プログラム Download PDF

Info

Publication number
WO2022195887A1
WO2022195887A1 PCT/JP2021/011529 JP2021011529W WO2022195887A1 WO 2022195887 A1 WO2022195887 A1 WO 2022195887A1 JP 2021011529 W JP2021011529 W JP 2021011529W WO 2022195887 A1 WO2022195887 A1 WO 2022195887A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
normal communication
iot device
communication
iot
Prior art date
Application number
PCT/JP2021/011529
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 PCT/JP2021/011529 priority Critical patent/WO2022195887A1/ja
Priority to EP21931632.0A priority patent/EP4293549A1/en
Priority to CN202180095837.7A priority patent/CN117043770A/zh
Priority to AU2021434202A priority patent/AU2021434202B2/en
Priority to JP2023506699A priority patent/JPWO2022195887A1/ja
Publication of WO2022195887A1 publication Critical patent/WO2022195887A1/ja

Links

Images

Classifications

    • 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
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • 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
    • G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting

Definitions

  • the present invention relates to traffic sensors, analysis methods, and analysis programs.
  • a traffic sensor (hereafter abbreviated as sensor), which monitors the communication of IoT devices, analyzes the communication data of the monitored IoT devices and statisticizes the feature values such as the number of packets sent and the number of destination IP addresses. to learn the normal communication model of the relevant IoT device. Then, using the learned normal communication model, the sensor cuts off the communication when it detects an abnormal behavior caused by malware infection of the IoT device.
  • the sensor learns the normal communication model of the above IoT device, learning of the normal communication model is completed when it can be determined that the communication behavior of the IoT device has stabilized. Then, the sensor uses the learned normal communication model for communication abnormality detection (see Patent Document 1).
  • an object of the present invention is to solve the above-mentioned problems and facilitate detection of abnormal communication common to multiple IoT devices.
  • the present invention provides a normal communication model learned for each monitored IoT (Internet of Things) device for detecting abnormal communication of the IoT device.
  • a calculating unit that calculates the degree of spread of the range of normal communication shown; classifies a normal communication model in which the degree of spread is less than a predetermined value as a normal communication model of the first type of IoT device; a classification unit that classifies a normal communication model as a normal communication model of a second model IoT device; and a detection unit that detects abnormal communication in the IoT device using the normal communication model of the first model IoT device.
  • a feature amount extracting unit for extracting a feature amount whose contribution to detection of the abnormal communication is equal to or greater than a predetermined value from among the feature amounts used in the normal communication model of the IoT device of the first model; and the extracted feature.
  • a model reconstruction unit that reconstructs a normal communication model of the second model IoT device using the quantity, and an abnormal communication of the first model IoT device that is detected using the normal communication model; an analysis unit that analyzes abnormal communication common to each of the IoT devices by using the abnormal communication of the second model IoT device detected using the reconstructed normal communication model.
  • FIG. 1 is a diagram illustrating an outline of a traffic sensor (sensor).
  • FIG. 2 is a diagram illustrating an example of a normal communication model.
  • FIG. 3 is a diagram for explaining an example of extraction of effective extraction amount.
  • FIG. 4 is a diagram showing a configuration example of a sensor.
  • FIG. 5 is a flow chart showing an example of the processing procedure of the sensor.
  • FIG. 6 is a diagram illustrating an example of a sensor processing procedure in the learning phase.
  • FIG. 7 is a diagram illustrating an example of a sensor processing procedure in the monitoring phase.
  • FIG. 8 is a graph showing experimental results of the sensor.
  • FIG. 9 is a diagram showing experimental results of the sensor.
  • FIG. 10 is a diagram showing a configuration example of a computer that executes an analysis program.
  • the sensor 10 relays communication from each IoT device to the outside (for example, the Internet shown in FIG. 1).
  • the sensor 10 learns the normal communication model of the IoT device based on the feature quantity such as the destination domain in the communication of the IoT device.
  • the sensor 10 learns a normal communication model for IoT_A, IoT_B, and IoT_C based on the communication feature amounts for each of IoT_A, IoT_B, and IoT_C.
  • the sensor 10 monitors the communication of each IoT device based on the normal communication model for each IoT device, and detects/blocks abnormal communication such as communication to a malicious site caused by malware infection, transmission of a large number of packets, etc. do.
  • Normal communication model Here, the normal communication model of the IoT device learned by the sensor 10 will be described with reference to FIG.
  • the sensor 10 learns a normal communication model of the IoT device by estimating the probability distribution of each feature included in the communication of the IoT device using, for example, principal component analysis. Then, the sensor 10 sets a threshold for the normal communication model, and detects communication based on the feature amount exceeding the threshold as abnormal communication.
  • the sensor 10 counts the statistic per unit time for each feature of IoT device communication. For example, the sensor 10 counts the number of transmitted packets and the number of transmitted bytes per unit time of IoT_A (1. counting statistics).
  • the sensor 10 in a space with each feature value as an axis, 1. Plot the values counted in , and determine the range of normal communication on the axis in the direction of greater variance (the first and second principal components obtained by principal component analysis). For example, the sensor 10 determines the range enclosed by the dashed line in FIG. 2 as the normal communication range of IoT_A. Then, the sensor 10 detects a value deviating from the normal communication range as abnormal communication (2. Generation of normal communication model (principal component analysis)).
  • IoT devices include models with few communication patterns during normal operation (stable models) and models with many communication patterns during normal operation (unstable models).
  • IoT_A and IoT_B shown in FIG. 3 consider a case where IoT_A is a stable model and IoT_B is an unstable model.
  • the range of normal communication (spread of feature amount) in the normal communication model of IoT_B is larger than the range of normal communication (spread of feature amount) in the normal communication model of IoT_A (see symbols 101 and 102). .
  • the sensor 10 detects abnormal communication using the IoT_B normal communication model, overdetection is likely to occur in various feature value directions. As a result, it is difficult for the sensor 10 to find common abnormal communication that occurs in multiple IoT devices due to the spread of malware infection in the NW.
  • the sensor 10 extracts the feature amounts 1 and 2 that contribute highly to the detection of abnormal communication among the feature amounts 1, 2, and 3 used in the normal communication model of IoT_A as effective feature amounts. (See reference numeral 103).
  • the sensor 10 uses the extracted effective feature quantities (feature quantities 1 and 2) to reconstruct the normal communication model of IoT_B (see reference numeral 104).
  • feature quantities 1 and 2 the extracted effective feature quantities
  • the sensor 10 can suppress the spread of the normal communication range in the normal communication model of IoT_B in the direction of unnecessary feature values.
  • it becomes easier for the sensor 10 to find common abnormal communications that occur in multiple IoT devices for example, communications marked with ⁇ in symbols 103 and 104).
  • the sensor 10 includes a communication section 11 , a storage section 12 and a control section 13 .
  • the communication unit 11 is an interface for communicating with an external device (for example, an IoT device) via a network.
  • the storage unit 12 stores data referred to when the control unit 13 executes various processes and data generated by the control unit 13. For example, the storage unit 12 stores the normal communication model generated by the control unit 13 for each IoT device.
  • the control unit 13 includes a learning unit 131, a calculation unit 132, a classification unit 133, a detection unit 134, a feature extraction unit 135, a model reconstruction unit 136, an analysis unit 137, and an analysis result output unit 138. Prepare.
  • the learning unit 131 learns (builds) a normal communication model of the IoT device based on the feature amount of the communication data of the monitored IoT device acquired via the communication unit 11 .
  • the feature amount is, for example, the number of packets transmitted per time, the IP address of the communication destination, the port number, the number of bytes of the packet, and the like.
  • the learned normal communication model is stored in the storage unit 12 .
  • the calculation unit 132 calculates the degree of expansion of the range of normal communication in the normal communication model. For example, the calculation unit 132 calculates the degree of expansion of the range of normal communication in the normal communication model by multiplying the variances in each feature amount direction used in the normal communication model.
  • the classification unit 133 classifies a normal communication model in which the degree of spread of the range of normal communication in the normal communication model calculated by the calculation unit 132 (for example, the product of variance in each feature value direction) is less than a predetermined value as an IoT device of a stable model.
  • normal communication model and the normal communication model of an IoT device whose range of normal communication is greater than or equal to a predetermined value is classified as a normal communication model of an unstable IoT device.
  • the detection unit 134 uses the normal communication model for each IoT device to detect abnormal communication in the IoT device.
  • the feature amount extraction unit 135 extracts, as effective feature amounts, feature amounts whose contribution to abnormal communication detection is equal to or greater than a predetermined value, from among the feature amounts used in the normal communication model of IoT devices of stable models. For example, when the feature quantity extraction unit 135 receives the detection result of abnormal communication of an IoT device of a stable model from the detection unit 134, among the feature quantities used for the normal communication model of the IoT device, A feature amount whose contribution is equal to or greater than a predetermined value is extracted as an effective feature amount.
  • the model reconstruction unit 136 uses the effective feature values extracted by the feature value extraction unit 135 to reconstruct the normal communication model of the unstable IoT device model.
  • the detection unit 134 uses the reconstructed normal communication model of the unstable model IoT device to Detect abnormal communication in stable IoT devices.
  • the analysis unit 137 uses the abnormal communication detected by the stable model IoT device using the normal communication model and the abnormal communication detected by the unstable model IoT device using the reconstructed normal communication model. , and analyze the trend of abnormal communication common to each IoT device. For example, the analysis unit 137 extracts anomalous communications having a degree of similarity greater than or equal to a predetermined value among the anomalous communications detected by each IoT device.
  • the analysis result output unit 138 outputs the analysis result by the analysis unit 137.
  • the analysis result output unit 138 outputs, as an important alert, the content of abnormal communication with a degree of similarity greater than or equal to a predetermined value among the abnormal communications detected by each IoT device extracted by the analysis unit 137 .
  • the learning unit 131 of the sensor 10 learns a normal communication model of the IoT device (S1).
  • the calculation unit 132 calculates the degree of spread of the range of normal communication indicated by the normal communication model of the IoT device (S2: Calculate the degree of spread of the normal communication model of the IoT device).
  • the classifying unit 133 classifies the model of the IoT device into stable model/unstable model based on the degree of spread of the normal communication model calculated in S2 (S3).
  • the detection unit 134 detects abnormal communication of each type of IoT device (S4). Then, the feature quantity extraction unit 135 extracts a feature quantity (effective feature quantity) whose degree of contribution to the detection of abnormal communication of the stable model IoT device is equal to or greater than a predetermined value (S5). That is, the feature quantity extraction unit 135 uses the detection result of abnormal communication of the IoT device of the stable model among the detection results in S4, and from the normal communication model of the IoT_A, the contribution to the detection of abnormal communication is a predetermined value. The above feature values are extracted.
  • the model reconstruction unit 136 uses the feature values extracted in S5 to reconstruct the normal communication model of the unstable IoT device (S6). Then, the detection unit 134 detects abnormal communication of the IoT device again using the reconstructed normal communication model (S7).
  • the analysis unit 137 analyzes the similarity of abnormal communication of each IoT device (S8).
  • the analysis result output unit 138 outputs the analysis result in S8 (S9).
  • FIG. 6 For example, as shown in FIG. 6, when the sensor 10 observes communication of new IoT devices (IoT_A, IoT_B, IoT_C) ((1)), the learning unit 131 detects the communication characteristics of each of IoT_A, IoT_B, and IoT_C. A normal communication model is learned based on the quantity ((2)).
  • the calculation unit 132 calculates the degree of expansion of the range of normal communication in each of the normal communication models of IoT_A, IoT_B, and IoT_C by multiplying the variances in each feature value direction of the normal communication model. Then, the classification unit 133 classifies IoT_A, IoT_B, and IoT_C into stable models/unstable models based on the calculated product of the variances in each feature value direction ((3)). For example, the classification unit 133 classifies IoT_A and IoT_B whose product of variances is smaller than a predetermined value as stable models, and classifies IoT_C whose product of variances is greater than a predetermined value as an unstable model.
  • the detection unit 134 detects abnormal communication using each normal communication model for IoT_A, IoT_B, and IoT_C ((4) Abnormal detection (first stage)). Then, the feature amount extraction unit 135 extracts, as effective feature amounts, feature amounts whose degree of contribution to detection of abnormal communication of IoT_A and IoT_B, which are stable models, is equal to or greater than a predetermined value ((5)). For example, the feature amount extraction unit 135 extracts feature amounts 1 and 2 shown in FIG. 7 as effective feature amounts.
  • the model reconstruction unit 136 reconstructs a normal communication model of IoT_C, which is an unstable model, using the effective feature amount.
  • the detection unit 134 detects abnormal communication of IoT_C again using the reconstructed normal communication model ((6) Abnormality detection using effective feature amount (second stage)).
  • the analysis unit 137 analyzes the similarities of the abnormal communications of IoT_A, IoT_B, and IoT_C. For example, the analysis unit 137 finds anomalies that tend to be common to IoT_A, IoT_B, and IoT_C.
  • the analysis result output unit 138 outputs abnormalities that tend to be common to IoT_A, IoT_B, and IoT_C as important alerts.
  • the attack data from the port scan was included during the time period indicated by the dashed line in Figure 8.
  • the sensor 10 extracts 30% of the feature amounts used in the normal communication model of the stable IoT device as an effective feature amount, and uses the extracted effective feature amount to We reconstructed the normal communication model and detected abnormal communication.
  • the horizontal axis indicates time
  • the vertical axis indicates the communication abnormality degree detected using the normal communication model at each time.
  • the graph indicated by reference numeral 801 in FIG. 8 shows experimental results when the sensor 10 detects abnormal communication without reconstructing a normal communication model.
  • a graph (with feature value extraction) indicated by reference numeral 802 shows experimental results when the sensor 10 detects abnormal communication after reconstructing a normal communication model. Note that in the graph indicated by reference numeral 801, time periods with a high degree of anomaly other than the time periods indicated by the dashed lines can be considered to be time periods in which the sensor 10 over-detected abnormal communication.
  • the reconstruction of the normal communication model of the unstable IoT device is more likely to overdetect abnormal communication than the case of not reconstructing the normal communication model. can be reduced by approximately 85%. As a result, it was confirmed that the sensor 10 can easily extract important alerts common to multiple IoT devices.
  • False Positive indicates over-detection of abnormal communication
  • True Positive indicates correct detection of abnormal communication.
  • 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 sensor 10 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 sensor 10 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 sensor 10 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. 10 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 sensor 10 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 . For example, a program module 1093 for executing processing similar to the functional configuration in the sensor 10 is stored in the hard disk drive 1090 .
  • 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)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Traffic Control Systems (AREA)
  • Fire Alarms (AREA)
  • Radar Systems Or Details Thereof (AREA)

Abstract

センサは、IoTデバイスの正常通信モデルごとに正常通信の範囲の広がり度合いを計算する。そして、センサは、広がり度合いが所定値未満の正常通信モデルを安定機種の正常通信モデルとして分類し、広がり度合いが所定値以上の正常通信モデルを不安定機種のIoTデバイスの正常通信モデルとして分類する。その後、センサは、安定機種のIoTデバイスの正常通信モデルを用いて、当該IoTデバイスにおける異常通信を検知し、当該正常通信モデルに用いられる特徴量のうち、異常通信の検知への寄与度が所定値以上の特徴量を用いて、不安定機種のIoTデバイスの正常通信モデルを再構築する。センサは、正常通信モデルを用いて検知した安定機種のIoTデバイスの異常通信と、再構築された正常通信モデルを用いて検知した不安定機種のIoTデバイスの異常通信とを用いて、IoTデバイスそれぞれに共通する異常通信を分析する。

Description

トラフィックセンサ、分析方法、および、分析プログラム
　本発明は、トラフィックセンサ、分析方法、および、分析プログラムに関する。
　IoT（Internet　of　Things）デバイスは、特定の通信パターンでのみ通信する場合が多いことが知られている。そこで、IoTデバイスの通信の監視を行うトラフィックセンサ（以下、適宜、センサと略す）は、監視対象のIoTデバイスの通信データを分析し、送信パケット数や宛先ＩＰアドレス数等の特徴量を統計化して、当該IoTデバイスの正常通信モデルを学習する。そして、センサは、学習した正常通信モデルを用いて、IoTデバイスのマルウェア感染等によって発生する異常な振る舞いを検知すると、通信の遮断等を行う。
　なお、センサが、上記のIoTデバイスの正常通信モデルを学習する際、当該IoTデバイスの通信振る舞いが安定したと判断できた時点で正常通信モデルの学習を完了する。そして、センサは、学習した正常通信モデルを通信の異常検知に利用する（特許文献１参照）。
特開２０１９－２１３１０３号公報
　しかし、従来技術には以下の課題がある。
（１）マルウェアの感染等により複数のIoTデバイスで発生した類似する異常通信が分からない
　従来技術では、センサが対象のIoTデバイス単位で正常通信モデルを学習し、学習した正常通信モデルを当該IoTデバイスの通信の異常検知に利用する。この技術によれば、単一のIoTデバイスの通信の異常を検知できるが、例えば、ネットワーク（NW）内のマルウェア感染の拡大により複数のIoTデバイスで発生する異常通信の類似度や相関性は分からない。これにより、NW全体で発生している重大なインシデントの認知が遅れる可能性があるという問題がある。このような問題の解決においては、下記の課題がある。
（２）不安定な機種のIoTデバイスの過検知が多く重要なアラートが分からない
　従来技術における各IoTデバイスの正常通信モデルの学習において、正常時の通信の傾向はIoTデバイスによって異なる。そのため、センサにより生成される正常通信モデルの性質も、IoTデバイスごとに異なる。ここで、正常時の通信パターンが少ない機種のIoTデバイスに関しては、センサは適切な正常通信モデルおよび閾値を学習しやすい。その結果、センサは、当該機種のIoTデバイスのマルウェア感染等による異常通信を顕著に検知できる。
　一方、正常時の通信パターンが多い機種のIoTデバイスに関しては、センサは正常通信モデルの学習期間中に全ての正常通信パターンを観測するのが難しい。このため、センサは、正常通信モデルの生成後、未知の正常通信を観測する可能性が高い。その結果、センサは、当該機種のIoTデバイスの異常通信を過検知してしまう可能性が高い。
　上記の問題の対策として、正常時の通信パターンが多い機種のIoTデバイスについては正常通信モデルの学習時間を長く確保する等の改善方法が考えられる。しかし、センサが、正常通信モデルの学習時間を長く確保すると、IoTデバイスの不正な通信の振る舞いも学習してしまうリスクが高くなったり、学習処理に伴うマシン負荷が増大したりする等の課題が残る。
　上記の課題により、NW内の複数のIoTデバイスで発生している異常通信の類似度や相関性を分析するのは困難であった。そのため、NW内の複数のIoTデバイスに共通する異常通信を検知することが困難であった。
　そこで、本発明は、前記した問題を解決し、複数のIoTデバイスに共通する異常通信の検知を容易にすることを課題とする。
　前記した課題を解決するため、本発明は、監視対象のIoT（Internet　of　Things）デバイスごとに学習された、前記IoTデバイスの異常通信を検知するための正常通信モデルそれぞれについて、前記正常通信モデルの示す正常通信の範囲の広がり度合いを計算する計算部と、前記広がり度合いが所定値未満の正常通信モデルを第１の機種のIoTデバイスの正常通信モデルとして分類し、前記広がり度合いが所定値以上の正常通信モデルを第２の機種のIoTデバイスの正常通信モデルとして分類する分類部と、前記第１の機種のIoTデバイスの正常通信モデルを用いて、前記IoTデバイスにおける異常通信を検知する検知部と、前記第１の機種のIoTデバイスの正常通信モデルに用いられる特徴量のうち、前記異常通信の検知への寄与度が所定値以上の特徴量を抽出する特徴量抽出部と、前記抽出した特徴量を用いて、前記第２の機種のIoTデバイスの正常通信モデルを再構築するモデル再構築部と、前記正常通信モデルを用いて検知された前記第１の機種のIoTデバイスの異常通信と、前記再構築された正常通信モデルを用いて検知された前記第２の機種のIoTデバイスの異常通信とを用いて、前記IoTデバイスそれぞれに共通する異常通信を分析する分析部とを備えることを特徴とする。
　本発明によれば、複数のIoTデバイスに共通する異常通信の検知を容易にすることができる。
図１は、トラフィックセンサ（センサ）の概要を説明する図である。 図２は、正常通信モデルの例を説明する図である。 図３は、有効抽出量の抽出の例を説明する図である。 図４は、センサの構成例を示す図である。 図５は、センサの処理手順の例を示すフローチャートである。 図６は、学習フェーズにおけるセンサの処理手順の例を説明する図である。 図７は、監視フェーズにおけるセンサの処理手順の例を説明する図である。 図８は、センサの実験結果を示すグラフである。 図９は、センサの実験結果を示す図である。 図１０は、分析プログラムを実行するコンピュータの構成例を示す図である。
　以下、図面を参照しながら、本発明を実施するための形態（実施形態）について説明する。本発明は、以下に説明する実施形態に限定されない。
[概要]
　まず、図１を用いて、本実施形態のトラフィックセンサ（センサ）の概要を説明する。センサ１０は、各IoTデバイスから外部（例えば、図１に示すインターネット）への通信を中継する。ここで、センサ１０は、IoTデバイスの通信における宛先ドメイン等の特徴量を基に、当該IoTデバイスの正常通信モデルを学習する。例えば、センサ１０は、IoT_A、IoT_B、IoT_Cそれぞれの通信の特徴量を基に、IoT_A、IoT_B、IoT_Cの正常通信モデルを学習する。
　センサ１０は、IoTデバイスごとの正常通信モデルを基に、各IoTデバイスの通信を監視し、例えば、マルウェア感染等によって発生する悪性サイトへの通信や大量パケットの送信等の異常通信を検知／遮断する。
[正常通信モデル]
　ここで、図２を参照しながら、センサ１０により学習されるIoTデバイスの正常通信モデルを説明する。センサ１０は、例えば、主成分分析等を用いてIoTデバイスの通信に含まれる各特徴量の確率分布の推定を行うことにより、当該IoTデバイスの正常通信モデルを学習する。そして、センサ１０は、正常通信モデルに閾値を設定し、閾値を超えた特徴量に基づく通信を異常通信として検知する。
　例えば、まず、センサ１０は、IoTデバイスの通信の特徴量ごとに単位時間あたりの統計量をカウントする。例えば、センサ１０は、IoT_Aの単位時間あたりの送信パケット数および送信バイト数をカウントする（１．統計量のカウント）。
　そして、センサ１０は、上記の各特徴量を軸とする空間に、１．でカウントした値をプロットし、分散が大きい方向の軸（主成分分析により得られた第一主成分および第二主成分）で正常通信の範囲を決定する。例えば、センサ１０は、図２の破線で囲った範囲をIoT_Aの正常通信の範囲として決定する。そして、センサ１０は、この正常通信の範囲から逸脱した値を異常通信として検知する（２．正常通信モデルの生成（主成分分析））。
[有効特徴量の抽出]
　IoTデバイスには、正常時の通信パターンが少ない機種（安定機種）と、正常時の通信パターンが多い機種（不安定機種）とがある。ここでは、例えば、図３に示すIoT_A、IoT_Bのうち、IoT_Aが安定機種であり、IoT_Bが不安定機種である場合を考える。この場合、IoT_Aの正常通信モデルにおける正常通信の範囲（特徴量の広がり）に比べて、IoT_Bの正常通信モデルにおける正常通信の範囲（特徴量の広がり）の方が大きい（符号１０１，１０２参照）。
　したがって、センサ１０が、IoT_Bの正常通信モデルを用いて、異常通信の検知を行うと、様々な特徴量方向で過検知が発生しやすい。その結果、センサ１０は、NW内のマルウェアの感染拡大によって、複数のIoTデバイスで発生する共通の異常通信を見つけにくい。
　そこで、センサ１０は、例えば、IoT_Aの正常通信モデルに用いられる特徴量１，２，３のうち、異常通信の検知に対して寄与度が高い特徴量１，２を、有効特徴量として抽出する（符号１０３参照）。
　そして、センサ１０は、抽出した有効特徴量（特徴量１，２）を用いて、IoT_Bの正常通信モデルを再構築する（符号１０４参照）。これにより、センサ１０は、IoT_Bの正常通信モデルにおける正常通信の範囲について、不要な特徴量方向への広がりを抑えることができる。その結果、センサ１０は、複数の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デバイスの異常通信の検知結果を用いて、当該IoT_Aの正常通信モデルから、異常通信の検知への寄与度が所定値以上の特徴量を抽出する。
　Ｓ５の後、モデル再構築部１３６は、Ｓ５で抽出された特徴量を用いて、不安定機種のIoTデバイスの正常通信モデルを再構築する（Ｓ６）。そして、検知部１３４は、再構築された正常通信モデルで再度IoTデバイスの異常通信の検知を行う（Ｓ７）。
　Ｓ７の後、分析部１３７は、各IoTデバイスの異常通信の類似度を分析する（Ｓ８）。例えば、そして、分析結果出力部１３８は、Ｓ８における分析結果を出力する（Ｓ９）。
　上記のセンサ１０の処理手順の例を、図６および図７を用いて説明する。例えば、図６に示すように、センサ１０が、新たなIoTデバイス（IoT_A、IoT_B、IoT_C）の通信を観測すると（（１））、学習部１３１は、IoT_A、IoT_B、IoT_Cそれぞれの通信の特徴量に基づき、正常通信モデルを学習する（（２））。
　その後、計算部１３２は、IoT_A、IoT_B、IoT_Cそれぞれの正常通信モデルにおける正常通信の範囲の広がり度合いを、正常通信モデルの各特徴量方向の分散の積により計算する。そして、分類部１３３は、計算された各特徴量方向の分散の積に基づき、IoT_A、IoT_B、IoT_Cを安定機種／不安定機種に分類する（（３））。例えば、分類部１３３は、分散の積の値が所定値より小さいIoT_AおよびIoT_Bを安定機種に分類し、分散の積の値が所定値より大きいIoT_Cを不安定機種に分類する。
　図７の説明に移る。検知部１３４は、IoT_A、IoT_B、IoT_Cについて、それぞれの正常通信モデルを用いて異常通信を検知する（（４）異常検知（１段階目））。そして、特徴量抽出部１３５は、安定機種である、IoT_A、IoT_Bの異常通信の検知への寄与度が所定値以上の特徴量を有効特徴量として抽出する（（５））。例えば、特徴量抽出部１３５は、図７に示す特徴量１，２を有効特徴量として抽出する。
　その後、モデル再構築部１３６は、有効特徴量を用いて、不安定機種であるIoT_Cの正常通信モデルを再構築する。そして、検知部１３４は、再構築された正常通信モデルで、再度、IoT_Cの異常通信の検知を行う（（６）有効特徴量を使った異常検知（２段階目））。そして、分析部１３７は、IoT_A、IoT_B、IoT_Cの異常通信の類似度を分析する。例えば、分析部１３７は、IoT_A、IoT_B、IoT_Cで共通した傾向のある異常を見つける。そして、分析結果出力部１３８は、IoT_A、IoT_B、IoT_Cで共通した傾向のある異常を重要アラートとして出力する。
　このようなセンサ１０によれば、複数のIoTデバイスに共通する異常通信を検知することができる。
[実験結果]
　図８を用いて、センサ１０の実験結果を説明する。ここでは、NW内のポートスキャンによる攻撃を混入したデータを用いて、不安定機種のIoTデバイスの正常通信モデルの再構築により、異常通信の検知を正しく行えるようになったか否かを確認した。
　なお、ポートスキャンによる攻撃データは、図８の破線で示す時間帯に混入した。また、センサ１０は、安定機種のIoTデバイスの正常通信モデルに用いられる特徴量のうち、30％の特徴量を有効特徴量として抽出し、抽出した有効特徴量を用いて不安定機種のIoTデバイスの正常通信モデルの再構築を行い、異常通信の検知を行った。なお、図８に示符号８０１，８０２に示すグラフにおいて、横軸は時間を示し、縦軸は各時刻において正常通信モデルを用いて検知された通信の異常度を示す。
　図８の符号８０１の示すグラフ（特徴量抽出なし）は、センサ１０が、正常通信モデルの再構築を行わずに異常通信の検知を行った場合の実験結果を示す。また、符号８０２に示すグラフ（特徴量抽出あり）は、センサ１０が、正常通信モデルの再構築を行った上で異常通信の検知を行った場合の実験結果を示す。なお、符号８０１に示すグラフにおいて、破線で示す時間帯以外で異常度が高い時間帯は、センサ１０が異常通信の過検知を行った時間帯と考えることができる。
　図８の符号８０１，８０２に示すように、不安定機種のIoTデバイスの正常通信モデルの再構築を行った方が、正常通信モデルの再構築を行わなかった場合に比べ、異常通信の過検知を約85％削減できることが確認できた。これにより、センサ１０は、複数のIoTデバイスに共通する重要アラートを抽出しやすいことが確認できた。
　さらに、図９を用いて、センサ１０の実験結果を説明する。ここでは、NW内の安定機種のIoTデバイス２台、不安定機種のIoTデバイス１３台に対して、異常データを４点混ぜたデータで実験を行った。実験時間は、図８で説明した実験と同様に200時間である。
　図９に示すように、センサ１０は、安定機種のIoTデバイス２台、不安定機種のIoTデバイス１３台それぞれについて、正常通信モデルの再構築を行わなかった場合（＝特徴量抽出なしの場合）と、正常通信モデルの再構築を行った場合（＝特徴量抽出ありの場合）とで異常通信の検知を行った。なお、図９において、False　Positiveは、異常通信の過検知を示し、True　Positiveは、異常通信の正しい検知を示す。
　図９に示すように、センサ１０が、正常通信モデルの再構築を行った場合（＝特徴量抽出ありの場合）、正常通信モデルの再構築を行わなかった場合（＝特徴量抽出なしの場合）に比べ、異常通信の過検知を各IoTデバイスの平均で約80％削減できることが確認できた。
［システム構成等］
　また、図示した各部の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部又は任意の一部が、ＣＰＵ及び当該ＣＰＵにて実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
　また、前記した実施形態において説明した処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
［プログラム］
　前記したセンサ１０は、パッケージソフトウェアやオンラインソフトウェアとしてプログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、上記のプログラムを情報処理装置に実行させることにより、情報処理装置をセンサ１０として機能させることができる。ここで言う情報処理装置には、デスクトップ型又はノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機や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 (6)

  1. 　監視対象のIoT（Internet　of　Things）デバイスごとに学習された、前記IoTデバイスの異常通信を検知するための正常通信モデルそれぞれについて、前記正常通信モデルの示す正常通信の範囲の広がり度合いを計算する計算部と、
    　前記広がり度合いが所定値未満の正常通信モデルを第１の機種のIoTデバイスの正常通信モデルとして分類し、前記広がり度合いが所定値以上の正常通信モデルを第２の機種のIoTデバイスの正常通信モデルとして分類する分類部と、
    　前記第１の機種のIoTデバイスの正常通信モデルを用いて、前記IoTデバイスにおける異常通信を検知する検知部と、
    　前記第１の機種のIoTデバイスの正常通信モデルに用いられる特徴量のうち、前記異常通信の検知への寄与度が所定値以上の特徴量を抽出する特徴量抽出部と、
    　前記抽出した特徴量を用いて、前記第２の機種のIoTデバイスの正常通信モデルを再構築するモデル再構築部と、
    　前記正常通信モデルを用いて検知された前記第１の機種のIoTデバイスの異常通信と、前記再構築された正常通信モデルを用いて検知された前記第２の機種のIoTデバイスの異常通信とを用いて、前記IoTデバイスそれぞれに共通する異常通信を分析する分析部と
    　を備えることを特徴とするトラフィックセンサ。
  2. 　前記計算部は、
    　前記正常通信モデルの示す正常通信の範囲の広がり度合いを、当該正常通信モデルに用いられる各特徴量方向の分散の積により計算する
    　ことを特徴とする請求項１に記載のトラフィックセンサ。
  3. 　前記分析部による、前記IoTデバイスそれぞれの異常通信の分析の結果、類似度が所定値以上の異常通信を出力する分析結果出力部
    　をさらに備えることを特徴とする請求項１に記載のトラフィックセンサ。
  4. 　新たなIoTデバイスの接続を検出すると、前記IoTデバイスの通信データに基づき、当該IoTデバイスの正常通信モデルを学習する学習部
    　をさらに備えることを特徴とする請求項１に記載のトラフィックセンサ。
  5. 　トラフィックセンサにより実行される分析方法であって、
    　監視対象のIoT（Internet　of　Things）デバイスごとに学習された、前記IoTデバイスの異常通信を検知するための正常通信モデルそれぞれについて、前記正常通信モデルの示す正常通信の範囲の広がり度合いを計算する工程と、
    　前記広がり度合いが所定値未満の正常通信モデルを第１の機種のIoTデバイスの正常通信モデルとして分類し、前記広がり度合いが所定値以上の正常通信モデルを第２の機種のIoTデバイスの正常通信モデルとして分類する工程と、
    　前記第１の機種のIoTデバイスの正常通信モデルを用いて、前記IoTデバイスにおける異常通信を検知する工程と、
    　前記第１の機種のIoTデバイスの正常通信モデルに用いられる特徴量のうち、前記異常通信の検知への寄与度が所定値以上の特徴量を抽出する工程と、
    　前記抽出した特徴量を用いて、前記第２の機種のIoTデバイスの正常通信モデルを再構築する工程と、
    　前記正常通信モデルを用いて検知された前記第１の機種のIoTデバイスの異常通信と、前記再構築された正常通信モデルを用いて検知された前記第２の機種のIoTデバイスの異常通信とを用いて、前記IoTデバイスそれぞれに共通する異常通信を分析する工程と
    　を含むことを特徴とする分析方法。
  6. 　監視対象のIoT（Internet　of　Things）デバイスごとに学習された、前記IoTデバイスの異常通信を検知するための正常通信モデルそれぞれについて、前記正常通信モデルの示す正常通信の範囲の広がり度合いを計算する工程と、
    　前記広がり度合いが所定値未満の正常通信モデルを第１の機種のIoTデバイスの正常通信モデルとして分類し、前記広がり度合いが所定値以上の正常通信モデルを第２の機種のIoTデバイスの正常通信モデルとして分類する工程と、
    　前記第１の機種のIoTデバイスの正常通信モデルを用いて、前記IoTデバイスにおける異常通信を検知する工程と、
    　前記第１の機種のIoTデバイスの正常通信モデルに用いられる特徴量のうち、前記異常通信の検知への寄与度が所定値以上の特徴量を抽出する工程と、
    　前記抽出した特徴量を用いて、前記第２の機種のIoTデバイスの正常通信モデルを再構築する工程と、
    　前記正常通信モデルを用いて検知された前記第１の機種のIoTデバイスの異常通信と、前記再構築された正常通信モデルを用いて検知された前記第２の機種のIoTデバイスの異常通信とを用いて、前記IoTデバイスそれぞれに共通する異常通信を分析する工程と
    　をコンピュータに実行させることを特徴とする分析プログラム。
PCT/JP2021/011529 2021-03-19 2021-03-19 トラフィックセンサ、分析方法、および、分析プログラム WO2022195887A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
PCT/JP2021/011529 WO2022195887A1 (ja) 2021-03-19 2021-03-19 トラフィックセンサ、分析方法、および、分析プログラム
EP21931632.0A EP4293549A1 (en) 2021-03-19 2021-03-19 Traffic sensor, analysis method, and analysis program
CN202180095837.7A CN117043770A (zh) 2021-03-19 2021-03-19 通信业务传感器、分析方法以及分析程序
AU2021434202A AU2021434202B2 (en) 2021-03-19 2021-03-19 Traffic sensor, analysis method, and analysis program
JP2023506699A JPWO2022195887A1 (ja) 2021-03-19 2021-03-19

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/011529 WO2022195887A1 (ja) 2021-03-19 2021-03-19 トラフィックセンサ、分析方法、および、分析プログラム

Publications (1)

Publication Number Publication Date
WO2022195887A1 true WO2022195887A1 (ja) 2022-09-22

Family

ID=83322187

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/011529 WO2022195887A1 (ja) 2021-03-19 2021-03-19 トラフィックセンサ、分析方法、および、分析プログラム

Country Status (5)

Country Link
EP (1) EP4293549A1 (ja)
JP (1) JPWO2022195887A1 (ja)
CN (1) CN117043770A (ja)
AU (1) AU2021434202B2 (ja)
WO (1) WO2022195887A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005159646A (ja) * 2003-11-25 2005-06-16 Ntt Docomo Inc パケット通信監視装置、及びパケット通信監視方法
US20190380037A1 (en) * 2017-06-27 2019-12-12 Allot Communications Ltd. System, Device, and Method of Detecting, Mitigating and Isolating a Signaling Storm
JP2019213103A (ja) 2018-06-06 2019-12-12 日本電信電話株式会社 判定装置、判定方法及び判定プログラム
JP2020102671A (ja) * 2018-12-19 2020-07-02 日本電信電話株式会社 検知装置、検知方法、および、検知プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005159646A (ja) * 2003-11-25 2005-06-16 Ntt Docomo Inc パケット通信監視装置、及びパケット通信監視方法
US20190380037A1 (en) * 2017-06-27 2019-12-12 Allot Communications Ltd. System, Device, and Method of Detecting, Mitigating and Isolating a Signaling Storm
JP2019213103A (ja) 2018-06-06 2019-12-12 日本電信電話株式会社 判定装置、判定方法及び判定プログラム
JP2020102671A (ja) * 2018-12-19 2020-07-02 日本電信電話株式会社 検知装置、検知方法、および、検知プログラム

Also Published As

Publication number Publication date
AU2021434202B2 (en) 2024-03-28
JPWO2022195887A1 (ja) 2022-09-22
AU2021434202A1 (en) 2023-09-07
EP4293549A1 (en) 2023-12-20
CN117043770A (zh) 2023-11-10

Similar Documents

Publication Publication Date Title
EP2769508B1 (en) System and method for detection of denial of service attacks
US10303873B2 (en) Device for detecting malware infected terminal, system for detecting malware infected terminal, method for detecting malware infected terminal, and program for detecting malware infected terminal
US10944784B2 (en) Identifying a potential DDOS attack using statistical analysis
CN111262722A (zh) 一种用于工业控制系统网络的安全监测方法
US20210185057A1 (en) Systems and methods for identifying malicious actors or activities
EP3337106B1 (en) Identification system, identification device and identification method
CN111600880A (zh) 异常访问行为的检测方法、系统、存储介质和终端
JP6491356B2 (ja) 分類方法、分類装置および分類プログラム
JPWO2016194123A1 (ja) 中継装置、ネットワーク監視システム及びプログラム
CN108804914B (zh) 一种异常数据检测的方法及装置
CN111641589A (zh) 高级可持续威胁检测方法、系统、计算机以及存储介质
WO2022195887A1 (ja) トラフィックセンサ、分析方法、および、分析プログラム
CN112966264A (zh) Xss攻击检测方法、装置、设备及机器可读存储介质
CN117391214A (zh) 模型训练方法、装置及相关设备
CN114900375A (zh) 一种基于ai图分析的恶意威胁侦测方法
EP3799367B1 (en) Generation device, generation method, and generation program
CN109462503B (zh) 一种数据检测方法和装置
CN113553370A (zh) 异常检测方法、装置、电子设备及可读存储介质
JP7176630B2 (ja) 検知装置、検知方法および検知プログラム
CN111027061A (zh) 一种基于数据包的终端病毒检测方法、装置及存储设备
CN114363148B (zh) 一种检测攻击告警的方法、装置、检测设备及存储介质
CN115378746B (zh) 网络入侵检测规则生成方法、装置、设备以及存储介质
EP4216113A1 (en) Assessment device, assessment method, and assessment program
EP4307612A1 (en) Detection program, detection apparatus, and detection method
CN115102728B (zh) 一种用于信息安全的扫描器识别方法、装置、设备及介质

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: 21931632

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023506699

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2021434202

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2021434202

Country of ref document: AU

Date of ref document: 20210319

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2021931632

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 202180095837.7

Country of ref document: CN

ENP Entry into the national phase

Ref document number: 2021931632

Country of ref document: EP

Effective date: 20230914

NENP Non-entry into the national phase

Ref country code: DE