Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Applications that Participate in their Own Defense (APOD) Review Meeting 23 March 00 Presentation by: Franklin Webber, Ron Scott, Partha Pal, and Ron Watro {fwebber, rscott, ppal, rwatro}@bbn.com BBN Technologies Presentation to: Doug Maughan, DARPA/ITO 1 23 March 00 APOD Review Agenda Project Status (Franklin, 70 mins) – Overview, Application-Level Defensive Adaptation, Goals – QuO Middleware Support – Accomplishments, Work In Progress, Plans Software Demonstrations (Partha, 30 mins) – Redundancy Management Demo – Bandwidth Reservation Demo Discussion of Technical and Contractual Issues (20 mins) – Deliverables, Budget – Priorities (TIC Experimentation, NT, etc.) 2 23 March 00 APOD Review Long-term Vision More survivable systems, built with less effort. Future military systems need to be more survivable than the components from which they are built. These systems will be distributed, and will: – Assume that OS and network infrastructure is vulnerable to intrusion and cyber-attack; – Detect and classify a wide variety of attacks; – Adapt to these attacks in various ways, reasoning about which response mechanisms will best retain the system’s effectiveness. Such systems are defense-enabled, and need to be designed, implemented, operated, and maintained with less (or at least no more) effort than today’s non-defense-enabled systems. 3 23 March 00 APOD Review Adaptable, Defense-Enabled, Survivable Applications • Can proceed in the face of intrusions or denial of service and participate in their own defense • Provide means to specify various aspects of Quality of Service (QoS) • Have means to recognize when QoS is degraded, indicating a potential failure, intrusion, or attack • Provide alternate implementation and adaptation strategies: – Switch among different operating modes according to the severity of the attack; – Dynamically reconfigure to counter or avoid attacks; – Interact with QoS management subsystems and intrusion detection systems (IDSs) operating on their behalf. 4 23 March 00 APOD Review Application and Attacker Compete to Control Information, Resources, and QoS Application Attacker IDS 5 23 March 00 APOD Review CPU bandwidth Levels of Attacker Privilege •no privilege •“login shell” privilege •“root shell” privilege •application privilege Application privilege includes the ability to modify the application or start new application components. We assume attackers do not have application privilege. We use cryptographic techniques to try to enforce this assumption. BBNT successfully proposed work under DARPA 00-15 that will remove this assumption about application privilege. •“Intrusion Tolerance by Uncertain Adaptation” 6 23 March 00 APOD Review Project Goals • Formulate strategies for responding to attacks that threaten survival of applications. • Implement many response mechanisms in a middleware infrastructure (i.e., a software layer between the application and the resources). – Start with existing QuO (Quality of Service for Objects) framework and the QoS aspects it supports; – Extend QuO as necessary with application-centered strategies. • Test whether response strategies, implemented at both the application and middleware layers and using QuO mechanisms, enhance survivability. 7 23 March 00 APOD Review Why Put Defenses In Middleware? •practicality: •Requiring secure, reliable OS and network support is not currently cost-effective. •Middleware defenses will augment, not replace, defense mechanisms available in lower system layers. •simplicity: •QoS concerns separated from functionality of application. •Better software engineering. •uniformity: •Advanced middleware such as QuO provides a systematic way to integrate defense mechanisms. •Middleware can hide peculiarities of different platforms. •reuseability •Middleware should be application-independent. 8 23 March 00 APOD Review QuO Technology QuO is DARPA Quorum developed middleware that provides: •interfaces to property managers, each of which monitors and controls an aspect of the Quality of Service (QoS) offered by an application; •specifications of the application’s normal and alternate operating conditions and how QoS should depend on these conditions. QuO has integrated managers for several properties: •dependability (DARPA’s Quorum AQuA project) •communication bandwidth (DARPA’s Quorum DIRM project) •real-time processing (using TAO from UC Irvine/WUStL) •security (using OODTE access control from NAI) 9 23 March 00 APOD Review QuO Simplified DOC Model (CORBA) Client Logical Method Call ORB Proxy Object Application Developer ORB Proxy Mechanism Developer Obj Req Broker Obj Req Broker Network Client 10 23 March 00 APOD Review Network Server QuO adds specification, measurement, and adaptation into the distributed object model Logical Method Call Client SysCond Delegate Contract SysCond Contract ORB Proxy Delegate Mechanism/Property Manager ORB Proxy Mechanism Developer Specialized ORB Network 11 23 March 00 APOD Review QuO Developer SysCond Specialized ORB Client Application Developer SysCond SysCond SysCond SysCond Object Network Server The QuO Toolkit provides tools for building QuO applications Connector Setup Language (CSL) Contract Description Language (CDL) Structure Description Language (SDL) • Quality Description Languages (QDL) CORBA IDL Delegates Contracts Connectors Code Generators QuO Runtime – Support the specification of QoS contracts (CDL), delegates and their adaptive behaviors (SDL), connection, creation, and initialization of QuO application components (CSL) – QuO includes code generators that parse QDL descriptions and generates Java and C++ code for contracts, delegates, creation, and initialization • System Condition Objects, implemented as CORBA objects • QuO Runtime Kernel – Contract evaluator – Factory object which instantiates contract and system condition objects 12 23 March 00 APOD Review New APOD Requirements on QuO •Survivability-related constructs in QDLs •e.g., encryption strength •Coordination of different QoS aspects to support survivability •e.g., RT+FT+security •Security-related restrictions on use of QuO •e.g., different address spaces for different levels of trust 13 23 March 00 APOD Review A Classification of Defense Strategies Overcome Use QoS Management Use Gateways Use application level adaptivity Avoid Reserve Migrate replicas bandwidth, CPU Block IP Change sources protocols, ports Retry, use local calls 23 March 00 APOD Review Tighten access controls Strengthen encryption Choose Increase selfalternate server, checking degrade service Table is open to expansion: •more strategies •more columns 14 Guard APOD Implementation Path A series of software releases over the course of the project, showing increasingly strong defenses. •implement critical strategies first •implement easy strategies first Defenses incorporated into example applications. Supporting technology, e.g., languages, motivated by need to integrate defenses into applications easily. 15 23 March 00 APOD Review APOD Accomplishments to Date Software Release 0 •delivery December 99 •initial “proof of concept”; simple defensive strategies •air traffic monitoring application •bandwidth reservation defense strategy •redundancy management defense strategy Improved Redundancy Management •supporting technology developed under Quorum program •defense for much wider class of applications 16 23 March 00 APOD Review Example Application Air Traffic Monitoring: •tracking a single aircraft •sensor data fusion from multiple radars •user interfaces for display and administration A potentially mission-critical application •motivated by Air Force’s ATD with multiple QoS aspects •security •availability •performance previously used in Quorum Integration project •integration of OODTE access control with QuO 17 23 March 00 APOD Review Control Center Field Deployed attacker Map display Tripwire detects intrusion into admin credentials tripwire QuO restores credentials admin Admin privileges suspended after intrusion detected simulator sens1 sens2 Quo Contract QuO sets critical parameters to preset value Quo Contract attacker Map server 18 File sharing protocol 23 March 00 APOD Review publish database Attempt to insert fake data into the database is thwarted by OO-DTE Bandwidth Reservation Defense Strategy Threat: denial of service by network flooding Strategy: reserve bandwidth for application •use QuO technology developed under Quorum •depends on RSVP-enabled routers and ORBs Weakness: malicious attacker can also reserve bandwidth •need trusted RSVP? 19 23 March 00 APOD Review Redundancy Management Defense Strategy Threat: denial of service by crashing hosts or application processes Strategy: replicate processes; move replicas off of damaged hosts •redundancy management integrated with QuO delegates •all delegates linked in a logical ring •status information is circulated; a “software bus” •self-stabilizing: converges to agreement about status •self-repairing: crashed replicas are replaced •protected by OO-DTE (Quorum technology from NAI) •delegates use ring status for multicast Pro: easy to integrate OO-DTE access control; portable Con: only weak guarantees for communication in replica groups 20 23 March 00 APOD Review First Attempt at Integrating Replication with Access Control Client Client Client Logical Method Call Delegate Delegate Delegate Object Object Object Delegate Delegate Delegate Self-Stabilizing Software Bus ORBProxy Proxy ORB ORB Proxy ORBProxy Proxy ORB ORB Proxy ORB+OODTE ORB+OODTE ORB+OODTE ORB+OODTE ORB+OODTE ORB+OODTE Network Client 21 23 March 00 APOD Review Network Server Application Developer QuO Developer Mechanism Developer Using Quorum Technology for Dependability QuO technology developed for Quorum offers better redundancy management than that used in Software Release 0: •group communication using Ensemble (Cornell U) •membership services •synchronization •encapsulation in QuO Gateway •alternate transport-layer protocol •replica management using Proteus (U of Illinois) •several alternate failure models supported This architecture separates the programming of the application’s functionality from concerns about dependability (reliability and availability). 22 23 March 00 APOD Review QuO Gateways Support Specialized Communication Protocols and Below the ORB Mechanisms Client-Side ORB QuO Gateway QuO Gateway Control IIOP IIOP Glue Control Group Replication Bandwidth Reservation IIOP over TCP/IP (default) WAN 23 23 March 00 APOD Review IIOP Glue IIOP Server-Side ORB • The QuO gateway enables insertion of below-the-ORB mechanisms and specialized network controls • The gateway translates IIOP messages into specialized communication protocols or network level controls • To the client-side, the QuO gateway looks like the remote ORB • To the object-side, the QuO gateway looks like the client’s ORB • The two ends of the gateway are on the same LAN as the client/object • Currently, we have gateways that support Ensemble group communication, RSVP resource reservation, and IIOP over TCP/IP Quorum Dependability vs. Software Bus Technologies: Summary Software Release 0 included redundancy management based on the self-stabilizing software bus. This implementation offers some advantages but it lacks facilities for replica coordination needed in many applications. Future releases will use the Quorum dependability management technology, as it is more advanced and its replica coordination facilities will support a wider range of applications. 24 23 March 00 APOD Review Work In Progress Integrating security with Quorum dependability management •needed to protect against attacks that gain application privilege •OODTE won’t work in the current architecture •uses SSL, which is point-to-point, not multicast •Ensemble has own multicast security mechanisms •uses PGP •option: combine OODTE policies, Ensemble mechanisms •Blocking unauthorized TCP requests using Linux ip_chains •needed to counter some denial of service attacks •a readily available defense on a single platform 25 23 March 00 APOD Review Plans for Current Year •Integrate redundancy management with other QuO property managers (security, bandwidth mgmt) in a single application •Integrate multiple IDSs for complementary detection •currently only using Tripwire •considering Snort •Augment IDS information about possible attacks with application-level self-checking •Use adaptation other than property management: •graceful degradation of application functionality •change protocols dynamically •Create or adopt a language for specifying defense strategies •Run experiments at IA’s Technology Integration Center 26 23 March 00 APOD Review Integration Issues Integrating complementary defenses is necessary, but difficult. Different Platforms: Solaris, Linux, NT •SSL support for OODTE not available on Linux •RSVP only available on Linux •Dependability management not yet ported to NT •... Different ORBs: Visibroker, TAO •offer different program language bindings •nonstandard extensions Different QoS Aspects: security, RT, FT •inadequate theory for composition •technology immature or unavailable, e.g, FT+RT 27 23 March 00 APOD Review A Strategy Specification Language Short-Term Goal: describe defensive strategies abstractly •avoid hardwiring in property managers •allow non-APOD users to create own strategies easily •considering using Adage/Pledge to augment QuO’s existing QDLs Long-Term Goal: map high-level strategies to lower-level ones •generate some QDL automatically •generate instructions for non-QuO components, e.g. •configure IDSs dynamically using CIDF 28 23 March 00 APOD Review Validating Defenses by Experiment IA’s Technology Integration Center offers facilities and staff that could be used for running attacks against APOD defenses. We are trying to put an APOD experiment on the TIC’s agenda. •Proposal submitted Nov 99; favorably reviewed •Hypothesis: the application-level defensive adaptation in an APOD application significantly increases the work needed to damage or destroy that application •TIC staff has requested more information •detailed proposal plan needed •stand-alone or piggybacked on other IA work? •“countermeasure characterizations” likely needed •Experiment may be run during 2000 29 23 March 00 APOD Review Adaptive software raises several interesting issues for IA and security • Tradeoff between critical application survivability and system security – System security policy manager has ultimate authority over security issues – Critical applications that are adapting to survive must take priority over other applications • What security holes will adaptable frameworks, applications, and systems introduce – Can adaptation be exploited? – Will adaptation, measurement, and control APIs be exploitable? • If good guys can adapt, then so can bad guys – If our applications are adapting to make it more difficult to compromise them and to increase their chances for survival; – Can attackers adapt making it more difficult to detect them, defend against them, and recover from their attacks? 30 23 March 00 APOD Review Technical Summary A variety of software defense mechanisms, including property management and other support from QuO middleware, is being used to enhance the survivability of applications. Ideally, the effectiveness of these defenses will be tested by experiment at the TIC. 31 23 March 00 APOD Review Schedule Highlights • 7/99: Contract Start • 12/99: Software release 0 – Simple defense-enabled adaptive applications. • 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 (CIDFbased) to intrusion detection systems. • 11/01: Validation experiments • 11/01 - 7/02: Technology transfer software deliveries and integration as needed 32 23 March 00 APOD Review