POC: Wayne Campbell 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 –AdministrativeLimited Usage –Role SpecificDaily/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 [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 = 5ba3 = 1 –ba5 = 4ba6 = 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