Application Intrusion Detection

1. Application Intrusion Detection Anita Jones University of Virginia

2. Application Intrusion Detection rationale: application has richer structure & semantics than OS so, intrusion leaves a potentially more evident trail Challenge What is the nature of that rich semantics? How and when can you use it to detect intrusion? Can Appln. ID systems be substantially “stronger” than OS ID systems? Three approaches taken in this research project Review of Research Project Application Intrusion Detection

3. Develop & demonstrate a technique that enables determination of intrusions appropriate to appln. in a form that delivers a definition of sensors that can be embedded, & relations that can be computed by monitors to detect those intrusions so that, generic ID monitors can be injected into the appln. Code Work complete: Illustrated technique on two example systems Slides 4 - 26 Approach 1 - Unique Threats Application Intrusion Detection

4. Assume the Operating System as the basis Use what an OS knows about -- OS semantics users, processes, devices controls on access and resource usage Record events in the life of the OS Use OS audit records State of Practice OS Intrusion Detection Systems -- OS IDS Application Intrusion Detection

5. Anomaly Detection assume that behavior can be characterized statically -- by known, fixed data encoding dynamically -- by patterns of event sequences or by threshold limits on event occurrences (e.g. system calls) detect errant behavior that deviates from expected, normal behavior Misuse Detection look for known patterns (signatures) of intrusion, typically as the intrusion unfolds OS IDS - the two Approaches Application Intrusion Detection

6. Anomaly Detection Static: e.g. Tripwire, Self-Nonself Dynamic: e.g. NIDES, Pattern Matching (UNM) Misuse Detection e.g. NIDES, MIDAS, STAT Networks are handled as “extensions” I.e. Use same two approaches listed above Centralized: e.g. DIDS, NADIR, NSTAT Decentralized: e.g. GrIDS, EMERALD Few genuinely new approaches OS IDS - the two Approaches Application Intrusion Detection

7. Take a Checkpoint • An OS exists simply to manage resources • Systems exists to perform some application, with the OS merely as a support • Focus on the application, not the OS The problem is to distinguish abusive behavior in the context of the application -- possibly by a legitimate user Application Intrusion Detection

8. An OS IDSis inherently limitedby the semantics of the OS You can’t talk about something for which you have no words!

9. A Complementary Approach Assume that the OS IDS does its job. Use the semantics of the application as a further basis for detection of intruders Application Intrusion Detection App IDS

10. App IDS -- What’s Possible? • How do you define intrusion in the context of (in the semantics of) an application? • Can an intrusion be “seen”? • Seen in progress? • Can intrusive behavior be linked to users? • Is there a richer notion of history (of intrusion)? • Is there a richer notion of “abused system state”? Application Intrusion Detection

11. App IDS -- Guiding Questions • Opportunity – what types of intrusions can be detected by an AppIDS? • Effectiveness – how well can those intrusions be detected by an AppIDS? • Cooperation – how can an AppIDS cooperate with the OS IDS to be more effective than either alone? Application Intrusion Detection

12. Electronic Toll Collection hierarchical numerous devices distributed complementary device state values monitors external behavior accounting component Health Record Management non-hierarchical; modular no devices beyond controlling computer limited access in app’n bound by known physical & medical realities no financial component complex scheduling components Case Studies Application Intrusion Detection

13. Devices Toll Lane Tag Sensor Automated Coin Basket Toll Booth Attendant Loop Sensor Axle Reader Weigh-In-Motion Scale Traffic Signal Video Camera Electronic Toll Collection (ETC) • - Vehicle • Tag (Active/Passive) Application Intrusion Detection

14. ETC - Hierarchy Application Intrusion Detection

15. Need Analysis Technique • What intrusions make sense in app’n terms? • How do you derive them? • Is there a disciplined analysis approach that ensures that “all” intrusions are found? • Once an intrusion is defined, is there a way to monitor for it within the application? • Is there a relation to the OS, and information that it has? Application Intrusion Detection

16. Threat Categories Specific Intrusions Methods Relations ETC - One Approach • Start with the known threat categories • How can they be manifested in app’n terms • Define app’n specific intrusions • Determine method that abuser would use • Define relations based on app’n state values that can be the basis for monitoring method Application Intrusion Detection

17. Denial of Service Disclosure Manipulation Masqueraders Replay Repudiation Physical Impossibilities Device Malfunctions Threat Categories Application Intrusion Detection

18. ETC - Appl’n Specific Intrusions • Annoyance (3 methods) • Steal Electronic Money (10 methods) • Steal Vehicle (4 methods) • Device Failure (1 method) • Surveillance (2 methods) Threat Categories Specific Intrusions Methods Relations Application Intrusion Detection

19. 5 relations ETC Intrusion - Steal Service 3 methods Application Intrusion Detection

20. Health Record Management (HRM) • Components • Patient Records • Orders – lists of all requests for drugs, tests, or procedures • Schedule – schedule for rooms for patient occupancy, laboratory tests, or surgical procedures (does not include personnel) • Users • doctors, laboratory technicians, and nurses Application Intrusion Detection

21. HRM - App’n Specific Intrusions • Annoyance (4 methods) • Steal Drugs (1 method) • Patient Harm (6 methods) • Surveillance (2 methods) Threat Categories Specific Intrusions Methods Relations Application Intrusion Detection

22. HRM - Patient Harm Intrusion 6 methods 4 relations Application Intrusion Detection

23. Similarities detect intrusions by evaluating relations to differentiate between anomalous and normal behavior centralized or decentralized (hierarchical) similar threat categories Differences anomaly detection using statistical and rule-based app’n relations internal intruders/abusers event causing entity outside system resolution -- finer grain tightness of thresholds Relate OS IDS to App IDS Application Intrusion Detection

24. Dependencies OS IDS on App IDS None App IDS on OS IDS basic security services prevent abuser from bypassing application control to access application components Cooperation correlate audit/event record communication bi-directional request-response complications terms of communication resource usage - lowest common denominator Relate OS IDS to App IDS (cont’d) Application Intrusion Detection

25. Opportunity app’n semantics ARE a rich basis for detecting internal intruders (abusers) CAN (define &) detect intrusions not visible to OS intrusions more readily relate to real world! monitors similar: rule-based & statistical relations Effectiveness grain and units of resolution much richer tighter of thresholds less ambiguity of anomalous and normal behavior tied to semantics, and therefore to correctness Conclusion -- App IDS Application Intrusion Detection

26. Technique developed we have developed a systematic technique for analyzing application intrusion potentials repeatable requires deep understanding of the application Generic? -- yes and no analysis technique is generic threats are a combination of generic & appln. specific ID monitor software is generic however predicates for monitoring hand-crafted upgrades require re-evaluation Conclusion Application Intrusion Detection

27. Determine if OS type signatures (for ID monitoring) can be adapted to applns. Demo it. Explore variant of S. Forrest signatures based on OS system sequences Explore appln’s library calls Explore timing signatures Work will be complete by Spring: Final experiments to be completed Two papers to be completed Slides 28 - 39 Approach 2 - Signatures Application Intrusion Detection

28. Use app’s calls to it’s language library routines (e.g. C or C++ libraries) Unix system calls number about 190 C library routines number about 200 Comparable Build library call signature for applications wu-ftpd, apache httpd, …. Sig1: Library Call Sequences Application Intrusion Detection

29. Status Able to build robust database C library routines number about 200 Comparable Build library call signature for applications wu-ftpd, apache httpd, [Next app: mysql] App Calls to Language Library Application Intrusion Detection

30. Robust Database is Derived Application Intrusion Detection

31. Signature Length Has Little Effect Application Intrusion Detection

32. Detection Results (1/2) • Two buffer-overflow cases based on ftpd Application Intrusion Detection

33. Detection Results (2/2) • DOS case based on vi Application Intrusion Detection

34. Time sequences -- Monitor timing behavior sequences demarcated by application system calls or language library invocations Time sequences consist of time stamps the relative time between the system calls or the relative time within system calls (idle time of the monitored application may be excluded or not) Sig2: Time-based Signatures Application Intrusion Detection

35. Results (1) • Distribution of the temporal signature • Usually, the frequency distribution for the time stamp is a normal distribution. • Definition of robust database • High variance time stamps may be excluded. • After excluding high variance time stamps, the robust database should include more than 90%. Application Intrusion Detection

36. Typical Features of the Time Stamp • Frequency distribution of time stamps for a system call (length 10 sequence) • Exclude high variance: open; sequence case 11 Application Intrusion Detection

37. Results (2) • In the absence of intrusion • temporal signatures of applications are very similar • . . . under changes of environment, e.g., workload, the speed and throughput of the network used by the application • In the presence of intrusion • Certain buffer overflow intrusions cannot be detected using system call sequence as a signature. • Difference between the temporal signature of the intrusion and that of normal applications can be observed Application Intrusion Detection

38. Buffer Overflow Intrusion Detection • Compare system call signature to temporal signature • Only the latter can detect the intrusion Normal/buffer overflow Application Intrusion Detection

39. Conclusions -- Signatures • Applications have a rich surface structure when it is defined in its own terms -- not OS terms • I.e. signatures based on • calls to classic language libraries (e.g.C, C++) • timing sequences • We have demonstrated that the signatures are a basis for intrusion detection in appln.s Application Intrusion Detection

40. Immediate Milestones • Complete demo experiments/measurement on actual intrusion detection using • signatures based on language library calls, and • temporal signatures • Paper on each by Spring • “Temporal Signatures for Intrusion Detection” by Song Li & Anita Jones • “Intrusion Detection Using Library Calls” by Yu Lin & Anita Jones Application Intrusion Detection

41. Determine if it is possible (for some classes of appln.s) to define patterns of progress that can be monitored to ensure that the appln. is proceeding as expected Embed sensors on both control structure and data products Use prior work on appln. threat identification as start point Work will be complete by August 2001 See revised budget Slides 42 - 44 Approach 3 - Progress Patterns Application Intrusion Detection

42. Progress pattern: characterization of an appln. that highlights intermediate milestones as appln. makes progress to a conclusion, sometimes represented as a constructed data product E.g. alternative formulations: finite state machines fault trees . . . Challenge is to identify (& be able to detect the appln. moving through the milestones/stages Progress Patterns Application Intrusion Detection

43. Many military appln.s are cyclic -- they repeatedly perform a function or build a data product. E.g. construction of the air tasking order building a transportation convoy order (inventory) building a tank refueling operation for a suite of tank trucks Challenge: specify when and in what form “progress” can characterized and monitored Request to DARPA: Help us acquire the specifications for some military software system that will have progress patterns Appln.s with Progress Patterns Application Intrusion Detection

44. Progress Patterns: Immediate Milestones • Adapt the analysis technique developed earlier for threat determination (April) • Apply it to several applications to define progress for those applications (April, May, June) • Determine how to derive a generic-as-possible monitoring system to monitor for progress • what analysis tools (e.g. fault tree decision tools) can be used to derive the progress characterization? • embedding of sensors in code & on data • potential for generic monitor code • Document initial results (June) Application Intrusion Detection

45. Immediate DARPA Questions See Following Slides Application Intrusion Detection

46. Immediate Milestones • Complete demo experiments/measurement on actual intrusion detection using • signatures based on language library calls, and • temporal signatures • Paper on each by Spring • “Temporal Signatures for Intrusion Detection” by Song Li & Anita Jones • “Intrusion Detection Using Library Calls” by Yu Lin & Anita Jones Application Intrusion Detection

47. Immediate Milestones (cont) • Complete initial analysis of progress patterns • Acquire specifications of military system through DARPA • Apply progress pattern approach to several example systems • Milestones • Early analysis (April) • Case studies (April, May, June) • Final report and paper (August) Application Intrusion Detection

48. Exactly Who Works on Project • Faculty: Anita Jones • Graduate Research Assistants (full time graduate students) • Yu Lin • Song Li • Rick Li Application Intrusion Detection