A column dependency-based approach for static and dynamic recovery of databases from malicious transactions

Abstract

Even state of the art database protection mechanisms often fail to prevent occurrence of malicious attacks. Since in a database environment, the modifications made by one transaction may affect the execution of some of the later transactions, it leads to spreading of the damage caused by malicious (bad) transactions. Following traditional log-based recovery schemes, one can rollback (undo) the effect of all the transactions, both malicious as well as non-malicious. In such a scenario, even the unaffected transactions are also rolled back. In this paper, we propose a column dependencybased approach to identify the affected transactions which need to be compensated along with the malicious transactions. To ensure durability, committed non-malicious transactions are then re-executed in a manner that retains database consistency. We present a static recovery algorithm as well as an on-line version of the same and prove their correctness. A detailed performance evaluation of the proposed scheme with TPC-C benchmark suite is also presented.

Approaches and Challenges in Database Intrusion Detection

“… When the DIDS is unable to prevent the execution of intrusive actions, it should consider the execution of a recovery-from-attack type solution, such as [3];…”

A survey on data security in data warehousing: Issues, challenges and opportunities

“…Other systems use these features and add encryption techniques for distributing storage [25]. Architectures for damage assessment and self-healing databases have also been proposed [9,11,12,23,24]. Although strongly effective for availability purposes, data replication techniques are always an important issue in DWs, given the volume of data and storage size typically involved.…”

Maintaining Data Integrity in Fog Computing Based Critical Infrastructure Systems

“…The algorithm will examine the next transaction in the log file, which is T 2 . Since T 2 is an updating transaction, it will be added into the DA Table. Consequently, every reading (K, 6) (K,3), (fog 1 .T 3 .G, 3) T 10 (M, 16) (M, 10), (K, 6) T 14 (N, 31) (L, 4), (fog 1 .T 7 .D, 27) T 16 (P, 43) (fog 1 .T 11 .E, 43)…”