130 likes | 241 Views
•. Partha. Pal (PI). •. Bill Sanders. •. Jeanna. Gossett. •. Michael. Atighetchi. •. Tod. Courtney. •. Chris Jones. •. Vishu. Gupta. •. Paul. Rubel. •. James Lyons. •. Franklin Webber. •. Hari Ramasamy. •. Michel. Cukier. •. Idit Keidar. •. Mouna. Seri. •.
E N D
• Partha Pal (PI) • Bill Sanders • Jeanna Gossett • Michael Atighetchi • Tod Courtney • Chris Jones • Vishu Gupta • Paul Rubel • James Lyons • Franklin Webber • Hari Ramasamy • Michel Cukier • Idit Keidar • Mouna Seri • Anil Sharma (MIT/ Technion ) • Sankalp Singh Intrusion Tolerance by Unpredictable Adaptation (ITUA) Franklin Webber BBN Technologies
Outline • Technology Description • Assumptions • Attack and Defense Scenario • Results
Application-Level Intrusion Tolerance • Ability to operate through attacks • adaptive middleware • to coordinate defense • and manage resources • crypto to block most • direct attacks • on application • attacks exploit • security weaknesses • in the environment
ITUA Approach • Security domains • privilege in one domain not easily transferred to another • Multiple defense mechanisms • replication across security domains with decentralized management • dynamic firewalls • intrusion detection • Defense strategy (policy) to coordinate mechanisms • Range of adaptive response • rapid local reaction • global coordinated adaptation
Basic ITUA Architecture manager group manager manager manager manager manager manager IDSs IDSs IDSs IDSs IDSs IDSs Fire wall Fire wall Fire wall Fire wall Fire wall Fire wall replica replica replica replica replica replica replica replica replica replica group Security Domain Security Domain replica replica replica replica Security Domain Security Domain Security Domain Security Domain
ITUA Group Communication System • Byzantine intrusion-tolerant process-group abstraction • group membership • reliable delivery • total ordering • Implemented by modifying crash-tolerant C-Ensemble • removing implicit trust assumptions • authentication by public-key crypto • new microprotocol layers
Assumptions • Cryptographic keys and algorithms cannot be broken; • Some communication links may be broken, but the network is not systematically flooded; • Diversity in OSs and networks prevent concurrent infiltration of every security domain and guarantees, at worst, a maximum infiltration rate; • Intrusion detectors have a decent chance of detecting any infiltration of a security domain; • The application and ITUA implementation have no exploitable flaws (but any property of the ITUA design may be exploited!).
Scenario: The Attack • Attacker gains privileges by exploiting known OS and network vulnerabilities • may have privileges initially if insider • stealth preferred • Attacker uses “root” (or comparable) privilege to corrupt running application processes • preferably, malicious behavior to be triggered later • platform-specific modification of process • other corruption would be detected immediately
Scenario: The Defense • Defense eventually detects attacker • by intrusion detector • by incorrect process behavior • Defense adapts • killing bad application replicas • quarantining apparently bad security domains • starting new replicas in apparently good domains • Adaptive response is made unpredictable for the attacker • varying detection thresholds • varying response times • varying new replica placement
Scenario: The Outcome • Application has been moved away from the attack • some resources now unavailable • Defenses are in higher state of alertness • possibly reduced application performance • System administrators have been notified of attack
Results -- Prototypes • Prototype of application-level defense prior to ITUA • “Applications that Participate in their Own Defense (APOD)” • tolerates only crash failures • no use of unpredictability • Prototype of ITUA design • used to defend existing military software components: “Insertion of Embedded Infosphere Support Technologies (IEIST)” (shown at DARPA PI meeting) • DARPA Tech 2002 (upcoming)
Results -- Experiments • An image-server application defended with the APOD prototype was subjected to Red Team attack • Sandia Red Team • whiteboard analysis in late 2001 • hands-on attack in early 2002 • Replication management with dynamic firewalls forced the Red Team to use complex and persistent attacks to deny service from the application, with some cost to the attacker in time and exposure. • Corrupting any running application component to behave badly could have denied service, but Red Team decided this attack was harder than others.
Summary The ITUA defenses are designed to delay a broad range of attacks, completely surviving the undesirable effects of some of them: • attacks that start with insider privileges • attacks that gain privileges in stages, infiltrating new security domains • attacks that corrupt running components maliciously.