1 / 11

Applications That Participate In Their Own Defense

Applications That Participate In Their Own Defense. Kickoff Meeting 6 October 1999 Ron Scott Franklin Webber Partha Pal BBN Technologies. Long-term Vision.

doli
Download Presentation

Applications That Participate In Their Own Defense

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. Applications That ParticipateIn Their Own Defense Kickoff Meeting 6 October 1999 Ron Scott Franklin Webber Partha Pal BBN Technologies

  2. Long-term Vision We need the capability to construct distributed systems that are more survivable than the components from which they are built. These systems will: • Detect and classify a wide variety of cyber-attacks; • Adapt to these attacks in various ways, reasoning about which response mechanisms will best retain the system’s effectiveness. More survivable systems, built with less effort. • We want to design, implement, operate, and maintain these systems with less (or at least no more) effort than today’s non-defense-aware systems.

  3. First Steps TowardAchieving the Vision • Let’s identify a subset of our needs that can profitably be attacked in middleware, as a way of beginning to achieve this vision: • A middleware infrastructure that integrates with a wide variety of intrusion detection systems. • A middleware infrastructure that enables a wide variety of defensive responses. • A means for system developers to specify response strategies to be used by applications.

  4. Why Middleware? • enhance survivability without requirement for secure, reliable OS and network support • heterogeneity Our goal is not to replace defense mechanisms in lower system layers but to augment them.

  5. Adaptable, Defense-Aware, Survivable Applications • Can proceed in the face of intrusions or denial of service and participate in their own defense • Provide means to specify their normal and alternative operating behavior • Have means to recognize when operating outside their normal range • Indicating a potential failure, intrusion, or attack • Can provide inputs to aid intrusion detection mechanisms • Provide alternate implementation and adaptation strategies • Can run in different survivability modes and can switch among these at runtime • Dynamically reconfigure to avoid further attacks orto restore service • Interact with resource managers operating on their behalf

  6. Project Goals • Formulate strategies for responding to cyber-attacks that threaten survival of applications. • Implement response mechanisms in a middleware infrastructure. • Start with existing QuO (Quality of Service for Objects) framework. • Extend QuO as necessary. • Test whether response strategies, implemented at both the application and middleware layers and using QuO mechanisms, enhance survivability.

  7. Contract Contract Network QuO adds QoS control and measurement into the DOC remote method call Logical Method Call Application Developer Client Object SysCond SysCond Delegate Delegate SysCond SysCond SysCond Qosketeer SysCond SysCond ORB Proxy ORB Proxy Mechanism/Property Manager Mechanism Developer Specialized ORB Specialized ORB Client Network Server

  8. Expected Results • A model or models of intrusion, stating assumptions about an attacker’s capability and permitting reasoning about the effectiveness of responses. • Analogous to failure models in FT theory • A library of response mechanisms, some general, some application-specific. • A language or languages in which developers can specify application-specific response strategies. • Example applications and attack scenarios that demonstrate the response mechanisms.

  9. In Progress • Design of an assertion-checking mechanism • aid to intrusion detection at application level • integrated with existing QuO middleware • Design of an initial test application, with response strategies • Air Traffic Control application, taken from Quorum Integration project and driven by Air Force’s ATD • Simple intrusion model, e.g., “crash failure after detection and delay” • Simple response strategy, e.g., “migrate replica to safer host”

  10. Plans • Validate the effectiveness of response strategies • Analysis: show a given response tolerates all attacks within a given intrusion model • Experiment: run tests at Technology Integration Center • understand the interactions between multiple intrusion detection systems and multiple response strategies. • Use supporting technology • fault tolerant replica coordination • AQuA/Proteus/Ensemble • Totem • intrusion detection systems • Broaden the class of applications as well as the classes of failure models and response strategies.

  11. Schedule Highlights • 7/99: Contract Start • 12/99: Software release 0 • A demonstration of a simple defense-aware adaptive application, as a proof of concept. • 7/00: Software release 1 • Initial integration with existing (COTS or from other DARPA researchers) infrastructure components. • 11/00: Initial validation experiments • 7/01: Software release 2 • Expanded defense strategies; potential feedback (CIDF-based) to intrusion detection systems. • 11/01: Validation experiments • 11/01 - 7/02: Technology transfer software deliveries and integration as needed

More Related