WO2020170345A1 - 履歴出力装置、制御方法、及びプログラム - Google Patents

履歴出力装置、制御方法、及びプログラム Download PDF

Info

Publication number
WO2020170345A1
WO2020170345A1 PCT/JP2019/006226 JP2019006226W WO2020170345A1 WO 2020170345 A1 WO2020170345 A1 WO 2020170345A1 JP 2019006226 W JP2019006226 W JP 2019006226W WO 2020170345 A1 WO2020170345 A1 WO 2020170345A1
Authority
WO
WIPO (PCT)
Prior art keywords
abnormal event
terminal
output
history
type
Prior art date
Application number
PCT/JP2019/006226
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 US17/431,508 priority Critical patent/US20220012345A1/en
Priority to PCT/JP2019/006226 priority patent/WO2020170345A1/ja
Priority to JP2021501189A priority patent/JP7211482B2/ja
Publication of WO2020170345A1 publication Critical patent/WO2020170345A1/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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • 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
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/034—Test or assess a computer or a system

Definitions

  • the present invention relates to a technique for managing information about an abnormality that has occurred in a system.
  • Patent Document 1 A technology has been developed to output information about abnormal events that have occurred in the system. For example, in Patent Document 1, among the commands executed by the system, those which affect the state of the system are recorded, and when an abnormality is detected in the system, the command executed within a predetermined time before the abnormality occurs. The technology for outputting is disclosed.
  • the present invention has been made in view of the above problems, and one of the purposes thereof is to provide a technique that facilitates handling of information regarding an abnormal event.
  • an acquisition unit that acquires an abnormal event history that represents an abnormal event that has occurred in a terminal, and 2) the type of abnormal event that the acquired abnormal event history represents is a predetermined type. And a type determining unit that determines whether or not the abnormal event is a predetermined type, and a terminal that has generated the abnormal event and other terminals that have communicated with the terminal before the abnormal event occurs.
  • a terminal specifying unit that specifies a terminal as an output target terminal and 4) an abnormal event represented by the acquired abnormal event history has occurred in the output target terminal, output that outputs output information related to the abnormal event And a section.
  • an acquisition unit that acquires an abnormal event history that represents an abnormal event that has occurred in a terminal, and 2) the type of abnormal event that the acquired abnormal event history represents is a predetermined type.
  • a type determining unit that determines whether or not 3), if the type of the abnormal event is a predetermined type, a terminal identifying unit that identifies the terminal in which the abnormal event has occurred as an output target terminal;
  • the output unit outputs the output information related to the abnormal event.
  • the output unit further outputs the output information regarding the abnormal event that occurred at the terminal before the specification.
  • the first control method of the present invention is executed by a computer.
  • the control method includes 1) an acquisition step of acquiring an abnormal event history representing an abnormal event that has occurred in a terminal, and 2) determining whether or not the type of abnormal event represented by the acquired abnormal event history is a predetermined type.
  • Type determination step and 3) if the type of the abnormal event is a predetermined type, output the terminal in which the abnormal event has occurred and the other terminals that have communicated with the terminal before the time when the abnormal event occurs. It has a terminal specifying step of specifying as a terminal and 4) an output step of outputting output information related to the abnormal event when the abnormal event represented by the acquired abnormal event history has occurred in the output target terminal.
  • the second control method of the present invention is executed by a computer.
  • the control method includes 1) an acquisition step of acquiring an abnormal event history representing an abnormal event that has occurred in a terminal, and 2) determining whether or not the type of abnormal event represented by the acquired abnormal event history is a predetermined type.
  • a type determining step 3) a terminal identifying step of identifying a terminal in which the abnormal event has occurred as an output target terminal when the type of the abnormal event is a predetermined type, and 4) an abnormality represented by the acquired abnormal event history
  • the output step When the event has occurred at the output target terminal, the output step of outputting the output information related to the abnormal event.
  • the output step when a certain terminal is specified as the output target terminal, output information regarding an abnormal event that occurred in the terminal before the specification is further output.
  • the first program of the present invention causes a computer to execute each step of the first control method of the present invention.
  • the second program of the present invention causes a computer to execute each step of the second control method of the present invention.
  • FIG. 1 It is a figure which illustrates the outline of operation
  • FIG. 9 is a flowchart illustrating the flow of processing executed by the history output device according to the second embodiment. It is a figure which illustrates the case where the period of an output subject changes according to types, such as a command. It is a figure which illustrates the case where a predetermined period is extended.
  • each block diagram represents a functional unit configuration, not a hardware unit configuration, unless otherwise specified.
  • FIG. 1 is a diagram illustrating an overview of the operation of the history output device 2000 of this embodiment.
  • FIG. 1 is a diagram showing a conceptual explanation for facilitating understanding of the operation of the history output device 2000, and does not specifically limit the operation of the history output device 2000.
  • the history output device 2000 acquires an abnormal event history 10 that is information indicating an abnormal event that has occurred in the target computer system (target system 100).
  • Abnormal events are 1) events that do not occur if the program is normal, and 2) events that do not occur if the program is used normally.
  • the abnormal event applicable to 1) is, for example, an event indicating that a file is not accessed when a certain program is in a normal state, or a communication partner that is not communicated when a certain program is in a normal state is communicated with.
  • the abnormal event applicable to 2) is, for example, an event that occurs as a result of the user of the program using the program contrary to the usage method when the correct usage method of the program is defined.
  • a correct usage method of the ping command a usage method of “sending a ping command to a specific machine (for example, server machine) and confirming that the machine is operating” is defined.
  • a specific machine for example, server machine
  • the event (event indicating communication with a machine other than a specific machine) that occurs due to this is against the correct usage of the ping command described above, so it is treated as an abnormal event.
  • the target system 100 is composed of one or more arbitrary terminals 110.
  • the terminal 110 may be a physical machine or a virtual machine.
  • the physical machine may be a stationary machine such as a PC (Personal Computer) or a portable machine such as a smartphone.
  • the event represents, for example, an activity (such as access to a file or another process) performed by a process running on a machine included in the target system.
  • the history output device 2000 controls the output (for example, display on a display device) of the abnormal event history 10 based on the type of abnormal event that has occurred in the target system 100.
  • the first-type abnormal event is, for example, an abnormal event having a high probability of representing a serious abnormality. More specifically, for example, the first type abnormal event is an event caused by the execution of a command or program whose safety is not ensured.
  • command or program is also referred to as "command, etc.”
  • the history output device 2000 After acquiring the abnormal event history 10, the history output device 2000 specifies the type of abnormal event represented by the abnormal event history 10.
  • the type of the identified abnormal event is the first type
  • the history output device 2000 identifies the terminal 110 in which the abnormal event has occurred as the output target terminal. Further, the history output device 2000 also identifies, as an output target terminal, another terminal 110 that was communicating with the terminal 110 in which the abnormal event occurred before the time when the abnormal event occurred.
  • the history output device 2000 outputs information about the abnormal event (hereinafter, output information).
  • the history output device 2000 of the information on the abnormal events that have occurred in the terminal 110, the information on the abnormal events that do not belong to the first type is not output until the first type abnormal event is detected. Therefore, for example, by treating an abnormal event having a high probability of representing a serious abnormality as a type 1 event, information regarding an abnormal event having a low probability of representing a serious abnormality to a certain extent is an abnormal event having a high probability of representing a serious abnormality. Will not be output until.
  • information about an abnormal event with a low probability of representing a serious abnormality is also output.
  • information about abnormal events with a low probability to indicate a serious abnormality is not output unconditionally, but is output with the occurrence of an abnormal event with a high probability to indicate a serious abnormality.
  • the output information is appropriately narrowed down, so that the information about the abnormal event can be handled easily. Therefore, it is difficult to overlook a serious abnormality (that is, the analysis accuracy is improved), the work load on the analyst who analyzes the abnormal event is reduced, and the time required for the analysis work is reduced. ..
  • an abnormal event caused by the execution of a command whose safety is not assured is treated as a type 1 abnormal event.
  • the information regarding the abnormal event whose safety is ensured is output together with the occurrence of the abnormal event whose safety is not ensured.
  • the information on the abnormal event for which safety is ensured is appropriately narrowed down and output, so that the information on the abnormal event can be handled easily.
  • the OS standard command here is a command provided by a predetermined program (for example, a shell program) that is also installed when the OS is installed.
  • a predetermined program for example, a shell program
  • the malware installed in the terminal 110 uses a standard command provided by the OS running on the terminal 110 to perform various activities (search activity, spread of infection, etc.).
  • search activity search activity, spread of infection, etc.
  • an abnormal event having a high probability of representing a cyber attack is treated as a first-type abnormal event.
  • an event such as "the document creation software reads the password file” is treated as a first type abnormal event.
  • the abnormal event caused by the execution of the standard command is considered to have a low probability of representing a cyber attack, and is therefore not treated as the first-type abnormal event.
  • the abnormal event caused by the execution of the standard command only the abnormal event that is highly likely to represent a cyber attack is output. Therefore, the information on the abnormal event related to the cyber attack is appropriately narrowed down and output, so that the information related to the cyber attack is easily handled. Therefore, there are effects that the accuracy of the analysis regarding the cyber attack is improved, the workload of the analyst who analyzes the cyber attack is reduced, and the time required for the cyber attack analysis work is reduced.
  • FIG. 2 is a diagram illustrating a configuration of the history output device 2000 according to the first embodiment.
  • the history output device 2000 has an acquisition unit 2020, a type determination unit 2040, a terminal identification unit 2060, and an output unit 2080.
  • the acquisition unit 2020 acquires the abnormal event history 10.
  • the type determination unit 2040 determines whether or not the type of abnormal event represented by the acquired abnormal event history 10 is a predetermined type (first type).
  • the terminal identifying unit 2060 determines whether the terminal 110 in which the abnormal event has occurred and other terminals 110 that have communicated with the terminal 110 before the time when the abnormal event occurs.
  • the terminal 110 is specified as the output target terminal.
  • the output unit 2080 outputs output information regarding the abnormal event.
  • Each functional component of the history output device 2000 may be implemented by hardware that implements each functional component (eg, hard-wired electronic circuit, etc.), or a combination of hardware and software (eg: Combination of an electronic circuit and a program for controlling the electronic circuit).
  • each functional component of the history output device 2000 is realized by a combination of hardware and software will be further described.
  • FIG. 3 is a diagram exemplifying a computer 1000 for realizing the history output device 2000.
  • the computer 1000 is an arbitrary computer.
  • the computer 1000 is a personal computer (PC), a server machine, a tablet terminal, a smartphone, or the like.
  • the computer 1000 may be a dedicated computer designed to realize the history output device 2000 or a general-purpose computer.
  • the computer 1000 has a bus 1020, a processor 1040, a memory 1060, a storage device 1080, an input/output interface 1100, and a network interface 1120.
  • the bus 1020 is a data transmission path for the processor 1040, the memory 1060, the storage device 1080, the input/output interface 1100, and the network interface 1120 to mutually transmit and receive data.
  • the processor 1040 is a processor such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or an FPGA (Field-Programmable Gate Array).
  • the memory 1060 is a main storage device realized by using a RAM (Random Access Memory) or the like.
  • the storage device 1080 is an auxiliary storage device realized by using a hard disk drive, SSD (Solid State Drive), memory card, ROM (Read Only Memory), or the like. However, the storage device 1080 may be configured with the same hardware as the hardware configuring the main storage device, such as RAM.
  • the input/output interface 1100 is an interface for connecting the computer 1000 and an input/output device.
  • the network interface 1120 is an interface for connecting the computer 1000 to a communication network.
  • This communication network is, for example, LAN (Local Area Network) or WAN (Wide Area Network).
  • the method of connecting the network interface 1120 to the communication network may be wireless connection or wired connection.
  • the storage device 1080 stores a program module that realizes the functional configuration unit of the history output device 2000.
  • the processor 1040 reads the program modules into the memory 1060 and executes the program modules to implement the functions corresponding to the program modules.
  • FIG. 4 is a diagram illustrating a usage environment of the history output device 2000 according to the first embodiment.
  • the target system 100 includes a plurality of terminals 110.
  • Various commands are executed on the terminal 110.
  • a history of events representing the operation of a process generated by executing a command or the like is recorded. This history is called event history 20.
  • the event history 20 is collected by the abnormality detection device 120.
  • the collection of the event history 20 is realized, for example, by the terminal 110 transmitting the event history 20 to the abnormality detection device 120 regularly or in real time.
  • the abnormality detection device 120 determines whether or not the event represented by the event history 20 is an abnormal event. If the event represented by the event history 20 is an abnormal event, the event history 20 is treated as the abnormal event history 10.
  • a model that defines a normal event that occurs in the target system 100 (in the terminal 110 included in the target system 100) is generated in advance.
  • the abnormality detection device 120 determines whether the event shown in each event history 20 deviates from the model.
  • the abnormality detection device 120 detects an event deviating from the model as an abnormal event.
  • Existing techniques can be used for the technique of generating a normal event model and the technique of detecting an event deviating from the normal event model as an abnormal event.
  • the history output device 2000 acquires the abnormal event history 10 and processes the acquired abnormal event history 10.
  • the history output device 2000 acquires the abnormal event history 10 from the event history 20.
  • the abnormality detection device 120 adds a flag indicating whether or not it is the abnormal event history 10 to the event history 20 and stores it in the storage device.
  • the acquisition unit 2020 acquires the event history 20 stored in this storage device, which is associated with the flag indicating the abnormal event history 10.
  • the abnormality detection device 120 may output (for example, transmit) the abnormality event history 10 to the acquisition unit 2020.
  • the acquisition unit 2020 acquires the abnormal event history 10 output by the abnormality detection device 120.
  • the abnormality detection device 120 may be provided separately from the history output device 2000 or may be provided in the history output device 2000. In the latter case, the history output device 2000 collects the event history 20 and determines whether or not each event history 20 represents an abnormal event. Then, the history output device 2000 treats the event history 20 representing the abnormal event as the abnormal event history 10. In FIG. 4, the abnormality detection device 120 and the history output device 2000 are separately provided.
  • FIG. 5 is a flowchart illustrating the flow of processing executed by the history output device 2000 according to the first embodiment.
  • the acquisition unit 2020 acquires the abnormal event history 10 (S102).
  • the type determination unit 2040 determines whether or not the type of abnormal event represented by the acquired abnormal event history 10 is the first type (S104). When the type of abnormal event is not the first type (S104: NO), the process of FIG. 5 proceeds to S110.
  • the terminal identifying unit 2060 was communicating with the terminal 110 in which the abnormal event occurred and the terminal 110 before the time when the abnormal event occurred.
  • the other terminal 110 is specified as the output target terminal (S106).
  • the output unit 2080 When the abnormal event represented by the acquired abnormal event history 10 has occurred in the output target terminal, the output unit 2080 outputs output information about the abnormal event (S108).
  • the type of the abnormal event indicated by the abnormal event history 10 is the first type (S104: YES)
  • the abnormal event always occurs in the output target terminal, and therefore the output unit 2080 outputs the abnormal event.
  • Information is output (S108).
  • the output unit 2080 determines whether or not the abnormal event has occurred in the output target terminal ( S110). When the abnormal event has occurred in the output target terminal (S110: YES), the output unit 2080 outputs the output information about the abnormal event (S108). On the other hand, when the abnormal event does not occur in the output target terminal (S110: NO), the output unit 2080 does not output the output information about the abnormal event.
  • the history output device 2000 acquires a plurality of abnormal event histories 10 and performs a series of processes shown in FIG. 5 in order from the abnormal event history 10 with the earliest occurrence time of the abnormal event. Therefore, after a certain terminal 110 is specified as the output target terminal, the output unit 2080 outputs each abnormal event history 10 representing the abnormal event that has occurred at the terminal 110.
  • the history output device 2000 may not treat that terminal 110 as an output target terminal based on a predetermined condition. For example, after a certain terminal 110 is specified as the output target terminal, if the first type abnormal event does not occur in the terminal 110 for a predetermined time or longer, the terminal 110 is not treated as the output target terminal.
  • the history output device 2000 may receive an input operation from the user for selecting a terminal 110 that is not treated as an output target terminal from the terminals 110 that are treated as output target terminals. For example, as a result of the administrator of the target system 100 browsing and analyzing the abnormal event history 10 output for a certain terminal 110, there is no problem for that terminal 110 (the abnormal event history 10 may not be output). Suppose you have decided. In this case, the administrator performs an input operation to exclude the terminal 110, which is determined to have no problem, from the output target terminals.
  • the event history 20 is information about an event that occurred in the target system 100 (at the terminal 110 included in the target system 100) at a certain point in the past.
  • the event history 20 shows the identification information of the terminal 110 in which the event has occurred, the time when the event occurred, and the content of the event in association with each other.
  • the event history 20 represents a history of activity of processes operating in the target system 100.
  • the activity of a process is recorded for each system call.
  • these processes may run on the same OS (Operating System) or may run on different OSs. Good.
  • one process may communicate with another process running on another OS.
  • the event history 20 shows information about one or more items.
  • an event is identified by information indicating five elements: identification information of the terminal 110 in which the event has occurred, the event subject, the object of the event, the activity content, and the time of occurrence. Therefore, for example, the event history 20 is roughly divided into five items: identification information of the terminal 110, subject information indicating a subject, object information indicating an object, content information indicating the content of activity, and an occurrence time.
  • the identification information of the terminal 110 is arbitrary information that can identify the terminal 110.
  • the network address (IP address or MAC address) or UUID (Universally Unique Identifier) of the terminal 110 can be used as the identification information of the terminal 110.
  • the subject information is, for example, the type and identification information of the subject.
  • the type of subject is, for example, a process or a socket.
  • the subject information includes information that identifies the process.
  • information for identifying a process will be referred to as process identification information.
  • the process identification information includes a process ID (Identifier).
  • the process identification information regarding the process in which the plurality of threads operate includes the thread ID in addition to the process ID.
  • the process identification information further includes information about the process execution file.
  • the information on the execution file of the process is, for example, the name or path of the execution file, the hash value of the execution file, the digital signature of the execution file, or the name of the application realized by the execution file.
  • the subject information includes the identifier assigned to the socket.
  • the object information is, for example, the type and identification information of the object.
  • the type of object is, for example, a process, a file, or a socket.
  • the object information includes process identification information of the process.
  • the object information When the object is a file, the object information includes information that identifies the file (hereinafter, file identification information).
  • file identification information is, for example, a file name or path.
  • the object information includes the hash value of the file, the combination of the file system identifier and the disk block identifier (inode number or object ID) that constitutes the file on the file system. May be included.
  • the object information includes the identifier assigned to the socket.
  • Content information is, for example, identification information assigned to various activity contents. For example, “execute specified command”, “start process”, “stop process”, “open file”, “read data from file”, “write data to file”, “ Different identifiers are assigned to the contents of activities such as “opening a socket”, “reading data from a socket”, “writing data to a socket”, and “sending data from a socket”.
  • the access to the socket means access to another device associated with the socket.
  • the identification information of the command to be executed is also included in the content information.
  • the content information is shown as “activity content identification information: command execution, command identification information: ls”.
  • command identification may be performed using subject information or object information instead of content information.
  • subject information or object information instead of content information.
  • an event whose identification information of the program is shown in the subject information or the object information can be treated as a command representing the execution of the command. ..
  • the identification information of the command may not be included in the content information.
  • the content information may show the identification information of the system call.
  • the identification information of the system call is, for example, a system call name or a system call number.
  • the contents information includes the contents of the argument given to the system call (the value of the argument itself, the data stored in the memory area pointed to by the pointer given as the argument), and under what conditions the system call is executed. Information indicating whether or not it has been performed may be further shown.
  • FIG. 6 is a diagram illustrating the event history 20 in a table format.
  • the table of FIG. 6 is referred to as the event table 200.
  • Each record in the event table 200 represents one event history 20.
  • the event table 200 roughly includes five items: terminal identification information 201, subject information 202, object information 204, content information 206, and occurrence time 207.
  • the subject information 202 includes three items of a process ID 208, a thread ID 209, and a path 210.
  • the object information 204 includes two items of type 212 and identification information 214.
  • the occurrence time 207 indicates the time when the event occurred.
  • the event history 20 is generated by recording the activity of the process on the target system.
  • Existing technology can be used as the technology for recording the activity of the process.
  • the abnormal event history 10 is an event history 20 representing an abnormal event.
  • the abnormal event history 10 may include information indicating the content of the abnormality (what kind of abnormality has occurred) in addition to the content of the event history 20.
  • Whether or not the event history 20 indicates an abnormal event is determined by, for example, the above-described abnormality detection device 120.
  • the method of determining whether or not the event represented by the event history is an abnormal event is as described above.
  • the acquisition unit 2020 acquires the abnormal event history 10 (S102). There are various methods by which the acquisition unit 2020 acquires the abnormal event history 10. For example, the acquisition unit 2020 acquires the abnormal event history 10 by receiving the abnormal event history 10 transmitted by the abnormality detection device 120. In addition, for example, the acquisition unit 2020 acquires the abnormal event history 10 by accessing the storage device in which the abnormal event history 10 is stored. A more specific method by which the acquisition unit 2020 acquires the abnormal event history 10 is as described above with reference to FIG.
  • the abnormal event of the first type is an abnormal event with a high probability that represents an important abnormality.
  • An example of an abnormal event having a high probability of representing an important abnormality is, for example, an abnormal event caused by execution of a command or the like whose safety is not ensured.
  • commands and the like various ones can be adopted as a standard for distinguishing commands that are secured and those that are not.
  • the program will be described. For example, a program determined to be safe by the administrator of the target system 100 is treated as a program whose safety is guaranteed. In addition, for example, the program that is installed together with the OS is treated as a program that guarantees safety.
  • a program that has been subjected to predetermined authentication is treated as a program that guarantees safety.
  • the program that has received the predetermined certification is, for example, a program to which a digital signature that certifies that the user has been certified by a predetermined certification authority is added.
  • whether or not the program is safe may be determined based on the number of users in the target system 100. For example, when the ratio of the number of terminals 110 in which a certain program is installed to the total number of terminals 110 included in the target system 100 is equal to or more than a predetermined value, the program is regarded as a program whose safety is guaranteed. deal with. In addition, for example, when a group is defined for the terminal 110, the ratio of the number of the terminals 110 in which a certain program is installed to the total number of the terminals 110 included in the group to which the terminal 110 belongs is equal to or more than a predetermined value. In some cases, the program is treated as a program that guarantees safety.
  • commands provided by programs whose safety is guaranteed can be treated as commands whose safety is ensured.
  • the standard command described above it is conceivable to handle the standard command described above as a command whose security is guaranteed. That is, the abnormal event generated by the execution of the standard command is not treated as the first-type abnormal event. By doing so, the information on the abnormal event generated by the execution of the standard command is not output until the first-type abnormal event is detected.
  • the safety of the command may be judged by a standard other than the above-mentioned standard.
  • a command that is determined to be safe by the administrator of the target system 100 is treated as a command whose safety is guaranteed.
  • the type determination unit 2040 determines whether the type of abnormal event represented by the abnormal event history 10 is the first type (S104). For example, the type determination unit 2040 uses information indicating a condition for classifying an abnormal event into the first type (hereinafter, type specifying information). The type identification information is stored in advance in a storage device accessible from the type determination unit 2040.
  • the above-mentioned type 1 abnormal event is an abnormal event caused by execution of a command or the like whose safety is not guaranteed, as described above. Therefore, for example, the type identification information indicates identification information such as a command whose safety is ensured. Then, an abnormal event caused by the execution of a command or the like not shown in the type specifying information is treated as a first type event.
  • the program identification information is, for example, the name or path of the executable file of the program.
  • the identification information of the executed program is included in the subject information described above.
  • the command identification information is, for example, the name of the command.
  • the identification information of the executed command is included in the subject information, the object information, or the content information described above.
  • commands with the same name are provided by different programs (for example, different shells).
  • the identification information of the command a combination of the identification information of the program providing the command and the name of the command is used as the identification information of the command.
  • the executed command is specified by the combination of the program identification information shown in the subject information and the command name shown in the content information.
  • the type determination unit 2040 determines whether or not the type of abnormal event represented by the abnormal event history 10 is the first type abnormal event by comparing the abnormal event history 10 with the type identification information. For example, if the program identified by the subject information of the abnormal event history 10 does not match any of the programs indicated in the type identification information, the type determination unit 2040 determines the type of abnormal event represented by the abnormal event history 10. Is a first-type abnormal event. On the other hand, when the program identified by the subject information of the abnormal event history 10 matches any of the programs indicated by the type identification information, the type determination unit 2040 determines whether the abnormal event represented by the abnormal event history 10 It is determined that the type is not the first type abnormal event.
  • the type determination unit 2040 determines whether the abnormal event represented by the abnormal event history 10 It is determined that the type is the abnormal event of the first type. On the other hand, when the command identified by the abnormal event history 10 matches any of the commands indicated in the type identification information, the type determination unit 2040 determines that the type of abnormal event represented by the abnormal event history 10 is the first. It is determined that the event is not one type of abnormal event.
  • the terminal identifying unit 2060 identifies the output target terminal (S106). Specifically, when the type of the abnormal event represented by the abnormal event history 10 is the first type, the terminal 110 in which the abnormal event has occurred, and communication with the terminal before the time when the abnormal event occurs The terminal 110 that was performing the operation is specified as the output target terminal.
  • the former is referred to as a first terminal and the latter is referred to as a second terminal.
  • the identification information of the first terminal is indicated by the abnormal event history 10 acquired by the acquisition unit 2020. Therefore, when the type of the abnormal event represented by the abnormal event history 10 is the first type, the terminal identifying unit 2060 uses the identification information of the terminal 110 indicated by the abnormal event history 10 to identify the output target terminal. One (first terminal) is specified.
  • the second terminal is specified by using the history of communication between the terminals 110. For example, when the terminal 110 communicates with another terminal 110, an event representing the communication is recorded as the event history 20.
  • the terminal identifying unit 2060 acquires the identification information of the second terminal by searching the database in which the event history 20 is recorded. Specifically, “the event occurrence time is before the occurrence time of the abnormal event indicated by the abnormal event history 10 acquired by the acquisition unit 2020” and “identification information of the terminal 110 of the communication source or the communication destination. Is the identification information of the first terminal.”
  • the event history 20 satisfying both of the two conditions is searched.
  • the event history 20 acquired by this search shows the first terminal on one of the communication source and the communication destination and the second terminal on the other. Therefore, the terminal identifying unit 2060 can identify the second terminal.
  • the terminal identifying unit 2060 stores the identification information of each output target terminal identified by the above-described method in the storage device. By doing so, the identification information of the output target terminal can be used in the subsequent processing.
  • the terminal 110 that communicates with the first terminal during the predetermined period before the time when the first-type abnormal event occurs, It may be handled as a terminal.
  • the length of this predetermined period is stored in advance in a storage device accessible from the terminal identification unit 2060.
  • the length of this predetermined period may be common to all the first-type abnormal events, or may differ depending on the type of the first-type abnormal event. In the latter case, for example, the length of the predetermined period is set according to the type of subject (program, command, etc.) of the first-type abnormal event. For example, a longer predetermined period is set for malware with a longer incubation period (a longer period from infection to specific damage). Examples of malware with a long incubation period include malware that searches for and exploits confidential information. On the other hand, examples of malware that has a short incubation period (the period from infection to specific damage is short) include ransomware.
  • the output unit 2080 determines whether the abnormal event represented by the abnormal event history 10 acquired by the acquisition unit 2020 has occurred in the output target terminal (S110). Specifically, the output unit 2080 determines whether the identification information of the terminal 110 shown in the abnormal event history 10 matches the identification information of any output target terminal. When the identification information of the terminal 110 shown in the abnormal event history 10 matches the identification information of any of the output target terminals, the output unit 2080 determines that the abnormal event has occurred in the output target terminal (S110: Yes). On the other hand, if the identification information of the terminal 110 shown in the abnormal event history 10 does not match the identification information of any output target terminal, the output unit 2080 determines that the abnormal event has not occurred in the output target terminal (S110: NO).
  • the output unit 2080 When the abnormal event represented by the abnormal event history 10 acquired by the acquisition unit 2020 has occurred in the output target terminal (S110: YES), the output unit 2080 outputs output information related to the abnormal event (S108). ).
  • the output information may be the acquired abnormal event history 10 itself, or may be information generated based on the content of the abnormal event history 10.
  • the output information includes the occurrence time of the abnormal event, the identification information of the terminal 110 in which the abnormal event has occurred, the identification information such as the command that caused the abnormal event, and the content of the abnormality (what kind of abnormality has occurred). ..
  • FIG. 7 is a diagram illustrating output information.
  • the output information is output to the display device connected to the history output device 2000.
  • the program X is a program not shown in the type specifying information (a program whose safety is not ensured), while the commands A and B are the commands (shown in the type specifying information). It is assumed that the command is secure. Further, it is assumed that the terminal A and the terminal B are communicating before the program X is executed on the terminal A.
  • an abnormal event of execution of program X that occurred in terminal A is shown. Since the program X is not shown in the type specifying information, the abnormal event of the execution of the program X in the terminal A is determined to be the first type abnormal event. Therefore, output information regarding this abnormal event is output. Even if the abnormal execution of the command A or the command B is performed before the occurrence of the first-type abnormal event, the abnormal execution is not output.
  • the terminal A on which the program X is executed is specified as the output target terminal.
  • the terminal B that was communicating with the terminal A before the occurrence time is also specified as the output target terminal. Therefore, the output unit 2080 also outputs output information for each abnormal event that occurs after the abnormal event of executing the program X. As a result, output information about abnormal execution of command A or command B is additionally displayed on the display device.
  • the output destination of the output information is not limited to the display device connected to the history output device 2000.
  • the output unit 2080 may output (additionally) output information to a predetermined stored log file.
  • the output information may be displayed on a display device other than the display device connected to the history output device 2000.
  • the history output device 2000 transmits output information to another device. As a result, the output information is displayed on the display device connected to the other device.
  • the history output device 2000 may further increase the number of output target terminals by another method.
  • the history output device 2000 may further treat the terminal 110 that has communicated with any of the output target terminals as an output target terminal. By doing so, when a specific abnormality (for example, a security risk) propagates through communication, it is possible to prevent the propagation of the abnormality from being overlooked.
  • a specific abnormality for example, a security risk
  • FIG. 8 is a diagram illustrating an overview of the history output device 2000 according to the second embodiment.
  • FIG. 8 is a diagram showing a conceptual explanation for facilitating understanding of the operation of the history output device 2000, and does not specifically limit the operation of the history output device 2000.
  • the history output apparatus 2000 according to the second embodiment has the same functions as the history output apparatus 2000 according to the first embodiment, except for the points described below.
  • the history output device 2000 of the second embodiment is common to the history output device 2000 of the first embodiment in that the abnormal event history 10 is output only for the output target terminal.
  • the history output device 2000 of the second embodiment differs from the history output device 2000 of the first embodiment in the following points.
  • the terminal 110 (first terminal) in which the abnormal event of the first type has occurred may be set as the output target terminal, and the terminal 110 (which is communicating with the terminal 110 ( The second terminal) does not have to be the output target terminal.
  • the history output device 2000 of the second embodiment when a certain terminal 110 is specified as an output target terminal, the abnormal event history 10 regarding the abnormal event that occurred in the terminal 110 is output retroactively.
  • the history output device 2000 of the present embodiment of the information on abnormal events that have occurred in the terminal 110, the information on abnormal events that do not belong to the first type is detected as the first type abnormal event. Is not output. However, when the first-type abnormal event occurs in the terminal 110, information about the abnormal event is output retroactively before the occurrence. Therefore, the information about the abnormal event having a low probability to a certain degree is not output unconditionally, but is output in association with the occurrence of the abnormal event having a high probability to show a serious abnormality.
  • the output information is appropriately narrowed down, so that the information about the abnormal event can be handled easily. Therefore, it is difficult to overlook a serious abnormality (that is, the analysis accuracy is improved), the work load on the analyst who analyzes the abnormal event is reduced, and the time required for the analysis work is reduced. ..
  • an example of a particularly effective case is analysis of a cyber attack using a standard OS command. Even if an anomaly occurs due to the standard command, it is difficult to determine whether or not the anomaly occurred as part of a cyber attack by itself. However, when an abnormal event with a high probability of representing a cyber attack is detected, it is considered highly probable that an anomaly caused by the standard command that occurred before that is related to the cyber attack.
  • an abnormal event having a high probability of representing a cyber attack is treated as a first-type abnormal event.
  • information about the abnormal event due to the standard command that occurred before that will also be output. Therefore, the information about the abnormality caused by the standard command can be appropriately narrowed down and output.
  • the functional configuration of the history output device 2000 of the second embodiment is represented in FIG. 2 as with the configuration of the history output device 2000 of the first embodiment.
  • the terminal identifying unit 2060 of the second embodiment identifies the terminal 110 in which the abnormal event occurs as the output target terminal.
  • the output unit 2080 outputs the output information regarding the abnormal event that occurs in the output target terminal after the identification, and also outputs the output information regarding the abnormal event that occurs in the output target terminal before the identification.
  • the hardware configuration of the history output device 2000 according to the second embodiment is represented in FIG. 3, for example, like the hardware configuration of the history output device 2000 according to the first embodiment.
  • the storage device 1080 of the history output apparatus 2000 of the second embodiment stores a program module that realizes the function of the history output apparatus 2000 of the second embodiment.
  • FIG. 9 is a flowchart illustrating the flow of processing executed by the history output device 2000 according to the second embodiment.
  • the acquisition unit 2020 acquires the abnormal event history 10 (S202).
  • the type determination unit 2040 determines whether the type of abnormal event represented by the acquired abnormal event history 10 is the first type (S204). When the type of abnormal event is not the first type (S204: NO), the process of FIG. 9 proceeds to S210.
  • the terminal identifying unit 2060 identifies the terminal 110 in which the abnormal event has occurred as the output target terminal (S206).
  • the output unit 2080 outputs, for the terminal 110 specified as the output target terminal, output information regarding an abnormal event that occurred in the terminal 110 before the specification (S207).
  • the output unit 2080 When the abnormal event represented by the acquired abnormal event history 10 has occurred in the output target terminal, the output unit 2080 outputs output information about the abnormal event (S208).
  • the type of the abnormal event indicated by the abnormal event history 10 is the first type (S204: YES)
  • the abnormal event always occurs in the output target terminal, and therefore the output unit 2080 outputs the abnormal event.
  • Information is output (S208).
  • the output unit 2080 determines whether or not the abnormal event has occurred in the output target terminal ( S210). When the abnormal event has occurred in the output target terminal (S210: YES), the output unit 2080 outputs the output information about the abnormal event (S208). On the other hand, when the abnormal event does not occur in the output target terminal (S210: NO), the output unit 2080 does not output the output information about the abnormal event.
  • the output unit 2080 outputs, for the terminal 110 specified as the output target terminal, output information regarding an abnormal event that occurred in the terminal 110 before the specification (S207).
  • the output unit 2080 may output the abnormal events that occurred in all the periods before the identification, or may output only the abnormal events that occurred within the predetermined period before the identification. Good.
  • the output unit 2080 causes the output time to occur in the abnormal event history 10 relating to the abnormal event that has occurred in the terminal 110 specified as the output target terminal, for a predetermined period before the specific time (the specific time is set as the end point). Specified period of time) to be included within the specified period. Then, the output unit 2080 outputs output information for the identified abnormal event history 10.
  • the length of this predetermined period may be common to all abnormal events or may differ depending on the abnormal event. In the latter case, for example, the length of the predetermined period is determined according to the type of command or the like that caused the abnormal event. Therefore, information in which the length of the predetermined period is associated with the type of command or the like is stored in the storage device in advance.
  • the malware activity may be of the types of activity such as initial investigation, search activity, and infection spread. Therefore, as the types of commands and the like, types such as commands used for initial investigation, commands used for search activities, and commands used for spreading infection are determined. Then, information in which these types of identification information are associated with identification information such as commands classified into the types is prepared. The history output device 2000 uses this information to grasp the type of each command and the like.
  • FIG. 10 is a diagram illustrating a case where the output target period varies depending on the type of command and the like.
  • a command for initial investigation, a command for search activity, a command for spreading infection, etc. are arranged in the order of longer output period. The reason for doing this is that malware activities are often carried out in the order of initial investigation activities, search activities, and infection spread activities.
  • FIG. 11 is a figure which illustrates the case where a predetermined period is extended.
  • the first-type abnormal event C occurs at the time t3 in the terminal A. Therefore, the output unit 2080 outputs the output information related to the abnormal event that occurred in the terminal A retroactively to the time t3.
  • the abnormal event that occurred in P1 (t2 to t3) for the predetermined period is the output target.
  • the abnormal event B has occurred in the terminal A. Therefore, the output information related to the abnormal event B is output.
  • the output information is output retroactively. Specifically, the output information is output for the period P2 (t1 to t3) in which the period P1 is further lengthened. For example, in the example of FIG. 11, abnormal event A occurs in terminal A during period P2. Therefore, the output information indicating the abnormal event A is output.
  • the output information may be output retroactively to a period earlier than period P2 (not shown).
  • the output unit 2080 repeats the process of “if an abnormal event occurs in the traced period, trace back to a past period (lengthen the period further)”. That is, until the situation "abnormal event has not occurred in the period traced back" is repeated, the trace is traced back to the past period.
  • an upper limit may be set to the number of times to go back (the number of times to extend the period).
  • the output information traced back in the past may be output as described in the second embodiment. That is, output information about an abnormal event that occurred in the past (prior to the occurrence) for each of the terminal in which the abnormal event of the first type has occurred and other terminals that have communicated with the terminal before the occurrence May be output.
  • An acquisition unit that acquires an abnormal event history indicating an abnormal event that has occurred in the terminal
  • a type determination unit that determines whether the type of the abnormal event represented by the acquired abnormal event history is a predetermined type, When the type of the abnormal event is the predetermined type, a terminal that identifies the terminal where the abnormal event has occurred and the other terminals that have communicated with the terminal before the time when the abnormal event occurs as the output target terminals A specific part,
  • an output unit that outputs output information related to the abnormal event, a history output device.
  • the predetermined type of abnormal event is an abnormal event caused by execution of a program or command whose safety is not ensured.
  • the program whose safety is not ensured is one or more of a program that is not installed together with the operating system, a program that is not authenticated, and a program that uses the program in a predetermined number or a predetermined ratio or less.
  • a command whose safety is not guaranteed is a command provided by a program whose safety is not guaranteed. Or 2.
  • History output device described in. 4. When the terminal specified as the output target terminal communicates with another terminal, the terminal specifying unit further specifies the other terminal as the output target terminal. Through 3.
  • the output unit When a certain terminal is specified as the output target terminal, the output unit further outputs output information related to an abnormal event that occurred at the terminal before the specification. Through 4.
  • An acquisition unit that acquires an abnormal event history indicating an abnormal event that has occurred in the terminal
  • a type determination unit that determines whether the type of the abnormal event represented by the acquired abnormal event history is a predetermined type, If the type of the abnormal event is the predetermined type, a terminal specifying unit that specifies the terminal in which the abnormal event has occurred as the output target terminal, When the abnormal event represented by the acquired abnormal event history is generated in the output target terminal, an output unit that outputs output information related to the abnormal event, A history output device, wherein when a certain terminal is specified as the output target terminal, the output unit further outputs output information regarding an abnormal event that has occurred at the terminal before the specification. 7. 5.
  • the output unit When a certain terminal is specified as the output target terminal, the output unit further outputs the abnormal event history indicating an abnormal event that has occurred in the terminal in a first predetermined period prior to the specification. History output device described in. 8. 6. The length of the first predetermined period differs depending on the type of program or command that has caused the abnormal event. History output device described in. 9. If the abnormal event has occurred in the terminal in the first predetermined period, the output unit further outputs output information related to the abnormal event that has occurred in the terminal in a second predetermined period that is longer than the first predetermined period, 7. Or 8. History output device described in.
  • a control method executed by a computer An acquisition step of acquiring an abnormal event history representing an abnormal event that has occurred in the terminal, A type determination step of determining whether the type of the abnormal event represented by the acquired abnormal event history is a predetermined type, When the type of the abnormal event is the predetermined type, a terminal that identifies the terminal where the abnormal event has occurred and the other terminals that have communicated with the terminal before the time when the abnormal event occurs as the output target terminals Specific steps, When the abnormal event represented by the acquired abnormal event history has occurred in the output target terminal, an output step of outputting output information related to the abnormal event is included. 11. 10.
  • the predetermined type of abnormal event is an abnormal event caused by execution of a program or command whose safety is not ensured. Control method described in. 12.
  • the program whose safety is not ensured is one or more of a program that is not installed together with the operating system, a program that is not authenticated, and a program that uses the program in a predetermined number or a predetermined ratio or less.
  • the unsecured command is a command provided by a program whose safety is not secured.
  • Control method described in. 13. 10. In the terminal specifying step, if the terminal specified as the output target terminal communicates with another terminal, the other terminal is further specified as the output target terminal. Through 12. The control method described in any one. 14. 10. In the output step, when a certain terminal is specified as the output target terminal, output information regarding an abnormal event that occurred in the terminal before the specification is further output. Through 13. The control method described in any one.
  • a control method executed by a computer An acquisition step of acquiring an abnormal event history representing an abnormal event that has occurred in the terminal, A type determination step of determining whether the type of the abnormal event represented by the acquired abnormal event history is a predetermined type, When the type of the abnormal event is the predetermined type, a terminal identification step of identifying the terminal in which the abnormal event has occurred as the output target terminal, When the abnormal event represented by the acquired abnormal event history is generated in the output target terminal, an output step of outputting output information related to the abnormal event, In the output step, when a certain terminal is specified as the output target terminal, output information regarding an abnormal event that occurred in the terminal before the specification is further output. 16.
  • the abnormal event history indicating an abnormal event that has occurred in the terminal in a first predetermined period prior to the specification is further output.
  • In the output step if an abnormal event has occurred in the terminal in the first predetermined period, output information regarding an abnormal event that has occurred in the terminal in a second predetermined period longer than the first predetermined period is further output. 16. Or 17. Control method described in.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

履歴出力装置（２０００）は、対象システム（１００）において発生した異常イベントを表す情報である異常イベント履歴（１０）を取得し、その異常イベント履歴（１０）によって表される異常イベントの種類を特定する。特定した異常イベントの種類が第１種である場合、履歴出力装置（２０００）は、その異常イベントが発生した端末（１１０）を、出力対象端末として特定する。さらに、履歴出力装置（２０００）は、その異常イベントが発生した時点以前に、その異常イベントが発生した端末（１１０）と通信を行っていた他の端末（１１０）も、出力対象端末として特定する。履歴出力装置（２０００）は、取得した異常イベント履歴（１０）によって表される異常イベントが出力対象端末で発生したものである場合に、その異常イベントに関する情報を出力する。

Description

履歴出力装置、制御方法、及びプログラム
　本発明はシステムで発生した異常に関する情報を管理する技術に関する。
　システムで発生した異常なイベントに関する情報を出力するための技術が開発されている。例えば特許文献１は、システムで実行されたコマンドのうち、システムの状態に影響を及ぼすものを記録しておき、システムにおいて異常が検知されたら、その異常の発生前所定時間内に実行されたコマンドを出力する技術を開示している。
特開２０１４－１０７６１号公報
　システムで発生した異常に関して出力される情報の量が多すぎると、その情報の解析作業が煩雑になる。その結果、重要な異常を見逃しやすくなるといった問題が生じる。この点、特許文献１の技術では、異常なイベントが検知されると、その異常が軽微なものなのか重大なものなのかにかかわらず、過去のコマンドのログが出力される。そのため、出力される情報（コマンドのログ）が多くなると考えられる。
　本発明は、上述の課題に鑑みてなされたものであり、その目的の一つは、異常なイベントに関する情報の扱いを容易にする技術を提供することである。
　本発明の第１の履歴出力装置は、１）端末において発生した異常イベントを表す異常イベント履歴を取得する取得部と、２）取得した異常イベント履歴が表す異常イベントの種類が所定の種類であるか否かを判定する種類判定部と、３）異常イベントの種類が所定の種類である場合、その異常イベントが発生した端末と、その異常イベントが発生した時点以前にその端末と通信した他の端末とを、出力対象端末として特定する端末特定部と、４）取得した異常イベント履歴によって表される異常イベントが出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力部と、を有する。
　本発明の第２の履歴出力装置は、１）端末において発生した異常イベントを表す異常イベント履歴を取得する取得部と、２）取得した異常イベント履歴が表す異常イベントの種類が所定の種類であるか否かを判定する種類判定部と、３）異常イベントの種類が所定の種類である場合、その異常イベントが発生した端末を出力対象端末として特定する端末特定部と、４）取得した異常イベント履歴によって表される異常イベントが出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力部と、を有する。
　出力部は、或る端末が出力対象端末として特定されたら、その特定より前にその端末で生じた異常イベントに関する出力情報をさらに出力する。
　本発明の第１の制御方法は、コンピュータによって実行される。当該制御方法は、１）端末において発生した異常イベントを表す異常イベント履歴を取得する取得ステップと、２）取得した異常イベント履歴が表す異常イベントの種類が所定の種類であるか否かを判定する種類判定ステップと、３）異常イベントの種類が所定の種類である場合、その異常イベントが発生した端末と、その異常イベントが発生した時点以前にその端末と通信した他の端末とを、出力対象端末として特定する端末特定ステップと、４）取得した異常イベント履歴によって表される異常イベントが出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力ステップと、を有する。
　本発明の第２の制御方法は、コンピュータによって実行される。当該制御方法は、１）端末において発生した異常イベントを表す異常イベント履歴を取得する取得ステップと、２）取得した異常イベント履歴が表す異常イベントの種類が所定の種類であるか否かを判定する種類判定ステップと、３）異常イベントの種類が所定の種類である場合、その異常イベントが発生した端末を出力対象端末として特定する端末特定ステップと、４）取得した異常イベント履歴によって表される異常イベントが出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力ステップと、を有する。
　出力ステップにおいて、或る端末が出力対象端末として特定されたら、その特定より前にその端末で生じた異常イベントに関する出力情報をさらに出力する。
　本発明の第１プログラムは、本発明の第１の制御方法が有する各ステップをコンピュータに実行させる。
　本発明の第２プログラムは、本発明の第２の制御方法が有する各ステップをコンピュータに実行させる。
　本発明によれば、異常なイベントに関する情報の扱いを容易にする技術が提供される。
　上述した目的、およびその他の目的、特徴および利点は、以下に述べる好適な実施の形態、およびそれに付随する以下の図面によってさらに明らかになる。
本実施形態の履歴出力装置の動作の概要を例示する図である。 実施形態１の履歴出力装置の構成を例示する図である。 履歴出力装置を実現するための計算機を例示する図である。 実施形態１の履歴出力装置の利用環境を例示する図である。 実施形態１の履歴出力装置によって実行される処理の流れを例示するフローチャートである。 イベント履歴をテーブル形式で例示する図である。 出力情報を例示する図である。 実施形態２の履歴出力装置の概要を例示する図である。 実施形態２の履歴出力装置によって実行される処理の流れを例示するフローチャートである。 コマンド等の種類に応じて出力対象の期間が異なるケースを例示する図である。 所定期間を延長するケースを例示する図である。
　以下、本発明の実施の形態について、図面を用いて説明する。尚、すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。また、特に説明する場合を除き、各ブロック図において、各ブロックは、ハードウエア単位の構成ではなく、機能単位の構成を表している。
＜概要＞
　図１は、本実施形態の履歴出力装置２０００の動作の概要を例示する図である。図１は、履歴出力装置２０００の動作についての理解を容易にするための概念的な説明を表す図であり、履歴出力装置２０００の動作を具体的に限定するものではない。
　履歴出力装置２０００は、対象のコンピュータシステム（対象システム１００）において発生した異常イベントを表す情報である異常イベント履歴１０を取得する。異常イベントとは、１）正常なプログラムならば発生させないイベントや、２）正常にプログラムを使用したならば発生しないイベントである。１）に当てはまる異常イベントとしては、例えば、或るプログラムが正常な状態であればアクセスしないファイルへアクセスしたことを表すイベントや、或るプログラムが正常な状態であれば通信しない通信相手と通信したことを表すイベントなどがある。例えばマルウエアに感染したプログラムは、そのプログラムが正常な状態であればアクセスしないファイルへアクセスしたりする。そのため、そのような動作を表すイベントが異常イベントとして検出される。
　２）に当てはまる異常イベントは、例えば、プログラムの正しい使用方法が定められている場合において、プログラムの使用者がその使用方法に反してプログラムを使用した結果として発生するイベントである。例えば、ping コマンドの正しい使用方法として、「特定のマシン（例えばサーバマシン）に対して ping コマンドを送信して、そのマシンが動作していることを確かめる」という使用方法を定めておく。この場合に、マシンの管理者が誤って、特定のマシン以外のマシンを宛先として ping コマンドを使用したとする。これによって発生するイベント（特定のマシン以外のマシンとの通信を表すイベント）は、上述した ping コマンドの正しい使用方法に反しているため、異常なイベントとして扱われる。
　対象システム１００は、１つ以上の任意の端末１１０で構成される。端末１１０は、物理マシンであってもよいし、仮想マシンであってもよい。物理マシンは、PC（Personal Computer）などの据え置き型のマシンであってもよいし、スマートフォンなどの可搬型のマシンであってもよい。イベントは、例えば、対象システムに含まれるマシンで動作するプロセスが行った活動（ファイルや他のプロセスへのアクセスなど）を表す。
　履歴出力装置２０００は、対象システム１００で発生した異常イベントの種類に基づいて、異常イベント履歴１０の出力（例えばディスプレイ装置への表示）を制御する。ここで、異常イベントの種類には、少なくとも第１種という種類が存在するとする。また、異常イベントには、第１種に属するものと属さないものが存在するとする。第１種の異常イベントは、例えば、重大な異常を表す蓋然性が高い異常イベントである。より具体的には、例えば第１種の異常イベントは、安全性が担保されていないコマンドやプログラムの実行によって生じたイベントである。以下、「コマンドやプログラム」のことを「コマンド等」とも表記する。
　履歴出力装置２０００は、異常イベント履歴１０を取得したら、その異常イベント履歴１０によって表される異常イベントの種類を特定する。特定した異常イベントの種類が第１種である場合、履歴出力装置２０００は、その異常イベントが発生した端末１１０を、出力対象端末として特定する。さらに、履歴出力装置２０００は、その異常イベントが発生した時点以前に、その異常イベントが発生した端末１１０と通信を行っていた他の端末１１０も、出力対象端末として特定する。履歴出力装置２０００は、取得した異常イベント履歴１０によって表される異常イベントが出力対象端末で発生したものである場合に、その異常イベントに関する情報（以下、出力情報）を出力する。
＜作用効果＞
　システムにおける重大な異常の見逃しを防ぐためには、重大な異常を表す蓋然性が高いイベントだけでなく、重大な異常を表す蓋然性がある程度低いイベントについても、異常イベントとして検出しておく必要がある。一方で、このように重大な異常を表す蓋然性がある程度低い異常イベントに関する情報についても無条件に出力（例えば、管理者等へ出力）してしまうと、異常イベントに関する情報が大量に出力されることになってしまい、情報の扱いが難しくなってしまう。その結果、重大な異常の見逃しが発生しやすい、異常イベントを解析する解析者の作業負担が大きい、解析作業に要する時間が長いといった問題が生じうる。
　このような問題の発生を防ぐためには、出力される情報をある程度絞り込むことが好適である。この点、履歴出力装置２０００によれば、端末１１０で発生した異常イベントに関する情報のうち、第１種に属さない異常イベントについての情報は、第１種の異常イベントが検出されるまで出力されない。そのため、例えば、重大な異常を表す蓋然性が高い異常イベントを第１種のイベントとして扱うことにより、重大な異常を表す蓋然性がある程度低い異常イベントに関する情報は、重大な異常を表す蓋然性が高い異常イベントが発生するまで出力されない。一方で、重大な異常を表す蓋然性が高い異常イベントが発生した後は、重大な異常を表す蓋然性がある程度低い異常イベントについての情報も出力されるようになる。このように、重大な異常を表す蓋然性がある程度低い異常イベントに関する情報は、無条件に出力されるわけでなく、重大な異常を表す蓋然性が高い異常イベントの発生に付随して出力されるようになる。
　この手法によれば、異常イベントに関する情報が無条件に出力される場合と比較し、出力される情報が適切に絞り込まれるため、異常イベントに関する情報の扱いが容易になる。そのため、重大な異常の見逃しが発生しにくくなる（すなわち、解析精度の向上）、異常イベントを解析する解析者の作業負担が軽減される、及び解析作業に要する時間が削減されるといった効果が生じる。
　例えば安全性が担保されていないコマンド等の実行によって生じる異常イベントを第１種の異常イベントとして扱うとする。この場合、安全性が担保されている異常イベントに関する情報は、安全性が担保されていない異常イベントの発生に付随して出力されるようになる。こうすることで、安全性が担保されている異常イベントについての情報が適切に絞り込まれて出力されるため、異常イベントに関する情報の扱いが容易になる。
　本発明が特に効果的なケースの例として、OS（Operating System）の標準コマンドを使用したサイバー攻撃の解析が挙げられる。ここでいう、OS の標準コマンドとは、OS をインストールした際に一緒にインストールされる所定のプログラム（例えばシェルプログラム）によって提供されるコマンドである。例えば、端末１１０にインストールされたマルウエアが、端末１１０上で動作している OS が提供している標準コマンドを利用して種々の活動（探索活動や感染拡大など）を行うとする。このようなサイバー攻撃を解析するためには、標準コマンドの実行によって生じた異常イベントに関する情報も出力する必要がある。
　一方で、標準コマンドの実行によって生じた異常イベントの全てがサイバー攻撃を表すわけでない。例えば、ユーザが誤った使用方法で標準コマンドを実行してしまうケースなどが考えられる。そのため、標準コマンドの実行によって生じた異常イベントに関する情報を全て出力してしまうと、上述のサイバー攻撃に関する情報の解析が難しくなるという問題が生じる。
　そこで例えば、履歴出力装置２０００において、サイバー攻撃を表す蓋然性が高い異常イベントを、第１種の異常イベントとして扱うようにする。例えば、「文書作成ソフトウエアがパスワードファイルを読み出す」などといったイベントを、第１種の異常イベントとして扱う。一方で、標準コマンドの実行によって生じた異常イベントについては、サイバー攻撃を表す蓋然性がある程度低いと考えられるため、第１種の異常イベントとしては扱わないようにする。こうすることで、標準コマンドの実行によって生じた異常イベントについては、サイバー攻撃を表す蓋然性が高い異常イベントに付随するもののみが出力されるようになる。よって、サイバー攻撃に関する異常イベントの情報が適切に絞り込まれて出力されるため、サイバー攻撃に関する情報の扱いが容易になる。そのため、サイバー攻撃に関する解析の精度が向上する、サイバー攻撃の解析を行う解析者の作業負担が軽減される、及びサイバー攻撃の解析作業に要する時間が削減されるといった効果が生じる。
　以下、本実施形態の履歴出力装置２０００についてさらに詳細に説明する。
＜履歴出力装置２０００の機能構成の例＞
　図２は、実施形態１の履歴出力装置２０００の構成を例示する図である。履歴出力装置２０００は、取得部２０２０、種類判定部２０４０、端末特定部２０６０、及び出力部２０８０を有する。取得部２０２０は異常イベント履歴１０を取得する。種類判定部２０４０は、取得した異常イベント履歴１０によって表される異常イベントの種類が所定の種類（第１種）であるか否かを判定する。端末特定部２０６０は、特定した異常イベントの種類が所定の種類である場合に、その異常イベントが発生した端末１１０、及びその異常イベントが発生した時点以前にその端末１１０と通信していた他の端末１１０を、出力対象端末として特定する。出力部２０８０は、取得した異常イベント履歴１０によって表される異常イベントが出力対象端末で発生したものである場合に、その異常イベントに関する出力情報を出力する。
＜履歴出力装置２０００のハードウエア構成＞
　履歴出力装置２０００の各機能構成部は、各機能構成部を実現するハードウエア（例：ハードワイヤードされた電子回路など）で実現されてもよいし、ハードウエアとソフトウエアとの組み合わせ（例：電子回路とそれを制御するプログラムの組み合わせなど）で実現されてもよい。以下、履歴出力装置２０００の各機能構成部がハードウエアとソフトウエアとの組み合わせで実現される場合について、さらに説明する。
　図３は、履歴出力装置２０００を実現するための計算機１０００を例示する図である。計算機１０００は任意の計算機である。例えば計算機１０００は、Personal Computer（PC）、サーバマシン、タブレット端末、又はスマートフォンなどである。計算機１０００は、履歴出力装置２０００を実現するために設計された専用の計算機であってもよいし、汎用の計算機であってもよい。
　計算機１０００は、バス１０２０、プロセッサ１０４０、メモリ１０６０、ストレージデバイス１０８０、入出力インタフェース１１００、及びネットワークインタフェース１１２０を有する。バス１０２０は、プロセッサ１０４０、メモリ１０６０、ストレージデバイス１０８０、入出力インタフェース１１００、及びネットワークインタフェース１１２０が、相互にデータを送受信するためのデータ伝送路である。ただし、プロセッサ１０４０などを互いに接続する方法は、バス接続に限定されない。プロセッサ１０４０は、CPU（Central Processing Unit）、GPU（Graphics Processing Unit）、又は FPGA（Field-Programmable Gate Array）などのプロセッサである。メモリ１０６０は、RAM（Random Access Memory）などを用いて実現される主記憶装置である。ストレージデバイス１０８０は、ハードディスクドライブ、SSD（Solid State Drive）、メモリカード、又は ROM（Read Only Memory）などを用いて実現される補助記憶装置である。ただし、ストレージデバイス１０８０は、RAM など、主記憶装置を構成するハードウエアと同様のハードウエアで構成されてもよい。
　入出力インタフェース１１００は、計算機１０００と入出力デバイスとを接続するためのインタフェースである。ネットワークインタフェース１１２０は、計算機１０００を通信網に接続するためのインタフェースである。この通信網は、例えば LAN（Local Area Network）や WAN（Wide Area Network）である。ネットワークインタフェース１１２０が通信網に接続する方法は、無線接続であってもよいし、有線接続であってもよい。
　ストレージデバイス１０８０は、履歴出力装置２０００の機能構成部を実現するプログラムモジュールを記憶している。プロセッサ１０４０は、これら各プログラムモジュールをメモリ１０６０に読み出して実行することで、各プログラムモジュールに対応する機能を実現する。
＜利用環境の例＞
　図４は、実施形態１の履歴出力装置２０００の利用環境を例示する図である。図４において、対象システム１００には、複数の端末１１０が含まれている。端末１１０では、種々のコマンド等が実行される。端末１１０では、コマンド等の実行によって発生したプロセスの動作を表すイベントの履歴が記録される。この履歴を、イベント履歴２０と呼ぶ。イベント履歴２０は、異常検知装置１２０に収集される。イベント履歴２０の収集は、例えば、端末１１０がイベント履歴２０を定期的に又はリアルタイムで異常検知装置１２０へ送信することで実現される。
　異常検知装置１２０は、イベント履歴２０によって表されるイベントが、異常イベントであるか否かを判定する。そして、イベント履歴２０によって表されるイベントが異常イベントである場合、そのイベント履歴２０は、異常イベント履歴１０として扱われる。
　例えば、対象システム１００で（対象システム１００に含まれる端末１１０で）発生する正常なイベントを定義したモデルを予め生成しておく。異常検知装置１２０は、各イベント履歴２０に示されるイベントが上記モデルから逸脱しているか否かを判定する。異常検知装置１２０は、上記モデルから逸脱しているイベントを、異常イベントとして検知する。なお、正常なイベントのモデルを生成する技術や、正常なイベントのモデルから逸脱したイベントを異常イベントとして検出する技術には、既存の技術を利用することができる。
　履歴出力装置２０００は、異常イベント履歴１０を取得して、取得した異常イベント履歴１０を処理する。ここで、履歴出力装置２０００がイベント履歴２０のうち、異常イベント履歴１０を取得する方法は様々である。例えば異常検知装置１２０は、イベント履歴２０に対し、異常イベント履歴１０であるか否かを示すフラグを付加して記憶装置に記憶させる。取得部２０２０は、この記憶装置に記憶されているイベント履歴２０のうち、異常イベント履歴１０であることを示すフラグに対応づけられているものを取得する。その他にも例えば、異常検知装置１２０が異常イベント履歴１０を取得部２０２０へ出力（例えば送信）してもよい。取得部２０２０は、異常検知装置１２０によって出力された異常イベント履歴１０を取得する。
　異常検知装置１２０は、履歴出力装置２０００と別途設けられてもよいし、履歴出力装置２０００の中に設けられてもよい。後者の場合、履歴出力装置２０００は、イベント履歴２０を収集して、各イベント履歴２０が異常イベントを表すか否かを判定する。そして、履歴出力装置２０００は、異常イベントを表すイベント履歴２０を、異常イベント履歴１０として扱う。なお、図４では、異常検知装置１２０と履歴出力装置２０００が別々に設けられている。
＜処理の流れ＞
　図５は、実施形態１の履歴出力装置２０００によって実行される処理の流れを例示するフローチャートである。取得部２０２０は異常イベント履歴１０を取得する（Ｓ１０２）。種類判定部２０４０は、取得した異常イベント履歴１０によって表される異常イベントの種類が第１種であるか否かを判定する（Ｓ１０４）。異常イベントの種類が第１種でない場合（Ｓ１０４：ＮＯ）、図５の処理はＳ１１０に進む。異常イベントの種類が第１種である場合（Ｓ１０４：ＹＥＳ）、端末特定部２０６０は、その異常イベントが発生した端末１１０と、その異常イベントが発生した時刻以前にその端末１１０と通信していた他の端末１１０を、出力対象端末として特定する（Ｓ１０６）。
　出力部２０８０は、取得した異常イベント履歴１０によって表される異常イベントが出力対象端末で発生したものである場合、その異常イベントについての出力情報を出力する（Ｓ１０８）。異常イベント履歴１０によって示される異常イベントの種類が第１種である場合（Ｓ１０４：ＹＥＳ）、その異常イベントは必ず出力対象端末で発生したものであるため、出力部２０８０は、その異常イベントに関する出力情報を出力する（Ｓ１０８）。
　一方、異常イベント履歴１０によって示される異常イベントの種類が第１種でない場合（Ｓ１０４：ＮＯ）、出力部２０８０は、その異常イベントが出力対象端末で発生したものであるか否かを判定する（Ｓ１１０）。異常イベントが出力対象端末で発生したものである場合（Ｓ１１０：ＹＥＳ）、出力部２０８０は、その異常イベントについての出力情報を出力する（Ｓ１０８）。一方、異常イベントが出力対象端末で発生したものでない場合（Ｓ１１０：ＮＯ）、出力部２０８０は、その異常イベントについての出力情報を出力しない。
　ここで、履歴出力装置２０００は複数の異常イベント履歴１０を取得し、異常イベントの発生時刻が早い異常イベント履歴１０から順に、図５に示す一連の処理を行う。そのため、或る端末１１０が出力対象端末として特定された後は、その端末１１０で発生した異常イベントを表す各異常イベント履歴１０が出力部２０８０によって出力されるようになる。
　ただし、或る端末１１０が出力対象端末として扱われるようになった後、履歴出力装置２０００は、所定の条件に基づいて、その端末１１０を出力対象端末として扱わないようにしてもよい。例えば、或る端末１１０が出力対象端末として特定された後、その端末１１０で第１種の異常イベントが所定時間以上発生しなかったら、その端末１１０を出力対象端末として扱わないようにする。
　その他にも例えば、履歴出力装置２０００は、出力対象端末として扱われている端末１１０の中から、出力対象端末として扱わないようにする端末１１０を選択する入力操作を、ユーザから受け付けてもよい。例えば対象システム１００の管理者が、或る端末１１０について出力された異常イベント履歴１０を閲覧・解析した結果、その端末１１０については問題がない（異常イベント履歴１０を出力しなくてもよい）と判断したとする。この場合、その管理者は問題がないと判断した端末１１０を出力対象端末から除外する入力操作を行う。
＜イベント履歴２０について＞
　イベント履歴２０は、過去の或る時点において対象システム１００で（対象システム１００に含まれる端末１１０で）発生したイベントに関する情報である。例えばイベント履歴２０は、イベントが発生した端末１１０の識別情報、イベントの発生時刻、及びイベントの内容を対応づけて示す。
　例えばイベント履歴２０は、対象システム１００で動作するプロセスの活動の履歴を表す。例えばプロセスの活動は、システムコール単位で記録される。或るプロセスが他のプロセスを客体として活動する場合、これらのプロセスは互いに同一の OS（Operating System）上で動作するものであってもよいし、互いに異なる OS 上で動作するものであってもよい。後者の例としては、例えば、ソケットインタフェースを利用することで、或るプロセスが他の OS 上で動作する別のプロセスと通信を行うことが考えられる。
　イベント履歴２０は、１つ以上の項目に関する情報を示す。ここで、例えばイベントは、イベントが発生した端末１１０の識別情報、イベントの主体、イベントの客体、活動内容、及び発生時刻という５つの要素を表す情報によって識別される。そこで例えば、イベント履歴２０は、大別して、端末１１０の識別情報、主体を表す主体情報、客体を表す客体情報、活動の内容を表す内容情報、及び発生時刻という５つの項目で構成される。
　端末１１０の識別情報は、端末１１０を識別できる任意の情報である。例えば、端末１１０のネットワークアドレス（IP アドレスや MAC アドレス）や UUID（Universally Unique Identifier）などを端末１１０の識別情報として利用できる。
　主体情報は、例えば、その主体の種類及び識別情報である。主体の種類は、例えば、プロセス又はソケットなどである。主体がプロセスである場合、主体情報には、そのプロセスを識別する情報が含まれる。以下、プロセスを識別する情報をプロセス識別情報と呼ぶ。具体的には、プロセス識別情報は、プロセスＩＤ（Identifier）を含む。ただし、複数のスレッドが動作するプロセスについてのプロセス識別情報は、プロセスＩＤに加え、スレッドＩＤをさらに含む。
　また、プロセス識別情報は、プロセスの実行ファイルに関する情報をさらに含む。プロセスの実行ファイルに関する情報とは、例えば、実行ファイルの名称やパス、実行ファイルのハッシュ値、実行ファイルのデジタル署名、又は実行ファイルで実現されるアプリケーションの名称などである。
　主体がソケットである場合、例えば主体情報には、ソケットに割り当てられた識別子が含まれる。
　客体情報は、例えば、その客体の種類及び識別情報である。客体の種類は、例えば、プロセス、ファイル、又はソケットなどである。客体がプロセスである場合、客体情報にはそのプロセスのプロセス識別情報が含まれる。
　客体がファイルである場合、客体情報には、そのファイルを識別する情報（以下、ファイル識別情報）が含まれる。ファイル識別情報は、例えばファイルの名称やパスなどである。また、客体がファイルである場合、客体情報には、そのファイルのハッシュ値や、ファイルシステムの識別子とファイルシステム上でのファイルを構成するディスクブロックの識別子（inode 番号やオブジェクトID）の組み合わせなどが含まれていてもよい。
　客体がソケットである場合、例えば客体情報には、ソケットに割り当てられた識別子が含まれる。
　内容情報は、例えば、種々ある活動内容に割り当てられた識別情報である。例えば、「指定されたコマンドを実行する」、「プロセスを起動する」、「プロセスを停止する」、「ファイルをオープンする」、「ファイルからデータを読み込む」、「ファイルにデータを書き込む」、「ソケットをオープンする」、「ソケットからデータを読み込む」、「ソケットにデータを書き込む」、及び「ソケットから別のソケットへデータを送信する」などといった活動の内容に、互いに異なる識別子を割り当てておく。なお、ソケットに対するアクセスは、そのソケットに対応づけられた他の装置へのアクセスを意味する。
　ここで、内容情報がコマンドの実行を表す場合には、実行されるコマンドの識別情報も内容情報に含める。例えば、ls というコマンドが実行されたことを表すイベント履歴２０では、内容情報として、「活動内容の識別情報：コマンドの実行、コマンドの識別情報：ls」などと示すようにする。
　なお、コマンドの識別は、内容情報ではなく主体情報や客体情報を用いて行われてもよい。例えば、或るコマンドの実行が１つのプログラムの実行によって実現される場合、そのプログラムの識別情報が主体情報又は客体情報に示されているイベントを、そのコマンドの実行を表すコマンドとして扱うことができる。この場合、コマンドの識別情報は内容情報に含まれなくてもよい。
　システムコール単位でイベントが記録される場合、内容情報は、システムコールの識別情報を示してもよい。システムコールの識別情報は、例えば、システムコール名やシステムコール番号である。また、内容情報には、システムコールに与えた引数の内容（引数自体の値や、引数として与えたポインタが指し示すメモリ領域に格納されているデータ）など、システムコールがどのような条件下で実行されたかを表す情報がさらに示されてもよい。
　図６は、イベント履歴２０をテーブル形式で例示する図である。以下、図６のテーブルをイベントテーブル２００と呼ぶ。イベントテーブル２００の各レコードは、１つのイベント履歴２０を表す。イベントテーブル２００は、大別して、端末識別情報２０１、主体情報２０２、客体情報２０４、内容情報２０６、及び発生時刻２０７という５つの項目を含む。主体情報２０２は、プロセスＩＤ２０８、スレッドＩＤ２０９、及びパス２１０という３つの項目を含む。客体情報２０４は、種類２１２及び識別情報２１４という２つの項目を含む。発生時刻２０７は、イベントが発生した時刻を示す。
　ここで、イベント履歴２０は、対象システム上におけるプロセスの活動を記録することで生成される。プロセスの活動を記録する技術には、既存の技術を利用することができる。
＜異常イベント履歴１０について＞
　異常イベント履歴１０は、異常イベントを表すイベント履歴２０である。異常イベント履歴１０には、イベント履歴２０の内容に加え、異常の内容（どのような異常が発生したのか）を示す情報が含まれてもよい。
　イベント履歴２０が異常イベントを示すか否かは、例えば前述した異常検知装置１２０によって判定される。ここで、イベントの履歴によって表されるイベントが異常なイベントであるか否かを判定する方法は、前述した通りである。
＜異常イベント履歴１０の取得：Ｓ１０２＞
　取得部２０２０は異常イベント履歴１０を取得する（Ｓ１０２）。取得部２０２０が異常イベント履歴１０を取得する方法は様々である。例えば取得部２０２０は、異常検知装置１２０によって送信された異常イベント履歴１０を受信することで、異常イベント履歴１０を取得する。その他にも例えば、取得部２０２０は、異常イベント履歴１０が記憶されている記憶装置にアクセスすることで、異常イベント履歴１０を取得する。なお、取得部２０２０が異常イベント履歴１０を取得するより具体的な方法については、図４を用いて前述した通りである。
＜異常イベントの種類について＞
　例えば第１種の異常イベントは、重要な異常を表す蓋然性が高い異常イベントである。重要な異常を表す蓋然性が高い異常イベントの例としては、例えば、安全性が担保されていないコマンド等の実行によって生じる異常イベントがある。ここで、コマンド等について、安全性が担保されているものとそうでないものを区別する基準には、様々なものを採用できる。まず、プログラムについて説明する。例えば、対象システム１００の管理者によって安全であると判断されたプログラムを、安全性が担保されているプログラムとして扱う。その他にも例えば、OS をインストールした際に一緒にインストールされるプログラムを、安全性が担保されているプログラムとして扱う。その他にも例えば、所定の認証を受けているプログラムを、安全性が担保されているプログラムとして扱う。所定の認証を受けているプログラムは、例えば、所定の認証機関による認証を受けたことを証明する電子署名が付与されたプログラムである。
　その他にも例えば、プログラムが安全であるか否かは、対象システム１００における利用者の多さに基づいて決められてもよい。例えば、対象システム１００に含まれる端末１１０の総数に対し、或るプログラムがインストールされている端末１１０の数の割合が所定値以上である場合、そのプログラムを、安全性が担保されているプログラムとして扱う。その他にも例えば、端末１１０にグループが定められている場合、或るプログラムがインストールされている端末１１０の数の、その端末１１０が属するグループに含まれる端末１１０の総数に対する割合が所定値以上である場合に、そのプログラムを、安全性が担保されているプログラムとして扱う。
　コマンドの安全性については、例えば、安全性が担保されているプログラムによって提供されているコマンドを、安全性が担保されているコマンドとして扱うことができる。例えば、前述した標準コマンドを、安全性が担保されているコマンドとして扱うことが考えられる。すなわち、標準コマンドの実行によって発生した異常イベントは第１種の異常イベントとして扱わないようにする。こうすることで、標準コマンドの実行によって発生した異常イベントに関する情報は、第１種の異常イベントが検出されるまで出力されないようになる。
　ただし、コマンドの安全性は、前述した基準とは別の基準で判断されてもよい。例えば、対象システム１００の管理者によって安全であると判断されたコマンドを、安全性が担保されたコマンドとして扱う。
＜異常イベントの種類の判定：Ｓ１０４＞
　種類判定部２０４０は、異常イベント履歴１０によって表される異常イベントの種類が第１種であるか否かを判定する（Ｓ１０４）。例えば種類判定部２０４０は、異常イベントが第１種に分類される条件を示す情報（以下、種類特定情報）を利用する。種類特定情報は、種類判定部２０４０からアクセス可能な記憶装置に予め記憶させておく。
　前述した第１種の異常イベントは、例えば前述したように、安全性が担保されていないコマンド等の実行によって生じた異常イベントである。そこで例えば、種類特定情報は、安全性が担保されているコマンド等の識別情報を示す。そして、種類特定情報に示されていないコマンド等の実行によって生じた異常イベントを、第１種のイベントとして扱う。
　プログラムの識別情報は、例えば、そのプログラムの実行ファイルの名称やパスなどである。異常イベント履歴１０において、実行されたプログラムの識別情報は、前述した主体情報に含まれている。
　コマンドの識別情報は、例えば、コマンドの名称である。異常イベント履歴１０において、実行されたコマンドの識別情報は、前述した主体情報、客体情報、又は内容情報に含まれている。ただし、同じ名称のコマンドが互いに異なるプログラム（例えば、互いに異なるシェル）によって提供されるケースもある。この場合、コマンドの識別情報は、そのコマンドを提供するプログラムの識別情報とそのコマンドの名称などとの組み合わせを、コマンドの識別情報として利用する。この場合、異常イベント履歴１０において、実行されたコマンドは、主体情報に示されるプログラムの識別情報と、内容情報に示されるコマンドの名称などとの組み合わせによって特定される。
　種類判定部２０４０は、異常イベント履歴１０を種類特定情報と比較することにより、異常イベント履歴１０によって表される異常イベントの種類が第１種の異常イベントであるか否かを判定する。例えば種類判定部２０４０は、異常イベント履歴１０の主体情報によって特定されるプログラムが、種類特定情報に示されているプログラムのいずれとも合致しない場合、その異常イベント履歴１０によって表される異常イベントの種類が第１種の異常イベントであると判定する。一方、異常イベント履歴１０の主体情報によって特定されるプログラムが、種類特定情報に示されているプログラムのいずれかと合致する場合、種類判定部２０４０は、その異常イベント履歴１０によって表される異常イベントの種類が第１種の異常イベントでないと判定する。
　その他にも例えば、種類判定部２０４０は、異常イベント履歴１０によって特定されるコマンドが、種類特定情報に示されているコマンドのいずれとも合致しない場合、その異常イベント履歴１０によって表される異常イベントの種類が第１種の異常イベントであると判定する。一方、異常イベント履歴１０によって特定されるコマンドが、種類特定情報に示されているコマンドのいずれかと合致する場合、種類判定部２０４０は、その異常イベント履歴１０によって表される異常イベントの種類が第１種の異常イベントでないと判定する。
＜出力対象端末の特定：Ｓ１０６＞
　端末特定部２０６０は、出力対象端末を特定する（Ｓ１０６）。具体的には、異常イベント履歴１０によって表される異常イベントの種類が第１種であった場合に、その異常イベントが発生した端末１１０と、その異常イベントが発生した時刻以前にその端末と通信していた端末１１０が、出力対象端末として特定される。以下、記載を明瞭にするため、前者を第１端末と呼び、後者を第２端末と呼ぶ。
　第１端末の識別情報は、取得部２０２０によって取得された異常イベント履歴１０によって示されている。そのため、端末特定部２０６０は、異常イベント履歴１０によって表される異常イベントの種類が第１種であった場合、その異常イベント履歴１０によって示されている端末１１０の識別情報によって、出力対象端末の１つ（第１端末）を特定する。
　第２端末は、端末１１０同士の通信の履歴を用いて特定する。例えば端末１１０が他の端末１１０と通信を行ったら、その通信を表すイベントがイベント履歴２０として記録されるようにしておく。端末特定部２０６０は、イベント履歴２０が記録されているデータベースを検索することで、第２端末の識別情報を取得する。具体的には、「イベントの発生時刻が、取得部２０２０によって取得された異常イベント履歴１０によって示されている異常イベントの発生時刻以前である」及び「通信元又は通信先の端末１１０の識別情報が、第１端末の識別情報である」という２つの条件の両方を満たすイベント履歴２０を検索する。この検索によって取得されたイベント履歴２０は、通信元又は通信先の一方に第１端末を示し、他方に第２端末を示す。そのため、端末特定部２０６０は、第２端末を特定することができる。
　端末特定部２０６０は、上述した方法で特定した各出力対象端末の識別情報を記憶装置に記憶させる。こうすることで、出力対象端末の識別情報を後の処理で利用できるようにする。
　なお、第１種の異常イベントが発生した時刻以前の期間の全てでは無く、第１種の異常イベントが発生した時刻以前の所定期間に第１端末と通信していた端末１１０のみを、第２端末として扱うようにしてもよい。この所定期間の長さは、端末特定部２０６０からアクセス可能な記憶装置に予め記憶させておく。
　この所定期間の長さは、第１種の異常イベント全てで共通であってもよいし、第１種の異常イベントの種類に応じて異なっていてもよい。後者の場合、例えば、第１種の異常イベントの主体（プログラムやコマンドなど）の種類に応じて、所定期間の長さを定めておく。例えば、潜伏期間が長い（感染してから具体的な被害が生じるまでの期間が長い）マルウエアほど長い所定期間を設定する。潜伏期間が長いマルウエアとしては、例えば、機密情報を探索して搾取するようなマルウエアが挙げられる。一方で、潜伏期間が短い（感染してから具体的な被害が生じるまでの期間が短い）マルウエアとしては、例えば、ランサムウエアなどが挙げられる。
＜出力対象端末で発生した異常イベントであるか否かの判定：Ｓ１１０＞
　出力部２０８０は、取得部２０２０によって取得された異常イベント履歴１０によって表される異常イベントが、出力対象端末で発生したものであるか否かを判定する（Ｓ１１０）。具体的には、出力部２０８０は、異常イベント履歴１０に示される端末１１０の識別情報が、いずれかの出力対象端末の識別情報と合致するか否かを判定する。異常イベント履歴１０に示される端末１１０の識別情報がいずれかの出力対象端末の識別情報と合致する場合、出力部２０８０は、異常イベントが出力対象端末で発生したものであると判定する（Ｓ１１０：ＹＥＳ）。一方、異常イベント履歴１０に示される端末１１０の識別情報がいずれの出力対象端末の識別情報とも合致しない場合、出力部２０８０は、異常イベントが出力対象端末で発生したものでないと判定する（Ｓ１１０：ＮＯ）。
＜異常イベント履歴１０の出力：Ｓ１０８＞
　出力部２０８０は、取得部２０２０によって取得された異常イベント履歴１０によって表される異常イベントが出力対象端末で発生したものである場合（Ｓ１１０：ＹＥＳ）、その異常イベントに関する出力情報を出力する（Ｓ１０８）。出力情報は、取得した異常イベント履歴１０そのものであってもよいし、異常イベント履歴１０の内容に基づいて生成される情報であってもよい。例えば出力情報は、異常イベントの発生時刻、異常イベントが発生した端末１１０の識別情報、異常イベントを発生させたコマンド等の識別情報、及び異常の内容（どのような異常が発生したか）を含む。
　図７は、出力情報を例示する図である。この例では、履歴出力装置２０００に接続されているディスプレイ装置に出力情報が出力されるケースを例示している。また、この例では前提として、プログラムＸは種類特定情報に示されていないプログラム（安全性が担保されていないプログラム）である一方、コマンドＡとコマンドＢは種類特定情報に示されているコマンド（安全性が担保されているコマンド）であるとする。さらに、端末ＡでプログラムＸが実行される前から、端末Ａと端末Ｂが通信を行っていたとする。
　図７に示す出力情報の１行目には、端末Ａにおいて発生したプログラムＸの実行という異常イベントが示されている。プログラムＸは種類特定情報に示されていないため、端末Ａにおいて発生したプログラムＸの実行という異常イベントは、第１種の異常イベントであると判定される。そのため、この異常イベントに関する出力情報が出力される。なお、第１種の異常イベントの発生前にコマンドＡやコマンドＢの異常な実行が行われたとしても、その異常な実行についての出力は行われない。
　上記プログラムＸの実行により、プログラムＸの実行が行われた端末Ａが出力対象端末として特定される。また、その発生時刻以前に端末Ａと通信していた端末Ｂも、出力対象端末として特定される。そこで出力部２０８０は、上記プログラムＸの実行という異常イベント以降に発生する各異常イベントについても、出力情報を出力する。その結果、コマンドＡやコマンドＢの異常実行についての出力情報が、ディスプレイ装置に追加で表示されていく。
　なお、出力情報の出力先は、履歴出力装置２０００に接続されているディスプレイ装置に限定されない。例えば出力部２０８０は、所定の記憶されているログファイルに対して出力情報を出力（追記）してもよい。また、履歴出力装置２０００に接続されているディスプレイ装置以外のディスプレイ装置に、出力情報が表示されるようにしてもよい。例えば履歴出力装置２０００は、他の装置に対して出力情報を送信する。その結果、当該他の装置に接続されているディスプレイ装置において、出力情報が表示される。
＜変形例＞
　履歴出力装置２０００は、別途の方法で出力対象端末をさらに増やしてもよい。例えば履歴出力装置２０００は、いずれかの出力対象端末と通信した端末１１０を、さらに出力対象端末として扱ってもよい。こうすることで、特定の異常（例えば、セキュリティ上の危険）が通信を介して伝播していく場合に、その異常の伝播を見逃さないようにすることができる。
［実施形態２］
　図８は、実施形態２の履歴出力装置２０００の概要を例示する図である。図８は、履歴出力装置２０００の動作についての理解を容易にするための概念的な説明を表す図であり、履歴出力装置２０００の動作を具体的に限定するものではない。以下で特に説明する点を除き、実施形態２の履歴出力装置２０００は、実施形態１の履歴出力装置２０００と同様の機能を有する。
　実施形態２の履歴出力装置２０００は、出力対象端末についてのみ異常イベント履歴１０が出力されるという点で、実施形態１の履歴出力装置２０００と共通する。
　一方で、実施形態２の履歴出力装置２０００は、以下の点で実施形態１の履歴出力装置２０００と異なる。まず、実施形態２の履歴出力装置２０００では、少なくとも、第１種の異常イベントが発生した端末１１０（第１端末）を出力対象端末とすればよく、その端末と通信を行っていた端末１１０（第２端末）については、出力対象端末としなくてもよい。ただし、実施形態２の履歴出力装置２０００では、或る端末１１０が出力対象端末として特定されたら、その端末１１０において発生した異常イベントに関する異常イベント履歴１０を過去に遡って出力する。すなわち、或る端末１１０が出力対象端末として特定されたら、その特定以降にその端末１１０で発生する異常イベントに関する出力情報が出力されるようになるだけでなく、その端末１１０においてその特定よりも前に発生した異常イベントに関する出力情報も出力される。
＜作用効果＞
　前述した様に、重大な異常を表す蓋然性が高いイベントだけでなく、重大な異常を表す蓋然性がある程度低いイベントについても異常イベントとして検出しておく必要がある一方で、異常イベントについて出力される情報をある程度絞り込むことが好適である。この点、本実施形態の履歴出力装置２０００によれば、端末１１０で発生した異常イベントに関する情報のうち、第１種に属さない異常イベントについての情報は、第１種の異常イベントが検出されるまで出力されない。ただし、第１種の異常イベントが端末１１０で発生したら、その発生前まで遡って、異常イベントに関する情報が出力される。よって、重大な異常を表す蓋然性がある程度低い異常イベントに関する情報は、無条件に出力されるわけでなく、重大な異常を表す蓋然性が高い異常イベントの発生に付随して出力されるようになる。
　この手法によれば、異常イベントに関する情報が無条件に出力される場合と比較し、出力される情報が適切に絞り込まれるため、異常イベントに関する情報の扱いが容易になる。そのため、重大な異常の見逃しが発生しにくくなる（すなわち、解析精度の向上）、異常イベントを解析する解析者の作業負担が軽減される、及び解析作業に要する時間が削減されるといった効果が生じる。
　なお、本実施形態の履歴出力装置２０００についても、特に効果的なケースの例として、OS の標準コマンドを使用したサイバー攻撃の解析が挙げられる。標準コマンドに起因する異常が発生したとしても、それ単体では、サイバー攻撃の一環で生じた異常であるのかどうかを判別することが難しい。しかし、サイバー攻撃を表す蓋然性が高い異常イベントが検出されたら、それ以前に発生した標準コマンドに起因する異常がサイバー攻撃に関連する蓋然性が高いと考えられる。
　そこで、本実施形態の履歴出力装置２０００において、サイバー攻撃を表す蓋然性が高い異常イベントを第１種の異常イベントとして扱うようにする。こうすることで、サーバ攻撃を表す蓋然性が高い異常イベントが発生したら、それよりも前に発生した標準コマンドに起因する異常イベントに関する情報も出力されるようになる。よって、標準コマンドに起因する異常についての情報が、適切に絞り込まれて出力されるようになる。
　以下、本実施形態の履歴出力装置２０００についてさらに詳細に説明する。
＜履歴出力装置２０００の機能構成の例＞
　実施形態２の履歴出力装置２０００の機能構成は、実施形態１の履歴出力装置２０００の構成と同様に、図２で表される。ただし、実施形態２の端末特定部２０６０は、種類判定部２０４０によって特定された異常イベントの種類が第１種である場合に、その異常イベントが発生した端末１１０を出力対象端末として特定する。また、出力部２０８０は、その特定以降に出力対象端末で発生する異常イベントに関する出力情報を出力することに加え、その特定よりも前に出力対象端末で生じた異常イベントに関する出力情報も出力する。
＜ハードウエア構成の例＞
　実施形態２の履歴出力装置２０００のハードウエア構成は、例えば、実施形態１の履歴出力装置２０００のハードウエア構成と同様に、図３で表される。ただし、実施形態２の履歴出力装置２０００のストレージデバイス１０８０には、実施形態２の履歴出力装置２０００の機能を実現するプログラムモジュールが記憶される。
＜処理の流れ＞
　図９は、実施形態２の履歴出力装置２０００によって実行される処理の流れを例示するフローチャートである。取得部２０２０は異常イベント履歴１０を取得する（Ｓ２０２）。種類判定部２０４０は、取得した異常イベント履歴１０によって表される異常イベントの種類が第１種であるか否かを判定する（Ｓ２０４）。異常イベントの種類が第１種でない場合（Ｓ２０４：ＮＯ）、図９の処理はＳ２１０に進む。異常イベントの種類が第１種である場合（Ｓ２０４：ＹＥＳ）、端末特定部２０６０は、その異常イベントが発生した端末１１０を出力対象端末として特定する（Ｓ２０６）。出力部２０８０は、出力対象端末として特定された端末１１０について、その特定よりも前にその端末１１０で生じた異常イベントに関する出力情報を出力する（Ｓ２０７）。
　出力部２０８０は、取得した異常イベント履歴１０によって表される異常イベントが出力対象端末で発生したものである場合、その異常イベントについての出力情報を出力する（Ｓ２０８）。異常イベント履歴１０によって示される異常イベントの種類が第１種である場合（Ｓ２０４：ＹＥＳ）、その異常イベントは必ず出力対象端末で発生したものであるため、出力部２０８０は、その異常イベントに関する出力情報を出力する（Ｓ２０８）。
　一方、異常イベント履歴１０によって示される異常イベントの種類が第１種でない場合（Ｓ２０４：ＮＯ）、出力部２０８０は、その異常イベントが出力対象端末で発生したものであるか否かを判定する（Ｓ２１０）。異常イベントが出力対象端末で発生したものである場合（Ｓ２１０：ＹＥＳ）、出力部２０８０は、その異常イベントについての出力情報を出力する（Ｓ２０８）。一方、異常イベントが出力対象端末で発生したものでない場合（Ｓ２１０：ＮＯ）、出力部２０８０は、その異常イベントについての出力情報を出力しない。
＜過去の異常イベントに関する出力情報を出力する条件＞
　出力部２０８０は、出力対象端末として特定された端末１１０について、その特定よりも前にその端末１１０で生じた異常イベントに関する出力情報を出力する（Ｓ２０７）。ここで、出力部２０８０は、上記特定よりも前の全ての期間で発生した異常イベントを出力対象としてもよいし、上記特定よりも前の所定期間内に発生した異常イベントのみを出力対象としてもよい。後者の場合、出力部２０８０は、出力対象端末として特定された端末１１０で発生した異常イベントに関する異常イベント履歴１０の中から、発生時刻がその特定よりも前の所定期間（その特定時刻を終点とする所定の長さの期間）内に含まれるものを特定する。そして、出力部２０８０は、特定した異常イベント履歴１０について、出力情報を出力する。
　この所定期間の長さは、全ての異常イベントで共通であってもよいし、異常イベントに応じて異なっていてもよい。後者の場合、例えば、異常イベントを発生させたコマンド等の種類に応じて、所定期間の長さを定める。そのために、コマンド等の種類に対して所定期間の長さを対応づけた情報を、予め記憶装置に記憶させておく。
　コマンド等の種類には、種々の種類を定めることができる。例えば、マルウエアの活動には、初期調査、探索活動、及び感染拡大などといった種類の活動が考えられる。そこで、コマンド等の種類として、初期調査に利用されるコマンド等、探索活動に利用されるコマンド等、及び感染拡大に利用されるコマンド等などといった種類を定めておく。そして、これらの種類の識別情報と、その種類に分類されるコマンド等の識別情報とを対応づけた情報を用意しておく。履歴出力装置２０００は、この情報を利用して、各コマンド等の種類を把握する。
　図１０は、コマンド等の種類に応じて出力対象の期間が異なるケースを例示する図である。図１０では、出力する期間が長い順に、初期調査用のコマンド等、探索活動用のコマンド等、感染拡大用のコマンド等となっている。このようにする理由は、マルウエアの活動が、初期調査の活動、探索活動、感染拡大の活動の順に行われることが多いためである。
　このようにコマンド等の種類に応じて出力対象の期間を変えることにより、過去に発生した異常イベントについての出力を適切に制限することができる。すなわち、検出された第１種の異常イベントとの関連性が高いと考えられる過去の異常イベントが適切に絞り込まれるため、検出された第１種の異常イベントとの関連性が低い異常イベントまでもが出力対象となってしまうことを防ぎつつ、検出された第１種の異常イベントとの関連性が高い異常イベントが出力対象から外れてしまうことも防ぐことで、解析精度の向上や解析作業の負担削減を実現できる。
＜所定期間の延長＞
　上記所定期間の中で異常イベントが発生していたら、その所定期間を過去に向かってさらに長くしてもよい（所定期間を延長してもよい）。図１１は、所定期間を延長するケースを例示する図である。図１１では、端末Ａにおいて、時刻 t3 で第１種の異常イベントＣが発生している。そのため、出力部２０８０は、時刻 t3 よりも過去に遡って、端末Ａで発生した異常イベントに関する出力情報の出力を行う。この例では、所定期間 P1（t2 から t3）に発生した異常イベントを出力対象とする。ここで、期間 P1 において、端末Ａで異常イベントＢが発生している。そのため、異常イベントＢに関する出力情報が出力される。
　また、期間 P1 内で異常イベントが発生していたため、さらに過去に遡って出力情報の出力が行われる。具体的には、期間 P1 の長さをさらに長くした期間 P2（t1 から t3）を対象として、出力情報の出力が行われる。例えば図１１の例では、期間 P2 において、端末Ａで異常イベントＡが発生している。そのため、異常イベントＡを表す出力情報が出力される。
　なお、期間 P2 でも異常イベントが発生しているため、期間 P2 よりもさらに過去の期間に遡って、出力情報の出力が行われてもよい（図示せず）。例えば出力部２０８０は、「遡った期間の中で異常イベントが発生していたら、さらに過去の期間まで遡る（期間の長さをさらに長くする）」という処理を繰り返す。すなわち、「遡った期間において異常イベントが発生していない」という状況になるまで、繰り返し過去の期間に遡ることとなる。ただし、遡る回数（期間の長さを延長する回数）などに上限を設けてもよい。
　以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、上記以外の様々な構成を採用することもできる。例えば、実施形態１における各出力対象端末について、実施形態２で説明したように、過去に遡った出力情報の出力が行われてもよい。すなわち、第１種の異常イベントが発生した端末と、その発生以前にその端末と通信を行った他の端末とのそれぞれについて、過去（その発生よりも前）に発生した異常イベントについての出力情報が出力されてもよい。
　上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
１．　端末において発生した異常イベントを表す異常イベント履歴を取得する取得部と、
　前記取得した前記異常イベント履歴が表す前記異常イベントの種類が所定の種類であるか否かを判定する種類判定部と、
　前記異常イベントの種類が前記所定の種類である場合、その異常イベントが発生した端末と、その異常イベントが発生した時点以前にその端末と通信した他の端末とを、出力対象端末として特定する端末特定部と、
　前記取得した異常イベント履歴によって表される前記異常イベントが前記出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力部と、を有する、履歴出力装置。
２．　前記所定の種類の異常イベントは、安全性が担保されていないプログラム又はコマンドの実行によって生じた異常なイベントである、１．に記載の履歴出力装置。
３．　安全性が担保されていないプログラムは、オペレーティングシステムと一緒にインストールされないプログラム、認証されていないプログラム、及びそのプログラムを利用している端末が所定数若しくは所定割合以下であるプログラムのいずれか１つ以上であり、
　安全性が担保されていないコマンドは、安全性が担保されていないプログラムによって提供されるコマンドである、１．又は２．に記載の履歴出力装置。
４．　前記端末特定部は、前記出力対象端末として特定されている端末が他の端末と通信したら、当該他の端末をさらに前記出力対象端末として特定する、１．乃至３．いずれか一つに記載の履歴出力装置。
５．　前記出力部は、或る端末が前記出力対象端末として特定されたら、その特定よりも前にその端末で生じた異常イベントに関する出力情報をさらに出力する、１．乃至４．いずれか一つに記載の履歴出力装置。
６．　端末において発生した異常イベントを表す異常イベント履歴を取得する取得部と、
　前記取得した前記異常イベント履歴が表す前記異常イベントの種類が所定の種類であるか否かを判定する種類判定部と、
　前記異常イベントの種類が前記所定の種類である場合、その異常イベントが発生した端末を出力対象端末として特定する端末特定部と、
　前記取得した異常イベント履歴によって表される前記異常イベントが前記出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力部と、を有し、
　前記出力部は、或る端末が前記出力対象端末として特定されたら、その特定よりも前にその端末で生じた異常イベントに関する出力情報をさらに出力する、履歴出力装置。
７．　前記出力部は、或る端末が前記出力対象端末として特定されたら、その特定よりも前の第１所定期間にその端末で生じた異常イベントを表す前記異常イベント履歴をさらに出力する、６．に記載の履歴出力装置。
８．　前記第１所定期間の長さは、異常イベントを発生させたプログラム又はコマンドの種類に応じて異なる、７．に記載の履歴出力装置。
９．　前記出力部は、前記第１所定期間に前記端末で異常イベントが発生していたら、前記第１所定期間よりも長い第２所定期間にその端末で生じた異常イベントに関する出力情報をさらに出力する、７．又は８．に記載の履歴出力装置。
１０．　コンピュータによって実行される制御方法であって、
　端末において発生した異常イベントを表す異常イベント履歴を取得する取得ステップと、
　前記取得した前記異常イベント履歴が表す前記異常イベントの種類が所定の種類であるか否かを判定する種類判定ステップと、
　前記異常イベントの種類が前記所定の種類である場合、その異常イベントが発生した端末と、その異常イベントが発生した時点以前にその端末と通信した他の端末とを、出力対象端末として特定する端末特定ステップと、
　前記取得した異常イベント履歴によって表される前記異常イベントが前記出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力ステップと、を有する、制御方法。
１１．　前記所定の種類の異常イベントは、安全性が担保されていないプログラム又はコマンドの実行によって生じた異常なイベントである、１０．に記載の制御方法。
１２．　安全性が担保されていないプログラムは、オペレーティングシステムと一緒にインストールされないプログラム、認証されていないプログラム、及びそのプログラムを利用している端末が所定数若しくは所定割合以下であるプログラムのいずれか１つ以上であり、
　安全性が担保されていないコマンドは、安全性が担保されていないプログラムによって提供されるコマンドである、１０．又は１１．に記載の制御方法。
１３．　前記端末特定ステップにおいて、前記出力対象端末として特定されている端末が他の端末と通信したら、当該他の端末をさらに前記出力対象端末として特定する、１０．乃至１２．いずれか一つに記載の制御方法。
１４．　前記出力ステップにおいて、或る端末が前記出力対象端末として特定されたら、その特定よりも前にその端末で生じた異常イベントに関する出力情報をさらに出力する、１０．乃至１３．いずれか一つに記載の制御方法。
１５．　コンピュータによって実行される制御方法であって、
　端末において発生した異常イベントを表す異常イベント履歴を取得する取得ステップと、
　前記取得した前記異常イベント履歴が表す前記異常イベントの種類が所定の種類であるか否かを判定する種類判定ステップと、
　前記異常イベントの種類が前記所定の種類である場合、その異常イベントが発生した端末を出力対象端末として特定する端末特定ステップと、
　前記取得した異常イベント履歴によって表される前記異常イベントが前記出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力ステップと、を有し、
　前記出力ステップにおいて、或る端末が前記出力対象端末として特定されたら、その特定よりも前にその端末で生じた異常イベントに関する出力情報をさらに出力する、制御方法。
１６．　前記出力ステップにおいて、或る端末が前記出力対象端末として特定されたら、その特定よりも前の第１所定期間にその端末で生じた異常イベントを表す前記異常イベント履歴をさらに出力する、１５．に記載の制御方法。
１７．　前記第１所定期間の長さは、異常イベントを発生させたプログラム又はコマンドの種類に応じて異なる、１６．に記載の制御方法。
１８．　前記出力ステップにおいて、前記第１所定期間に前記端末で異常イベントが発生していたら、前記第１所定期間よりも長い第２所定期間にその端末で生じた異常イベントに関する出力情報をさらに出力する、１６．又は１７．に記載の制御方法。
１９．　１０．乃至１８．いずれか一つに記載の制御方法の各ステップをコンピュータに実行させるプログラム。

Claims (19)

  1. 　端末において発生した異常イベントを表す異常イベント履歴を取得する取得部と、
    　前記取得した前記異常イベント履歴が表す前記異常イベントの種類が所定の種類であるか否かを判定する種類判定部と、
    　前記異常イベントの種類が前記所定の種類である場合、その異常イベントが発生した端末と、その異常イベントが発生した時点以前にその端末と通信した他の端末とを、出力対象端末として特定する端末特定部と、
    　前記取得した異常イベント履歴によって表される前記異常イベントが前記出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力部と、を有する、履歴出力装置。
  2. 　前記所定の種類の異常イベントは、安全性が担保されていないプログラム又はコマンドの実行によって生じた異常なイベントである、請求項１に記載の履歴出力装置。
  3. 　安全性が担保されていないプログラムは、オペレーティングシステムと一緒にインストールされないプログラム、認証されていないプログラム、及びそのプログラムを利用している端末が所定数若しくは所定割合以下であるプログラムのいずれか１つ以上であり、
    　安全性が担保されていないコマンドは、安全性が担保されていないプログラムによって提供されるコマンドである、請求項１又は２に記載の履歴出力装置。
  4. 　前記端末特定部は、前記出力対象端末として特定されている端末が他の端末と通信したら、当該他の端末をさらに前記出力対象端末として特定する、請求項１乃至３いずれか一項に記載の履歴出力装置。
  5. 　前記出力部は、或る端末が前記出力対象端末として特定されたら、その特定よりも前にその端末で生じた異常イベントに関する出力情報をさらに出力する、請求項１乃至４いずれか一項に記載の履歴出力装置。
  6. 　端末において発生した異常イベントを表す異常イベント履歴を取得する取得部と、
    　前記取得した前記異常イベント履歴が表す前記異常イベントの種類が所定の種類であるか否かを判定する種類判定部と、
    　前記異常イベントの種類が前記所定の種類である場合、その異常イベントが発生した端末を出力対象端末として特定する端末特定部と、
    　前記取得した異常イベント履歴によって表される前記異常イベントが前記出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力部と、を有し、
    　前記出力部は、或る端末が前記出力対象端末として特定されたら、その特定よりも前にその端末で生じた異常イベントに関する出力情報をさらに出力する、履歴出力装置。
  7. 　前記出力部は、或る端末が前記出力対象端末として特定されたら、その特定よりも前の第１所定期間にその端末で生じた異常イベントを表す前記異常イベント履歴をさらに出力する、請求項６に記載の履歴出力装置。
  8. 　前記第１所定期間の長さは、異常イベントを発生させたプログラム又はコマンドの種類に応じて異なる、請求項７に記載の履歴出力装置。
  9. 　前記出力部は、前記第１所定期間に前記端末で異常イベントが発生していたら、前記第１所定期間よりも長い第２所定期間にその端末で生じた異常イベントに関する出力情報をさらに出力する、請求項７又は８に記載の履歴出力装置。
  10. 　コンピュータによって実行される制御方法であって、
    　端末において発生した異常イベントを表す異常イベント履歴を取得する取得ステップと、
    　前記取得した前記異常イベント履歴が表す前記異常イベントの種類が所定の種類であるか否かを判定する種類判定ステップと、
    　前記異常イベントの種類が前記所定の種類である場合、その異常イベントが発生した端末と、その異常イベントが発生した時点以前にその端末と通信した他の端末とを、出力対象端末として特定する端末特定ステップと、
    　前記取得した異常イベント履歴によって表される前記異常イベントが前記出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力ステップと、を有する、制御方法。
  11. 　前記所定の種類の異常イベントは、安全性が担保されていないプログラム又はコマンドの実行によって生じた異常なイベントである、請求項１０に記載の制御方法。
  12. 　安全性が担保されていないプログラムは、オペレーティングシステムと一緒にインストールされないプログラム、認証されていないプログラム、及びそのプログラムを利用している端末が所定数若しくは所定割合以下であるプログラムのいずれか１つ以上であり、
    　安全性が担保されていないコマンドは、安全性が担保されていないプログラムによって提供されるコマンドである、請求項１０又は１１に記載の制御方法。
  13. 　前記端末特定ステップにおいて、前記出力対象端末として特定されている端末が他の端末と通信したら、当該他の端末をさらに前記出力対象端末として特定する、請求項１０乃至１２いずれか一項に記載の制御方法。
  14. 　前記出力ステップにおいて、或る端末が前記出力対象端末として特定されたら、その特定よりも前にその端末で生じた異常イベントに関する出力情報をさらに出力する、請求項１０乃至１３いずれか一項に記載の制御方法。
  15. 　コンピュータによって実行される制御方法であって、
    　端末において発生した異常イベントを表す異常イベント履歴を取得する取得ステップと、
    　前記取得した前記異常イベント履歴が表す前記異常イベントの種類が所定の種類であるか否かを判定する種類判定ステップと、
    　前記異常イベントの種類が前記所定の種類である場合、その異常イベントが発生した端末を出力対象端末として特定する端末特定ステップと、
    　前記取得した異常イベント履歴によって表される前記異常イベントが前記出力対象端末で発生したものである場合、その異常イベントに関する出力情報を出力する出力ステップと、を有し、
    　前記出力ステップにおいて、或る端末が前記出力対象端末として特定されたら、その特定よりも前にその端末で生じた異常イベントに関する出力情報をさらに出力する、制御方法。
  16. 　前記出力ステップにおいて、或る端末が前記出力対象端末として特定されたら、その特定よりも前の第１所定期間にその端末で生じた異常イベントを表す前記異常イベント履歴をさらに出力する、請求項１５に記載の制御方法。
  17. 　前記第１所定期間の長さは、異常イベントを発生させたプログラム又はコマンドの種類に応じて異なる、請求項１６に記載の制御方法。
  18. 　前記出力ステップにおいて、前記第１所定期間に前記端末で異常イベントが発生していたら、前記第１所定期間よりも長い第２所定期間にその端末で生じた異常イベントに関する出力情報をさらに出力する、請求項１６又は１７に記載の制御方法。
  19. 　請求項１０乃至１８いずれか一項に記載の制御方法の各ステップをコンピュータに実行させるプログラム。
PCT/JP2019/006226 2019-02-20 2019-02-20 履歴出力装置、制御方法、及びプログラム WO2020170345A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US17/431,508 US20220012345A1 (en) 2019-02-20 2019-02-20 History output apparatus, control method, and program
PCT/JP2019/006226 WO2020170345A1 (ja) 2019-02-20 2019-02-20 履歴出力装置、制御方法、及びプログラム
JP2021501189A JP7211482B2 (ja) 2019-02-20 2019-02-20 履歴出力装置、制御方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/006226 WO2020170345A1 (ja) 2019-02-20 2019-02-20 履歴出力装置、制御方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2020170345A1 true WO2020170345A1 (ja) 2020-08-27

Family

ID=72144099

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/006226 WO2020170345A1 (ja) 2019-02-20 2019-02-20 履歴出力装置、制御方法、及びプログラム

Country Status (3)

Country Link
US (1) US20220012345A1 (ja)
JP (1) JP7211482B2 (ja)
WO (1) WO2020170345A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008152541A (ja) * 2006-12-18 2008-07-03 Ricoh Printing Systems Ltd 印刷装置及びログデータ管理方法
JP2011034507A (ja) * 2009-08-05 2011-02-17 Fujitsu Ltd 動作履歴収集装置、動作履歴収集方法およびプログラム
JP2013191070A (ja) * 2012-03-14 2013-09-26 Nomura Research Institute Ltd 監視装置
JP2018160170A (ja) * 2017-03-23 2018-10-11 富士通株式会社 出力プログラム、情報処理装置、出力方法、生成プログラム、及び生成方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4705961B2 (ja) * 2008-01-25 2011-06-22 Ｓｋｙ株式会社 ウィルス被害範囲予測システム
US9418222B1 (en) * 2013-09-27 2016-08-16 Symantec Corporation Techniques for detecting advanced security threats
US9571519B2 (en) * 2014-09-29 2017-02-14 Juniper Networks, Inc. Targeted attack discovery

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008152541A (ja) * 2006-12-18 2008-07-03 Ricoh Printing Systems Ltd 印刷装置及びログデータ管理方法
JP2011034507A (ja) * 2009-08-05 2011-02-17 Fujitsu Ltd 動作履歴収集装置、動作履歴収集方法およびプログラム
JP2013191070A (ja) * 2012-03-14 2013-09-26 Nomura Research Institute Ltd 監視装置
JP2018160170A (ja) * 2017-03-23 2018-10-11 富士通株式会社 出力プログラム、情報処理装置、出力方法、生成プログラム、及び生成方法

Also Published As

Publication number Publication date
JP7211482B2 (ja) 2023-01-24
US20220012345A1 (en) 2022-01-13
JPWO2020170345A1 (ja) 2021-12-02

Similar Documents

Publication Publication Date Title
US10701091B1 (en) System and method for verifying a cyberthreat
JP5972401B2 (ja) 攻撃分析システム及び連携装置及び攻撃分析連携方法及びプログラム
US8739287B1 (en) Determining a security status of potentially malicious files
Garcia et al. Obfuscation-resilient, efficient, and accurate detection and family identification of android malware
CN112003838B (zh) 网络威胁的检测方法、装置、电子装置和存储介质
US20150047034A1 (en) Composite analysis of executable content across enterprise network
US10073980B1 (en) System for assuring security of sensitive data on a host
WO2019144548A1 (zh) 安全测试方法、装置、计算机设备和存储介质
KR102098064B1 (ko) 로그 분석을 기반으로 하는 보안 모니터링 방법, 장치 및 시스템
WO2016121348A1 (ja) マルウェア対策装置、マルウェア対策システム、マルウェア対策方法、及び、マルウェア対策プログラムが格納された記録媒体
US20170277887A1 (en) Information processing apparatus, information processing method, and computer readable medium
KR101359378B1 (ko) 보안 무결성 검사 장치와 방법
CN109062965B (zh) 大数据分析系统、服务器、数据处理方法和存储介质
KR102338998B1 (ko) 로그 무결성 검사 및 이를 통한 로그 위변조 행위 증빙 시스템 및 그 방법
Feng et al. Selecting critical data flows in Android applications for abnormal behavior detection
WO2020170345A1 (ja) 履歴出力装置、制御方法、及びプログラム
CN111092867A (zh) Ssh后门账号检测方法、装置及电子设备和存储介质
CN116226865A (zh) 云原生应用的安全检测方法、装置、服务器、介质及产品
JP2020004127A (ja) コンピュータ資産管理システムおよびコンピュータ資産管理方法
JP6258189B2 (ja) 特定装置、特定方法および特定プログラム
JP5386015B1 (ja) バグ検出装置およびバグ検出方法
KR102535251B1 (ko) 전자 장치의 사이버 보안 리포트 생성 방법
WO2022137883A1 (ja) 攻撃情報生成装置、制御方法、及び非一時的なコンピュータ可読媒体
CN116432240B (zh) 内网终端敏感数据的检测方法、装置、服务器及系统
CN116432208B (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: 19915852

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021501189

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19915852

Country of ref document: EP

Kind code of ref document: A1