Properties of Current Response Systems

1. A Network-based Response Framework and ImplementationMarcus Tylutki and Karl Levitttylutki@cs.ucdavis.edu

2. Properties of Current Response Systems • Limited Scope • Attacks • Responses • State • Policy • Feedback control is not used for sensor retargeting or for response

3. Modeling Language Components • Event Instance • Describes ongoing and past events • Event Class • Template and Classification for Event Instances • Rule • Describes how Event Instances can match to create new Event Instances

4. Modeling Language • Policy • Policy violations are types of Event Classes • Rules define how policy violations are generated • E.g., if 5 or more identical filesystem types are compromised within 5 minutes, then an unknown worm policy violation is created. • State Assessment Values (SAVs) • State • E.g., Filesystem Event Class with member attributes: host, filesystem type, compromised, etc.

5. Modeling Language (cont’d) • Attacks • E.g., Buffer Overflow Event Class with member attributes source host, target host, target service, target port, buffer overflow type, etc. • Responses • E.g., Recover Filesystem Event Class with member attributes target host, target filesystem type, backup host, backup partition, etc. • Grouped into recovery, prevention, or both

6. Agent Topology

7. Agent Communication • All communication via XML documents • IDS Alerts → XML Documents → Event Instances • Similar to CIDF/IDMEF, but with a broader scope • Describes policies, responses, vulnerability profiles, etc. • Sensors and responses can be simulated or real • Real sensors require translation into XML Alert documents • Real response systems must translate into XML Response documents

8. How are sensors integrated? • Each sensor configuration (C) detects a set of Event Classes (ECs) • Each Event Class has a list of detection thresholds that must be satisfied • Each sensor configuration has a resource cost

9. What does the response agent do? • Alert → Event Instance → Policy Violation • Prevent and Recover along a path • All nodes in path must be recovered • End of path must be prevented • All paths are tested • All response combinations are tested • The optimal response set wrt state is sent to host agents • State is assessed by

10. How is preemption handled? • Partial rule matches → Detection threshold additions

11. Experiment Setup (Sensors) • Host-based integrity IDS (e.g., Tripwire) • Varying timeliness configurations (5 min. – 12 hrs.) • All configurations provide a low FPP and FNP. • Host-based anomaly IDS • Sliding window of 5-90 seconds. • Larger windows have a lower FPP/FNP. • Network-based signature IDS (e.g., Snort) • On or off

12. Experiment Setup • Worm speeds tested: • Fast: one scan per 5 μs • Medium: one scan per 50,000 μs • Slow: one scan per 80,000 μs • Number of nodes tested: • 7 nodes for most trials (~.02s) • 15, 31 node tests for scalability (~.28s, ~2.5s) (.7s) • Vulnerability density of 0.5 (3 nodes vuln) • Raised to .83 for sensor retargeting testing

13. Fast Worm Results (Avg.)

14. Medium Worm Results (Single)

15. Future Work • Allow for ‘black box’ computations in place of rules to represent other response systems or intrusion detection systems. • Probabilistic assessment of a response system.

16. Future Work (cont’d) • Responses tied to rule conditions rather than event classes. • Bayesian inferencing for FPP/FNP calculation.