A Stochastic Model for Intrusions Robert P. Goldman rpgoldman@sift.info Interface 2003 1
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 27 September 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 27 September 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 27 September 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, goal- directed attacks , and was originally intended to support intrusion report fusion. Interface 2003 27 September 2003 5
Example Use Attacker Sensor Models Event Stream Simulator IDS Reports IDS Fusion System Enhanced version of function supplied by DARPA CyberPanel Grand Challenge Problem. Interface 2003 27 September 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 27 September 2003 7
Current Architecture Attacker Plans refers to Simulation Event Model Engine/ feedback Interpreter affects Network Model Interface 2003 27 September 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 27 September 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 27 September 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 27 September 2003 11
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 27 September 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 27 September 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 27 September 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 27 September 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, goal- directed agents Interface 2003 27 September 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 27 September 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); DoS(t) spoof_to(host, t) end Parallel composition Interface 2003 27 September 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 27 September 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 27 September 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 27 September 2003 21
Recommend
More recommend
