A Stochastic Model for Intrusions

1. A Stochastic Model for Intrusions Robert P. Goldman rpgoldman@sift.info 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 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. 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. Interface 2003

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

6. Example Use Sensor Models Attacker Simulator Event Stream IDS Fusion System IDS Reports Enhanced version of function supplied by DARPA CyberPanel Grand Challenge Problem. 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. Interface 2003

8. Current Architecture Attacker Plans Event Model Network Model feedback Simulation Engine/ Interpreter refers to affects 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 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) on a particular network, whether successful or not. 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 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 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 other attack modeling languages. Consider the preconditions for attempting a buffer overflow, for example. 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.” 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)). 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: • Golog provides methods for embedding situation calculus actions into procedures • Goal-directed procedure invocation added to Golog permits us to model rational, goal-directed agents 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 Interface 2003

18. Sample Procedures Parallel composition 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 Variable binding 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. 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 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. Interface 2003

22. 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 Sample Transcript Interface 2003

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

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