Toolkit for Creating Adaptable Distributed Applications

1. Toolkit for Creating Adaptable Distributed Applications Joe Loyall www.dist-systems.bbn.com/projects/OIT “Adapt or perish, now as ever, is nature's inexorable imperative.” – H. G. Wells DARPA Intrusion Detection PI Meeting December 15-17, 1998

2. Motivation for developing the QuO toolkit for survivable systems • Large scale information systems are vulnerable to attack • increasingly so because of their distributed, networked nature • Distributed object systems and wide-area networks offer increased chances of failure or attack • Most applications do not participate in their own defense, i.e., • they rely on intrusion detection systems, security systems, firewalls, etc. • they are blissfully unaware of ongoing attacks • Most large scale systems rely on a single implementation • they are unable to adapt to changes in their environment • they have little alternative to complete failure in the face of attacks or loss of service

3. Our goal: adaptable, intrusion-aware applications • Provide means for applications to specify their normal operating behavior • Provide means to recognize when an application is operating outside its normal range • Indicating a potential failure, intrusion, or attack • Provide alternate implementation and adaptation strategies • The application can reconfigure to avoid an attack or to proceed in the face of loss of service • Such an application would be more likely to survive hostile situations • Current distributed object systems do not provide the mechanisms and infrastructure necessary to support this • Any survivability is often ad hoc and intertwined throughout the application’s code

4. Examples of applications detecting intrusions and responding by adaptation • Example problems that could indicate intrusions and attacks • Responses from a server object become slower • Flooding of the network • Attacks on routers • Host attack, flooding or other denial of service • Virus in the object’s implementation or the host OS • An object starts returning incorrect responses, performing incorrect functionality, extra information, or less precision or accuracy • Virus in the object’s implementation or the host OS • Interception of data between the client and the object • Intrusion affecting a service used by the object • Example application responses: • Break connection and try to reestablish with reservation, different path • Reconfigure to use a server object which provides similar or identical service, but on a different host or with a different implementation • Continue with degraded service

5. Characteristics of an adaptable, intrusion-aware application • Specification • Normal operating behavior or ranges • Behavior or implementation alternatives and adaptation strategies • Measurement and control • Recognize when the application or environment is operating outside normal ranges • Interact with intrusion detection systems, resource managers, etc. operating on its behalf • Adaptation • Change operating modes to proceed despite loss of service, perhaps with degraded performance or functionality • Dynamically reconfigure to avoid further attacks or to restore service

6. The Toolkit for Creating Adaptable Distributed Applications • Two main goals • Develop a general Toolkit for building adaptable, intrusion aware applications • Apply the Toolkit to and demonstrate in the area of survivability, e.g., intrusion detection, response, security • This builds on the QuO technology developed under the Quorum program • Developed to support QoS-aware, adaptive applications • Applied to the areas of managed bandwidth and dependability • We are extending the concepts and applying them to survivability

7. Application Alternate Implementations Contract (operating regions) QuO applications specify, control, monitor, and adapt to QoS in the system Specification of normal and abnormal operating states, alternate implementations, and reconfiguration strategies using QuO’s QDL • Multiple layers of reconfiguration • managers and mechanisms can adapt to changes in the system • QuO contracts provide another layer of adaptation • Client and user can also adapt System Condition Objects • System condition objects monitor QoS in the system • system condition objects recognize changes in the system and notify the contracts that observe them • QuO contracts notify client programs, users, managers, and other system condition objects through transition behavior • Mechanisms and managers control QoS in the system • a layer below QuO that provides ORB-level services, such as security, replication, or managed communication • contracts and delegates interface to these services through system condition objects Replication Mgr IDS Resource Reservation Manager ORB Network Servers

8. Contract Contract Network QuO adds specification, measurement, and adaptation into the distributed object model Logical Method Call Application Developer Client Object SysCond SysCond Delegate Delegate SysCond SysCond SysCond QuO Developer SysCond SysCond ORB Proxy ORB Proxy Mechanism/Property Manager Mechanism Developer Specialized ORB Specialized ORB Client Network Server

9. We are extending the QuO components to develop the survivability toolkit • Contracts summarize the possible states of QoS in the system and behavior to trigger when QoS changes • Contract regions represent ranges of normal operating behavior • We have extended the region predicate language to permit the description of broader ranges of behavior • Transitions specify behavior to trigger when the active regions change • Have developed a specification language for describing adaptive behavior alternative and adaptation strategies • Supports runtime decision making, e.g., the selection between methods or remote objects • Enables runtime reconfiguration, e.g., bindings to remote objects to be severed and new ones (to different objects or through different paths) to be established • System condition objects are used to measure and control system resources and managers • Can interface to intrusion detection systems, mechanisms, and resources

10. The QuO Toolkit provides tools for building QuO applications CORBA IDL Contract Description Language (CDL) Code Generators Structure Description Language (SDL) Contracts Delegates QuO Runtime • Description Languages (QDL) • Support the specification of contracts (CDL), delegates and their adaptive behaviors (SDL), connection, creation, and initialization of application components (ConnDL) • The toolkit includes code generators that parse QDL descriptions and generate Java and C++ code for contracts, delegates, creation, and initialization • QuO Runtime Kernel • Contract evaluator • Factory object which instantiates contract and system condition objects • System Condition Objects, implemented as CORBA objects

11. The QuO Toolkit provides tools for building adaptive applications • Quality Description Languages (QDL) • Analogous to CORBA’s Interface Description Language (IDL) • Support the specification of • QoS contracts • delegates and their adaptive behaviors • connection, creation, and initialization of QuO application components • QuO includes code generators that parse QDL descriptions and generates Java and C++ code for contracts, delegates, creation, and initialization • QuO Runtime Kernel • Contract evaluator • Factory object which instantiates contract and system condition objects • System Condition Objects • Implemented as CORBA objects • We have a growing library of system condition objects for reuse

12. CDL contract to recognize problems in a banking system contract BankContract( syscond FileCounterSC FileCounterSCImpl fileAddedOrDeleted, callback ClientCB clientCallBack ) is syscond probe TimeProbeSCImpl TimeToCompleteTransaction(); active regions are region NORMAL : // Transactions are taking normal time and records have not been changed when TimeToCompleteTransaction <= minTime and fileAddedOrDeleted == False => region SUSPECT : // Transactions are taking a little long, but records have not been changed when (fileAddedOrDeleted == False) and ((TimeToCompleteTransaction > minTime) and (TimeToCompleteTransaction < maxTime)) => region INTRUSION: // Transactions are taking much too long or records have been changed when (TimeToCompleteTransaction >= maxTime) or (fileAddedOrDeleted == True) => transitions are transition any->NORMAL : clientCallBack.toNormal(); transition any->SUSPECT : clientCallBack.toSuspect(); transition any->INTRUSION : clientCallBack.toIntrusion(); end transitions; end active regions; end BankContract;

13. SDL code that chooses behavior based upon whether an intrusion is suspected delegate behavior for Bank and BankContract is call withdraw : region NORMAL : pass_through; region SUSPECT : pass to withdraw_with_logging_on; region INTRUSION : throw BANK_SERVER_COMPROMISED; default : pass_through; call deposit : region NORMAL : pass_through; region SUSPECT : pass to deposit_with_logging_on; region INTRUSION : throw BANK_SERVER_COMPROMISED; default : pass_through; call identify : default : pass_through; call balance : default : pass_through; return withdraw : default : pass_through; return deposit : default : pass_through; default : pass_through; end delegate behavior; • SDL currently supports choosing between methods, run-time binding, and embedded Java or C++ code.

14. The QuO toolkit provides an interface between applications and mechanisms, e.g., IDSs • The QuO toolkit provides a standard interface, i.e., contracts, delegates, and system condition objects, between applications and the mechanisms working on their behalf • IDSs and other mechanisms often have proprietary interfaces and different data formats • The QuO toolkit middleware can present a common interface to all the different IDS interfaces • QuO supports the building of applications that run in different survivability modes, from paranoid to intrusion unaware, and can switch among these at runtime • This is complementary and consistent with other DARPA efforts, e.g., CIDF • CIDF provides a standard interface between IDS components (which lie below the middleware layer) • The QuO Toolkit provides a standard interface between applications and the components at the CIDF layer

15. Interfacing with intrusion detection mechanisms • We are working with the University of Illinois to apply fault detection mechanisms to intrusion detection and response within the QuO toolkit • UI has a dependability manager, Proteus, that provides replication, fault detection, and recovery (i.e., restarting replicas) • Proteus’s fault detection and recovery occurs without the awareness of the application • Many of the faults that Proteus detects could be indications of attacks, e.g., timing faults, host failure, value faults • UI and BBN are working to “open up” Proteus’s implementation • Proteus will report faults to the middleware • Proteus will try to gather information about fault patterns and causes • Application and middleware (the QuO toolkit layer) will provide input to Proteus to control its recovery

16. Other interface possibilities • Odyssey Research Associates • Performing research in computer immunology • Identify patterns of normal usage and recognize when a system is operating outside normal regions • MIT • Model Based Troubleshooting • TIS/Network Associates • DTEL++ and OO-DTE

17. Summary • Intrusion-aware, adaptable applications can participate in their own defense • Can proceed in the face of intrusions or denial of service • Can provide inputs to aid intrusion detection mechanisms • Can run in different survivability modes and can switch among these at runtime • The QuO Toolkit is providing an environment for developing intrusion-aware, adaptable applications • Standard, reusable components instead of ad hoc and intertwined code • Standard interfaces to a variety of mechanisms • Hides heterogeneity and distribution problems; application can adapt and reconfigure for changing system conditions

18. Where to find more information • The Toolkit project http://www.dist-systems.bbn.com/projects/OIT • To get the QuO Toolkit v.1.0 software, send mail to jloyall@bbn.com mberman@bbn.com