Intrusion response device, intrusion response method, intrusion response system, and program

Abstract

An intrusion response device (70) performs risk handling by using a database (50) in which a plurality of countermeasures against security risks related to information assets, vulnerabilities, and threats and costs of the countermeasures are registered in advance. The intrusion response device (70) comprises: a risk handling unit (71) that acquires a risk level that is an estimated loss cost when a risk obtained as a risk assessment result becomes obvious, compares the risk level with the costs of countermeasures, and identifies, as a countermeasure candidate, a countermeasure having a cost below the risk level; and a risk handling proposal unit (72) that proposes the countermeasure candidate to a system administrator.

Description

Intrusion response device, intrusion response method, intrusion response system, and program

[0001] The present invention relates to security risk management, security risk assessment, and security risk response for network systems, and more particularly to an intrusion response device, an intrusion response method, an intrusion response system, and a program.

[0002] In recent years, network systems have been exposed to various cyber-attack threats, making security risk management increasingly important. Security risk management requires determining the severity and priority of various risks through security risk assessment, and then taking appropriate risk responses based on that.

[0003] Security risk assessment involves collecting and analyzing a huge amount of security information to identify, analyze, evaluate, and respond to risks. Here, security information includes network configuration management information, vulnerability information, and alerts from intrusion detection systems (IDS) and intrusion prevention systems (IPS).

[0004] Especially in large-scale network systems such as enterprise networks, it is not realistic for system operators to manually perform all of these risk assessment tasks due to the time and workload involved. Furthermore, because the environment surrounding network systems and the types and characteristics of the risks they pose change daily, each step in the risk management process must be performed dynamically, quickly, and accurately. Therefore, there is a strong demand for automating and mechanizing risk management tasks. Such automation and mechanization not only reduces human workload (human time and workload), but also speeds up the management process and helps prevent human error.

[0005] Non-Patent Document 1 describes a security risk management method using a Bayesian Attack Graph (BAG). A BAG is a Bayesian network (BN) for representing the probabilistic dependencies between vulnerabilities inherent in a network system. It comprehensively describes the paths (attack procedures) an attacker can take to attack information assets within the system. In the BAG, nodes represent system states, and edges represent the probability of a system state transition. Here, a system state could be, for example, "a state in which an attacker has gained administrative privileges over a specific information asset (such as a host)," and a system state transition corresponds to "(successful) exploitation of a vulnerability." Using a BAG, the probability of transitioning to each system state can be calculated mechanically and quantitatively while taking vulnerability dependencies into account.

[0006] Furthermore, the technology described in Non-Patent Document 1 constructs an Augmented-BAG, which adds countermeasures to security risks and the gains (or costs) of each countermeasure to a BAG. By using Augmented-BAG and a genetic algorithm, it is possible to identify a combination of risk countermeasures that maximizes (or minimizes) the sum of these gains (or costs).

[0007] N. Poolsappasit, R. Dewri, and I. Ray, “Dynamic Security Risk Management Using Bayesian Attack Graphs,” IEEE Transactions on Dependable and Secure Computing, vol. 9, no. 1, pp. 61-74, 2012.

[0008] When risk countermeasures are identified using Augmented-BAG and a genetic algorithm, the following problems arise: (Problem 1) Because a combinatorial optimization problem is solved iteratively using a genetic algorithm, the procedure is complex and the computational costs are high. (Problem 2) The solutions of the genetic algorithm (the risk countermeasures identified) generally differ each time, resulting in variations in the effectiveness of the countermeasures. (Problem 3) Because the attempt is to maximize (or minimize) the total gain (or cost) of the countermeasures, it is difficult to determine the cost-effectiveness of each countermeasure. In other words, conventional technology has had problems such as complex procedures and high computational costs, variations in the effectiveness of the countermeasures, and difficulty in determining the cost-effectiveness of each countermeasure.

[0009] Therefore, the present invention aims to solve the above problems and automate and mechanize a series of risk management operations.

[0010] The intrusion response device of the present invention is an intrusion response device that responds to risks in a network system, and is characterized by comprising: a memory unit that stores a database in which a plurality of countermeasures for security risks related to information assets, vulnerabilities, and threats within the network system and at least the cost of the countermeasures as an item associated with each countermeasure are pre-registered; a risk response unit that acquires a risk level, which is the cost of loss when a risk obtained as a result of a risk assessment within the network system becomes apparent, compares the risk level with the cost of the countermeasures, and identifies countermeasures having costs below the risk level as candidate countermeasures; and a risk response proposal unit that proposes the candidate countermeasures identified by the risk response unit to a system administrator.

[0011] According to the present invention, the above problems can be solved and a series of risk management operations can be automated and mechanized.

[0012] 12. FIG. 13 is a schematic configuration diagram of a system including an intrusion response device according to a first embodiment of the present invention. FIG. 14 is a diagram illustrating an example of risk countermeasures. FIG. 15 is a schematic diagram of an analysis graph created by the intrusion response device. FIG. 16 is a flowchart illustrating a process flow for creating an analysis graph. FIG. 17 is a flowchart illustrating a process flow for creating an analysis graph. FIG. 18 is a schematic diagram illustrating a corresponding relationship between step S1 in FIG. 4 and the analysis graph. FIG. 19 is a schematic diagram illustrating a corresponding relationship between step S2 in FIG. 4 and the analysis graph. FIG. 19 is a schematic diagram illustrating an example of calculation performed in step S2 in FIG. 4. FIG. 20 is a schematic diagram illustrating a corresponding relationship between step S3 in FIG. 4 and the analysis graph. FIG. 21 is a schematic diagram illustrating a corresponding relationship between step S4 in FIG. 4 and the analysis graph. FIG. 22 is a schematic diagram illustrating an example of calculation performed in step S4 in FIG. 4. FIG. 23 is a flowchart illustrating a process flow for calculating a risk probability related to a node state using an analysis graph. FIG. 24 is a schematic diagram of an outbound analysis graph created by an intrusion response device according to a second embodiment of the present invention. FIG. 25 is a flowchart illustrating a process flow by a risk response unit. FIG. 26 is a flowchart illustrating a process flow by a risk response unit. FIG. 27 is a flowchart illustrating a process flow by a risk response unit.

[0013] The intrusion response device according to this embodiment will be described in detail below with reference to the accompanying drawings. [System Configuration Overview] As shown in FIG. 1, the intrusion response system 1 includes a network information acquisition unit 10, a host anomaly detection unit 20, an information input unit 30, a data processing unit 40, a database 50, a risk assessment unit 60, and an intrusion response unit (intrusion response device) 70. The network information acquisition unit 10 automatically collects security information related to information assets, vulnerabilities, and threats within a network system having multiple hosts, the security information being collected by multiple security devices installed within the network system. The host anomaly detection unit 20 acquires detection information related to host anomalies from security software installed on the hosts within the network system. The information input unit 30 accepts input information related to security risk assessment and risk response. The data processing unit 40 associates the security information acquired by the network information acquisition unit 10 with the time the security information was collected and stores the associated information in the database 50. The data processing unit 40 also associates the detection information acquired by the host anomaly detection unit 20 with the time the detection information was collected and stores the associated information in the database 50. The risk assessment unit 60 performs risk assessment based on the data stored in the database 50. The intrusion response unit 70 performs risk response using the database 50 in which a plurality of countermeasures for security risks related to information assets, vulnerabilities, and threats within the network system are registered in advance. Each unit of the intrusion response system 1 will be described in detail below.

[0014] 1, the network information acquisition unit 10 includes a network flow information acquisition unit 11, a vulnerability information acquisition unit 12, and a threat information acquisition unit 13. The network flow information acquisition unit 11 acquires security information related to information assets. The vulnerability information acquisition unit 12 acquires security information related to vulnerabilities. The threat information acquisition unit 13 acquires security information related to threats.

[0015] The network information acquisition unit 10 can use commercially available products. The network flow information acquisition unit 11 can use a network flow collector installed in the network. The network flow collector can obtain statistical information on packets flowing through a router. The vulnerability information acquisition unit 12 can use a vulnerability scanner installed in the network. The threat information acquisition unit 13 can use a NIDS (Network Intrusion Detection System), NIPS (Network Intrusion Prevention System), or WAF (Web Application Firewall) installed in the network. Information obtained from various security products by the network information acquisition unit 10 includes logs, alerts, and detection results.

[0016] [Host Anomaly Detection Unit 20] The host anomaly detection unit 20 acquires detection information related to host anomalies from security products installed on each host. Here, host anomalies refer to, for example, virus infections, suspicious behavior, exploitation of vulnerabilities, etc. In this embodiment, the host anomaly detection unit 20 acquires information from systems such as a HIDS (Host Intrusion Detection System) or an EDR (Endpoint Detection and Response) system installed on each host. Details of the information acquired by the host anomaly detection unit 20 will be described later.

[0017] [Information Input Unit 30] The information input unit 30 accepts input of the value of an information asset, risk criteria, risk countermeasures, etc. from, for example, a system administrator. The value of an information asset is the cost of loss when a risk becomes apparent. Hereinafter, the value of an information asset will also be referred to as asset value. The information input from the information input unit 30 is stored in the database 50 along with various other security information. The asset value and risk criteria information input from the information input unit 30 is transmitted from the database 50 to the risk assessment unit 63. Furthermore, the risk countermeasure information input from the information input unit 30 is transmitted from the database 50 to the risk response unit 71. Details of the information acquired by the information input unit 30 will be described later.

[0018] [Data Processing Unit 40, Database 50] The data processing unit 40 appropriately organizes and formats the various security information acquired by the network information acquisition unit 10, host anomaly detection unit 20, and information input unit 30, and stores the information in the database 50. The database 50 stores the information shown in Tables 1 to 3 below, as well as the information shown in FIG. 2. Here, the information shown in Table 1 is mainly acquired by the network information acquisition unit 10 and is used by the risk identification unit 61.

[0019]

[0020] In this specification, a tuple of a host and a starting port is called a "starting interface." A tuple of a host and a finishing port is called a "finishing interface." For convenience, data will also be expressed using symbols. Let the host be h, the starting port be s, and the finishing port be d. The starting interface is expressed as i = (h, s). The finishing interface is expressed as j = (h, d). Let v be a vulnerability, and the vulnerability v inherent in host h is expressed as vulnerability node u = (h, v).

[0021] As will be described later, the database 50 receives a "certain period" as a query from the risk identification unit 61, and provides the risk identification unit 61 with the data flow for each interface during that period, the unit-time average number of malicious communications, and vulnerability information inherent in each host during that period. Therefore, to satisfy this requirement, these data are managed and saved together with time information. Such processing is performed in advance by the data processing unit 40, and the database 50 also satisfies this requirement.

[0022] The database 50 stores the information shown in Table 2 below together with the information shown in Table 1. The information shown in Table 2 is mainly acquired by the host abnormality detection unit 20 and used by the risk analysis unit 62.

[0023]

[0024] The "starting interface (or ending interface) related to abnormal host behavior" is, for example, information about an interface that transmits or receives traffic that shows an unusual pattern in terms of traffic volume, protocol, or the nature of data stored in packets. The "vulnerability related to abnormal host behavior" is, for example, information about an alert indicating that a vulnerability has been exploited. However, this information is only stored when a security product installed on the host detects an abnormality. Therefore, this information is not necessarily stored in the database 50 all the time.

[0025] As will be described later, the database 50 receives a "certain period" as a query from the risk analysis unit 62, and provides the risk analysis unit 62 with "information related to host abnormalities" detected during that period. Therefore, to satisfy this requirement, these data are managed and saved together with time information. Such processing is performed in advance by the data processing unit 40, and the database 50 also satisfies this requirement.

[0026] The database 50 stores the information shown in Table 3 below together with the information shown in Tables 1 and 2. The information shown in Table 3 is mainly obtained by the information input unit 30 (i.e., input by the system administrator) and used by the risk assessment unit 63.

[0027]

[0028] An "asset value" is assigned to each end interface node. Alternatively, an "asset value" is assigned to each start interface node. Alternatively, an "asset value" is assigned to each vulnerability node. As an example, a case where an asset value is assigned to an end interface node will be described. For example, a system administrator or the like assigns asset values ​​as real numbers to all end interface nodes on an analysis graph. Alternatively, a system administrator or the like assigns asset values ​​as real numbers to some (particularly important) end interface nodes on an analysis graph.

[0029] For example, assume that there is an information asset in the target network system that satisfies the following conditions 1 to 3. (Condition 1) An application (e.g., a database) on host h stores important business information for the company. (Condition 2) That application is accessible from destination port d on host h. (Condition 3) The estimated loss cost if the company's important business information were lost or leaked is 50 million yen. In this case, "50 million yen" is entered as the asset value for the corresponding destination interface node (h, d) in the analysis graph. Note that the asset value entered is not limited to a monetary amount; it could also be, for example, the man-hours (man-months) required for risk treatment. The "risk standard" is entered as the upper limit (expected value) of the tolerable loss cost.

[0030] As shown in FIG. 2, information on countermeasures is stored in the database 50. The information shown in FIG. 2 is acquired by the information input unit 30 (i.e., input by the system administrator) and used by the intrusion response unit 70. In the database 50, at least the cost of the countermeasure is registered as an item associated with each countermeasure. In the example shown in FIG. 2, information on items 101 to 104 is registered in the database 50. Item 101 indicates a risk countermeasure (main points). Item 102 indicates the application destination of the countermeasure. The application destination may be, for example, an asset, a vulnerability, a threat, or the like. Item 103 indicates whether the countermeasure is applied to a single object or multiple objects. Item 104 indicates the cost of the countermeasure. The cost may be, for example, the expense associated with the risk response. Note that the parameter values ​​for each item are merely examples.

[0031] The risk countermeasures shown in item 101 are explained in detail below. For example, countermeasure No. 5, "Vulnerability Patch Application <Night>," involves waiting until the nighttime maintenance period after a vulnerability is discovered in the system to apply a patch. This countermeasure incurs costs such as labor costs and electricity costs associated with the nighttime response. Countermeasure No. 6, "Vulnerability Patch Application <Switching>," involves patching a secondary system to switch it over to the primary system for vulnerabilities inherent in a redundantly configured host, and then patching the former primary system to keep it on standby as the secondary system. This countermeasure incurs costs such as labor costs associated with the complex operation and the momentary interruption associated with the switchover. Countermeasure No. 7, "Vulnerability Patch Application <Immediate>," involves immediately patching discovered vulnerabilities. This countermeasure incurs costs such as temporarily suspending the system. Countermeasure No. 8, "Packet Filtering," is applied to threats and filters specific packets based on IP addresses, etc.

[0032] Additionally, countermeasure No. 1 "Port deletion <nighttime>" waits until the nighttime maintenance period to block the port, just like with vulnerabilities. Countermeasure No. 2 "Port deletion <switching>" uses a redundant configuration to block the port, just like with vulnerabilities. Countermeasure No. 3 "Port deletion <immediate>" blocks the port immediately, just like with vulnerabilities. Countermeasure No. 4 "Address shuffling" is applied to assets and shuffles the IP addresses of internal devices using an SDN controller or similar. This countermeasure incurs costs such as configuration changes (over a wide area) and momentary outages when shuffling.

[0033] In the example shown in Figure 2, countermeasures No. 1 to No. 4 are potential countermeasures for the end interface. Countermeasures No. 5 to No. 7 are potential countermeasures for vulnerabilities. Countermeasure No. 8 is a potential countermeasure for threats. However, the number of countermeasures and the number of items associated with the countermeasures are just examples; for example, an item for "Countermeasure Details" could be added. In this case, it is possible to notify the details of the countermeasures to the system administrator, etc.

[0034] [Risk Assessment Unit 60] Based on the information in the database 50 shown in Table 1 and the like, the risk assessment unit 60 calculates the "probability that unauthorized communications reached each asset (interface) in a certain period of time" and the "probability that each vulnerability was exploited in a certain period of time." To do this, the risk assessment unit 60 uses a directed acyclic graph such as that shown in Fig. 3. Hereinafter, such a directed acyclic graph will be referred to as an analysis graph.

[0035] The analysis graph describes, as nodes, the source interface (Src Interface) and destination interface (Dst Interface) within the network system, as well as the vulnerabilities inherent in each host. The analysis graph also describes, as edges and their weights, the probability that unauthorized communication from outside will propagate between interfaces, and the probability that this will lead to a vulnerability attack.

[0036] Each node has its own state variable. If the node is an interface node, the state variable is a binary variable indicating whether unauthorized communication has arrived (1) or not (0). If the node is a vulnerable node, the state variable is a binary variable indicating whether the node has been exploited (1) or not (0). The risk assessment unit 60 calculates the probability that each of these state variables will be 1 (i.e., the expected value of each state variable) based on graph theory, thereby calculating the probability that unauthorized communication from outside will propagate between interfaces and the probability that this will lead to a vulnerability attack.

[0037] In addition, since the nodes of the BN in the conventional technology described in Non-Patent Document 1 represent the system state (unique combinations of system variables), when attempting to apply this conventional technology to a large-scale network, there is a problem that the system variables will cause a combinatorial explosion, making it difficult to create the BN itself from the perspective of computational cost. In contrast, the nodes of the BN created by the risk assessment unit 60 represent ports or vulnerabilities in the host, so the graph is less likely to become bloated, making it possible to apply it to large-scale networks.

[0038] As shown in FIG. 1 , the risk assessment unit 60 includes a risk identification unit 61, a risk analysis unit 62, and a risk evaluation unit 63. The risk identification unit 61 identifies security risks inherent in the network system and sources of external threats based on security information, creates an analysis graph that describes the probabilistic dependencies of the identified security risks in the form of a directed acyclic graph, and adds nodes indicating the sources of the identified external threats to the analysis graph. Here, external threats refer to external suspicious hosts and applications. The risk analysis unit 62 calculates risk probabilities related to the state of the nodes using information about threats within the network detected by security software installed on hosts in the network system and the analysis graph. The risk evaluation unit 63 estimates the loss cost when a risk materializes based on the risk probability calculated by the risk analysis unit 62 and predetermined asset value information. If the estimated loss cost is equal to or exceeds a predetermined risk standard, the risk is determined to require action. Details of each unit of the risk assessment unit 60 are described below.

[0039] [Risk Identification Unit 61] Based on information obtained from the network information acquisition unit 10 during a certain period, the risk identification unit 61 identifies risks inherent in the network system during that period and describes their probabilistic dependencies as an analytical graph. To do this, a system administrator or the like specifies an arbitrary period t in the past. The period t may be, for example, the period from five minutes ago to the present. The risk identification unit 61 sequentially executes the following processes. The risk identification unit 61 inputs the period t into the database 50 as a query and acquires various information for that period. The risk identification unit 61 uses the information obtained from the database 50 as input to create an analytical graph to be used for risk analysis. The risk identification unit 61 inputs the created analytical graph to the risk analysis unit 62.

[0040] Next, the flow of processing by the risk identification unit 61 to create an analysis graph will be described with reference to FIG. 4 (and FIG. 3 as appropriate). The risk identification unit 61 identifies dependencies between hosts over a predetermined period of time t (step S1). Here, the risk identification unit 61 describes the dependencies between hosts based on data flow and alert information. Then, the risk identification unit 61 identifies dependencies between interfaces between host groups (step S2). Here, the risk identification unit 61 calculates and describes dependencies between ports (interfaces), i.e., the probability that unauthorized communication will flow between interfaces, in accordance with the dependencies between hosts identified in step S1.

[0041] The risk identification unit 61 then identifies the dependency relationship between the destination interface and the vulnerability within each host (step S3). Here, the risk identification unit 61 calculates and describes the probability that the vulnerability will be accessed from the destination port (destination interface) and exploited. Then, the risk identification unit 61 identifies the dependency relationship between the vulnerability and the initiation interface within each host (step S4). Here, the risk identification unit 61 calculates and describes the probability that unauthorized communication will be performed from the initiation port (initiation interface) after the vulnerability is exploited. Then, the risk identification unit 61 sets the state variables of each node within each host based on the alert information (step S5). Then, the risk identification unit 61 adds an external interface based on the alert information (step S6).

[0042] Steps S1 to S6 will be described in detail below with reference to the drawings and formulas. (Step S1) In step S1, the risk identification unit 61 identifies the dependency relationships L0, L1, L2, ....L between the hosts during the period t. l Here, L l is a set of hosts whose "distance" from the Internet (outside) is l. A list of hosts whose distance from the outside is l is called a list L. lList L0 lists the hosts that have directly received unauthorized communications from outside. List L1 contains hosts that have received direct communications from hosts that belong to the list immediately preceding it, List L0. Similarly, lists L2 and onwards contain hosts that have received direct communications from hosts that belong to the list immediately preceding it. The value of l is determined automatically based on the input information (network environment). Furthermore, if the host that conducted the communications does not exist in the first place, these dependencies cannot be obtained, so a graph cannot be created and an assessment cannot be carried out.

[0043] Next, a detailed processing flow of step S1 will be described with reference to Fig. 5 and Fig. 6. Fig. 6 shows the dependency relationships L0, L1, L2, ..., L between hosts when the risk identification unit 61 has completed the process of creating the analysis graph. l In order to create this analysis graph, the risk identification unit 61 first creates a list L of hosts that have performed communication (alerts, network flows) during the period t. A (Step S11). This list L A Initially, all hosts for which an alert was generated due to external communication within the period t, or all hosts that have performed some kind of communication with other hosts within the network system, are listed in list L. Then, in the following process, the risk identification unit 61 creates a list L according to the dependency relationships between hosts. A Updates are made to sequentially remove hosts from the

[0044] Next, the risk identification unit 61 creates a list L A Among these, the hosts that received malicious communication (alerts) from the outside during the period t are listed in list L0 (step S12). As shown in FIG. 6, all hosts that received alerts are listed in list L0 in proximity to the outside (Internet). Then, the risk identification unit 61 determines whether list L0 is empty (step S13). If list L0 is not empty (step S13: No), the risk identification unit 61 adds the hosts in list L0 to list L A (Step S14), and delete it from the list L AThe risk identification unit 61 updates the list L as follows: A list L until it is empty A First, the risk identification unit 61 updates the list L A It is determined whether the list L is empty (step S15). A If is not empty (step S15: No), the risk identification unit 61 sets the value of the distance l from the Internet (external) to 0 (l ← 0: step S16), and performs the following repeated processing.

[0045] In the repeated processing, first, the risk identification unit 61 identifies the list L l Among the hosts that directly received communication (network flow) from each host in list L A List of what's included in L l+1 (Step S21). If the value of the distance l is 0 in Step S21, the list L l+1 In this case, list L1 lists all hosts that have directly received communication (network flow) from each host in list L0, in close proximity to list L0, as shown in FIG.

[0046] Following step S21, the risk identification unit 61 creates a list L l+1 It is determined whether the list L is empty (step S22). l+1 is not empty (step S22: No), the risk identification unit 61 l+1 List hosts in L A (step S23), and delete it from list L A Next, the risk identification unit 61 updates the list L A It is determined whether the list L is empty (step S24). A is not empty (step S24: No), the risk identification unit 61 increments the value of l (l ← l+1: step S25) and returns to step S21. Note that if the value of the distance l is 1 in step S21, the list L l+1In this case, list L2 lists all hosts that have directly received communication (network flow) from each host in list L1, in close proximity to list L1, as shown in FIG. 6. Similarly, in step S21, l As shown in FIG. 6, 1-1 All hosts that have directly received communication (network flow) from each host in the list L 1-1 are listed close to

[0047] On the other hand, in step S24, list L A is empty (step S24: Yes), the risk identification unit 61 increments the value of l (l ← l+1: step S26) and sets L0, L1, L2, . . . L as the dependency relationships between the hosts at that time. l (step S27), and the process ends. l+1 If the list L is empty (step S22: Yes), the risk identification unit 61 proceeds to step S27. A If the list L0 is empty (step S15: Yes), the risk identification unit 61 obtains L0 as the dependency relationship between the hosts at that time (step S28) and ends the process. Also, if the list L0 is empty in step S13 (step S13: Yes), the risk identification unit 61 ends the process.

[0048] (Step S2) In step S2, the risk identification unit 61 calculates the conditional probability that malicious communication will occur between each start-point interface node and each end-point interface node, and creates an edge with the calculated value as a weight. The edge is a group of hosts (L n ) and host groups (L n+1 ) where the source interface node i=(h i ,s), h i ∈L n When malicious communication reaches the source interface node i=(h i ,s), h i ∈L n and destination interface node j=(hj ,d), h j ∈L n+1 The conditional probability of malicious communication occurring between and is given by p ij This probability p ij is expressed as the weight of the edge between node i and node j.

[0049] 7A is a schematic diagram showing the correspondence between step S2 and the analysis graph. In the analysis graph shown in FIG. 7A, for example, an area 201 surrounded by a virtual line schematically shows communication occurring between a start interface node of a host belonging to host group L0 and a finish interface node of a host belonging to host group L1. Also, for example, an area 202 surrounded by a virtual line schematically shows communication occurring between a start interface node of a host belonging to host group L1 and a finish interface node of a host belonging to host group L2.

[0050] In step S2, the risk identification unit 61 normalizes the ratio of the network flows to obtain a probability p ij In this case, the risk identification unit 61 determines the probability p ij Ask for.

[0051]

[0052] In formula (1), μ ij is the network flow between the source interface node i and the destination interface node j. i is the total amount of network flow sent from source interface node i.

[0053] Next, the probability p ij 7B, for example, when the network flows (communication volumes) from a start interface node i to end interface nodes j1, j2, and j3 are 2, 5, and 4, respectively, the total network flow volume ρ sent from the start interface node i is iis 11. Therefore, according to equation (1), the probabilities that communication will occur from the source interface node i to the destination interface nodes j1, j2, and j3 are 2 / 11, 5 / 11, and 4 / 11, respectively.

[0054] Note that the system administrator ij Alternatively, the system administrator may assign an arbitrary probability value as p ij An alternative method for calculating

[0055] (Step S3) In step S3, the risk identification unit 61 calculates the "probability that each vulnerable node will be exploited after being accessed from each end interface node," and creates an edge with the calculated value as a weight. The edge is defined between an end interface (port) node and a vulnerable node in the same host. Here, when malicious communication has reached end interface node j=(h,d), the conditional probability that vulnerable node u=(h,v) will be accessed from end interface node j=(h,d) is defined as q ju Then, the conditional probability that the vulnerable node u is exploited is w u In addition, the weight of the edge between the destination interface node j and the vulnerable node u is q ju ×w u Let's say.

[0056] 8 is a schematic diagram showing the correspondence between step S3 and the analysis graph. In the analysis graph shown in FIG. 8, for example, an area 301 surrounded by a virtual line schematically shows access from an end interface node to a vulnerable node in a host belonging to host group L0. An area 302 surrounded by a virtual line schematically shows access from an end interface node to a vulnerable node in a host belonging to host group L1. An area 303 surrounded by a virtual line schematically shows access from an end interface node to a vulnerable node in a host belonging to host group L2. An area 304 surrounded by a virtual line schematically shows access from an end interface node to a vulnerable node in a host belonging to host group L3. l 10 shows a schematic diagram of access from a destination interface node to a vulnerable node within a host belonging to the

[0057] Probability q ju is defined as a binary value, for example, 0 or 1. For example, it can be defined as 1 if application a containing vulnerability v uses d as the destination port, and 0 otherwise. Also, the probability w u can be calculated using a calculation method based on the Common Vulnerability Scoring System (CVSS), for example. The calculation method based on CVSS is described in Non-Patent Document 1, etc.

[0058] Note that the system administrator ju And probability w u The system administrator may assign any probability value as ju And probability w u An alternative method for calculating

[0059] (Step S4) In step S4, the risk identification unit 61 calculates the "probability that unauthorized communication will be performed from each start interface node after each vulnerable node is exploited" and creates an edge with the calculated value as a weight. The edge is defined between a vulnerable node and a start interface (port) node in the same host. Here, when the vulnerable node u=(h,v) is exploited, the probability that the start interface node i=(h,s) will be accessed from the vulnerable node u=(h,v) is defined as r ui This probability r ui is expressed as the weight of the edge between node u and node i.

[0060] 9A is a schematic diagram showing the correspondence between step S4 and the analysis graph. In the analysis graph shown in FIG. 9A, for example, an area 401 surrounded by a virtual line schematically shows access from a vulnerable node to an initiation interface node in a host belonging to host group L0. An area 402 surrounded by a virtual line schematically shows access from a vulnerable node to an initiation interface node in a host belonging to host group L1. An area 403 surrounded by a virtual line schematically shows access from a vulnerable node to an initiation interface node in a host belonging to host group L2.

[0061] The probability r calculated by the risk identification unit 61 ui For example, let us assume that the source port used by the host is random, and the ratio of network flows sent from each source interface node is simply expressed as probability r ui In this case, the risk identification unit 61 determines the probability r ui In equation (2), ρ i is the total amount of network flow sent from source interface node i.

[0062]

[0063] Next, the probability r calculated by the risk identification unit 61 uiA specific example of this will be described with reference to Figure 9B. Figure 9B is a schematic diagram illustrating the following conditions 1 to 4: (Condition 1) A network flow is sent from each of the ingress interface nodes i1, i2, and i4, and the other ingress interface nodes, including i3, are not sending any network flows. (Condition 2) The total amount of network flows sent from ingress interface node i1 is 6. (Condition 3) The total amount of network flows sent from ingress interface node i2 is 8. (Condition 4) The total amount of network flows sent from ingress interface node i4 is 15. In this case, the total amount of network flows sent from all ingress interface nodes within the host is 29. Therefore, according to equation (2), the probabilities that vulnerable node u will access ingress interface nodes i1, i2, and i4 are 6 / 29, 8 / 29, and 15 / 29, respectively.

[0064] In addition, the system administrator determines the probability r ui The system administrator may assign any probability value as r ui An alternative method for calculating

[0065] (Step S5) In step S5, the risk identification unit 61 defines and sets state variables for each start interface node, end interface node, and vulnerable node. The risk identification unit 61 defines and sets state variables M i Define the state variable M i is a binary variable that is 1 if an unauthorized communication has arrived, and 0 otherwise. i The initial value of is set to 0. The risk identification unit 61 determines whether or not unauthorized communication has reached the destination interface node j by setting a state variable M j Define the state variable M j is a binary variable that is 1 if an unauthorized communication has arrived, and 0 otherwise. j The initial value of is set to 0. The risk identification unit 61 sets a state variable Eu Define the state variable E u is a binary variable that is 1 if it is exploited and 0 otherwise. The state variable E u The initial value of is set to 0.

[0066] In step S5, the risk identification unit 61 calculates the state variable M j That is, the risk identification unit 61 calculates the state variable M j In equation (3), λ j is the unit time average of the number of unauthorized communications (IDS alerts and IPS alerts) received by destination interface j.

[0067]

[0068] Note that the system administrator can set this status variable M j Another way of setting may be provided.

[0069] (Step S6) In step S6, the risk identification unit 61 adds the initiation interface from which malicious communication was initiated from outside the network system to the analysis graph created by the process up to step S5 (see FIG. 3). This initiation interface, which is external to the network system and caused the alert, is the external malicious interface. The analysis graph shown in FIG. 3 differs from the analysis graphs shown in FIGS. 6, 7A, 8, and 9A in that a node indicating the external malicious interface has been added. This makes it possible to identify and visualize the IP address and port number of the host that initiated malicious or suspected malicious communication and specifically identify the source of the threat.

[0070] Information on external malicious interfaces is acquired by the network information acquisition unit 10 and stored in the database 50 as shown in item 2 of Table 1. Item 2 of Table 1 includes information on the starting interface that performed unauthorized communication from the outside to the ending interface within the network system. This completes the processing of the risk identification unit 61, and the created analysis graph is sent to the risk analysis unit 62.

[0071] [Risk analysis unit 62] The risk analysis unit 62 sequentially executes the following processes. The risk analysis unit 62 acquires an analysis graph from the risk identification unit 61. The risk analysis unit 62 acquires information on host abnormalities from the database 50 as threat information within the network. The risk analysis unit 62 calculates a risk probability related to the node state using the analysis graph acquired from the risk identification unit 61 and the information on host abnormalities acquired from the database 50. The risk analysis unit 62 inputs the obtained risk probability of each node to the risk assessment unit 63.

[0072] Next, the flow of processing by the risk analysis unit 62 to calculate risk probability will be described with reference to FIG. 10 (and also with reference to FIG. 1 and FIG. 6 as appropriate). FIG. 10 is a flowchart showing the flow of processing to calculate risk probability. Note that the calculation and update method of state variables will be described later. First, the risk analysis unit 62 generates a list L that specifies the dependency relationships between hosts. n The value of the identifier n is set to 0 (n←0: step S31).

[0073] Then, if an "interface related to a host abnormality" or a "vulnerability related to a host abnormality" has been detected for a certain host (if it has been stored in the database 50), the risk analysis unit 62 updates the state variables of the interface node and vulnerability node to non-zero values ​​(step S32). A non-zero value indicates a probability value that is not 0. This value may be determined by a system administrator or the like in any way based on the severity of the abnormality detected in the host. Also, if the appropriate value is unknown, the most pessimistic value, i.e., 1, may be used. However, in the list L nIf no abnormality has been detected in any of the hosts (if no abnormality is stored in the database 50), step S32 is omitted.

[0074] Then, the risk analysis unit 62 creates a list L n For all hosts in list L0, the probability that the state variable of each end interface node will be 1 (expected value of the state variable) is calculated, and this is substituted and updated as the value of the new state variable (step S33). However, when n=0 (i.e., for the group of hosts belonging to list L0), the risk identification unit 61 has already set the state variable of the end interface node, so step S33 is omitted. Then, the risk analysis unit 62 calculates the probability that the state variable of each end interface node will be 1 (expected value of the state variable) for all hosts in list L0. n For all hosts in the list L, the probability that the state variable of each vulnerable node will be 1 (expected value of the state variable) is calculated, and this is substituted as the value of the new state variable and updated (step S34). Then, the risk analysis unit 62 determines whether n=l (step S35). If n=l is not the case (step S35: No), the risk analysis unit 62 n For all hosts in the list, the risk analysis unit 62 calculates the probability that the state variable of each start interface node will be 1 (expected value of the state variable), and assigns and updates the value of the new state variable (step S36). Next, the risk analysis unit 62 increments the value of n (n ← n+1: step S37) and returns to step S32. On the other hand, if n=1 in step S34 (step S35: Yes), the risk analysis unit 62 ends the process of calculating the risk probability.

[0075] The risk analysis unit 62 describes the inbound analysis graph by sequentially calculating and updating the values ​​(expected values) of the state variables of each node along the direction of the edge from the outside to the inside of the network system. Here, the risk analysis unit 62 calculates the weight of each edge by regarding it as a conditional probability related to the state variables. In other words, the risk analysis unit 62 calculates by regarding the analysis graph as a BN.

[0076] Details of steps S33, S34, and S36 are explained below. (Step S33) In step S33, the risk analysis unit 62 performs calculations by regarding the weight of the edge extending from the start interface node to the end interface node as "the probability that unauthorized communication will reach the end interface node if unauthorized communication has reached the start interface node." When the risk analysis unit 62 regards the analysis graph as a BN and calculates the probability that the state variable of the end interface node will be 1, this becomes the risk probability as is. The risk probability in this case is the probability that unauthorized communication has reached the end interface node.

[0077] (Step S34) In step S34, the risk analysis unit 62 performs calculations by regarding the weight of the edge extending from the destination interface node to the vulnerable node as "the probability that the vulnerable node will be exploited when unauthorized communication reaches the destination interface node." When the risk analysis unit 62 regards the analysis graph as a BN and calculates the probability that the state variable of the vulnerable node will be 1, this becomes the risk probability as is. The risk probability in this case is the probability that the vulnerable node is exploited.

[0078] (Step S36) In step S36, the risk analysis unit 62 performs calculations by regarding the weight of the edge extending from the vulnerable node to the start interface node as "the probability that unauthorized communication will be performed from the start interface node if the vulnerable node is exploited." When the risk analysis unit 62 regards the analysis graph as a BN and calculates the probability that the state variable of the start interface node will be 1, this becomes the risk probability. In this case, the risk probability is the probability that unauthorized communication will reach the start interface node. The risk analysis unit 62 may apply a BN calculation method using a Conditional Probability Table (CPT).

[0079] In steps S33, S34, and S36, the calculation method by which the risk analysis unit 62 obtains each risk probability is not limited to the BN calculation method using CPT. The risk analysis unit 62 can also obtain a risk probability by calculating the probability that the state variable of the destination interface node will be 1 using the following formula (4). The risk analysis unit 62 can also obtain a risk probability by calculating the probability that the state variable of the vulnerable node will be 1 using the following formula (5). The risk analysis unit 62 can also obtain a risk probability by calculating the probability that the state variable of the source interface node will be 1 using the following formula (6).

[0080]

[0081] Here, if an edge with a non-zero weight extends from node A to node B, node A is called the parent node of node B. In equation (4), P j is the set of parent nodes of the destination interface node j. In equation (5), P u is the set of parent nodes of the vulnerable node u. In equation (6), P i is the set of parent nodes of the starting interface node i. The calculation methods shown in equations (4), (5), and (6) are likely to be faster than the calculation method for BN using CPT.

[0082] However, for a node that has been detected as an "interface related to a host abnormality" or a "vulnerability related to a host abnormality" and whose state variable has been updated first, the risk analysis unit 62 gives priority to the value stored earlier. That is, for a node whose state variable has been updated to a non-zero value in step S32, the risk analysis unit 62 discards the value calculated from the state variable of the parent node using equation (4), equation (5), or equation (6). This completes the processing of the risk analysis unit 62, and the calculated risk probability is sent to the risk assessment unit 63.

[0083] [Risk Assessment Unit 63] The risk assessment unit 63 calculates an estimated loss cost using asset value information input by a system administrator, etc. and the risk probability calculated by the risk analysis unit 62, and compares the estimated loss cost with a risk standard to determine the acceptability of the risk.

[0084] As an example, a case will be described in which an asset value is assigned to a destination interface node. The risk assessment unit 63 calculates the expected value of the loss cost for all destination interface nodes from their risk probability and asset value. At this time, for nodes for which no asset value has been input, a default value may be determined in advance in accordance with some policy. The risk assessment unit 63 stores the calculated information in the database 50 or the like so that it can be referenced by a system administrator or the like. Therefore, even when the risk is considered to be acceptable, the system administrator or the like can refer to the information on the estimated loss cost calculated by the risk assessment unit 63.

[0085] The risk assessment unit 63 can determine the acceptability of the risk by comparing the calculated estimated loss cost with the risk standard. For interfaces or vulnerable nodes that are determined to be particularly unacceptable (i.e., requiring action), the risk assessment unit 63 not only determines the estimated loss cost, but also specifically identifies the external interfaces (i.e., threat sources) that are ancestor nodes of the interfaces or vulnerable nodes in the analysis graph.

[0086] The risk assessment unit 63 determines whether the estimated loss cost is equal to or greater than the risk standard (threshold), using the risk standard as a threshold, and determines that the risk is acceptable if the estimated loss cost is smaller than the risk standard. On the other hand, if the estimated loss cost is equal to or greater than the risk standard, the risk assessment unit 63 determines that the risk requires action.

[0087] As an example, assume that a system administrator or the like inputs "1 million yen" as the risk standard using the information input unit 30. In this case, if the estimated loss cost is less than 1 million yen, the risk assessment unit 63 considers the risk to be "acceptable" and does not notify the system administrator or the like of the assessment result (however, the system administrator or the like will be able to refer to the information). Conversely, if the estimated loss cost exceeds 1 million yen, the risk assessment unit 63 notifies the system administrator or the like of the specific estimated loss cost, as well as the locations and risk probabilities of interfaces and vulnerabilities that are deemed to require particular attention.

[0088] [Modification of the Risk Assessment Unit 60] Below, a description will be given of a modification of the risk assessment unit 60. As indicated by the dashed line in FIG. 1 , the risk identification unit 61 can also be modified to acquire risks determined by the risk evaluation unit 63 to require a response. In this case, the risk identification unit 61 describes an outbound analysis graph by identifying the dependency relationships between nodes along the direction of the edges pointing outward, with the node indicating a risk in the analysis graph as the root node. The risk identification unit 61 then outputs the outbound analysis graph to the risk analysis unit 62.

[0089] In this modification, the risk identification unit 61 receives a list of risks (interfaces and vulnerabilities) that the risk assessment unit 63 has determined to be "requiring action," and writes an "outbound analysis graph" (see FIG. 11) for each risk, outputting it to the risk analysis unit 62. Note that hereinafter, the analysis graph shown in FIG. 2 will be referred to as the original analysis graph or the inbound analysis graph.

[0090] The method for creating an outbound analysis graph is almost the same as the method for creating an inbound analysis graph, with the following three differences in the creation procedure: (1-1) The interface node or vulnerability node determined to require action by the risk assessment unit 63 (rather than the node where an alert occurred) is set as the root node. (1-2) The outbound network flow (rather than the inbound network flow) from the root node is described until it reaches an external interface. (1-3) Dummy vulnerability nodes can be added as appropriate.

[0091] The reason for adding dummy vulnerability nodes here is to take into account the following malicious communications. Usually, outbound communications are much easier than intrusion from the outside into the inside. Therefore, outbound communications that do not involve exploiting vulnerabilities are also expected. In order to take into account such malicious communications, the risk identification unit 61 can add any number of dummy vulnerability nodes to each host in the outbound analysis graph. In this case, the risk identification unit 61 determines the edges of exploit access and their weights (probabilities) q ju , r ui can be determined arbitrarily.

[0092] In this modified example, the risk analysis unit 62 analyzes the outbound analysis graph in a manner similar to that of the inbound analysis graph, but differs in the following two respects. (2-1) As the value of the state variable of the root node, the state variable value of the same node in the inbound analysis graph is used (instead of 1). (2-2) As for the state variables of nodes other than the root node, either a value calculated by tracing the dependency chain starting from the root node (a value calculated using the same procedure as in the first embodiment) or the state variable value of the same node in the inbound analysis graph can be arbitrarily selected and used. For example, assume that the state variable value of a vulnerability node other than the root node calculated by tracing the dependency chain from the root node is "0.7," while the state variable of the same node in the inbound analysis graph is "0.87." In this case, the larger (pessimistic) value of the two values, "0.87," can be used as the state variable of the vulnerability node. It should be noted that although there is a possibility that a plurality of outbound analysis graphs may be input to the risk analysis unit 62 from the risk identification unit 61, the risk analysis unit 62 analyzes the outbound analysis graphs one by one.

[0093] In a modified example, the risk assessment unit 63 can determine the acceptability of risk by processing the outbound analysis graph in the same way as by processing the inbound analysis graph. The risk assessment unit 63 can also determine suspicious external interfaces through which particularly suspicious communications are flowing based on their risk probability (state variable value) (e.g., by extracting external interfaces with a risk probability exceeding a certain threshold) and output this as threat information. By tracking outbound flows, the risk assessment unit 63 can identify the destination of data flowing out from an interface that is (highly likely to be) under attack, leading to rapid risk response operations such as packet filtering.

[0094] [Intrusion Response Unit 70] The intrusion response unit 70 includes a risk response unit 71 and a risk response proposal unit 72. The risk response unit 71 acquires a risk level, which is the estimated loss cost when a risk obtained as a result of risk assessment within the network system becomes apparent, compares the risk level with the costs of countermeasures, and identifies countermeasures with costs below the risk level as candidate countermeasures. The risk response proposal unit 72 proposes the candidate countermeasures identified by the risk response unit 71 to the system administrator.

[0095] [Risk Response Unit 71] When selecting candidate countermeasures, the risk response unit 71 considers "applicability" and the "trade-off between cost and risk level." Here, applicability means, for example, that a countermeasure based on a redundant system can be applied only to hosts that can quickly switch between the primary and secondary systems. The risk level is, for example, the amount of damage (or its expected value), and when the cost of applying a certain countermeasure is lower than the risk level, that countermeasure will be selected as a candidate.

[0096] The flow of processing by the risk response unit 71 will be described with reference to Fig. 12. First, the risk response unit 71 processes a terminal interface j∈J that is determined to require response. T and vulnerability u ∈U T and their risk levels j and l u and are respectively acquired from the risk assessment unit 63 (step S41). The risk response unit 71 also acquires the host that has communicated from the outside with the above-mentioned end interface j and its information as a threat from the risk assessment unit 63 (step S42). The risk response unit 71 also acquires a set of risk countermeasures from the database 50 (step S43). Note that the order of steps S41 to S43 is arbitrary.

[0097] Based on the information acquired in steps S41 and S43, the risk response unit 71 then identifies candidate countermeasures for each endpoint interface and candidate collective countermeasures (step S44), as described below. Based on the information acquired in steps S41 and S43, the risk response unit 71 also identifies candidate countermeasures for each vulnerability and candidate collective countermeasures (step S45), as described below. Based on the information acquired in steps S42 and S43, the risk response unit 71 also identifies candidate countermeasures for each threat and candidate collective countermeasures (step S46). The risk response unit 71 then outputs the candidate countermeasures identified in steps S44 to S46 to the risk response proposal unit 72 (step S47).

[0098] In the processing of step S44, the risk response unit 71 identifies candidate countermeasures for each interface (single unit) from among countermeasures related to the asset (interface), and also identifies candidate countermeasures for multiple interfaces if there are any. That is, as shown in FIG. 13, the risk response unit 71 first identifies the end interface j∈J that needs to be handled. T Here, a loop process is executed for each risk level l j The risk response unit 71 determines whether there is a smaller countermeasure (step S442). If there is a countermeasure (step S442: Yes), it selects it as a countermeasure candidate (step S443). If there is no countermeasure (step S442: No), step S443 is skipped. Next, the risk response unit 71 selects the above-mentioned end interface ∀j∈J T Regarding risk level l j The risk response unit 71 calculates the sum s of the above (step S444). Then, the risk response unit 71 determines whether there is a countermeasure that can be applied to multiple cases and whose cost is less than the sum s (step S445). If there is a countermeasure (step S445: Yes), it selects it as a batch countermeasure candidate (step S446) and returns to the main processing. On the other hand, if there is no countermeasure (step S445: No), step S446 is skipped.

[0099] In the process of step S45, when identifying candidates for countermeasures against vulnerabilities, as shown in FIG. 14, the risk response unit 71 similarly first identifies vulnerabilities u ∈ U that need to be addressed. T A loop process is executed for each risk level (S451). u The risk management unit 71 then determines whether there is a smaller countermeasure (step S452). If there is a countermeasure (step S452: Yes), it selects it as a countermeasure candidate (step S453). If there is no countermeasure (step S452: No), step S453 is skipped. Next, the risk management unit 71 T Regarding risk level l u The risk response unit 71 calculates the sum s of the above (step S454). Then, the risk response unit 71 determines whether there is a countermeasure that can be applied to multiple cases and whose cost is less than the sum s (step S455). If there is a countermeasure (step S455: Yes), it selects it as a batch countermeasure candidate (step S456) and returns to the main processing. On the other hand, if there is no countermeasure (step S455: No), step S456 is skipped.

[0100] In the processing of step S46, the process of identifying potential countermeasures against a threat is substantially similar to the process of identifying potential countermeasures against assets (interfaces) and vulnerabilities. For example, suppose the risk response unit 71 receives, as threat information, from the risk assessment unit 63, a list of IP addresses of hosts that are conducting malicious external communications with the system. In this case, the risk response unit 71 identifies filtering of packets sent from the acquired IP addresses as a potential countermeasure against the threat (see No. 8 in Figure 2). Also, suppose the risk response unit 71 receives, as threat information, information about a suspicious external interface from the risk assessment unit 63 of the modified example. In this case, the risk response unit 71 can consider measures such as filtering outbound communications to external interfaces determined to be "suspicious" as a countermeasure against the threat.

[0101] [Risk Response Proposal Unit 72] The risk response proposal unit 72 provides and proposes to the system administrator, etc., the information received from the risk response unit 71. The information acquired by the risk response proposal unit 72 includes candidate individual countermeasures for each asset (interface), candidate collective countermeasures for multiple assets (interfaces), candidate individual countermeasures for each vulnerability, candidate collective countermeasures for multiple vulnerabilities, candidate individual countermeasures for each threat, candidate collective countermeasures for multiple threats, etc.

[0102] As described above, the intrusion response unit 70 can identify various risk countermeasures using the risk response unit 71 and propose them to the system administrator or the like using the risk response proposal unit 72. Therefore, the intrusion response unit 70 can leave the final decision-making regarding the implementation of risk countermeasures entirely to the system administrator. Therefore, even if an incorrect countermeasure is proposed to the system administrator, the system administrator can correct the error.

[0103] [Variation 1 of Intrusion Response Unit 70] Variation 1 of the intrusion response unit 70 will be described below. The intrusion response unit 70 performs risk response using a database 50 (see, for example, FIG. 2 ) in which a plurality of countermeasures are registered in advance, but it can also be modified to register classification information in which these plurality of countermeasures are classified into two types in advance. In this case, classification information in which the plurality of countermeasures are classified in advance into Type 1, which should be applied after consulting a system administrator, and Type 2, which may be applied to the system without consulting a system administrator, is registered in the database 50. Here, Type 2 countermeasures are countermeasures that may be applied to the network system at the independent discretion of the risk response unit 71.

[0104] In the first modification, the risk response unit 71 first acquires the risk level obtained as a result of the risk assessment within the network system, compares the risk level with the cost of each countermeasure, and identifies countermeasures whose costs are lower than the risk level. The risk response unit 71 then extracts second-type countermeasures from the identified countermeasures. Furthermore, the risk response unit 71 narrows down the number of extracted second-type countermeasures and applies the narrowed-down second-type countermeasures to the network system.

[0105] Here, the risk response unit 71 can narrow down the number of extracted second-type countermeasures by selecting the one with the lowest cost from among the extracted second-type countermeasures. Alternatively, the risk response unit 71 can narrow down the number of extracted second-type countermeasures by preferentially selecting from among the extracted second-type countermeasures those that can be applied to multiple targets at once. Note that the method by which the risk response unit 71 narrows down the number of extracted second-type countermeasures is not limited to these, and for example, a system administrator or the like can determine any method.

[0106] The risk response unit 71 outputs detailed information about countermeasures (type 2 countermeasures) that it has applied to the network system at its own discretion, and candidate countermeasures (type 1 countermeasures) that should be decided by a system administrator or the like, to the risk response proposal unit 72. In variant example 1, the risk response proposal unit 72 reports the type 2 countermeasures applied by the risk response unit 71 to the system administrator, and proposes type 1 countermeasures that have not been applied.

[0107] [Variation 2 of the Intrusion Response Unit 70] Variation 2 of the intrusion response unit 70 is described below. In actual network operations, due to business constraints and other factors, it is not always possible to implement a full-scale risk response immediately after completing an assessment. In other words, it is often necessary to implement only a temporary response (emergency measure) on the spot and then move on to a full-scale response after a certain period of time has passed. To address such situations, the intrusion response unit 70 selects a countermeasure using a database 50 (see, for example, FIG. 2 ) in which multiple countermeasures are pre-registered. However, the intrusion response unit 70 can be modified so that the candidate countermeasures are not limited solely by cost (primarily monetary). In this case, the database 50 registers, as items associated with the countermeasure, numerical parameters for at least one of the response time and human labor required to implement the countermeasure. Here, human labor refers to the amount of time or work required by a person.

[0108] The database 50 according to the second modification will be described with reference to Fig. 15. As shown in Fig. 15, information on countermeasures is stored in the database 50. The information shown in Fig. 15 is acquired by the information input unit 30 (i.e., input by a system administrator) and used by the intrusion response unit 70 of the second modification. The example shown in Fig. 15 differs from Fig. 2 in that information related to item 105 is registered in the database 50. Item 105 indicates the response time required to implement the countermeasure.

[0109] 15, when countermeasure No. 1 or countermeasure No. 5 is implemented, the time until night falls is added. However, the number of countermeasures and the number of items associated with the countermeasures are just examples; for example, it is possible to add an item of "human operation" instead of "response time," or to register both the items of "response time" and "human operation."

[0110] In variant example 2, the risk response unit 71 compares the risk level with the cost of the countermeasures, identifies countermeasures with costs below the risk level, and then divides these into countermeasures suitable for temporary response and countermeasures suitable for full-scale response based on numerical parameters of response time or human operation, and outputs them to the risk response proposal unit 72.

[0111] For example, the risk response unit 71 can select risk countermeasures for each of interfaces, vulnerabilities, and threats, and then extract from the selected countermeasures those whose "response time" is below a certain threshold (e.g., 30) as countermeasures for "temporary responses." Alternatively, the risk response unit 71 can sort the selected countermeasures in ascending order of "response time" and output the sorted results (all selected countermeasures) to the risk response proposal unit 72. In this way, a system administrator or the like can prioritize the implementation of countermeasures that are more suitable for temporary responses. Note that it is also possible to combine Variation 1 with Variation 2.

[0112] [Hardware Configuration] The intrusion response unit (intrusion response device) 70 according to each of the above-described embodiments is realized by a computer 900 having a configuration such as that shown in Fig. 16. Fig. 16 is a hardware configuration diagram showing an example of the computer 900 that realizes the functions of the intrusion response unit 70 according to this embodiment. The computer 900 has a CPU (Central Processing Unit) 901, a ROM (Read Only Memory) 902, a RAM (Random Access Memory) 903, an HDD (Hard Disk Drive) 904, an input / output I / F (Interface) 905, a communication I / F 906, and a media I / F 907.

[0113] The CPU 901 operates based on programs stored in the ROM 902 or the HDD 904. The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started up, programs related to the hardware of the computer 900, and the like.

[0114] The CPU 901 controls an input device 910 such as a mouse or keyboard, and an output device 911 such as a display or printer, via an input / output I / F 905. The CPU 901 acquires data from the input device 910 via the input / output I / F 905, and outputs generated data to the output device 911. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 901.

[0115] The HDD 904 stores programs executed by the CPU 901 and data used by the programs. The communication I / F 906 receives data from other devices via the communication network 920 and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network 920.

[0116] The media I / F 907 reads a program or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads a program related to a target process from the recording medium 912 onto the RAM 903 via the media I / F 907, and executes the loaded program. The recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase Change Rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical Disk), a magnetic recording medium, or a semiconductor memory.

[0117] For example, when the computer 900 functions as the intrusion response unit 70 according to each of the above-described embodiments, the CPU 901 executes a program loaded onto the RAM 903 to realize the function of the intrusion response unit 70. Furthermore, the HDD 904 stores data in the RAM 903. The CPU 901 reads and executes a program related to a target process from the recording medium 912. Alternatively, the CPU 901 may read a program related to a target process from another device via the communication network 920.

[0118] [Effects] As described above, the intrusion response device is an intrusion response device 70 that responds to risks in a network system, and is characterized by comprising: a memory unit 904 that stores a database 50 in which a plurality of countermeasures for security risks related to information assets, vulnerabilities, and threats in the network system and at least the cost of the countermeasure as an item associated with each countermeasure are pre-registered; a risk response unit 71 that acquires a risk level, which is the estimated cost of loss when a risk obtained as a result of a risk assessment in the network system becomes apparent, compares the risk level with the cost of the countermeasure, and identifies countermeasures having costs below the risk level as candidate countermeasures; and a risk response proposal unit 72 that proposes the candidate countermeasures identified by the risk response unit 71 to a system administrator.

[0119] By doing so, the intrusion response device compares the cost of the countermeasure with the cost (risk level) of the actual risk and determines which countermeasure to apply. Therefore, in response to Problem 1 in the prior art, the intrusion response device 70 simplifies the procedure for identifying risk countermeasures and reduces computational costs. Furthermore, in response to Problem 2 in the prior art, the intrusion response device 70 identifies consistent risk countermeasures from the same input information, ensuring consistent effectiveness of the countermeasures. Furthermore, in response to Problem 3 in the prior art, the intrusion response device 70 clarifies the cost-effectiveness of each countermeasure. Therefore, the intrusion response device solves the problems of the prior art and automates and mechanizes a series of risk management tasks. Such automation and mechanization not only reduce human labor (human work time and workload) but also speed up the management process and prevent human error.

[0120] The intrusion response device is an intrusion response device (70) that responds to risks in a network system, and is characterized by comprising: a memory unit (904) that stores a database (50) in which a plurality of countermeasures for security risks related to information assets, vulnerabilities, and threats in the network system, at least the cost of the countermeasure as an item associated with each countermeasure, and classification information in which the plurality of countermeasures are pre-classified into first type that should be applied after consulting a system administrator and second type that may be applied to the system without consulting a system administrator; a risk response unit (71) that acquires a risk level that is an estimated loss cost when a risk obtained as a result of a risk assessment in the network system becomes apparent, compares the risk level with the cost of the countermeasures, identifies countermeasures whose costs are below the risk level, extracts second-type countermeasures from among them, narrows down the number of extracted second-type countermeasures, and applies the narrowed-down second-type countermeasures to the network system; and a risk response proposal unit (72) that reports the second-type countermeasures applied by the risk response unit (71) to the system administrator and proposes first-type countermeasures that have not been applied.

[0121] By doing this, the risk response unit 71 in the intrusion response device compares the cost of the countermeasure with the cost (risk level) if the risk becomes apparent and determines which countermeasure to apply, resulting in a simple procedure for identifying the countermeasure and low computational cost. Furthermore, because the risk countermeasures identified from the same input information are consistent, the effectiveness of the countermeasures is consistent, and the cost-effectiveness of each countermeasure can be clarified. Furthermore, the risk response unit 71 can quickly respond to risks without waiting for a system administrator's decision. Therefore, the intrusion response device solves the problems of conventional technology and automates and mechanizes a series of risk management tasks.

[0122] In the intrusion response device, database 50 stores, as items associated with countermeasures, numerical parameters for at least one of the response time and human operations required to implement the countermeasures, and risk response unit 71 compares the risk level with the cost of the countermeasures to identify countermeasures with costs below the risk level, and then, based on the numerical parameters of the response time or human operations, classifies these into countermeasures suitable for temporary response and countermeasures suitable for full-scale response, and outputs the results to risk response proposal unit 72.

[0123] In this way, the intrusion response device 70 determines which risk response measures are suitable for provisional risk responses and which are suitable for full-scale risk responses, taking into account the time and human effort required to implement the response measures. This allows the system administrator or the like to choose between provisional and full-scale risk responses, enabling flexible risk responses according to the system's operational status.

[0124] The intrusion response method is an intrusion response method for an intrusion response device 70 that responds to risks in a network system, and the intrusion response device 70 has a memory unit 904 that stores a database 50 in which a plurality of countermeasures for security risks related to information assets, vulnerabilities, and threats within the network system and at least the cost of the countermeasures as an item associated with each countermeasure are pre-registered, and is characterized by performing the steps of acquiring a risk level, which is the estimated cost of loss when a risk obtained as a result of a risk assessment within the network system becomes apparent, comparing the risk level with the cost of the countermeasures, and identifying countermeasures with costs below the risk level as candidate countermeasures, and proposing the identified candidate countermeasures to a system administrator.

[0125] In this way, in the intrusion response method, the intrusion response device 70 compares the cost of a countermeasure with the cost (risk level) if the risk becomes apparent, and determines which countermeasure to apply. Therefore, the procedure for identifying countermeasures is simple and computationally inexpensive. Furthermore, because the risk countermeasures identified from the same input information are consistent, the effectiveness of the countermeasures is consistent, and the cost-effectiveness of each countermeasure can be clarified. Therefore, the intrusion response device solves the problems of the prior art and automates and mechanizes a series of risk management tasks.

[0126] The intrusion response method is an intrusion response method for an intrusion response device that responds to risks in a network system. The intrusion response device includes a memory unit that stores a database in which a plurality of countermeasures for security risks related to information assets, vulnerabilities, and threats in the network system, at least the cost of the countermeasure as an item associated with each countermeasure, and classification information that pre-classifies the plurality of countermeasures into a first type that should be applied after consulting a system administrator and a second type that may be applied to the system without consulting a system administrator, and is characterized by performing the steps of: acquiring a risk level that is an estimated loss cost when a risk obtained as a result of a risk assessment in the network system becomes apparent; comparing the risk level with the cost of the countermeasures; identifying countermeasures that have costs below the risk level; extracting second-type countermeasures from among them; narrowing down the number of extracted second-type countermeasures; and applying the narrowed-down second-type countermeasures to the network system; and reporting the applied second-type countermeasures to the system administrator and proposing the first-type countermeasures that have not been applied.

[0127] By doing so, in the intrusion response method, the intrusion response device 70 compares the cost of a countermeasure with the cost (risk level) if the risk becomes apparent and determines which countermeasure to apply. Therefore, the procedure for identifying a countermeasure is simple and computationally inexpensive. Furthermore, because the risk countermeasures identified from the same input information are consistent, the effectiveness of the countermeasures is consistent, and the cost-effectiveness of each countermeasure can be clarified. Furthermore, the intrusion response device 70 can quickly respond to risks without waiting for a system administrator's decision. Therefore, the intrusion response device solves the problems of conventional technology and automates and mechanizes a series of risk management tasks.

[0128] The intrusion response system includes a network information acquisition unit 10 that automatically collects security information relating to information assets, vulnerabilities, and threats within a network system having a plurality of hosts, the security information being collected by a plurality of security devices installed within the network system; a host anomaly detection unit 20 that acquires detection information relating to host anomalies from security software installed in the hosts within the network system; and a database that associates the security information acquired by the network information acquisition unit 10 with the time at which the security information was collected and stores the association information in association with the time at which the detection information was collected, and stores the association information in association with the time at which the detection information was collected. The system is characterized by comprising a data processing unit 40 that stores information on a base 50, a risk identification unit 61 that identifies security risks inherent in the network system and sources of external threats based on security information stored in the database 50, creates an analysis graph that describes the probabilistic dependencies of the identified security risks in the form of a directed acyclic graph, and adds nodes that indicate the sources of the identified external threats to the analysis graph, a risk analysis unit 62 that calculates risk probabilities related to the state of the nodes using the detection information and analysis graph stored in the database 50, a risk assessment unit 63 that calculates risk levels based on the risk probabilities and predetermined asset value information, and an intrusion response device 70.

[0129] In this way, in the intrusion response system, the intrusion response device 70 acquires the risk level calculated by the risk assessment unit 63 as the result of risk assessment within the network system, compares the risk level with the cost of countermeasures, and proposes countermeasures with costs lower than the risk level as candidate countermeasures to the system administrator. The intrusion response system 1 can also automate the entire process, from information collection to risk identification, risk analysis, risk assessment, and risk response. This automation also makes it easier for system administrators without advanced specialized knowledge to perform risk management, minimizing the possibility of human error.

[0130] The present invention is not limited to the above-described embodiments, and many modifications can be made by a person skilled in the art within the scope of the technical concept of the present invention. For example, a database storing the information shown in Figure 2 may be provided separately from the database storing the information shown in Tables 1 to 3.

[0131] REFERENCE SIGNS LIST 1 intrusion response system 10 network information acquisition unit 11 network flow information acquisition unit 12 vulnerability information acquisition unit 13 threat information acquisition unit 20 host abnormality detection unit 30 information input unit 40 data processing unit 50 database 60 risk assessment unit 61 risk identification unit 62 risk analysis unit 63 risk evaluation unit 70 intrusion response unit (intrusion response device) 71 risk response unit 72 risk response proposal unit

Claims

1. An intrusion response device that responds to risks in a network system, comprising: a memory unit that stores a database in which a plurality of countermeasures for security risks related to information assets, vulnerabilities, and threats within the network system and at least the cost of the countermeasures as an item associated with each countermeasure are pre-registered; a risk response unit that acquires a risk level, which is the estimated cost of loss when a risk obtained as a result of a risk assessment within the network system becomes apparent, compares the risk level with the costs of the countermeasures, and identifies countermeasures having costs below the risk level as candidate countermeasures; and a risk response proposal unit that proposes the candidate countermeasures identified by the risk response unit to a system administrator.

2. An intrusion response device for responding to risks in a network system, comprising: a memory unit for storing a database in which a plurality of countermeasures for security risks related to information assets, vulnerabilities, and threats in the network system, at least the cost of the countermeasures as items associated with each countermeasure, and classification information in advance classifying the plurality of countermeasures into a first type that should be applied after consulting a system administrator and a second type that may be applied to the system without consulting a system administrator; a risk response unit for acquiring a risk level that is an estimated loss cost when a risk obtained as a result of a risk assessment in the network system becomes apparent, comparing the risk level with the costs of the countermeasures, identifying countermeasures having costs below the risk level, extracting the second type countermeasures from among them, narrowing down the number of extracted second type countermeasures, and applying the narrowed down second type countermeasures to the network system; and a risk response proposal unit for reporting the second type countermeasures applied by the risk response unit to the system administrator and proposing first type countermeasures that have not been applied.

3. The intrusion response device of claim 1, characterized in that the database registers numerical parameters for at least one of the response time and human work required to implement the countermeasure as items associated with the countermeasure, and the risk response unit compares the risk level with the cost of the countermeasure to identify countermeasures having costs below the risk level, and then, based on the numerical parameters of the response time or human work, classifies them into countermeasures suitable for a temporary response and countermeasures suitable for a full-scale response, and outputs them to the risk response proposal unit.

4. The intrusion response device described in claim 2, characterized in that the database registers numerical parameters for at least one of the response time and human work required to implement the countermeasure as items associated with the countermeasure, and the risk response unit compares the risk level with the cost of the countermeasure to identify countermeasures having costs below the risk level, and then, based on the numerical parameters of the response time or human work, classifies them into countermeasures suitable for a temporary response and countermeasures suitable for a full-scale response, and outputs them to the risk response proposal unit.

5. An intrusion response method of an intrusion response device that responds to risks in a network system, the intrusion response device having a memory unit that stores a database in which a plurality of countermeasures for security risks related to information assets, vulnerabilities, and threats in the network system and at least the cost of the countermeasures as an item associated with each countermeasure are pre-registered, the intrusion response method executing the steps of: acquiring a risk level which is the estimated cost of loss when a risk obtained as a result of a risk assessment in the network system becomes apparent, comparing the risk level with the cost of the countermeasures, and identifying countermeasures having a cost below the risk level as candidate countermeasures; and proposing the identified candidate countermeasures to a system administrator.

6. An intrusion response method for an intrusion response device that responds to risks in a network system, the intrusion response device comprising: a storage unit that stores a database in which a plurality of countermeasures for security risks related to information assets, vulnerabilities, and threats in a network system, at least the cost of the countermeasure as an item associated with each countermeasure, and classification information in advance classifying the plurality of countermeasures into a first type that should be applied after consulting a system administrator and a second type that may be applied to the system without consulting a system administrator, are registered; the intrusion response method executes the steps of: acquiring a risk level that is an estimated loss cost when a risk obtained as a result of a risk assessment in the network system becomes apparent, comparing the risk level with the costs of the countermeasures, identifying countermeasures having costs below the risk level, extracting the second type countermeasures from among them, narrowing down the number of extracted second type countermeasures, and applying the narrowed down second type countermeasures to the network system; and reporting the applied second type countermeasures to the system administrator and proposing unapplied first type countermeasures.

7. A network information acquisition unit that automatically collects security information relating to information assets, vulnerabilities, and threats in a network system having a plurality of hosts, the security information being collected by a plurality of security devices installed in the network system; a host anomaly detection unit that acquires detection information relating to anomalies in the hosts in the network system from security software installed in the hosts; a data processing unit that associates the security information acquired by the network information acquisition unit with the time at which the security information was collected and stores the association in a database, and also associates the detection information acquired by the host anomaly detection unit with the time at which the detection information was collected and stores the association in a database; a risk identification unit that identifies security risks inherent in the network system and sources of external threats based on the security information stored in the database, creates an analysis graph that describes the probabilistic dependencies of the identified security risks in the form of a directed acyclic graph, and adds a node indicating the source of the identified external threat to the analysis graph; a risk analysis unit that calculates a risk probability relating to the state of a node using the detection information stored in the database and the analysis graph; a risk assessment unit that calculates the risk level based on the risk probability and predetermined asset value information; An intrusion response system comprising: an intrusion response device according to any one of claims 1 to 4.

8. A program for causing a computer to function as an intrusion response device according to any one of claims 1 to 4.

Images