S. Upadhyaya1

1
Towards an Integrated Real-Time Intrusion
Assessment and Recovery Framework for Network
Management

• Shambhu J. Upadhyaya
• Dept. of Computer Science Eng.
• SUNY at Buffalo
• Buffalo, New York, 14260
• October 2000
• (Research Supported by AFOSR, AFRL)

2
Focus of the Talk

• Network Management Framework
• Intrusion detection, response and recovery
• Key Components
• Assertions, data mining, profiling for intrusion
  assessment and analysis
• Reasoning for security management
• Undo/redo type recovery
• Concurrent intrusion detection by encapsulation
  of user intent (Joint work with Kevin Kwiat, AFRL)

3
Why Concurrent, Why Encapsulation?

• Concurrent Intrusion Detection
• Current techniques are passive
• Do not offer much for damage assessment
• Need proactive techniques
• User Intent Encapsulation
• Concurrent detection concurrent monitoring
• Monitoring with respect to what?
• Need a reference graph

4
Break-ins, Hacking, Abuse

• Break-ins, Hacker Challenges
• June 1999, Vandalized, defaced web sites of DOI,
  FBI in DC, supercomputer lab at Idaho Falls
• DOS Attacks
• Aug 1999, University of Minnesota, internet was
  brought down for 2 days
• Feb 2000, Web paralysis, Many e-commerce
  companies (Yahoo, eBay, Amazon.com) brought to
  their knees
• Insider Threats

5
Measures Taken by the Government

• Targeting Cyberterrorism
• October 1997, Presidents Commission on CIP
• Identifies nations electrical, transportation,
  telecom financial systems as critical points
• Need to be made secure and dependable
• Information Security Summit at White House
• February 2000, Invited company CIOs, academic
  researchers to the White House
• Goal was to find ways to defeat distributed DOS
• CIP/SW URI
• Aug. 2000, Multi-agency DoD program solicitation

6
Outline of the Talk

• Introduction
• Traditional Approaches
• Concurrent Intrusion Detection
• Signature Analysis
• Overall Network Management Architecture
• Algorithm and Illustration
• Prototype Development
• Application Environments Experiments
• Discussion

7
Security or Fault Tolerance, Which One?

• Fault Tolerance
• 30 years ago, technology not at its best, failure
  very common
• Von Neumanns concept of redundant resources
• Telecom, Space shuttle, Deep space probes built
  with stringent fault tolerance requirement
• Today, email, disks, servers all come with dual
  resources
• Despite state-of-the-art tools for design, FT is
  important
• System complexity increases, new types of
  failures occur
• Security
• Failures are of different kind in this
  information age
• Greed, fraudulent operations, spying, hacking for
  fun
• Both share common features
• Failure avoidance, tolerance

8
Cryptographic Techniques

• Computer crime is certain to continue
• Institute controls to preserve
• Confidentiality, Integrity, Availability
• Encryption is the most powerful tool
• Strongly based on Information Theory
• Heavily researched topic - RSA Scheme, Elliptic
  Curve
• It doesnt solve all the security problems
• Need to develop counter-measures that would
  complement existing schemes

9
The Big Picture Where Are We?

• Introduction
• Traditional Approaches
• Concurrent Intrusion Detection
• Signature Analysis
• Overall Network Management Architecture
• Algorithm and Illustration
• Prototype Development
• Application Environment Experiments
• Discussion

10
Intrusion Detection -Traditional Methods

• Rule-based, Model-based, State transition-based
  techniques Lunt 93
• All are based on audit-trail analysis
• Passive, after-the-fact solutions
• Some recent efforts are claimed to be real-time
• Techniques that use audit-trail as the baseline
  approach cannot be real-time!

11
EMERALD

• Event Monitoring Enabling Responses to Anomalous
  Live Disturbances
• Deployed by SRI International (DARPA-funded)
• Hierarchical, non-monolithic structure
• Has a profile engine signature analysis engine
• Integrated P-BEST
• Performs live traffic analysis of TCP/IP gateways
• Claimed to be a gem
• Largely audit-trail based!
• Other efforts at GMU, Purdue, UC Davis, Companies

12
The Big Picture Where Are We?

• Introduction
• Traditional Approaches
• Concurrent Intrusion Detection
• Signature Analysis
• Overall Network Management Architecture
• Algorithm and Illustration
• Prototype Development
• Application Environments Experiments
• Discussion

13
Concurrent Monitoring Methodology

• Ideas on security come from fault tolerance
• Leveraging concepts from other domains
• Faults Failures Vs. Threats and Attacks
• Similarities and differences!
• Fault effects analyzed using stochastic models
• Threats cannot be! They are made to happen
• Similarity ends here!
• We just borrow the concept of control flow
  checking

14
Control Flow Checking by Signature Analysis

• Program pre-analysis
• Generate control flow graph
• Transient faults result in instruction bit errors
  and control flow errors
• Verify control flow
• Technique is based on sound principles
• Error detection, correction codes

15
Concurrent Error Detection(Upadhyaya
Ramamurthy 94)

• Generate compile-time signatures assertions and
  embed them into instruction stream
• Monitor execution and look for discrepancy

Address Processor Memory
BUS
Tags
Reset
SIG-REG
SIG-GEN
CU
BD
Error Signal
COMPARATOR
16
Our Approach to CID

• Need a reference graph, but dont have one
• Generate one - Encapsulation of user intent
• System queries users for a scope of session
• An agent translates this into a set of verifiable
  assertions
• Monitor run-time commands
• Assess user behavior
• Advantages
• No need to sift through audit data
• Both external and internal abuse can be handled
  uniformly

17
Preliminaries

• Assumptions
• LAN with access by UserID Password submission
• Communication with other processes by message
  passing
• Intrusions - masquerading, legitimate user
  penetration, legitimate user leakage etc.

18
Definitions

• Watchdog Monitor
• Concurrent monitor of user commands (script or a
  macro)
• Session Scope
• Encapsulates user intent by means of a GUI
• Verifiable Assertion
• (subject, action, object, period)
• Subject - A superID (loginID, IP address, tty
  no.)
• Action - Operation performed (login, read,
  execute..)
• Object - Receptor of action (files, programs,
  messages, records..)
• Period - Time of usage of a command (absolute or
  relative)

19
Definitions

• Sprint-Plan
• Signature powered Revised Instruction Table is a
  collection of verifiable assertions
• Also includes temporal sequences of operations
• Attack
• Actions whose purpose is to compromise the
  integrity, confidentiality, or availability of a
  resource
• Intrusion
• Deviations resulting in violation of security
  policy
• Very difficult to judge

20
Flow Diagram of CID

User
Session Scope
Plan Generator
Sprint Plan
Filter
One-time effort
Run-time monitoring


Run-time Commands
Assertion Generator
Run-time Watchdog Monitor

Tolerance limits, counters, Thresholds
Intrusion Signal
21
Overall Architecture of Network Management
Secure File Monitor
Recovery Module
Network level Profiler

File Server
Gateway, Router Bridge
Local Area Network
Host 1
Host 1
To Other Networks


Master Monitor
Master Monitor
User Monitor 1
User Monitor 2
User Monitor 1
User Monitor 2
Task 1
Task 2
Task 1
Task 2
22
Block Schematic of the Watchdog
User Command Buffer
Operating System
Atomic Operation Generator
Previously Generated Table of Verifiable Assertion
s
Inclusion Checker
Pattern Matching Unit
Counter and Dialog Initiator
Buffer Register
Exception Generator
To User
Intrusion Signal to Master Watchdog
23
Outline of the Talk

• Introduction
• Traditional Approaches
• Concurrent Intrusion Detection
• Signature Analysis
• Overall Network Management Architecture
• Algorithm and Illustration
• Prototype Development
• Discussion
• Future Efforts

24
Algorithm

• Two phases -- Initialization and Runtime op.
• Steps of On-line Monitoring
• 1. Set monitor_rate, tolerance_rate, counter
• 2. For all user_command_line do
• 3. Decode user_command_line into atomic
  operations
• 4. If each atomic_operation in sprint_plan then
• a. No_Error, go to Step 3
• 5. else
• a. If subject_ID_violation then
• i. Set intrusion_signal, exit
• b. Else
• i. Counter / increase count on
  non-permissible commands /

25
Algorithm (Contd.)

• ii. If counter tolerance_limit then
• A. If provision_for_future_changes in
  session_scope then
• B. Reset counter, go to Step 3
• C. Else Issue message to user to update
  session_scope
• D. If user_response YES then
• E. Compare new session_scope with original
  one
• F. If criteria not met then / see
  explanation below /
• G. Issue intrusion_signal, exit
• H. Else Reset counter, go to Step 3
• I. Else Issue intrusion_signal, exit
• iii. Else
• A. Go to Step 3

26
Observations

• Technique doesnt require huge audit data
• Flagging subjectID violation is straightforward
• Submission of session-scope requested at 1st
  login
• Session-scope once submitted is secure and not
  accessible to user
• Session-scope can be updated in later
• Revised session-scope is updated for certain
  criteria
• Reasonableness check
• Comparison of old and new session-scope files
• Careful examination may reveal user intentions

27
Illustration (Intrusion Scenarios)

• Detectable Situations
• Case 1 Both logins are legitimate
• User is expected to include the intent
• If no intent expressed, terminate as a security
  measure
• Case 2 1st login legitimate, 2nd one intrusive
• If user doesnt indicate multiple logins,
  intrusion flagged
• If multiple logins admitted initially, break-in
  becomes successful
• Intruder oblivious of the watchdog is likely to
  deviate from the legitimate users session-scope
  and detection becomes imminent

28
Illustration (Contd.)

• Case 3 Intruder logs in first, user joins later
• If intruder did not allow multiple logins,
  legitimate user denied service
• If multiple logins allowed, absence of a query
  may raise suspicion for cognizant user
• Non-cognizant user operation may result in
  deviation of masquerades session-scope and
  intrusion will be flagged
• Case 4 Both logins correspond to intrusions
• Intruder himself initiates multiple logins
• Two logins are due to different intruders
• The probability of this happening is small, but
  is similar to case 3

29
Enhancements

• Monitoring Sequences of Operations
• Compare assertion sequences with predetermined
  patterns for indication of possible abuse
• Voluntary Input of Updates to Scope file
• The user can submit changes to his plan on a
  need basis
• Too many update requests may be indicative of a
  problem
• On-the-fly Admittance of Multiple Logins
• Multi-level Counters

30
Outline of the Talk

• Introduction
• Traditional Approaches
• Concurrent Intrusion Detection
• Signature Analysis
• Overall Network Management Architecture
• Algorithm and Illustration
• Prototype Development
• Discussion
• Future Efforts

31
Implementation Objectives

• CIDS should not impact system performance
• Should not lead to poor quality of service to
  users
• Mapping of session-scope into a reasonable
  sprint plan
• Minimize false alarms
• CIDS itself should be hack proof

32
Watchdog Complex

User
Watchdog/User Interface
Watchdog/OS Interface
Session Scope
Software Agent
Converter
Inclusion Checker
Formatter
Sprint Plan
33
Design of Submodules

• Converter
• Session-scope Verifiable assertions
• Written in C
• Formatter
• Output of converter is given to the formatter
• Identifies and groups the individual parts of the
  subject, action, object and period
• Can also be used to generate sequences of
  operations of known intrusion scenarios
• Written in C

34
Software Agent

Watchdog/Agent Interface
Agent Database
Parser
Sprint Plan To Formatter
Execution Module
Agent/Agent Interface
35
Inclusion Checker

Site-specific details
Monitoring Unit
Preprocessor
Comparator
User Activity
Comparison Unit
SPRINT Plan
Violation Flag
Logic Unit
36
Run-time Monitoring Setup

37
Outline of the Talk

• Introduction
• Traditional Approaches
• Concurrent Intrusion Detection
• Signature Analysis
• Overall Network Management Architecture
• Algorithm and Illustration
• Prototype Development
• Application Environments Experiments
• Discussion

38
Two Test Environments

• University Research Environment
• Test cases can be derived from published
  descriptions of well known attacks
• Site specific test cases can be designed
• Both sequential and concurrent intrusions can be
  considered
• Bank Teller Usage
• User intent encapsulation is easy
• Expected to know what programs will be executed
• What files will be accessed, created, destroyed
• What time users will log off
• Whether users will require multiple sessions
• Traditional Approaches
• Concurrent Intrusion Detection
• Signature Analysis
• Overall Network Management Architecture
• Algorithm and Illustration
• Prototype Development
• Application Environments

39
The University Environment

• Session scope Presentation GUI

40
Screen Shots of the GUI

Pre-selected list of simulators
Programming
41
Session Scope and Sprint Plan Illustration

Session-scope
Action Part of Sprint-plan
42
Banking Application

• GUI driven
• File Watchdog integrated into the database
• System implementation is done in Java
• Database is custom made
• SQL queries are used to handle all the requests
  to access the information on the database
• JDBC is used for the connectivity of the banking
  system and the database

43
Virtual Banking Capabilities

• Access by manager to the teller in a bank
• Departments
• Bank operations, business banking,
  credit/lending, e-commerce, investment banking,
  monitoring
• Bank Operations
• Creating new accounts, opening existing accounts
• Supports a variety of accounts such as
  checking, savings, loan, mortgage
• Profitability analysis, generate reports
• System contains two databases and a transfer tool

44
Account Manipulation GUI

45
Virtual Banking Environment -Integrating CIDS

46
Experiments and Results

• Testing is done in 2 phases
• Performance Testing
• Functional Testing
• Main server on which CIDS is running is Sun Ultra
  Enterprise 450 Model 4400
• Clients are Sun Ultra 5 workstations
• Functional testing is application specific

47
Performance Testing

48
Functional Test - University Environment

• 10 different scenarios, in which different scopes
  for the sessions are specified by the user
• 10 different experiments performed on each
  scenario
• Example Scenario
• IRSIM, Veriwell, Hspice, Berkeley Tools, Test
  Bench, Magic, verilog, VHDL, vi, e-mail,
  browsing, UNIX A session time of 3 hrs is
  selected
• Size of the sprint plan generated by the
  watchdog 2.2 kB
• Experiment 1
• The victim (genuine user in this case) has a
  setuid shell script, located in /tmp and named
  setuid_script. The intruder creates a link to
  this script and then executes the script through
  the new name, which starts with a '-'

49
Results of Experiment 1

50
Summary of all 10 Experiments

51
Experiments on Banking Application

• Remote logins to the banking software from
  external locations are not allowed
• Scope file selected is specific to the intrusion
  scenario being simulated
• Misuse intrusions are the main focus
• All Intrusive activities are detected in all
  cases
• The counter values are arbitrarily chosen

52
Outline of the Talk

• Introduction
• Traditional Approaches
• Concurrent Intrusion Detection
• Signature Analysis
• Overall Network Management Architecture
• Algorithm and Illustration
• Prototype Development
• Application Environments Experiments
• Discussion

53
Discussion

• Features and Limitation
• Leveraging of successful concepts from elsewhere
  
• Potential for low latency detection
• Better assessment and faster restoration of
  service
• Not a replacement to other ID tools, but
  complementary
• Future Plans
• Network related issues, profiling, pattern
  generation
• Implementation in an isolated network
• Integration with EMERALD-like tools as a third
  party security module
• Scope file selected is specific to the intrusion
  scenario being simulated
• Misuse intrusions are the main focus
• All Intrusive activities are detected in all
  cases
• The counter values are arbitrarily chosen

54
Current Status

• Interrogation-based detection
• Quality of Service Vs. Security
• Pattern generation using the concept of fault
  trees (top-down approach)
• Developing a reasonableness check framework
• To assist in automating the sprint-plan
  generation
• To resolve ambiguity regions in intrusion
  detection
• Mathematical models using statistical methods
• Graduate Students
• Ram Chinchani, Suranjan Pramanik, Min Xu