Databases Reference
In-Depth Information
On-the-fly attack recovery faces several unique challenges. First, since new
transactions may first read corrupted data objects then update clean data ob-
jects, the damage may continuously spread, and the attack recovery process
may never
terminate
. Accordingly, we face two critical questions. (a) Will the
attack recovery process terminate? (b) If the attack recovery process termi-
nates, can we detect the termination? Second, we need to do repair
forwardly
since the assessment process may never stop. The assessment process may
never stop since the damage may continuously spread. Third, cleaned data
objects could be re-damaged during attack recovery.
To tackle challenge 2, we must ensure that a later on cleaning transac-
tion will not accidentally damage an object cleaned by a previous cleaning
transaction. For this purpose, the system should “remember” the data ob-
jects that are already repaired and not yet re-damaged. To tackle challenge 3,
we must not mistake a cleaned object as damaged, and we must not mistake a
re-damaged object as already cleaned. To tackle challenge 1, the study in [68]
shows that when the damage spreading speed is quicker than the repair speed,
the repair may never terminate. Otherwise, the repair process will terminate,
and under the following three conditions we can ensure that the repair termi-
nates: (1) every malicious transaction is cleaned; (2) every identified damaged
object is cleaned; (3) further damage assessment scans will not identify any
new damage (if no new attack comes).
From a state-transition angle, the job of attack recovery is to get a
state
of the database, which is determined by the values of the data objects, where
(a) no effects of the malicious transactions are there and (b) the work of good
transactions should be retained as much as possible. In particular, transactions
transform the database from one state to another. Good transactions trans-
form a good database state to another good state, but malicious transactions
can transform a good state to a damaged one. Moreover, both malicious and
affected (good) transactions can make an already damaged state even worse.
We say a database state
S
1
is
better
than another one
S
2
if
S
1
has fewer
corrupted objects. The goal of on-the-fly attack recovery is to get the state
better and better, although during the repair process new attacks and damage
spreading could (temporarily) make the state even worse. (A state-oriented
object-by-object attack recovery scheme is proposed in [71].)
Finally, it should be noticed that from the transaction scheduling view-
point, on-the-fly repair introduces new scheduling constraints. For example,
(a) when a read operation
r
T
[
x
] is scheduled,
x
must be clean. (b) Conflicting
cleaning transactions should be scheduled in the same order in which they are
submitted by the Repair Manager. The order is critical to the correctness of
repair. (c) When a cleaning operation
w
U
[
x
] is scheduled,
x
must be dirty.
Dynamic DQR Solutions with Proactive Quarantine
From the viewpoint of on-the-fly non-stop recovery, fault/damage quarantine
can be viewed as part of recovery. The goal of damage quarantine is to prevent
