Abstract:
The present invention relates to an attack observation apparatus being a simulation environment where a malicious program such as malware created by an attacker is run, the simulation environment being built for observing the behavior and attack scheme of the malicious program. 
     The attack observation apparatus includes a low-interactive simulation environment to execute on a terminal a predetermined response to communication coming from the malware, a high-interactive simulation environment to execute a response to the communication coming from the malware with using a virtual machine which simulates the terminal, and a communication management part to monitor an execution state of the low-interactive simulation environment with respect to the communication coming from the malware and switch the communication coming from the malware to the high-interactive simulation environment depending on the execution state of the low-interactive simulation environment.

Description:
TECHNICAL FIELD 
       [0001]    The present invention relates to an attack observation apparatus being a simulation environment where a malicious program such as malware created by an attacker is run, the simulation environment being built for observing the behavior and attack scheme of the malicious program. 
       BACKGROUND ART 
       [0002]    Conventionally, in a simulation network system where a malicious program such as malware created by an attacker is run, the malicious network system being built for observing the behavior and attack scheme of the malicious program, a scheme (to be referred to as simulation environment hereinafter) of simulating a terminal or server which functions in the network system is known. For example, a scheme as described in Patent Literature 1 is known. According to this scheme, simulation is performed by a simulation program which receives communication data as input transmitted from a malware-infected terminal, determines response data in accordance with the contents of the communication data, and sends back the response data. Such a simulation environment will be called a low-interactive honeypot (an example of a low-interactive simulation environment) hereinafter. 
         [0003]    A scheme as described in Patent Literature 2 and Non-Patent Literature 1 is also known. According to this scheme, a virtual machine is operated in a virtualized environment that uses a commercially available product, and this virtualized environment is used as a simulation environment. Such a simulation environment will be referred to as a high-interactive honeypot (an example of a high-interactive simulation environment) hereinafter. 
       CITATION LIST 
     Patent Literature 
       [0000]    
       
         Patent Literature 1: JP 2009-181335 
         Patent Literature 2: JP 2012-212391 
       
     
       Non-Patent Literature 
       [0000]    
       
         Non-Patent Literature 1: Takahiro Kasama et al, “Malware Sandbox Analysis System with Accumulated Server Responses Collected by Dummy Clients”, International Processing Society of Japan, anti Malware engineering Workshop 2009 (MWS2009) A7-2, (October 2009). 
       
     
       SUMMARY OF INVENTION 
     Technical Problem 
       [0007]    In a low-interactive honeypot, each simulated terminal and each server return a response to the contents of a received communication packet, in accordance with a method predetermined by a program. Since it is only necessary to return the determined response to the packet transmitted from malware, advantageous can be obtained that the processing load is small and that large numbers of terminals and servers can be simulated simultaneously. However, a problem exists that when a packet with contents (for example, an unknown attack) that cannot be processed by the program is received, the terminals and servers cannot respond in the same manner as when an actual packet is received. Another problem also arises that in face of an attack accompanying malware infection, it is impossible to run the malware in the simulation environment. 
         [0008]    Meanwhile, a high-interactive honeypot can cope with the above-mentioned issue of unknown attack and malware infection. However, a simulation environment that uses high-interactive honeypots requires resources (a CPU, a memory, an HHD, and so on) equivalent to the actual resources for simulating one terminal or one server. When, for example, the entire business system is to be simulated, a large number of terminals and a large number of servers must be prepared. 
         [0009]    As described above, in the prior art, a large-scale system cannot be simulated elaborately. 
         [0010]    The present invention has been made to solve the above problems, and has as its object to implement an attack observation apparatus capable of elaborate simulation with a few computer resources even in a large-scale network system such as a business system. 
       Solution to Problem 
       [0011]    In order to solve the problems described above, an attack observation apparatus according to the present invention is an attack observation apparatus being an environment where malware is run and an attack of the malware is observed, and includes: a low-interactive simulation environment to execute on a terminal a predetermined response to communication coming from the malware; a high-interactive simulation environment to execute a response to the communication coming from the malware with using a virtual machine which simulates the terminal; and a communication management part to monitor an execution state of the low-interactive simulation environment with respect to the communication coming from the malware and switch the communication coming from the malware to the high-interactive simulation environment depending on the execution state of the low-interactive simulation environment. 
       Advantageous Effects of Invention 
       [0012]    According to the present invention, communication is processed initially by a low-interactive honeypot. Communication is switched to a low-interactive honeypot only where necessary, so that use of the high-interactive honeypot can be reduced. Hence, an effect can be obtained that an attack observation apparatus simulating a large-scale system can be implemented with a few computer resources. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0013]      FIG. 1  is a configuration diagram illustrating one configuration example of an attack observation apparatus according to Embodiment 1. 
           [0014]      FIG. 2  is a diagram describing configurations of a communication management part  112  and network  111  in detail. 
           [0015]      FIG. 3  is a diagram describing a configuration of a low-interactive honeypot part  106  in detail. 
           [0016]      FIG. 4  is a diagram illustrating an example of honeypot execution state data stored in a honeypot execution state management part  115 . 
           [0017]      FIG. 5  is a diagram illustrating an example of a terminal state transition scenario stored in a terminal state transition scenario accumulation part  110 . 
           [0018]      FIG. 6  is a diagram illustrating an example of a high-interactive honeypot execution command definition table stored in a high-interactive honeypot execution command accumulation part  116 . 
           [0019]      FIG. 7  is a diagram illustrating a configuration example of a terminal state accumulation part  109 . 
           [0020]      FIG. 8  is a sequence diagram illustrating communication the communication management part  112  carries out with other terminals and a process executed in the communication management part  112 . 
           [0021]      FIG. 9  is a diagram illustrating an example of a state transition of a communication protocol. 
           [0022]      FIG. 10  is a flowchart illustrating an operation flow of a low-interactive honeypot  802 . 
           [0023]      FIG. 11  is a flowchart illustrating an operation flow in a communication processing program  303 . 
           [0024]      FIG. 12  is a flowchart illustrating an operation flow of a terminal state management part  108 . 
           [0025]      FIG. 13  is a diagram illustrating examples of a command that can be executed by a communication management part  112 . 
           [0026]      FIG. 14  is a flowchart illustrating an operation flow of a terminal state transition scenario execution part  107 . 
           [0027]      FIG. 15  is a diagram illustrating an example of a system configuration of a periphery of a communication management part  112  according to Embodiment 2. 
           [0028]      FIG. 16  is a diagram illustrating an example of a system configuration of a periphery of a communication management part  112  according to Embodiment 3. 
           [0029]      FIG. 17  is a diagram illustrating an example of an ARP response packet. 
           [0030]      FIG. 18  is a diagram illustrating an example of a system configuration of a periphery of a communication management part  112  according to Embodiment 4. 
           [0031]      FIG. 19  is a diagram illustrating an example of a configuration of a low-interactive honeypot part  106  according to Embodiment 4. 
           [0032]      FIG. 20  is a flowchart illustrating an operation flow of the low-interactive honeypot part  106  according to Embodiment 4. 
           [0033]      FIG. 21  is a flowchart illustrating an operation flow of a communication processing program according to Embodiment 4. 
           [0034]      FIG. 22  is a diagram illustrating an example of a system configuration of a periphery of a communication management part  112  according to Embodiment 5. 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
     Embodiment 1 
       [0035]      FIG. 1  is a configuration diagram illustrating a configuration example of an attack observation apparatus according to Embodiment 1. 
         [0036]    Referring to  FIG. 1 , a honeypot system  101  being an attack observation apparatus is constituted of a high-interactive honeypot part  103  being a high-interactive simulation environment, a low-interactive honeypot part  106  being a low-interactive simulation environment, a terminal state transition scenario execution part  107 , a terminal state management part  108 , a terminal state accumulation part  109 , a terminal state transition scenario accumulation part  110 , a communication management part  112 , a honeypot execution state management part  115  being an execution state management part, and a high-interactive honeypot execution command accumulation part  116  being an execution command accumulation part. The high-interactive honeypot part  103  and the low-interactive honeypot part  106  will be collectively called the honeypot hereinafter. 
         [0037]    The high-interactive honeypot part  103  houses virtual machines  104  serving as high-interactive honeypots and a virtual machine execution environment  105  which executes the virtual machines  104 . The low-interactive honeypot part  106  operates as a low-interactive honeypot. The terminal state transition scenario execution part  107  instructs to the terminal state management part  108  a state change of a file and the like occurring spontaneously in each terminal simulated in the honeypot system  101 . The terminal state management part  108  acquires and/or changes the state of the file and the like in each terminal in accordance with a command from the terminal state transition scenario execution part  107  or low-interactive honeypot part  106 . The terminal state transition scenario accumulation part  110  accumulates a terminal state transition scenario indicating a scenario for the state transition of each terminal. The communication management part  112  relays and/or manages communication between honeypots, or between the honeypots and an external network  102 . The honeypot execution state management part  115  manages honeypot execution state data indicating the present execution state of the honeypots. The high-interactive honeypot execution command accumulation part  116  accumulates a high-interactive honeypot execution command definition table that defines a command and so on started when the terminal state transition scenario is reproduced on the high-interactive honeypot part  103 . The communication management part  112  is connected to the virtual machines  104  via a network  111  and connected to the low-interactive honeypot part  106  via a network  113 . The communication management part  112  is also connected to the external network  102  via a network  114 . 
         [0038]      FIG. 2  is a diagram describing configurations of the communication management part  112  and network  111  in detail. 
         [0039]    Referring to  FIG. 2 , the communication management part  112  is constituted of a packet reception part  207  which receives a packet to the communication management part  112 , a packet transmission part  208  for transmitting the packet from the communication management part  112 , an ARP (Address Resolution Protocol) response part  209  which returns a spoofed response to an ARP, a gateway part  210  which relays communication, and a communication restoring data accumulation part  211  accumulating data necessary for reconstructing a pre-transition communication state on a post-transition simulated terminal in execution state transition of the simulated terminal. The communication management part  112  is connected to the low-interactive honeypot part  106  via a network  113  and connected to the outside of the honeypot system via a network  114 . 
         [0040]    In  FIG. 2 , the network  111  of  FIG. 1  is constituted of a virtual switch  205  in the high-interactive honeypot part  103 , VLANs (Virtual Local Area Networks)  203  to  204  built between respective virtual machines  201  to  202  and the virtual switch  205 , and a network  206  which trunk-connects the virtual switch  205  and the communication management part  112 . 
         [0041]      FIG. 3  is a diagram describing a configuration of a low-interactive honeypot part  106  in detail. 
         [0042]    Referring to  FIG. 3 , the low-interactive honeypot part  106  is provided with a communication processing program execution part  301  and a communication processing program accumulation part  302 . The communication processing program execution part  301  executes a communication processing program which processes common communication protocols such as TCP/IP (Transmission Control Protocol/Internet Protocol) and TLS (Transport Layer Security), and application layer communication. The communication processing program accumulation part  302  stores at least one communication processing program  303 . Each communication processing program  303  is identifiable by its program name. 
         [0043]      FIG. 4  is a diagram illustrating an example of honeypot execution state data stored in the honeypot execution state management part  115 . 
         [0044]    Referring to  FIG. 4 , the honeypot execution state data is constituted of a terminal ID  401 , a communication processing program name  402 , a file system name  403  an IP address  404 , an execution state  405 , and a VLAN ID  406 . 
         [0045]      FIG. 5  is a diagram illustrating an example of the terminal state transition scenario stored in the terminal state transition scenario accumulation part  110 . 
         [0046]    Referring to  FIG. 5 , the terminal state transition scenario is constituted of a scenario execution time  501 , a terminal ID  502  indicating the ID of a simulated terminal for which a scenario is to be carried out, and a command  503  which is to be carried out for causing a state transition. 
         [0047]      FIG. 6  is a diagram illustrating an example of the high-interactive honeypot execution command definition table stored in the high-interactive honeypot execution command accumulation part  116 . 
         [0048]    Referring to  FIG. 6 , the high-interactive honeypot execution command definition table is constituted of a command name  601 , a terminal ID  602  of a terminal for which a command is to be carried out, a started program  603  started when carrying out a command, and a user ID  604  of a user having a user privilege for carrying out an operation. As indicated by  605 , it is possible to specify for the started program  603  a variable ($1 in the case of  FIG. 6 ) that looks up an argument given to the command of the started program  603 . 
         [0049]      FIG. 7  is a diagram illustrating a configuration example of the terminal state accumulation part  109 . 
         [0050]    Referring to  FIG. 7 , virtual machine images  701  to  702  of the respective simulated terminals are housed in the terminal state accumulation part  109 . A virtual machine image stores as a file the image of the file system of a corresponding simulated terminal. This method of storing the image of a file system, as a file can be implemented easily by, for example, reading the sectors in the HDD sequentially and storing them in a file, as with a dd command of a basic OS, for example. 
         [0051]    The operation of the attack observation apparatus according to Embodiment 1 will be described. 
         [0052]    First, the outline of the overall operation will be described. A terminal simulated in the honeypot system  101  according to Embodiment 1 transitions between two execution states, namely, a low-interactive honeypot state and a high-interactive honeypot state. 
         [0053]    When communication addressed to a target terminal to be simulated in this system occurs, the communication management part  112  relays communication data to the low-interactive honeypot part  106  or to the virtual machines  104  in the high-interactive honeypot part  103  depending on the execution state of the target terminal. 
         [0054]    The low-interactive honeypot part  106  returns a response to the transmitted communication data in accordance with the communication processing program  303 . If the communication processing program  303  determines that switching to a high-interactive honeypot is necessary because, for example, communication for which a processing method is not defined has arrived, then a virtual machine that simulates the address terminal is booted in the high-interactive honeypot part  103 , and the execution state of the addressed terminal transitions to the high-interactive honeypot state. Subsequent communication is transferred to the virtual machine by the communication management part  112 . 
         [0055]    The terminal state transition scenario execution part  107  carries out the spontaneous state change in each simulated terminal in accordance with the scenario by operating the terminal state management part  108 . A spontaneous state change signifies a state change occurring irrespective of the communication to the simulated terminal, that is, a file change. The purpose of the spontaneous state change is to make the state look as if an authorized user were acting on the simulated terminal. 
         [0056]    The operation in detail of each part of the attack observation apparatus will now be described. To begin with, the operation of the communication management part  112  will be described with referring to  FIG. 8 . 
         [0057]      FIG. 8  is a sequence diagram illustrating communication the communication management part  112  carries out with other terminals and a process executed in the communication management part  112 . 
         [0058]    Referring to  FIG. 8 , first, when a terminal 1 ( 801 ) is to communicate with a simulated terminal (having an IP address of IP2), the terminal 1 transmits a connection request to IP2 ( 803 ) as a destination. The connection request is received by the packet reception part  207  of the communication management part  112  and supplied to the gateway part  210 . The gateway part  210  establishes the connection with the sender. Honeypot execution state data ( FIG. 4 ) in the honeypot execution state management part  115  is searched for with using the destination IP address as a key. When it is confirmed that the terminal 1 is a simulated terminal, the communication management part  112  sends a connection request, and the connection is established ( 804 ). Namely, connection from a terminal to another terminal is terminated by the gateway part  210  in the communication management part  112 , providing two connections. Not only a TCP but also a session such as a TLS (Transport Layer Security), which is built by a higher-level protocol is terminated by the communication management part  112 . 
         [0059]    After that, the terminal 1 ( 801 ) and a low-interactive honeypot ( 802 ) communicate with each other as the communication is being relayed by the communication management part  112  ( 805  to  815 ). The communication management part  112 , while relaying the communication, monitors the communication state change of the application layer of the communication it relays, and stores in the communication restoring data accumulation part  211  the communication of when a state transition occurs. 
         [0060]    For example, suppose that the communication illustrated in  FIG. 8  relays an application layer which that causes a state transition as indicated by the state transition diagram illustrated in  FIG. 9 . 
         [0061]      FIG. 9  is a diagram illustrating an example of a state transition of a communication protocol. 
         [0062]    In the case of the state transition of  FIG. 9 , it is seen that at the time a log-in ( 904 ) communication occurs, the communication state transitions from connection complete ( 903 ) to log-in complete ( 905 ). Therefore, after log-in is successful at  808 , log-in data is stored in the communication restoring data accumulation part  211  at  809 . A command relayed after the log-in will not be stored in the communication restoring data accumulation part  211  because this command corresponds to transition of  906  in  FIG. 9  and does not cause a state transition. 
         [0063]    Subsequently, communication with a command #n is transferred to the low-interactive honeypot  802  at  815 , and after that a switching request  816  for a honeypot is sent from the low-interactive honeypot  802 . Then, the communication management part  112  changes the execution state of the simulated terminal in the honeypot execution state data ( FIG. 4 ) in the honeypot execution state management part  115  to the high-interactive honeypot state ( 817 ). The communication management part  112  boots a new virtual machine in the high-interactive honeypot part  103  and connects the high-interactive honeypot part  103  to a virtual switch with using a VLAN independent of the other virtual machines ( 819 ). 
         [0064]    After that, the communication management part  112  connects to the booted virtual machine ( 820 ). In order to restore the communication state to the state of communication that has been carried out between the low-interactive honeypot  802  and the terminal 1 ( 801 ) until immediately recently, the communication management part  112  transmits a log-in request ( 821 ) with using the log-in data which has been stored in the communication restoring data accumulation part  211 , and receives a log-in response ( 822 ). Note that communication state restoration of  821  to  822  is to restore the communication state of immediately before switching the honeypot and accordingly does not deal with a command #1 to a command “n−1 as a restoration target. Then, the communication management part  112  transmits a command #n ( 823 ) that has been transmitted to the low-interactive honeypot  802  the last time, and transfers ( 825 ) a command #n result ( 824 ) being a response to the command #n ( 823 ), to the terminal 1 ( 801 ). 
         [0065]    A proxy server and the like are known as examples of an apparatus arranged between two terminals, for building separate connections to the two terminals respectively and transferring data between the two connections in this manner. Embodiment 1 is different from such a known embodiment in the following respect. Namely, the communication management part  112  in Embodiment 1 spoofs an IP address so that none of the two terminals can identify the communication management part  112  as being a communication party. This operation is implemented when, at the start of communication with each simulated terminal, the ARP response part  209  of the communication management part  112  returns the MAC (Media Access Control) address of the communication management part  112  for an ARP (Address Resolution Protocol) request from the communication terminal to broadcast the MAC address of the communication party. 
         [0066]    In Embodiment 1, the packet transmission part  208  of the communication management part  112  must determine on which network a packet should be supplied. For this purpose, the packet transmission part  208  looks up the honeypot execution state data stored in the honeypot execution state management part  115  to check the execution state of a simulated terminal corresponding to the destination IP. If the execution state is low-interactive, the packet transmission part  208  transmits the packet onto a network ( 113  in the case of  FIG. 2 ) connected to the low-interactive honeypot  802 . If the execution state is high-interactive, the packet transmission part  208  acquires a VLAN ID of the VLAN to which the simulated terminal is connected. The packet transmission part  208  stores the VLAN ID in an L2 frame (tag VLAN) as a tag and transmits the packet, so that the packet arrives at the corresponding VLAN. 
         [0067]    The operation of the low-interactive honeypot  802  will be described with referring to  FIG. 10 . 
         [0068]      FIG. 10  is a flowchart illustrating an operation flow of the low-interactive honeypot  802 . 
         [0069]    First, in step S 101 , the low-interactive honeypot  802  waits for a packet to arrive. 
         [0070]    Then, in step S 102 , when a packet arrives at the low-interactive honeypot  802 , the low-interactive honeypot  802  acquires a destination IP. 
         [0071]    Then, in step S 103 , the low-interactive honeypot  802  searches for honeypot execution state data stored in the honeypot execution state management part  115  with using the acquired destination IP as a key, and acquires a terminal ID and a communication processing program name which are registered in the honeypot execution state data. 
         [0072]    Then, in step S 104 , the low-interactive honeypot  802  executes the communication processing program  303  by giving the acquired terminal ID to the communication processing program  303  as a parameter. 
         [0073]    The process in the communication processing program  303  changes when seen in detail depending on the protocol simulated by the communication processing program  303 , and flows as illustrated by the flowchart of  FIG. 11 . 
         [0074]      FIG. 11  is a flowchart illustrating an operation flow in the communication processing program  303 . 
         [0075]    First, in step S 201 , the communication processing program  303  receives the data of the arriving packet, from the communication processing program execution part  301 . 
         [0076]    Then, in step S 202 , the communication processing program  303  analyzes the received data and determines whether a response should be returned, the process should be ended, or switching to a high-interactive honeypot should be made 
         [0077]    Then, in step S 203 , if the result of the data analysis by the communication processing program  303  in step S 202  indicates that switching to a high-interactive honeypot is needed, the flow branches to step S 204  and “switching request” is set in the execution result. The program ends. 
         [0078]    Then, in step S 205 , if it is determined to end the process based on the result of the data analysis by the communication processing program  303  in step S 202 , the flow branches to step S 206  and “end” is set in the execution result. The program ends. If the result of the data analysis in step S 202  indicates that a response should be returned, the flow branches to step S 207 . 
         [0079]    Then, in step S 207 , the communication processing program  303  checks whether or not look-up or change of the terminal state is necessary in creating a response to the received data. Such a need arises when, for example, the contents of some file in the simulated terminal need be stored in the response, or when the received data is a command requesting change of some file. If it is determined that look-up or change of the terminal state is necessary, the flow branches to step S 208 . The communication processing program  303  calls the terminal state management part  108  with using the terminal ID and command as a parameter, and carries out necessary look-up or change. 
         [0080]    Finally, in step S 209 , the communication processing program  303  creates response data and transmits the response data to the communication management part  112 . The transmitted data is transferred to a destination terminal via the gateway part  210  of the communication management part  112 . After that, the communication processing program  303  returns to step S 201  and waits for the next data to arrive. 
         [0081]    When the communication processing program ends, the process returns to step S 105  of  FIG. 10 . 
         [0082]    In step S 105 , the low-interactive honeypot  802  checks the execution result of the communication processing program. If the execution result indicates “switching request”, the flow branches to step S 106  and the low-interactive honeypot  802  notifies the communication management part  112  of a honeypot switching request. After that, the low-interactive honeypot  802  returns to step S 101 . 
         [0083]    The operation of the terminal state management part  108  will be described with referring to  FIG. 12 . 
         [0084]      FIG. 12  is a flowchart illustrating an operation flow of the terminal state management part  108 . 
         [0085]    First, in step S 301 , the terminal state management part  108  receives the terminal ID and the command. 
         [0086]    Then, in step S 301 , the terminal state management part  108  acquires a file system name stored in the honeypot execution state management part  115  with using the received terminal ID as a key. 
         [0087]    Then, in step S 301 , based on the acquired file system name, the terminal state management part  108  selects a function for executing a command given on a virtual machine image where the file system is stored. Such a function can be created by using a technique applied to a command such as mount command of the basic OS, which renders a file operable as a virtual file system. 
         [0088]    In Embodiment 1, the function is implemented in the terminal state management part  108  as a function. It is also possible to divide the function into modules and switch a module to be loaded, with referring to the file system name. 
         [0089]    An example of a command executable by the communication management part  112  in Embodiment 1 will be described. 
         [0090]      FIG. 13  is a diagram illustrating examples of the command that can be executed by the communication management part  112 . 
         [0091]    As illustrated in  FIG. 13 , some command requires a parameter such as a file name being the operation target. In that case, a command name and a required parameter make up one complete command. Note that the command executable by the communication management part  112  is not limited to the examples illustrated in  FIG. 13 . 
         [0092]    Finally, in step S 304 , the terminal state management part  108  returns the processing result obtained by executing the function, to the caller. The process ends. 
         [0093]    The process of the terminal state transition scenario execution part  107  will be described with referring to  FIG. 14 . 
         [0094]      FIG. 14  is a flowchart illustrating an operation flow of the terminal state transition scenario execution part  107 . 
         [0095]    First, in step S 401 , when booting the system, the terminal state transition scenario execution part  107  loads the terminal state transition scenario from the terminal state transition scenario accumulation part  110 . The terminal state transition scenario is formed in a table format including, as elements, the execution time  501 , the terminal ID  502 , and the command  503 , as in  FIG. 5 . 
         [0096]    Then, in step S 402 , the terminal state transition scenario execution part  107  acquires the present time. 
         [0097]    Then, in step S 403 , the terminal state transition scenario execution part  107  checks if the terminal state transition scenario includes a scenario to be executed describing the execution time  501  coinciding with the time acquired in step S 402 . If such a scenario does not exist, the flow returns to step S 402 . 
         [0098]    Then, in step S 404 , the terminal state transition scenario execution part  107  acquires the terminal ID  502  and command  503  of the scenario concerned. 
         [0099]    Then, in step S 405 , the terminal state transition scenario execution part  107  searches the execution state management part  115  with using the acquired terminal ID as a key, and acquires the execution state of the terminal having the ID concerned. 
         [0100]    Then, in step S 406 , the terminal state transition scenario execution part  107  checks if the execution state of the simulated terminal indicated by the acquired terminal ID shows a high-interactive honeypot. If the execution state shows a high-interactive honeypot, the flow branches to step S 407 . 
         [0101]    Then, in step S 407 , the terminal state transition scenario execution part  107  searches the high-interactive honeypot execution command definition table ( FIG. 6 ) stored in the high-interactive honeypot execution command accumulation part  116  with using the command name and terminal ID as a key, and acquires the started program  603  and the user ID  604  that correspond to an operation. The name of the program started on the virtual machine, and an argument which is given at start-up are described in the started program  603 . In  FIG. 6 , a portion $1 expresses a variable indicating the first value of parameters included in the command. The acquired started program  603  is started on the virtual machine concerned, under the privilege of the acquired user ID. Such start-up of a program in the virtual machine is a function provided by an existing product of the virtual machine execution environment as well and is easy to implement. 
         [0102]    Finally, in step S 408 , the terminal state transition scenario execution part  107  supplies the terminal ID and the command acquired from the scenario to the terminal state management part  108 . The flow returns to step S 402 . 
         [0103]    As described above, in the invention of Embodiment 1, the communication management part  112  switches the transfer destination honeypot. The communication is initially processed by a low-interactive honeypot. The transfer destination honeypot is switched to a high-interactive honeypot only where necessary, so that use of the high-interactive honeypot can be suppressed. This provides an effect that an attack observation apparatus which simulates a large-scale system can be implemented with a few computer resources. 
         [0104]    Regarding the terminal state stored in the terminal state accumulation part  109 , the image file of the virtual machine is employed, and the image file is operated by the terminal state management part  108 . As a result, the execution state of the low-interactive honeypot and the execution state of the high-interactive honeypot can be synchronized. 
         [0105]    The protocol state transition of the application layer is traced by the communication management part  112 . Data necessary for state restoration is accumulated. When switching the honeypot, communication for communication state restoration is performed. As a result, honeypot switching can be carried out without causing communication state inconsistency and so on. 
         [0106]    Since the communication is terminated in the communication management part  112 , honeypot switching can be carried out even with communication using a protocol such as TCP or TLS. 
         [0107]    The communication management part  112  returns an ARP response to an ARP request for all simulated terminal IPs. Furthermore, the virtual machines are connected to different VLANs and are booted. This can guarantee that all communications pass by way of the communication management part  112 . 
         [0108]    The terminal state is changed in accordance with the terminal state transition scenario. Therefore, it is possible to reproduce a state showing as if the user was actually conducting business within the simulated terminal. 
         [0109]    When having the high-interactive honeypot carry out state transition according to the terminal state transition scenario, a process is started in the virtual machine. This further enables camouflaging a user conducting business. 
       Embodiment 2 
       [0110]    In Embodiment 1 described above, the communication management part  112  transfers communication to the low-interactive honeypot and the high-interactive honeypot. In Embodiment 2, a case will be described where the low-interactive honeypot is operated by the gateway part  210  of the communication management part  112 . 
         [0111]      FIG. 15  is a diagram illustrating an example of a system configuration of a periphery of a communication management part  112  according to Embodiment 2. 
         [0112]    Comparison of  FIG. 15  with  FIG. 2  shows that the low-interactive honeypot part  106  is no longer used. Instead, a gateway part cum low-interactive honeypot part  1501  replaces the gateway part  210 . 
         [0113]    An operation of the gateway part cum low-interactive honeypot part  1501  in Embodiment 2 will be described. Upon reception of communication from a terminal, the gateway part cum low-interactive honeypot part  1501  processes the communication by a low-interactive honeypot part while storing communication restoring data in the same manner as the gateway part  210  of Embodiment 1 does. This process can be implemented easily by inputting the data to a communication processing program  303  disclosed in Embodiment 1, instead of transferring communication on the gateway part  210  of Embodiment 1. When the communication processing program  303  returns a honeypot switching request, a high-interactive honeypot is booted and the communication state is restored in accordance with the same method as that in Embodiment 1. Subsequently, the communication is transferred to the high-interactive honeypot which has started the communication, in the same manner as in Embodiment 1. 
         [0114]    As described above, in the invention of Embodiment 2, since the process of the low-interactive honeypot is carried out on the communication management part  112 , overhead of transferring communication to the low-interactive honeypot is eliminated, providing an effect of reducing response delay of communication. 
       Embodiment 3 
       [0115]    In Embodiments 1 and 2 described above, the virtual machines in the high-interactive honeypot part  103  are connected to different VLANs respectively. In Embodiment 3, a case will be described where the same effect is obtained without using VLANs but by setting ARP caches of the respective virtual machines on the communication management part  112 . 
         [0116]      FIG. 16  is a diagram illustrating an example of a system configuration of a periphery of a communication management part  112  according to Embodiment 3. Comparison of  FIG. 16  with  FIG. 2  shows that virtual machines  201  and  202  and the communication management part  112  are connected to the same LAN. A configuration being the ARP response part  209  in the communication management part  112  of Embodiment 1 is replaced by an ARP cache setting part  1601 . 
         [0117]    An operation of the communication management part  112  in Embodiment 3 will be described. In Embodiment 3, the communication management part  112  periodically transmits an ARP response packet to each virtual machine in operation, the ARP response packet indicating that a MAC address corresponding to the IPs of all simulated terminals is the MAC address assigned to the interface of the communication management part  112  connected to a network  206 . 
         [0118]      FIG. 17  is a diagram illustrating an example of the ARP response packet. 
         [0119]    As illustrated in  FIG. 17 , in the packet, the MAC address of the communication management part  112  is used as the MAC address ( 1701 ) for each virtual machine IP ( 1702 ). Therefore, even when the communication party is an adjacent virtual machine, each virtual machine does not transmit communication directly to the adjacent virtual machine but transmits the packet to the communication management part  112 . 
         [0120]    As described above, in the invention of Embodiment 3, an ARP response being spoofed is transmitted to each virtual machine. Thereby, the individual virtual machines need not be separated apart by VLANs, providing an effect of simplifying the system configuration. 
         [0121]    The scheme disclosed in Embodiment 3 can be applied not only to Embodiment 1 but also to Embodiment 2 similarly, as a matter of course. 
       Embodiment 4 
       [0122]    In Embodiments 1 to 3 described above, all pieces of data necessary for communication state restoration are stored in the communication management part  112 . In case of communication state restoration, the communication management part  112  communicates with a booted virtual machine. In Embodiment 4, a case will be described where a low-interactive honeypot is used for communication state restoration of an application layer. 
         [0123]      FIG. 18  is a diagram illustrating an example of a system configuration of a periphery of a communication management part  112  according to Embodiment 4. 
         [0124]    Comparison of  FIG. 18  with  FIG. 2  of Embodiment 1 shows that the communication restoring data accumulation part  211  is no longer used. An application layer restoring communication transfer part  1801  is added which transfers to a virtual machine communication sent from a low-interactive honeypot for restoring the application layer communication state. 
         [0125]      FIG. 19  is a diagram illustrating an example of a configuration of a low-interactive honeypot part  106  of an attack observation apparatus according to Embodiment 4. 
         [0126]    Comparison of  FIG. 19  with  FIG. 3  illustrating the configuration of the low-interactive honeypot part  106  of Embodiment 1 shows that an application layer communication restoring data accumulation part  1901  for accumulating data for restoring application layer communication and a communication state restoring program accumulation part  1902  for accumulating a restoration program  1903  for restoring communication of the application layer are added. 
         [0127]    An operation of the attack observation apparatus according to Embodiment 4 will be described. In Embodiment 4, the low-interactive honeypot part  106  operates in a manner illustrated in  FIG. 20 . 
         [0128]      FIG. 20  is a flowchart illustrating an operation flow of the low-interactive honeypot part  106  according to Embodiment 4. 
         [0129]    The flowchart of  FIG. 20  is the same as that in Embodiment 1 until step S 506 . 
         [0130]    After a honeypot switching request is executed in step S 506 , a communication restoration program is acquired in step S 507 . Using this program, the communication state of the application layer is restored in step S 508 . 
         [0131]    In order to accumulate data necessary for restoring the communication state of the application layer in step S 508 , a communication processing program in Embodiment 4 operates as indicated by the flowchart illustrated in  FIG. 21 . 
         [0132]      FIG. 21  is a flowchart illustrating an operation flow of the communication processing program according to Embodiment 4. 
         [0133]    The flowchart of  FIG. 21  is equivalent to the flowchart indicated in Embodiment 1 but additionally includes step S 607  and step S 608 . More specifically, a process is added so that necessary data is stored when it is determined in the communication processing program that data need be stored for communication state restoration (for example, when a log-in request on an application layer protocol is received in  FIG. 8  of Embodiment 1). 
         [0134]    Upon reception of a honeypot switching request, the communication management part  112  boots the virtual machine in the same manner as in Embodiment 1, and restores low-level layer communication (for example, TCP, TLS session, and so on). After that, communication restoring application layer data being transmitted from a communication restoration program in a low-interactive honeypot is transferred to a virtual machine on the restored communication connection. Likewise, a response from the virtual machine is transferred to the communication restoration program. This communication is executed until the communication restoration program ends. Then, communication restoration ends. 
         [0135]    As described above, in the invention of Embodiment 4, the communication management part  112  covers as far as to the restoration of a protocol of an application layer such as TCP or TLS, which is not higher than the application layer. The communication state restoration of the application layer is executed by a communication restoration program on the low-interactive honeypot. This provides an effect that the communication management part  112  will not be influenced by a change in a protocol of the application layer. Apparently, Embodiment 4 is operable on the communication management part  112 , as has been described in Embodiment 2. 
       Embodiment 5 
       [0136]    In Embodiments 1 to 4 described above, switching to a high-interactive honeypot takes place in response to a request from a low-interactive honeypot. In Embodiment 5, a case will be described where an intrusion detection system (IDS) is installed in a low-interactive honeypot, or on a network that connects a low-interactive honeypot and the communication management part  112  to each other, and where honeypot switching is effected under the condition that the IDS has detected an attack. 
         [0137]      FIG. 22  is a diagram illustrating an example of a system configuration of a periphery of a communication management part  112  according to Embodiment 5. 
         [0138]    Referring to  FIG. 22 , an IDS  2201  monitors communication to a low-interactive honeypot. When an attack is detected, the attack is notified to the communication management part  112 , and switching to a high-interactive honeypot is executed. Switching of the honeypot and communication state restoration after switching are the same as those in Embodiments 1 to 4. 
         [0139]    As has been described above, in the invention of Embodiment 5, honeypot switching is effected under the condition that the IDS has detected an attack. Therefore, honeypot switching can be carried out exhaustively, not only when undefined communication arrives but also in response to attacks as a whole which are detectable by an IDS, thus providing an effect that a large-scale system can be simulated more elaborately. 
       REFERENCE SIGNS LIST 
       [0140]      101 : honeypot system (attack observation apparatus);  102 : external network;  103 : high-interactive honeypot part;  104 : virtual machines;  105 : virtual machine execution environment;  106 : low-interactive honeypot part;  107 : terminal state transition scenario execution part;  108 : terminal state management part;  109 : terminal state accumulation part;  110 : terminal state transition scenario accumulation part;  112 : communication management part;  115 : honeypot execution state management part;  116 : high-interactive honeypot execution command accumulation part;  201  to  202 : virtual machine;  205 : virtual switch;  207 : packet reception part;  208 : packet transmission part;  209 : ARP response part;  210 : gateway part;  211 : communication restoring data accumulation part;  301 : communication processing program execution part;  302 : communication processing program accumulation part;  303 : communication processing program;  701  to  702 : virtual machine image;  1501 : gateway part cum low-interactive honeypot part;  1601 : ARP cache setting part;  1801 : application layer restoring communication transfer part;  1901 : application layer communication restoring data accumulation part;  1902 : communication state restoring program accumulation part;  1903 : restoration program;  2201 : IDS