Using Capability Attack Model for Correlating Intrusion Detection Alerts

1
Using Capability Attack Model for Correlating
Intrusion Detection Alerts

• Jimmy (Jingmin) Zhou
• Computer Security Laboratory
• CS Dept., UC Davis

2
Outline

• Terminology
• Motivation
• Capability Attack Model
• IDS Alert Correlation Using Capabilities
• Experimental Results
• Related Work
• Future Work
• Acknowledgement

3
Terminology

• Attack
• An attack is a malicious or a suspicious event
  observed by an intrusion detection system (IDS).
• Alert
• An alert is a message sent by an IDS when it
  observes an attack.
• Intrusion Incident
• An incident is a sequence of related attacks
  within a time frame against a single machine by
  an attacker. For example, an attacker launches an
  IP sweep, a port scan and a buffer overflow
  exploitation against a system on some day.

4
Terminology (cont.)

• Alert fusion
• Cluster alerts that share the same
  characteristics. Typically the alerts have the
  same class and network addresses Debar
• Alert correlation
• Cluster alerts that are involved in the same
  intrusion incident through their logical
  connections. Typically the alerts have different
  classes and possibly different network addresses

5
Motivation

• Simple low level attacks vs real-world intrusions
• IP sweep, port scanning, buffer overflow
  exploitation, etc.
• No evaluation of alerts
• A huge number of alerts vs a small number of
  serious intrusion incidents
• 63,963 Snort alerts vs 10 serious intrusions (
  7 months on NT 4.0 honeypot)

6
Motivation (Cont.)

• Logical connections among alerts in an intrusion
  incident?
• Requires/Provides Model (JIGSAW, Templeton and
  Levitt, 2000)
• A systematic model to precisely define the
  logical relationship?
• Capability Model

7
Requires/Provides Model

• Steven J. Templeton Karl Levitt, 2000
• An attack as a set of capabilities
• One attack provides capabilities that support the
  next attack, which in turn may provide new
  capabilities to support following attacks
• No implementation, no model of capability

8
Capability State Transition

• Each state is a unique set of capabilities
  obtained by the attacker
• Each edge is one or more attack performed by the
  attacker

9
Capability State Transition

• IP Sweep
• know the running status of victims TCP/IP stack
• Port scanning
• know the running status of victims TCP/IP stack
• know the running status of victims network
  process
• Buffer overflow
• know the running status of victims TCP/IP stack
• know the running status of victims network
  process
• execute the shell program as particular account

10
Model Capability

• Systematic (universal)
• Capable to model a variety of objects in
  intrusion detection
• Consistent
• Same format for all objects, easy to formalize
• Precise
• No ambiguity
• Simple
• Easy to understand

11
A Capability

• A capability is a 6-tuple, meaning from the
  attack source, perform the action on the property
  of the service with the given credential on the
  attack destination

12
Cap. - An Example

• (mariner, spurr, read, smith, /etc/passwd,
  content)
• Attack source host mariner
• Attack destination host spurr
• Action read
• Credential account smith
• Service file /etc/passwd
• Property of the Service content
• The attacker is from host mariner, she can read
  the content of file /etc/passwd on host spurr as
  account smith

13
Capability Inference

• One cap. can be logically inferred from another
  cap.
• C1 (src, dst, read, /etc/passwd, content,
  smith)
• C2 (src, dst, read, All files, content, smith)
• C1 can be logically inferred from C2
• C3 (src, dst, know, All accounts, name, smith)
• C4 (src, dst, read, /etc/passwd, content,
  smith)
• C3 can be logically inferred from C4

14
Comparable Inference

• Two capabilities are comparable if they have
• Same value of source, destination, action
• Same type of service, property
• Example
• C1 (mariner, spurr, read, /etc/passwd, content,
  smith)
• C2 (mariner, spurr, read, All files, content,
  smith)
• C1 can be inferred from C2 if they are
  comparable, and C1s service, property and
  credential is a subset of C2s service, property
  and credential respectively

15
IDS Alert Correlation

• Model Alerts with Capability
• Alert Correlation Algorithms
• Implementation

16
Hyper-Alert (h-alert)

• A h-alert is an abstract form of an alert
• requires
• The required capabilities for the attack to
  succeed
• provides
• The capabilities obtained from the successful
  attack
• failure
• The capabilities obtained from the failed attack
• raw
• Data of Raw IDS alert, e.g, timestamp, signature
  , source ip, destination ip, source port,
  destination port, protocol, direction, etc.

17
Hyper-Alert (cont.)

• The provides includes the requires
• A failed attack can provide certain capabilities
• The result of an attack is often assumed to be
  successful
• It is still possible to determine an attack
  fails, e.g., a 403 forbidden alert after a web
  CGI attack alert

18
Sample H-alerts

• IP sweep
• Requires none
• Provides (src, dst, know, IP, running, none)
• Port scanning (port 21)
• Requires (src, dst, know, IP, running, none)
• Provides (src, dst, know, ftpd, running, none)
• Ftpd buffer overflow
• Requires (src, dst, know, IP, running, none),
  (src, dst, know, ftpd, running, none)
• Provides (src, dst, exec, ALL programs, code,
  root)

19
Meta-attack (m-attack)

• A m-attack is an abstract form of correlated
  alerts
• haset
• A set of h-alerts been correlated together
• capset
• A set of capabilities obtained by the h-alerts in
  the haset
• timestamp
• The timestamp of the newest h-alert in the haset

20
Alert Correlation

• Given a new h-alert H and a set S of existing
  m-attacks, combine H with a set S of m-attacks,
  where S is a subset of S, the requires of H can
  be comparably inferred from the union of capset
  of each m-attack in S.

21
Alert Correlation (cont.)

• A set of m-attacks vs a single one
• How to combine H with S?
• Create a new m-attack M, where
• M.capset H.provides union Mi.capset (Mi belongs
  S)
• M.haset H union Mi.haset (Mi belongs S)
• M.timestamp H.timestamp
• How to find the appropriate set of m-attack?

22
M-attack Set Searching Alg.

• H is a new h-alert, S' is an empty m-attack set
• From the newest m-attack M to the oldest one
• if M.provides and S' support H.requires, add it
  to S', goto 3
• elif M.provides provides net contribution to S',
  add it to S', continue with the next M
• elif M is the oldest m-attack, set S' to be empty
  set
• Return S'
• Simple, but effective
• S' always contains a single m-attack in
  experiments

23
Response of Failed Attack

• H1 is a web CGI alert, H2 is a 403 Forbidden
  alert
• H1 has been correlated to a m-attack M
  H1.provides is added to M.capset
• H2.provides is an empty set
• After seeing H2, look for corresponding H1
• H1.provides is replaced by H1.failure in M.capset
• Q how to find H1 after seeing H2?
• A fixed pair (H2 , H1 ) is not good!
• We use protocol, IP addresses, port numbers and
  timestamp to find H1.

24
External attacks

• Compromise a computer system A
• Use A as a stepping stone
• Correlate alerts of both above stages
• Q Meaning of compromise?
• A capability to execute arbitrary programs as any
  user

25
Implementation

• Capability Qualifier
• Context Set
• Please refer to paper for details (hope the
  source code and database will be released under
  open source licenses in the future -))

26
Capability Qualifier

• Each capability in the requires set is associated
  with a qualifier, e.g., implicit, optional or
  required. Implicit and optional cap. can be
  ignored if they are not provided by previous
  alerts

27
Context Set

• A capability set (context set) for each known
  system
• (any, mariner, know, UNIX, Linux2.4, none)
• (any, mariner, know, httpd, Apache1.3.0, none)
• An extra capability set (config set) for each
  h-alert
• (src, dst, know, Windows, NT4.0, none)
• (src, dst, know, httpd, IIS4.0, none)
• A mismatch of any capability between the two sets
  of a system indicates the attack fails

28
Experimental Results

• DARPA 2000 Data Set
• UCD Seclab Honeynet Project Data Set
• Performance

29
DARPA 2000

• Used by Ning et al. in their predicate based
  correlation approach
• Five-phase intrusion incidents

Sadmind Ping
Upload mstream
Mstream DDoS
Zombie startup
Sadmind buf overflow
30
Correlation Result

• Alerts of an intrusion from mill to pascal (DARPA
  2000)
• Sig.ID Sig.Name Timestamp
• 652 FTP_User 11-09-15-57-29
• 649 FTP_Pass 11-09-15-57-30
• 27 Admind 11-09-16-34-42
• 3688 Sadmind_Overflow 11-09-16-34-42
• 652 FTP_User 11-09-16-36-45
• 649 FTP_Pass 11-09-16-36-45
• 650 FTP_Put 11-09-16-36-45
• 4370 Mstream_Zombie 11-09-16-36-47
• 3936 TelnetEnvAll 11-09-16-57-01
• Mstream_Zombie 11-09-16-57-27
• ... ... ...

31
DARPA 2000 (cont.)

• Attacks of same class are fused together
• They share the same requires set (pre-conditions)
• Our approach does not need explicit alert fusion
• First four phases are correlated, plus with more
  details
• Mstream zombie are started twice
• The attacker telneted to the victim system in
  between
• Q Why the fifth phase is missing?
• The addresses of the last phase is forged, we
  currently only focus on true addresses
• The fourth phase has multiple alerts with
  different addresses, but there is only one alert
  in the last phase

32
Honeynet Linux

• Three systems are repeatedly compromised.
  Intrusions are analyzed and recorded
• RH 7.2
• OpenSSL buffer overflow
• wu-ftpd buffer overflow
• NT 4.0
• Web scannings
• Directory traversal intrusions
• Anonymous ftp uploading
• Win2000
• Similar to NT 4.0, but not yet examined

33
Honeynet Linux

• RH 7.2 OpenSSL buffer overflow
• No initial result Snort did not reported a
  single alert!
• 5 Snort alerts reported after turning on all
  Snort rules
• All 5 alerts are correlated together
• Sig.ID Sig.Name Timestamp
• 1881 BAD_HTTP 07-31-03-35-27
• 1887 SSL_WORM 07-31-03-36-30
• 1882 id_check 07-31-03-36-30
• 1887 SSL_WORM 07-31-03-37-23
• 1882 id_check 07-31-03-37-23

34
Honeynet Linux (cont.)

• RH 7.2 wu-ftpd buffer overflow
• 78 Snort alerts, most are repeated alerts
• 74th alert is missing from correlation it's an
  attack against ftp server on Windows
• 75th alert is missing from correlation Bugtraq
  states wu-ftpd 2.6.1 and earlier are vulnerable,
  the real server is 2.6.2 but is vulnerable
• After fix the config set of 75th alert, it's
  successfully correlated

35
Honeynet NT 4.0

• 1342 m-attacks contains at least 5 alerts,
  compared with 63,963 alerts in total
• web scannings
• CodeRed worms 30-80 alerts per m-attack
• Intensive scannings largest m-attack contains
  2321 alerts
• directory traversal intrusions
• Two intrusions of June 26 and August 12 did not
  appear in the intrusion analysis report!
• anonymous ftp uploading
• ftp login procedure and uploading alerts are
  correlated

36
Performance

• Hardware Software setting
• PIII 450MHz, 256 MB SDRAM
• Slackware Linux dated Mar 2, 2004, kernel 2.6.4
• MySQL 4.0.17
• 63,963 alerts ( 7 months on NT 4.0)
• 629 IDS signatures, 8 known hosts, 3243
  capabilities
• Correlator implemented in Perl
• Performance results
• 54 sec on initializing data from the database
• 94 minutes to process all alerts, i.e., 11.3
  alert/sec
• Process peak memory usage is 24MB
• Largest m-attack pool contains 165 m-attacks

37
Related Work

• Attack Models
• Requires/Provides Model Templeton
• Target-centric Attack Model Undercoffer
• Alert Fusion and Correlation
• Multisensor data fusion Bass
• Alert fusion aggregation Levitt, Valdes, Debar
• Alert correlation Ning, Cuppens
• Comparison
• Read the papers for details please -)

38
Future Work

• Formal approach
• An attack language based on capability model
• Integration with security policy, access control
  matrix
• Correlation Algorithms
• More algorithms for distributed alert correlation
• Capability Database
• Complete database entries for existing NIDS
  (manually)
• Automatic generating capability set for IDS
  signatures
• Incorporate host based IDS (HIDS)
• IDS
• Attack result verification
• Unknown attack detection

39
Acknowledgement

• Matt Bishop
• Karl Levitt (ECS 236)
• Mark Heckman, Adam Carlson, Brennen Reynolds, Tom
  Ristenpart
• Security Laboratory
• Promia Inc.

40
Q A

• Thank you!
• Interesting users please drop me e-mail for the
  papers submitted to RAID 2004. Hopefully they
  will be put online soon. Stay tuned. -)
• My e-mail zhouji_at_cs.ucdavis.edu