Automated Reasoning in Co-operative Cyber Defense-A PhD thesis ...

Automated Reasoning in Co-operative Cyber Defense

- A PhD thesis proposal

Senthilkumar G Cheetancheri

Department of Computer Science

UC Davis.

September 15, 2004

Abstract

Computer attacks are here to stay. The best we can do is detect and tolerate them. With attacksbecoming more sophisticated and prevalent, especially the unknown ones, we cannot afford to tacklethem individually. We need to rule them out on a wholesale basis. The increasing frequency ofautomated attacks and worm outbreaks demand automated responses.

This research presents a thorough overview of the existing literature in addressing these require-ments and provides new ideas and approaches to overcome their shortcomings. The key parts ofthis research are: formal verification of security of a network, an automated response framework forenterprises and strategies to deal with widespread attacks such as worms. Together, these compo-nents in conjunction with the established defense systems can provide complete protection againstknown and unknown attacks.

i

Contents

1 Overview 31.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 A Brief Introduction to Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . 61.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Intrusion Response 92.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 The Uncertainty Problem - A Decision Theory Approach . . . . . . . . . . . . . . . 112.4 Extending JIGSAW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.1 Proof-of-Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.2 JIGSAW database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.3 Costing models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.4 Decision Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Response strategies for widespread attacks 203.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Friends Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 The Friends Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Hierarchical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.2 Description of the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.3 Mathematical Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.4 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.1 Experimental Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.2 Automatic Signature generation . . . . . . . . . . . . . . . . . . . . . . . . . 32

1

CONTENTS 2

4 Formal Reasoning about security 354.1 State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Formal Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3 Attack Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.2 An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.3 Description of the model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.4 Experiments and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.5 Technical Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.6 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Automated Theorem Proving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.5 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.1 Layered Specification Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.2 Interface Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Future Plans 495.1 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Bibliography 51

Chapter 1

Overview

1.1 Introduction

Critical computer systems will continue to be targets of wily attackers. Attacks cannot be prevented.We have to detect and tolerate them. These attacks could be as innocuous as they could be injurious.They could steal sensitive data and use it for the deteriment of nations’ security. Attackers couldtransfer money from one account to another in computerised banks. With the advent and widespread use of computer worms, attacks are no longer confined to one particular system. They couldbe automated easily and can be made to propagate from one system to another autonomouslycausing havoc in the world. Such worms have been witnessed in the Internet more than onceand the consequences were too simple to be ignored. Recovery of systems and reconstitution ofcompromised data back to operational levels after attacks are huge tasks that require enormousamounts of time and effort from experts.

Hence it is imperative that critical computer systems are secured against known and unknownattacks. Efforts towards this end are numerous. Intrusion detection systems(IDS), firewalls androuter access control lists are some of the various means currently adopted to secure a computerintallation from attackers. But most of them tend to be deployed only in an ad-hoc trial and errorfashion that serve their stated goals only to a certain extent. It is hard to ascertain the effectivenessof such measures with respect to primary objectives. This leads to systems being compromised byunforseen schemes and variations of known schemes, which the defense is not prepared to handleeffectively.

We need to build systems that can survive against such computer attacks. We believe thatserious evaluation and verification of the system properties are required before they are deployed.

Clarke [28] claims that formal methods is a good choice to address problems arising out ofunexpected interaction amongst system components. Wing [127] claims that the fields of computersecurity and formal methods have a symbiotic relationship and one could gain from the other. For-mal methods have been used in computer security for verifying communication and cryptographicprotocols [28]. Model checking techniques have been used to generate attack graphs[104, 7]. This re-search applies formal techniques such as model checking and theorem proving to verify the securityof a computer network.

However, the real world is not a formal system. A proof, does not show that, things will happenas one expects in the real world[51]. Nevertheless, such methods should not be abandoned. Ratherwe should expect attacks, albeit much fewer, and should be ready to counter to them.

3

CHAPTER 1. OVERVIEW 4

Most IDSs only log an alert in response to an intrusion. At best they send a message tothe system administrator(SA) in case a serious breach of security is identified. They do not takeany counter-measures to alleviate the ill-effects of such intrusions. In most cases, each intrusionidentified by an IDS forms the building block of a complex attack scenario that could endanger ourmission.

Regardless of the notification mechanisms to the SAs, there is a delay between the detectionof the intrusion and the response to the attack and this provides a window of opportunity forthe attacker to complete his task. Cohen[29] explores the effect of reaction time on the successof attacks using simulations. It states that an attack can be thwarted if a skilled administratorresponded instantaneously to the attack. After about a day, the attack is almost always successful.

If only we responded to these alerts in time, we can thwart many attempts to compromise ourmission. Given the computer speeds at which attackers can operate and that they can operateduring nights and weekends when the SAs are not generally on immediate call, manual response isnot a feasible proposition. We need timely automated response.

There has been some development in automated response but problems abound. Critical ofthem is the uncertainity of the alerts raised due to imperfections in IDSs. Most IDSs raise a lotof false alarms. An automated response based on such unreliable alerts might cause more damagethan the attack itself. The second problem arises after we have ascertained the veracity of thealert. Some of the questions we need to answer are, ‘What is the attacker’s ultimate goal?’, ‘ Willit affect our mission?’. We have correlation engines like JIGSAW[63] and CAML[26] which can helpus identify the scenario. But there is an uncertainty in these too. Several attack steps might bea pre-requisite for several complex attacks. For example, a Sadmind buffer overflow attack can beused to get a shell access. This step might be a part of several scenario attacks. So, the responsemechanism should choose an optimal response strategy considering the impact of the attack as wellas the response[73].

Further, computer worms have gained prevalence and incidents of worm outbreak are increasingby the day. They can cause damage to thousands of computers across a wide geography at averyhigh speeds. This is a case in point crying for automated response.

Current approach to worm respone include installation of firewalls and anti-virus software.After all, worms are ordinary intrusions but with added ability to propagate automatically. So, thegeneral but naive belief is that any intrusion prevention or response mechanism can also prevent orrespond to worm attacks. In case of an ordinary intrusion, one can call up the SA of an offendingnetwork to unhook the attacking system or atleast block traffic from a particular IP or network.However, even this task becomes onerous in case the intruder is based in a foreign or hostile country.But such isolated efforts are not sufficient to contain worms. During worm outbreaks, there is aconstant and heavy onslaught of attacks coming in from all directions. There is no single IP orblock of IP addresses that can be blocked. No single SA to call for assisstance. Such attacks callfor widespread and cooperative responses. We propose one such approach for responding for wormattacks in this paper.

This research considers enterprise level networks to reason about security formally. We considerthe microcosm of an enterprise to select optimal response and the macrocosm of an internet for acollective co-operative response to wide-spread instrusions. This research provides a unified theoryto reason about the security of a network and automated intrusion response.


1.2 Proposed Solution

Formal methods have been used to specify and verify properties of operating systems. An exampleis PSOS[41, 83]. We develop a formal framework that permits the analysis of the network inquestion. This analysis can be used to identify the loopholes in the network that were not apparentinitially by manual or ad-hoc analysis techniques that are in vogue.

First, we use Symbolic Model Checking(SMC) [34, 104, 96] approaches to verify the requiredsecurity property of our network. Model checking tools take as input a model of a system and arequirements specification, expressed in Computation Tree Logic(CTL), and verifies if the modelsatisfies the requirements. If the model doesn’t satisfy the specification, the model checker providesa sequence of system states, starting from the initial state, that would lead to the violation of therequirements. In verifying the security of a network, we specify the security requirements as a CTLand the model of a network in a language suitable for a model checker. This model of our networkcontains, the models of attacks, firewalls, IDSs as well as vulnerable systems. If the requirementis satisfied, the model of our system is verified. If not, the model checker gives us the sequenceof steps or attacks through which our requirement specification can be violated. In particular, weused NuSMV as the model checker of choice[5]. If we can generate all possible such sequences, wehave what is known as an attack graph. Attack graph is a graph-based succint representation of allpaths through a system that end in a state where an intruder has successfully achieved his goal[60].

From our experience, which we describe in chapter 4, we find that this method doesn’t scalewell even to reasonable sized networks due the choice of heuristics. There are several reaons whichare discussed in section 4.3.5. One of the reaons for this scalibility problem is the expensive nestedboolean universal and existential quantifiers in model checking algorithms; these are NP-completeoperations. Hence we propose using interactive theorem provers instead of model checkers to verifythe security of our network. We believe this approach would work because the user can guide thesystem at crucial points of the proof process. For example, in finding an existential item instead ofletting the system grind away for long hours to find one.

HOL[1], ACL-2[65] and PVS[113] are some examples of theorem provers. Our approach involvesconstructing high-level models of system components, formally specifying the desired security prop-erties of the system and using automated theorem provers to prove the desired properties in thesystem. In particular, we model our system as a stack of layers, each layer modeling certain prop-erties of our system. This approach makes it easy to verify our model, if there is a change. Weonly need to verify the layer that has undergone change. Also we break down the requirementsas several lemmas to be proved that would finally help us prove the overall requirement. Theselemmas can be stored for future use. Thus when the system undergoes change, we need to proveonly those lemmas that are affected by the change.

Even though the theorem prover itself doesn’t point out vulnerablities, the process of formallyspecifying the requirements, the modeling of the system and proving certain properties makesapparent to the system designer how those properties could be violated. It also gives an insight intothe various subtle interactions between the components of system that can lead to its compromise.Then we can devise appropriate schemes to prevent, detect or respond to such intrusions.

We propose two schemes of automatic response to attacks that effectively counter the uncer-tainity problem mentioned above. The main assumption in our response effort is that the IDSsalways detect and report intrusions, known and unknown within a reasonable time frame. We areable to make this assumption due to the work of Song[107] which claims that we can formally verify


that a specification based IDS can detect known and unknown attacks.The first one is a decision theory based approach to deal with uncertainty in alerts from IDSs.

This scheme helps the system to choose an optimal dynamic response strategy. Optimal responseis a reponse that would cost us the least considering the damage due to the attack and the cost ofthe response. Some times, the optimal response would just be to let the attack go on because theresponse cost is more than the damage cost due to the attack. Dynamism in response is requiredso that the attacker doesn’t use our response as an attack in itself. For example, if we use a staticresponse like closing a port under certain circumstances, the attacker can trick us into doing thesame even for a legitimate connection. Thus tricking us into inflicting a denial of service attack onourselves.

The second approach is a hierarchical co-operative response strategy which is very effective inresponding to worm like scenarios across various co-operating enterprises. Worms are the mostimportant intrusions that require automated response due to the high speed at which they affectour mission and can spread to other machines.

A worm cannot be prevented completely. By definition, a worm is not a worm until it spreads.Once it spreads, it has already infected atleast one machine which we haven’t prevented. So, thebest response against worms would minimize the infected population. We believe that no isolatedefforts can contain a worm. A site can successfully filter worm packets from getting in and out of itsnetwork but there are several other sites from which the worm can continue to propagate. Hence,we need cooperation amongst several sites in throttling the spread of a worm. Any mechanism tostop worms must be distributed and co-operative. The measure of effectiveness of any such effortis the ratio of the number of vulnerable machines that are prevented from infection to the numberof infections. The greater this ratio, the better the response strategy. In this paper, we propose ahierarchical co-operative response strategy to respond to both slow and high speed worms and inthe presence of false alarms. We perform analytical analysis and verify the claims by performingsimulations.

1.3 A Brief Introduction to Intrusion Detection

Early IDS efforts can be classified into 2 categories; anomaly detection and misuse detection [66,119, 49].

The former category, first proposed by Anderson[9], flags any deviation from the normal be-haviour in audit trails as an intrusion. Normal behaviour is defined in terms of various parametersincluding resource usage patterns by users[30], system call sequences by programs[44] among others.The normal behaviour is profiled over a period of time in live environments using expert systems[128] and machine learning techniques[15, 31, 120, 50] Alternatively, artificial traffic can be gener-ated in controlled environments and the behaviour of the system can be recorded to be normal [44].The anomalies are detected using statistical profiles [8, 77, 78, 43, 86], inductive pattern generation[54] or neural networks [68].

Most of the anti-virus software and current commercial IDSs fall into the latter category, misusedetection. EMERALD[90, 81] is one notable example of such systems. These systems essentiallydefine what is wrong. They contain succint descriptions of attacks, also known as signatures, andmatch them against the audit trail looking for known attacks[85, 76]. Other approaches includeexpert systems[129], abstract modelling of attacks[75] and model-based reasoning[47] and pattern-matching using colored petri-nets[72]. STAT[58] and NetSTAT[46], developed based on [89] and


[57], are both notable exceptions in the class of misuse detectors because, they can detect variationsof known attacks which others in this category usually cannot.

One of the most popular and relatively new paradigm in Intrusion Detection is specificationbased. Specification based IDS models like SHIM[71] claim to detect unknown attacks. They can dothis because they work by specifing the way a certain program should work and flag any operationsperformed by the program that doesn’t conform to the specification[70, 69, 92, 99]. This is differentfrom the anomaly based system in that the specifications are based on the design and intent of theprograms rather than established usage patterns.

Efforts like JIGSAW[63], CAML[26] and Zhou[131] can help us to correlate messages fromvarious IDSs to understand complex attacks that may not be apparent with IDSs that fall underone of the above categories.

Other approaches of intrusion detection that have been developed over the years. Ghosh[49]proposes a process-based intrusion approaches that provides the ability to generalize from pastbehaviour to recognize future unseen behaviour using artificial neural networks. Static analysis[123],data mining[74, 101] and log-auditing through online model-checking for detecting attack signatures[98] are examples of other approaches.

1.4 Contribution

The key contribution of this research is an unified theory to reason about the security of a network,detect and respond to intrusions automatically. People have used interactive theorem proversto prove properties of OS kernels, cryptograhic and communication protocols. We extend thisapproach to prove properties of our network models. We formulate the reasoning problem as atheorem to be proved by theorem provers. This is a pioneering approach that can help evaluatethe security posture of a system before it is deployed.

We make use of a huge body of research in Decision Theory to ameliorate the uncertainty prob-lem in IDS alerts that impends progress in intrusion response. Our approach involves characterisingthe IDSs in terms of its false positive and false negative rates. We define the parameters of theoperating environment in terms of intrusion probability and the costs of attacks and responses tofalse alarms. With these parameters defined, we make use of decision theory to determine whethera response is required or not for an alert.

Once the uncertainty problem is solved, we can make huge progress in the intrusion responseresearch and thereby actively combat complex computer attacks. As an example of this we show howwe can extend JIGSAW[63] to choose appropriate response to thwart the attacker from achievinghis goals.

No response policy is complete if it doesn’t address the issue of response to worms. Accordingly,we provide a response strategy to combat computer worms. We provide a hierarchically controlledresponse strategy for widespread attack scenarios. We have analysed this strategy mathematicallyand also evaluated it with simulations. We have shown that this strategy is effective in stoppingboth high and slow speed worms. We have also shown that this model can work in the presence ofambient false alarms.

These efforts push the frontiers of computer security one step further in combating wily attack-ers.


1.5 Outline

The rest of the proposal is organised as follows. Chapter 2 discusses our decision theory basedapproach to select optimal response strategies. Chapter 3 explains our hierarchically controlledco-operative response strategy for widespread attacks like worm attacks. Chapter 4 talks aboutour formal reasoning efforts; the model-checking and theorem proving approach. The last one,Chapter 5 lays down a road map for the next 2 years for my research areas.

Chapter 2

Intrusion Response

2.1 Introduction

Traditionally, security efforts have focussed only on simple prevention mechanisms, detection ofattacks and manual efforts of restoring sanity after an intrusion. Many a times, IDSs raise alertsbased on an intrusion attempt even though no services were actually being offered that were targetedby the attempted intruions. Example, an intrusion that matches an attack on IIS web serversoftware could trigger an alert though apache was being used to host web servers. Such alerts takea great toll on system resources and SA time. They also act as an effective deterrent to timelyresponse by SAs to real attacks.

With more critical infrastructure vulnerable than ever before on the Internet, prevalence ofautomated attacks that operate at high speeds including computer worms, and for those severalreasons cited in chapter 1 manual response to computer intrusions are anachronous. There is anincreasing need for timely and dynamic automated response. One of the first automatic responsesytesm was developed by HayStacks labs in their commercial product, NetStalker. Upon detectionof an intrusion, these systems sent messages to firewalls to block traffic from particular IP addresses.This is in effect, a static response and quite susceptible to further attacks. Attackers can easilylearn the static response behaviours and can tailor their attacks to achieve their goals renderingthe response systems toothless.

Any response has to be launched based on the detection of an intrusion by a IDS. But expertsare wary about such automatic response because of the high rates of false alarms from IDSs. Iffirewalls were to block traffic based on these alerts from IDSs, they might block traffic inadvertentlyfrom legitimate sources. Furthermore, an attacker can induce these responses on legitimate clientsby attempting intrusions with forged IP addresses.

As a result of these problems, we only have very rudimentary or ‘safe’ response mechanisms thatare automated. By ‘safe’, we mean those response that don’t have any discomforting consequencesto the legitimate users even accidently. These can be easily circumvented even by automated attacksthat have minimal intelligence.

There is a big reserach community that is working on improving IDSs to reduce false alerts.Until a perfect IDS is developed which could take several years into the future, we have to workwith the existing IDSs. We need to find ways to deduce the event that triggered the alert, whichcould be false. Alternatively, we need to guess the ultimate motive of the attacker based on theavailable alerts, true or false, so that we could deploy responses. These responses should help us

9

CHAPTER 2. INTRUSION RESPONSE 10

prevent the attacker from taking the attack to the next step to disrupt our mission.We propose a decision theory based approach to reduce the uncertainty in IDS alerts. Then,

with the help of a correlating engine like JIGSAW[63] (or CAML[26]), we try to launch appropriateresponses. This involves assigning costs to the various required parameters in each of the attacksdescribed by the correlation engine’s database. And we need to know the operating environmentin terms of the probability of intrusion, the damage costs due to intrusions, the penalty costs dueto responses to false alarms, the false positive and false negative rates of the IDS we use. Theseparameters are not unreasonably believed to be available or can be learnt in a short time (order ofa few days).

2.2 Prior Work

There are several research efforts towards automated response. Quite a few of them have stressedon the need for a taxonomy for intrusions and responses to produce a effective response. There havebeen several attack taxonomies proposed. We will just show two of them which uses the taxonomyfor deciding upon responses. For a comprehensive digest of attack taxonomies refer to Carver[17].

Lee et al [73] propose an attack taxonomy to produce meaningful cost metrics. Their taxonomygroups intrusions into diffeent types so that cost measurment can be performed for categories ofsimilar attacks. Their first level of classification is based on the intrusion results. Within each ofthese categories attacks are classified based on their techniques. These are further partitioned basedon the attack targets. They assign fixed costs for damage and response to each category of attacksrelative to each other. They also have a notion of operational costs for the IDSs. Their responsemodel tempers responses based on the overall cost due to damage caused by the intrusion, responseto the intrusion and the operatioal costs. In short, for a true intrusion, response is initiated onlywhen the damage cost is greater than or equal to the response cost. The shortcoming of theirapproach to response is that they consider only individual attacks detectable by IDSs. They don’tconsider scenario attacks. Given that most IDSs detect an attack after the fact, any response tojust that attack doesn’t help much. At best it could serve as an automated means of restoringsanity to the system.

Fisch[35] proposed a intrusion response taxonomy based on just 2 parameters: the time ofintrusion detection(during or after attack) and the goal of the response(damage control, assessmentor recovery). Carver [17] claims that this is not sufficient and proposes a 6 dimension responsetaxonomy based on the following:

• timing of the response (preemptive, during or after the attack)

• type of attack (Dos, integrity or confidentiality attack)

• type of attacker (cyber-gangs, economic rivals, military organizations, automated attacks orcomputer worms)

• degree of suspicion (high or low)

• attack implications (critical or low implication)

• environmental constratints (social, ethical, legal and institutional constraints)


AARIS [16] uses the Carver taxonomy [17] to classify attacks and resolve uncertainity in IDSalerts to an extent with the help of the SA.

Balepin [14] proposes an automated response strategy by combining response with a host basedspecification based IDS. They describe a map of the system and a map-based action cost modelthat gives them the basis for deciding upon the response strategy. They also show the process ofsuspending the attack to buy time to desgin an optimal response strategy even in the presence ofuncertainity. However, this scheme is purely only for a host. This doesn’t address the issue ofenterprise wide response. To effect a enterprise wide response, this system must be employed oneach of the hosts in the enterprise which is not very effecient. Therefore, we need to deploy thissystem in the mission critical systems.

In most cases, an attacker cannot directly reach the mission critical systems. He plots his waythrough a series of attacks on several machines that are in between the periphery of the enterpriseand the mission critical systems. We would like to stop him early in his tracks before he can getto the mission critical systems to respond.

SARA[106] and αLADS[10] are two feed-back control based automated response frameworksthat are similar to [14]. They all propose a quick local response, suspending or slowing down theattacker, to gain time for a more elaborate and efficient response strategy to be planned. IDIP[100, 116] proposed a quarantining infected nodes approach with a designated response coordinatorin a cooperating neighborhood. Toth[121] provide automated response in a network setting bybuilding a dependency tree based on the network topology and relationships between the resourcesand the system users. A response with the minimum negative impact on the system is chosenfrom a set of alternatives. Responses include re-configuring firewalls, controlling services and usersaccesses.

Tylutki[122] proposes another response system that is based on policy and state-based modellingand feedback control. This provides a general response model capable of using low-level responsesystems in order to address a wide range of response requirements without any scope restriction.Thus, enlarging the collective scope of several existing automated intrusion response paradigms.EMERALD[90] and CSM[48] are other response strategies that are discussed in chapter 3. For alonger list of related work see Balepin [13].

2.3 The Uncertainty Problem - A Decision Theory Approach

As mentioned earlier, one of the most critical impediment in automated response is the uncertaintyof the intrusion alert. We formulate the problem as a decision theory problem [93], analyze it andprovide a guideline to respond or ignore the alert.

Decision Theory is a field of science that provides a systematic methodology to reason aboutevents that are not under control of a subject but will affect its final state. The outcome of theseevents are uncertain but can be characterised by assigning probabilities to those outcomes. Itprovides a system of delibrate, reasoned, and logical analysis of the problem at hand that wouldsuggest the best course of experimentation and action in an uncertain environment. We use thistechnique to cast our problem of minimizing costs of intrusions and responses to them on the basisof unreliable alerts from IDSs.

In this section, we assume that we have an IDS which has a false alarm rate of α and a falsenegative rate of β. That is (1 − α) is the true positive rate and (1 − β) is the true negative rate.These values can be calculated for any IDS by observing them in a controlled environment. We also


assume that we have a response agent that responds to the alerts. We assume that Cα is the cost ofresponding to false alerts (penalty) and Cβ is the cost of not responding to attacks. That is, Cβ isthe damage cost for a particular attack. These costs are determined by the SA based on the attackstarget and the target’s criticality to the mission. To simplify matters and focus on the technique,we can assume without loss of generality that, the cost of a response to an actual intrusion is 0.One can easily reassign the costs to include operational costs and repeat the following analysis.We assume that the operating environment is subject to intrusions with a probability of p. Torecapitulate, we have:

α : False Positive rate of an IDS

β : False Negative rate of anIDS

Cα : Penalty for responding to False alerts

Cβ : Damage; Cost of not responding to Intrusions

p : Probability of Intrusion

0 : Cost of responding to an alert

The key to understanding the above parameters is to distinguish alerts and intrusions. An alert isnot always an intrusion. An intrusion doesn’t always generate an alert. We will use the followingnotation throughout this section:

I : There is an Intrusion

A : An Alert is raised by the IDS

R : We decide to Respond to this Alert

The corresponding letters with a bar on them indicates its negative sense. Similarly the bar overa probability variable is 1 minus that variable. That is p = 1− p.

Then, the problem of whether to respond to an alert or not can be represented as a decision-flowdiagram (called DFD henceforth) as shown in Figure 2.1. The expected cost of any response orthe lack of it is determined by analyzing this DFD. We then claim that the response agent needsto act based on an action’s expected cost, which we shall computer shortly. The action that wouldlead to the least final cost is considered appropriate response for a particular situation.

Fig. 2.1 shows the actions of the response agent emanating out of squares. The squares in aDFD denote the point of time that the decision maker has control and can take an action. A DFDalso shows events that are not under the control of the decision maker. These uncertain eventsemanate out of circles. It also shows the consequences, the final costs, of the sequences of eventsand actions. Each node is labelled as a tuple consisting of the sequence of events and actions. Forexample, in Fig. 2.1, the point we reach after an alert and a response is labelled as (A,R).

In our problem decision points (squares) are under the control of the response agent and theuncertain events (circles) are determined by the IDS and attackers. A probability function deter-mines which event will happen consequent to a event node. Each combination of actions and eventsis characterised by the final cost. The higher the cost, less desirable the path. We, as the decisionmaker, cannot know the final cost outcome. However, we can estimate the expected cost based onour limited knowldege of the system and probability distribution of various parameters.

The expected cost at any decision point is the lowest cost expected cost from among the node’sbranches. This corresponds to choosing the alternative with the lowest expected cost. The expected


Alert Response Intrusion Cost Scenario

1

2

3

4

5

6

7

8

: Decision Fork

: Chance Fork

PSfrag replacements

A

I

I

I

I

R

R

A

I

I

I

I

R

R

Cα

Cα

Cβ

Cβ

0

0

0

0

Figure 2.1: Decision flow diagram

cost at any event node is the sum of the product of the probability and cost for each branch, takenover all branches.

To calculate the expected costs at the two decision points we need to know certain probabiliticquantities. These and the other predetermined known quantities are listed in the Table 2.1.

Known Probabilities Unknown Probabilities

1 P (A|I) = α P(an alert is raised if there isan intrusion).

P (I|A) P(an intrusion given that an alert israised ). Scenario 1 and 3 of Fig 2.1.

2 P (A|I) = α P(an alert is raised when thereis no intrusion).

P (I |A) P(no intrusion given that an alert israised). Scenario 2 and 4 of Fig 2.1.

3 P (A|I) = β P(no alert is raised when thereis an intrusion).

P (I|A) P(an intrusion given no alert israised). Scenario 5 and 7 of Fig 2.1.

4 P (A|I) = β P(no alert is raised when therei no intrusion).

P (I |A) P(no intrusion given no alert israised). Scenario 6 and 8 of Fig 2.1.

5 P (I) = p Probability of no intrusion. P (A) Probability of an alert.6 P (I) = p probability of intrusion. P (A) Probability of no alert.

Table 2.1: Unknown and Known Probabilities

The known values can be represented pictorially as shown in Fig. 2.2(a). The tips of the paths,give the path probability. The figures on the arcs give the conditional probability of each event.Fig 2.2(a) can be flipped to get the required unknown probabilities shown in Fig. 2.2(b). Thisprocedure is called averaging out and rolling back. This is also called as the process of backwardsinduction in the theory of dynamic programming[93].

The path probabilities are assigned by observing that the path probability is independent of theorder of events. Thus the path probability for A followed by I in Fig. 2.2(b) is the same as the pathprobability for the path I followed by A in Fig. 2.2(a). The A branch in Fig. 2.2(b) is assignedthe sum of the path probabilities of A branches from Fig. 2.2(a), that is, αp+αp. Similarly, the Abranch is assigned βp + βp. Having assigned these two probabilities, the other probabilities can bederived using the path probabilities. For example, we know that the path probability of AI pathis αp which is P (A).P (I|A). This means that P (I|A) = (αp)/P (A) = αp/αp + αp.


ProbabilitiesPath

PSfrag replacements

A

A

I

A

A

I

p

pp

α

α

ββ

p

pp

α

α

β

β

αp + αpβp + βp

αp/(αp + αp)αp/(αp + αp)βp/(βp + βp)βp/(βp + βp)

(a) Known Probabilities

PathProbabilities

PSfrag replacements

A

I

IA

I

I

p

p

α

β

p

p

α

β

αp + αp

βp + βp

αp/(αp + αp)

αp/(αp + αp)

βp/(βp + βp)

βp/(βp + βp)

(b) Unknown Probabilities derived

Figure 2.2: Averaging out and Rolling Back

Carrying these probabilities back to Fig. 2.1, we get the expected cost at node (A,R),

E[(A,R)] = max

[

0.αp

(αp + αp),

Cα.αp

(αp + αp)

]

=Cα.αp

(αp + αp)(2.1)

Similarly we can calculate the expected costs at other nodes, (A,R), (A, R) and (A, R). With thesecosts determined, we get the expected cost at decision point (A) and (A), which is the minimumof the expected costs of its branches:

E[(A)] = min

[

Cα.αp

(αp + αp),

Cβ .αp

(αp + αp)

]

(2.2)

E[(A)] = min

[

Cα.βp

(βp + βp),

Cβ.βp

(βp + βp)

]

(2.3)

When the decision maker is at a decision node, he has to take the branch that has the leastexpected cost. Thus, given the rates of false negatives and false positives of the IDS and the costof response and damage, we can decide whether we have to respond to an attack or not.

This section provides an example of how decision theory can be used to make a scientificdecision about futher actions. This example showed how one decides about responding to anisolated intrusion alert based on several environmental parameters. There were only two givenoptions, to do or not to do. However, the concepts and ideas used here can be extended andapplied to other similar problems. An example of such a scenario, is to decide upon which action totake given a set of n different options. The model could also be extended to incorporate operationalcosts of IDSs and fixed costs for responses in addition to damage costs and penalty cost for wrongresponses that are already used here.


IDS Alert DecisionEngine

Update/DropAlert

JIGSAWDatabase AgentTable

Updated Response

Figure 2.3: The Response plan

We show how we use the results from applying these techniques at the grassroots level of otherlarger response plans in the next section. We use this result in conjunction with JIGSAW[63] toinitiate appropriate responses to thwart scenario attacks.

2.4 Extending JIGSAW

This section explains a novel idea in using the JIGSAW correlation engine’s database to preemptthe attacker from getting ahead with his intended attack. We assume that there is a low levelIDS that monitors the network. A decision engine processes these alerts and decides whether ornot to respond to this alert. If it decides to respond, it update the JIGSAW database which thereponse agent uses to launch responses. Fig. 2.3 captures this notion. The alerts are consideredas is received from the IDS. The decision engine doesn’t make any distinction based on the user orprocess. These aspects are left to be handled by the correlation engine.

JIGSAW[63] is an attack specification language. It provides a requires/ provides model forcomputer attacks. This language describes attack components in terms of capabilities and concepts.This language allows detailed specification of the system being modeled. We make use of this featureto add more information about the system.

An attack in JIGSAW is specified as a concept with an identifier. Each concept has a requiresblock and a provides block. The requires section lists the types of capabilities and configurationinformation the concept uses. Inside the requires block is the with section, which specifies anyrelations that must hold between the requires capabilities are stated.

An extended example attack concept sepcification looks like the following:

concept RSHConnectionSpoofing is <damage cost = 2000>requires

TrustedPartner: TP;

Serviceactive: SA;

PreventPacketSend: PPS;...

with

TP.Service is RSH, <resp1 = deny rsh for IP1, penalty = 10>,

<resp2 = disable rsh, penalty = 20>;

PPS.host is TP.trusted <resp1 = drop packets, penalty = 10,000>;

SA.port is TCP/RSH <resp1 = disable rsh, penalty = 20>;...

end;

provides

PushChannel: PSC <damage cost = 1300>;

RemoteExecution: REX <damage cost = 900>;

with


RSC.from ← FPS.TrueSrc;

RSC.to ← FPS.dst;

RSC.using ← RSH;...

end

action

true → report(‘‘RSH Connection Spoofing: TP.hostname’’)

end;

end.

The extensions are shown in angled brackets. We associate a damage cost,Di with each attackconcept, i, that is currently active. This cost represents the damage that the attacker can cause ifthe attacker acquires the capabilities provided by this concept. This corresponds to Cβ in section2.3. By active, we mean that some of the requirements of the concept is satisfied by the attacker.This attacker is monitored with respect to all the concepts that he activates in the JIGSAW library.With each concept, i, is also associated a probability of pursuit, πi. This is a measure of beliefabout the attacker’s goal concept. This is roughly the ratio of requirements satisfied by the attackerto the total number of requirements for the concept to be achieved.

With each requires clause, i, in the with section, we associate a response and penalty cost,pi. This is the cost we incur by trying to prevent the attacker from satisfying the requirement.A better way to look at it is the penalty we pay if this response was deployed for a false alert.For example, in the RSHConnectionSpoofing concept above , TP.Service is RSH requirement, RSHenjoys a trust relation between a pair of hosts. If we try to prevent the attacker from satisfying thisrequirement by turning off RSH, other legitimate users might be affected. If the alert that identifiedthis intrusion turns out to be false, this cost is a penalty. This corresponds to Cα in section 2.3. Ifthe alert is true, we consider this penlaty to be zero in keeping the conventions in section 2.3. So,there is a penalty involved in turning off RSH. This penalty is associated with each response thatare associated with a requirement in the concept.

For each requires clause, there may be more than one response possible with different penalties.We let the response engine apply only the response that has the least penalty. In some cases, asatisfied requirement may not be revokable. Or even, the attacker cannot stopped from satisfinga requirement at all. For example, a requirement in a concept might be access to the web server.Some of the possible responses are:

1. Shutting down the server.

2. Denying the service to the offending IP address.

In an e-commerce enterprise, the first of these 2 responses is not an option at all. The second oneis a reasonable option unless the attacker spoofs some other legitimate client. However, we expectthat most attackers either spoof their ID addresses or use a hijacked machine for attacks. So, thesetwo responses have to be assigned very high costs; the second one slightly lower than the first. Thisdiscourages our response engine to apply these responses.

However, once a requirement has been satisfied by the attacker, a response has to be applied torevoke it and prevent the attacker from regaining it in future. In the above example, if a suspectedattacker is able to establish a connection even after we apply response 2, it means he is using aspoofed or hijacked IP address. We need to apply response 1. So, at any point of time, the response


ConceptsC1 C2 C3 . . . Cn

r1 100 20 30 . . . 30

r2 20 20 ∞ . . . 19

r3 10,000 20 30 . . . 30...

......

......

...

rm 1 0 0 . . . 14

Probability π1 π2 π3 . . . πn

Damage D1 D2 D3 . . . Dn

Expected Damage E[D1] E[D2] E[D3] . . . E[Dn]

Table 2.2: The JIGSAW matrix

with the lowest penalty is associated with a requirement. After the response with the lowest penaltyis applied, the response with the next least penalty is associated with the requirement. When allresponses are exhausted, a cost of inf is associated with the requirement meaning that nothingmore can be done.

All the above quantites can be conveniently stored as a matrix in Table 2.2. The table shows aconcept in each column. Each cell, (i, j), in the matrix, represents the penalty, pi for a concept’srequirement. A penalty of 10, 000 indicates that it is very difficult to prevent the attacker fromsatisfying requirement r3 for concept 1. A ∞ means that the capability gained by satisfying thecorresponding requirement cannot be revoked from the attacker. A 0 in cell (i, j) indicates thatthe concept j doesn’t have as many as i requirements. Each ri may mean different requirementsfor different concepts.

This table is the most important input to the response agent. The response agent follows thefollowing algorithm:

For (Each update in the JIGSAW database)

Choose the concept i with maximum E[D i];Choose the requirement j and the corresponding response that has minimum

penalty for that concept i;Apply this response;

Update this requirement j with the next cheapest penalty;

Revoke responses and remove concepts from this table which have been

dormant for the last, say, 1000 updates of this table;

The response agent calculates the expected damage cost, E[Di] for each of the concepts. This iscalculated as the product of πi and Di. The response agent selects the concept with the highestexpected damage cost. If a concept is critical to the mission, then it must have been assigned ahigh damage cost. And, if this is concept is highly probable to be achieved by the attacker, thenthe E[Di] would be high for this concept than the others. One of the key points here is to assignproper costs to various concepts and to define appropriate responses for each requires clause witha realistic penalty. This in effect chooses the attack that poses the maximum danger and tries toprevent it while taking minimum risks.

This idea effectively makes use of existing framework with a small extension to address the


problem of automated response. Since the responses are activated based on the penalty we believethat the over-all negative impact due to our responses will be minimal.

2.5 Future Work

We believe this idea will work because we suggest minimal extensions to JIGSAW which has beenexperimentally proved to effectively correlate attacks[63]. We need to complete the following tasksto make this effort worthwhile and convincing.

2.5.1 Proof-of-Concept

We have to atleast implement a proof-of-concept experiment for the model we have discussed here.We will build a small isolated network and launch attacks on it to see if our system can successfullythwart these attacks. This isolated network should contain a mix of computers, OSs, routers,firewalls and IDSs, each with some mix of vulnerabilities. We plan to use one kind of IDS first,for example, SHIM or SNORT. Later we plan to use a mix of signature, anomaly and specificationbased IDSs. This network will also contain the decision and response engine with the appropriatedatabase of attack concepts defined. The attacker will be given a goal to achieve, for example,deface a web-page in a web-server being hosted on this network. We expect that the responsemechanism would be able to prevent the attacker from achieving this goal. To carry out thisexperiment, we need several building blocks. These are listed below.

2.5.2 JIGSAW database

In developing this model, we have directly assumed that we have a database which has all theconcepts defined in it. In reality we have none. We need to build it. This database needs to includespecifications for the attack concepts, attack capabilities and interface concepts.

Specifications for attack capabilities define attributes of the capability. Specifications for attackconcepts define the capabilities provided and relations amongst them for the concept to hold.

Vulnerabilities in our isolated network can be enumerated using a vulnerability scanner such asISS[2]. This information is required to build the initial database. The specification for the attackconcepts can be built from various Internet resources like CERT[19]. The correlation engine canbe implemented using CLIPS/JESS because it supports forward chaining which is the natural andefficient means to implement this kind of correlation.

2.5.3 Costing models

We have assumed that, we know the costs of damage that an attack can cause and the penalty forresponding to false alerts. Currently we have used an arbitrary scale to assign costs in which thereference point is a cost of ‘0’ for response to true alerts, ignoring the operational costs, and a costof ‘∞’ for response that cannot be realised. Assigning numerical costs to security has always been atouchy subject in the security community. Nevertheless, for tour decision theory approach to work,we need to have some notion of costs and probability. Hence, we need to develop a convincing andrealistic scale for costing attacks and responses.

A first step towards achieving this is to develop an taxonomy for attacks and responses togroup similar attacks together, so we can atleast partially order attacks we face. We have already


mentioned some of the taxonomies developed by the community in section 2.2. Of those, Carver’staxonomy[17] seems to be promising because, it captures almost all the essential characteristics ofattacks and responses. We believe we will be able to use it to develop a realistic scale for Intrusionand Response costing.

2.5.4 Decision Engine

Implementing the decision engine is an important aspect. For this, we need to characterize IDSswith their false positive and false negative rates. We can do this by observing them in a controlledenvironment. We can use the 1999 DARPA/Lincoln Labs offline evaluation dataset[97] and the1999 DARPA/AFRL online evaluation dataset to evaluate our IDSs before using them. We alsoneed to find out the probability for intrusion. This can be found by connecting the network tothe Internet without any access restrictions at the router level and having the IDS in front of thefirewall.

Chapter 3

Response strategies for widespread

attacks

3.1 Introduction

The previous chapter dealt with responding to attacks at an enterprise level. We consider this as amicrocosm. It did not take advantage of information available at other enterprises which also haveIDSs and are monitoring networks for attacks. If the response agents at various enterprises couldco-operate exchanging information about current attacks, a collective response could be launchedagainst attacks that are widespread across enterprises at the macrocosm level.

For this we assume that, the response agents at the microcosm has analysed all the intrusionsand has arrived at conclusion with regards to the attack that is currently in progress. We alsoassume that a signature has been deeveloped for the current attack. We assume that the IDS atother co-operating locations can identify variations of the same attack with the signature providedto them. Each participant can independently decide on the response for each attack. The responsemay just be not to do anything or as minimal as just alert other participants.

Critical to the two models discussed here is the communication amongst the various IDS/responseagents. They need to exchange information like the signatures of the attacks, the response strategythat is being adopted etc.,. They need to dynamically adapt to the new and improved componentsand to the changes in the environment. The co-operating agents could be heterogeneous in na-ture. Hence they need a negotiation protocol to reach an agreement on each other’s capabilitiesand requirements. They also need a common language to allow communication of information andinter-operation. We suggest the use of IDIAN [40] protocol for negotiation of contracts betweendifferent participating agents. The IDIAN protocol is implemented using the Estelle [59, 64], aformal description language. The IDS/response information could be exchanged using CIDF [27]as used in IDIAN or the more recent IDMEF [56].

In this chapter, we briefly introduce a model called the friends model [24, 32]. We also proposeand analyse in detail, a hierarchically controlled co-operative [22] response strategy that could helpall participating agents to take the best approach to the current threat. An immediate applicationof such frameworks would be to counter worm attacks.

Shoch [105], Seeley[103], Spafford[111] and Eichin [36] give an excellent analysis of pioneeringworms like the Xerox Parc worm and the Morris Internet worm. The Morris worm [110, 112], Code

20

CHAPTER 3. RESPONSE STRATEGIES FOR WIDESPREAD ATTACKS 21

Red [20] and Slammer[80] are classical examples of malicious worms of the past. Staniford[115, 114],Weaver [124, 125] talk about high speed, stealth and contagion worm models of the future.

Though the simulations for the following two models have focussed on applying these strategiesto worm scenarios, they are readily applicable to other kinds of distributed attacks too. Some ofthe other scenarios include co-ordinated attacks against multiple sites and repeated attacks on thesame service across several enterprises. We have assumed that the attacks are not polymorphic.

3.2 Friends Model

This model was first proposed in [21] and later refined and analysed by Noijiri et al[32]. It providesa peer-to-peer co-operative response strategy to handle distributed attacks like worms. Furtherexperimental research with this protocol is currently being carried out by Porras et al[88] on theDETER test bed.

3.2.1 Related Work

Cooperating Security Managers(CSM) [48] is a distributed and host-based intrusion detection andresponse system. CSM responds to intrusions using the Fisch DC&A taxonomy [35] to classify theattack and assign a suspicion level to an intruder. CSM doesn’t discriminate between various IDSsbased on their false alarm rates. It just treats all IDS equally and believes all the alerts. If a IDSprovides it with more incriminating alerts, it increases the suspicion level of the current intrusionand increases the reponse. This scheme can be tricked to over react by a cleverly forcing a seriesof false alarms.

The Adaptive, Agent Based Response System(AARIS) [16] collects alerts from various IDSs.It uses a Response Taxonomy [17] and a centralized Master Analysis engine to prepare a plan ofaction. This response is deployed using a Response Toolkit. This scheme uses the false alarm rateof an IDS to temper the responses. It has explicit methods for measuring the success of a responseand adapting the response to current conditions on the network. This scheme suffers from the riskof single point failure. If the Master Analysis engine is compromised or broken, the whole systembreaks down.

The Friends model is distinct from these two. Though developed independently it has thestrengths of both of the above mentioned systems. It is different from CSM in the followingrespects. It can dynamically temper the response based on the current environmental conditions.It has a notion of sliding scale of trust for its peers based on which a certain weightage is assignedto alerts received from them. This helps in reducing the overall uncertainty in response by droppingalerts from malfunctioning agents. It is different from AARIS in that there is no centralized control.This gives freedom to individual enterprises to choose their own responses without any restriction.This is an important criterion for the success of any co-operative scheme. There are provisions forrevoking responses locally which provides for graceful recovery of performance.

3.2.2 The Friends Algorithm

In this model, once an attack has been detected by one of the participating agents, it sends a alertmessage to its friends. A friend is a trusted co-operating agent. Each participant has a list of


friends and a trust associated with each friend. This trust can be adjusted based on the false alarmrates from these friends.

Once an agent suspects an attack, it send the suspected signature and an associated PerceivedThreat, PT , to its friends. The PT is a function of the number of such attack attempts seen andthe number of alerts received from its other friends for the same attack taken together with thetrust worthiness of those alerting friends. In particular notice that the cost of damage and response[73] is not taken into account as this might vary from one environment to another. Assessing thesecosts is best left to the individual agents.

If the PT thus calculated by an agent exceeds a pre-determined threshold and satisfies anyother criteria that the agent deems required, response action is taken. An example of such othercriteria is: an alert should be received from a certain number of unique agents with a trust abovea certain limit. This avoids spreading spurious alerts from compromised agents.

The list of friends is not static. It can be changed on a periodic basis based on the veracity ofthe previous alerts from each of the them automatically or by the site administrator. The protocolto be followed while updating the friends lists will be the same as in updating routing tables toavoid race conditions and other inconsistencies that are possible when data at different locationshave to be updated independently.

The actions taken are decided by the agents individually unless a contract [40] binds a pair ofagents to take a collective decision about the actions to be undertaken. The iterative actions takenby each agent include:

1. Assigning a threat level as perceived by the alert-receiver based on various parameters asmentioned above. This PT may be different from the PT seen by others.

2. Alerting its friends. Depending on the PT , a host chooses a different number of friends toalert.

3. Scanning the incoming and outgoing packets for the new signature. The intensity of scanningdepends on the PT at the particular enterprise. Based on the results of scanning, the PT atthat enterprise might increase or decrease.

4. If the PT changes based on scanning, sending new alerts with the new PT . This acts like acontrol mechanism to dynamically increase or decrease the scanning intensity.

5. Reducing the bandwidth available to the general traffic and increasing the bandwidth tothe alert messages. This is possible because the agents can control the traffic speed passingthrough it.

6. Blocking of traffic that is believed to be malicious.

7. Backing-off from blocking the allegedly malicious traffic once it is found not to be so. This isachieved automatically since the intensity of the scanning decreases if there is a decrease inPT .

This model just provides a protocol for exchange of useful IDS messages. It is up to theindividual enterprises to act upon them appropriately to safe gaurd their networks.


3.2.3 Limitations

This model could fail if the network is already saturated with malicious worm traffic. Reference[11] deals with such network connectivity problems. The techniques described in [11] can be usedto analyze the robustness of network architectures against denial-of-service by link and node de-struction.

If we treat our friends’ network as a graph with nodes representing agents and the edges betweenthem as links, we could answer the question, ‘how many links may get saturated before the alertmessages can’t reach others?’.

N : Total # of participants

F : # of friends for each agent

τ : # of independent agents from which alerts are required

before any action can be taken

There are F unsaturated links from each agent to its friends when there is no worm. If thisagent has to take action, it should have at least τ links unsaturated to receive τ alerts. Thus, amaximum of F − τ links could be saturated. If more than F − τ nodes are saturated, then thisparticular node cannot even receive the required number of alerts to take any action. Consideringthe links to be uni-directional and since there are N agents in total, we could have a maximumof N.(F − τ) links saturated before the model can fail. Beyond that for each additional link thatgets saturated, a maximum of one node gets cut-out from the network. In the worst case, if eachadditional link beyond N.(F − τ) that becomes saturated cuts off one node all nodes are isolatedwhen N.(F − τ) + N links get saturated.

Another limitation of this model is that the signature of the worm is assumed to be availablealready or almost immediately after the worm is detected. But, it is very difficult to get thesignatures of zero-day attacks within a very short time. Because, there are several techniques forvery high-speed worms, this model could come a cropper against them. Fortunately, however, asdiscussed in [22] zero day attacks are very far and few in between.

3.3 Hierarchical Model

Hierarchical and distributed correlation is necessary in analyzing highly distributed and environ-ments [82]. This model provides a hierarchical co-operative response strategy. This helps in alertingenterprises of possible attacks before they actually happen based on the attacks seen at other sites.The framework consists of hierarchically arranged control structures that provide the ability torecognize global patterns from isolated local events over a widely distributed heterogeneous envi-ronment.

Simulations conducted with this model on worm scenarios reveal that this model performs betterthan the previously discussed Friends’ model.

Section 3.3.1 covers the related work while section 3.3.2 describes the model itself. Since thebest application of this model is against worm attacks, we have developed a mathematical model forthe performance of this strategy against worm attacks (section 3.3.3). This model is also verifiedby simulations of worm scenarios. In addition, we also simulate stealth worm and false alarmscenarios(section 3.3.4).


3.3.1 Related Work

Event Monitoring Enabling Responses to Anomalous Live Disturbances (EMERALD) [90] is a dis-tributed misuse and anomaly intrusion detection system for large scale heterogeneous environmentsbut within an enterprise. Its architecture is similar to the model discussed here but different inthe sense that it has an hierarchy of monitors. Each monitor consists of an expert system thatreceives reports from the analysis componenets and invokes various response handlers. This is agood approach for enterprise level responses. As such, all the intrusion reports are trusted. As themonitors receive increasing amounts of misuse information stricter response measures are invoked.There is no mechanism to attune the reponses to accomodate false alarms.

In contrast to EMERALD, the hierarchical model tries to correlate intrusion detection andcoordinate response at a much bigger scale; across enterprises. It is also able to handle false alarmsand isolated incidents by including a time to live’(TTL) metric in its alert messages. In particular,it is able to respond to work-like scenarios very effectively.

3.3.2 Description of the Model

This model assumes a tree structure where the internal nodes of the tree are control structuresand the leaves are the representative response/IDS agents at various participating enterprises. Thecontrol structures are assumed to be immune to intrusions. Each node in the tree has equal numberof children except for the leaves. Each leaf node in the tree communicates its local intrusion reportsto its parent control structure. The control structure correlates these reports. If the number ofunique children reporting a similar intrusive activity reaches a certain threshold(τ), it alerts all itschildren to take response actions against this particular attack. Each enterprise’s response may bedifferent. It is important to note that the threshold, τ , should be less than the number of childrenfor each control structure. The alert message is communicated down the tree from the controlstructure to the individual enterprises. Thus, if a control structure has n children, n − τ of themare alerted in advance of the intrusion. These n− τ enterprises take preemptive actions to preventthe attack. This is explained by Fig. 3.1.

Each control structure further escalates the consolidated intrusion reports, to its parent oncethe threshold is crossed. This escalation happens all the way upto the root. Once, the root nodealso receives more than tau intrusion reports all the participants are effectively alerted to respondto this particular intrusion.

The thresholds at each level of the hierarchy could be different to suit different levels of tolerance.For example, a certain collection of enterprises could be of very similar nature like e-commerceenterprises. They could all report to the same control agent. If there are repeated attacks at onesite, there is a high probability that the same attack could be possible at the other similar sitestoo; possibly due to a discovery of a new vulnerability that is common to all of them. In this case,the threshold could be just 1. Whereas, at one level higher in the hierarchy, the threshold couldbe set to something much higher than 1 because, the constituent enterprises might beof differentnature and similar attacks are not very probable.

This scheme is susceptible to false alerts of a different nature. The control structure couldreceive alert reports from certain enterprises that are only local attacks and not widespread. Thiskind of false alerts are handled by associating a TTL with the latest alert received by a controlstructure. If the TTL expires before receiving fresh intrusions reports of the same kind, all thechildren of this control structure are instructed to revoke the preemptive action previously initiated


��

��

��

��

� � � � � � � � � � � �

��

��

��

��

��

�� !�!

"�"�"�"�""�"�"�"�""�"�"�"�"

#�#�#�#�##�#�#�#�##�#�#�#�#

$�$%�%

&�&�&&�&�&&�&�&

'�'�''�'�''�'�'

(�(�(�(�((�(�(�(�((�(�(�(�(

)�)�)�)�))�)�)�)�))�)�)�)�)

*�*�**�*�**�*�**�*�**�*�*

+�+�++�+�++�+�++�+�+

,�,�,,�,�,,�,�,

-�-�--�-�--�-�- Vulnerable Site

Tau at each level = 2

.�./�/Infected Site0�01�1Alerted Site

Unalerted Controller

2�2�22�2�23�3�33�3�3 Controller with < tau alerts

4�4�4�44�4�4�45�5�55�5�5

Controller with >= tau alerts

6�6�66�6�66�6�67�7�77�7�7

Controller instructed to respond

Figure 3.1: The Hierarchical model

as the threat doesn’t seem to exist any more or the threat is local to only a few sites. These fewsites already have independent response mechanisms in place that can handle the attacks. All theintrusion reports are discarded except for one which will be used for future reference. When freshreports are received, they are compared with the past reports. If there is a match, a stealth worm[115] is suspected and the TTL associated with this report is increased so that this intrusion canbe monitored for a longer time. Reports with large TTL values are manually inspected at regularintervals and the reports are purged if the corresponding intrusions are found not to be a threat.

3.3.3 Mathematical Models

Simple mathematical models of worms are described by Weaver et al in [115]. Here we will provethat our model is indeed bounded. We prove this by showing that the root node receives τ intrusionreports within a finite time.

Theorem 1 (Bounding Theorem). The root node receives τ intrusion reports within a finitetime.

Proof. For the sake of this proof, we will consider a small sub-tree with just 2 levels. The top level,containing the root node, and the leaves all form a group. Each infected leaf node tries to infect allnon-infected leaf nodes in its group. For each infected/non-infected leaf node pair, the time untilinfection of the non-infected node by the infected one is exponentially distributed. By scaling oftime, we can take the mean of this distribution to be 1.0. It is assumed that all infecting processesoperate stochastically independently.

i : # of infected nodes in a group

h : the threshold for alerts

g : the group size


Then in state i, there are i(g − i) exponential random variables in progress at once, since eachof the i infected nodes is trying to infect each of the g − i uninfected nodes. Then the time to gofrom state i to i + 1 will be the minimum of i(g − i) exponentially distributed random variables,and thus will itself be exponentially distributed1, with mean 1.0/[i(g − i)] [79].

For simplicity, we will consider the case h = g − 1; the more general case is handled similarly.The total expected time to an alert, starting at the time the first member of the group becomesinfected, is

g−1∑

i=1

1

i(g − i)(3.1)

Using a standard approximation, (3.1) is approximately equal to

∫ g−1

1

1

x(g − x)dx =

1

g

∫ g−1

1

(1

x+

1

g − x) dx

=2

gln(g − 1) (3.2)

The latter quantity goes to 0 as g → ∞. In other words, (3.1) remains bounded as g → ∞.This means that the mean time to alert the root is bounded no matter how big our group size is.This is verified by our simulations.

Other important quantities

Apart from the proof, there are other quantities that are of interest. The goal is to minimize thenumber of worm infections/intrusions amongst the participating sites. To achieve this, the rootnode must be alerted while there are minimum possible number of infections at the leaf nodes.Also notice that we need a certain minimum number of intrusion reports from the leaf nodes forthe root node to be notified. So, we will first calculate the minimum number of infections needed.Then we will derive the probability with which this will happen.

For the sake of this discussion let us consider that the leaves are at level 0 of the tree, theparents of the leaves are at level 1 and so on. Let,

λ : # of children per level

n : # of levels

mi : # of nodes at level i

τ − 1 : Infection Tolerance or Threshold

We need atleast τ infections in each susceptible domain for the control structure to escalate analert. Here we define a domain to be a control structure at level 1 and all the participants thatreport to it. Since there are n levels in the hierarchy and the threshold is τ − 1, at each level, theminimum number of infections required at the leaves for the root node to be alerted is:

Imin = τn−1 (3.3)1Note that the Markov property is being used here implicitly.


Given, the number of levels of control structures and the damage that we are willing to bear, Imin,3.3 dictates the threshold at each level.

Also, the number of nodes at level 0, m0 = λn−1, at level 1, m1 = λn−2 and so on. The quantitym1 represents the number of domains of susceptible hosts. Each infection can pick a victim fromany of m1 domain. Thus, the probability of an infection choosing a particular domain to infectis 1/m1. Let this value be P1. Then, the probability of i infections choosing the same domain toinfect is:

Pi = 1/mi1

The number of ways this one domain can be chosen is Cm1

1= m1.

For a node to protect its children, it should have received τ infection alerts from its children.That is, i = τ . Let π1 be the probability that some non-leaf node at level 1 will protect its children.Then,

π1 = Cm1

1.mτ

1 = 1/mτ−1

1

Similarly, π2 = (1/mτ−1

2) times the probability that τ nodes are being alerted at level 1. This

is:

π2 =

(

1

mτ−1

2

)

.πτ1 =

(

1

mτ−1

2

)

.

(

1

mτ−1

1

)τ

Thus, at level n− 1, we have,

πn−1 =

(

1

mτ−1

n−1

)τ0 (

1

mτ−1

n−2

)τ1

· · ·

(

1

mτ−1

1

)τn−2

=

n−1∏

i=1

(

1

mτ−1

n−i

)τ i−1

(3.4)

But the only node at level n− 1 is the root node. So, the (3.4) gives us the probability that theroot will be alerted with the minimum number of infections at the leaves.

3.3.4 Simulations

We simulated 3 different scenarios that a worm defense system would face in reality and tested ourmodel against each of them.

We tested our model’s ability to stop the spread of a worm in the first scenario. We also studythe behaviour of our system against worms of different speeds for different configurations of thehierarchy. In particular, we study damage control in terms of number of sites that were preventedfrom infection and the response time of our system.

In the second scenario, we generate varying levels of false alarms. In this case, we test ourmodel for its intelligence to realize that the alerts are false and revoke the reponses. We also studythe effect of TTLs on the behaviour of our system for various rates of False alarms.

In the last scenario, we introduce Stealth worms also known as slow worms. These are supposedlydifficult to discover using statistical methods of intrusion detection because they don’t show anyanamolous increase in traffic, which is one of the most obvious feature of most worms.

The simulation was implemented in Perl. The simulation was done on a network modeled as atree with 4 levels. Each level of the tree has 4 children. The structure of network and thresholds


were chosen such that the methodologies and results are comprehensible. More complex structureswith different number of children at each level and different thresholds at each level could also besimulated by passing different parameters to the simulator.

The flow of time is considered to be discrete and all actions take place synchronously. Eachinstance of the worm trying to spread is independent of other instances of the same worm. Alertsare raised in the same time slice as an infection occurs. Each alert is propagated as high as possiblein the hierarchy in the same time slice. Once the root node receives τ alerts, all participantsare alerted to the impending (worm) attack and hence the attack cannot propagate any further.Complete immunization is said to have occured at this moment.

Worm Scenario

This scenario is started by randomly infecting a single leaf node. The worm scenarios were simulatedwith a large TTL value, 1000 to study its ideal behaviour where there are no false worms.

0

50

100

150

200

250

300

0 2 4 6 8 10 12 14 16

# of

nod

es

Time (no units)

Hierarchical Model of worm defense

# of levels = 4

# of children = (4, 4, 4, 4)

Threshold = (2, 2, 2, 2, 1)

Infection Rate = 0.5

TTL = 1000

protectedinfected

(a) Response for a low rate of infection

0

50

100

150

200

250

300

1 1.5 2 2.5 3 3.5 4

# of

nod

es

Time (no units)


# of levels = 4

# of children = (4, 4, 4, 4)

Threshold = (2, 2, 2, 2, 1)

Infection Rate = 5

TTL = 1000

protectedinfected

(b) Response for a high rate of infection.

20

25

30

35

40

45

50

55

60

65

70

0 2 4 6 8 10 12 14 16 18 20

Per

cent

age

of in

fect

ed n

odes

Infection rate

Response Analysis to Worms.

Threshold All 2’sThreshold All 3’s

(c) Percentage of machines infected.

0

20

40

60

80

100

120

140

160

0 2 4 6 8 10 12 14 16 18 20

Tim

e ta

ken

for

com

plet

e pr

otec

tion

Infection rate

Timing Analysis of response to Worms.

Threshold All 2’sThreshold All 3’s

(d) Timing Behaviour.

Figure 3.2: Worm Scenario


The first two experiment we conducted was for two very simple cases to show the typicalbehaviour of the system. Both cases had identical parameters with 2 as the threshold. But the firstexperiment had an infection rate of 0.5 while the second one had ten times that, 5. An infectionrate 5 means, the worm will try to infect 5 other sites in one time step. Figs.3.2(a) and 3.2(b) showthe time it takes to alert the root node of this hierarchy and also the number of sites that wereinfected. We can see that the number of infections before complete immunization could take placeis almost the same for both the cases, about 55− 60.

Observation 1. The number of infected enterprises is independent of the speed of the worm.

We verify this claim with the next experiment. We repeat the simulations for various ratesof infection with 2 different levels of thresholds. The results are shown in Fig.3.2(c). As we cansee in Fig.3.2(c), the number of infections before complete immunization takes place is almost thesame for varied rates of infection. However, for higher thresholds, significantly more machines areinfected than for lower thresholds.

Fig.3.2(d) shows the timing behaviour of the same experiment. While the number of infections,remain the same for various infection rates, complete immunizations occur at different times fordifferent infection rates. We can see that the two are inversely proportional. For high rates ofinfection, maximum possible protection is achieved quicker than for slower rates of spread. This isa direct result of the dependence of the alert propagation on the infection rate. This also verifiesour Bounding theorem.

We also see that the thresholds don’t determine the time taken as it takes almost the same timeto achieve complete immunization for 2 different threshold values. The only thing that varies withthreshold is the number of infected machines.

Observation 2. The time taken for complete immunization is inversely proportional to the infec-tion rate.

Observation 3. The number of infected sites is proportional to the threshold.

It is obvious that we can’t forecast an unknown worm’s infection rate. But we can define ourtolerance. This model can tell us what should be the threshold, for a given tolerance independentof the infection rate.

For example, if we want to save 90% of the participants in the event of a worm attack, we justneed to find out from simulations or the equations derived earlier, the thresholds at various levelsof the hierarchy. It would do the job for us slowly for quickly depending on the infection rate ofthe worm.

False Alarms

In this scenario, the rate of false alarms is fixed at the beginning of the simulation. Unlike wormswhere only infected sites can infect others, there is no relationship between one false alarm andthe next. The site that raises a false alarm is determined randomly. All false alarm scenarios weresimulated with TTL window sizes varying from 10 to 400 time units.

In face of ambient false alarms, that reflect the real-world scenario, the number of sites givenprotection(alerted in advance about the worm) does not rise steadily as it happens in case of realworms. Rather, the number keeps oscillating as the control structures drop the intrusion reports


0

50

100

150

200

250

300

0 100 200 300 400 500 600 700 800 900

# of

nod

es

Time (no units)


# of levels = 4

# of children = (4, 4, 4, 4)

Threshold = (3, 3, 3, 3, 1)

False Alarm Rate = 2

TTL = 200

protectedinfected

(a) Back-off due to False Alarms

0

20

40

60

80

100

120

140

160

180

0 50 100 150 200 250 300 350 400

Ave

rage

# o

f pro

tect

ed n

odes

TTL (no units)

Response Analysis to False Alarms.

FA Rate 246

(b) Cost of responding to False Alarms.

Figure 3.3: False Alarms Scenario

if there are no alerts within the TTL as seen in Fig.3.3(a). This oscillation is an indication of aseries of false alarms. Or it can be considered as an indication of a Stealth Worm in motion whichhas very slow rate of spread as discussed in the next sub-section. The curve that says infected justcounts the number of false alarms raised, but considers that to be infections because, the systemcannot decide without uncertainity that this is not a worm.

Fig.3.3(b) shows the average number of sites alerted in advance in response to false alarms forvarious TTLs and various false alarm rates. The average is calculated by adding up the numberof sites that acted preemptively during each time slice and dividing it by the total duration thesimulation ran. This protection involves a price and can be considered equivalent to a self inflictedDoS. As we can see, if the TTLs are low enough, we have to pay a very low price. But we wouldnot be able to identify Stealth worms which need a high TTL. At the same time, a high TTL would‘cry worm’ even for low rates of false alarms and raise costs unnecessarily.

Stealth Worms

Two experiments were conducted for the Stealth worms scenario. They were simulated with verylow rate of infection of 0.05 but for two different thresholds. We can see the same oscillating patternin Fig.3.4(a) and Fig.3.4(b) which were recorded for a Stealth worm simulation with a small TTLof 60. Fig.3.4(a) shows a case where the stealth worm is suppressed because of a low threshold ofthe defense system.

Fig.3.4(b) shows a scenario where the strategy is able to sense that something is wrong. But dueto the high threshold, the rate of alerts received is just low enough that the TTL expires frequentlyand our system backs-off reasoning it as a false alarm. This suggests that we need a higher TTLor a lower threshold. But a high TTL means a high cost due to false alarms which is unworthy.

Since an oscillating curve means a series of false alarms or a stealth worm, we can afford theluxury of human intervention.

So, we need to arrive at a compromise saying that we will look out for Stealth worms whichonly move above a certain speed. The TTL in a way also dictates how many machines we will


0

50

100

150

200

250

300

0 50 100 150 200 250

# of

nod

es

Time (no units)


# of levels = 4

# of children = (4, 4, 4, 4)

Threshold = (2, 2, 2, 2, 1)


TTL = 60

protectedinfected

(a) A stealth worm overpowered with a lowthreshold

0

50

100

150

200

250

300

0 50 100 150 200 250

# of

nod

es

Time (no units)


# of levels = 4

# of children = (4, 4, 4, 4)

Threshold = (3, 3, 3, 3, 1)


TTL = 60

protectedinfected

(b) A Stealth worm sneaking in due to a highthreshold

Figure 3.4: Stealth Worsm Scenario

have to sacrifice before our defense mechanism takes over. We may even lose all machines beforewe respond if we choose a very small TTL.

3.4 Future Work

The friends model is already being researched by the E-MIST team at UCDavis and SRI on theDETER[84] testbed. Our goal is to accomplish the following for the hierarchical model.

3.4.1 Experimental Validation

This experimental evaluation can be done on any of the publicly available research testbeds[37]:

• The DETER[84] testbed: It is primarily designed for medium scale repeatable experimentsopen to only DETER memebers. This is located at USC, ISI with about 64 PCs each runningseveral virtual machines. This is well within the requirements of a co-operative hierarchicalmodel. Since UCDavis, is already a part of the DETER group, we hope to be able to use itfor this research.

• Emulab[37] at Utah: Once we have a small implementation running we can extend itto large scale environments. For this purpose, we can use use the large scale emulationenvironment Netbed [37] at University of Utah. This testbed is open to all reseachers. Thistestbed is much bigger than the DETER testbed and can support much more realistic trafficpattern. It derives its strength from 178PCs, 40 wide-area nodes and 9 802.11 wireless nodeswith plans to extend this further. We hope testing on this testbed will give us more insightinto our model.

For the success of this model, we need to generate signatures of attacks on the fly to be sharedwith other co-operating agents.


3.4.2 Automatic Signature generation

Typical approaches to generating candidate signature is for analysts to examine the attack, generatecandidate signatures, test it against an archive of past network traffic data and then deploy thesignature into the IDSs. The past data is normal traffic trace and the candidate signatures is asubstring of an attack trace. The testing of candidate signatures against past data can take anhuge amount of time, particularly, when the data is to of the order of terabytes. Hence, we need aparticularly, skilled analyst working on the task of generating the signature. There are two problemswith this. First, human resource is not available at all times. Second, with a worm outbreak, wedon’t have the luxury of time to test signature candidates before deploying them. So, we needmachines to generate signatures which can do them fast and at any time of the day.

Machines can generate signatures by taking a sample attack trace and generating all possiblecandidate signatures and testing them against the past data. The problem with machines generatingsignatures is that they are not as skilled as a human analyst. There is a greater chance that they willgenerate lot of bad candidate signatures before they generate one that is good enough to detect thecurrent attack. So, we have two choices. We could either improve the intelligence of the machinesgenerating signature candidates or quicken the testing process. We choose to address the latterproblem.

The testing process is essentially a string matching problem. We propose using suffix treesto expedite the testing process; matching candidate signatures against past normal traffic trace.The original idea was suggested in Heberlein[52]. Suffix tree is a data structure that exposes theinternal structure of a string in a deep way[33]. Suffix trees can be used effeciently for the substringproblem.

If we are given a text T of length m, after O(m) preprocessing time[38], we can take in anyunknown string S of length n and either find an occurence of S in T or determine that Sis not inT in O(n) time.

This is a very useful feature for us. We can preprocess the normal traffic trace, storing it asa suffix tree and match any candidate signature within a time proportional to the length of thecandidate. This time bound is not achievable by the Knuth-Morris-Pratt or Boyer-Moore methods.These methods would preprocess each input and then take Θ(m) worst case time to search for thestring in the text. In our case, m is the past traffic data which can easily be several terabytes ofdata which renders the KMP or BM methods useless.

x a b x a c1

a

bx

a

c

2

cc

bx

ca

3

6

5

Root

β4

cα

Figure 3.5: Suffix Tree for the string xabxac


The suffix tree for an example string, T , xabxac is shown in Fig 3.5. This string would representa snippet of the past network traffic. Each path from the root to a leaf node represents a suffix inthe text, T , and each leaf is labelled by a number indicating the position in T for that suffix. Forexample, the branch with leaf node marked 2, is labelled abxac, indicating that the string abxac isa suffix of T starting at position 2. Note the internal nodes marked α and β. The total numberof leaves below each internal node represents the number of occurences of the pattern formed byconcatenating the labels of edges from the root to that node. For example, there are 2 leaves belowα, indicating that the pattern xa appears twice in T .

Suppose, our IDS detects a traffic pattern xax. Suppose, we have a candidate generator thatcan generate candidates of length 2. Suppose, the candidate signatures generated are xa and ax.Fig 3.6 shows how these are matched against the normal traffic data. The first candidate xa ispart of the normal traffic trace hence cannot be an attack signature. The second candidate, ax, isanamolous. This pattern is not present in the normal traffic pattern. We find no match for thiscandidate in the suffix tree. Therefore, we would use the second candidate as a signature to detectattacks that have the trace xax.

x a b x a c1

a

bx

a

c

2

cc

bx

ca

3

6

5

Root

β4

cα

(a) Testing candidate xa

x a b x a c1

a

bx

a

c

2

cc

bx

ca

3

6

5

Root

β4

cα

(b) Testing candidate ax

Figure 3.6: Testing Signature candidates

Some problems

The normal data trace could be really huge with terabytes of data. Though the sufix tree is linearin size to the input text, we cannot have the entire suffix tree in the memory. We suggest two waysto overcome this problem:

• We can use secondary storage devices to store parts of tree, swapping them into the memoryas and when required.

• Suffix trees work effeciently to find if a string is a substring of a fixed set of strings also.Hence, we can break the normal traffic pattern into several strings and build different suffixtrees for each part. This way, we need not bother about safely swapping in and out parts ofsuffix trees. It is easier to swap full data strutures than parts of them.

When we break the normal data into several parts, we might miss some of the normal patterns,leading to signatures generating false alarms. For example, suppose T = . . . xa . . . . We break T


into two parts T1 = . . . x and T2 = a . . . , a candidte S = xa will be accepted as an attack signaturewhereas it a part of the original data trace T . This would lead to a lot of false alarms. To overcomethis, we can have some overlap between two parts of normal data. Breaking T into T1 = . . . xaand T2 = xa . . . , will solve this problem.

What we need is to implement this idea and see, how well it works. We expect it to take 6-8weeks to accomplish this task.

Chapter 4

Formal Reasoning about security

4.1 State of the art

As already noted, the security of a network is more often than not, verified using adhoc approachesincluding penetration testing and configuration of security components through trial and error[107]. However, there are a few systematic approaches that can be mechanized.

The first approach checks the configuration of the systems. For example, COPS[39] uses a setof shell scripts to check for mis-configurations in a Unix system. Some of the checks it does arethe file permissions of system security relevant files like /etc/passwd and set-uid program files.Su-Kuang[12] and NetKuang[130] are examples of similar tools. Ramakrishnan[94] uses a modelchecking approach to detect and analyze configuration vulnerabilities. They claim that they canfind known and unknown vulnerabilities.

The second approach is file integrity checking. Examples are Tripwire [67], Miro[6], etc.,. Theyverify the security of the system by monitoring suspicious changes to security critical files like/etc/passwd and ~/.rhosts.

The third approach is the attack graph approach. An attack graph is a representation of allpaths through a system by which an attacker can achieve his/her goal. Traditionally, attack graphsare drawn by hand. The process involves scanning each host in the network for vulnerabilities.Security analysts then use this information to construct the attack graph by hand. This process isquite cumbersome and highly error prone.

However, quite a few approaches have been developed to automate this process. An attackgraph generator tool has been developed by Swiler et al[118, 87]. The authors developed theirown algorithms to match attack templates to network configuration information and hypotheticalattacker profiles. Their prototype generated an attack graph for a network with two hosts and fiveattack templates. While several methods based on graph-theory were described to handle the issueof scalability, their feasibility was not fully explored.

Ammann et al[7] propose a graph based approach to generate attack graphs. They claim thatattack graphs present more information than is required for the analysts and that more usefulinformation can be produced for large networks even without an attack graph.

The third approach is to use model checkers to generate attack graphs. Ritchey et al [96] usethe model checking tool, SMV[3] to verify one security property at a time, in a network with twohosts and a firewall, and an attacker on the Internet. The model was hand-coded in the SMVlanguage. They indicate that the process of encoding a model in SMV language needs to be and

35

CHAPTER 4. FORMAL REASONING ABOUT SECURITY 36

can be automated to verify large networks. They also mention that the data structures used forreasoning, and hence the state space of the model, are bound to grow large.

This explosion in state space was encountered by Sheyner et al[104]. They modeled a networkwith two hosts and 4 vulnerabilities, and an attacker on the Internet. This model’s state space isabout 291. But only 101 states are reachable. It took about 5 seconds to generate the attack graph.But when they added a few other parameters, their tool took about 2 hours to generate the attackgraph.

4.2 Formal Methods

Though the above mentioned schemes are systematic, they lack the ability to prove that a systemis secure with a scientific logic. Though model checking has a strong mathematical and scientificbackground, it is essentially a brute force approach using clever ways to explore the entire statespace of a system. It lacks the ability to express universal and existential quantifiers easily. Atbest it can be considered a semi-formal method; a definite improvement over other systematic andad-hoc approaches to security.

Whereas, using formal methods, people can specify, develop and verify systems in a moresystematic, rather than ad-hoc, manner [126].

Simply using a formal notation does not ensure that specifications will be correct: writing acorrect formal specification is no easier than writing a correct program or a correct description inEnglish.[113]. A method is formal if it has a sound mathematical basis, typically given by a formalspecification language. This basis provides the means of precisely defining notions like consistencyand completeness and a means to prove that the system has been implemented correctly[126].

The distinctive feature of formal specification is that they support formal deduction: it is possi-ble to reduce certain questions about a formal specification to a process that resembles calculationand that can be checked by others or by machine. In order to conduct mechanized analysis, it isnecessary to support a specification language with powerful tools like theorem prover [113].

The first half of this chapter describes our experience with verifying the security of a samplenetwork using SMC[34]. Sheyner[104, 60] and Ammann[7] have already demonstrated the use ofa model checker in generating attack paths on a network. They both used a very small networkfor demonstration. If we could extend that to even reasonable sized networks, we can abstract realnetworks and use this approach to certify security of networks in the real world.

Unfortunately, the above approach did not scale up to even small networks that were onlyslightly bigger than the one used in previous researches. As mentioned earlier one of the imped-iments was the lack of a efficient way of find existential quantifiers in model checkers. Hence wepropose theorem proving techniques which can take human input to instantiate existential quanti-fiers. The second half of this chapter lays down an idea for employing interactive theorem provingto reason about the security of a network.

4.3 Attack Graphs

We tried to extend the Model Checking efforts described in Sheyner [104] and Ammann[7] in orderto ascertain if we can get any closer to modeling even a reasonable sized network, if not largenetworks.


For this purpose, we chose NuSMV[5], an improvised version of SMV as our model checker.We chose NuSMV for the following four reasons. First, this is one of the most popular symbolicmodel checkers available which makes it easy to get help. Second, it is easy to use. Third, theprevious work done in this area by Ritchey[96] and Sheyner[104] used this as the model checker ofchoice. We wanted to extend their work and compare our performance results with that of theirs.And finally, Sheyner[104] readily had a tool that would compile a simple xml specification of ournetwork into NuSMV specification which would save us a lot of time.

We used the compiler from [104] because, modeling with NuSMV is a very laborious and trickyprocess; akin to software programming. A typical NuSMV specification in the example suite pro-vided along with the NuSMV package is a few thousand lines of code. Such skills and the time thatit needs cannot be expected of a typical SA who will need to use this tool on a daily basis.

The rest of this section is organized as follows. The section 4.3.1 first describes the methodologywe use to generate attack graphs. Section 4.3.2 introduces an example. Section 4.3.3 explains themodel and scenarios we consider for model checking in the project. Section 4.3.4 discusses theexperiments and results. Section 4.3.5 explores the reasons for the poor performance of symbolicmodel verification for the task of producing attack graphs.

4.3.1 Methodology

Our general plan of action to push NuSMV to its limits follows(see Figure 4.1(a)). We specifiedthe network model in xml format and compiled it to the NuSMV language using the compiler fromSheyner[104]. This compiler produced a NuSMV specification that has all the possible connectionscenarios including an attacker connecting to himself, which is meaningless in a real world scenario.We fed this specification to NuSMV for verification of certain properties. We noted the performance.We then tried to optimize the network specification by removing some of the components thatdon’t add value to the verification of the properties in question. A new NuSMV specificationwas generated by feeding this enhanced xml specification to the compiler. The resulting NuSMVspecification was verified for the same properties as before. We noted the new performance. We nowpruned the optimized NuSMV specification by hand to remove some of the uninteresting/unlikelyscenarios such as hosts inside our network trying to attack the attacker. We hand-optimized thecode until we could no longer represent the system being modeled correctly.

As mentioned earlier, SMC suffer from state space explosion problem. Ordered Binary DecisionDiagrams(OBDD)[95] form the basic data structure for symbolic model checking. The size of theOBDD depends on the order of the variables in the system model for Computation Tree Logic(CTL).There are various algorithms to reorder the variables and find a different OBDD to suit our speedand space requirements. NuSMV comes with the CUDD package which is a collection of libraryroutines to manipulate OBDDs efficiently. We turned on the dynamic variable re-ordering switchand chose the sift algorithm which would find an optimal position for each variable. We chose thisalgorithm because it gives us the greatest reduction of the size of the OBDD.

We only tried to generate a single attack trace instead of an attack graph as we only wantedto verify how big a realistic network can we model and verify using model checkers. Moreover,generating an attack graph from model checkers has already been demonstrated in Jha[60].


HandOptimize

HandOptimize

NuSMV Counter exampletrace, if found

specificationNuSMV

xml NuSMVof the modelxml specification

Compiler

PSfrag replacements

from [104]

(a) Strategy

Attacker

InternetRouter /

Firewall

IDS

PC

sshd

PC

sshd

PC

sshdftpd/httpd

Enclave SGC

Server

ftpd/httpd

Enclave BPRD

Server

Enclave BPRD

Server

PSfrag replacements

from [104]

(b) An example network

Figure 4.1: The Model Checking Approach

4.3.2 An example

Figure 4.1(b) shows an example network we tried to model. It is slightly different and bigger thanthe model used in both [104] and [96]. We already verified networks of sizes discussed by them both.This example has 2 enclaves, each with a server and a client. The server is running the ftp service,although this can more abstractly be thought of as any Internet accessible service such as a webserver. The client is a standard end-user PC. Such PCs often have services running, either defaultfactory settings that the user may be unaware of or a service deliberately set up for organizationalpurposes. Such services may not be secured to disallow Internet access. The above set up is verytypical of office networks. In our example, the PCs are running sshd to allow encrypted access forothers within the organization.

Our example has a router and firewall separating the network from the Internet. We also havea IDS behind the router, but the placement of the IDS is immaterial to our analysis here. In fact,the IDS is not even required for our analysis. One can see in Section 4.3.4 that we removed it fromour model during one of the optimization rounds. It was included for the sake of completeness.

We assume that the attacker has complete knowledge of the topology of our network. Hestarts his attacks from a single computer Attacker which is outside the firewall. Initially, he has noprivileges on any of the machines within our network. Our goal is to prevent any attacker fromgaining root access the on PC in BPRD enclave. We can specify this requirement as a CTL formula:

AG(network.adversary.privilege[3] < network.priv.root)

to be verified by the model checker.

4.3.3 Description of the model

NuSMV provides for a hierarchical schema for modeling systems. In our system, modeling consistsof describing the network which in turn is described by the hosts on the network, the various attacksand exploits and the connectivity relationships between hosts on the network.


The network description

The network is described by its components, viz-a-viz the hosts in the network, relationship betweenthe hosts, the privilege levels possible and the various atomic attacks possible in the network.

The state of the network is described by the current values of various parameters, like thecurrent vulnerability that is being exploited and the attack-id, the source and target IP addressesinvolved in the current attack, and the current privilege level of the attacker in the constituenthosts. Initial values are assigned to all the parameters. Non-deterministic rules are defined basedon which the variables assume new values which collectively takes the network to a new state.

Each host in turn is described by the set of services being offered, the vulnerabilities present init and its IP address. The relationship between the hosts are described by the connectivity matrix.

Exploit and attack descriptions

This model contains four atomic attacks: sshd buffer overflow, ftp writable home directory, rshlogin and xterm buffer overflow. The sshd buffer overflow is in the generic class of “remote to root(R2R)” attacks. It allows a remote attacker to obtain root privileges on the target machine. Theftp writable home directory attack allows the attacker to set up a trust relationship between thetarget machine and any other machine. The rsh login attack exploits a trust relationship to getuser level privileges on the target machine. It is in the generic class “remote to user (R2U)”. Thexterm buffer overflow is a privilege escalation that changes user privileges to root privileges. It isin the generic class “user to root (U2R)”.

Consider the example network shown in Figure 4.1(b). As shown, there are two different servicesrunning in the network. These two services allow at least two different atomic attacks over thenetwork initially. First, the sshd buffer overflow attack which directly gives root access to anattacker. Second, the ftpd .rhosts attack which lets an attacker exploit a ftp vulnerability to writea .rhosts file in the ftp home directory. This creates a trust relationship between the attacker’smachine and the ftp server. In both these cases, the attacker need not have any privileges on thetarget machines initially. Once an attacker gains an ordinary user privilege, he can exploit a localxterm vulnerability to gain root access on the machine.

Each attack is described as a rule in NuSMV as described in Sheyner [104].

Connectivity Description

The firewall information is embedded into the connectivity matrix instead of using a separate hostas a firewall. This helps reduce the number of variables in the model of the network. This matrixdefines how one host in the network being modeled may connect to another host. The connectivitymatrix is an array of boolean values. Each row, i, represents a host i, as the source of the connection.Each column, j, represents a host j, as the destination of the connection. A cell (i, j) in this matrixwould contain a 1, if the host i can initiate a connection with host j and a 0 otherwise.

Source Destination Address Action

Any Any Server AllowAny Any PC Allow

Table 4.1: Scenario-1 Filtering Rules.

Source Destination Address Action

Any Any Server AllowAny Any PC Deny

Table 4.2: Scenario-2 Filtering Rules.


We envisage four scenarios. In scenario 1, we turn ‘off’ the firewall such that both the serversand both the PCs can accept connections from anyone. Table 4.1 shows the filtering rules at thefirewall for this scenario. The connectivity matrix would contain 1s in all the cells. In scenario 2,we turn ‘on’ the firewall such that SYN packets to servers are only allowed to pass through thefirewall and all other connection requests are dropped. Tables 4.2 and 4.3 show the filtering rulesand the corresponding implementation as a connectivity matrix, respectively, for this scenario. Inscenario 3, we allow SYN packets to the server in the SGC enclave only from the Internet. Theserver in the BPRD enclave however still can receive SYN packets from the 2 PCs and the serverbehind the firewall. In scenario 4, we implement a true “demilitarized zone” (DMZ). SYN packetsare allowed to the SGC server only as in scenario 3. Further, we restrict servers from initiatingconnections.

However, the last two scenarios don’t change the size of the connectivity matrix at all becausewe still need the firewall to drop SYNs to any host other than BPRD.server. Hence, it is sufficientif we only verify the model for scenarios 1 and 2. The last two scenarios would show identicalperformance as scenario 2 though the counter-example traces might be different.

Host# Hostname Attacker SGC.PC SGC.Server BPRD.PC BPRD.Server

0 Attacker 1 0 1 0 1

1 SGC.PC 1 1 1 1 1

2 SGC.Server 1 1 1 1 1

3 BPRD.PC 1 1 1 1 1

4 BPRD.Server 1 1 1 1 1

Table 4.3: Connectivity Matrix for Scenario-2

4.3.4 Experiments and Results

We ran the experiments on a Intel-4 2GHz with 512 MB RAM machine, a fairly typical machinecurrently, although, machines with 1GB RAM are gaining prevalence. If such a small networkmodel needs more powerful machines, we surmise that this is a wrong technique to adopt for thetask of verifying real-size network models.

Recall that our goal is to protect the PC in the BPRD enclave. The corresponding specificationis: AG(network.adversary.privilege[3] < network.priv.root)

Figure 4.2 presents a graphical representation of the number of lines of xml code it took tospecify our sample network, the number of lines of smv code generated by the complier and thenumber of variables in the model. We can see that the number of variables reduces drastically witheach round of optimization for scenario 1 but remains almost the same for scenario 2. The reasonsare explained in the following two sections.

Scenario 1

Table 4.4 summarizes the results of the experiment for scenario 1 following the methodology de-scribed in section 4.3.1. See also Figure 4.2(a).

The first run of the NuSMV specification had about 379 variables. This run tried to generatea OBDD that couldn’t fit into the available RAM and so was killed.


��

��

��

��

��

��

��

��

��

��

� � � �

��

��0

200

400

600

800

1000

1200

1400

1600

Step 2 Step 3

xml line countsmv line count# of variables

# of

line

s / v

aria

bles

Step 1

(a) Scenario 1

��

��

��

��

��

��

��

��

��

200

400

600

800

1000

1200

1400

1600

# of

line

s / v

aria

bles

Step 1 Step 2 Step 3

xml line countsmv line count# of variables

(b) Scenario 2

Figure 4.2: The performance statistics.

The second run needs a special mention. Since, the attacker can establish connections withboth the servers and the PCs in this scenario, all the cells in the connectivity matrix contain a 1.Therefore, we decided to completely remove the connectivity matrix from the model. That meansthat all hosts can open connection with all hosts if the connection is accepted. This generated amodel with about 239 variables. The OBDD for this model was able to fit into just half of the512MB RAM, but it was very computation intensive that there was no response even after 2 hours.So we killed this run.

In the third run we optimized the specification further. We removed the IDS module as thisdoesn’t affect the ability of the attacker in any way to penetrate the network. It just raises an alertif it detects an intrusion. We also removed the unlikely attacks from the NuSMV code, like anattacker attacking himself. These cases are generated by the compiler for the sake of completeness.This reduces the number of variables in the model drastically to just 74. The experiment alsoconcluded in just under 3 seconds producing an attack path by which an attacker can gain rootaccess on the PC at the BPRD.

Scenario 2

Table 4.5 summarizes the results of the experiment for scenario 2 following the methodology de-scribed in section 4.3.1. See also Figure 4.2(b). Recall that in scenario 2, the firewall would allowSYN packets from the Internet only to the servers (see Table 4.3).

As we can see from the Table 4.5, scenario 2 also generated a model with a large number ofvariables, 379 to begin with. Since the model was different and had to account for the firewall rules,we couldn’t remove the connectivity matrix out of the system. So, we just tried removing the IDSfrom the model of the network. This generated a OBDD that was only slightly smaller than thefirst run. The behaviour of the model checker was similar to the first run.

In the third step of the optimization, we removed the unlikely attack instances, as we didfor scenario 1. This didn’t produce a smaller OBDD either. This was because the firewall rulesembedded in the connectivity matrix were still required to be included in the model. We couldn’tthrow away the connectivity matrix as we did in scenario 1, which caused the speed-up there.

Examples from the NuSMV package with several thousand lines of code also had only very few


# linesSl. Description

(xml/smv)# variables Result

1 Specification with all the con-nectivity information

294/1450 379 Went to an uninterruptiblesleep and the RAM was full.

2 Specification with the connec-tivity information removed.

231/1050 239 Used only about 50% of the512MB RAM, used almost90% of the CPU time, butdidn’t complete even after 2hrs.

3 Specification with no connec-tivity information and no un-interesting/unlikely scenarios.The IDS was also removedfrom the NuSMV code byhand.

231/851 74 Produced a counter-exampletrace.User Time: 2.9 secs.System Time: 0.03 secs.

Table 4.4: Scenario-1 Performance Report.

variables; of the order of tens of variables. But the example smv-dist/dme2-16.smv that had themaximum number of variables, 289, had only 232 lines of code. However, it ran with the (preferred)variable ordering provided with the package for about 87.5 hours without concluding. This seems toindicate that our model with about 379 variables, was definitely not easy to verify. Unfortunately,this is just a model for a very small network. Realistic networks are much bigger and more complex.

4.3.5 Technical Limitations

There are several reasons for the failure of this approach. We discuss three of them here in thecontext of success in verifying hardware using symbolic model checking.

First, we need to understand underlying mechanisms of symbolic model checking. In thistechnique, a system is usually modeled as a Kripke structure, M = (S, δ, L), where M is a finite-state concurrent system, S is the set of states that the system could be in at any point of time,δ the transition relation that dictates how the system transits from one state in S to another andL is a labeling function that labels each state with a set of atomic propositions that are true atthat state, L : S → 2|AP |, where |AP | is the number of atomic propositions in the model[34]. Themodel is verified against a specification φ, expressed in CTL, by checking if φ holds in all the initialstates of the model[34]. This is represented as:

M, s0 |= φ

A counter example trace can be obtained by checking the above for all states of the system. Wecan represent sets of states, S, and the transition function δ of a model as OBDDs with the helpof the labeling function, L. Also all the fundamental operations in model checking algorithms canbe performed by operations on OBDDs.

However, the pre∃ operation of the model checking algorithm depends on the OBDD’s nestedexists, also known as smoothing, operation which is shown to be NP-complete [55]. We also havethat any OBDD representation of a function with n − 1 variables, fn−1, has atleast a number of


# linesSl. Description

(xml/smv)# variables Result

1 Specification with all theconnectivity information

292/1450 379 The machine went into an unin-terruptible sleep and the RAMwas full. The last message fromthe model checker, “Checking forcircular assignments”, was re-ceived about 1.5 minutes after theexperiment was started.

2 Specification with the IDSinformation removed.

288/1397 328-Same as above-

3 Specification with no unin-teresting/unlikely scenariosand no IDS information.

288/945 325 Same as above except that it tookabout 3 minutes to reach thisstage.

Table 4.5: Scenario-2 Performance Report.

vertices proportional to 1.09n, i.e its size is exponential in n[55]. Also some functions cannot berepresented efficiently with OBDD regardless of the input ordering[95]. Thus, the combination ofan explosion in size of OBDD, notwithstanding re-ordering algorithms, and the expensive nestedsmoothing operations slow down model checking.

Second. Though done mechanically using a compiler, it is inefficient to model a network asboolean expressions so as to represent it as an OBDD. Sizes of network models are several magni-tudes of orders bigger than hardware models. Hardware by design is specified in boolean expressionsand it easily lends itself to be modeled as a OBDD. Each variable in a hardware specification isa boolean variable or an atomic proposition in the system. But in a network, variables that takeon a range of values, have to mapped to a boolean representation. This increases the number ofvariables used by the labeling function L, inviting a lot of inefficiency.

For example, our model of a small network had about 379 variables. Several of them are notboolean variables. Each of them needs to be mapped to a set of atomic propositions. If a variablecan take on 8 = 23 possible values, we need 3 atomic propositions to represent that one variable. Avery conservative back of the envelop calculation, estimates the number of boolean variables to bea minimum of 400 in our example. That is, the state space is about 2400 ≈ 2.58× 10120. Comparethis simple network to the complicated circuits verified by [62] involving 10120 states.

Third. Model checking is designed for verifying finite-state space systems. Hardware systemsare in finite-state space by design. A computer network is difficult to model as a finite-state spacesystem. In trying to model networks as finite-space systems, we have to make several assumptionswhich may not be valid in reality. The closer our model represents a real network, the more difficultit is to verify our network using symbolic model checking.

4.3.6 Future Work

There are several other specification languages other than CTLs to model systems. Alternativeformalisms include CTL*, Linear-time Temporal Logic(LTL) among others. For example, the modelchecker SPIN [53] uses partial order reduction technique to alleviate the state space explosion


problem and accepts required properties in LTL, CVC[4] uses first-order logic, etc,. We are notsure, if these logic and heuristics could perform better than the techniques used in SMC. We wouldlike to explore these options but it doesn’t look promising due to the reasons mentioned earlier insection 4.2.

[23] has explored expert systems approach using JESS[45] to build attack graphs. This lookspromising as it is able to scale well to large networks than those used in this section. The strengthof that approach is the Rete algorithm[42]. As with variable ordering in OBDD’s, the order ofevaluating the preconditions affect the number of facts that have to be evaluated by the expertsystem. If the most restrictive preconditions are evaluated higher in the Rete network, the numberof facts that have to be evaluated farther down the network is greatly reduced. The user knowswhat are the most restrictive conditions and this information can be used to minimize the runningtime. In contrast, the variable ordering in OBDDs are not manually tractable. Though thereare mechanised algorithms available, they are not fast enough as we found out during in theexperiments.

The current implementation cannot generate all possible combinations of attack paths, onlythose paths that give new capabilities to the attacker. In order to convert the JESS code to do all-paths graph generation, the fact base would need to be fragmented into nodes, so that capabilitiesobtained in one path do not affect the execution of rules in other paths as it does in the currentsolution. This is difficult to do natively in JESS without a huge explosion in the size of the factbase. The replication of identical facts across the fact base is a concern in any implementation ofan all-paths solution. There are concerns that the communication between JESS and Java wouldmake such an approach scale poorly.

If we can extend the current implementation to cover all paths, we would have a scalable,automated approach to generating attack graphs. This would take about 8-12 weeks.

We also explore theorem proving approaches as it is more expressive than Predicate logic.

4.4 Automated Theorem Proving

Theorem provers are by far one of the most advanced tools to work with formal methods. Auto-mated theorem Proving(ATP) deals with computer programs that show that some statement(theconjecture) is a logical consequence of a set of statements(the axioms and hypotheses). The lan-guage in which the conjecture, hypotheses and axioms (generically known as formulae are writtenin a logic, often classical first order logic, but possibly a higher order logic. These languages allowa precise formal statement of the necessary information that can be manipulated by an ATP sys-tem. This formality is the underlying strength of ATP: there is no ambiguity in the problem, as isoften the case when using a natural language such as English. Users have to describe the problemprecisely and accurately, and this process itself can lead to a clear understanding of the problem.The proofs produced by the ATP describe how and why the conjecture follows from the axiomsand hypotheses in a manner that can be understood and agreed upon by others, man and machine.

Because of the profound nature of the problems that are solved using ATPs, they usually needexpert guidance to complete tasks in a reasonable amount of time. This process of proving certainconjectures itself reveals hidden flaws in the system design or produces a useful proof [117].

ACL-2[65] and HOL[1] are some examples of higher order logic theorem provers.


4.4.1 Related work

Formal methods have been used for verification of cryptographic protocols. However, very littleresearch has been done on analyzing security of a complete system formally. Roger[98] used modelchecking to audit IDSs and system logs. Pouzol [91] refines the declarative approach to writingintrusion signatures by using a ”parsing schemata” to formally specify intrusion signatures anddetection rules. Song [108, 109] uses ACL2 to verify the security properties of sepecification- basedIDSs. [107, 109] shows how detection rules of the SHIM[71] IDS can be verified and improved.It builds an abstract behavioral model of the system, specifications of IDS rules and a high-levelspecification of security properties. It uses a hierarchical model to verify if the system abstractionand the IDS specification satisfy the security requirements.

Cavalli[18] uses temporal logic to define protocol specification and prove properties automati-cally. Some of the complex protocols that have been analyzed so far include Kereberos IV, TLSand SET. Schwartz [102] gives a methodology to write specifications for protocol standards usingtemporal logic. Cheung [25] provides a formal specification for the DNS protocol and securityinvariants were shown to be satisfied by a particular implementation.

4.5 Future Work

This section gives an approach to use theorem provers for our task.

Our Proposed Approach

Objective We want to find out whether an attacker can penetrate into our system, given thecurrent configuration and the vulnerabilities present in our system. He may achieve this usingseveral methods which we may not know but we know that he needs access to some security-criticalobject like the /etc/passwd. We can use formal methods like theorem proving to show whethersuch security-critical objects can be accessed by exploiting the existing vulnerabilities.

4.5.1 Layered Specification Approach

We model the system as a stack of layers. Each layer captures the properties of a particular facetof the network. The layers from top to bottom are, the security-requirements, the security-criticalobjects that affect the stated security requirements, the services that are being offered and theconfiguration of the system (Fig. 4.3). We develop specifications for each layer. We want to verifythe security of interaction between any 2 adjacent layers and then compose them to prove that theentire network is secure. We develop specifications for each of these layers and use theorem proverto reason about their interactions.

For example, let us consider the the classic ‘anonymous ftp home directory write’ attack.Machines offering anonymous ftp services are vulnerable to this attack. This attack is possible ifthe ftp home directory is set writable and owned by ftp. With this configuration the attacker canwrite to arbitary files on the server. In fact, the anonymous user can even write to the systempassword file. Exploiting this vulnerability an attacker can overwrite the password of root andlater login as superuser.


Interface 1

Interface 2

Interface 3

(layer 2)

(layer 1)

(layer 0)

eg. ftpd specification

eg. Current system configuration

(layer 3)

Security Requirement Spec

Security critical Objects Spec

Services Protocol Spec

Configuration Spec.

eg. No attacker gets root access

eg. /etc/passwd access policies

Figure 4.3: The Layered approach

A model system that offers anonymous ftp as in the above example would look like the Fig. 4.3and as explained below:

Layer 0: captures the configuration of the system. An example of property that will bespecified here is file permission of various files. Here, it is the ownership and filepermissions of ftp home directory.

Layer 1: will contain the specification for the behaviour of ftp daemon. For example, asnippet of ftpd specification is:

<validop> -> (OPEN RD, WorldReadable($F.Mode))

|(OPEN RD, CreatedByProc($P.pid, &$F))

|(OPEN RD, $F.ouid == $S.uid)

|(OPEN WR, CreatedByProc($P.pid, &$F))

This specifications lists the various file operations allowed for ftp user based thefile parameters.

Layer 2: will contain the specification of how security-critical objects should be accessed.In this example it is the /etc/passwd file. The /etc/passwd should be written onlyby the superuser or by a privileged program.

Layer 3: will specify our security requirement; no body from outside the network shouldget root access.


4.5.2 Interface Verification

By breaking down the system into 4 different layers as shown above, we get an opportunity toverify security at 3 different interfaces. Again for the same example attack, we can find out theweak points of the loopholes at more than one interface in this model:

At Interface 1: we get an opportunity to verify if the configuration of the system allowsanonymous ftp user to access any files other than what is intended to be accessed.This can be checked because, the ftp specification in Layer 1 explicitly states whatis accessible and what is not. While Layer 0 will give us the configuration of thesystem. We will be able to show if the current configuration would let ftpd toaccess files that it is not supposed to access.

At Interface 2: we can again verify if the ftpd is able to access any security critical object,/etc/passwd in this example. The illegal access in this example attack will become apparent during the process of proving that ftpd cannot access /etc/passwd.

At Interface 3: we can verify if any specification violation for objects in Layer 2 leads toany specification violation in Layer 3. In this example, we have already discoveredthat /etc/passwd can be accessed by the anonymous ftp user. Hence, this user canget root access. Our system is proved not to be secure.

Suppose, for example, at Interface 3, we had determined that a user can getillegal access to .rhosts files of non-priveleged users in the system. Then thesecurity requirement at Layer 3 would not be violated. Hence, our system wouldbe proved to be secure with respect to the service we are offering under the currentconfiguration.

We can express our objective as a theorem to be proved by a theorem prover. In this example,our theorem would be:

Theorem 2. No anonymous ftp user can get root access.

To prove this theorem, we need to prove that the interactions at the various Interfaces aresecure. We can state each of them as a lemma. The security at Interface 1 can be stated as:

Lemma 1. With the current configuration, ftpd cannot write to any files other than those specifiedby the ftp specification.

Similarly the security at Interface 2 and 3 can be stated as:

Lemma 2. ftpd cannot write to any security critical object.

Lemma 3. Specification violation at Layer 2 will not violate specification at Layer 3.

Once, we prove each of these lemmas, these can be stored for future use. For example, if wedecide to offer web services or upgrade to a newer version of ftpd, only layer 2 gets affected. So,we just need to prove that the interfaces 1 and 2 are secure with respect to the new or upgradedservice. Even if the interface 2 is not secure, if we can show that interface 3 is secure, the systemwould be considered secure.

The ftpd specification snippet given above can be specified to HOL as follows:


- val FTP = Define‘

FTP op filelist = !file. Open RD (file) Open WR(file)‘;

-val Open RD = Define ‘

Open RD file = @file process uid.

WorldReadable(file)

process = Creator(file)

uid = OwnerID(file) ‘;

-val Open WR = Define ‘

Open WR file = @file process.

process = Creator(file) ‘;

Chapter 5

Future Plans

5.1 Timeline

Future work described in sections 4.3.6, 4.4, 2.5, and 3.4 are tabulated in Table 5.1. The nature andapproximate estimate of the time required is given. In addition to the individual tasks identified,we need to develop a unifying model to integrate all the efforts into one model.

Task Nature Time Estimate

Unifying Model Theory 2 weeks

Formal Methods:Model Checking Theory 2 weeks

Expert systems(JESS) Implementation 2-4 weeks

Theorem Proving Theory 8-10 weeksImplementation 6-8 weeks

Intrusion Response:Proof of concept Implementation 8-10 weeks

JIGSAW Database Implementation 4-6 weeks

Costing Model Theory 4-6 weeks

Decision Engine Theory and Implementation 5-7 weeks

Widespread Intrusion Response:Experimental Validation Implementation 8-12 weeks

Automatic Signature Generation Theory and Implementation 6-8 weeks

Dissertation writing 12 weeks

Total ≈ 77weeks

Table 5.1: Future Work summary and timeline

Totally we expect about 67 - 87 weeks of work. That is about one and a years. We expect thatmost of the dissertation writing might take place in paralllel with the individual tasks as a partof the documentation process. This might lead to shorter time required for actuall dissertationwriting. This might change depending on various factors that we cannot look ahead right now.

49

CHAPTER 5. FUTURE PLANS 50

5.2 Evaluation

The final evaluation of the project will consider the following issues:

• Did the decision theory approach effectively resolve the uncertainity in IDS alerts? If notwhy?

• Were the estimates of probability of intrusions, false postive and flase negative rates realistic?

• How effective was the costing model? Did it accurately describe the importance of an event orresource to generate responses a skilled SA would have generated in the given circumstances?

• Was the method of extending JIGSAW a good choice? Would it have been easier or moreeffective to extend CAML[26] instead?

• What was the overhead to the existing defense systems in incorporating these new com-ponenets like decision engine and response engine? Was the overhead a worthy compared tothe pay-offs?

• Do the experimental results match the simulation results for worm response?

• How effective are the signature generated automatically?

• Are worm response techniques, appropriate for other distributed attacks? Theoretically, theyseems so. Are they in practice?

• Did the model/specification of the system successfully capture the required features of thesystem to be proved using theorem provers?

• What effort is required to prove that the system is secure, if there is a change? Do we haveto repeat the entire proof process?

• Overall, how easy is it to incorporate the proposed solutions in an existing environment?

• In retrospect, what contribution has this research made to the field of computer security?Did it meet the stated obectives?

Bibliography

[1] “HOL, http://www.cl.cam.ac.uk/Research/HVG/HOL/”. Internet.

[2] “http://www.iss.net”. Internet.

[3] “SMV http://www.cs.cmu.edu/ modelcheck”. Internet.

[4] “SVC, http://chicory.stanford.edu/svc/svc-1.11/html”. Internet.

[5] A.Cimatti, E.Clarke, F.Giunchiglia, and M.Roveri. “NuSMV. A New Symbolic ModelChecker. http://sra.itc.it/tools/nusmv”. Internet.

[6] A.Heydon and J.D.Tygar. “Specifying and Checking Unix Security Constraints”. In Proceed-ings of the 3rd USENIX Security Symposium, September 1992.

[7] Paul Ammann, Duminda Wijesekara, and Saket Kaushik. “Scalable, Graph-Based NetworkVulnerability Analysis”. In Proceedings CCS02: 9th ACM Conference on Computer andCommunication Security, pages 217 – 224, Washington, DC, November 2002. ACM.

[8] D. Anderson, T. Frivold, and A. Valdes. Next-generation intrusion detection expert sys-tem(nides): A summary. Technical Report: SRI-CSL-95-07.

[9] James P Anderson. Computer security threat monitoring and surveillance. Technical Report,April 1980.

[10] D Armstrong, S Carter, G Frazier, and T Frazier. Autonomic defense: Thwarting automatedattacks through real-time feedback control. In Proceedings of the DISCEX III, Washington,DC, April 2003.

[11] Tuomas Aura, Matt Bishop, and Dean Sniegowski. “Analyzing Single-Server Network Inhibi-tion”. In Proceedings of the 13th Computer Security Foundations Workshop, pages 108–117,July 2000.

[12] Robert W. Baldwin. “Kuang: Rule based security checking.”. Documentation inftp://ftp.cert.org/pub/tools/cops/1.04/cops.104.tar. MIT, Lab for Computer Science Pro-gramming Systems Research Group.

[13] Ivan Balepin. Active cyberdefense via Behaviour modelling and Automated response - A PhDThesis Proposal. PhD thesis, University of California, Davis, July 2004.

51

BIBLIOGRAPHY 52

[14] Ivan Balepin, Sergei Maltsec, Jeff Rowe, and Karl Levitt. Using specification-based intrusiondetection for automated response. In Proceedings of the 2003 RAID, Pittsburg, 2003.

[15] J. Cannaday. Artificial neural networks for misuse detection. In Proceedings of the 1998National Information Systems Security Conference, pages 443–458, Arlington, Va, October1998.

[16] Curtis A Carver, John M.D.Hill, and Udo W. Pooch. Limiting uncertainty in intrusionresponse. In Proceedings of the 2001 IEEE Workshop on Information Assurance and Security,pages 142–147, US Military Academy, West Point, NY, jun 2001. IEEE.

[17] Curtis A Carver and Udo W. Pooch. An intrusion response taxonomy and its role in automaticintrusion response. In Proceedings of the 2000 IEEE Workshop on Information Assuranceand Security, pages 129–135, US Military Academy, West Point, NY, jun 2000. IEEE.

[18] Ana R. Cavalli. A method of automatic proof for the specification and verification of protocols.In Proceedings of the ACM SIGCOMM Symposium on Communiations architectures andprotocols: tutorial and symposium., 1984.

[19] Cert. http://www.cert.org. Internet.

[20] Cert. “Cert Advisory CA-2001-19 ”Code Red” Worm Exploiting Buffer Overflow In Iis

Indexing Service DLL”. Internet, January 2002. http://www.cert.org/advisories/CA-2001-19.html.

[21] C.G.Senthilkumar. “Worms: How to stop them? - A proposal for Master’s thesis.”. Universityof California, Davis. http://wwwcsif.cs.ucdavis.edu/cheetanc, July 2002.

[22] Senthilkumar G Cheetancheri. “Modelling worm defense systems”. Master’s thesis, Universityof California, Davis. http://seclab.cs.ucdavis.edu/, June 2004.

[23] Senthilkumar G Cheetancheri and Melissa Danforth. Model checking and expert systemapproaches to attack graphs. Submitted to NDSS’05, August 2004.

[24] Senthilkumar G Cheetancheri, Daisuke Noijiri, Jeff Rowe, Akshay Aggarwal, and Karl Levitt.Worms: How to stop them? In Proceedings of the UC Davis CS Student Computing Workshop,September 2002.

[25] Steven Cheung and Karl N Levitt. A formal specification based approach for protecting thedomain name system. In Proceedings of the International Conferece on Dependable Systemsand Networks, pages 641–651, New York City, New York, June 2000.

[26] Steven Cheung, Ulf Lindqvist, and Martin W. Fong. Modeling multistep cyber attacks forscenario recognition. In Proceedings of the DISCEX III, volume I, pages 284–292, Washington,DC, April 2003. SRI.

[27] C.Kahn et al. A common intrusion detection framework. Sumitted to the Journal of ComputerSecurity, 1998.

[28] Edmund M. Clarke and Jeannette M. Wing. “Formal Methods: State of the Art and FutureDirections”. In ACM Computing Surveys, September 1996.

BIBLIOGRAPHY 53

[29] Fred Cohen. Simulating cyber attacks, defenses and consequences.http://all.net/journal/ntb/simulate/simulate.html. May 13, 1999.

[30] D.E.Denning. “An Intrusion Detection Model”. In IEEE Transactions on Software Engineer-ing, February 1987.

[31] D.Endler. Intrusion detection: Applying machine learning to solaris audit data. In Proceedingsof the 1998 Annual Computer Security Applications conference, pages 268–279, Los Alamitos,December 1998.

[32] D.Noijiri, J.Rowe, and K.Levitt. “Cooperative Response Strategies for Large Sacle AttackMitigation”. In Proceedings of DISCEX’02. DISCEX, 2002.

[33] ECS122. Class handout - introduction to suffix trees, Spring 2002. Prof Charles Martel.

[34] Jr. Edmund M. Clarke, Orna Grumberg, and Doron A. Pleld. “Model Checking”. The MITPress, 1999.

[35] E.F.Fisch. Intrusion Damage Control and Assessment: A taxonomy and Implementation ofAutomated Responses to Intrusive Behavior. PhD thesis, Department of Computer Science,Texas A&M University, College Station, TX, 1996.

[36] Mark W. Eichin and Jon A. Rochlis. “With Microscope and Tweezers: An analysis of theInternet Virus of November 1988”. In Proceedings of the symposium on Research in Securityand Privacy, May 1988. Oakland, CA.

[37] Emulab. http://www.emulab.net. Internet.

[38] E.Ukkonen. On-line construction of suffix trees. In Algorithmica, volume 14, pages 249–260,1995.

[39] Dan Farmer and Eugene H. Spafford. “The cops Security Checker System”. In Proceedings ofthe 14th Systems Administration Conference, USENIX Association. USENIX, 1990. Summer.

[40] Richard Feiertag et al. Intrusion detection inter-component adaptive negotiation. In Proceed-ings of RAID 99, 1999.

[41] Richard J. Feiertag and Peter G. Neumann. The foundations of a provably secure operatingsystem (psos). In Proceedings of the National Computer Conference, pages 329–334. AFIPSPress, 1979.

[42] Charles L Forgy. “Rete: A Fast Algorithm for the Many Pattern / Many Object PatternMatch Problem”. Artificial Intelligence, 19:17–37, 1982.

[43] Stephanie Forrest, Steven A. Hofmeyr, and Anil Somayaji. Computer immunology. In Com-munications of the ACM, volume 40 of 10, pages 88–96, October 1991.

[44] Stephanie Forrest, Steven A. Hofmeyr, Anil Somayaji, and Thomas A Longstaff. A senseof self for unix processes. In Proceedings of the IEEE Symposium on Security and Privacy,pages 120 – 128, Los Alamitos, CA, 1996. IEEE CS Press.

BIBLIOGRAPHY 54

[45] Ernest Friedman-Hill. “JESS in Action”. Manning Publications Company, 2003.

[46] Vigna G and Kemmerer R. “NetSTAT: A network-based intrusion detection approach”.In Proceedings of the 14th annual Computer Security Applications Conference, Scottsdale,Arizona, December 1998.

[47] T.D Garvey and Teresa F Lunt. Model-based intrusion detection. In Proceedings of the 14thNational Computer Security Conference, October 1991.

[48] G.B.White, E.A. Fisch, and U.W.Pooch. Co-operating security managers. In IEEENetwork,volume 10 of 1, pages 20–23, January/February 1996.

[49] Anup K Ghosh and Aaron Schwartzbard. A study in using neural networks for anomaly andmisuse detection. In Proceedings of USENIX Security Symposium, 1999.

[50] Anup K Ghosh, J Wanken, and F Charron. Detecting anomalous and unknown intrusionsagainst programs. In Proceedings of the ACSAC’98, December 1998.

[51] Anthony Hall. Seven myths of formal methods. In Software. IEEE, September 1990.

[52] Todd Heberlein. Automatic signature generation: Report on the initial implementaion. Net-Squared, Inc., TR-2004-01-20.01.

[53] Gerard J Holzmann. “The Model Checker SPIN”. In IEEE Transactions on Software Engi-neering, volume 23. IEEE, May 1997. No.5.

[54] H.S.Teng, K.Chen, and S.C.Lu. Security audit trail analysis using inductively generatedpredictive rules. In Proceedings of the Sixth Conference on Artificial Intelligence Applications,pages 24–29, Piscataway, New Jersey, March 1990. IEEE.

[55] Michael RA Huth and Mark D Ryan. “Logic in Computer Science: Modelling and resaoningabout systems.”. The Press Syndicate of The University of Cambridge, 2000.

[56] IETF. Intrusion detection message exchange format. Internet. http://www.ietf.org/.

[57] Koral Ilgun. Ustat: A real-time intrusion detection system for unix. Master’s thesis, Dept ofCS, UCSB, July 1992.

[58] Koral Ilgun, Richard Kemmerer, and Phillp A Porras. State transition analysis: A rule-basedintrusion detection approach. In IEEE Transactions on Software Engineering, volume X,1995.

[59] ISO/TC97/SC21. Information processing systems - open systems interconnection - estelle- a formal description technique based on an extended state transition model. IS 9074,International Organization for Standardization, Geneva, 1997.

[60] Somesh Jha, Oleg Sheyner, and Jeannette Wing. “Two Formal Analyses of Attack Graphs”.In IEEE Computer Security Foundations Workshop, pages 49–63, Cape Brenton, Nova Scotia,Canada, June 2002.

BIBLIOGRAPHY 55

[61] John E. Gaffney Jr; and Jacob W. Ulvila. Evaluation of intrusion detectors: A decisiontheory approach. In In Proceedings of the 2001 IEEE Symposium on Security and Privacy,pages 50–61. IEEE, 2001.

[62] J.R.Burch, E.M.Clarke, K.L.McMillan, D.L.Dill, and L.J.Hwang. “Symbolic Model Checking:1020 States and Beyond”. In Proceedings of the ACM/SIGDA International Workshop onFormal Methods in VLSI Design., January 1991.

[63] Steven J.Templeton and Karl Levitt. “A Require/Provides Model for Computer Attacks”.In Proceedings New Security Paradigms Workshop, Cork Island, September 2000.

[64] J.Thees and R.Gotzhein. Protocol implementation with estelle - from prototypes to efficientimplementations. In Proceedings of Estelle ’98, Evry, France, 1998.

[65] Matt Kaufmann, Panagiotis Manolios, and J Strother Moore. Computer-Aided Reasoning:An Approach. Kluwer Academic Publishers, June 2000.

[66] Richard A. Kemmerer and Giovanni Vigna. Intrusion detection: A brief history and overview.In Security and Privacy, Supplementary to COMPUTER, 2002. Invited Article.

[67] Gene Kim and Eugene H. Spafford. “The design of a system integrity monitor:Tripwire”.Technical Report CSD-TR-93-071, Purdue University, West Lafayette, IN, USA, November1993.

[68] K.L.Fox, RR¿Henning, J.H. Reed, and R.Simonian. A neural network approach towardsintrusion detection. In Proceedings of the 13th National Computer Security Conference, pages125–134, Washington, D.C., October 1990.

[69] Calvin Ko. “Execution Monitoring of Security-critical Programs in Distributed Systems: ASpecification-based approach”. PhD thesis, University of California, Davis., August 1996.

[70] Calvin Ko, George Fink, and Karl Levitt. “Execution Monitoring of Security-critical Pro-grams in Distributed Systems: A Specification-based approach”. In Proceedings of the IEEESymposium on Security and Privacy, pages 134–144. IEEE, 1997.

[71] Calvin Ko, Jeff ROwe, P. Brutch, and Karl Levitt. System health and intrusion monitoringusing a hierarchy of constraints. In Proceedings of the 4th RAID, 2001.

[72] Sandeep Kumar and Eugene Spafford. A pattern matching model for misuse intrusion detec-tion. In Proceedings of the 17th National Computer Security Conference, pages 11 – 21, 1994.The COAST project.

[73] Wenke Lee, Wei Fan, Matthew Miller, Salvatore J. Stolfo, and Erez Zadok. Towards cost-sensitive modeling for intrusion detection and response. In Journal of Computer Security,volume 10, 2002. Numbers 1,2.

[74] Wenke Lee, Salvatore J. Stolfo, and Kui W. Mok. A data mining framework for buildingintrusion detection models. In Proceedings of the IEEE Symposium on Security and Privacy,1999.

BIBLIOGRAPHY 56

[75] Jia-Ling Lin, X. Sean Wang, and Sushil Jajodia. Abstraction-based misuse detection: High-level specifications and adaptable strategies. In Proceedings of the IEEE Computer SecurityFoundations Workshop. CSIS, GMU, 2002.

[76] Ulf Lindqvist and Phillip A Porras. Detecting computer and network misuse with theproduction-based expert system toolset. In IEEE Symposium on Security and Privacy, pages149 – 161, Los Alamitos, 1999. IEEE CS Press.

[77] Teresa Lunt et al. A real-time intrusion detection expert system (ides)-final technical report.February 1992.

[78] Teresa F. Lunt and R.Jagannathan. A prototype real-time intrusion-detection system. InProceedings of the 1988 IEEE Symposium on Security and Privacy, April 1988.

[79] Norman S Matloff. Probability Modeling and Computer Simulation. PWS, 1988.

[80] David Moore et al. “Inside the Slammer Worm”. In IEEE Security and Privacy, August2003.

[81] M.Roesch. Snort: Lightweight intrusion detection for networks. In Proceedings of the USENIXLISA ’99, pages 229–238, Seattle, Wahington, November 1999. http://www.snort.org.

[82] Peter G. Neumann and Phillip A. Porras. Experience with EMERALD to date. In FirstUSENIX Workshop on Intrusion Detection and Network Monitoring, pages 73–80, SantaClara, California, apr 1999.

[83] Peter G. Neumann, R.S.Boyer, Richard J. Feiertag, Karl N Levitt, and Larry Robinson. Aprovably secure operating system; the system, its applications, and proofs. February 1977.

[84] Members of DETER and EMIST Projects. Cyber defense technology networking and evalu-ation. In Communications of the ACM, volume 7 of 3, pages 58–61, march 2004.

[85] Vern Paxson. Bro: A system for detecting network intruders in real time. In Proceedings ofthe seventh USENIX Security Symposium, Berkeley, 1998. USENIX Association.

[86] P.D’haeseleer, Stephanie Forrest, and P. Helman. An immunological approach to changedetection: Algorithms, analysis and implications. In Proceedings of the IEEE Symposium onSecurity and Privacy, 1996.

[87] C. Phillips and L. Swiler. “A Graph-Based System for Network-Vulnerability Analysis”. InProceedings of the New Security Paradigms Workshop, Charlottesville, VA, 1998.

[88] Phillip Porras, Linda Briesemeister, Karl Levitt, Jeff Rowe, Keith Skinner, and Allen Ting.A hybrid quarantine defense. In To appear in Proceedings of the WORM’05 Workshop, 2004.

[89] Phillip A Porras and Richard A Kemmerer. Penetration state transition analyysis - a rule-based intrusion detection approach. In Proceedings of ACSAC’92, pages 220–229. IEEE CSPress, November 1992.

BIBLIOGRAPHY 57

[90] Phillip A. Porras and Peter G. Neumann. EMERALD: event monitoring enabling responsesto anomalous live disturbances. In 1997 National Information Systems Security Conference,oct 1997.

[91] Jean-Philippe Pouzol and Mireille Ducasse. Formal specification of intrusion signatures anddetection rules. In Proceedings of the IEEE Computer Security Foundations Workshop, 2002.

[92] P.Uppuluri and R Sekar. Experiences with specification-based intrusion detection. In Pro-ceedings of RAID, 2001.

[93] Howard Raiffa. Decision Analysis Introductory Lectures on Choices under Uncertainity.Addison-Wesley Publishing Company, 1968.

[94] C.R. Ramakrishnan and R. Sekar. “Model-Based Analysis of Configuration Vulnerabilities”.In Proceedings of 7th ACM Conference on Computer and Communication Security, November2000.

[95] Randal.E.Bryant. Graph-based algorithms for boolean function manipulation. IEEE Trans-actions on Computers, C-35(8):677–691, August 1986.

[96] Ronald W. Ritchey and Paul Ammann. “Using Model Checking to Analyze Network Vulner-abilities”. In Proceedings, 2000 IEEE Symposium on Security and Privacy, pages 156 – 165,Oakland, CA, May 2000.

[97] R.Lippmann et al. The 1999 darpa off-line evaluation intrusin detection evaluation. InComputer Networks, volume 34, 2000.

[98] Muriel Roger and Jean Goubault-Larrecq. Log auditing through model-checking. In Proceed-ings of the 14th IEEE Computer Security Foundations Workshop, pages 220–234, 2001.

[99] R.Sekar, Yong Cai, and Mark Segal. A specification-based approach for building surviv-able systems. In Proceedings of the 21st NIST-NCSC Nation Information Systems SecurityConference, 1998.

[100] D. Schnackenberg and K. Djahandari. Infrastructure for intrusion detection and response. InProceedings of DISCEX00, Hilton Head, SC, 2000.

[101] Matthew G. Schultz, Eleazar Eskin, and Erez Zadok. Data mining methods for detection ofnew malicious executables. In Proceedings of the IEEE Symposium on Security and Privacy,2001.

[102] Richard L. Schwartz and P.M.Melliar-Smith. From state machines to temporal logic : Spec-ification methods for protocol standards. In PSTV, pages 3 – 19, 1982.

[103] Don Seeley. “A Tour of the Worm”. In Proceedings of 1989 Winter USENIX Conference,pages 287–304, Berkeley, CA, February 1989. Usenix Association, USENIX.

[104] Oleg Sheyner, Joshua Haines, Somesh Jha, Richard Lippmann, and Jeanette Wing. “Au-tomated Generation and Analysis of Attack Graphs”. In Proceedings IEEE Symposium onSecurity and Privacy, pages 254 – 265, May 2002.

BIBLIOGRAPHY 58

[105] John F. Shoch and Jon A. Hupp. “The “Worm” Programs - Early Experience with a Dis-tributed Computation”. Communications of the ACM, 25(3):172–180, March 1982.

[106] S.Lewandowski, D.V. Hook, G.O’Leary, J. Haines, and L. Rosse. Sara: Survivable autonomicresponse architecture. In Proceedings of DISCEXII, Anaheim, CA, June 2001.

[107] Tao Song. Formal Reasonging of Intrusion Detection. PhD thesis, University of California,Davis. Work in Progress.

[108] Tao Song et al. Using acl2 to verify security properties of specification-based intrusion de-tection systems. In Proceedings of the 4th International Workshop on the ACL2 TheoremProver and Its Applications, 2003.

[109] Tao Song, Calvin Ko, Jim Alves-Foss, Cui Zhang, and Karl Levitt. Formal reasoning aboutintrusion detection systems. In Proceedings of RAID 2004, September 2004.

[110] Eugene H. Spafford. “The Internet Worm Program: An Analysis”. Technical Report CSD-TR-823, Purdue University, West Lafayette, IN, USA, December 1988.

[111] Eugene H. Spafford. “The Internet Worm: Crisis and aftermath”. Communications of theACM, 32(6):678–687, June 1989.

[112] Eugene H. Spafford. “The Internet Worm Incident”. Technical Report CSD-TR-933, PurdueUniversity, West Lafayette, IN, USA, September 1991.

[113] SRI. Pvs specification and verification system. Internet. http://pvs.csl.sri.com/.

[114] Stuart Staniford, Gary Grim, and Roelof Jonkman. “Flash Worms: Thirty Seconds to Infectthe Internet”. Silion Defense - Security Information, August 2001.

[115] Stuart Staniford, Vern Paxson, and Nicholas Weaver. “How to Own the Internet in YourSpare Time”. In Proceedings of 2002 Summer USENIX Conference, Berkeley, CA, August2002. Usenix Association, USENIX.

[116] D Sterne, K. Djahandari, B. Wilson, B. Babson, and D. Schnackenberg. Autonomic responseto distributed denial of service attacks. In Proceedings of the RAID, Davis, CA, January2001.

[117] Geoff Sutcliffe. Automated theorem proving. Internet.http://www.cs.miami.edu/tptp/overviewofATP.html.

[118] L. Swiler, C. Phillips, D. Ellis, and S. Chakerian. “Computer-Attack Graph Generation Tool”.In Proceedings of DARPA Information Survivability Conference and Exposition II, June 2001.

[119] Teresa.F.Lunt. “A Survey of Intrusion Detection Techniques”. In Computers and Security,volume 12, pages 405 – 418, 1993.

[120] T.Lane and C.E.Brodley. An application of machine learning to anomaly detection. In Pro-ceedings of 20th National Information Systems Security Conference, pages 366–377, October1997.

BIBLIOGRAPHY 59

[121] Thomas Toth and Christopher Kruegel. Evaluating the impact of automated intrusion re-sponse mechanisms. In Proceedings of the 18th Annual Computer Security Applications Con-ference, Las Vegas, Nevada, December 9-13 2002.

[122] Marcus Tylutki and Karl Levitt. Optimal response through policy and state-based modeling.UC Davis.

[123] David Wagner and Drew Dean. Intrusion detection via static analysis. In Proceedings of theIEEE Symposium on Security and Privacy, 2001.

[124] Nicholas Weaver. “Potential Strategies for High Speed Active Worms: A Worst Case Analy-sis”. UC Berkeley, March 2002.

[125] Nicholas Weaver. “Warhol Worms: The Potential for Very Fast Internet Plagues”. UCBerkeley, February 2002.

[126] Jeannette Wing. A specifier’s introduction to formal methods. In Computer. IEEE, September1990.

[127] Jeannette Wing. “A Symbiotic Relationship between Formal Methods and Security”. InWorkshops on Computer Security, Fault Tolerance and Software Assurance: From Needs toSolution, December 1998.

[128] W.Lee, S.Stolfo, and P.K.Chan. Learning patterns from unix process execution traces frointrusion detection. In Proceedings of AAAI97 Workshop on AI Methods in Fraud and RiskManagement, 1997.

[129] W.W.Cohen. Fast effective rule induction. In Machine Learning: Proceedings of the 12thInternational Conference, 1995.

[130] Dan Zerkle and Karl Levitt. “NetKuang - A Multi-Host Configuration Vulnerability Checker”.USENIX, 1996.

[131] Jimmy Zhou. Modeling Intrusion Detection Alerts for Correlation. PhD thesis, University ofCalifornia, Davis., 2004. Work in Progress.

Automated Reasoning in Co-operative Cyber Defense-A PhD thesis ...

Documents

Transcript of Automated Reasoning in Co-operative Cyber Defense-A PhD thesis ...