The document discusses a self-healing database system that can assess damage, track dependencies between transactions, and dynamically repair data after an intrusion. It proposes 1) using a before-image table to log old data values for repairs, 2) tracking inter-transaction dependencies to determine which transactions need to be undone, and 3) algorithms for damage assessment and on-the-fly repair based on the dependency information and transaction log. The system aims to provide continuous service while repairing damage by selectively undoing malicious and affected transactions.

1. LOGO
Self-healing
Database System
——小组讨论 2010/11/16

2. Contents
A Robust Damage Assessment1
Tracking and Repairing2
Dynamic Data Recovery3
A new Logging Mechanism4

3. The Whole View
 Intrusion-tolerant/attack-resistant/self-healing system
Post-intrusion
database
A consistent state
Recovery
Damage assessment
Damage containment
Damage repair
*Critical phase
Recovery process
Detect damage propagation
scales in a corrupted database system

4. Self-healing System Architecture
Intrusion detection
user
Damage assessment
Damage repair
database
audit
transaction
Intrusion Alarm
Transaction dependency
Undo transaction set
compensating transaction

5. Related Work
A repairable DBMS prototype
Based on the PostgreSQL DBMS:
1.multi-version concurrency control(MVCC)
2.no-overwrite storage structure
An attack self-healing database system prototype
Dependency between transactions is not complete.

6. A Robust Damage Assessment Model
Damage Spreading Patterns
• How innocent data are affected in a compromised
database system.(most common: Read-Write)
Transaction dependency
Data sharing
Application level
Inter-Transaction

7. Inter-transaction Dependency
 Read-Write Dependency
 Phantoms Dependency
 Pseudo-Identity Dependency
 Domain-Integrity Dependency
 Reference-Integrity Dependency
Extended
damage
assessment
model

8. Inter-transaction Dependency
product_id name price
P000 rice 400
P001 banana 230
P002 orange 120
Phantoms Dependency
product_id name price
P000 rice 600
P001 banana 230
P002 orange 120
G1:UPDATE product SET price=1.1*price WHERE price>500
G1 read a phantom data “rice”.
G0
product_id name price
P000 rice 400
P001 banana 230
P002 orange 120
B1 (undo : make the recovery
Result incomplete )

9. Inter-transaction Dependency
product_id name price
P000 rice 400
P001 banana 230
P002 orange 120
P003 apple 100
P004 flour 460
product_id name price
P000 rice 400
P001 banana 230
P003 apple 100
P004 flour 460
product_id name price
P000 rice 400
P001 banana 230
P003 apple 100
P004 flour 460
P002 grape 320
Pseudo-Identity Dependency
Same primary key
B
G : creates a new entity
with a pseudo identity to
satisfy the entity integrity
constraint.

10. Inter-transaction Dependency
product_id p_price r_price
P000 400 500
P001 230 246
P002 460 486
product_id p_price r_price
P000 350 500
P001 230 246
P002 460 486
product_id p_price r_price
P000 350 360
P001 230 246
P002 460 486
Domain-Integrity Dependency
Row integrity constraint CHECK(p_price<r_price)
B
G

11. Inter-transaction Dependency
product_id p_price r_price
P000 400 500
P001 230 246
order_id p_id quantity
O001 P000 500
O002 P001 300
product_id p_price r_price
P000 400 500
P001 230 246
P002 460 486
order_id p_id quantity
O001 P000 500
O002 P001 300
O003 P002 260
Reference-Integrity Dependency
DO-NULL/SET-NULL/CASCADE
B G

12. Extended Recovery Model
 Definition 1: DB(V,B)
 Definition 2: actual-read ari[x]:x∈DB.V
 Definition 3: potential-read pri[y]:y∈DB.B
 Definition 4: express dependency wi[y]ari[x]
 Definition 5: implied dependency wi[y]pri[x]
 *Definition 6:A transaction Ti is dependent on
another transaction Tj if there is at least one write
operation of Ti which is:
1) expressly dependent on an actual-read operation ari[x] where x was
inserted by Tj, or
2) impliedly dependent on a potential-read operation pri[x] where y was
deleted by Tj.

13. The Recovery Method Based On BI Table
Before Image Table
When a row in a base table is deleted or updated, the
trigger will be invoked and the row’s old value will be
inserted into the table’s BI table.
 Advantages:
long-standing than traditional before image
 Disadvantages:
may grow huge, need a time window

14. The Recovery Method Based On BI Table
Capturing Inter-transaction Dependency
Each data item x : x.ins_tran & x.del_tran
(be recorded in DS)
Each active transaction T: DS
Q:A system table(all dependency is kept in) :
TranDepTab ( commit_ord,
dependent_tran,
precursor_tran )
Transaction depending on
other transaction
Transaction being depended
by dependent_tran
Order in which
dependent_tran has committed

15. The Recovery Method Based On BI Table
 Rows satisfying the search condition of each subquery
are looked as the objects of actual-read operations, so
the ins_tran fields of these rows are recorded in DS.
 Each time when a subquery is executed on a base table,
an equivalent subquery will be executed on its relevant
BI table to determine the potential-reads on the
deleted data items.
 Although rows in BI table which satisfy the search
condition will not participate in further computation,
the del_tran field of these rows will be recorded in
DS.

16. Repair the Post-intrusion Database
Repair Process：
1. Identify the transactions to be undone
If a transaction is executing an actual-read on item x where
x.ins_tran ∈ UndoTranList, or a potential-read on item y where
y.del_tran ∈ UndoTranList, then this transaction is regarded as
reading damaged data and will be aborted.
2. Erase these transactions’ effect on the database
BI tables are used to restore those deleted data.
The undone of transactions in UndoTranList is implemented by
compensating transactions.
UndoTranList:{(tran,first_cleaned_tab),……}

17. Algorithm 1.
The damage assessment algorithm
Input: the TranDepTab table, the set B of bad transactions.
Output: the UndoTranList.
Steps:
1. For each bad transaction b in B, add (b, Null) to UndoTranList.
2. Locate the first record in TranDepTab table whose
dependent_tran∈B.
3. Scan forward until the end of the TranDepTab table.
For each record r
3.1 If ( r.precursor_tran∈UndoTranList ) then
3.1.1 Add (r. dependent_tran, Null) to UndoTranList.

18. Algorithm 2.
The on-the-fly repair algorithm
Input: the UndoTranList.
Output: a consistent database state in which all transactions in UndoTranList are undone.
Steps:
1. For each base table r in database
1.1 For each item u in UndoTranList
1.1.1 If (u.first_cleaned_tab = r) then
1.1.1.1 Set UndoTranList = UndoTranList – u
1.1.2 Elseif (u.first_cleaned_tab is Null) then
1.1.2.1 Set u.first_cleaned_tab = r
1.2 If (UndoTranList is Null) then exit
1.3 For each data item x in r
1.3.1 If (x.ins_tran∈UndoTranList) then
1.3.1.1 Delete x from r
1.4 For each data item y in the BI table of r, say bi_r
1.4.1 If (y.del_tran∈UndoTranList) then
1.4.1.1 If (y.ins_tran∉UndoTranList) then
1.4.1.1.1 Set y.del_tran = Null
1.4.1.1.2 Insert y into r
1.4.1.2 Delete y from bi_r

19. Dynamic Recovery based on Fine Grained T log
when the damage for data items occurs, the
database system should provide continuous,
but maybe degraded service while the damage
is being repaired.
Two evaluation criteria:
1.exactness
2.high-efficient

20. The Data Recovery Model
Transaction Dependency Relationship
• Extended Read-Write Dependency TjETi
• 1) Tj extended reads x after Ti wrote x;
• 2) Ti doesn't abort before Tj extended reads x;
• 3) every transaction that writes x between the time Ti writes x and
• Tj extended read x is aborted before Tj extended reads x.
• Phantoms Dependency
• Transaction Dependency in a Transaction History
H: B ∪ G
D = {<Ti Tj>| Ti ETj or Tjp Ti, where Ti, Tj ∈ B ∪ G }
The transaction dependency for H is denoted DH
The Recovery Method
1. Locate affected transactions
2. Undo the malicious as well as the affected transactions
3. Retain the results of other benign transactions

21. Fine Grained Transaction Log
Fine Grained Transaction Log
1) [TRASATIONID, OPTYPE, ITEM, BEFOREIMG, AFTERIMG, TIME]
2) when a transaction is committed, entries for write and
extended read operations involved in the transaction are
added to the log.
3)Q: Fine grained transaction log generator?
{SELECT, UPDATE, INSERT, DELETE}
involves tablename, rownumber, and column

22. Dynamic Recovery based on Fined Grained T log
1. Retaining Modifications for Blind Write
2. Damage Assessment and Data Recovery

23. Dynamic Recovery based on Fined Grained T log
Damage Assessment and Data Recovery
 Extended Read-Write Dependency
Damage Assessment process devoted to three kinds of log entries:
1)Write entries for a transaction in B  undone
2)A long entry for blind write transaction , when losing modification
conditions  a compensation transaction
3)Normal transaction log entry , if reads data items modified by
malicious or affected transactions  undone
 Q:Phantoms Dependency ?
SQL statement s in T is executed. C1
An additional SELECT statement q following s. C2
Differ:q reads from Original table&history table
Item.rownumber field in the collection (C2-C1)?Phantoms :not

24. Selective Recovery based on
a new Logging mechanism
Selective recovery
Inadequacy of traditional logging mechanisms
Demand:
1. Transaction dependency
2. Containing before image
3. Longtime preservation of before image datas
4. Convenient

25. New Logging mechanism
事务依赖日志
前像表日志
重做日志

26. New Logging mechanism
事务依赖日志：
系统处理读操作的过程中及时确定事务依赖关系；
扩充元组数据结构：
对于每个事务Ti，系统维护一个初值为空的集合DTSi，Ti每执行一次读
操作，都将所读元组的Ins_tran加入到DTSi。
事务依赖日志由事务开始记录、事务依赖记录和事务回滚记
录构成。
( Rec_type ,TranID, Dep_tran_num,Dep_tranID1,…, Dep_tranIDn)
Ins_tran Del_tran Other information field1 fieldn……
元组控制信息 元组数据信息

27. New Logging mechanism
前像表日志
由若干个前像表构成，分别与基表存在一一对应的关系。
重做日志
用于记录对数据库修改的后像数据，包括数据文件、事务
依赖日志文件以及前像表日志文件的修改。
遵循WAL（write-ahead logging），修改在写盘之前，必
须先将相应修改的日志记录写入重做日志。
采用物理日志形式，日志中记录的修改以数据页为单位，
（PageID，offset，len，data）。

28. Selective Recovery based on
a new Logging mechanism
输入: 恶意事务 B
输出: 撤销了 B 及依赖于B 的所有事务后的数据库
步骤: 初始化回滚事务集合 S = { B} ;
在事务依赖日志中定位事务 B 的开始记录t b ;
for ( tb后的每条记录 r) {
if ( t. Rec_type ==事务依赖记录类型 ) {
for ( i = 1 ; i < = t. Dep_tran_ num; i + + )
if ( t. Dep_t ranIDi ∈S) {
S = S ∪{ t.TranID} ;
break ;
}
}
}
for (数据库中的每个基表 R) {
删除 R中所有 r. Ins_tran∈S 的元组 r ;
将 R的前像表 Rbi中所有 r. Del_ tran∈S 且 r. Ins_ tran 不属于S的元组 r 重新插入R ;
}

29. LOGO