Automating cyber-defense management

Automating Cyber-Defense Management Partha Pal, Franklin Webber, Michael Atighetchi and Paul Rubel Paul Benjamin BBN Technologies 10 Moulton Street Cambridge, MA 02138 Pace University 1 Pace Plaza New York, NY 10038 {ppal,fwebber,matighet,prubel}@bbn.com [email protected] ABSTRACT Last year, we reported [1] our success in setting a new high-water mark for intrusion tolerance. That success can largely be attributed to our use of a “survivability architecture”, which refers to the organization of a set of concrete defense mechanisms for preventing intrusion, and for detecting and responding to intrusions that cannot be prevented. The system defense-enabled with the DPASA survivability architecture [2] showed a high level of resistance to sustained attacks by sophisticated adversaries, but needed expert operators to perform the role of an “intelligent control loop”—interpreting the events reported by the survivable system as well as deciding in some cases which defense mechanisms to actuate. We took the position that the survivability architecture must be extended to include part, if not all, of the functionality of the intelligent control loop. This paper is a work in progress report of our current research attempting to introduce a cognitive control loop into survivability architectures. Categories and Subject Descriptors D.4.6 [Security and Protection], C.2.4 [Distributed Systems], K.6 [Management of Computing and Information Systems] Keywords Survivability, Intrusion-tolerance, Survivability Architecture, Defense-enabling, Defense Mechanisms 1. INTRODUCTION In the last workshop we reported our work on the DPASA survivability architecture, and the successes of an intrusion tolerant system that was based on the DPASA survivability architecture [2]. The DPASA survivability architecture integrated a number of defense mechanisms including cryptographic identity management and access control, IPSEC based network security, digital signatures, redundancy and adaptive middleware. Collectively, these mechanisms combined three essential elements of cyber-defense namely, protection, detection and adaptive response. The intrusion tolerant system showed excellent resiliency in thwarting, bypassPermission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Workshop on Recent Advances in Intrusion Tolerant Systems’08, April 1, 2008, Glasgow, Scottland. Copyright 2008 ACM 1-58113-000-0/00/0004 $5.00. 1 1 ing or gracefully degrading service levels in order to survive the attacks. However, as expected of a high-water mark research prototype, it needed expert operators to interpret the information it captures and to use the provided response mechanisms effectively. In other words, the human experts needed to play the role of an “intelligent control loop” supervising the tightly configured organization of various defense mechanisms. We took the position that part, if not all, of the intelligent control loop functionality should be included in the survivability architecture. Apart from a challenging problem in and of itself, we were motivated by practical reasons as well as a long term vision. First, it is impractical to deploy every intrusion tolerant system with a set of human experts to act as the intelligent control loop; functions that are beyond the grasp of typical users of these systems had better be automated. Second, a cognitive capability that does not simply react to observed conditions [as is the case in most control systems and system autonomics] but tries to interpret the implications, evaluates possible explanations and courses of action, and decides the most effective next step(s) under the circumstances is also the enabler of sophisticated adaptive behavior that is in the sight of our long term research objectives—building better managed and self adaptive distributed information systems. Clearly, many such cognitive loops with varying scope can exist in a system. In this position paper we restrict our focus to the outermost – the control loop that has a system-wide focus and has the most opportunity to do deep semantic interpretation of observations. In the remainder of this paper we will first describe and present an analysis of the main challenge we plan to address in this research. Next we describe the solution approach, followed by a discussion of the current state and capability. We conclude with a forward looking discussion of where this research is headed. 2. PROBLEM DEFINITION Survivability architectures combine three basic types of defensive capability (as noted earlier, they are protection, detection and adaptive reaction) in a way where overlapping defenses are synergistically integrated with the application functionality. In (intrusion tolerant) systems with survivability architecture, there is no shortage of information. Detection focused defensive capabilities implemented by traditional IDS and application embedded sensors, as well as other types of defense mechanisms ranging from resource and redundancy management, policy enforcement, and middleware services capture quite a bit of information about the state of the system as well as the incidents and con- This research was funded by DARPA under Navy Contract No. N00178-07-C-2003. In that restricted sense, making sense of low level alerts and observations reported by the intrusion tolerant system means drawing conclusions about what needs fixing—i.e., conditions or system states that are detrimental to continued operation of the system. Once such a conclusion is drawn from the observed impact of an attack, many courses of action may become applicable. A second problem then becomes identifying the most effective one(s). Our goal in this effort is develop and validate control loop that performs these functions effectively and automatically. The above description alludes to utility functions of some kind for ranking conclusions and weighing courses of action—the challenge is defining utility functions, preferably one that an intelligent adversary (who can watch the defensive responses and adapt his attacks) cannot easily game. It may also be possible that the 3. APPROACH Based on our experience in playing the role of expert operators defending the intrusion tolerant system under attack, one thing was clear from the outset—the experts had very good understanding of the system architecture (no wonder, they designed the system), about potential causes of observed symptoms, about actions that could remedy the symptoms etc. So, if we were to automatically reason about the information reported by defense mechanisms embedded in the architecture, we must begin by a precise and machine operable representation of this knowledge. In some sense, the encoded knowledge constitutes the rules and constraints that will help us drawing conclusions about compromised hosts, networks or services from observed symptoms and selecting responses, but we still need a “process” that uses the knowledge representation (KR). Our current design consists of 2 major steps—Event Interpretation (EI) and Response Selection (RS), connected by an intermediate step called Claim Selection (CS). Key elements of our approach as introduced above are depicted in Figure-1. reports Hypotheses (Constraint Net) System specific translation layer In other branches of science (such as chemistry or physics), we have the advantage of codified knowledge that help explain an observed phenomena (such as a chemical reaction or a physical event), or even design and predict the outcome of new experiments. In the context of information systems security we do not have analogs of the law of mass/energy conservation or law of definite proportion. In fact, the lack of “ground truth” makes it very hard to derive and prove empirical rules that can be trusted or are sound and complete. Yet, human experts continue to arrive at certain conclusions from what they observe, based on what is often described as “expert insight” or “knowledge”. While it would be really interesting to devise the scientific laws that govern cyber-security, we settled on the (slightly) less ambitious goal of understanding the process the human experts use and encoding a version of that as an additional capability to augment survivability architectures. In doing so, we drew upon our own experience in playing the role of human defenders in red team exercises. In this round, we are mostly focused on demonstrating that an intelligent control loop can be built using encoded expert knowledge, and to see if the control loop functions as good as the experts whose knowledge it encodes. observed information does not lead to any conclusion; or given the conclusion drawn, no action is available to engage. Minimizing the possibility of this happening, and being able to at least recognize (and do something intelligent) when such a situation arises is a second challenge. Real System ditions that are of interest to them. The survivability architecture also provides a means to reliably deliver the captured and aggregated information to system management functions. For instance, in the DPASA architecture a combination of application level signatures and a NIC-enforced IPSEC mechanism ensure that identity of message senders cannot be spoofed; redundancy and adaptive middleware ensure reliable message delivery. In reality, the survivability architecture allows us to make certain assumptions in our reasoning (e.g., senders identity cannot be spoofed, but the sender can be corrupt and lie about the message content). However, this information typically are fairly low level (e.g., connection attempt, application level exception etc. as opposed to identifying an attack, attacker) and of local scope (i.e., reporting about a host or a network, as opposed to the impact on the mission operation). Some reports have high false positive rates (e.g., traditional IDSs), and some provide incomplete and partial information (e.g., alerts reporting a remote exception). Also, because of a lack of commonly accepted standard between various vendors (and in some cases differences in products from the same vendor) the information is likely in different formats. Furthermore, in the context of cyber-security the amount of alerts can change dramatically in a short amount of time, and may contain chaff that is intentionally generated by the attacker. How does one make sense of this vast, versatile and variable quality information that is currently available? What do we even mean by “making sense? CS order & subset responses EI generation coherence knowledge proving RS selection evaluate utility look-ahead actions Figure 1: Key elements of CSISM cognitive control loop The outcome of EI is a set of hypotheses decorated with additional metadata that are used by CS and RS. A hypothesis is an interim conclusion reflecting undesirable system state that can potentially explain the observed symptoms. The decorated set of hypotheses is essentially a constraint network where nodes are hypotheses and edges represent constraints. The outcome of RS is response decisions that can be translated into actuator commands that mitigate the attack effects. The CS takes a constraint net and selects a set of hypotheses that must be responded with—we have been calling this the claims set. Encoded knowledge (KR) is the basis on which decisions are made in each of these stages. One of the design goals is to keep the knowledge and processing at a level of generic abstractions, pushing a lot of details into a system-specific layer that manages the mapping from concrete event reports and actuator commands to our abstract concepts and vice versa. This serves two purposes—it consolidates the number of possibilities to consider more manageable, and makes the KR, EI, RS and CS applicable to multiple systems subject to the availability of a system specific translation layer (SSTL) (the vertical ellipse in Figure 1). In this paper, we will exclude discussion about the SSTL. 3.1 Knowledge Representation (KR) Our analyses revealed that there are at least 4 types of knowledge at play in human expert’s cyber-defense decision making. These may not be sufficient, but we argue that these are the necessary knowledge that the cognitive control loop must encode. First, the expert knows and can recall very well the systems configuration and attributes of constituent parts i.e., which machine is of what OS, which network is it on, what services or mechanisms it hosts, which other services or hosts connect to or depend upon any given host, what are application-level strings (chain of services connected by an end to end service request and response) etc. We call this “relational knowledge”. Encoding relation knowledge boils down to building a high level but accurate static model of the architectural entities and their relationships. Model fidelity is always a cause of concern, but in our case adequate level of fidelity is easy to achieve, and can even be automatically built from system scans and traces given an ontology. We had the advantage of an existing ontology of networked systems [proprietary] that we are enhancing with concepts introduced by the survivability architecture. Initially we build the model by hand using Protégé and generate executable code that enables the ontology to be used by other parts of the system (say, written in Java) automatically. Second, the human expert has a pretty good idea for almost all possible symptoms what incorrect system states might have caused them. Representing this knowledge, that we call the symptomatic knowledge has three components. The first one involves an abstract model of the states the system can be in when under attack. This model defines which architectural entities (e.g., hosts, LANs, services) are in a bad state. The model clearly is a high level and abstract model. It defines only a small number of bad states such as dead, corrupt, flooded etc (see section 3.2 for more), and it neglects many details such as different ways in which a host might be corrupt, or how much bandwidth is being lost to flooding. A second aspect of symptomatic knowledge defines what each report from the system (i.e., symptom) must mean in the context of the model. For example, if a network monitor, M, reports that LAN L is flooded, and a report from M cannot be faked because it is signed with a key that only M should have, then either M is corrupt or LAN L really is flooded as M reports. Note that symptomatic knowledge creates an abstract version of each report, by neglecting details in each report that are not relevant to the abstract model. Third and finally, symptomatic knowledge provides a classification of possible vulnerabilities in the system. The corruption that can result from each class is known. For example, one class is operating system vulnerabilities: if an attacker exploits vulnerability in operating system Q, then any host controlled by Q may become corrupt. This classification is used when interpreting a set of reports to try to find an explanation for the symptoms reported. Again, this aspect of symptomatic knowledge is abstract in the sense it does not depend on specific vulnerabilities in some current version of software. Third, after interpreting reports from the system, the experts know what response options were available and how to select a defensive response. We call this “reactive knowledge”. Given an interpretation of the current attack, reactive knowledge is a list of actions that might be effective in countering the attack. For example, if the attacker is exploiting vulnerability in the Solaris operating system and host H has been corrupted, one possible response might be to quarantine H and rely on other hosts to provide services formerly provided by H. Many possible responses might be known for a given situation; selecting a response from the set of possibilities will involve reasoning about which is most effective. Note that reactive knowledge, like symptomatic knowledge, is abstract and so can apply to a variety of systems. Fourth, to decide whether a response is effective, human operators often asked not only whether the response counters the attack now, but also whether the attacker can easily work around the response in the future. Of course, the attacker’s actions cannot be predicted with certainty, but if the attacker’s goal were known, some intelligent guesses could be made. We call this intelligent guessing “teleological knowledge”, because it leads from an analysis of the current situation to an assumption about the attacker’s likely goal. Given the attacker’s goal, the cognitive control loop can ask whether future actions toward that goal will also be countered by a defensive response; a response that blocks future steps in an attack is better than one that does not. 3.2 Event Interpretation (EI) The EI stage constructs a constraint network from the alerts and observations reported from the system. Alerts, representing security incidents reported by concrete sensors, are turned into accusations at the SSTL. As of now, only 5 types of accusations namely, omission, value, timing, policy and flood, are required to abstractly represent over 100 alerts that were supported in the DPASA architecture. Given symptomatic knowledge, EI constructs hypotheses and constraints from accusations. A hypothesis describes an undesired condition involving the accuser, the accused or the victim. In our current implementation, we support only 4 types of hypotheses: dead(x), corrupt(x), flooded(x) and comm-broken(x,y) where x and y are architectural entities represented in our relational knowledge (Note, not all hypotheses apply to all entities, for example comm-broken(x,y) is not applicable when x and y are file partitions). The constraints are used to represent supporting or competing relation between 2 nodes, where the amount if support is noted by its weight. In addition, some constraints signify logical implication. Symptomatic knowledge often implies alternative possibilities—this leads the EI to connect one or more hypotheses by an OR relation. Note that no explicit AND relation is needed because all the hypotheses and accusations are in implicitly AND’ed. Collectively, the accusations, hypotheses and OR relations form the nodes, and the constraints form the edges of the constraint network. Observations are similarly processed to add nodes and edges. The types of accusations, hypotheses and constraints we currently support is the minimal (as opposed to a complete) set for reasoning about cyber-defense. As an example, consider a host accused of causing a security policy violation. EI will create two hypotheses, connected by an OR-one hypothesis notes the accuser is corrupt (i.e., accuser is lying), and the other notes the accused is corrupt (i.e., the accused indeed violated the policy). There is a “competing” link between these two hypotheses (indicating that they are alternatives), and an implication link from the accusation to the OR node (indicating that the accusation leads to these alternatives). EI will also generate a hypothesis and a negative implication to note that the accuser is not dead (he just reported it). Once the constraint network is created, EI looks for truth assignments to the hypotheses nodes such that the accusation nodes are always true. In this search, EI uses additional symptomatic and teleological knowledge to narrow down the possibilities. For example, EI will first try to find proof under the assumption that the attacker only has single OS exploit. Note that some proofs can be found without such assumptions—for example, the fact that the accuser is not dead can be proven directly from the constraint network. Similarly, if a self-accusation leads to a degenerate case of an OR node with a single corrupt hypothesis (because accuser and accused is the same entity), then the corrupt hypothesis can be proven true directly from the constraint network. Acc2 Acc1 Reconfigure SELinux policies Reconfigure local firewall (iptables) OR OR H1 H3 H2 Acc3 OR H4 Fig-2: Coherence search accepting H1 In addition, EI uses the compete/support relation among hypotheses to compute the most coherent overall picture. The coherence search [3] partitions the hypotheses into an accepted and a rejected set. Hypotheses are assigned to the accepted set or the rejected set to maximize the weight of accepted constraints. Figure 2 shows an example where hypothesis H1 is accepted while H2, H3, and H4 are rejected. In this figure the red arrows indicate “competes” relationship between thee nodes they connect, where as thee blue arrows indicate “supports” relationship between the nodes they connect. Intuitively, in Figure 2, H1 has thee most support, and all H2, H3 and H4 push H1 away from them—hence H1 is in the accepted set alone and not with any other hypotheses. The coherence and proof status are the meta-data that decorates the constraint network. 3.3 Response Selection (RS) The RS stage uses responses to maintain the operational capabilities of the system (i.e., maintain availability, integrity and confidentiality of services and data). Responses are high-level descriptors of actions that need to be down-translated into specific commands for real actuators at the SSTL. In some cases a response may embody a generic act that can be carried out in different ways. For example, the act of “quarantining” a host may be carried out by a) reconfiguring a process protection domain or b) reconfiguring a local firewall (note that (a) and (b) are still generic and needs the SSTL to take effect since they do not bind to any actual process protection or firewall mechanism). In such situations, the RS outputs something that is translatable at the SSTL, i.e., in our example, either (a), (b), or (a+b), but never “quarantine”. Our current implementation supports 6 types of high level responses that are explained below: • • Ping: to test liveliness of a component (network ping for hosts, posix signals for processes, NIC status etc) • Quarantine: to temporarily block components (e.g., reconfigure firewalls rules to block hosts) • Isolate: to permanently block components (halting a machine, killing a process) • Degrade: to cause a component or service to run in degraded mode The actual action indicated by each of the responses will depend on the subject. We currently support a number of response executions for each of the 6 high level responses. For example, the following executions of the quarantine response are supported when the subject of the quarantine action is a host, running SELinux: • Refresh: to reset a component to known good state (e.g., reloading a vmware instance, restoring a file system from CDROM) Reset: to reset a component to its initial state (e.g., powercycling hosts, killing and starting processes from scratch) Reconfigure remote firewalls (iptables on machines that connect to it) Not all actions are applicable to all entities in the system. We mentioned quarantining a host earlier, but the quarantine response may also be applicable to a file. On the other hand, while pinging a host or a service makes sense, pinging a file partition does not. As in EI, this initial set of high-level responses (e.g., quarantine) and their alternative ways of execution covers the capabilities of the DPASA architecture, but is not necessarily a complete set. RS takes the claims set produced by CS to decide which response executions to perform. In this process, RS is guided by reactive knowledge to propose high level response(s) to remedy the condition embodied in each of the hypotheses in the claims set. A single hypothesis may lead to multiple such proposals, and each high level response will have many execution possibilities. Clearly, the RS must engage in a pruning process. The pruning process is guided by teleological, reactive and relational knowledge, as well as past history of the system. Examples of pruning based on reactive and relational knowledge are cases when response execution proposals have conflicting requirements (e.g., ping host and quarantine host) or overlapping subjects (reboot a host and restart a service on the same host). Examples of pruning based on teleological and relational knowledge are cases when response proposals conflict with current or future requirements of the mission (e.g., isolate a host, but the host has impending critical function incomplete). Examples of pruning based on past history of the system are cases when a condition persists despite earlier actions (e.g., restarted offending service on the host, but a hypothesis indicating that the host might be corrupt appears again in the claims set). In general, the RS needs to pick out the sequence of response execution proposals that it thinks will be most effective from a set of such sequences (note that this situation could happen even after an aggressive pruning step). We currently support two strategies to handle this situation: we engage all remaining sequence of response executions or randomly pick one. We are exploring additional selection heuristics such as smallest sequence first, response severity order, cheapest first etc. As of this writing, the benefit of such selection criteria is not clearly understood, especially in the context when an intelligent adversary may discover and game the chosen strategy. 3.4 Claims Selection (CS) CS has the responsibility to select a subset of hypotheses that is important to be responded with from the decorated constraint network produced by EI. The most straightforward strategy is to look at the metadata such as proof status—i.e., include all hypotheses that are proven true. Our current experience is that the claims set selected only by looking at proof status this way are small (sometimes non existent). The other metadata produced by EI is the coherence partition; and one strategy could be to use the “accepted” set, as the claims set when no hypotheses have been proven true. Our simulation runs indicate about 30-40% accuracy but almost 0 false positive in including the offending hosts in accepted set produced by our coherence computation. Is responding to the offending hypotheses 30-40% cases good enough for survival? We do not know the answers yet, but we are exploring what other heuristic strategies can be used to decide which hypotheses needs responding to apart from those that are proven and those that are put in the accepted set. Candidates are most critical, longest unfixed, attacker goal/gaming. In addition, learning techniques such as Reinforcement Learning [4] may be applicable to learn good response selection policies over time. The fact that such strategies can be refined/changed/added independent of the rest of the RS and EI logic is precisely the reason for CS’s existence separate from EI and RS. 4. CURRENT ACHIEVEMENTS For knowledge representation our ontology has nearly 3500 instances modeled, these are hosts and services, paths that application messages take, appropriate accusations, and many other facts. 300 classes of instances are modeled. Using the ontology we have also modeled which hosts and services are able to send which alerts so we are not taken in by impossible accusations. In event interpretation there are more than 30 SOAR[10] (SOAR is the reasoning engine used for EI) rules that are used to transform alerts into accusations.19 rules are used to reason about the flow of data through the system and how it relates to hypotheses. For response selection, we have implemented an initial set of 4 rules for proposal generation in JESS [5], and these rules act on hypotheses as long as they are not proven false. For example, one rule states that a policy accusation should cause a very strong reaction because it indicates an attack that may be spreading. We have started exploring pruning and step selection rules. To evaluate the effectiveness and timeliness of our approach, we have implemented a simulation environment together with simulation of intrusion tolerant system based on the DPASA survivability architecture. The simulation consists of in the order of 50 hosts, 60 NICs, multiple routers and switches, 12 application level protocols (such as heartbeats, publish-subscribe, registration). The simulation is also rich enough to evaluate various responses through service such as file managers (checkpoint, delete, restore files), resource sensors (process/host cpu load and memory load), and distributed firewall manager (for taking individual machines of the network). To measure the effectiveness of our defense logic, we’ve implemented a utility function for a small representation scenario that captures availability and integrity aspects of cyber security. We’ve also added extensive instrumentation to accurately determine the delay in executing a response given an abnormal condition within the system. We are planning to enter an intensive evaluation phase in the middle of this year. The evaluation will include external red team exercises, in addition to a thorough in-home testing and evaluation prior to exercise deployment. 5. RELATED WORK Cisco's Self-Defending Network architecture [6] shares the theme of adaptive as well as proactive responses using a set of security mechanisms for network and end system protection. Within the architecture, Cisco's Security, Monitoring, Analysis, and Response System (Cisco MARS) products [7] provide security experts a platform to identify, aggregate, correlate, evaluate, mitigate, and classify cyber security incidents and responses. One of the key differences to our work is that the focus in Cisco's line of products is how to present a concise operational picture to security experts, while our focus is to build an intelligent expert system that can take autonomous actions without user involvement. Previous SRS phase I projects, such as CORTEX [8] and AWDRAT [9] and respective techniques such as AI planning, sandbox experimentation, and architectural differencing, are related to our work in the sense that they are automating parts of the intelligent control loop for cyber defense. Our work differs in that instead of providing a point solution, our system tries to take a holistic approach of managing system wide survivability. 6. CONCLUSION We propose to augment the notion of survivability architectures with a cognitive component, that will perform deep semantic interpretation of the information gathered by the defense mechanisms incorporated in the architecture, and aid in mounting effective response. This paper reports a work that is currently ongoing. The outcome of the ensuing evaluation phase will determine whether we need more validation in terms of applying the technology to real systems or we need to find a new approach. A positive outcome will also encourage enhancement of the control loop, which currently has a number of limitations. For example, we limit ourselves to avoid the unsuccessful paths of reasoning—but there is a large opportunity to learn more from past successes and failures. As another example, the repertoire of responses available in a survivability architecture that we considered so far does not include defensive response like upgrade, move, morph, reinstate(unquarantine), join, or learn. This means, success with respect to this version of the survivability architecture would only establish automated defensive decision-making mostly concerned with graceful degradation. Despite elevating the level of sophistication of adaptation control (from reactive to cognitive), reasoning in the presence of these additional capabilities will remain unexplored. But on the other hand, success at this level will be a stepping stone to automating defensive decision-making beyond graceful degradation—what is often termed regenerative response; and also to the next level of sophistication in adaptation control – learning how to improve the cognitive control. 7. ACKNOWLEDGEMENT The authors would like to thank Lee Badger of DARPA, Bob Balzer of Teknowledge, Fred Schneider of Cornell University and Brett Chappel of NSWC for their support and feedback. 8. REFERENCES [1] Partha Pal, Franklin Webber and Richard Schantz "The DPASA Survivable JBI-- A High-Water Mark in IntrusionTolerant Systems." , EuroSys Workshop on Recent Advances in Intrusion Tolerant Systems, Lisbon, March 23, 2007 [2] Jennifer Chong, Partha Pal, Michael Atighetchi, Paul Rubel, Franklin Webber. Survivability Architecture of a Mission Critical System: The DPASA Example. 21st Annual Computer Security Applications Conference December 5-9, 2005 Tucson, Arizona [3] Thagard, P., and Verbeurgt, K. (1998). Coherence as constraint satisfaction. Cognitive Science, 22: 1-24. [4] Sutton and Barto, Reinforcement Learning, an introduction, MIT Press 1998 (online version at http://www.cs.ualberta.ca/%7Esutton/book/ebook/thebook.html) [5] Ernest Friedman-Hill , “Jess in Action - Java Rule-based Systems", Manning Publications Co.; ISBN: 1930110898; Publication date: July 2003 [6] Cisco Whitepaper: Core Elements of the Cisco SelfDefending Network Strategy, http://www.cisco.com/en/US/solutions/collateral/ns340/ns39 4/ns171/net_implementation_white_paper0900aecd8024791 4.html [7] http://www.cisco.com/web/strategy/docs/higher_CampusSec ure_defense_WP.pdf [8] CORTEX SRS phase I December 2005 PI Meeting Presentation,http://www.tolerantsystems.org/SRSPIMeeting12/12pi_ meeting.html [9] AWDRAT SRS phase I December 2005 PI Meeting Presentation, http://www.tolerantsystems.org/SRSPIMeeting12/AWDRAT .ppt [10 ] Laird, J. E., Newell, A., and Rosenbloom, P. S., “Soar: An Architecture for General Intelligence”, Artificial Intelligence 33: 1-64, 1987