# Presentation: 191805

## Fusing Intrusion Data for Pro-Active Detection and Containment

- Mallikarjun (Arjun) Shankar, Ph.D.
- (Joint work with Nageswara Rao and Stephen Batsell)
- _[shankarm@ornl.gov](mailto:shankarm@ornl.gov)_
- Oak Ridge National Laboratory

## Motivating Overview

- Problem: changing cyber-security landscape
- Distributed attacks
- Self-propagating worms cause denial-of-service and serious infrastructure damage
- Intrusions characteristics:
- Trigger and impact many parts of the system
- Spread rapidly
- Solution focus:
- Detect using multiple sensors
- Fuse intrusion sensors effectively to reduce false alarms
- Meet response time constraints for rapid containment

**Notes:**
Cyber warfare and cyber terrorism are serious emerging problems. Various forms of stealthy attacks exist.
Worms caused several millions of dollars of damage last year
We don’t want to reinvent the wheel so we would like to build upon previous sensors
Spread rapidly so need autonomous reaction

False alarms are the biggest problem. Fusion has been used in other fields (like radar) to reduce false alarms so may be we can use it too.

## Background

- Most existing intrusion sensors
- Host based
- Protection boundary violation
- User activity
- System call anomalies
- Network based
- Packet signatures
- Anomalous activity
- Detection methodologies
- Data mining and pattern searching
- Probabilistic techniques
- Learning, anomaly detection

*Typically, single point of analysis in system*

**Notes:**
Pattern Matching and Learning were used to remember a set of signatures of
the intrusion so that future intrusions could be caught. Led to Anomaly Detection which is more recent, looks
for unusual activities.
Hitherto, single point of analysis approach because it was not clear how to
combine different sets of information. Also work remained to be done in each
of the individual sensors themselves.

## Fusion Possibility: Example

*Telnet* Intrusion

*ps* Attack

- [**] [1:716:5] TELNET access [**] [Classification: Not Suspicious Traffic] [Priority: 3] 03/08-19:09:06.852083 172.16.112.50:23 -> ***197.182.91.233:1664*** TCP TTL:255 TOS:0x0 ID:39157 IpLen:20 DgmLen:55 DF ***AP*** Seq: 0x3BCB82CB  Ack: 0x38633CDD  Win: 0x2238  TcpLen: 20
- [Xref => cve CAN-1999-0619]
- [Xref => arachnids 08]

- header,805,2,execve(2),,
- Mon Mar 08 19:09:54 1999, + 971937365 msec, path,/usr/bin/ps,attribute,104555,root,sys,
- 8388614,22927,0,exec_args,4,ps,-z,-u, [.. data
- snipped ..] ,subject,2066, root,100,2066,
- 100,2804,2795,24 2 ***197.182.91.233***, return,success,0,trailer,805

- Break-in Progress

**Network Sensor: Snort**

**Host**
**Sensor:**
**BSM**

- Example from DARPA Intrusion Detection Test - Lincoln Labs 1999:

## Fusing Multiple Sensors

*Problem: How do you combine information from multiple sensors of intrusion?*
- Use data fusion!
- Di: any type of sensor (legacy, signature, anomaly, etc.)
- Ui: attack detection signal

- Net: **D****1**

- CPU: **D****2**

- u1

**FUSER**

**D****n**

- u0 – Overall Determination

- un

- u2

- ....

**Notes:**
Related issues are  when to fuse, how much data to fuse. These are related, we are exploring them in ongoing work. As far as we know, this is one of the first applications of the simple idea of data fusion to this field.

We apply  results from the field of data-fusion developed. Some of these
Discoveries are recent. The first relevant results in data fusion came up about 15 years ago.

## Simple Likelihood Ratio Derivation

- Cost:

## Single node tracking: data fusion (likelihood ratio)

- Data Fusion

- >
- <

- η: Learned Constant

-  P(u1, u2, ..., uN| attack)

-  P(u1, u2, ..., uN| no attack)

**Notes:**
We evaluate the likelihood ratio. Using Bayesian probability, you can show that this ratio optimizes the decision criterion at U0.
When the likelihood ration is greater than the constant, the fuser rules it as an attack.
Nagi’s work shows how to learn these even when you don’t have the a priori probability distributions.
Adjust the learned constant to minimize false alarms. Results from fusion theory show that the false alarms can be minimized while improving the detection rate.

Information fusion involves using AI rules and patterns to detect new information. Here, if more than N parameters match at two hosts A and B (after the fuser on each of the hosts reported an intrusion), you declare a spreading intrusion. N is a tunable parameter. Each LAN needs a “Info-Fusion Center”.
Nagi’s source propagation work shows how to determine the potential entry point of the attack when you know that there is a distributed intrusion taking place.

## Fusion: Example Computation Data

- Three Sensors
- P(FalseAlarm1)= 0.1, P(Miss1) = 0.01
- P(FalseAlarm2)= 0.2, P(Miss2) = 0.01
- P(FalseAlarm3)= 0.25, P(Miss3) = 0.01
- Overall
- P(FalseAlarm) = 6x10^-3
- P(Miss) = 2x10^-6
*Simplifying Assumption: Sensors are Independent.*

## Requirements for Containment of Autonomous Intrusions: Worms

- Exploit vulnerability for entry
- Gains system control
- Attacks other vulnerable machines
- May stay dormant and wake up for delayed attack
- Propagate at network bandwidth (e.g, using UDP in slammer)
- Random as well as deterministic destinations
- Target popular hosts for worst impact

*Some Examples: Code Red (8/2002), Slammer (1/2003), Blaster (8/2003), Bagle(1/2004)*

**Notes:**
Unlike viruses that have humans in the loop. Worms are self-propagating. 
They can attack over a wide-area. Once compromised, the direction of attack is outgoing at the firewall, and hence, the attack packets are often not stopped.

Slammer exploited an MSSql server propagated in a 384 byte packet
Sent by UDP exploited nearly all of the network bandwidth trying to
Randomly attack other machines. (Random actually made it less harmful. If
It had targeted popular and known machines with the vulnerability,
It could have spread much faster..)

Blaster exploit a Windows NT and 2000 Server system vulnerability. Is said to be lurking dormant now, and likely to recur at future dates.

## Evaluation of Spreading Behavior

- Reaches 1 (all machines infected) if not patched or restrained
- Spreading depends on “infection rate”
- Mode of transport (TCP, UDP)
- Targeted spreading
- Rate of restraint and patching
- Past examples
- Code red – doubled every 37 minutes, infected 375,000 hosts
- Slammer – doubled every 8 seconds, infected 90% of vulnerable hosts in internet in 10 minutes

*Rate of Increase of Infectives[dI/dt] **α** **Infectives[I(t)] ***** ****Susceptibles[1-I(t)]*
*	**dI/dt = **β I(t)(1-I(t))             I(t) = e**β(t-T)**/(1 + e**β(t-T)**)*

**Notes:**
To be able to create a containment architecture we must determine the parameters of the spreading infection. 
We show how we determine
Rate of infection for different reaction times

Models from medicine (immunology) have been recently used to model spreading of infections.
We have adapted work by David Moore et al. for our purposes. The basic model is shown here.

## Restraining Infections

- Assume you can contain an infected machine in *θ** *seconds
- Assuming aggressive worms  (2*Slammer, high infection rate)

*Rate of Increase of Infectives[dI/dt] **α*
-  *Infectives Remaining[I(t) – I(t - **θ**)] * Susceptibles[1-I(t)]*

## Spreading Under Restraint

- Code Red β = 0.03

- Slammer β = 0.11

- β = 0.2

## Pro-active Restraint Requirements

- Local response needed < 5-7 s
- Proactive alerting
- Global patching
- Response needed < 50 s

- With Restraint

**Notes:**
We modify the model to evaluate what sort of reaction times we will need for high infection rates (about double slammer taking into account future worms and future bandwidth)
If only local responses are allowed, then the restraint has to be carried out in about 5-7 seconds. Note that these are model based calculations and are therefore necessarily approximate.
If a global system can respond using proactive alerting and patching, in 50 seconds you may be able to contain the infection to under 20%.

Thus this overall performance characteristic and behavior motivates (next slide shows) the methodology for the architecture of a system we are designing and building.

## Multi-resolution Response Levels to Detect and Contain Worms

- Node detection: data fusion at a single node
- LAN detection and containment: information fusion
- WAN containment: proactive notification and patching

**Notes:**
This slide shows the methodology for the architecture of a system we are designing and building.
At a single node, use data fusion to detect an intrusion
Using information fusion, we identify the source and the propagation
Proactively notify WAN peers who will apply content filters

## Conclusion

- Data-fusion: technique applicable to combine diverse sensors
- Containing intrusions: fused data and intrusion determinants need to be distributed proactively
- Local response times in the order of seconds needed
- Wide-area notifications in the order of tens of seconds are effective

*-Thank You-*

**Notes:**
Data-Fusion: 
   -Sensor Extensions and Learning – We need to extend current sensors to be
          more effective to work in the fusion context. 
          (What we have now are available sensors to prototype the principle.)
          The sensors also need to learn distributions, as we claim is possible.
-Plug-in Prototype Development 
       To create wider test beds, we will develop this as a plug-in implementation         model. So that  it will generate commercial and r&d interest to actually extend our model.
Rapid Information Fusion Architecture
-Optimized and Selective Fusing – critical because the response times (as shown before ) are stringent. Too inefficient to spend time fusing too much information.
-Scaled Peer-to-Peer Notification – designed to reduce the notification time. System wide architectures must be rapid, as well as apply to end-nodes. Designing to address this trade-off is an important objective.

Responses will have to be implemented by developing a flexible and portable framework (identify the common core of the operations) because – (i) routers etc. are company dependent (ii) topologies are highly variable and constraints of privacy mandate obstacles (firewalls, protection boundaries, etc.) to implementation.