13.3. Dynamic Decision-Making Systems

13.3.1. Broad Research Issues

Dynamic decision-making-based IRS involves the process of reasoning about an ongoing attack based on observed alerts and determining an appropriate response to take. There have been various designs and architectures proposed for this kind of dynamic decision-making-based IRS system. However, the core issue underlying all these systems is how the decision making should be achieved. Many factors can contribute to and complicate the decision-making process. For instance, a response can come with a certain cost such as the computation resource required for executing the response and the negative impact on the system after the execution of this response. Also, a response can fail with some probability. So, at the highest level of abstraction for each applicable response option, an IRS has to consider both the outcome from deploying the specific response and not deploying it, and makes a decision between these two choices based on some metric. From this point, we can see three potential research issues regarding dynamic decision-making-based IRSs. One is modeling the effect of an attack on a system, and this is directly related to the outcome from a decision on not using any response. The second issue is modeling the effect of the responses, and this is related to the outcome from a decision on using responses. Finally, there’s the issue of how to decide the set of responses for deployment for a given attack, considering that responses are deployed on different hosts or services in a distributed environment and that they are not all independent.

There has been some work done on modeling the effect from responses and incidents. For example, Balepin et al. [5] propose the “gain matrix,” which formulates the effect of using response A_k in a system with M potential states S₁, S₂,...,S_M as:

(q₁a_k1 + q₂a_k2 + ... + q_ma_km)

where q_i is the probability of the system being in state S_i and a_ki is the benefit from using response A_k in state S_i. The benefit is derived from the response cost (say, in terms of negative impact on functional services), the likelihood of success of the response, and the potential damage from the system remaining in that system state. Following this formulation, the “optimal” response A_i from a set of response alternatives {A₁,A₂,...,A_N} is determined by:

The gain matrix brings out two challenging facts in the design and implementation of a dynamic decision-making-based IRS. One is the number of system states to be considered. There are likely to be a vast number of states for a real production system and this would preclude any approach that relies on statically enumerating the states and creating the responses in each state. This underpins the desirability of dynamic intrusion response approaches. An example is the work by Toth and Kruegel [10], in which they use a dependency tree structure to dynamically calculate the impact on a system from a response.

The second challenge is about selecting the optimal set of responses in real time. A response plan is composed of multiple response operations that will be carried out in a certain sequence and at specific times. For example, {tightening the firewall rules for the entry point to the network at time x, rebooting the web server at time y, and resetting the firewall rules at time z} is a response plan composed of three response operations. Now, consider that the IRS has a choice of N response operations, say one each at a service site. There can be at least 2^N – 1 possible response plans even without considering the timings in the sequence of response operations. This imposes a challenge on the response decision process, which is to pick the best choice from all potential plans. A naive dynamic approach of scanning through the gain matrix and evaluating the expected gain for the large number of response plans will not work well, in general, since an IRS usually has to respond to incidents in a timely manner. Existing work, such as ADEPTS [26, 27], relies on heuristics for limiting the size of the set of response plans by considering only the response operations that are applicable near the sites where an incident was detected. ADEPTS also evaluates the responses with respect to a local optimality criterion (e.g., effect on the specific service, rather than on the system as a whole). While this is certainly an improvement over static decision-making-based IRS systems, much work needs to be done to determine how good a given heuristic is for a specific payload system. Now we provide the details of some representative dynamic IRSs.

13.3.2. ADEPTS

Design Approach

ADEPTS [26, 27] makes use of the characteristics of a distributed application in guiding its response choices. It considers the interaction effects among the multiple services both to accurately identify patterns of the intrusions relevant to the response process (e.g., cascading failures due to service interactions) and to identify the effectiveness of the deployed response mechanism. In designing an IRS, a possible approach is to consider different attacks and provide a customized sequence of response actions for each step in an attack. A second approach, subtly yet significantly different, is to consider the constituent services in the system and the different levels of degradation of each individual service due to a successful attack. For easier understanding, one may visualize a malicious adversary who is trying to impact the constituent services (the subgoals) with the overall goal of either degrading some system functionality (e.g., no new orders may be placed to the e-store) or violating some system guarantee (e.g., credit card records of the e-store customers will be made public). In ADEPTS, the authors take the latter approach. This is motivated by the fact that the set of services and their service levels are finite and reasonably well understood, while the possible universe of attack sequences is potentially unbounded. They focus on the manifestations of the different attacks as they pertain to the services rather than the attack sequence itself. This leads them to use a representation called an intrusion graph (I-Graph), where the nodes represent subgoals for the intrusion and the edges represent preconditions/postconditions between the goals. Thus, an edge may be OR/AND/Quorum indicating any, all, or a subset, respectively, of the goals of the nodes at the head of the edge that need to be achieved before the goal at the tail can be achieved.

In ADEPTS, the response choice is determined by a combination of three factors: static information about the response, such as how disruptive the response is to normal users; dynamic information, which is essentially the history of how effective the response has been for a specific class of intrusion; and out-of-band parameters of the response, such as expert system knowledge of an effective response for a specific intrusion or policy-determined response when a specific manifestation occurs. Importantly and distinct from other work, ADEPTS points out the need for the IRS to provide its service in the face of unanticipated attacks. Thus, it does not assume that the I-Graph is complete nor that there is a detector to flag whenever an I-Graph node is achieved. However, it assumes that the intrusion will ultimately have a manifested goal that is detectable. ADEPTS also considers the imperfections of the detection system that inputs alerts to it. The detectors would have both type I and type II errors, that is, false alarms and missed alarms. If false alarms are not handled, this can cause the IRS to take unnecessary responses, potentially degrading the system functionality below that of an unsecured system. If missed alarms (or delayed alarms) are not compensated for, the system functionality may be severely degraded despite the IRS. ADEPTS can coexist with off-the-shelf detectors and estimates the likelihood that an alarm from the detection system is false or there is a missing alarm. The algorithm is based on following the pattern of nodes being achieved in the I-Graph with the intuition that a lower-level subgoal is achieved with the intention of achieving a higher-level subgoal.

The design of ADEPTS is realized in an implementation that provides intrusion response service to a distributed e-commerce system. The e-commerce system mimics an online bookstore system and two auxiliary systems for the warehouse and the bank. Real attack scenarios are injected into the system with each scenario being realized through a sequence of steps. The sequence may be nonlinear and have control flow, such as trying out a different step if one fails. ADEPTS’ responses are deployed for different runs of the attack scenarios with different speeds of propagation, which bring out the latency of the response action and the adaptive nature of ADEPTS. The survivability of the system is shown to improve over a baseline system, with a larger number of runs leading to greater improvement.

Contributions and Further Work

ADEPTS presents a worthy framework for reasoning about and responding to multistage attacks in systems that have the nondeterminism and imperfections of real-world distributed systems. It provides fundamental algorithms for diagnosis of the affected service, taking proactive response and evaluating the effect of a response by observing further alerts in the system.

However, the responses in ADEPTS only achieve a local optima and are deployed in sites close to where the detector flagged the alarm. It is unclear how close ADEPTS can get to the theoretically best achievable response. Also, ADEPTS needs to consider variants of previously observed attack scenarios and completely unanticipated attack scenarios.

13.3.3. ALPHATECH Light Autonomic Defense System

Design Approach

This is a host-based autonomic defense system (ADS) using a partially observable Markov decision process (PO-MDP) that is developed by a company called ALPHATECH, which has since been acquired by BAE systems [28–30]. The system ALPHATECH Light Autonomic Defense System (α LADS) is a prototype ADS constructed around a PO-MDP stochastic controller. The main thrust of the work has been the development, analysis, and experimental evaluation of the controller. At the high level, Armstrong et al. [28, 29] and Kriedl and Frazier [30] have two goals for their ADS: it must select the correct response in the face of an attack and it must not take actions to attacks that are not there, notwithstanding noisy signals from the IDS.

The overall framework is that the system has a stochastic feedback controller based on PO-MDP that takes its input from a commercially available anomaly sensor (CylantSecure, from Software Systems International, Cyland Division, http://www.cylant.com/), calculates the probability that the system may be in an attack state, and invokes actuators to respond to a perceived attack. The system is partially observable because the sensors (the intrusion detectors) can give imperfect alerts; the system is also partially controllable since the effect of an action by the ADS will not deterministically bring the system back to a functional state.

The authors set up PO-MDP formulas to determine for each x ϵ X,b_k(x) = Pr(x_k = x/I_k), where I_k denotes the set of the first k observations received and all controls selected through the (k – 1)st decision stage. Let B_k = {b_k (x): x ϵ X} be the set of all individual state estimates after the kth observation. The objective is to choose a response policy μ that outputs the selected control u_k = μ(B_k) (as a function of B_k). The choice of the optimal response is given by:

where α*(u, x), for each u ϵ U and x ϵ X, is proportional to the optimal cost-to-go, given current state x_k = x and current decision u_k = u. That is, α*(u,x) is the expected cost obtained through an optimal selection of controls at future decision stages, given current state x_k = x and current decision u_k = u. However, determining the optimal response policy that minimizes the infinite horizon cost function is intractable and heuristics must be applied to find near-optimal policies. The heuristics Armstrong et al. [28, 29] and Kriedl and Frazier [30] apply is to consider the single-step combination of current state and control.

For the evaluation, the authors build a Markov state model for the worm attack on a host. The prototype ADS receives observations from two intrusion detector sensors. One intrusion detector sensor monitors activities on the IP port and the other sensor monitors processes operating on the host computer. These two sensors are calibrated against activity that is determined to be representative of how the computer system will typically be used. For the experiments, the training data were a combination of stochastic http and ftp accesses plus random issuances of commands that are commonly used by operators of Linux. The first experiment demonstrates that an ADS built on a feedback controller is less likely to respond inappropriately to authorized system activity than a static controller (i.e., is less susceptible to noises from the detection system) and is thus able to effectively use a more sensitive anomaly detector than a static controller. The second experiment demonstrates the ability to respond to attacks not seen before—α LADS was trained with a worm attack on the ftp server and able to thwart similar worm attacks to the named and rpcd servers. The surprising result is αLADS is able to thwart every single instance of the not-seen-before attacks. To interpret the results, a crucial piece of information is the degree of similarity between the different worms, which is not available in the published papers.

Contributions and Further Work

The work is significant in its use of a formal modeling technology (i.e., PO-MDP) in intrusion response. The design is rigorous and while the modeling technique has the challenge of determining the correct transition matrix from suitable training data, this challenge is not unique to the αLADS system. It is expected that the work will mature and use more sophisticated techniques for creation of the matrices that are available in related literature.

What has gotten short shrift in this work is the development of the actual responses that would be effective in a distributed environment. In fact, their experiments only use the ability to kill a process or shutdown a computer (apart from just observation or human notification). The system has to be made hierarchical and distributed so that it can respond to attacks in different parts of a distributed infrastructure.

13.3.4. Cooperating Security Managers and Adaptive, Agent-Based Intrusion Response Systems

Design Approach

Both systems come from the same research group with cooperating security managers (CSMs) preceding adaptive, agent-based intrusion response system (AAIRSs) in chronology. CSM is designed to be used as an intrusion detection tool in a large network environment. CSM follows an approach in which individual intrusion detection monitors can operate in a cooperative manner, without relying on a centralized director to perform the network intrusion detection. To stress the role of the individual components in managing intrusions, not just monitoring them, the term used is security managers. CSM employs no centralized director; instead, each of the individual managers assumes this role for its own users when that manager suspects suspicious activity. Each CSM reports all significant activity to the CSM for the host from which the connection originated. This enables CSM to track a user as he or she travels from one host to another in a distributed environment.

If an intruder is suspected or detected, it is up to the intruder-handling (IH) component to determine which action to take. This is where the intrusion response capability is embedded in CSM. The responsibility of the IH module is to take appropriate actions when intrusive activity is detected. Performing a specific action in response to an abuse will depend on the perceived severity of the detected abuse. Simple notification of the system manager on the detecting system is still the first step. The second step is to also notify all other CSMs in the trail for this user. This information is obtained from the user-tracking module. Beyond this, several other activities may be deemed appropriate. Two actions would be to kill the current session of the suspected intruder and to lock the account that was used to gain access so the intruder cannot simply return. However, they have to be done with care only when the evidence is strong and the disruption due to lack of response is severe.

A later work coming from the same group is the AAIRS [20, 21]. In AAIRS, multiple IDSs monitor a computer system and generate intrusion alarms. The interface agents receive the alerts and use an iteratively built model of false alerts and missed alerts from the detectors to generate an attack-confidence metric. The agents pass this metric along with the intrusion report to the master analysis agent. The master analysis agent classifies whether the incident is a continuation of an existing incident or is a new attack using several different parameters, such as the target application and target port. The decision algorithm for determining if an alarm corresponds to a new attack or an existing attack is adopted by other systems, such as ADEPTS.

If the master analysis agent determines this is a new attack, it creates a new analysis agent for handling this attack. The analysis agent analyzes an incident and generates an abstract course of action to resolve the incident, using the response taxonomy agent from Hiltunen et al. [18] to classify the attack and determine a response goal. The analysis agent passes the selected course of action to the tactics agent, which decomposes the abstract course of action into very specific actions and then invokes the appropriate components of the response toolkit.

The proposed methodology provides response adaptation through three components: the interface, analysis, and tactics agents. The interface agent adapts by modifying the confidence metric associated with each IDS. As the analysis components receive additional incident reports, these reports may lead to reclassification of the type of attacker and/or type of attack. This reclassification may lead to the formulation of a new plan or a change in how the response goal is accomplished. The analysis component may change the plan steps being used to accomplish the goal if alternative steps are available and can be substituted into the plan. Alternatively, the tactics components may have multiple techniques for implementing the plan step and adapt by choosing alternate steps. These components maintain success metrics on their plans and actions, respectively, and weight the successful ones so that they are more likely to be taken in subsequent instances of an attack.

The work provides a good framework on which the IRS can be built. However, it does not provide any of the system-level techniques and algorithms that will be required for the AAIRS to work in practice. It leaves many unanswered questions, most important of which are: How is the algorithm to determine a sequence of response actions to an incident, how does the system measure the success of previous responses, or how are multiple concurrent attacks handled?

Contributions and Further Work

CSM highlights the trade-offs to be made in any autonomous response system. Its module for tracking a user and the architecture for distributed detection are valuable in an IRS for a distributed system. However, the work is lacking in system-level details and actual design decisions made for a specific application context. The evaluation does not shed any light on the IH component of the system.

AAIRS presents a compelling architecture with different modules that make up an IRS. The modules are at two basic levels of abstraction: application system neutral and application system specific. These levels are important to the extensibility of an IRS to new applications. AAIRS also raises important concerns for any IRS: the imperfections of any IDS both for false alarms and missed alarms have to be accounted for in the IRS and there should be feedback about the success or failure of a deployed response. However, the work is lacking in specific algorithms for any of the steps of an IRS. There are no system-level details provided and this is especially critical for IRS since many trade-offs in algorithms are brought out by actual implementations and deployments. The system description indicates competent system administrators may still need to be involved in the loop (e.g., in manually determining if an alert from an IDS was a false one).

13.3.5. Emerald

Design Approach

Event Monitoring Enabling Responses to Anomalous Live Disturbances (EMERALD) developed an architecture that inherits well-developed analytical techniques for detecting intrusions and cast them in a framework that is highly reusable, interoperable, and scalable in large network infrastructures [8, 31]. Its primary goal is not to perform automated intrusion response. However, its modular structure and tools can enable effective response mechanisms.

The primary entity within EMERALD is the monitor, with multiple monitors deployed within each administrative domain. The monitors may interact with the environment passively (reading activity logs or network packets) or actively (via probing that supplements normal event gathering). The monitors may interact with one another. An EMERALD monitor has a well-defined interface for sending and receiving event data and analytical results from third-party security services. An EMERALD monitor is capable of performing both signature analysis and statistical profile-based anomaly detection on a target event stream. The work on these components represent state-of-the-art development in the intrusion detection literature within each domain. In addition, each monitor includes an instance of the EMERALD resolver, a countermeasure decision engine capable of fusing the alerts from its associated analysis engines and invoking response handlers to counter malicious activity.

A feature that makes EMERALD well suited to intrusion response in a distributed environment is its capability for alert aggregation. This is achieved through a tiered arrangement of monitors and exchange of CIDF-based [32] alert information. Thus, resolvers are able to request and receive intrusion reports from other resolvers at lower layers of the analysis hierarchy, enabling the monitoring and response to global malicious activity. Each resolver is capable of invoking real-time countermeasures in response to malicious or anomalous activity reports produced by the analysis engines. The countermeasures are defined in a field specific to the resource object corresponding to the resource in which the monitor is deployed. Included with each valid response method are evaluation metrics for determining the circumstances under which the method should be dispatched. These criteria are the confidence of the analysis engine that the attack is real and the severity of the attack. The resolver combines the metrics to formulate its monitor’s response policy.

Contributions and Further Work

An important lesson from the design of EMERALD is the separation of generic and target-specific parts of the system. Target-specific refers to the service (FTP, SSH) and the hardware resource (router) that EMERALD is deployed on. This design approach simplifies reusability of components and extensibility and enhances integration with other data sources, analysis engines, and response capabilities. While we see the great potential in EMERALD to build automatic responses in the resolver, we did not find any detailed description of its capabilities or its application. The infrastructure provides the common EMERALD API, event-queue management, error-reporting services, secondary storage management (primarily for the statistical component), and internal configuration control. The statistical and P-BEST (Production-Based Expert System Tool) components are integrated as libraries and provide powerful intrusion detection capabilities. The EMERALD API can likely be used to build a powerful intrusion response engine. However, this has not been reported in the project.

13.3.6. Other Dynamic Intrusion Response Systems

There are some other systems that employ dynamic decision making for intrusion response. In the interest of space, we will limit the discussion of these systems to their key contributions.

In general, dynamic decision-making-based IRS is a promising technology that is still in its nascent phase. There is scarce deployment of them in real-world production systems, at least what is reported in open literature. Part of the reason is the many open issues that need to be solved before generalizable design principles can be presented. For example, the heterogeneity among real-world systems has been an obstacle for modeling the effect on a system from incidents and responses. In a sense, an IRS has to figure out what are the services in the system, what are their functionalities, what are the interactions among them, and what are the effects of a response on the system. Each of these is a topic of active research in distinct fields, such as system management. Besides, there are many properties in the response decision-making process that need to be quantitatively modeled and analyzed, such as the optimality of a response. There is surprisingly little in the way of comparative evaluation of the different techniques with respect to each other and with respect to an idealized scenario. We believe this is an exciting field of development in IRS technology and we hope to see many worthwhile research efforts in it in the years to come.