WO2022118427A1 - 異常検知支援装置、異常検知支援方法及びプログラム - Google Patents

異常検知支援装置、異常検知支援方法及びプログラム Download PDF

Info

Publication number
WO2022118427A1
WO2022118427A1 PCT/JP2020/045031 JP2020045031W WO2022118427A1 WO 2022118427 A1 WO2022118427 A1 WO 2022118427A1 JP 2020045031 W JP2020045031 W JP 2020045031W WO 2022118427 A1 WO2022118427 A1 WO 2022118427A1
Authority
WO
WIPO (PCT)
Prior art keywords
learning
abnormality detection
data
packet
communication
Prior art date
Application number
PCT/JP2020/045031
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/JP2020/045031 priority Critical patent/WO2022118427A1/ja
Publication of WO2022118427A1 publication Critical patent/WO2022118427A1/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/06—Management of faults, events, alarms or notifications
    • H04L41/0686—Additional information in the notification, e.g. enhancement of specific meta-data
    • 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/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services

Definitions

  • the present invention relates to an abnormality detection support device, an abnormality detection support method, and a program.
  • DDS Data Distribution Service
  • Pub / Sub communication middleware for distributed systems.
  • communication values for example, sensor values, etc.
  • behaviors communication intervals, etc.
  • anomaly detection processing has been performed manually for data collection, abnormality definition, and detection program creation.
  • Non-Patent Document 1 a method of automatically generating an abnormality detection program by defining an abnormality according to a predetermined description format. According to this method, data collection and creation of a detection program can be automated.
  • Non-Patent Document 1 since the definition of the abnormality is performed manually, it cannot be completely automated, and when the setting related to communication changes, it is necessary to manually redefine the abnormality. There is a problem that it takes time to restart the abnormality detection process according to the change of the communication setting.
  • the present invention has been made in view of the above points, and an object of the present invention is to support the efficiency of detection of communication abnormalities.
  • the abnormality detection support device provides auxiliary information for extracting the feature amount from the value included in the packet indicating the quality of the Pub / Sub communication by the abnormality detection model related to the Pub / Sub communication.
  • An analysis unit that generates data based on packets indicating quality, and a learning unit that causes the anomaly detection model to perform learning using a data group to which the auxiliary information is added to each packet in the Pub / Sub communication. Have.
  • FIG. 1 is a diagram showing a configuration example of a communication system according to an embodiment of the present invention.
  • one or more Pub devices 20, one or more Sub devices 30, and an abnormality detection support device 10 are connected to the network N1.
  • Pub / Sub communication for a data-centric distributed control system is performed between the application on the Pub device 20 and the application on the Sub device 30.
  • the communication node (Pub device 20 or Sub device 30) on the network N1 is regarded as a participant, other nodes are searched, and the quality related to the Pub / Sub communication (Pub / Sub communication).
  • Pub / Sub communication realized by exchanging communication specifications such as QoS (Quality of Service).
  • QoS Quality of Service
  • Pub / Sub communication middleware for example, DDS (Data Distribution Service) (https://ja.wikipedia.org/wiki/Data_Distribution_Service) is assumed.
  • the Pub device 20 is a device that behaves as a data transmission source (publisher) in Pub / Sub communication.
  • the Sub device 30 is a device that behaves as a data receiving destination (subscriber) in Pub / Sub communication.
  • the abnormality detection support device 10 monitors the communication of the network N1 and causes an abnormality such as a cyber attack (an attack that causes a malfunction of an application by changing the value of each communication or an attack that causes a malfunction of a communication program due to incorrect communication behavior).
  • a cyber attack an attack that causes a malfunction of an application by changing the value of each communication or an attack that causes a malfunction of a communication program due to incorrect communication behavior.
  • Pub / Sub communication has three common properties: "spatial separation”, “temporal separation”, and “asynchronous processing” ("EUGSTER, Patrick Th, et al. The many faces of publish”. /subscribe.ACMcomputingsurveys (CSUR), 2003, 35.2: 114-131. ”).
  • Spatial separation refers to the property that Publisher or Subscriber do not need to know each other's existence.
  • Temporal separation refers to the property that data can be sent and received even if they do not exist on the network at the same time.
  • Asynchronous processing refers to the property that data transmission and reception are processed asynchronously with other processing of Publisher or Subscriber.
  • Pub / Sub communication is roughly classified into a broker type and a brokerless type, and the DDS assumed in the present embodiment belongs to the brokerless type.
  • FIG. 2 is a diagram for explaining the structural difference between the broker type and the brokerless type.
  • (1) shows a broker type configuration.
  • (2) shows a brokerless type configuration.
  • the brokerless type has a distributed configuration in which functions (“DSS” in the figure) responsible for spatial separation, temporal separation, and asynchronous properties are arranged in all nodes (Publisher or Subscriber).
  • DSS functions responsible for spatial separation, temporal separation, and asynchronous properties are arranged in all nodes (Publisher or Subscriber).
  • “PubApp” indicates an application on the Publisher side (data transmission source).
  • “SubApp” indicates an application on the Subscriber side (data usage side).
  • the Publisher DSS is particularly referred to as “DDS Publisher”.
  • Publisher's DSS is particularly referred to as "DDS Subscriber”.
  • the DSS of each node is a communication program (middleware) that is automatically generated based on the definition of the data to be distributed (created by compiling the definition) and includes communication destinations, communication QoS information, and the like as parameters.
  • FIG. 3 is a diagram for explaining the communication procedure on the DDS.
  • FIG. 3 shows the communication procedure from the viewpoint of Publisher in the steps (1) to (4).
  • Step (1) is a participation step.
  • Publisher's DSS announces the existence of its own node on the network (for example, multicasts), announces the participation of its own node, and starts searching for another node.
  • Step (2) is a search step.
  • Publisher's DSS detects the presence of another node based on the response from the other node's DSS to the participation statement.
  • Step (3) is a delivery content agreement step.
  • Publisher's DSS confirms whether it is a Subscriber suitable as a data transmission destination, and forms an agreement with Subscriber regarding QoS.
  • Step (4) is a delivery step.
  • Publisher's DSS sends data about a topic.
  • the data is delivered to the Subscriber who wishes to receive (subscribe) the data.
  • FIG. 4 is a diagram for explaining the types of packets exchanged in DDS. As shown in FIG. 4, in DDS, there are mainly four types of packets: (1) participant information packet, (2) communication QoS information packet, (3) APP data packet, and (4) QoS guarantee packet. Is exchanged.
  • the participant information packet is a packet exchanged in the participation step and the search step in FIG.
  • the communication QoS information packet is a packet exchanged in the delivery content agreement step in FIG.
  • the APP data packet is a packet containing data (that is, application data) transmitted in the delivery step in FIG.
  • the QoS guarantee packet is a packet exchanged to guarantee the QoS agreed in the delivery content agreement step.
  • the packets (1) to (4) are shown to be exchanged in series on the time axis, but various packets are exchanged in parallel. That is, not only the APP data packet and the QoS guarantee packet but also the participant information packet and the communication QoS information packet are continuously exchanged.
  • the anomaly detection support device 10 of this implementation which supports the detection of anomalies in Pub / Sub communication as described above, will be described below.
  • FIG. 5 is a diagram showing a hardware configuration example of the abnormality detection support device 10 according to the embodiment of the present invention.
  • the abnormality detection support device 10 of FIG. 5 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a processor 104, an interface device 105, and the like, which are connected to each other by a bus B, respectively.
  • the program that realizes the processing by the abnormality detection support device 10 is provided by a recording medium 101 such as a CD-ROM.
  • a recording medium 101 such as a CD-ROM.
  • the program is installed in the auxiliary storage device 102 from the recording medium 101 via the drive device 100.
  • the program does not necessarily have to be installed from the recording medium 101, and may be downloaded from another computer via the network.
  • the auxiliary storage device 102 stores the installed program and also stores necessary files, data, and the like.
  • the memory device 103 reads a program from the auxiliary storage device 102 and stores it when there is an instruction to start the program.
  • the processor 104 is a CPU or GPU (Graphics Processing Unit), or a CPU and GPU, and executes a function related to the abnormality detection support device 10 according to a program stored in the memory device 103.
  • the interface device 105 is used as an interface for connecting to a network.
  • FIG. 6 is a diagram showing a functional configuration example of the abnormality detection support device 10 according to the embodiment of the present invention.
  • the abnormality detection support device 10 includes a capture unit 11, a perspective unit 12, a communication QoS information analysis unit 13, a model management unit 14, a data transfer unit 15, a model learning unit 16, an abnormality detection execution unit 17, and a result output unit. It has 18 mag. Each of these parts is realized by a process of causing the processor 104 to execute one or more programs installed in the abnormality detection support device 10.
  • the abnormality detection support device 10 also uses the communication QoS information storage unit 121 and the data storage unit 122.
  • Each of these storage units can be realized by using, for example, a storage device that can be connected to the auxiliary storage device 102 or the abnormality detection support device 10 via a network.
  • the abnormality detection support device 10 is composed of a plurality of computers, each part shown in FIG. 6 may be distributed to the plurality of computers. In this case, each part and the computer may correspond one-to-one, many-to-one, or one-to-many.
  • the capture unit 11 captures (captures) packets flowing through the network N1 for Pub / Sub communication.
  • the packet related to Pub / Sub communication is four types of packets described with reference to FIG.
  • the capture unit 11 may be realized by using, for example, a sniffer (registered trademark).
  • the parsing unit 12 parses the received packet for each packet (hereinafter referred to as “received packet”) captured by the capture unit 11, and parses the parsed result (hereinafter referred to as “parsed packet”) for each received packet.
  • received packet captured by the capture unit 11
  • parses the parsed result hereinafter referred to as “parsed packet” for each received packet.
  • the parsing is a process of extracting the name (item name) and value of each item related to DDS from the received packet.
  • the perspective unit 12 may be realized by using, for example, tshark or the like.
  • FIG. 7 is a diagram showing a configuration example of a parsed packet.
  • the parsed packet includes packet information, frame information, IP information, protocol information (UDP / TCP), Pub / Sub protocol information, and the like obtained from the received packet.
  • Pub / Sub protocol information is a group of parameters (item name and value set) related to Pub / Sub communication.
  • APP data ID "* guaranteed system QoS_N", "* guaranteed system QoS_N value”, "APP data”, and "QoS guaranteed data” will be described in the Pub / Sub protocol information.
  • APP data ID is topic identification information. That is, the "APP data ID” is identification information indicating which topic the received packet is related to.
  • Guarantee system QoS_N (* is "cycle”, “fault tolerance” or “order”, N is 1 to X, Y or Z) is QoS that guarantees the cycle, fault tolerance or order of DDS communication. It is an item name of a related item (hereinafter, referred to as "QoS guarantee item” when the part marked with * is not distinguished).
  • QoS guarantee item an item name of a related item
  • N is a symbol for convenience for distinguishing each of a plurality of items having the same *. Items for which * is a "cycle” are hereinafter referred to as “cycle guarantee items”. Items for which * is “fault-tolerant” are hereinafter referred to as “fault-tolerant guarantee items”. Items for which * is “order” are hereinafter referred to as "order guarantee items”.
  • Guarantee system QoS_N value is the value of the item whose item name is "* Guarantee system QoS_N”.
  • APP data is data transmitted from the application on the Publisher side, and is an effective item when the received packet is an APP data packet.
  • QoS guaranteed data is an item in which data included in the QoS guaranteed packet is stored when the received packet is a QoS guaranteed packet.
  • FIG. 8 is a flowchart for explaining an example of the processing procedure executed by the communication QoS information analysis unit 13, and the communication QoS information analysis unit 13 shows the processing procedure shown in FIG. 8 each time a parsed packet is input. To execute. That is, the processing procedure of FIG. 8 is executed for each parsed packet.
  • step S101 the communication QoS information analysis unit 13 inputs a parsed packet (hereinafter referred to as "target packet") from the parse unit 12.
  • target packet a parsed packet
  • the communication QoS information analysis unit 13 acquires (extracts) communication QoS information from the target packet (S102).
  • the communication QoS information refers to a parameter group excluding the participant ID, the participant domain ID, the message type, the QoS guarantee data, and the APP data from the Pub / Sub protocol information (FIG. 7). That is, in FIG. 7, the parameter group surrounded by the broken line constitutes the communication QoS information.
  • the communication QoS information is information indicating the QoS guaranteed in Pub / Sub communication. Therefore, the communication deviated from the QoS is abnormal. In the present embodiment, abnormality detection is performed based on such a premise.
  • the communication QoS information analysis unit 13 stores the communication QoS information including the same APP data ID as the APP data ID included in the acquired communication QoS information (hereinafter referred to as “target communication QoS information”). It is determined whether or not it is stored in the unit 121 (S103).
  • the communication QoS information analysis unit 13 When the corresponding communication QoS information is not stored in the communication QoS information storage unit 121 (Yes in S103), the communication QoS information analysis unit 13 records the target communication QoS information in the communication QoS information storage unit 121 (S105). Subsequently, the communication QoS information analysis unit 13 generates a QoS identifier which is an identifier of the target communication QoS information (S106).
  • the QoS identifier may be, for example, a hash value of the target QoS information.
  • the communication QoS information analysis unit 13 issues (outputs) a learning start trigger to the model management unit 14 (S107).
  • the learning start trigger is data indicating the trigger for starting learning of the abnormality detection model.
  • the abnormality detection model is a model (for example, a neural network) for detecting an abnormality in Pub / Sub communication in the network N1.
  • FIG. 9 is a diagram showing a configuration example of a learning start trigger.
  • the learning start trigger includes communication QoS information and a QoS identifier.
  • the communication QoS information is the target communication QoS information.
  • the QoS identifier is the QoS identifier generated in step S106.
  • the communication QoS information analysis unit 13 is the target.
  • the communication QoS information and the corresponding communication QoS information are compared, and it is determined whether or not they are the same (S104). Such a determination corresponds to a determination as to whether or not the communication QoS information related to the APP data ID (topic) related to the target communication QoS information has been converted.
  • the transmission interval of data for example, a sensor value
  • other communication QoS information changes due to a change in the performance of a certain device (for example, a sensor) as a public, the device concerned.
  • the communication QoS information analysis unit 13 When the compared two are different (Yes in S104), the communication QoS information analysis unit 13 overwrites the corresponding communication QoS information stored in the communication QoS information storage unit 121 with the target communication QoS information (S105). Therefore, the communication QoS information storage unit 121 stores the latest communication QoS information for each APP data ID (that is, for each topic). Subsequently, steps S106 and S107 are executed as described above. If both are the same in step S104 (No in S104), the communication QoS information has not changed, so steps S105 to S107 are not executed.
  • the learning start trigger is issued when the communication QoS information of a certain topic changes (including the case where the communication QoS information of the topic is discovered for the first time).
  • a change in communication QoS information means a change in the guaranteed QoS.
  • Guaranteed QoS is information that serves as a reference for normal communication. That is, since the change in the communication QoS information means that the criterion of whether it is normal or abnormal changes, a learning start trigger is issued each time.
  • the communication QoS information analysis unit 13 assists (reference or guides) data when the abnormality detection model extracts the feature amount of the target packet (hereinafter, “learning”). Information necessary for generating "auxiliary data") is extracted from the communication QoS information acquired in step S102 (S108).
  • FIG. 10 is a diagram for explaining information extracted from communication QoS information.
  • a cycle guarantee item, a fault tolerance compensation item, and an order guarantee item included in the QoS guarantee item are assigned in the column direction.
  • the first row of the table in FIG. 10 shows the content that abstractly expresses the information extracted by the communication QoS information analysis unit 13 in step S108 from the QoS guarantee items corresponding to each column.
  • the second line shows a specific item name in Pub / Sub protocol information (communication QoS information) for the information abstractly expressed in the first line.
  • the communication QoS information analysis unit 13 extracts the communication interval information to be guaranteed from the periodic system guarantee item, extracts the priority level information (as Owner) from the fault tolerance guarantee system item, and guarantees the order. Extract the guarantee presence / absence information from the system items.
  • the QoS guarantee item of the parsed packet related to the communication QoS information packet includes such information.
  • the communication interval information is information indicating a guaranteed communication interval (for example, the communication interval of each packet).
  • Priority level information (as Owner) is information indicating the priority among the plurality of Publishers when there are a plurality of Publishers for the same topic.
  • the item names of the items corresponding to the communication interval information of the periodic system guarantee items are Deadline and Liveliness.
  • the item names of the items corresponding to the priority level information (as Owner) of the fault tolerance guarantee system items are Ownership and Ownership_Strength.
  • the item name of the item corresponding to the guarantee presence / absence information of the order guarantee system item is Reliability.
  • Deadline and Liveliness are any of the items abstracted by the notation “periodic system guarantee QoS_N” in the parsed packet of FIG. 7.
  • Ownership and Ownership_Strength are any items abstracted by the notation "fault-tolerant guarantee system QoS_N” in the parsed packet of FIG. 7.
  • the reliability is any item abstracted by the notation "order guarantee system QoS_N" in the parsed packet of FIG. 7. That is, according to the example of FIG. 10, in step S108, the communication QoS information analysis unit 13 extracts the respective values of Deadline, Liveliness, Ownership, Ownership_Strength, and Reliability from the target packet.
  • the communication QoS information analysis unit 13 generates learning auxiliary data to be added to the target packet based on the information extracted in step S108 (S109).
  • FIG. 11 is a diagram showing a configuration example of learning auxiliary data.
  • the learning auxiliary data includes small items for each of the major items of "QoS management", “cycle guarantee system”, “fault tolerance guarantee system”, “order guarantee system”, and “learning management”. ..
  • QoS management includes “QoS identifier” and "establishment time”.
  • the communication QoS information analysis unit 13 uses the QoS identifier generated in step S106 and the current time as the values of these items.
  • the "cycle guarantee system” includes annotations generated based on the guaranteed communication interval information (Deadline and Liveliness) extracted from the cycle guarantee system items of the parsed packet as sub-items.
  • the “QoS_N_ * value interval” (N is 1 to X, * is Null, double or half) is communication as shown in the column of the cycle guarantee system in the third row of the table of FIG.
  • the division information based on the interval is shown.
  • the division information based on the communication interval indicates a candidate for a time interval (unit time) for extracting the feature amount at the time of learning, which is determined based on the guaranteed communication interval.
  • FIG. 12 is a diagram for explaining division information based on the communication interval.
  • the horizontal axis corresponds to time
  • the vertical axis represents some value in Pub / Sub communication (for example, APP data as a sensor value).
  • Each point on the periodic curve indicates the observation time of the packet and the value contained in the packet in Pub / Sub communication of a certain topic.
  • the division information is expected that the characteristics of Pub / Sub communication may appear in a cycle that is a multiple of Deadline or Liveliness. According to the example of FIG. 12, if the feature amount (statistical information) can be extracted for each time interval indicated by the broken line rectangle, there is an abnormality in the cycle in which there is a difference with the feature amount. Can be detected.
  • FIG. 13 is a diagram showing an example of an abnormal cycle.
  • (1) shows a period in which the value of a certain packet is abnormal.
  • (2) indicates a cycle in which an abnormality occurs in the communication interval between a certain two packets.
  • the candidates for the cycle are listed in the learning auxiliary data. Therefore, it is desirable that the divided information included in the learning auxiliary data is a value at which such a feature is likely to be obtained.
  • QoS_1_value interval indicates a time interval (division information) of Deadline ⁇ 1.
  • QoS_1_double value interval indicates a time interval (division information) of Deadline ⁇ 2.
  • QoS_1_half price interval indicates a time interval (division information) of Deadline ⁇ 1/2.
  • QoS_X_value interval indicates a time interval (division information) of Liveliness ⁇ 1.
  • QoS_X_double value interval indicates a time interval (division information) of Liveliness ⁇ 2.
  • QoS_X_half price interval indicates a time interval (division information) of Liveliness ⁇ 1/2.
  • the extracted value (Deadline or Liveliness) ⁇ (1, 2, or 1/2) is included in the learning auxiliary data, but the value obtained by multiplying the Deadline or Liveliness is learned.
  • Whether to include it in the auxiliary data may be arbitrarily set. For example, a 10-fold value may be included, or a 100-fold value may be included.
  • the "fault tolerance guarantee system" of the learning auxiliary data in FIG. 11 includes metadata based on priority level information (Ownership and Ownership_Strength) extracted from the fault tolerance guarantee system item of the parsed packet as a sub-item. As shown in the column of the fault tolerance guarantee system in the third row of the table of FIG. 10, the sub-item is a value indicating Primaly and Secondary information to the data source.
  • the "order guarantee system" of the learning auxiliary data in FIG. 11 includes metadata based on the guarantee presence / absence information (Reliability) extracted from the order guarantee system items of the parsed packets as sub-items. As shown in the column of the order guarantee system in the third row of the table of FIG. 10, the sub-item indicates the sequence number difference from the previous packet.
  • the "learning management" of the learning auxiliary data in FIG. 11 includes the "QoS setting change flag" as a sub-item.
  • the "QoS setting change flag” is information indicating that the packet is a packet at the time when the communication QoS information is changed. Therefore, the communication QoS information analysis unit 13 adds the "QoS setting change flag" to the learning auxiliary data only when the learning start trigger is issued based on the target packet (that is, when step S107 is executed).
  • the "QoS setting change flag" enclosed in () indicates that it is a sub-item given only to the packet at the time when the communication QoS information is changed.
  • the communication QoS information analysis unit 13 generates learning assistance data by adding the learning assistance data generated in step S109 to the target packet (S110).
  • FIG. 14 is a diagram showing a configuration example of data with learning assistance. As shown in FIG. 14, the learning-assisted data includes parsed packets and learning-assisted data.
  • the communication QoS information analysis unit 13 records the data with learning assistance in the data storage unit 122 (S111).
  • the recording of the data with learning assistance in the data storage unit 122 triggers the start of the processing of the data transfer unit 15.
  • the model management unit 14 switches between learning the anomaly detection model and executing anomaly detection using the trained anomaly detection model (runtime) using a finite automaton, so that the communication QoS information is changed. Control is performed to automatically change the anomaly detection model by re-learning.
  • FIG. 15 is a diagram for explaining the model management unit 14.
  • FIG. 15 shows the finite automaton A1 used by the model management unit 14.
  • the finite automaton A1 is prepared for each APP data ID (that is, for each topic).
  • the input to the finite automaton A1 is a learning start trigger including the APP data ID corresponding to the finite automaton A1, or a learning result by the model learning unit 16 regarding the abnormality detection model corresponding to the APP data ID. That is, the abnormality detection model is also learned for each APP data ID (that is, for each topic).
  • the finite automaton A1 has three states: a stopped state, a learning state, and a run-time state.
  • the stopped state is a state in which both the learning of the abnormality detection model and the detection of the abnormality using the learned abnormality detection model are stopped.
  • the learning start trigger is input in the stopped state
  • the finite automaton A1 transitions to the learning state after X seconds have elapsed from the input of the learning start trigger (that is, after X seconds have elapsed since the communication QoS information has changed). do.
  • X is given in advance as a set value for the model management unit 14.
  • the model management unit 14 causes the model learning unit 16 to learn the abnormality detection model corresponding to the APP data ID included in the learning start trigger that triggered the transition to the learning state.
  • the learning assisted data group corresponding to the APP data ID related to the finite automaton A1 stored in the data storage unit 122 is accumulated in the data storage unit 122 in the last X seconds of the stopped state.
  • the data group with learning assistance is regarded as a normal data group, and the data group with learning assistance accumulated in the data storage unit 122 before the X seconds is regarded as an abnormal data group. Therefore, when the learning start trigger corresponding to the APP data ID is input for the first time, there is no abnormal data group.
  • the learning result (for example, the correct answer rate) is input to the finite automaton A1 every time the learning by the model learning unit 16 is completed.
  • the details of the correct answer rate will be described later.
  • the model management unit 14 causes the learning to be repeated. In this case, changes are made to the anomaly detection model.
  • the finite automaton A1 transitions to the runtime state. Y is given in advance as a set value for the model management unit 14.
  • the model management unit 14 instructs the model learning unit 16 to apply the abnormality detection model to the abnormality detection execution unit 17, and also uses the abnormality detection execution unit 17 for the abnormality detection execution unit 17. Instructs the start of anomaly detection.
  • the finite automaton A1 transitions to the stopped state.
  • FIG. 16 is a diagram for explaining the output from the model management unit 14 in each state of the finite automaton. Each output from the model management unit 14 is performed each time an input is made to the finite automaton A1.
  • the model management unit 14 In the learning state, the model management unit 14 outputs a learning start instruction to the model learning unit 16.
  • the learning start instruction includes an APP data ID, a QoS identifier, a learning count, and the like.
  • the APP data ID and the QoS identifier As the APP data ID and the QoS identifier, the values included in the learning start trigger are used as they are.
  • the number of learnings is the number of learnings for each APP data ID. Every time a learning start instruction is output, 1 is added to the number of learnings.
  • the model management unit 14 inputs to the model learning unit 16 an instruction to apply the trained abnormality detection model to the abnormality detection execution unit 17, and also inputs an operation instruction to the abnormality detection execution unit 17. do.
  • the abnormality detection execution unit 17 starts abnormality detection using the abnormality detection model.
  • the operation instruction includes the APP data ID included in the learning start trigger.
  • the model management unit 14 Each time the state of the finite automaton A1 transitions, the model management unit 14 notifies the data transfer unit 15 of the state after the transition and the APP data ID corresponding to the finite automaton A1.
  • FIG. 17 is a flowchart for explaining an example of a processing procedure executed by the data transfer unit 15.
  • the data transfer unit 15 executes the processing procedure of FIG. 17 in response to the notification of the state (state after transition) from the model management unit 14 or the recording of new data with learning assistance in the data storage unit 122.
  • the data transfer unit 15 stores the status in the memory device 103 or the like in association with the APP data ID notified together with the status (S202).
  • the data transfer unit 15 stores at least the latest two states for each APP data ID.
  • the data transfer unit 15 is the data with target learning assistance.
  • target finite automaton A1 which is the latest state of the finite automaton A1 (hereinafter referred to as “target finite automaton A1”) corresponding to the APP data ID (hereinafter referred to as “target APP data ID”) of the parsed packet included in Branch the process based on.
  • the latest state can be specified based on the history of the state stored in step S202.
  • the data transfer unit 15 determines whether or not the state of the target finite automaton A1 at the time of recording the previous learning assisted data related to the target APP data ID was the stopped state. Is determined (S205).
  • the previous state can also be specified based on the history of the state stored in step S202.
  • the data transfer unit 15 ends the process related to the data with target learning assistance.
  • the data transfer unit 15 corresponds to the target APP data ID using the packet number of the parsed packet included in the target learning assisted data as the final learning packet number. Attached and stored in the memory device 103 (S206).
  • the packet number is, for example, a received time number included in the packet information (see FIG. 7).
  • the received number is, for example, a number assigned in ascending order to the parsed packet by the parse unit 12. Therefore, the reception order of each parsed packet can be identified by the reception number (packet number).
  • the data transfer unit 15 is a data group with learning assistance from the packet number that triggers the learning start to the final packet number for learning among the data with learning assistance stored in the data storage unit 122 regarding the target APP data ID.
  • the data with learning assistance including the same communication QoS information as the communication QoS information included in the learning start trigger is regarded as normal data, and the data group with learning assistance before the packet number that becomes the learning start trigger (that is, the latest communication).
  • Communication different from QoS information (data group with learning assistance related to QoS information) is transmitted to the model learning unit 16 as abnormal data (S207).
  • the packet number that triggers the learning start is the latest learning assistance data among the learning assistance data including the learning assistance data to which the QoS specification change flag is added among the learning assistance data related to the target APP data ID.
  • the packet number of the packet related to the data is the latest learning assistance data among the learning assistance data including the learning assistance data to which the QoS specification change flag is added among the learning assistance data related to the target APP data ID.
  • the data transfer unit 15 determines whether or not the state of the target finite automaton A1 at the time of recording the learning assisted data related to the previous target APP data ID was the learning state. Is determined (S209). When the previous state is not the learning state (No in S209), the data transfer unit 15 ends the process related to the data with target learning assistance.
  • the data transfer unit 15 is for learning related to the target APP data ID among the data with learning assistance stored in the data storage unit 122 regarding the target APP data ID.
  • the data group with learning assistance from the data with learning assistance related to the final packet number to the data with target learning assistance is transferred to the abnormality detection execution unit 17.
  • the packets that flowed to the network N1 in the period until the abnormality detection model learned by the model learning unit 16 is applied to the abnormality detection execution unit 17 are transmitted. It can be retroactively targeted for abnormality detection.
  • the data transfer unit 15 transfers the target learning assisted data to the abnormality detection execution unit 17 (S211). .. That is, while the runtime state continues, the learning assisted data corresponding to the received packet is transferred to the abnormality detection execution unit 17 in real time. As a result, the abnormality detection execution unit 17 performs abnormality detection in real time.
  • Model learning unit 16 In response to the learning start instruction, the model learning unit 16 learns the abnormality detection model corresponding to the APP data ID included in the learning start instruction. At this time, the data group with learning assistance transferred from the data transfer unit 15 is used as learning data. When the learning data transferred from the data transfer unit 15 contains only normal data, unsupervised learning is executed. In this case, the model learning unit 16 inputs a set of probabilities of normal data output from the abnormality detection model for each learning data to the finite automaton A1 as a learning result. The finite automaton A1 transitions the state when all the probabilities are Y or more. On the other hand, when the learning data transferred from the data transfer unit 15 includes both normal data and abnormal data, supervised learning is executed.
  • the model learning unit 16 inputs the ratio of correct answers (correct answer rate) as to whether the learning data group is normal or abnormal to the finite automaton A1 as a learning result.
  • the finite automaton A1 transitions the state when the correct answer rate is Y or more.
  • a plurality of abnormality detection models may be prepared for one APP data ID.
  • the plurality of anomaly detection models may be neural networks having different model configurations (number of layers, number of nodes), etc., or neural networks having the same model configuration but different hyperparameters.
  • the difference between Primary and Secondary communication amount is the abnormality detection.
  • the maximum value of the permissible sequence number may be used as the feature quantity for abnormality detection if it is a parameter of the order guarantee system among the learning auxiliary data.
  • the QoS guarantee items of the cycle guarantee system and the fault tolerance guarantee system are -The behavior of the APP data packet and the QoS guarantee packet changes greatly depending on the setting change. -It is possible to switch without significantly affecting the application. Since it has two features, it is easy to generate abnormal data, and it can be expected that the detection accuracy will be improved.
  • learning of a plurality of abnormality detection models may be executed in parallel, or one abnormality detection model may be sequentially executed in series.
  • the correct answer rate input to the finite automaton A1 as a learning result may be the highest correct answer rate among the plurality of abnormality detection models.
  • the model learning unit 16 may identify the abnormality detection model to be learned according to the number of learnings included in the learning start instruction.
  • the model learning unit 16 also applies the abnormality detection model having the highest correct answer rate to the abnormality detection execution unit 17 among the abnormality detection models learned in the learning state in response to the application instruction from the model management unit 14.
  • the model learning unit 16 may, for example, save an abnormality detection model having a record-high learning result in association with a QoS identifier included in the learning start instruction. By doing so, when a learning start instruction including the same QoS identifier as the QoS identifier is input, the model learning unit 16 may quickly converge the learning by using the abnormality detection model corresponding to the QoS identifier. good.
  • the anomaly detection execution unit 17 inputs the data with learning assistance transferred from the data transfer unit 15 in the runtime state into the abnormality detection model applied to the anomaly detection execution unit 17, and performs Pub / Sub communication in the network N1. Detects anomalies.
  • the result output unit 18 outputs the abnormality detection result by the abnormality detection execution unit 17.
  • learning data is generated based on the value of the QoS guarantee item included in the communication QoS information packet, and machine learning is executed. Therefore, the abnormality detection algorithm is automatically used. Can be generated. Therefore, it is possible to support the efficiency of detecting communication abnormalities.
  • abnormality detection processing is automatically changed according to the new communication QoS information (abnormality detection processing).
  • the efficiency of communication abnormality detection can be improved by automatically controlling "change of communication setting" and "optimization support of abnormality detection processing".
  • the communication QoS information analysis unit 13 is an example of the analysis unit.
  • the model learning unit 16 is an example of the learning unit.
  • the abnormality detection execution unit 17 is an example of the execution unit.
  • Learning auxiliary data is an example of auxiliary information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Databases & Information Systems (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Software Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

異常検知支援装置は、Ｐｕｂ／Ｓｕｂ通信に関する異常検知モデルが前記Ｐｕｂ／Ｓｕｂ通信の品質を示すパケットに含まれる値から特徴量を抽出するための補助情報を、前記品質を示すパケットに基づいて生成する解析部と、前記Ｐｕｂ／Ｓｕｂ通信における各パケットに対して前記補助情報が付与されたデータ群を用いた学習を、前記異常検知モデルに実行させる学習部と、を有することで、通信の異常の検知の効率化を支援する。

Description

異常検知支援装置、異常検知支援方法及びプログラム
　本発明は、異常検知支援装置、異常検知支援方法及びプログラムに関する。
　分散システム向けのＰｕｂ／Ｓｕｂ通信ミドルウェアとして、ＤＤＳ（Data Distribution Service）が知られている。ＤＤＳによる通信の値（例えば、センサ値等）の変化や振る舞い（通信間隔等）の変化を検知することで、サイバー攻撃等の何らかの異常を検知することができる。従来、このような異常検知処理は、データ収集、異常の定義、検知プログラム作成について全て手作業で行われていた。
　これに対して近年、所定の記述様式に従って異常を定義することで自動的に異常検知プログラムを生成する手法が提案されている（非特許文献１）。当該手法によれば、データ収集及び検知プログラムの作成を自動化することができる。
HASAN, MD Siam, et al. A constraint-based intrusion detection system. In: Proceedings of the Fifth European Conference on the Engineering of Computer-Based Systems. 2017. p. 1-10.
　しかしながら、非特許文献１の手法では、異常の定義を人手で行うため、完全な自動化はできず、また、通信に関する設定が変化したときは、再度、人手によって異常の定義をやり直す必要が有るため、通信設定の変更に応じた異常検知処理の再開に時間がかかるという課題が有る。
　本発明は、上記の点に鑑みてなされたものであって、通信の異常の検知の効率化を支援することを目的とする。
　そこで上記課題を解決するため、異常検知支援装置は、Ｐｕｂ／Ｓｕｂ通信に関する異常検知モデルが前記Ｐｕｂ／Ｓｕｂ通信の品質を示すパケットに含まれる値から特徴量を抽出するための補助情報を、前記品質を示すパケットに基づいて生成する解析部と、前記Ｐｕｂ／Ｓｕｂ通信における各パケットに対して前記補助情報が付与されたデータ群を用いた学習を、前記異常検知モデルに実行させる学習部と、を有する。
　通信の異常の検知の効率化を支援することができる。
本発明の実施の形態における通信システムの構成例を示す図である。 ブローカ型とブローカレス型の構成上の違いを説明するための図である。 ＤＤＳ上の通信手続きを説明するための図である。 ＤＤＳにおいてやりとりされるパケットの種類を説明するための図である。 本発明の実施の形態における異常検知支援装置１０のハードウェア構成例を示す図である。 本発明の実施の形態における異常検知支援装置１０の機能構成例を示す図である。 パース済みパケットの構成例を示す図である。 通信ＱｏＳ情報解析部１３が実行する処理手順の一例を説明するためのフローチャートである。 学習開始トリガの構成例を示す図である。 通信ＱｏＳ情報から抽出される情報を説明するための図である。 学習補助データの構成例を示す図である。 通信間隔に基づく分割情報を説明するための図である。 異常な周期の一例を示す図である。 学習補助付きデータの構成例を示す図である。 モデル管理部１４を説明するための図である。 有限オートマトンの各状態におけるモデル管理部１４からの出力を説明するための図である。 データ転送部１５が実行する処理手順の一例を説明するためのフローチャートである。
　以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における通信システムの構成例を示す図である。図１において、１以上のＰｕｂ装置２０、１以上のＳｕｂ装置３０、及び異常検知支援装置１０は、ネットワークＮ１に接続される。
　ネットワークＮ１においては、Ｐｕｂ装置２０上のアプリケーションとＳｕｂ装置３０上のアプリケーションとの間において、データ中心型分散制御システム向けＰｕｂ／Ｓｕｂ通信が行われる。当該Ｐｕｂ／Ｓｕｂ通信は、配信するデータの定義に基づき、ネットワークＮ１上の通信ノード（Ｐｕｂ装置２０又はＳｕｂ装置３０）を参加者としてみなし、他のノードを探索し、Ｐｕｂ／Ｓｕｂ通信に関する品質（ＱｏＳ（Quality of Service））などの通信仕様を交換することで実現されるＰｕｂ／Ｓｕｂ通信をいう。斯かるＰｕｂ／Ｓｕｂ通信のミドルウェアとして、例えば、ＤＤＳ（Data Distribution Service）（https://ja.wikipedia.org/wiki/Data_Distribution_Service）が想定される。
　Ｐｕｂ装置２０は、Ｐｕｂ／Ｓｕｂ通信におけるデータの送信元（出版側（publisher））として振る舞う装置である。Ｓｕｂ装置３０は、Ｐｕｂ／Ｓｕｂ通信におけるデータの受信先（購読側（subscriber））として振る舞う装置である。
　異常検知支援装置１０は、ネットワークＮ１の通信を監視し、サイバー攻撃（個々の通信の値を変えてアプリケーションの誤動作を引き起こす攻撃や誤った通信の振る舞いによる通信プログラムの誤動作を引き起こす攻撃）等の異常の検知の支援を行う１以上のコンピュータである。
　本実施の形態におけるＰｕｂ／Ｓｕｂ通信について補足する。一般的に、Ｐｕｂ／Ｓｕｂ通信には「空間的分離」、「時間的分離」、「非同期処理」の３つが共通の性質として見られる（「EUGSTER, Patrick Th, et al. The many faces of publish/subscribe. ACM computing surveys (CSUR), 2003, 35.2: 114-131.」）。
　空間的分離とは、Ｐｕｂｌｉｓｈｅｒ又はＳｕｂｓｃｒｉｂｅｒが、互いの存在を知る必要がない性質をいう。時間的分離とは、お互いが同時にネットワーク上に存在しなくてもデータの送受信が可能であるという性質をいう。非同期処理とは、データの送信及び受信は、Ｐｕｂｌｉｓｈｅｒ又はＳｕｂｓｃｒｉｂｅｒのその他処理と非同期で処理される性質をいう。
　また、Ｐｕｂ／Ｓｕｂ通信の構成には、ブローカ型とブローカレス型に大別されるところ、本実施の形態において想定されているＤＤＳは、ブローカレス型に属する。
　図２は、ブローカ型とブローカレス型の構成上の違いを説明するための図である。図２において、（１）は、ブローカ型の構成を示す。（２）は、ブローカレス型の構成を示す。
　ブローカ型では、空間的分離、時間的分離、非同期の性質を担う機能（図中の「Ｂｒｏｋｅｒ」）がＰｕｂｌｉｓｈｅｒとＳｕｂｓｃｒｉｂｅｒの間に配置される。
　一方、ブローカレス型では、全てのノード（Ｐｕｂｌｉｓｈｅｒ又はＳｕｂｓｃｒｉｂｅｒ）に、空間的分離、時間的分離、非同期の性質を担う機能（図中の「ＤＳＳ」）が配置される分散構成を有する。なお、図中において「ＰｕｂＡｐｐ」は、Ｐｕｂｌｉｓｈｅｒ側（データの送信元）のアプリケーションを示す。「ＳｕｂＡｐｐ」は、Ｓｕｂｓｃｒｉｂｅｒ側（データの利用側）のアプリケーションを示す。また、ＰｕｂｌｉｓｈｅｒのＤＳＳは、特に、「ＤＤＳ　Ｐｕｂｌｉｓｈｅｒ」という。ＰｕｂｌｉｓｈｅｒのＤＳＳは、特に、「ＤＤＳ　Ｓｕｂｓｃｒｉｂｅｒ」という。各ノードのＤＳＳは、配信されるデータの定義に基づき自動生成される（当該定義のコンパイルにより作成される）、通信先や通信ＱｏＳ情報などをパラメータとして含む通信プログラム（ミドルウェア）である。
　図３は、ＤＤＳ上の通信手続きを説明するための図である。図３には、Ｐｕｂｌｉｓｈｅｒからの観点での通信手続きが（１）～（４）のステップで示されている。
　ステップ（１）は、参加ステップである。参加ステップにおいて、ＰｕｂｌｉｓｈｅｒのＤＳＳは、自ノードの存在をネットワーク上に通知する（例えば、マルチキャストする）ことで、自ノードの参加を表明すると共に他ノードの探索を開始する。
　ステップ（２）は、探索ステップである。探索ステップにおいて、ＰｕｂｌｉｓｈｅｒのＤＳＳは、参加表明に対する他ノードのＤＳＳからの応答に基づき、他ノードの存在を検知する。
　ステップ（３）は、配信内容合意ステップである。配信内容合意ステップにおいて、ＰｕｂｌｉｓｈｅｒのＤＳＳは、データの送信先としてふさわしいＳｕｂｓｃｒｉｂｅｒであるかを確認すると共に、ＱｏＳに関してＳｕｂｓｃｒｉｂｅｒとの間で合意を形成する。
　ステップ（４）は、配信ステップである。配信ステップにおいて、ＰｕｂｌｉｓｈｅｒのＤＳＳは、或るトピックに関するデータを送信する。或るトピックに関するデータが送信された場合、当該データの受信（購読）を希望しているＳｕｂｓｃｒｉｂｅｒへ当該データが配信される。
　図４は、ＤＤＳにおいてやりとりされるパケットの種類を説明するための図である。図４に示されるように、ＤＤＳにおいては、主として、（１）参加者情報パケット、（２）通信ＱｏＳ情報パケット、（３）ＡＰＰ用データパケット及び（４）ＱｏＳ保証用パケットの４種類のパケットがやりとりされる。
　参加者情報パケットは、図３における参加ステップ及び探索ステップにおいてやりとりされるパケットである。通信ＱｏＳ情報パケットは、図３における配信内容合意ステップにおいてやりとりされるパケットである。ＡＰＰ用データパケットは、図３における配信ステップにおいて送信されるデータ（すなわち、アプリケーションのデータ）を含むパケットである。ＱｏＳ保証用パケットは、配信内容合意ステップにおいて合意されたＱｏＳを保証するためにやりとりされるパケットである。
　なお、図４では、便宜上、（１）～（４）のパケットが時間軸において直列的にやりとりされるように示されているが、各種パケットは、並列的にやりとりされる。すなわち、ＡＰＰ用データパケット及びＱｏＳ保証用パケットのみならず、参加者情報パケット及び通信ＱｏＳ情報パケットも継続的にやりとりされる。
　上記のようなＰｕｂ／Ｓｕｂ通信における異常の検知を支援する、本実施の異常検知支援装置１０について以下に説明する。
　図５は、本発明の実施の形態における異常検知支援装置１０のハードウェア構成例を示す図である。図５の異常検知支援装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、プロセッサ１０４、及びインタフェース装置１０５等を有する。
　異常検知支援装置１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。プロセッサ１０４は、ＣＰＵ若しくはＧＰＵ（Graphics Processing Unit）、又はＣＰＵ及びＧＰＵであり、メモリ装置１０３に格納されたプログラムに従って異常検知支援装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
　図６は、本発明の実施の形態における異常検知支援装置１０の機能構成例を示す図である。図６において、異常検知支援装置１０は、キャプチャ部１１、パース部１２、通信ＱｏＳ情報解析部１３、モデル管理部１４、データ転送部１５、モデル学習部１６、異常検知実行部１７及び結果出力部１８等を有する。これら各部は、異常検知支援装置１０にインストールされた１以上のプログラムが、プロセッサ１０４に実行させる処理により実現される。異常検知支援装置１０は、また、通信ＱｏＳ情報記憶部１２１及びデータ記憶部１２２を利用する。これら各記憶部は、例えば、補助記憶装置１０２、又は異常検知支援装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。なお、異常検知支援装置１０が複数のコンピュータによって構成される場合、図６に示した各部は、複数のコンピュータに分散されてもよい。この場合、各部とコンピュータが１対１、多対１又は１対多に対応してもよい。
　［キャプチャ部１１］
　キャプチャ部１１は、Ｐｕｂ／Ｓｕｂ通信に関してネットワークＮ１を流れるパケット取り込む（キャプチャする）。Ｐｕｂ／Ｓｕｂ通信に関するパケットとは、図４において説明した４種類のパケットである。キャプチャ部１１は、例えば、スニファ（登録商標）を用いて実現されてもよい。
　［パース部１２］
　パース部１２は、キャプチャ部１１によって取り込まれパケット（以下、「受信パケット」という。）ごとに、当該受信パケットをパースし、パース結果（以下、「パース済みパケット」という。）を受信パケットごとに通信ＱｏＳ情報解析部１３へ入力する。パースとは、受信パケットからＤＤＳに関する各項目の名前（項目名）及び値を抽出する処理をいう。パース部１２は、例えば、ｔｓｈａｒｋ等を用いて実現されてもよい。
　図７は、パース済みパケットの構成例を示す図である。図７に示されるように、パース済みパケットは、受信パケットから得られる、パケット情報、フレーム情報、ＩＰ情報、プロトコル情報（ＵＤＰ／ＴＣＰ）、Ｐｕｂ／Ｓｕｂプロトコル情報等を含む。これらの情報のうち、Ｐｕｂ／Ｓｕｂプロトコル情報は、Ｐｕｂ／Ｓｕｂ通信に関するパラメータ（項目名及び値の組）群である。ここでは、Ｐｕｂ／Ｓｕｂプロトコル情報において、「ＡＰＰデータＩＤ」、「＊保証系ＱｏＳ＿Ｎ」，「＊保証系ＱｏＳ＿Ｎの値」、「ＡＰＰデータ」及び「ＱｏＳ保証データ」について説明する。
　「ＡＰＰデータＩＤ」は、トピックの識別情報である。すなわち、「ＡＰＰデータＩＤ」は、受信パケットがいずれのトピックに関するパケットであるのかを示す識別情報である。
　「＊保証系ＱｏＳ＿Ｎ」（＊は、「周期」、「耐障害」又は「順序」、Ｎは、１～Ｘ、Ｙ又はＺ）は、ＤＤＳの通信の周期、耐障害又は順序を保証するＱｏＳ関連の項目（以下、＊の部分を区別しない場合「ＱｏＳ保証項目」という。）の項目名である。なお、＊保証系ＱｏＳ＿Ｎの「Ｎ」は、＊が同一の複数の項目のそれぞれを区別するための便宜上の記号である。なお、＊が「周期」である項目を、以下「周期保証系項目」という。＊が「耐障害」である項目を、以下「耐障害保証系項目」という。＊が「順序」である項目を、以下「順序保証系項目」という。
　「＊保証系ＱｏＳ＿Ｎの値」は、「＊保証系ＱｏＳ＿Ｎ」を項目名とする項目の値である。
　なお、「＊保証系ＱｏＳ＿Ｎ」及び「＊保証系ＱｏＳ＿Ｎの値」は、受信パケットが通信ＱｏＳ情報パケットである場合に有効となる項目である。
　「ＡＰＰデータ」は、Ｐｕｂｌｉｓｈｅｒ側のアプリケーションから送信されたデータであり、受信パケットがＡＰＰ用データパケットである場合に有効な項目である。
　「ＱｏＳ保証データ」は、受信パケットがＱｏＳ保証用パケットである場合に当該ＱｏＳ保証用パケットに含まれているデータが格納される項目である。
　［通信ＱｏＳ情報解析部１３］
　図８は、通信ＱｏＳ情報解析部１３が実行する処理手順の一例を説明するためのフローチャートである通信ＱｏＳ情報解析部１３は、パース済みパケットが入力されるたびに、図８に示される処理手順を実行する。すなわち、図８の処理手順は、パース済みパケットごとに実行される。
　ステップＳ１０１において、通信ＱｏＳ情報解析部１３は、パース部１２からパース済みパケット（以下、「対象パケット」という。）を入力する。
　続いて、通信ＱｏＳ情報解析部１３は、対象パケットから通信ＱｏＳ情報を取得（抽出）する（Ｓ１０２）。通信ＱｏＳ情報とは、Ｐｕｂ／Ｓｕｂプロトコル情報（図７）から、参加者ＩＤ、参加者ドメインＩＤ、メッセージ種別、ＱｏＳ保証データ及びＡＰＰデータを除いたパラメータ群をいう。すなわち、図７において、破線で囲まれたパラメータ群が通信ＱｏＳ情報を構成する。なお、通信ＱｏＳ情報は、Ｐｕｂ／Ｓｕｂ通信において保証されるＱｏＳを示す情報である。したがって、当該ＱｏＳから外れた通信は、異常であることになる。本実施の形態では、斯かる前提に基づいて異常検知が行われる。
　続いて、通信ＱｏＳ情報解析部１３は、取得した通信ＱｏＳ情報（以下「対象通信ＱｏＳ情報」という。）に含まれているＡＰＰデータＩＤと同じＡＰＰデータＩＤを含む通信ＱｏＳ情報が通信ＱｏＳ情報記憶部１２１に記憶されているか否かを判定する（Ｓ１０３）。
　該当する通信ＱｏＳ情報が通信ＱｏＳ情報記憶部１２１に記憶されていない場合（Ｓ１０３でＹｅｓ）、通信ＱｏＳ情報解析部１３は、対象通信ＱｏＳ情報を通信ＱｏＳ情報記憶部１２１に記録する（Ｓ１０５）。続いて、通信ＱｏＳ情報解析部１３は、対象通信ＱｏＳ情報の識別子であるＱｏＳ識別子を生成する（Ｓ１０６）。ＱｏＳ識別子は、例えば、対象Ｑｏｓ情報のハッシュ値であってもよい。
　続いて、通信ＱｏＳ情報解析部１３は、学習開始トリガをモデル管理部１４に対して発出（出力）する（Ｓ１０７）。学習開始トリガとは、異常検知モデルの学習の開始の契機を示すデータをいう。異常検知モデルとは、ネットワークＮ１におけるＰｕｂ／Ｓｕｂ通信の異常を検知するためのモデル（例えば、ニューラルネットワーク）である。
　図９は、学習開始トリガの構成例を示す図である。図９に示されるように、学習開始トリガは、通信ＱｏＳ情報及びＱｏＳ識別子を含む。通信ＱｏＳ情報は、対象通信ＱｏＳ情報である。ＱｏＳ識別子は、ステップＳ１０６において生成されたＱｏＳ識別子である。
　一方、ステップＳ１０３において該当する通信ＱｏＳ情報（以下、「該当通信ＱｏＳ情報」という。）が通信ＱｏＳ情報記憶部１２１に記憶されている場合（Ｓ１０３でＮｏ）、通信ＱｏＳ情報解析部１３は、対象通信ＱｏＳ情報と該当通信ＱｏＳ情報とを比較して、両者が同一であるか否かを判定する（Ｓ１０４）。斯かる判定は、対象通信ＱｏＳ情報に係るＡＰＰデータＩＤ（トピック）に関する通信ＱｏＳ情報が変換したか否かの判定に相当する。一例として、Ｐｕｂｌｉｓｈｅｒとしての或る装置（例えば、センサ）の性能の変化によって、データ（例えば、センサ値）の送信間隔が変化したり、その他の通信ＱｏＳ情報が変化したりした場合に、当該装置が送信するデータのトピックの通信ＱｏＳ情報は変化する。
　比較された両者が異なる場合（Ｓ１０４でＹｅｓ）、通信ＱｏＳ情報解析部１３は、通信ＱｏＳ情報記憶部１２１に記憶されている該当通信ＱｏＳ情報を対象通信ＱｏＳ情報によって上書きする（Ｓ１０５）。したがって通信ＱｏＳ情報記憶部１２１には、ＡＰＰデータＩＤ別（すなわち、トピック別）に最新の通信ＱｏＳ情報が記憶される。続いて、上述した通りにステップＳ１０６及びＳ１０７が実行される。なお、ステップＳ１０４において、比較された両者が同じである場合（Ｓ１０４でＮｏ）、通信ＱｏＳ情報は変化していないため、ステップＳ１０５～Ｓ１０７は実行されない。
　上記から明らかなように、学習開始トリガは、或るトピックの通信ＱｏＳ情報が変化した場合（当該トピックの通信ＱｏＳ情報が初めて発見された場合も含む）に発出される。通信ＱｏＳ情報が変化することは、保証されるＱｏＳが変化することである。保証されるＱｏＳとは正常な通信の基準となる情報である。すなわち、通信ＱｏＳ情報が変化することは、正常であるか異常であるかの基準が変化することであるため、その度に学習開始トリガが発出される。
　ステップＳ１０７、又はステップＳ１０４でＮｏの場合に続いて、通信ＱｏＳ情報解析部１３は、異常検知モデルが対象パケットの特徴量を抽出する際に補助（基準又はガイド）となるデータ（以下、「学習補助データ」という。）の生成に必要な情報を、ステップＳ１０２において取得した通信ＱｏＳ情報から抽出する（Ｓ１０８）。
　図１０は、通信ＱｏＳ情報から抽出される情報を説明するための図である。図１０の表において、列方向には、ＱｏＳ保証項目に含まれる周期保証系項目、耐障害補償系項目、順序保証系項目が割り当てられている。
　図１０の表の１行目は、各列に対応するＱｏＳ保証項目から、ステップＳ１０８において通信ＱｏＳ情報解析部１３が抽出する情報を抽象的に表現した内容を示す。２行目は、１行目において抽象的に表現された情報について、Ｐｕｂ／Ｓｕｂプロトコル情報（の通信ＱｏＳ情報）における具体的な項目名を示す。
　１行目によれば、通信ＱｏＳ情報解析部１３は、周期系保証項目からは保証する通信間隔情報を抽出し、耐障害保証系項目から（Ｏｗｎｅｒとしての）優先レベル情報を抽出し、順序保証系項目から保証の有無情報を抽出する。換言すれば、通信ＱｏＳ情報パケットに係るパース済みパケットのＱｏＳ保証項目には、これらの情報が含まれている。なお、通信間隔情報とは、保証される通信間隔（例えば、各パケットの通信間隔）を示す情報である。（Ｏｗｎｅｒとしての）優先レベル情報とは、同一のトピックに対して複数のＰｕｂｌｉｓｈｅｒが存在する場合に、当該複数のＰｕｂｌｉｓｈｅｒ間の優先度を示す情報である。
　２行目によれば、周期系保証項目の通信間隔情報に該当する項目の項目名は、Ｄｅａｄｌｉｎｅ及びＬｉｖｅｌｉｎｅｓｓである。耐障害保証系項目の（Ｏｗｎｅｒとしての）優先レベル情報に該当する項目の項目名は、Ｏｗｎｅｒｓｈｉｐ及びＯｗｎｅｒｓｈｉｐ＿Ｓｔｒｅｎｇｔｈである。順序保証系項目の保証の有無情報に該当する項目の項目名は、Ｒｅｌｉａｂｉｌｉｔｙである。
　なお、Ｄｅａｄｌｉｎｅ及びＬｉｖｅｌｉｎｅｓｓは、図７のパース済みパケットにおいて「周期系保証ＱｏＳ＿Ｎ」という表記によって抽象化されているいずれかの項目である。また、Ｏｗｎｅｒｓｈｉｐ及びＯｗｎｅｒｓｈｉｐ＿Ｓｔｒｅｎｇｔｈは、図７のパース済みパケットにおいて「耐障害保証系ＱｏＳ＿Ｎ」いう表記によって抽象化されているいずれかの項目である。更に、Ｒｅｌｉａｂｉｌｉｔｙは、図７のパース済みパケットにおいて「順序保証系ＱｏＳ＿Ｎ」いう表記によって抽象化されているいずれかの項目である。すなわち、図１０の例によれば、通信ＱｏＳ情報解析部１３は、ステップＳ１０８において、Ｄｅａｄｌｉｎｅ、Ｌｉｖｅｌｉｎｅｓｓ、Ｏｗｎｅｒｓｈｉｐ、Ｏｗｎｅｒｓｈｉｐ＿Ｓｔｒｅｎｇｔｈ及びＲｅｌｉａｂｉｌｉｔｙのそれぞれの値を対象パケットから抽出する。
　続いて、通信ＱｏＳ情報解析部１３は、ステップＳ１０８において抽出された情報に基づいて、対象パケットに対して付与する学習補助データを生成する（Ｓ１０９）。
　図１１は、学習補助データの構成例を示す図である。図１１に示されるように、学習補助データは、「ＱｏＳ管理」、「周期保証系」、「耐障害保証系」、「順序保証系」及び「学習管理」の大項目ごとに小項目を含む。
　「ＱｏＳ管理」は、「ＱｏＳ識別子」及び「成立時刻」を含む。通信ＱｏＳ情報解析部１３は、ステップＳ１０６において生成したＱｏＳ識別子と現在時刻とをこれらの項目の値とする。
　「周期保証系」は、パース済みパケットの周期保証系項目から抽出された、保証する通信間隔情報（Ｄｅａｄｌｉｎｅ及びＬｉｖｅｌｉｎｅｓｓ）に基づいて生成されるアノテーションを小項目として含む。図１１において「ＱｏＳ＿Ｎ＿＊値区間」（Ｎは１～Ｘ、＊は、Ｎｕｌｌ，倍又は半）は、図１０の表の３行目の周期保証系の列に示されているように、通信間隔に基づく分割情報を示す。通信間隔に基づく分割情報とは、保証する通信間隔に基づいて定められる、学習時の特徴量を抽出する時間区間（単位時間）の候補を示す。
　図１２は、通信間隔に基づく分割情報を説明するための図である。図１２において、横軸は時間に対応し、縦軸はＰｕｂ／Ｓｕｂ通信における何らかの値（例えば、センサ値としてＡＰＰデータ）を示す。周期的な曲線上の各点は、或るトピックのＰｕｂ／Ｓｕｂ通信におけるパケットの観測時刻と当該パケットに含まれている値を示す。
　当該分割情報は、Ｐｕｂ／Ｓｕｂ通信の特徴がＤｅａｄｌｉｎｅ又はＬｉｖｅｌｉｎｅｓｓの倍数の周期で現れる可能性を期待したものである。図１２の例によれば、破線の矩形によって示されている時間区間ごとに特徴量（統計情報）を抽出することができれば、その特徴量に対して差異がある周期において、異常があったことを検知できる。
　例えば、図１３は、異常な周期の一例を示す図である。図１３において（１）は、或るパケットの値が異常である周期を示す。（２）は、或る２つのパケット間の通信間隔に異常が発生した周期を示す。
　但し、その周期（時間区間）がいずれであるかは既知でない。そこで、その周期の候補が学習補助データに列記される。したがって、学習補助データに含められる分割情報は、斯かる特徴が得られる可能性の高い値であることが望ましい。
　図１１の例において、「ＱｏＳ＿１＿値区間」は、Ｄｅａｄｌｉｎｅ×１の時間区間（分割情報）を示す。「ＱｏＳ＿１＿倍値区間」は、Ｄｅａｄｌｉｎｅ×２の時間区間（分割情報）を示す。「ＱｏＳ＿１＿半値区間」は、Ｄｅａｄｌｉｎｅ×１／２の時間区間（分割情報）を示す。また、例えば、「ＱｏＳ＿Ｘ＿値区間」は、Ｌｉｖｅｌｉｎｅｓｓ×１の時間区間（分割情報）を示す。「ＱｏＳ＿Ｘ＿倍値区間」は、Ｌｉｖｅｌｉｎｅｓｓ×２の時間区間（分割情報）を示す。「ＱｏＳ＿Ｘ＿半値区間」は、Ｌｉｖｅｌｉｎｅｓｓ×１／２の時間区間（分割情報）を示す。なお、この例では、抽出された値（Ｄｅａｄｌｉｎｅ又はＬｉｖｅｌｉｎｅｓｓ）×（１，２又は１／２）が学習補助データに含まれる例が示されているが、Ｄｅａｄｌｉｎｅ又はＬｉｖｅｌｉｎｅｓｓを何倍した値を学習補助データに含めるかは任意に設定可能とされてよい。例えば、１０倍の値が含められてもよいし、１００倍の値が含められてもよい。
　図１１の学習補助データの「耐障害保証系」は、パース済みパケットの耐障害保証系項目から抽出された優先レベル情報（Ｏｗｎｅｒｓｈｉｐ及びＯｗｎｅｒｓｈｉｐ＿Ｓｔｒｅｎｇｔｈ）に基づくメタデータを小項目として含む。図１０の表の３行目の耐障害保証系の列に示されているように、当該小項目は、データソースへのＰｒｉｍａｌｙ、Ｓｅｃｏｎｄａｒｙ情報を示す値である。
　図１１の学習補助データの「順序保証系」は、パース済みパケットの順序保証系項目から抽出された保証の有無情報（Ｒｅｌｉａｂｉｌｉｔｙ）に基づくメタデータを小項目として含む。図１０の表の３行目の順序保証系の列に示されているように、当該小項目は、前パケットとのシーケンス番号差分を示す。
　図１１の学習補助データの「学習管理」は、「ＱｏＳ設定変更フラグ」を小項目として含む。「ＱｏＳ設定変更フラグ」は、通信ＱｏＳ情報が変化した時点のパケットであることを示す情報である。したがって、通信ＱｏＳ情報解析部１３は、対象パケットに基づいて学習開始トリガを発出した場合（すなわち、ステップＳ１０７を実行した場合）に限って、「ＱｏＳ設定変更フラグ」を学習補助データに付加する。なお、図１１において、「ＱｏＳ設定変更フラグ」が（）で囲まれているのは、通信ＱｏＳ情報が変化した時点のパケットにのみ付与される小項目であることを示す。
　続いて、通信ＱｏＳ情報解析部１３は、ステップＳ１０９において生成した学習補助データを対象パケットに付与することで、学習補助付きデータを生成する（Ｓ１１０）。
　図１４は、学習補助付きデータの構成例を示す図である。図１４に示されるように、学習補助付きデータは、パース済みパケットと学習補助データとを含む。
　続いて、通信ＱｏＳ情報解析部１３は、学習補助付きデータをデータ記憶部１２２に記録する（Ｓ１１１）。なお、データ記憶部１２２への学習補助付きデータの記録は、データ転送部１５の処理の開始の契機となる。
　［モデル管理部１４］
　モデル管理部１４は、異常検知モデルの学習と学習済みの異常検知モデルを用いた異常検知の実行（ランタイム）とを、有限オートマトンを用いて切り替えることによって、通信ＱｏＳ情報が変更された場合に、再学習により自動的に異常検知モデルを変更するための制御を行う。
　図１５は、モデル管理部１４を説明するための図である。図１５には、モデル管理部１４が用いる有限オートマトンＡ１が示されている。有限オートマトンＡ１は、ＡＰＰデータＩＤ別（すなわち、トピック別）に用意される。有限オートマトンＡ１に対する入力は、当該有限オートマトンＡ１に対応するＡＰＰデータＩＤを含む学習開始トリガ、又は当該ＡＰＰデータＩＤに対応する異常検知モデルに関するモデル学習部１６による学習結果である。すなわち、異常検知モデルもＡＰＰデータＩＤ別（すなわち、トピック別）に学習される。
　有限オートマトンＡ１は、停止状態、学習状態及びランタイム状態の３つの状態を有する。
　停止状態は、異常検知モデルの学習及び学習済みの異常検知モデルを用いた異常の検知のいずれをも停止させる状態である。停止状態において、学習開始トリガが入力されると、有限オートマトンＡ１は、当該学習開始トリガの入力からＸ秒経過後（すなわち、通信ＱｏＳ情報が変化してからＸ秒経過後）に学習状態へ遷移する。Ｘは、モデル管理部１４に対する設定値として予め与えられる。
　学習状態において、モデル管理部１４は、学習状態への遷移の契機となった学習開始トリガに含まれるＡＰＰデータＩＤに対応する異常検知モデルの学習をモデル学習部１６に実行させる。学習においては、データ記憶部１２２に記憶されている、当該有限オートマトンＡ１に係るＡＰＰデータＩＤに対応する学習補助付きデータ群がのうち、停止状態の最後のＸ秒間においてデータ記憶部１２２に蓄積された学習補助付きデータ群が正常データ群とされ、当該Ｘ秒間より前にデータ記憶部１２２に蓄積された学習補助付きデータ群が異常データ群とされる。したがって、当該ＡＰＰデータＩＤに対応する学習開始トリガが初めて入力された場合、異常データ群は無い。
　学習状態においては、モデル学習部１６による学習が終了するたびに学習結果（例えば、正答率）が有限オートマトンＡ１に入力される。正答率の詳細については後述される。正答率がＹ％未満である場合には、モデル管理部１４は、学習を繰り返させる。この場合、異常検知モデルに対して変更が行われる。正答率がＹ％以上である学習結果が得られると、有限オートマトンＡ１は、ランタイム状態へ遷移する。なお、Ｙは、モデル管理部１４に対する設定値として予め与えられる。
　ランタイム状態において、モデル管理部１４は、モデル学習部１６に対して、異常検知実行部１７への異常検知モデルの適用を指示すると共に、異常検知実行部１７に対して、当該異常検知モデルを用いた異常検知の開始を指示する。ランタイム状態において、当該有限オートマトンＡ１に対して新たな学習開始トリガが入力されると（すなわち、通信ＱｏＳ情報が変化すると）、当該有限オートマトンＡ１は、停止状態へ遷移する。
　図１６は、有限オートマトンの各状態におけるモデル管理部１４からの出力を説明するための図である。なお、モデル管理部１４からの各出力は、有限オートマトンＡ１に対する入力のたびに行われる。
　学習状態において、モデル管理部１４は、学習開始指示をモデル学習部１６へ出力する。学習開始指示は、ＡＰＰデータＩＤ、ＱｏＳ識別子及び学習回数等を含む。ＡＰＰデータＩＤ及びＱｏＳ識別子は、学習開始トリガに含まれていた値がそのまま利用される。学習回数は、ＡＰＰデータＩＤ別の学習回数である。学習開始指示が出力されるたびに、学習回数には１が加算される。
　ランタイム状態において、モデル管理部１４は、モデル学習部１６に対して異常検知実行部１７への学習済みの異常検知モデルの適用指示を入力するとともに、異常検知実行部１７に対して動作指示を入力する。その結果、異常検知実行部１７は、当該異常検知モデルを用いて異常検知を開始する。なお、動作指示には、学習開始トリガに含まれていたＡＰＰデータＩＤが含まれる。
　なお、モデル管理部１４は、有限オートマトンＡ１の状態が遷移するたびに、遷移後の状態と当該有限オートマトンＡ１に対応するＡＰＰデータＩＤとをデータ転送部１５へ通知する。
　［データ転送部１５］
　図１７は、データ転送部１５が実行する処理手順の一例を説明するためのフローチャートである。データ転送部１５は、モデル管理部１４からの状態（遷移後の状態）の通知、又はデータ記憶部１２２への新たな学習補助付きデータの記録に応じて、図１７の処理手順を実行する。
　モデル管理部１４から状態が通知された場合（Ｓ２０１でＹｅｓ）、データ転送部１５は、当該状態と共に通知されたＡＰＰデータＩＤに関連付けて、当該状態をメモリ装置１０３等に記憶する（Ｓ２０２）。データ転送部１５は、ＡＰＰデータＩＤ別に、少なくとも直近の過去２回分の状態を記憶する。
　一方、データ記憶部１２２に対して新たな学習補助付きデータ（以下、「対象学習補助付きデータ」という。）が記録された場合（Ｓ２０３でＹｅｓ）、データ転送部１５は、対象学習補助付きデータに含まれるパース済みパケットのＡＰＰデータＩＤ（以下、「対象ＡＰＰデータＩＤ」という。）に対応する有限オートマトンＡ１（以下、「対象有限オートマトンＡ１」という。）の最新の状態がいずれであるかに基づいて処理を分岐させる。当該最新の状態は、ステップＳ２０２において記憶される状態の履歴に基づいて特定可能である。
　最新の状態が学習状態である場合（Ｓ２０４でＹｅｓ）、データ転送部１５は、対象ＡＰＰデータＩＤに係る前回の学習補助付きデータの記録時の対象有限オートマトンＡ１の状態が停止状態であったか否かを判定する（Ｓ２０５）。前回の状態についても、ステップＳ２０２において記憶される状態の履歴に基づいて特定可能である。前回の状態が停止状態でない場合（Ｓ２０５でＮｏ）、データ転送部１５は、対象学習補助付きデータに関する処理を終了させる。
　一方、前回の状態が停止状態である場合（Ｓ２０５でＹｅｓ）、データ転送部１５は、対象学習補助付きデータに含まれるパース済みパケットのパケット番号を学習用最終パケット番号として対象ＡＰＰデータＩＤに対応付けてメモリ装置１０３に記憶する（Ｓ２０６）。パケット番号とは、例えば、パケット情報に含まれる受信時番号である（図７参照）。受信時番号は、例えば、パース部１２によって、パース済みパケットに対して昇順に付与される番号である。したがって、受信時番号（パケット番号）によって、各パース済みパケットの受信順序を識別することができる。
　続いて、データ転送部１５は、対象ＡＰＰデータＩＤに関してデータ記憶部１２２に記憶されている学習補助付きデータのうち、学習開始トリガとなるパケット番号から学習用最終パケット番号までの学習補助付きデータ群の中で、学習開始トリガに含まれる通信ＱｏＳ情報と同じ通信ＱｏＳ情報を含む学習補助付きデータを正常データとし、学習開始トリガとなるパケット番号より前の学習補助付きデータ群（すなわち、最新の通信ＱｏＳ情報と異なる通信ＱｏＳ情報に係る学習補助付きデータ群）を異常データとしてモデル学習部１６へ送信する（Ｓ２０７）。なお、学習開始トリガとなるパケット番号とは、対象ＡＰＰデータＩＤに係る学習補助付きデータのうち、ＱｏＳ仕様変更フラグが付与された学習補助データを含む学習補助付きデータの中で最新の学習補助付きデータに係るパケットのパケット番号をいう。
　最新の状態がランタイム状態である場合（Ｓ２０８でＹｅｓ）、データ転送部１５は、前回の対象ＡＰＰデータＩＤに係る学習補助付きデータの記録時の対象有限オートマトンＡ１の状態が学習状態であったか否かを判定する（Ｓ２０９）。前回の状態が学習状態でない場合（Ｓ２０９でＮｏ）、データ転送部１５は、対象学習補助付きデータに関する処理を終了させる。
　前回の状態が学習状態である場合（Ｓ２０９でＹｅｓ）、データ転送部１５は、対象ＡＰＰデータＩＤに関してデータ記憶部１２２に記憶されている学習補助付きデータのうち、対象ＡＰＰデータＩＤに係る学習用最終パケット番号に係る学習補助付きデータから対象学習補助付きデータまでの学習補助付きデータ群を異常検知実行部１７へ転送する。転送対象の学習補助付きデータを学習用最終パケット番号まで遡ることで、モデル学習部１６で学習された異常検知モデルについて、異常検知実行部１７への適用までの期間においてネットワークＮ１に流れたパケットを遡って異常検知の対象とすることができる。
　一方、前回の状態が学習状態でない場合、すなわち、ランタイム状態が継続している場合（Ｓ２０９でＮｏ）、データ転送部１５は、対象学習補助付きデータを異常検知実行部１７へ転送する（Ｓ２１１）。すなわち、ランタイム状態が継続している間は、受信パケットに対応する学習補助付きデータがリアルタムに異常検知実行部１７へ転送される。その結果、異常検知実行部１７においてリアルタムに異常検知が行われる。
　［モデル学習部１６］
　モデル学習部１６は、学習開始指示に応じ、当該学習開始指示に含まれているＡＰＰデータＩＤに対応する異常検知モデルの学習を行う。この際、データ転送部１５から転送される学習補助付きデータ群が学習データとして利用される。データ転送部１５から転送される学習データに正常データのみが含まれている場合、教師なし学習が実行される。この場合、モデル学習部１６は、異常検知モデルから学習データごとに出力される、正常データである確率の集合を学習結果として有限オートマトンＡ１へ入力する。有限オートマトンＡ１は、全ての確率がＹ以上である場合に状態を遷移させる。一方、データ転送部１５から転送される学習データに正常データ及び異常データの双方が含まれている場合、教師あり学習が実行される。この場合、モデル学習部１６は、学習データ群に対する、正常であるか異常であるかについての正答の割合（正答率）を学習結果として有限オートマトンＡ１へ入力する。有限オートマトンＡ１は、当該正答率がＹ以上である場合に状態を遷移させる。
　なお、１つのＡＰＰデータＩＤに対して複数の異常検知モデルが用意されてもよい。当該複数の異常検知モデルは、相互にモデル構成（層数やノード数）等が異なるニューラルネットワークでもよいし、モデル構成は共通でハイパーパラメータが異なるニューラルネットワークでもよい。また、各異常検知モデルにおいて学習補助データの扱いが異なってもよい。すなわち、学習補助データを学習にどのように利用するのかについては異常検知モデルに依存する。例えば、学習補助データのうち、周期保証系のパラメータであれば、分割した間隔内（当該間隔×Ｎ（Ｎ＝１、２、１／２、又はその他の値）、の統計情報（パケット数やＡＰＰデータの統計情報等）が、異常検知のための特徴量として用いられてもよい。学習補助データのうち、耐障害保証系のパラメータであれば、ＰｒｉｍａｌｙとＳｅｃｏｎｄａｒｙ通信量差分が、異常検知のための特徴量として用いられてもよい。学習補助データのうち、順序保証系のパラメータであれば、許容されるシーケンス番号の最大値が、異常検知のための特徴量として用いられてもよい。なお、周期保証系、耐障害保証系のＱｏＳ保証項目は、
・設定変更によりＡＰＰ用データパケットとＱｏＳ保証用パケットの挙動が大きく変わる。
・アプリケーションに大きな影響を出さず切り替えることが可能である。
という二つの特徴を持つため、異常データを生成することが容易であると共に、検知精度向上を期待することができる。
　また、１回の学習開始指示に応じて、複数の異常検知モデルの学習が並列的に実行されてもよいし、直列的に１つの異常検知モデルが順次実行されてもよい。前者の場合、学習結果として有限オートマトンＡ１に入力される正答率は、複数の異常検知モデルの中で、最も高い正答率であってもよい。後者の場合、モデル学習部１６は、学習開始指示に含まれている学習回数に応じて、学習する異常検知モデルを識別してもよい。
　モデル学習部１６は、また、モデル管理部１４からの適用指示に応じ、学習状態において学習された異常検知モデルの中で、最も正答率が高い異常検知モデルを異常検知実行部１７へ適用する。
　なお、モデル学習部１６は、例えば、学習結果が過去最高である異常検知モデルを、学習開始指示に含まれているＱｏＳ識別子に関連付けて保存しておいてもよい。そうすることで、当該ＱｏＳ識別子と同一のＱｏＳ識別子を含む学習開始指示が入力された場合、モデル学習部１６は、当該ＱｏＳ識別子に対応する異常検知モデルを用いて迅速に学習を収束させてもよい。
　［異常検知実行部１７］
　異常検知実行部１７は、ランタイム状態においてデータ転送部１５から転送される学習補助付きデータを、異常検知実行部１７に対して適用された異常検知モデルに入力して、ネットワークＮ１におけるＰｕｂ／Ｓｕｂ通信について異常の検知を実行する。
　［結果出力部１８］
　結果出力部１８は、異常検知実行部１７による異常の検知結果を出力する。
　上述したように、本実施の形態によれば、通信ＱｏＳ情報パケットに含まれるＱｏＳ保証項目の値に基づいて学習データが生成されて、機械学習が実行されるため、自動的に異常検知アルゴリズムを生成することができる。したがって、通信の異常の検知の効率化を支援することができる。
　また、通信設定の変更に応じた通信ＱｏＳ情報の変更をトリガとして異常検知モデルの再学習を行うことにより、新たな通信ＱｏＳ情報に合わせて自動的に異常検知アルゴリズム（異常検知処理）を変更（最適化）することができる。すなわち、通信の異常の検知について、「通信設定の変更」と「異常検知処理の最適化支援」を自動で制御することにより効率化できる。
　なお、本実施の形態において、通信ＱｏＳ情報解析部１３は、解析部の一例である。モデル学習部１６は、学習部の一例である。異常検知実行部１７は、実行部の一例である。学習補助データは、補助情報の一例である。
　以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
１０　　　　　異常検知支援装置
１１　　　　　キャプチャ部
１２　　　　　パース部
１３　　　　　通信ＱｏＳ情報解析部
１４　　　　　モデル管理部
１５　　　　　データ転送部
１６　　　　　モデル学習部
１７　　　　　異常検知実行部
１８　　　　　結果出力部
１２１　　　　通信ＱｏＳ情報記憶部
１２２　　　　データ記憶部
２０　　　　　Ｐｕｂ装置
３０　　　　　Ｓｕｂ装置
１００　　　　ドライブ装置
１０１　　　　記録媒体
１０２　　　　補助記憶装置
１０３　　　　メモリ装置
１０４　　　　プロセッサ
１０５　　　　インタフェース装置
Ｂ　　　　　　バス
Ａ１　　　　　有限オートマトン
Ｎ１　　　　　ネットワーク

Claims (6)

  1. 　Ｐｕｂ／Ｓｕｂ通信に関する異常検知モデルが前記Ｐｕｂ／Ｓｕｂ通信の品質を示すパケットに含まれる値から特徴量を抽出するための補助情報を、前記品質を示すパケットに基づいて生成する解析部と、
    　前記Ｐｕｂ／Ｓｕｂ通信における各パケットに対して前記補助情報が付与されたデータ群を用いた学習を、前記異常検知モデルに実行させる学習部と、
    を有することを特徴とする異常検知支援装置。
  2. 　前記解析部は、前記品質を示すパケット群に基づいて、前記品質が変化したことを検知し、
    　前記学習部は、前記品質が変化する前のパケットに係る前記データ群を異常データとし、前記品質が変化した後のパケットに係る前記データ群を正常データとして、前記異常検知モデルに前記学習を実行させる、
    ことを特徴とする請求項１記載の異常検知支援装置。
  3. 　前記学習部は、前記解析部によって前記品質の変化が検知されるたびに、前記異常検知モデルを再学習させる、
    ことを特徴とする請求項２記載の異常検知支援装置。
  4. 　学習済みの前記異常検知モデルを用いて、前記Ｐｕｂ／Ｓｕｂ通信について異常検知を実行する実行部、
    を有することを特徴とする請求項１乃至３いずれか一項記載の異常検知支援装置。
  5. 　Ｐｕｂ／Ｓｕｂ通信に関する異常検知モデルが前記Ｐｕｂ／Ｓｕｂ通信の品質を示すパケットに含まれる値から特徴量を抽出するための補助情報を、前記品質を示すパケットに基づいて生成する解析手順と、
    　前記Ｐｕｂ／Ｓｕｂ通信における各パケットに対して前記補助情報が付与されたデータ群を用いた学習を、前記異常検知モデルに実行させる学習手順と、
    をコンピュータが実行することを特徴とする異常検知支援方法。
  6. 　請求項１乃至４いずれか一項記載の異常検知支援装置としてコンピュータを機能させることを特徴とするプログラム。
PCT/JP2020/045031 2020-12-03 2020-12-03 異常検知支援装置、異常検知支援方法及びプログラム WO2022118427A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/045031 WO2022118427A1 (ja) 2020-12-03 2020-12-03 異常検知支援装置、異常検知支援方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/045031 WO2022118427A1 (ja) 2020-12-03 2020-12-03 異常検知支援装置、異常検知支援方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2022118427A1 true WO2022118427A1 (ja) 2022-06-09

Family

ID=81853084

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/045031 WO2022118427A1 (ja) 2020-12-03 2020-12-03 異常検知支援装置、異常検知支援方法及びプログラム

Country Status (1)

Country Link
WO (1) WO2022118427A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4407955A1 (de) * 2023-01-24 2024-07-31 Siemens Aktiengesellschaft Verfahren zum betreiben von datenzentrischen applikationen in einem gerätenetzwerk und gerätenetzwerk

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017120497A (ja) * 2015-12-28 2017-07-06 川崎重工業株式会社 航空機搭載システム
JP2019153894A (ja) * 2018-03-01 2019-09-12 日本電信電話株式会社 通信制御装置、通信制御方法および通信制御プログラム
WO2019225710A1 (ja) * 2018-05-25 2019-11-28 日本電信電話株式会社 特定装置、特定方法及び特定プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017120497A (ja) * 2015-12-28 2017-07-06 川崎重工業株式会社 航空機搭載システム
JP2019153894A (ja) * 2018-03-01 2019-09-12 日本電信電話株式会社 通信制御装置、通信制御方法および通信制御プログラム
WO2019225710A1 (ja) * 2018-05-25 2019-11-28 日本電信電話株式会社 特定装置、特定方法及び特定プログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4407955A1 (de) * 2023-01-24 2024-07-31 Siemens Aktiengesellschaft Verfahren zum betreiben von datenzentrischen applikationen in einem gerätenetzwerk und gerätenetzwerk
WO2024156537A1 (de) * 2023-01-24 2024-08-02 Siemens Aktiengesellschaft Verfahren zum betreiben von datenzentrischen applikationen in einem gerätenetzwerk und gerätenetzwerk

Similar Documents

Publication Publication Date Title
CN112313916B (zh) 一种融合区块链技术拟态存储防篡改日志的方法及系统
CN110262972B (zh) 一种面向微服务应用的失效测试工具及方法
Lou et al. Mining dependency in distributed systems through unstructured logs analysis
US6792456B1 (en) Systems and methods for authoring and executing operational policies that use event rates
US20170075746A1 (en) Information processing device and monitoring method
JP2011091464A (ja) ネットワーク構成の想定のための装置、システム
KR102325258B1 (ko) 원격통신 네트워크의 네트워크 성능에 관한 자율적 또는 ai-보조적 유효성 검증 또는 결정 수행을 행하고 그리고/또는 원격통신 네트워크 내에서 자율적 또는 ai-보조적 장애해결 또는 성능 증진을 행하기 위한 방법, 원격통신 네트워크, 시스템, 머신 지능 엔티티, 시각화 인터페이스, 컴퓨터 프로그램 그리고 컴퓨터-판독가능 매체
CN114363042B (zh) 日志分析方法、装置、设备及可读存储介质
CN107168844B (zh) 一种性能监控的方法及装置
JP5198154B2 (ja) 障害監視システム及びデバイスと監視装置並びに障害監視方法
Chen et al. Automatic root cause analysis via large language models for cloud incidents
US20140201762A1 (en) Event handling system and method
Inçki et al. Runtime verification of IoT systems using complex event processing
CN113572726A (zh) 一种多模态网络控制-数据平面一致性校验方法及装置
WO2022118427A1 (ja) 異常検知支援装置、異常検知支援方法及びプログラム
CN113434323A (zh) 数据中台的任务流控制方法及相关装置
US11349730B2 (en) Operation device and operation method
Vizarreta et al. Dason: Dependability assessment framework for imperfect distributed sdn implementations
CN111913824A (zh) 确定数据链路故障原因的方法及相关设备
JP2010128597A (ja) 情報処理装置及び情報処理装置の運用方法
CN113672452A (zh) 一种数据采集任务的运行监控方法、系统
CN111338609B (zh) 信息获取方法、装置、存储介质及终端
Han et al. A service-oriented approach to modeling and reusing event correlations
CN114422386B (zh) 一种微服务网关的监测方法及装置
Hill et al. Unit testing non-functional concerns of component-based distributed systems

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20964280

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP