A Stochastic Model for Intrusions Robert P Goldman

A Stochastic Model for Intrusions Robert P. Goldman rpgoldman@sift. info Interface 2003 1

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 Interface 2003 2

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. Interface 2003 3

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. Interface 2003 4

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, goaldirected attacks, and was originally intended to support intrusion report fusion. Interface 2003 5

Example Use Attacker Simulator Event Stream Sensor Models IDS Fusion System IDS Reports Enhanced version of function supplied by DARPA Cyber. Panel Grand Challenge Problem. Interface 2003 6

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. Interface 2003 7

Current Architecture Attacker Plans refers to Event Model feedback Simulation Engine/ Interpreter affects Network Model Interface 2003 8

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 Interface 2003 9

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. Interface 2003 10

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 Interface 2003 11

The Situation Calculus Action representation formalism [Mc. Carthy & 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 Interface 2003 12

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. Interface 2003 13

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. ” Interface 2003 14

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)). Interface 2003 15

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, goaldirected agents Interface 2003 16

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 Interface 2003 17

Sample Procedures proc login(host) if console_access(host) then ( u)? known_uid(u, host); ( s)? login(host, u, s) end Variable binding proc ip_spoof(host) ( t)? trusted(host, t); Do. S(t) spoof_to(host, t) end Parallel composition Interface 2003 18

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. Interface 2003 19

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 Interface 2003 20

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. Interface 2003 21

Sample Transcript login(boris, b 0 ri 5, bpass, _session 0) =======>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, _session 1) rlogin(boris, kubrick, rocky, _session 2) neptune(boris, lucas) =======>neg(tcp_available(lucas)) session_hijack_add_perm_all(rocky, kubrick, lucas) rlogin(boris, kubrick, rocky, _session 3) =======>logged_into(kubrick) ftp(dtappgather) =======>available(dtappgather) dtappgather(_session 3) email(sadmindex) =======>available(sadmindex) sadmindex(_session 3) =======>root_privileged_on(kubrick) magic_transfer(sniffer) =======>available(sniffer) install_sniffer(_session 3, kubrick) =======>access(oracle, fellini) yes Interface 2003 22

Summary of Contributions Attack simulation architecture Use of situation calculus to cash out exploit (and other 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 Interface 2003 23

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 Interface 2003 24

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. Interface 2003 25

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 26

End of Presentation Interface 2003 27