POC: Wayne Campbell 402-293-3967 campbell_wayne@prc.com

Traditional Indications and Warnings for Host

Based Intrusion Detection

Intrusion Detection Systems

• Network Based– external threat– commonly used

• Host Based– internal threat– 2% of corporate America uses– FBI survey - 86% had attacks by employees

Network Based IDS

• Packet Sniffer

• Signature or scenario based– historical protection– updated frequently

• Limited historical evidence

Host Based IDS

• Site specific– up front work required

• Analysis of audit or log data

• Real time or batch analysis

• Distributed processing

Indication and Warning Methodology

• Developed by military organizations

• Used to predict aggression by an enemy– extensive historical analysis– current trend analysis

• Repository of significant events

I&W Recent History

• Cold War

• United States Development– sophisticated alert system for tracking– determination of critical events

• Continuous analysis by experts– events and possible actions– prioritized and weigh events

I &W Warnings

• Multiple indicators are required to be triggered– sequence of events is irrelevant– indicators could set higher level indicators

• Warnings of potential– prediction, not fact– snap shoot in time, estimate

I &W Warnings (cont'd)

• Strategic Decision Makers– experienced analyst– big picture view

• Defined/recommended actions– I & W data– supporting data

War on Cyber Crime

• Use I&W techniques to predict behavior

• Techniques are used in post-attack research

• Post-mortem– determine attack characteristics– physical, social engineering, system level

• Security Indications and Warnings (SIW)

Security Indications and Warnings

• Premise - historical events, can be used as indicators current of activity.

• Host-based Intrusion Detection– why? audit log analysis– network based possible

• Not scenario matching

Indicators

• Event or group of events

• Historically important events

• Building blocks of SIW

• Non-critical events– alone inconsequential– example: large number of prints occurring

Indicators (cont'd)

• Hierarchical– lowest level

• barriers

• boundaries

– mid level• gauges (counters)

– top level• criteria and indicators

Event Categories

• Security Organization– written site policy– derived and stated

• Why? Ease of rule generation

• Suggested Minimum– Administrative Limited Usage– Role Specific Daily/Routine– Policy Limits

Event Categories (cont'd)

• Prioritize events per category

• Cost vs. Performance– more events

• slower response (volume)

• costlier (time/resources)

– limited events• threats undetected

– balanced, manageable level

Barriers

• A computer resource or process that when used, misused or compromised suggest that a security breach or operating system misuse may be occurring or has been attempted.– operating system specific– security relevant– example: .rhosts file

Boundaries

• A computer resource or process that when used, misused or compromised indicates that the site’s security policy or normal operating procedures may have been violated.– operating system or application events– defined within site policy– example: accessing a restricted directory

Barriers and Boundaries

• Clearly and unambiguously activated– computer trends– level of significance

• Response definition– barriers - may require aggressive actions– boundaries - further investigation

• Both need to be monitored

Level of Significance

• All events are not created equal– weighing occurs naturally– importance defines significance

• Site defines and sets

• Unique or unusual events– quickly raise attention of security

• Example: production vs. development

SIW Approach

• Security Policy

• Response definition

• Categorizing of events

• Prioritizing events

• Barriers and Boundaries

• Rule generation

• Levels of significance

Policy Statement #1

• No user shall have direct access to the prices files for job proposal submissions; access to theses files is only permitted via the corporate directed tools.– all price files are in /proposal/prices– corporate tool is PropGen– price files have a “.ppf” extension

Policy Statement #2

• No individual shall be able to assume another user’s identity on any production machine. On development machines, developers may assume the “root” role– IP range of dev. systems 192.12.15.[0-20]– no direct login as root is permitted– “root” can not change to a user’s ID

Policy Statement #3

• No user shall attempt to obtain root or administrative privileges through covert means.– prohibits attempts to get administrative

privileges– stolen password– buffer overflows– operating system specific weaknesses

Statement #1 Responses

• Assumptions– copying, removing of price file prohibited– reading of price files, except by PropGen is

prohibited.– accessing /proposal can be a sign of browsing

Statement #1 Responses (cont'd)

• Alert messages– Attempt to copy sensitive price schedules– Attempt to delete sensitive price schedules– Illegal access of the price schedules– Unauthorized browsing of restricted resources

Statement #2 Responses

• Assumptions– root log ins are not permitted

• Alert messages– Illegal root login– Unauthorized use of su() command– Root assumed a user’s identity– Unauthorized transition to a new user ID

Statement #3 Responses

• Assumptions– all acquisition of root privileges should be

made known to security personnel

• Alert messages– Illegal transition to root (buffer overflow)– Root shell attack has occurred– Undefined root acquisition

Defining Barriers

• Knowledgeable of basic system security– vulnerabilities– version specific data

• Know your system setup– What have you added? deleted?

Barrier Breakdown

• Audit daemon– primary barrier

• su() command– used to change effective UID

• Login Service– limits user log in capabilities

Barrier Breakdown (cont'd)

• /etc/passwd– user information

• Development systems– IP address specific

• Audit ID– unique identifier

Boundary Breakdown

• “ppf” files– contain price schedules

• /proposal directory– repository of company sensitive

• root privilege– limited to a few individuals

• PropGen application

Rule Generation

• Limitation of presentation paper– not all rules– not all circumstances

• Two step process– initial definition– refinement

Sample Rules

• Successful use of su() and “root” login at console– ba2 and ba3(root)

• Successful use of su() and you’re not a development machine– ba2 and not ba5

Sample Rules (cont'd)

• Successful use of su() and on the development platform and your current ID is not root– (ba2 and ba5) and not ba6(root)

Rule Threshold

• Numeric values as levels

• Trigger value assumption– ba2 = 5 ba3 = 1– ba5 = 4 ba6 = 3

• Level of Significance– SF = .25

Refined Equation

• ba2 and ba3 => 6

• ba2 and not ba5 => 9

• (ba2 and (ba5*SF)) and not ba6 => 12– allows 4 su() before alerting on development

systems– alert message severity level

Advantages

• Proven methodology

• Flexibility– levels of significance– prioritization of events

• Multiple levels - one to many relation

• Attack signature is not required

• Historical analysis

Disadvantages

• Number of possible enemies to monitor– traditional I&W had a few enemies– SIW has potentially thousands of enemies

• System requirements– memory– disk space

Summary

• Consistent with IDS requirements– warns of potential attacks

• Implementation– manual– automatic

• Guidance for security professional