A Stochastic Model for Intrusions

1
A Stochastic Model for Intrusions

• Robert P. Goldman
• rpgoldman_at_sift.info

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

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.

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.

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 dont 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
Sensor Models
Attacker Simulator
Event Stream
IDS Reports
IDS Fusion System
Enhanced version of function supplied by DARPA
CyberPanel Grand Challenge Problem.
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 weve
  developed?
• Must incorporate feedback from the environment.

8
Current Architecture
feedback
Simulation Engine/ Interpreter
refers to
affects
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 OrtaloTempleton
  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.

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

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

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.

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

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

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

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

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 Transcript

• login(boris,b0ri5,bpass,_session0)
• gtlogged_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)
• gtneg(tcp_available(lucas))
• session_hijack_add_perm_all(rocky,kubrick,lucas)
• rlogin(boris,kubrick,rocky,_session3)
• gtlogged_into(kubrick)

• email(sadmindex)
• gtavailable(sadmindex)
• sadmindex(_session3)
• gtroot_privileged(_session3)
• gtroot_privileged_on(kubrick)
• magic_transfer(sniffer)
• gtavailable(sniffer)
• install_sniffer(_session3,kubrick)
• gtaccess(oracle,fellini)
• yes

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

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

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 dont 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 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

27
End of Presentation
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

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 on the network?
• Important to assess countermeasures
• Important to predict false positive IDS reports
• Defender Plans and Defender Actions

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