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

UCDavis SecLab MURI October 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.

UCDavis SecLab MURI October 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()

UCDavis SecLab MURI October Sample Responses

UCDavis SecLab MURI October 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

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

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

UCDavis SecLab MURI October 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

UCDavis SecLab MURI October 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

UCDavis SecLab MURI October 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

UCDavis SecLab MURI October 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

UCDavis SecLab MURI October 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: Work to be done –Formalizing response model –Implementing response on a spec-based IDS –Testing and evaluating performance –Applying response model to other systems