Towards an Integrated Real-Time Intrusion Assessment and Recovery Framework for Network Management

1. Towards an Integrated Real-Time Intrusion Assessment and Recovery Framework for Network Management Shambhu J. Upadhyaya Dept. of Computer Science & Eng. SUNY at Buffalo Buffalo, New York, 14260 October 2000 (Research Supported by AFOSR, AFRL) Univ. at Buffalo, CSE Dept.

2. Focus of the Talk • Network Management Framework • Intrusion detection, response and recovery • Key Components • Assertions, data mining, profiling for intrusion assessment and analysis • Reasoning for security management • Undo/redo type recovery • Concurrent intrusion detection by encapsulation of user intent (Joint work with Kevin Kwiat, AFRL) Univ. at Buffalo, CSE Dept.

3. Outline of the Talk • Introduction • Traditional Approaches • Concurrent Intrusion Detection • Signature Analysis • Overall Network Management Architecture • Algorithm and Illustration • Prototype Development • Application Environments & Experiments • Discussion Univ. at Buffalo, CSE Dept.

4. Security or Fault Tolerance, Which One? • Fault Tolerance • 30 years ago, technology not at its best, failure very common • Von Neumann’s concept of redundant resources • Telecom, Space shuttle, Deep space probes built with stringent fault tolerance requirement • Today, email, disks, servers all come with dual resources • Despite state-of-the-art tools for design, FT is important • System complexity increases, new types of failures occur • Security • Failures are of different kind in this information age • Greed, fraudulent operations, spying, hacking for fun • Both share common features • Failure avoidance, tolerance Univ. at Buffalo, CSE Dept.

5. Cryptographic Techniques • Computer crime is certain to continue • Institute controls to preserve • Confidentiality, Integrity, Availability • Encryption is the most powerful tool • Strongly based on Information Theory • Heavily researched topic - RSA Scheme, Elliptic Curve • It doesn’t solve all the security problems • Need to develop counter-measures that would complement existing schemes Univ. at Buffalo, CSE Dept.

6. Intrusion Detection -Traditional Methods • Rule-based, Model-based, State transition-based techniques [Lunt 93] • All are based on audit-trail analysis • Passive, after-the-fact solutions • Some recent efforts are claimed to be real-time • Techniques that use audit-trail as the baseline approach cannot be real-time! Univ. at Buffalo, CSE Dept.

7. EMERALD • Event Monitoring Enabling Responses to Anomalous Live Disturbances • Deployed by SRI International (DARPA-funded) • Hierarchical, non-monolithic structure • Has a profile engine & signature analysis engine • Integrated P-BEST • Performs live traffic analysis of TCP/IP gateways • Claimed to be a gem • Largely audit-trail based! • Other efforts at GMU, Purdue, UC Davis, Companies Univ. at Buffalo, CSE Dept.

8. Control Flow Checking by Signature Analysis • Program pre-analysis • Generate control flow graph • Transient faults result in instruction bit errors and control flow errors • Verify control flow • Technique is based on sound principles • Error detection, correction codes Univ. at Buffalo, CSE Dept.

9. Our Approach to CID • Need a reference graph, but don’t have one • Generate one - Encapsulation of user intent • System queries users for a scope of session • An agent translates this into a set of verifiable assertions • Monitor run-time commands • Assess user behavior • Advantages • No need to sift through audit data • Both external and internal abuse can be handled uniformly Univ. at Buffalo, CSE Dept.

10. Preliminaries • Assumptions • LAN with access by UserID & Password submission • Communication with other processes by message passing • Intrusions - masquerading, legitimate user penetration, legitimate user leakage etc. Univ. at Buffalo, CSE Dept.

11. Definitions • Watchdog Monitor • Concurrent monitor of user commands (script or a macro) • Session Scope • Encapsulates user intent by means of a GUI • Verifiable Assertion • (subject, action, object, period) • Subject - A superID (loginID, IP address, tty no.) • Action - Operation performed (login, read, execute..) • Object - Receptor of action (files, programs, messages, records..) • Period - Time of usage of a command (absolute or relative) Univ. at Buffalo, CSE Dept.

12. Definitions • Sprint-Plan • Signature powered Revised Instruction Table is a collection of verifiable assertions • Also includes temporal sequences of operations • Attack • Actions whose purpose is to compromise the integrity, confidentiality, or availability of a resource • Intrusion • Deviations resulting in violation of security policy • Very difficult to judge Univ. at Buffalo, CSE Dept.

13. Flow Diagram of CID User Session Scope Plan Generator Sprint Plan Filter One-time effort Run-time monitoring Run-time Commands Assertion Generator Run-time Watchdog Monitor Tolerance limits, counters, Thresholds Intrusion Signal Univ. at Buffalo, CSE Dept.

14. Files Files Host N Master Monitor User level Profiler User level Profiler User level Profiler User Monitor 1 User Monitor n User Monitor n User Monitor n User Monitor 2 Task 1 Task n Task n Task n Task 2 Overall Architecture of Network Management Secure File Monitor Recovery Module Network level Profiler File Server Gateway, Router Bridge Local Area Network Host 1 Host 1 To Other Networks Master Monitor Master Monitor User Monitor 1 User Monitor 1 User Monitor 2 User Monitor 2 Task 1 Task 1 Task 2 Task 2 Univ. at Buffalo, CSE Dept.

15. Block Schematic of the Watchdog User Command Buffer Operating System Atomic Operation Generator Previously Generated Table of Verifiable Assertions Inclusion Checker Pattern Matching Unit Counter and Dialog Initiator Buffer Register To User Exception Generator Intrusion Signal to Master Watchdog Univ. at Buffalo, CSE Dept.

16. Algorithm • Two phases -- Initialization and Runtime op. • Steps of On-line Monitoring 1. Set monitor_rate, tolerance_rate, counter; 2. For all user_command_line do 3. Decode user_command_line into atomic operations; 4. If each atomic_operation in sprint_plan then a. No_Error, go to Step 3; 5. else a. If subject_ID_violation then i. Set intrusion_signal, exit; b. Else i. Counter++; /* increase count on non-permissible commands */ Univ. at Buffalo, CSE Dept.

17. Algorithm (Contd.) ii. If counter > tolerance_limit then A. If provision_for_future_changes in session_scope then B. Reset counter, go to Step 3; C. Else Issue message to user to update session_scope; D. If user_response YES then E. Compare new session_scope with original one; F. If criteria not met then /* see explanation below */ G. Issue intrusion_signal, exit; H. Else Reset counter, go to Step 3; I. Else Issue intrusion_signal, exit; iii. Else A. Go to Step 3; Univ. at Buffalo, CSE Dept.

18. Observations • Technique doesn’t require huge audit data • Flagging subjectID violation is straightforward • Submission of session-scope requested at 1st login • Session-scope once submitted is secure and not accessible to user • Session-scope can be updated in later • Revised session-scope is updated for certain criteria • Reasonableness check • Comparison of old and new session-scope files • Careful examination may reveal user intentions Univ. at Buffalo, CSE Dept.

19. Illustration (Intrusion Scenarios) • Detectable Situations • Case 1: Both logins are legitimate • User is expected to include the intent • If no intent expressed, terminate as a security measure • Case 2: 1st login legitimate, 2nd one intrusive • If user doesn’t indicate multiple logins, intrusion flagged • If multiple logins admitted initially, break-in becomes successful • Intruder oblivious of the watchdog is likely to deviate from the legitimate user’s session-scope and detection becomes imminent Univ. at Buffalo, CSE Dept.

20. Illustration (Contd.) • Case 3:Intruder logs in first, user joinslater • If intruder did not allow multiple logins, legitimate user denied service • If multiple logins allowed, absence of a query may raise suspicion for cognizant user • Non-cognizant user operation may result in deviation of masquerades session-scope and intrusion will be flagged • Case 4:Both logins correspond to intrusions • Intruder himself initiates multiple logins • Two logins are due to different intruders • The probability of this happening is small, but is similar to case 3 Univ. at Buffalo, CSE Dept.

21. Enhancements • Monitoring Sequences of Operations • Compare assertion sequences with predetermined patterns for indication of possible abuse • Voluntary Input of Updates to Scope file • The user can submit changes to his plan on a need basis • Too many update requests may be indicative of a problem • On-the-fly Admittance of Multiple Logins • Multi-level Counters Univ. at Buffalo, CSE Dept.

22. Implementation Objectives • CIDS should not impact system performance • Should not lead to poor quality of service to users • Mapping of session-scope into a reasonable sprint plan • Minimize false alarms • CIDS itself should be hack proof Univ. at Buffalo, CSE Dept.

23. Watchdog Complex User Watchdog/OS Interface Watchdog/User Interface Session Scope Software Agent Converter Inclusion Checker Formatter Sprint Plan Univ. at Buffalo, CSE Dept.

24. Design of Submodules • Converter • Session-scope Verifiable assertions • Written in C • Formatter • Output of converter is given to the formatter • Identifies and groups the individual parts of the subject, action, object and period • Can also be used to generate sequences of operations of known intrusion scenarios • Written in C Univ. at Buffalo, CSE Dept.

25. Software Agent Watchdog/Agent Interface Agent Database Parser Sprint Plan To Formatter Execution Module Agent/Agent Interface Univ. at Buffalo, CSE Dept.

26. Inclusion Checker Site-specific details Preprocessor Monitoring Unit Comparator User Activity Comparison Unit SPRINT Plan Violation Flag Logic Unit Univ. at Buffalo, CSE Dept.

27. Run-time Monitoring Setup Univ. at Buffalo, CSE Dept.

28. Two Test Environments • University Research Environment • Test cases can be derived from published descriptions of well known attacks • Site specific test cases can be designed • Both sequential and concurrent intrusions can be considered • Bank Teller Usage • User intent encapsulation is easy • Expected to know what programs will be executed • What files will be accessed, created, destroyed • What time users will log off • Whether users will require multiple sessions • Traditional Approaches • Concurrent Intrusion Detection • Signature Analysis • Overall Network Management Architecture • Algorithm and Illustration • Prototype Development • Application Environments • Discussion Univ. at Buffalo, CSE Dept.

29. The University Environment • Session scope Presentation GUI Univ. at Buffalo, CSE Dept.

30. Screen Shots of the GUI Pre-selected list of simulators Programming Univ. at Buffalo, CSE Dept.

31. Session Scope and Sprint Plan Illustration Session-scope Action Part of Sprint-plan Univ. at Buffalo, CSE Dept.

32. Banking Application • GUI driven • File Watchdog integrated into the database • System implementation is done in Java • Database is custom made • SQL queries are used to handle all the requests to access the information on the database • JDBC is used for the connectivity of the banking system and the database Univ. at Buffalo, CSE Dept.

33. Experiments and Results • Testing is done in 2 phases • Performance Testing • Functional Testing • Main server on which CIDS is running is Sun Ultra Enterprise 450 Model 4400 • Clients are Sun Ultra 5 workstations • Functional testing is application specific Univ. at Buffalo, CSE Dept.

34. Performance Testing Univ. at Buffalo, CSE Dept.

35. Functional Test - University Environment • 10 different scenarios, in which different scopes for the sessions are specified by the user • 10 different experiments performed on each scenario • Example Scenario: • IRSIM, Veriwell, Hspice, Berkeley Tools, Test Bench, Magic, verilog, VHDL, vi, e-mail, browsing, UNIX; A session time of 3 hrs is selected • Size of the sprint plan generated by the watchdog: 2.2 kB • Experiment 1: • The victim (genuine user in this case) has a setuid shell script, located in /tmp and named setuid_script. The intruder creates a link to this script and then executes the script through the new name, which starts with a '-' Univ. at Buffalo, CSE Dept.

36. Results of Experiment 1 Univ. at Buffalo, CSE Dept.

37. Summary of all 10 Experiments Univ. at Buffalo, CSE Dept.

38. Discussion • Features and Limitation • Leveraging of successful concepts from elsewhere • Potential for low latency detection • Better assessment and faster restoration of service • Not a replacement to other ID tools, but complementary • Future Plans • Network related issues, profiling, pattern generation • Implementation in an isolated network • Integration with EMERALD-like tools as a third party security module • Scope file selected is specific to the intrusion scenario being simulated • Misuse intrusions are the main focus • All Intrusive activities are detected in all cases • The counter values are arbitrarily chosen Univ. at Buffalo, CSE Dept.

39. Current Status • Interrogation-based detection • Quality of Service Vs. Security • Pattern generation using the concept of fault trees (top-down approach) • Developing a reasonableness check framework • To assist in automating the sprint-plan generation • To resolve ambiguity regions in intrusion detection • Mathematical models using statistical methods • Graduate Students • Ram Chinchani, Suranjan Pramanik, Min Xu Univ. at Buffalo, CSE Dept.