1 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies Toolkit for Creating Adaptable Distributed Applications Joe Loyall “Adapt or perish, now as ever, is nature's inexorable imperative.” – H. G. Wells DARPA Intrusion Detection PI Meeting December 15-17, 1998

2 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 System Condition Objects QuO applications specify, control, monitor, and adapt to QoS in the system Application Alternate Implementations Contract (operating regions) Servers Network ORB Replication Mgr Resource Reservation Manager IDS 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 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

8 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies QuO adds specification, measurement, and adaptation into the distributed object model ClientNetworkServer Application Developer QuO Developer Mechanism Developer Logical Method Call Client Delegate ORB Proxy Specialized ORB Contract SysCond Object Delegate ORB Proxy Specialized ORB Contract Network Mechanism/Property Manager SysCond

9 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies The QuO Toolkit provides tools for building QuO applications 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 CORBA IDL Code Generators Code Generators Contract Description Language (CDL) QuO Runtime Structure Description Language (SDL) Delegates Contracts

11 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 region SUSPECT : // Transactions are taking a little long, but records have not been changed when (fileAddedOrDeleted == False) and ((TimeToCompleteTransaction > minTime) and (TimeToCompleteTransaction 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies 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 12/16/98DARPA Intrusion Detection PI Meeting BBN Technologies Where to find more information The Toolkit project To get the QuO Toolkit v.1.0 software, send mail to