1 / 19

System Health and Intrusion Monitoring: A New Approach to Triggering Intrusion Tolerant Mechanisms (SHIM)

System Health and Intrusion Monitoring: A New Approach to Triggering Intrusion Tolerant Mechanisms (SHIM). Calvin Ko, NAI Labs , Network Associates Karl Levitt, UC Davis July 17, 2000. Technical Objectives. Continuous monitoring of the health of a system

garrick
Download Presentation

System Health and Intrusion Monitoring: A New Approach to Triggering Intrusion Tolerant Mechanisms (SHIM)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. System Health and Intrusion Monitoring:A New Approach to Triggering Intrusion Tolerant Mechanisms (SHIM) Calvin Ko, NAI Labs, Network Associates Karl Levitt, UC Davis July 17, 2000

  2. Technical Objectives • Continuous monitoring of the health of a system • Detect previously unseen intrusions with a low false alarm rate • Provide intrusion tolerant (IT) mechanisms with accurate and strategic information on the detected anomalies • Demonstrate via a prototype • First step towards total health monitoring of a large system NAI Labs-7/6/00-2

  3. Technical Approach - Overview • Employ a set of dynamic constraints to detect security failures • define healthy operations of a system • at different levels of abstraction (a hierarchy) • capture static behavior, dynamic behavior, time-critical behavior • A systematic methodology for development of constraints and placement of sensors • able to reason about and project between layers NAI Labs-7/6/00-3

  4. Technical Approach: Rationale • Checking is (in general) easier than doing (implementation) • Error/failures can be uncovered by simple checks • Recovery block acceptance test • Run-time result-checking (Blum) • sorting, graph-isomorphism, group-theoretic computation • Specification-based Intrusion Detection (Ko/Levitt, Sekar) • Access checking of security-critical programs NAI Labs-7/6/00-4

  5. Example Constraints • Privileged programs • e.g., finger daemon (fingerd) • read publicly readable files • execute finger program • write to the output socket • Router • conservation-of-flow in WATCHERS (out = in - dest) • route a packet only to a router “closer” to the destination • Database • DEMIDS: monitor users’ accesses to database • ARP - Address Resolution Protocol NAI Labs-7/6/00-5

  6. Address Resolution Protocol (ARP) • ARP • For mapping between the Ethernet layer and the IP layer • Hosts on the network query all machines for their Ethernet-to-IP assignments before sending to a new IP address. Hosts typically keep a local list of mappings ( the ARP cache ) to avoid repetitive queries • ARP Cache Poisoning • Unsolicited Response • Bogus Request • Bogus Response • Both a spurious Request and a spurious Response NAI Labs-7/6/00-6

  7. Unsolicited ARP Response • ARP reply will be accepted by a victim machine, even though it hasn’t sent a request. • Sending a arbitrary IP to Ethernet mapping will poison the victim’s ARP cache. • Sending an unsolicited response to the broadcast Ethernet address poisons the cache of all machines (Solaris, Windows, Linux). ARPREPLY to victim blanc.cs.ucdavis.eduIS-AT08:00:20:23:71:52 NAI Labs-7/6/00-7

  8. Bogus ARP Request • ARP implementations cache entries based upon broadcast requests. • Even if the host isn’t involved in any resolution their cache will update with the information contained in third-party requests. • Sending out an request with bogus sender information poisons everyone’s cache. ARPREQUESTWHO-HAS olympus.cs.ucdavis.edu TELL blanc.cs.ucdavis.edu at 08:00:20:23:71:52 NAI Labs-7/6/00-8

  9. alarm ARP Response ARP Response Bogus Request ARP Specification ARP Request ARP Response Initial reply_wait cached ARP Request ARP cache timeout NAI Labs-7/6/00-9

  10. Criteria of Constraints • Simple • Can be efficiently checked for violations (Checkable and Efficient) • Should not contradict with existing behavior • Able to adapt to different platforms/configurations and changes • Consistency/Correctness/Completeness NAI Labs-7/6/00-10

  11. A hierarchy of constraints at different levels of abstraction Data-integrity constraints Program-integrity constraints Interaction constraints Temporal constraints Resource-usage constraints System-level System Services Host-based Application Types of Constraints NAI Labs-7/6/00-11

  12. Security Policies Design Principles Attack or Vulnerability Models Normal runs Formal Analysis Intended Usage Configuration & System policy System Semantics Constraints Development Methodology Constraint Model NAI Labs-7/6/00-12

  13. Intrusion-Tolerance Triggers • Provide • information about rogue/faulty processes • objects being damaged or service disrupted • capability of the rogue processes • information to identify related constraint violations • Consequences if a constraint being violated • Associate capability of the rogue processes with constraints • Jigsaw language NAI Labs-7/6/00-13

  14. Challenges • Detect new attacks with a low false alarm rate • Hierarchical constraint development and refinement methodology • Efficient checking of constraints • Adapt to changing environment • Unified existing specifications • Model consequence of constraint violations NAI Labs-7/6/00-14

  15. Implementation • Constraint Specification • Use existing languages and extend when necessary • ESTELLE • Statechart (Harel) • Constraint Implementation • Translation to rules in • SNORT, NFR • NAI Generic Software Wrappers NAI Labs-7/6/00-15

  16. Expected Results • A systematic methodology for specifying constraints • A generic constraint model (for UNIX) that can be customized to different environments • Detect new attacks that cannot be detected by existing signature-based ID systems. • Intelligent placement of IT sensors • Provide accurate and strategic information to IT mechanisms NAI Labs-7/6/00-16

  17. Major Risks and Mitigation • Constraints not checkable • refine to lower level • extend the wrapper prototype • application auditing • Behavior of big systems very complicated • focus on critical components • focus on important security aspects • Constraints may not be able to detect intrusions • use existing attack/vulnerability models to test • revise the constraint model based on the experience NAI Labs-7/6/00-17

  18. Task Schedule Final Prototype & Demonstration Initial Prototype Task 2 Constraints for Unix Task 1 Months 12 24 NAI Labs-7/6/00-18

  19. Technology Transfer • Provide a public release of the software prototype • Work with NAI Labs Internal Research and Development Group to transfer technology to NAI products • Present results at NAI Labs semi-annual technology review to provide visibility NAI Labs-7/6/00-19

More Related