Transcript MAITA Project CyberPanel review

Adaptive Knowledge-Based Monitoring
Adaptive Knowledge-Based Monitoring
for Information Assurance
Peter Szolovits ([email protected]), MIT LCS
Howard Shrobe ([email protected]), 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 Children’s
Hospital, Boston
Jon Doyle, North Carolina State University
Maita Final, Dec. 5, 2002 -- **Not for distribution**
1
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
3
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)
Maita Final, Dec. 5, 2002 -- **Not for distribution**
4
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
5
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
8
Other Maita Components
• MOM (Monitor of Monitors)
• Human/Computer Interface
– Control Panels
– General-purpose display
• Boot server – starts monitors on its machine
Maita Final, Dec. 5, 2002 -- **Not for distribution**
9
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
10
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*
Maita Final, Dec. 5, 2002 -- **Not for distribution**
11
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
12
Routinely monitoring
Maita Final, Dec. 5, 2002 -- **Not for distribution**
13
Control Panel showing various monitors
Maita Final, Dec. 5, 2002 -- **Not for distribution**
14
Sendmail/relaying & trend lines
Maita Final, Dec. 5, 2002 -- **Not for distribution**
15
Backup sizes
Maita Final, Dec. 5, 2002 -- **Not for distribution**
16
FTP activity
Maita Final, Dec. 5, 2002 -- **Not for distribution**
17
FTP analysis
Maita Final, Dec. 5, 2002 -- **Not for distribution**
18
SNORT
Maita Final, Dec. 5, 2002 -- **Not for distribution**
19
FTP Transshipment Trend Template
RLA
RLA
ESA
ESA
Maita Final, Dec. 5, 2002 -- **Not for distribution**
ESA
ESA
Leveling off of unusual
Transfer destinations
Saturation of host capacity
Start of unusual transfers
Cessation of abnormal
probing
Start of abnormal probing
• ESA = external site activity average
• RLA = resource load activity average
RLA
ESA
20
Recognizing: passwordscan(IP) -> ftp uploads(IP) -> 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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
21
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)
Maita Final, Dec. 5, 2002 -- **Not for distribution**
22
Computational Vulnerability
Analysis
• Grounding the attack model in systematic analysis
• Ontology of:
–
–
–
–
System Properties
System Types
System Structure
Control and Dependencies
Maita Final, Dec. 5, 2002 -- **Not for distribution**
23
Generating Attack Models
Through 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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
24
Modeling System Structure
File
System
Operating
System
Hardware
Processor
Memory
Part-of
Part-of
Access
Controller
Logon
Controller
Job
Admitter
Device
Controllers
Scheduler
controls
Devices
Resides-In
controls
Maita Final, Dec. 5, 2002 -- **Not for distribution**
Device
Drivers
files
Part-of
resources
controls
User
Set
Input-to
controls
Input-to
Work
Load
Scheduler
Policy
25
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
26
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
27
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
Is vulnerable to
Buffer-Overflow
Attack
Maita Final, Dec. 5, 2002 -- **Not for distribution**
IIS Web Server
Process
Takes control of
Buffer-Overflow
Attack
28
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
Modificationaction
Maita Final, Dec. 5, 2002 -- **Not for distribution**
Scheduler
Policy
Parameters
29
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
Controlaction
Maita Final, Dec. 5, 2002 -- **Not for distribution**
User Job
Admitter
30
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
Controls
Job Admitter
Workload
Controls
Job Admitter
Maita Final, Dec. 5, 2002 -- **Not for distribution**
Attack.
31
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
Workload
Component
controlled by
User
Workload
Modify
User Workload
Maita Final, Dec. 5, 2002 -- **Not for distribution**
Component
Workload
Attack.
32
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 OS’s.
• 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 OS’s.
• An access pool is a set of machines that shares
resources, password & access right descriptions
Maita Final, Dec. 5, 2002 -- **Not for distribution**
33
The AI Lab Topology (partial)
Netchex
Server
Switch
8thFloor-1
Server
Access
Pool
Kenmore
Router Netchex
Filters out Telnet.
8thFloor-2
Dwarf
Access
Pool
Maytag
Dopey
Lisp
Access
Pool
Wilson
Truman
Sleepy
Sneezy
Maita Final, Dec. 5, 2002 -- **Not for distribution**
7thFloor-1
Sakharov
Doc
Life
Router
Access
pool
General
Access
Pool
QuincyAdams
Jefferson
Creepy
Crawler
34
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
Controlaction
Typical User
Process
35
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 user’s capabilities
Typical User File
Typical User File
Required for
Read
To Read
User Read Capability
Typical User
Posseses
Capability
User Read Capability
Maita Final, Dec. 5, 2002 -- **Not for distribution**
Logon as
Typical User
Launches
User
Process
36
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 user’s machine
• By monitoring network traffic
– Change it
• By hacking the password file, for example.
Maita Final, Dec. 5, 2002 -- **Not for distribution**
37
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
network
Maita Final,monitor
Dec. 5, 2002 -- **Not
for distribution** traffic
38
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
39
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
40
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
41
An Example
• Affecting reliable performance:
– Control the scheduler • The scheduler is a component that impacts performance
– By modifying the scheduler’s 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.
Maita Final, Dec. 5, 2002 -- **Not for distribution**
42
Affecting Data Privacy (1)
Maita Final, Dec. 5, 2002 -- **Not for distribution**
43
Affecting Data Privacy (2)
Maita Final, Dec. 5, 2002 -- **Not for distribution**
44
Affecting Data Privacy (3)
Maita Final, Dec. 5, 2002 -- **Not for distribution**
45
Affecting Performance (1)
Maita Final, Dec. 5, 2002 -- **Not for distribution**
46
Affecting Performance (2)
Maita Final, Dec. 5, 2002 -- **Not for distribution**
47
Attack Models and Monitoring
Trust Model:
Trustworthiness
Compromises
Attacks
Maita Final, Dec. 5, 2002 -- **Not for distribution**
48
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
49
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
50
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
51
Transition
• Potentially transferable
results:
–
–
–
–
–
Monitoring architecture
Languages of descriptions
Monitoring methods
Diagnostic methods
Learning of trend
templates
– Compilation of utilities
– Visualizations
Maita Final, Dec. 5, 2002 -- **Not for distribution**
• 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
52
Lessons
• Recognize as large systems problem
– Distributed, secure, authenticated, dynamic, selfmonitoring 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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
53
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
Maita Final, Dec. 5, 2002 -- **Not for distribution**
54
Recent Publications
1.
2.
3.
4.
5.
6.
7.
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/
Maita Final, Dec. 5, 2002 -- **Not for distribution**
55