A Comprehensive Approach for Intrusion Tolerance Based on Intelligent Compensating Middleware

1. DARPA BAA0015 Intrusion Tolerance A Comprehensive Approach for Intrusion Tolerance Based on Intelligent Compensating Middleware Amjad Umar Farooq Anjum Rabih Zbib Abhrajit Ghosh

2. Some Examples (from “Dark”) • Situation: XML “Trade Languages” in many industry segments based on a common DTD. DTD is used to validate the information being exchanged between trading partners. • Threat: Someone modifies the DTD (or DTD parser) so that every transaction becomes invalid • Situation: Pub/subscribe for Integration. Many organizations, such as JBI (Joint Battlespace Infosphere), are beginning to use publish/subscribe platforms. • Threat: someone damages/modifies the P/S channel • Situation: components (EJBs, CORBA components) are being positioned to develop many applications. Vendors are providing EJBs for industry segments (Financial). Components are “dropped in” to containers that provide security, transaction etc. • Threat: someone contaminates container disabling industry segments • Other examples: • “electronification” of supply chains • call agent for VOIP JBI web site: http://www.sab.hg.af.mil/archives/index.html

3. Background and Scope Motivated by • Army Fed Labs (ATIRP) -- Information distribution in battlefields • Ebusiness “Frontiers” - Extended enterprises, large scale integration • Telcommunications - OSSs, call agents • Common problem: getting uniformity out of non-uniformity (same COTS from same supplier with different capabilities at different sites) • What threats/attacks is your project considering • Focus on assault tolerance (“threat model”) • Vicious attack to damage/disable (attacks may be subtle) • Explore “dark points” (e.g., attacks on emerging COTS with heavy use) • What assumptions does your project make • Very knowledgeable attacker (can infer what you are relying on to conduct operations) • Knows your weak points (e.g., middleware stack) • What policies can your project enforce • Concentrate on “continue to operate as long as possible” and higher

4. Applications are increasingly relying on layers of technologies Intrusion Tolerance Trading Hubs, Large collaborative systems MS Office Web App E-Purchasing Higher Level Middleware (“Upperware”) Software Infrastructure EC Middleware General Purpose Middleware Operating Systems, DBMS,, Network Services (PSTN, IP, NGN,,)

6. Problem Statement and Approach Intrusion tolerant systems must, as stated in the BAA00-15 PIP, be able to • maintain the integrity of application data and programs • assure high availability under information attacks Our Approach: Attempt to address both issues a) For integrity of application data and programs, we attempt to provide • capabilities to make the application programs and data intrusion tolerant. • integrity of “behaviour of application” by assuring intrusion tolerance of middleware itself. b) For high availability, our focus is also on middleware since availability of network, hardware, and system software is discussed heavily elsewhere. .

7. Reality Check: How To Introduce Intrusion Tolerance in Middleware (any COTS) • Given: • a set of requirements R (e.g., intrusion/assault tolerance) • M middleware components are available (M > 200) • m middleware components (where m < M) that do not satisfy R • Find the most practical approach to satisfy R • Possible approaches: • Extend the non-conforming m middleware components to satisfy R (not doable). • Imbed the functionality in the applications (not advisable). • Build completely new middleware M’ (not advisable). • * Build intelligent compensating middleware (ICM) that provides the missing functionality and interworks with m through an open API

8. Intelligent Compensating Middleware for Intrusion/Assault Tolerance (Detailed View) FRS (Fragmentation, Replication, scattering) Applications Operational Knowledgebase ICM B1 A1 Scheduler C H-API Intrusion Triggers B2 COTS Middleware C IT Components . R, F, S, A . Encryption L-API A2 B3 C A3, C Network Services • Arrows A1, A2, A3 indicate Path A (ICM as a lower level service) • Arrows B1, B2, B3 indicate Path B (ICM as a higher level service) • Arrow C indicates Path C (ICM invoked by intrusion triggers in random order)

9. Policies (Specified in Operational Knowledgebase) Protection Policy (secrecy, IT) • Protection policies can be described for • applications (by users or system administrators) • middleware also (by system administrators) • Recovery Policies to specify level of recovery from intrusions Compensation Compensation Recovery policies can be inferred from Protection Policies and vice versa

10. An XML-CORBA Example Oracle Server Client Customer Information Applications IDL (XML) IDL (XML) • CORBA Services • Basic services (finding and invoking objects) • Thread services (create and manage threads) • Object life cycle services (create, destroy objects) • Naming services (facilitate portable names) • Others: Event, Trading, transactions, Persistence,, XML Support Middleware

11. ICM higher layer services Purpose: • Make application itself intrusion tolerant • Level of intrusion tolerance is specified by protection policies How will it work (example: FRSA specified) : • Startup: FRSA the application - data and DTD (one copy in highly secure site) • Normal runtime: keep updating FRSs (based on policy) • Under attack - indicated by triggers (recovery policy is “Continue under all conditions”): • No damage to application ; no action required (pass to monitor) • partly damaged - isolated (database destroyed, or DTD overwritten): use replicated database or DTD • partly damaged but unpredictable or severely damaged - attempt to rebuild/reconstruct. Give up with messages to roll back, restart

12. ICM lower layer services Purpose: • Make COTS middleware intrusion tolerant • Level of intrusion tolerance is specified by protection policies How will it work (example: CORBA =FRS, XML =E specified) : • Startup: FRS the CORBA middleware, encrypt XML middleware • Normal runtime: keep updating FRSs of CORBA and verifying XML • Under attack - indicated by triggers (recovery policy is “Continue as long as possible” and “graceful shutdown”): • No damage to middleware; no action required • partly damaged - identified (directory destroyed): restore replicated directory • partly damaged but unpredictable or severely damaged • for XML, send message, reload • for CORBA. • Switch to another middleware (e.g., MOM) to continue operation • ICM itself takes over completely in case of disasters (can send/receive info through an open API invoked through interceptors)

13. Operational Knowledgebase - Rules for operation Also contains what needs to be compensated where

14. Scheduler and Triggers • Scheduler: • Invoked by the triggers (subscriber) • consults the knowledgebase to determine what to do • invokes high level for app • invokes low level for middleware Operational Knowledgebase Intrusion Channel Publisher Subscribers Intrusion Triggers Scheduler H-API • detect intrusions • publish intrusions as events • No damage • Modified (isolated) • Modified (not isolated) • Disaster IT Components . R, F, S, A . Encryption L-API No damage Admnistrator

15. Intrusion Tolerant Components Redundancy Scattering Fragmentation Agents Others Encryption Core-ICM Middleware Use the EJB (CORBA Component) type model “Intrusion Tolerant Container” Components dropped in the container

16. Work Done So Far (since June 22) • Task 1: Impact Analysis • Several cases gathered about various newer COTS and possible threats • Task 2: Architecture Specification • Rough outline prepared • Task 3: Software prototyping • A simple prototype working (inherited from Army) • Compensates/adjusts for wireless/wired networks and network congestions • Examining how to extend it • Task 4: FRSA Evaluation • Quantify the level of intrusion tolerance achieved based on • Degree of Fragmentation • Degree of Redundancy • Degree of Scattering • Collaboration between Agents to achieve the given level of intrusion tolerance • The combined effect of FRS schemes and cryptographic schemes • Analytical models to evaluate tradeoffs ( • Task 5: Operational Management (optional) • Some initial thoughts (from OSSs)

18. Technology Transfer • Publicize the results of the work in academic/industrial conferences • Investigate the possibility of initiating an Intrusion Tolerance Task Force in OMG (we are already active members of the OMG Fault Tolerance Task Force) • Work with DARPA to identify potential transition to military customers. In particular, Army Research Lab, JBI, National Security Agency and CECOM • Leverage Telcordia’s industrial position to pursue the following avenues: • Work with some vendors to introduce the results of our research directly into the future COTS middleware. • Utilize the concepts and software produced by this research in building the future intrusion tolerant telecommunications operation support systems (OSSs). • Build intrusion tolerance as a consulting offer that will promote the practice of intrusion tolerance.

19. Risks and Issues • Difficult to keep up with emerging COTS (will have to be selective) • May have to change direction of research somewhat due to industry evolution (not sure about DARPA process) • Some spaces may be too dark for DARPA

20. Conclusions • Focus on : • Dependability from undependable COTS • Assault tolerance (“threat model”) • Explore “dark points” (e.g., attacks on emerging COTS with heavy use) • Approach: intelligent compensation to introduce IT on • applications • middleware • Main interest in building flexible architectures that can automatically adjust/compensate for missing functionalities in available COTS

21. Backup stuff

22. Middleware Definition: MIDDLEWARE is a set of common business/industry-unaware services enabling applications and end users to interact with each other across a network. It resides above the network and below the business-aware application software. Examples: email, Web, CORBA, distributed transaction processors, data replicators, workflow systems, collaborating systems More than 200 middleware packages (Gartner) Application Middleware Network Application Middleware Network USWeb Professional Certification Legacy Systems and the Web

23. Intelligent Compensating Middleware for Intrusion/Assault Tolerance (High Level View) Applications Operational Knowledgebase B1 ICM • Runs on trusted machines • Compensation at startup, normal runtime, intrusion recovery A1 C Intrusion Triggers B2 COTS Middleware A3 Publish intrusion events B3 A2 Network Services Intended for large scale systems Different levels of compensation needed at different sites