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

2. 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

3. Network Based IDS Packet Sniffer Signature or scenario based –historical protection –updated frequently Limited historical evidence

4. Host Based IDS Site specific –up front work required Analysis of audit or log data Real time or batch analysis Distributed processing

5. 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

6. 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

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

8. I &W Warnings (cont'd) Strategic Decision Makers –experienced analyst –big picture view Defined/recommended actions –I & W data –supporting data

9. 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)

10. 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

11. Indicators Event or group of events Historically important events Building blocks of SIW Non-critical events –alone inconsequential –example: large number of prints occurring

12. Indicators (cont'd) Hierarchical –lowest level barriers boundaries –mid level gauges (counters) –top level criteria and indicators

13. Event Categories Security Organization –written site policy –derived and stated Why? Ease of rule generation Suggested Minimum –AdministrativeLimited Usage –Role SpecificDaily/Routine –Policy Limits

14. 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

15. 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

16. 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

17. 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

18. 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

19. SIW Approach Security Policy Response definition Categorizing of events Prioritizing events Barriers and Boundaries Rule generation Levels of significance

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. Defining Barriers Knowledgeable of basic system security –vulnerabilities –version specific data Know your system setup –What have you added? deleted?

28. Barrier Breakdown Audit daemon –primary barrier su() command –used to change effective UID Login Service –limits user log in capabilities

29. Barrier Breakdown (cont'd) /etc/passwd –user information Development systems –IP address specific Audit ID –unique identifier

30. Boundary Breakdown “ppf” files –contain price schedules /proposal directory –repository of company sensitive root privilege –limited to a few individuals PropGen application

31. Rule Generation Limitation of presentation paper –not all rules –not all circumstances Two step process –initial definition –refinement

32. 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

33. 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)

34. Rule Threshold Numeric values as levels Trigger value assumption –ba2 = 5ba3 = 1 –ba5 = 4ba6 = 3 Level of Significance –SF =.25

35. 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

36. Advantages Proven methodology Flexibility –levels of significance –prioritization of events Multiple levels - one to many relation Attack signature is not required Historical analysis

37. 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

38. Summary Consistent with IDS requirements –warns of potential attacks Implementation –manual –automatic Guidance for security professional