Adaptive KnowledgeBased Monitoring for Information Assurance

1
Adaptive Knowledge-Based Monitoring for
Information Assurance
Adaptive Knowledge-Based Monitoring

• Peter Szolovits (psz_at_mit.edu), MIT LCSHoward
  Shrobe (hes_at_ai.mit.edu), MIT AI Lab
• William J. Long, Glenn S. Burke, Mike McGeachie,
  Delin Shen, Ying Zhang, Steve Bull, Joe Hastings,
  MIT
• Isaac S. Kohane, Marco Ramoni, The Childrens
  Hospital, BostonJon Doyle, North Carolina State
  University

2
Adaptive Knowledge-Based Monitoring
Impact

Rapid reconfiguration enables adaptation to
evolving
threats "inside the loop"

Dynamically and intelligently targeted monitors
give
commanders the information they need

Rational response decisions ensure optimal,
flexible,
and robust defenses

Trust models enable operations despite
compromises
to critical computing bases

Common language and repository for IAS
knowledge strengthens defensive efforts
Jon Doyle Peter Szolovits http//www.medg.lcs.mi
t.edu/projects/maita
3
Domain Background

• Defense against information attacks requires
  broad and deep understanding of
• Mission
• Systems used to accomplish it
• Ability to operate with diminished resources
• Trade-offs among competing objectives
• Threats
• Capabilities of adversary
• Experience

4
Our Aims/Cyber Panel

• Provide situational awareness to commanders
• Inside the loop monitor construction/adaptation
• Timely concerns
• Empirical
• Simplify CC of monitoring
• Guidance for automatic trust management
• Self-monitoring, resource allocation
• Common description language(s) and library(ies)

5
Potential Contributions

• Conceptual
• Advance role of probabilistic, decision analytic,
  preference-based dynamic reasoning
• Develop new methods for adaptive knowledge-based
  monitoring
• Learning of new monitoring methods
• Expressive languages for description of domain,
  tasks, attacks, monitoring strategies, etc.
• Artifactual
• Maita system as a testbed to foster and test
  above ideas

6
Our Overall Approach

• Knowledge-Based Monitoring
• Contextual Awareness
• Reusable monitoring methods
• Diagnostic methods to identify underlying
  problems
• Preference and utility-based specification of
  tactics

7
Monitoring Management Executive
Monitor Control Panels
Monitoring Knowledge Library
System Health Monitor
8
Maita Monitors

• Maita is based on a general-purpose distributed
  system archtecture whose primitive (and composed)
  components are monitors
• Control inputs via specialized HTTP server
• Set of input terminals a monitor with no inputs
  is a data source, often wrapping a lower-level
  system resource.
• Set of output terminals a monitor with no
  outputs is a display or alerting service

9
Other Maita Components

• MOM (Monitor of Monitors)
• Human/Computer Interface
• Control Panels
• General-purpose display
• Boot server starts monitors on its machine

10
Outline

• Incremental Progress since Charleston PI meeting
• (Not here
• Preference compilation
• Markov analysis of system call traces
• Multi-stream data segmentation
• Efficient trend matching)
• Maita
• Vulnerability Analysis
• Lessons Learned

11
Progress since PI Meeting

• Making Maita implementation more
• Complete
• Run on Windows as well as Unix platforms
• Ability for monitoring processes to save
  checkpoint data in MoM
• Robust
• Restart capabilities from various kinds of
  system, communication, failure
• More thorough self-monitoring
• Status progress, but still not completed

12
Progress since PI Meeting

• More sources of monitoring data
• System log (ftp, sendmail, imapd)
• Auth log (logins, ipmon, popper)
• Daemon log (ftp details, stunnel, telnet, )
• Sendmail volume, relaying
• Disk utilization
• Backup sizes
• CPU load
• Lincoln Labs TCPDUMP
• Additional filters detectors, with HCI, using
• Configurable parameters
• Temporal sequencing

13
Routinely monitoring
14
Control Panel showing various monitors
15
Sendmail/relaying trend lines
16
Backup sizes
17
FTP activity
18
FTP analysis
19
SNORT
20
FTP Transshipment Trend Template

• ESA external site activity average
• RLA resource load activity average

Start of abnormal probing
Saturation of host capacity
Leveling off of unusual Transfer destinations
Start of unusual transfers
Cessation of abnormal probing
21
Recognizing passwordscan(IP) -gt ftp uploads(IP)
-gt excess diskuse
Events recognized by ftp-monitor as preconditions
and as events
Parameters that must match for precondition to
enable event
Label to put on resulting event
22
Work in Progress

• Writing
• Completion of Maita code to distributable state
• Web site summarizing project accomplishments and
  distributing results
• Student research
• Preferences for student interest matching,
  collaboration, and retrieval of focused
  information
• Real-time machine learning from intensive care
  unit data
• Markov analysis of system call patterns as
  another basis for detecting anomalies
• Planning for future use
• mMesh proposal (distributed health records,
  system monitoring)
• ARMS (IXO) proposal on secure ship computing
  environment infrastructure
• Potential industrial collaborations (under
  discussion)

23
Computational Vulnerability Analysis

• Grounding the attack model in systematic analysis
• Ontology of
• System Properties
• System Types
• System Structure
• Control and Dependencies

24
Generating Attack ModelsThrough Vulnerability
Analysis

• The problem Where does the attack model and its
  links to behavioral modes come from?
• So far, by hand crafting
• Vulnerability Analysis supplants this by a
  systematic analysis
• Forming an ontology of how computer systems are
  structured
• Building models of the environment
• Network topology nodes, routers, switches,
  filter, firewalls
• System types hardware, operating systems
• Server and user suites Which servers and users
  run where
• Analyzing how properties depend on resources
• Analyzing the vulnerabilities of the resources

25
Modeling System Structure
File System
files
Part-of
resources
Operating System
Access Controller
Hardware
controls
Logon Controller
User Set
Processor
Part-of
Part-of
Input-to
Job Admitter
Memory
Device Controllers
controls
Scheduler
Work Load
controls
Input-to
Devices
Device Drivers
Scheduler Policy
Resides-In
controls
26
Modeling the topology
Machine name sleepy OS Type Windows-NT Server
Suite IIS.. User Authentication Pool Dwarfs
Switch subnet restrictions. .
Switch subnet restrictions. .
Router Enclave restrictions. .
Topology tells you who can share (and sniff)
which packets who can affect what types of
connections to whom
27
The Key Notion is Dependency

• Start with the desirable properties of systems
• Reliable performance
• Privacy of communications
• Integrity and/or privacy of data
• Analyze which system components impact those
  properties
• Performance - scheduler
• Privacy - access-controller
• Rule 1 To affect a desirable property control a
  component that contributes to the delivery of
  that property

28
Controlling components (1)

• One way to gain control of a component is to
  directly exploit a known vulnerability
• One way to control a Microsoft IIS web server is
  to use a buffer overflow attack on it.

IIS Web Server Process
IIS Web Server
Is vulnerable to
Takes control of
Buffer-Overflow Attack
Buffer-Overflow Attack
29
Controlling components (2)

• Another way to control a component is to find an
  input to the component and then find a way to
  modify the input
• Modify the scheduler policy parameters

Scheduler
Scheduler
Input to
control by
Scheduler Policy Parameters
30
Controlling components (3)

• Another way to control a component is to find one
  of its sub-components and then to find a way to
  gain control of the sub-component

Job-Admitter
Job-Admitter
Component-of
control by
User Job Admitter
31
Modifying Inputs (1)

• One way to modify an input is to find a component
  which controls the input and then to find a way
  to gain control component

Scheduler
Scheduler
Input-of
control by
Workload
Controls
Job Admitter
Workload
Controls
Controls
Job Admitter
Attack.
32
Modifying Inputs (2)

• One way to modify an input is to find a component
  of the input and then to find a way to modify the
  component

Scheduler
Scheduler
Input-of
controlled by
Workload
Component
User Workload
33
Access Rights

• Each object specifies a set of capabilities
  required for each operation on that object
• Capabilities are organized in an DAG
• This generalizes the access mechanisms of all
  OSs.
• Each actor (user or process) possesses certain
  capabilities.
• An actor can perform an action on an object only
  if it possesses a capability at least as strong
  as that required for the operation
• This is a generalization of the access mechanisms
  in all current OSs.
• An access pool is a set of machines that shares
  resources, password access right descriptions

34
The AI Lab Topology (partial)
Router Access pool
Netchex
Router Netchex Filters out Telnet.
Server Switch
8th-Floor-1
8th-Floor-2
7th-Floor-1
Sakharov
Wilson
Lisp Access Pool
Dwarf Access Pool
Server Access Pool
Truman
Dopey
Kenmore
Sleepy
Maytag
Quincy-Adams
General Access Pool
Sneezy
Creepy Crawler
Jefferson
35
Obtaining Access (1)

• One way to gain access to an operation on an
  object is to find a process with an adequate
  capability and take control of the process

Typical User File
Typical User File
Required for Read
To Read
User Read Capability
Typical User Process
Possesses Capability
User Read Capability
36
Obtaining Access (2)

• Another way to gain access to an operation on an
  object is to find a user with an adequate
  capability and find a way to log in as that user
  and launch a process with the users capabilities

Typical User File
Typical User File
Required for Read
To Read
User Read Capability
Typical User
Posseses Capability
Launches
User Read Capability
37
Logging On

• Logging on requires obtaining knowledge of a
  password
• To gain knowledge of a password
• Guess it, using guessing attacks
• Sniff it
• By placing a parasitic virus on the users
  machine
• By monitoring network traffic
• Change it
• By hacking the password file, for example.

38
Monitoring and Changing Network Traffic

• Network are broken down into subnet segments
• Segments are connected by Routers
• Routers can monitor traffic on any connected
  segment
• Each segment may be
• Shared media
• Coaxial ethernet
• Wireless ethernet
• Any connected computer can monitor traffic
• Switched media
• 10 (100, 1000) base-T
• Only the switch (or reflected ports) can monitor
  Traffic
• Switches and Routers are computers
• They can be controlled
• But they may be members of special access pools
• To gain knowledge of some information, gain the
  ability to monitor network traffic

39
Residences

• Components reside in several places
• Main memory
• Boot files
• Paging Files
• They migrate between residences
• Through local peripheral controllers
• Through networks
• To modify/observe a component find a residence of
  the component and modify/observe it in the
  residence
• To modify/observe a component find a migration
  path and modify/observe it during the
  transmission

40
Formats and Transformations

• Components live in several different formats
• Source code
• Compiled binary code
• Linked executable images
• Processes transform one format into another
• Compilation
• Linking
• To modify a component change an upstream format
  and cause the transformations to happen
• To modify a component gain control of the
  processes that perform the transformations

41
Modification during Transmission

• To control traffic on a network segment launch a
  man in the middle attack
• Get control of a machine, redirect traffic to it
• To observe network traffic get control of a
  switch/router and a user machine and then reflect
  traffic to the user machine
• To modify network traffic launch an inserted
  packet attack.
• Get control of a machine
• Send a packet from the controlled machine with
  the correct serial number but wrong data before
  the sender sends the real packet

42
An Example

• Affecting reliable performance
• Control the scheduler -
• The scheduler is a component that impacts
  performance
• By modifying the schedulers policy parameters
• The policy parameters are inputs to the scheduler
• By gaining root access
• The policy parameters require root access for
  writing
• By using a buffer overflow attack on the
  web-server
• The web-server process possesses root
  capabilities
• The web-server process is vulnerable to a
  buffer-overflow attack.
• For this attack to impact performance, all the
  actions must succeed
• Each has an a priori probability based on its
  inherent difficulty and current evidence
  suggesting that it occurred.

43
Affecting Data Privacy (1)
44
Affecting Data Privacy (2)
45
Affecting Data Privacy (3)
46
Affecting Performance (1)
47
Affecting Performance (2)
48
Attack Models and Monitoring
Trust Model Trustworthiness Compromises Attacks
49
Using Attack Scenarios

• This information is captured in an
  object-oriented Knowledge Representation and a
  rule-base system that reasons about it.
• The inference process develops multi-stage attack
  scenarios
• The scenarios can be transformed into trend
  templates for plan recognition purposes
• The scenarios can be transformed into Bayesian
  network fragment for diagnostic purposes
• The model can be used to audit an environment for
  possible cascaded vulnerabilities

50
Technical Validation

• Conceptual adequacy of
• Descriptive languages
• Monitoring methods
• Learning approaches
• Performance of artifacts
• Ability to recognize events of interest to human
  sysadmins
• Resource utilization

51
Schedule (and Future Milestones)

• End-to-end data feed, analysis and display
• Accomplished
• New, more efficient Trend Template matcher as
  monitor component
• Partly Accomplished
• Maita system
• Robust complete implementation (almost)
• Demonstration on local data sources
  (accomplished)
• Validation against sysadmins (not done)
• Preference ? utility function compiler
• Complete, numerous applications under way
• Analyses, refinements and papers

52
Transition

• Potentially transferable results
• Monitoring architecture
• Languages of descriptions
• Monitoring methods
• Diagnostic methods
• Learning of trend templates
• Compilation of utilities
• Visualizations

• Plans and Interest
• Preference compiler
• Teknowledge interest
• Harvard/MIT HST program interest matching Red
  Book
• Maita monitors
• NLM proposal for distributed clinical data
  sharing
• Potential commercial collaboration/transfer

53
Lessons

• Recognize as large systems problem
• Distributed, secure, authenticated, dynamic,
  self-monitoring computing infrastructure
• Design and implement for robustness, generality
• Collaborate with others
• Recognize as large knowledge-based system problem
• Need lots of knowledge
• Systematic representation
• Basic inference system as substrate

54
More Lessons

• Recognize as large HCI problem
• The total problem is unsolvable
• Focus on limited goals
• Collaborate with others
• Need good data for development and formative
  evaluation

55
Recent Publications

• McGeachie, Michael, Efficient Utility Functions
  for Ceteris Paribus Preferences, AAAI 2002.
• Shrobe, Howard, Computational Vulnerability
  Analysis for Information Survivability, AAAI
  2002.
• Long, William, Doyle, Jon, Burke, Glenn, and
  Szolovits, Peter, Detection of Intrusion across
  Multiple Sensors, submitted.
• McGeachie, Michael and Doyle, Jon, Utility
  Functions for Ceteris Paribus Preferences,
  submitted.
• Steven Bull, Diagnostic Process Monitoring with
  Temporally Uncertain Models, MIT EECS SM Thesis,
  May 2002.
• Jon Doyle, Isaac Kohane, William Long, Howard
  Shrobe, and Peter Szolovits, "Agile Monitoring
  for Cyber Defense", Second DARPA Information
  Survivability Conference and Exposition
  (DISCEX-II), Anaheim, California, June 12-14,
  2001.
• Jon Doyle, Isaac Kohane, William Long, Howard
  Shrobe, and Peter Szolovits, "Event recognition
  beyond signature and anomaly", Second IEEE-SMC
  Information Assurance Workshop, West Point, New
  York, June 5-6, 2001.

http//medg.lcs.mit.edu/projects/maita/
56
Financial Status(12/5/2002)

• Total funds received 1,987,403
• Total funds expended all
• Remaining 295,720
• Depletion 9/30/2002
• Total funding 1,987,403
• Total contract 2,487,144
• possible return of disability

57
Current personnel

• Peter Szolovits
• Howie Shrobe
• Bill Long
• Glenn Burke
• Students Delin Shen, Ying Zhang, Joe Hastings
• Fern DiOliveira
• Childrens Hospital Isaac Kohane, Marco Ramoni