Interface 20031 A Stochastic Model for Intrusions Robert P. Goldman [email protected]

Interface 2003 1

A Stochastic Model for Intrusions

Robert P. [email protected]

April 21, 2023Interface 2003

2

Topic

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


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.

Robert P. Goldman

Relatively ad hoc sensors, mostly based on pattern-matching, engineered by people.


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.

Robert P. Goldman

Need to mention the challenges of getting data from "in the wild" about prevalence and effectiveness of tactics and exploits.


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.


6

Example Use

AttackerSimulator Event Stream Sensor Models

Enhanced version of function supplied by DARPA CyberPanel Grand Challenge Problem.

IDS ReportsIDS Fusion System


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.

Robert P. Goldman

rethink the outline, since it's not clear that the simulation architecture should come first. At any rate, need smoother transition to the second two points.


8

Current Architecture

Attacker Plans

Event Model

Network Model

SimulationEngine/

Interpreteraffects

refers to

feedback


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


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) on a particular network, whether successful or not.

Robert P. Goldman

Need to rethink this viewgraph for this audience.Should introduce the concept of preconditions and postconditions in general.


11

The Frame ProblemThe (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


12

The Situation Calculus

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

Action Precondition axioms Successor State axioms

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


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 other attack modeling languages.

Consider the preconditions for attempting a buffer overflow, for example.

Robert P. Goldman

This viewgraph must be extensively modified.


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.”


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)).


16

Goal-Directed Attack Modeling

Now we can project the effects of individual actions but we want extended, goal-directed attacksTwo 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


17

Golog

Need to package actions into proceduresGolog 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


18

Sample Procedures

proc login(host)if console_access(host) then

( u)?known_uid(u,host); ( s)? login(host, u, s)

endproc ip_spoof(host)

( t)?trusted(host, t); DoS(t) spoof_to(host, t)

end

Parallel composition

Variable binding


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.


20

Goal-directed Procedure Invocation

Need to model agents (attackers) that choose methods appropriate to their goalsGoals may employ subgoalsGoals are persistentSubgoals should come and go with parent goalsSubgoaling gives modularity advantagesWe 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


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.


22

Sample Transcriptlogin(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


23

Summary of Contributions

Attack simulation architectureUse of situation calculus to cash out exploit (and other action) descriptions into a form whose effects can be projectedUse of Golog to capture simple tactics/complex exploits Adding goal-directed procedure invocation to simulate goal-driven attackersFirst 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


24

Related Work: Intrusion DetectionSimulating 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 assessmentAttack 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


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.


26

Future Directions

Better software engineering to make simulator more usable and appealing GUI Debugger More appealing, type-checked, input language

Complete the simulation architectureMake attacker actions (by extension, plans) executable in the real worldActions with durations in metric time; stochastic actionsModeling (faulty) beliefs of attackers and belief updates

Interface 2003 27

End of Presentation

Documents

Interface 20031 A Stochastic Model for Intrusions Robert P. Goldman [email protected]