A Stochastic Model for Intrusions Robert P. Goldman - - PowerPoint PPT Presentation

Interface 2003 1

A Stochastic Model for Intrusions

Robert P. Goldman rpgoldman@sift.info

27 September 2003

Interface 2003

2

Topic Topic area: Computer and Network Intrusion Detection Subject: A technique for stochastic modeling of goal-directed computer network intruders Benefits: Provides for repeatable tests in computer intrusion detection and supports cyber wargaming Approach: Use techniques from Artificial Intelligence to provide simulated attackers that act (somewhat) rationally to achieve their goals

27 September 2003

Interface 2003

3

Definition of Intrusion Detection

What is intrusion detection? The state of the art?

Current sensors have very high false positive rates (base rate

problems, systematic errors);

Many current sensors have difficulties with novel attacks; No agreement among sensors about the phenomena to be

detected.

Intrusion detectors (IDSes) are sensors whose sensitivity is very difficult to assess

Difficult to test them in realistic environments; Difficult to identify features that affect their sensitivity; Varying frames of reference and fields of vision; Lack of access to sensors’ internals; Lack of labeled data.

Intrusion detector fusion: Fuse reports from multiple IDSes to overcome blind spots, incorporate context, etc.

27 September 2003

Interface 2003

4

Problem

We need to be able to carry out repeatable tests with computer intrusions

To evaluate intrusion detection and response research To train and prepare for intrusions

Unfortunately, with the current state of the art, this is too difficult

Requires set-up and destruction of specially-tailored

networks

Particularly true for research involving coordinated attacks, and exploitation of intrusions

With human attackers, difficult to carry out repeated

trials.

27 September 2003

Interface 2003

5

Simulations

We need simulated attacks on simulated networks. We need simulated attackers

So that we can repeat and replay attacks for

experimentation;

So that we can vary attacks in controlled ways; But our simulated attackers must react to their

environments: closed-loop attack controllers.

Simulations don’t replace real-world experiments, but they are an invaluable supplement. This work aims to simulate extended, goal- directed attacks, and was originally intended to support intrusion report fusion.

27 September 2003

Interface 2003

6

Example Use

Attacker Simulator

Event Stream

Sensor Models Enhanced version of function supplied by DARPA CyberPanel Grand Challenge Problem. IDS Reports IDS Fusion System

27 September 2003

Interface 2003

7

Outline

Simulation Architecture

Overall structure and what exists in prototype.

Event Modeling

What are the building blocks of an intrusion? How do

we model them?

Attacker Modeling / Attacker Plans

How do we model the process of an attack, composed

from the building blocks we’ve developed?

Must incorporate feedback from the environment.

27 September 2003

Interface 2003

8

Current Architecture

Attacker Plans Event Model Network Model Simulation Engine/ Interpreter affects refers to feedback

27 September 2003

Interface 2003

9

Proposed Future Additions

Attacker Population Model – What sort of attackers? What are their objectives?

“Ankle-biters,” criminals, terrorists, spies, etc. Important to assess response and focus on most

important threats.

Sensor Models Background Traffic Model – What is the authorized traffic on the network?

Important to assess countermeasures. Important to predict false positive IDS reports.

Defender Plans and Defender Actions

27 September 2003

Interface 2003

10

Intrusion Event Modeling

Model exploits with preconditions and postconditions [Cuppens & Ortalo;Templeton & Levitt; Lindquist et al]. What are semantics of preconditions and postconditions?

E.g., most preconditions are preconditions for

successful execution not execution per se. [logs show many unsuccessful attempts at intrusion]

To experiment and simulate, we must be able to predict the effects of an action (exploit or other)

• n a particular network, whether successful or

not.

27 September 2003

Interface 2003

11

The Frame Problem

The (little-F) Frame Problem – When an action is executed, what does not change?

What is independent of my action?

The Ramification Problem – What changes are indirectly caused by the action?

E.g., I paint an object; all of its parts are also

painted…

Qualification Problem – What are all the conditions necessary to make an action feasible?

Relatively easy to name some necessary conditions,

but getting all the sufficient conditions is more difficult…

Ramification and Qualification problems closely related to database integrity constraints

27 September 2003

Interface 2003

12

The Situation Calculus

Action representation formalism [McCarthy & Hayes; Reiter; Levesque; etc.] Dialect of First Order Logic Provides solutions to the Frame problem Action representations are decomposed into:

Action Precondition axioms Successor State axioms

With appropriate closure assumptions, the above provide a solution to the frame problem These representations are also relatively natural for modeling An efficient, special-purpose prover can project the effects of a sequence of actions in a given situation

27 September 2003

Interface 2003

13

Action Precondition Axioms

Poss(login(user, host), s) ≡ atconsole(user,host,s) “A user can login to a host in a situation, if that user is at the console of that host.” Note that possibility of an action is a much weaker notion than the conventional precondition used in

• ther attack modeling languages.

Consider the preconditions for attempting a buffer

• verflow, for example.

27 September 2003

Interface 2003

14

Successor State Axioms

Poss(a, s) → { loggedin(user, host, do(a,s)) ≡ [a = login(user,host) or (loggedin(user,host,s) and a ≠ logout(user, host)) ] } “A user will be logged in to host after doing an action, if the action is logging in, or the user was logged in and the action is not logging out.”

27 September 2003

Interface 2003

15

Practical Matters Precondition and Successor State axioms can be derived from more natural, modular specifications.

simple_action(add_oracle_account(Session, Host, UID, Password), [knows_pass(Host, UID, oracle)=true, known_service(Host, oracle)=true, valid_uid(UID, Host, oracle)=true, password(Host, oracle, UID, Password)=true], runs(Host, oracle), root_session(Session,Host)).

27 September 2003

Interface 2003

16

Goal-Directed Attack Modeling

Now we can project the effects of individual actions but we want extended, goal-directed attacks Two parts to solution:

• 1. Golog provides methods for embedding

situation calculus actions into procedures

• 2. Goal-directed procedure invocation added to

Golog permits us to model rational, goal- directed agents

27 September 2003

Interface 2003

17

Golog

Need to package actions into procedures Golog extends situation calculus semantics to procedures with

Sequences Nondeterminism Conditionals Variable binding Concurrency Loops Constructs taken from conventional programming

language temporal logics

Can project effects of executing procedures with augmented situation calculus prover

27 September 2003

Interface 2003

18

Sample Procedures

proc login(host) if console_access(host) then (π u)?known_uid(u,host); (π s)? login(host, u, s) end proc ip_spoof(host) (π t)?trusted(host, t); DoS(t)  spoof_to(host, t) end

Parallel composition Variable binding

27 September 2003

Interface 2003

19

Helpful, but Not Sufficient Modeling:

Not enough to model an agent whose objective is to

deface a web server and who will use all the methods at his/her disposal to achieve that goal.

Engineering:

Not convenient to add new means to, for example,

achieve the goal of acquiring root privilege.

We want to be able to add new events and tactics

freely and have them used within existing tactics.

Dynamically generated attack trees.

27 September 2003

Interface 2003

20

Goal-directed Procedure Invocation

Need to model agents (attackers) that choose methods appropriate to their goals Goals may employ subgoals Goals are persistent Subgoals should come and go with parent goals Subgoaling gives modularity advantages We have provided constructs for goal-directed procedure invocation within the semantics of Golog (and a Golog prover) We have developed attacker tactics that employ goals and subgoaling

27 September 2003

Interface 2003

21

Sample Procedure with Goals

KA user_to_root(h) (π s)? logged_into(h, s); achieve_goal(root_priv(s)) to achieve root_privileged_on(h) when logged_into(h) “To get root privilege on a host, if you are logged into that host, escalate the privilege of that login session.” Note that the attacker may now try multiple means to achieve root privilege on a session, if the first one fails. Or the attacker may back up and try an alternative KA at this level. Method choice and response to failures are stochastic.

27 September 2003

Interface 2003

22

Sample Transcript

login(boris,b0ri5,bpass,_session0) =======>logged_into(boris) zone_transfer(besson,boris) ping_sweep(boris,ip(192,168,2,*)) ping_sweep(boris,ip(192,168,3,*)) ping_sweep(boris,ip(192,168,1,*)) port_sweep(boris,bergman) port_sweep(boris,besson) port_sweep(boris,fellini) port_sweep(boris,kubrick) port_sweep(boris,landis) port_sweep(boris,lucas) rlogin(boris,kubrick,rocky,_session1) rlogin(boris,kubrick,rocky,_session2) neptune(boris,lucas) =======>neg(tcp_available(lucas)) session_hijack_add_perm_all(rocky,kubrick,lucas) rlogin(boris,kubrick,rocky,_session3) =======>logged_into(kubrick) ftp(dtappgather) =======>available(dtappgather) dtappgather(_session3) dtappgather(_session3) email(sadmindex) =======>available(sadmindex) sadmindex(_session3) =======>root_privileged(_session3) =======>root_privileged_on(kubrick) magic_transfer(sniffer) =======>available(sniffer) install_sniffer(_session3,kubrick) =======>access(oracle,fellini) yes

27 September 2003

Interface 2003

23

Summary of Contributions

Attack simulation architecture Use of situation calculus to cash out exploit (and

• ther action) descriptions into a form whose

effects can be projected Use of Golog to capture simple tactics/complex exploits Adding goal-directed procedure invocation to simulate goal-driven attackers First working version of the attacker simulator

able to simulate simple scenarios Built on modified Golog interpreter/simulator established level of abstraction for model can exhibit variation between individual intrusion runs

27 September 2003

Interface 2003

24

Related Work: Intrusion Detection

Simulating Network Attacks:

Checkmate [Apostal et al] – simple, somewhat ad-hoc simulator,

difficult to extend; no simulated attacker

[Chi et al] – described a simulation architecture (non-concurrent);

less emphasis on the mechanism of attack and action modeling

Grammar-based approach [Gorodetski & Kotenko] – similar;

action model seems simpler

Planning and model-checking for vulnerability assessment Attack Description Languages

Survey [Vigna, Eckmann, Kemmerer] Precondition/Postcondition modeling [Templeton and Levitt,

Cuppens and Ortalo]

We are more concerned with projecting the effects of exploits

(and other actions) and an executable semantics of the pre- and postconditions

Others more concerned with analyzing exploits

27 September 2003

Interface 2003

25

Related Work: Artificial Intelligence

Softbots [Etzioni, Golden, Weld] Goal-directed procedure languages

PRS [Georgeff & Lansky] RAPS [Firby]

These have rich control structures and goal-directed procedure invocation, but their actions don’t have clear semantics for simulation.

Automated Opponents in military wargaming [Tambe, et. al.] Action Modeling [Reiter; Shanahan; Baral]

Provide clean semantics, but cumbersome to describe goal-directed actions, closed-loop control.

27 September 2003

Interface 2003

26

Future Directions

Better software engineering to make simulator more usable and appealing

GUI Debugger More appealing, type-checked, input language

Complete the simulation architecture Make attacker actions (by extension, plans) executable in the real world Actions with durations in metric time; stochastic actions Modeling (faulty) beliefs of attackers and belief updates

Interface 2003 27

End of Presentation

27 September 2003

Interface 2003

28

Simulation Architecture

Current Version: Can produce goal-directed attacks on a relatively passive network

Explore different intruder courses of action Experiment with plan recognition techniques Modeling choices: relatively high-level model of

exploits (not packet-level)

Correlation Version: Add models of background traffic and IDSes

Test correlation approaches Game human defense approaches

Model with Defenders: Add defender actions

Test (automated) defense approaches Game network attacks

27 September 2003

Interface 2003

29

Proposed Future Additions

Attacker Population Model – What sort of attackers? What are their objectives?

“Ankle-biters,” criminals, terrorists, spies Important to assess response and focus on most important

threats

Sense Model and Beliefs –

What information do the agents gain through their actions? How

do they update their beliefs (e.g., about the OS on a particular host)?

Currently ad hoc

Sensor Models Background Traffic Model – What is the authorized traffic

• n the network?

Important to assess countermeasures Important to predict false positive IDS reports

Defender Plans and Defender Actions

27 September 2003

Interface 2003

30

Example Effect Specification

if login(agent,host,uid,sess) when valid_uid(uid, host) and new_sid(sess, host, uid) and known_password(agent, uid, host) result logged_in(agent, sess, host, uid) Note complex specification of preconditions for effects. Note effect specification separated from preconditions for

• execution. The preconditions for trying to login are different

from preconditions of successfully logging in. Our prover works with effect specifications like these.

27 September 2003

Interface 2003

31

Simulation Architecture -- Current

Attacker Plans – What are the means an attacker can use to achieve these objectives?

Captured as goal-directed Golog procedures.

Event Model/Event Dictionary – The basic building blocks of the plans. Captured in situation calculus Network Model – Records the effects of the events, and combines with event model to determine outcomes of actions Augmented Golog Interpreter – Execution/simulation framework