1. UCDavis SecLab MURI October 2002 1 Automated Intrusion Response Project Ivan Balepin, Karl Levitt UC Davis Computer Security Lab

2. UCDavis SecLab MURI October 2002 2 Why Study Automated Response? Immediate: contain the attack quickly –Kill the offending process –Slow down the attacker –Roll back to a safe state, etc. Cleanup - needs to be done carefully –Weighing cost of response against potential attack damage –High cost of false positives – can be used for DOS attacks Prevent the same attack from happening on this system –Report the attack to other security systems (firewalls, IDS’s, JIGSAW, HACQIT, etc). Long term: generalize the attack and warn others –Synthesize an attack signature and report it. –Deceive and study the attacker.

3. UCDavis SecLab MURI October 2002 3 Autonomic Responses: –not open –lock the file –delete the file –kill the process(es) –alert Complex Responses: –start a combination of response actions –start checkpointing –change permissions –reboot the system –block the user –slow down the process(es) –roll back –return a random result –perform a random action –operate on a fake file Example: Responses to open()

4. UCDavis SecLab MURI October 2002 4 Sample Responses

5. UCDavis SecLab MURI October 2002 5 Areas a Response Action Affects: –Data Integrity: deleting files, killing the process, etc. –Confidentiality: changing permissions, etc. –Availability: slowing down a process, disabling certain calls, etc. Level of a Response Action: –Single process –Group of Processes –User –Group –System –Network Categorizing Response

6. UCDavis SecLab MURI October 2002 6 Example: Selecting the Response System Spec-Based IDS System Spec-Based IDS System Spec-Based IDS Response Broker

7. UCDavis SecLab MURI October 2002 7 Example: Selecting the Response Incident Data: –Resources involved –Specs violated –Suggested responses System Spec-Based IDS Incident System Spec-Based IDS Incident Response Broker

8. UCDavis SecLab MURI October 2002 8 Example: Selecting the Response Incident Data: –Resources involved –Specs violated –Suggested responses System Data: –Resource ownership –Level of threat, etc. System Spec-Based IDS Incident Response Broker System Data

9. UCDavis SecLab MURI October 2002 9 Example: Selecting the Response Incident Data: –Resources involved –Specs violated –Suggested responses System Data: –Resource ownership –Level of threat, etc. Which Responses Satisfy our Rules? –Integrity –Confidentiality System Spec-Based IDS Incident Response Broker Security Principles: Integrity Confidentiality System Data

10. UCDavis SecLab MURI October 2002 10 Example: Selecting the Response Incident Data: –Resources involved –Specs violated –Suggested responses System Data: –Resource ownership –Level of threat, etc. Which Responses Satisfy our Rules? –Integrity –Confidentiality Pick the Least Costly One –Look at the whole chain –Estimate resources used: level hierarchy System Spec-Based IDS Incident Response Broker Security Principles: Integrity Confidentiality Respond

11. UCDavis SecLab MURI October 2002 11 Example: Selecting the Response Incident Data: –Resources involved –Specs violated –Suggested responses System Data: –Resource ownership –Level of threat, etc. Which Responses Satisfy our Rules? –Integrity –Confidentiality Pick the Least Costly One –Look at the whole chain –Estimate resources used: level hierarchy …or Pick the Least Costly Way to Preserve System Spec-Based IDS Incident Response Broker Security Principles: Integrity Confidentiality RespondPreserve

12. UCDavis SecLab MURI October 2002 12 Response: Project Plan Current progress –Defined the problem and the scope of study –Initial experiments with spec-based IDS’s: hard-coding response –Developing response hierarchy –Web page: http://wwwcsif.cs.ucdavis.edu/~balepin Work to be done –Formalizing response model –Implementing response on a spec-based IDS –Testing and evaluating performance –Applying response model to other systems