Engineering a Distributed Intrusion Tolerant Database System Using COTS Components

1. Engineering a Distributed Intrusion Tolerant Database System Using COTS Components Peng Liu Lab. for Info. and Sys. Security http://www.liss.ifsm.umbc.edu/ University of Maryland Baltimore County July 2001

2. Motivation Authorized but malicious transactions reject Unauthorized transactions database damage Reference Monitor Authorized but malicious transactions can damage a database to useless !

3. Existing Practice: Database Assurance Authentication and access controlcannot prevent all attacks Integrity constraints are weak at prohibiting plausible but incorrect data Concurrency control and recovery mechanisms cannot distinguish legitimate transactions from malicious ones Automatic replication facilities and active database triggers can serve to spread the damage network

4. The Context From scratch Using COTS components Application or Transaction Level Our focus Our focus Trusted DBMS which protects data on un-trusted storage using signatures DBMS Level OS Level Trusted OS or trusted DBMS loader 1. Storage jamming 2. Signed hashes Hardware Tamper resistant processing environment Multi-layer Database Survivability

5. Technical Objectives Engineering using COTS components a database system that can survive authorized but malicious transactions Practical Database Intrusion Tolerance Our approach: using COTS DBMS as main building blocks Cost effective Database Intrusion Tolerance Our approach: multi-layer defense, cost-effectiveness-performance analysis Comprehensive Database Intrusion Tolerance Our approach: transaction-level intrusion detection, isolation & masking, damage confinement, assessment, and repair Adaptive Database Intrusion Tolerance Our approach: self-stabilization by adaptation

6. Assumptions & Policies What attacks are you considered? All and only the attacks through malicious transactions What assumptions are you making? The proposed ITS facilities are trusted The COTS DBMS executes transactions correctly What policies can your project enforce? New transactions execution control policy, i.e., stop, continue, or reduce speed Damage confinement policy, i.e., single-phase or multi-phase Intrusion detection policy, i.e., suspicion levels for malicious and suspicious trans Attack isolation and masking policy Self-stabilization control policy, i.e., the minimum integrity level etc.

7. Expected major achievements A cost-effective intrusion tolerant database system prototype A family of innovative database intrusion tolerance techniques Transaction-level intrusion detection Intrusion isolation and masking Multi-phase damage confinement On the fly damage assessment and repair (implementation) Adaptive database intrusion tolerance Optimized load balance among ITS facilities Identification and study of such ITS properties as adaptability, stability, and sensitivity

8. Our Approach

9. Installation

10. Scheme 1: preliminary intrusion tolerance User Transactions Damage Confinement Mediator (Policy Enforcement) Repair Transactions Intrusion detector Proofs COTS DBMS Damage Repairer Proof collector Damage Assessor

11. Transaction-Level Intrusion Detection • Our goal: applying existing intrusion detection techniques to identifying malicious transactions • Key issues: • semantics-based intrusion detection • proof collection • using the detector as a protection tool • coupling OS-level and transaction-level intrusion detection

12. Application-Aware Intrusion Detection Intrusion Detector Rule Registration Rule Definition rule base Function DLL Application Semantics trails Every existing ID algorithm can be specified by a rule Rules capture application semantics Active malicious transaction will be rolled back

13. Damage Assessment and Repair time The database A history B1 G2 G3 B1: read(x,z); write(x) G2: read(z); write(z) G3: read(x,y); write(y) x y z B1 Read-from G2 G3 A repair A dependency graph Undo B1 & G3 Our goal: implementation and evaluation

14. New Progress of Scheme 1 Since Feb 2001 The intrusion detector prototype is implemented (using ad-hoc rules) Scheme 1 was demonstrated on DISCEX II in June A new testing application is developed Till now Scheme 1 is implemented (except the damage confinement part) The prototype has around 20,000 lines of multi-threaded C++ code, running on top of a NT LAN and an Oracle server The prototype proxies every user transaction, collects the trails of transactions, detects bad transactions, rolls back active bad transactions, locates and repairs the damage (caused by identified bad transactions), all on-the-fly The prototype (except the intrusion detector) is tested and evaluated

15. Scheme 1: Publications 1. Peng Liu, Xu Hao, "Efficient Damage Assessment and Repair in Resilient Distributed Database Systems", Proc. 15th IFIP WG 11.3 Working Conference on Database and Application Security, July 15-18, 2001, Ontario, Canada. 2. P. Luenam, P. Liu, "ODAM: An On-the-fly Damage Assessment and Repair System for Commercial Database Applications", Proc. 15th IFIP WG 11.3 Working Conference on Database and Application Security, July 15-18, 2001, Ontario, Canada. 3. S. Ingsriswang, P. Liu, "AAID: An Application Aware Transaction-Level Database Intrusion Detection System", Technical Report, Dept. of Information Systems, UMBC, 2001.

16. A Limitation of Scheme 1 User SQL Commands Damage Confinement Mediator (Policy Enforcement) B1’s write sets G2’s write sets The purpose of confinement is to prevent damage from spreading The delay of damage assessment can cause ineffective confinement! Repair SQL Commands Intrusion detector B1 B1 Proofs Damage Repairer G4 Proof collector G2 Damage Assessor The database

17. Scheme 2: multi-phase confinement User SQL Commands Damage Confinement Mediator (Policy Enforcement) Phase 1 Repair SQL Commands Later phases Intrusion detector Proofs COTS DBMS Damage Repairer Proof collector Damage Assessor

18. Multi-Phase Confinement: An example To be confined: all data objects updated after time 5 except the data objects updated by G3 User SQL Commands Damage Confinement Mediator (Policy Enforcement) G3’s write set is clean B1 Repair SQL Commands Intrusion detector B1 B1[5] G4[15] Proofs Damage Repairer Proof collector G2[7] G3[9] Damage Assessor The database

19. Damage Confinement: A Spectrum Maximum damage leakage Zero damage leakage Maximum computing resources Minimum computing resources Minimum integrity Maximum integrity Maximum availability Minimum availability Approximate multi-phase Multi-phase One-phase

20. New Progress of Scheme 2 Since Feb 2001 The damage confinement subsystem is 70% designed and 70% implemented Till now The multi-phase damage confinement technique is developed P. Liu, S. Jajodia, “Multi-Phase Damage Confinement in Database Systems for Intrusion Tolerence”, Proc. 14th IEEE Computer Security Foundations Workshop, June 11-13, 2001, Nova Scotia, Canada

21. A Limitation of Scheme 2 • For accuracy, intrusions can be detected with a significant delay • The delay can cause serious damage when an intrusion is detected • Quicker detection can decrease the amount of damage, but could mistake many legitimate transactions for malicious, and cause denial-of-service t1 t2 An user’s history Attack enforced Attack detected The database • Our goal: decreasing the amount of damage without losing detection accuracy and denial-of-service

22. Scheme 3: Isolation User SQL Commands Damage Confinement Mediator (Policy Enforcement) Suspicious trans. Intrusion detector Main database Isolating engine 1 ... Isolating engine n Damage Repairer read Damage Assessor merge

23. New Progress of Scheme 3 • Since Feb 2001 • We have developed a SQL statement rewriting technique to enforce isolation in COTS DBMS • The isolation subsystem is 100% designed • The implementation of the isolation subsystem has started P. Liu, “DAIS: A Real-Time Data Attack Isolation System for Commercial Database Applications”, submitted to ACSAC 2001.

24. A Limitation of Scheme 3 • To reduce cost, very few users (i.e., one) can be isolated within a single engine • However, to avoid causing damage on the main database, the number of suspicious transactions can be large • Hence, isolating every suspicious transaction can be too expensive! • Our solution • Treating very suspicious and less suspicious users differently • Isolating very suspicious users • Masking less suspicious users • Advantage: better cost-effectiveness

25. Scheme 4: Masking User SQL Commands Damage Confinement Mediator (Policy Enforcement) Less suspicious trans. Very suspicious trans. Intrusion detector Masking engine 1 ... Isolating engine 1 Isolating engine n ... Main DB Damage Assessor Masking engine n Damage Repairer read merge

26. Intrusion Masking: An Example Three less suspicious users: Main history Masking history 1 Masking history 2 • Advantages: • Quicker recovery • Less cost clean T[i1] T[k1] T[j1] • If T[i1], T[j1], and T[k1] are all malicious, the main database is valid • If T[i1] and T[j1] are malicious, but T[k1] is not, then masking engine 2 is valid • If T[i1] and T[k1] are malicious, but T[j1] is not, then though none is valid, re-executing T[j1] on the main history can produce the valid database

27. A Limitation of Scheme 4 • Scheme 4 is not adaptive by nature • Adaptation can give better resilience and cost-effectiveness • There is no automatic way for the system to adaptively adjust its defense behavior according to: • the characteristics of recent and ongoing attacks • its current performance against these attacks • Although the SSO can dynamically reconfigure some of its components, manual reconfiguration operations are ad-hoc, not scalable, and prone to errors • Our goal: adaptive database intrusion tolerance

28. Scheme 5: Self-Stabilization • Self-Stabilization: the degree of data integrity should be able to be automatically stabilized within a tolerable range no matter how the system is attacked User SQL Commands Damage Confinement Mediator (Policy Enforcement) Tolerable range Intrusion detector The controller State variable feedback Damage Assessor Isolation engines Masking engines Main database Damage Repairer The database

29. Optimized Load Balance • Observation: • Different load configurations usually cause different cost-effectiveness • A load configuration can cause very different cost-effectiveness in different situations • An example of load configuration: • the percentage of isolated users • the percentage of masked users • the percentage of malicious users • the number of masking engines used • the average interval of state variable feedback • ... • Our goal: adaptive load configuration optimization • Mechanism:the controller can be responsible for this job

30. New Progress of Scheme 5 • Since Feb 2001 • We have investigated rule-based (adaptive) self-stabilization techniques • Some example self-tuning rules are produced • Overall

31. Metrics to measure success Cost time, space needed for tolerating intrusions Effectiveness how many intrusions are detected, isolated, or masked how many mistakes are made how effectively can the damage be confined how quick can the damage be assessed and repaired how well can the system be adapted availability: how often is a legitimate request rejected integrity: how well can data integrity be preserved under attacks Performance system throughput response time

32. Task Schedule

33. Technology Transfer Technical papers published in leading technical meetings and technical reports Release and dissemination of the prototype in source and binary forms Pursuing technology transition through major commercial DBMS vendors. The technologies can either be absorbed into their DBMS kernels, or be commercialized as intrusion tolerance wrappers Starting a company to commercialize the technologies and provide flexible services toarm customers' database systems with necessary intrusion tolerance facilities

34. Questions? Thank you!

35. Multi-layer representation of our approach