Engineering a Distributed Intrusion Tolerant Database System Using by akm33296

VIEWS: 24 PAGES: 35

									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
                                          1
Motivation

                    reject            Authorized but
     Unauthorized                     malicious transactions
     transactions




               database

                                                      damage


                       Reference Monitor

  Authorized but malicious transactions can damage a database to
  useless !                                                        2
Existing Practice: Database Assurance

•Authentication and access control cannot 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




                                                             3
The Context
                      From scratch                Using COTS components

Application or
                          Our focus                   Our focus
Transaction Level


DBMS Level          Trusted DBMS which
                    protects data on un-trusted
                    storage using signatures
OS Level            Trusted OS or trusted            1. Storage jamming
                    DBMS loader                      2. Signed hashes

 Hardware           Tamper resistant
                    processing environment




               Multi-layer Database Survivability
                                                                          4
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                      5
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.
                                                                                    6
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



                                                                7
Our Approach




               8
Installation




               9
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


                                                            10
Transaction-Level Intrusion Detection

•Our goal: applying existing
intrusion detection techniques to
identifying malicious transactions

•Key issues:                         SSN       Start Date Salary
    –semantics-based intrusion
                                     900000001 01/01/97   $58,000
    detection
    –proof collection                900000001 01/01/98   $60,000
    –using the detector as a
    protection tool                  900000001 01/01/99   $62,000

    –coupling OS-level and           900000001 01/01/00   $82,000
    transaction-level intrusion
    detection

                                                                    11
Application-Aware Intrusion Detection

  Intrusion                                 Rule
   Detector
                                         Registration


                                           Rule
                        rule base
                                         Definition

                                          Function        Application
   trails                                   DLL            Semantics

      Every existing ID algorithm can be specified by a rule
                 Rules capture application semantics
            Active malicious transaction will be rolled back       12
Damage Assessment and Repair

         A history                  time   The database
          B1       G2              G3

         B1: read(x,z); write(x)
                                                      x
         G2: read(z); write(z)
         G3: read(x,y); write(y)                          y
                                                  z
                  B1
                       Read-from

          G2           G3
                                               A repair
         A dependency graph
                                                 Undo B1 & G3
Our goal: implementation and evaluation                         13
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

                                                                          14
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.
                                                            15
     A Limitation of Scheme 1
     •The purpose of confinement is to prevent damage from spreading
     •The delay of damage assessment can cause ineffective confinement!


                                                      User SQL Commands
        Damage Confinement
                                             Mediator
B1’s write sets                        (Policy Enforcement)
G2’s write sets
                  Intrusion detector                        Repair SQL Commands

            B1                             B1
                            Proofs
                                                      G4       Damage Repairer
                  Proof collector          G2


              Damage Assessor
                                       The database
                                                                              16
    Scheme 2: multi-phase confinement
                                             User SQL Commands
         Damage Confinement
                 Phase 1                Mediator
                                  (Policy Enforcement)

                                                   Repair SQL Commands
Later
             Intrusion detector
phases
                       Proofs       COTS DBMS
                                                         Damage Repairer
              Proof collector


             Damage Assessor


                                                                   17
     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
G3’s write set       B1                   (Policy Enforcement)
is clean
                 Intrusion detector                               Repair SQL Commands

            B1                               B1[5]       G4[15]
                            Proofs
                                                                    Damage Repairer
                  Proof collector            G2[7]

                                             G3[9]
                 Damage Assessor
                                          The database
                                                                                    18
Damage Confinement: A Spectrum


Maximum damage leakage                            Zero damage leakage
Maximum computing resources                 Minimum computing resources
Minimum integrity                                   Maximum integrity
Maximum availability                                Minimum availability


One-phase                     Approximate               Multi-phase
                              multi-phase




                                                                   19
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




                                                                 20
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
                                                                      21
Scheme 3: Isolation
                                          User SQL Commands
 Damage Confinement

         Suspicious trans.         Mediator
                             (Policy Enforcement)


     Intrusion detector
                             Main       Isolating ... Isolating
                             database   engine 1      engine n    Damage
                                                                  Repairer


                                        read
     Damage Assessor
                                           merge


                                                                    22
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.




                                                              23
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




                                                                            24
Scheme 4: Masking
                                                User SQL Commands
Damage Confinement
      Less suspicious trans.                   Mediator
                                         (Policy Enforcement)
                      Very suspicious trans.

    Intrusion detector                                              Masking
                                                                    engine 1
                                                  ...
                               Main   Isolating         Isolating      ...
                               DB     engine 1          engine n
 Damage Assessor                                                    Masking
                                                                    engine n
  Damage                              read
  Repairer
                                               merge
                                                                      25
Intrusion Masking: An Example
                                         U i : T i1
      Three less suspicious users:       U j : T j1
                                         Uk : T k 1
       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
                                                                                 26
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



                                                                      27
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)


        Intrusion                                    Tolerable
                             The controller
         detector                                    range
                                         State variable feedback
   Damage
   Assessor                        Main         Isolation    Masking
                                   database     engines      engines
    Damage
    Repairer
                                                                        28
                                              The database
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



                                                                          29
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




                                                          30
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
                                                                        31
Task Schedule


                                                                                100
                        Repair
                                                                                90
  Mediator Detection                                                            80
                                  Confine                                       70
                                                                                60
                                                                                50
                                                                                40
                                                                                30
                                                                                20
                                              Isolation                         10
                                                          Masking Self-Tuning   0
             Design    Implementation   Evaluation


                                                                                  32
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 to arm customers' database systems
with necessary intrusion tolerance facilities
                                                               33
Questions?




             Thank you!




                          34
Multi-layer representation of our approach




                                      35

								
To top