POC: Wayne Campbell 402-293-3967 [email protected]
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