towards an integrated real-time intrusion assessment and recovery framework for network management

Oct. 24, 2000 Univ. at Buffalo, CSE Dept. S. Upadhyaya-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)


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)


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


Security or Fault Tolerance, Which One? • Fault Tolerance

– 30 years ago, technology not at its best, failure very common

– Von Neumann’s 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


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 doesn’t solve all the security problems

• Need to develop counter-measures that would complement existing schemes

•


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!


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


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


Our Approach to CID• Need a reference graph, but don’t 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


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.


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)


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


Flow Diagram of CID

SessionScope

Plan Generator

SprintPlan

User

One-time effort

Run-time monitoring

Run-timeCommands

Filter

Intrusion Signal

Run-timeWatchdogMonitor

AssertionGenerator Tolerance

limits, counters,Thresholds


Overall Architecture of Network Management

Master Monitor

Host 1

UserMonitor

1

Task 1

UserMonitor

2

Task 2

UserMonitor

n

Task n

User level Profiler

Master Monitor

Host N

UserMonitor

1

Task 1

UserMonitor

2

Task 2

UserMonitor

n

Task n

File Server

User level Profiler User level Profiler

Master Monitor

Host 1

UserMonitor

1

Task 1

UserMonitor

2

Task 2

UserMonitor

n

Task n

Network level Profiler

Secure File Monitor

Recovery Module

Files Files

Local Area Network

Gateway, Router Bridge

To Other Networks


Block Schematic of the Watchdog

User CommandBuffer

OperatingSystem

Atomic OperationGenerator

Inclusion Checker

PreviouslyGeneratedTable of

VerifiableAssertions

PatternMatching Unit

Buffer Register

Counter andDialog

Initiator

ExceptionGenerator

To User

Intrusion Signal to Master Watchdog


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


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;


Observations • Technique doesn’t 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


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 doesn’t 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 user’s session-scope and detection becomes imminent


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


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


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


Watchdog Complex

User

Watchdog/User Interface

SessionScope

Converter

Formatter

Sprint Plan

SoftwareAgent

Inclusion Checker

Watchdog/OS Interface


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


Software Agent

Watchdog/Agent Interface

Parser

AgentDatabase

Execution Module

Agent/Agent Interface

Sprint Plan To

Formatter


Inclusion Checker

User Activity

Monitoring Unit Preprocessor

SPRINTPlan

Comparator

Comparison Unit

Logic Unit

Site-specific details

Violation Flag


Run-time Monitoring Setup


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


The University Environment• Session scope Presentation GUI


Screen Shots of the GUI

Pre-selected list of simulators Programming


Session Scope and Sprint Plan Illustration

Session-scope

Action Part of Sprint-plan


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

–


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

–


Performance Testing

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

No. of Users

Ave

rag

e l

oa

d/

min

ute

0

100

200

300

400

500

600

Sto

rag

e o

ve

rhe

ad

(kB

)

average load

storage overhead


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

–


Results of Experiment 1

Horizantally --- Login Cases User and User User and Intruder Intruder and User Intruder and Intruder

vertically ---- Scenarios and Catergories detection latency detection latency detection latency detection latency

1 User, No multiple logins FP 34 Yes 0 Yes 0 FN, 4 10

Scenario 1 1 User, with multiple logins FP 32 Yes 7 Yes 0 FN, 4 9

2 Users, No multiple logins FP 30 Yes 0 Yes 0 Yes 8

2 Users, with multiple logins FP 29 Yes 6 Yes 8 FN, 4 12

1 User, No multiple logins - - Yes 0 Yes 0 Yes 14

Scenario 2 1 User, with multiple logins - - Yes 12 Yes 0 FN, 3 11

2 Users, No multiple logins FP 40 Yes 0 Yes 0 FN, 3 21

2 Users, with multiple logins FP 38 FN, 3 16 Yes 7 Yes 14

1 User, No multiple logins - - Yes 0 Yes 0 FN, 3 9

Scenario 3 1 User, with multiple logins - - Yes 8 Yes 0 Yes 102 Users, No multiple logins FP 21 Yes 0 Yes 0 FN, 3 12

2 Users, with multiple logins FP 22 Yes 11 Yes 0 Yes 81 User, No multiple logins - - Yes 0 Yes 0 FN, 2 6

Scenario 4 1 User, with multiple logins FP 34 FN, 3 15 Yes 0 Yes 102 Users, No multiple logins - - Yes 0 Yes 0 FN, 2 82 Users, with multiple logins - - Yes 12 Yes 0 Yes 9


Scenario 5 1 User, with multiple logins - - Yes 5 Yes 0 Yes 5

2 Users, No multiple logins - - Yes 0 Yes 0 Yes 23

2 Users, with multiple logins FP 24 Yes 7 Yes 0 Yes 8


Scenario 6 1 User, with multiple logins - - FN, 2 12 Yes 9 Yes 11

2 Users, No multiple logins - - Yes 0 Yes 0 FN, 3 11

2 Users, with multiple logins - - Yes 11 Yes 0 Yes 12


Scenario 7 1 User, with multiple logins FP 45 Yes 0 Yes 0 FN, 4 24




Scenario 8 1 User, with multiple logins - - Yes 5 Yes 0 Yes 17

2 Users, No multiple logins - - Yes 0 Yes 0 Yes 16


1 User, No multiple logins FP 29 Yes 0 Yes 0 Yes 18

Scenario 9 1 User, with multiple logins FP 24 Yes 15 Yes 0 Yes 14

2 Users, No multiple logins FP 39 Yes 0 Yes 0 Yes 16



Scenario 10 1 User, with multiple logins - - FN, 3 24 Yes 0 Yes 22




Summary of all 10 Experiments

Summary 1 User, No Multiple Logins 1 User, With Multiple Logins 2 Users, No Multiple Logins 2 Users, With Multiple LoginsUser Detection 87.50% 78.60% 74.90% 91.90%and Latency 33.4 35 36.1 29User False Positives 12.50% 21.40% 25.10% 8.10%

False Negatives 0% 0% 0% 0%User Detection 98% 89% 100% 94.70%and Latency 0 11 0 9.6

Intruder False Positives 0% 0% 0% 0%False Negatives 2% 11% 0% 5.30%

Intruder Detection 99% 100% 98.20% 100%and Latency 0.4 0.7 0.6 0.5User False Positives 0% 0% 0% 0%

False Negatives 1.40% 0% 1.80% 0%Intruder Detection 56% 81.30% 77.40% 91.50%

and Latency 15.9 14.8 17 27Intruder False Positives 0% 0% 0% 0%

False Negatives 44% 18.70% 22.60% 8.50%


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


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

towards an integrated real-time intrusion assessment and recovery framework for network management

Documents

afrlwhy concurrent

network management shambhu

security problemsneed

recovery framework

fault tolerance30 years

space shuttle

white housefebruary

information theoryheavily