adaptive knowledge based monitoring for information assurance l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Adaptive Knowledge-Based Monitoring for Information Assurance PowerPoint Presentation
Download Presentation
Adaptive Knowledge-Based Monitoring for Information Assurance

Loading in 2 Seconds...

play fullscreen
1 / 52

Adaptive Knowledge-Based Monitoring for Information Assurance - PowerPoint PPT Presentation


  • 144 Views
  • Uploaded on

Adaptive Knowledge-Based Monitoring. Adaptive Knowledge-Based Monitoring for Information Assurance. Peter Szolovits ( psz@mit.edu ), MIT LCS Howard Shrobe ( hes@ai.mit.edu ), MIT AI Lab William J. Long, Glenn S. Burke, Mike McGeachie, Delin Shen, Ying Zhang, Steve Bull, Joe Hastings, MIT

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Adaptive Knowledge-Based Monitoring for Information Assurance' - bianca


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
adaptive knowledge based monitoring for information assurance

Adaptive Knowledge-Based Monitoring

Adaptive Knowledge-Based Monitoring for Information Assurance

Peter Szolovits (psz@mit.edu), MIT LCSHoward Shrobe (hes@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 Children’s Hospital, BostonJon Doyle, North Carolina State University

domain background
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
our aims cyber panel
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)
potential contributions
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 monitors
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
other maita components
Other Maita Components
  • MOM (Monitor of Monitors)
  • Human/Computer Interface
    • Control Panels
    • General-purpose display
  • Boot server – starts monitors on its machine
outline
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
progress since pi meeting
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*
progress since pi meeting9
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
ftp transshipment trend template

RLA

RLA

RLA

ESA

ESA

ESA

ESA

ESA

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

slide18

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

work in progress
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)
computational vulnerability analysis
Computational Vulnerability Analysis
  • Grounding the attack model in systematic analysis
  • Ontology of:
    • System Properties
    • System Types
    • System Structure
    • Control and Dependencies
generating attack models through vulnerability analysis
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
modeling system structure

File

System

Modeling System Structure

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

modeling the topology
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

the key notion is dependency
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
controlling components 1
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

controlling components 2

Scheduler

Policy

Parameters

Modification-

action

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

controlling components 3

Control-

action

User Job

Admitter

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

modifying inputs 1
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.

modifying inputs 2

User Workload

Component

Workload

Modify

Attack.

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

access rights
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
the ai lab topology partial

Doc

Life

Router

Access

pool

The AI Lab Topology (partial)

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

obtaining access 1

Control-

action

Typical User

Process

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

obtaining access 2

Logon as

Typical User

User

Process

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

Launches

User Read Capability

logging on
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.
monitoring and changing network traffic
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
residences
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
formats and transformations
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
modification during transmission
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
an example
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.
attack models and monitoring
Attack Models and Monitoring

Trust Model:

Trustworthiness

Compromises

Attacks

using attack scenarios
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
technical validation
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
schedule and future milestones
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
transition
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
lessons
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
more lessons
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
recent publications
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/