Traditional Indications and Warnings for Host Based Intrusion

Traditional Indications and Warnings for Host Based Intrusion Detection POC: Wayne Campbell 402 -293 -3967 campbell_wayne@prc. com

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 – Role Specific – Policy Limits Limited Usage Daily/Routine

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 Prop. Gen – 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. 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 Prop. Gen 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 • Prop. Gen 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 – ba 2 and ba 3(root) • Successful use of su() and you’re not a development machine – ba 2 and not ba 5

Sample Rules (cont'd) • Successful use of su() and on the development platform and your current ID is not root – (ba 2 and ba 5) and not ba 6(root)

Rule Threshold • Numeric values as levels • Trigger value assumption – ba 2 = 5 – ba 5 = 4 ba 3 = 1 ba 6 = 3 • Level of Significance – SF =. 25

Refined Equation • ba 2 and ba 3 => 6 • ba 2 and not ba 5 => 9 • (ba 2 and (ba 5*SF)) and not ba 6 => 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