Databases Reference
In-Depth Information
lutions transparent to existing applications, it is a good idea to develop
DQR theories and mechanisms at the transaction level. Since real world
mission/life/business-critical applications typically deploy the transaction
mechanism, transaction-level DQR solutions will have wide applicability.
2.1 Scope of Transaction Level DQR
In the rest of this paper, we will focus on transaction level DQR problems,
models, and solutions. In particular, the transaction-level
scope
of an applica-
tion and its
environment
are shown in Figure 1. In an information system, the
transaction processing components of an application do not form an “isolated”
system. Instead, these components will interact with their environment, which
includes the Physical World, the various non-transactional actions, and the
various types of data sources. Through these
interactions
, inputs are taken,
physical world effects can be caused, and non-transactional attacking actions
can “poison” the application's transaction scope. Although we are aware that
the cyberspace damage and cascading effects can certainly cause damage in
the physical world, this paper will focus on the
cyberspace
DQR solutions
which will help minimize the damage caused in the physical world.
Based on how the transaction abstraction is implemented, different real
world applications may deploy different transaction models. In this paper, we
will focus on the transaction model shown in Figure 2. This model is widely
used by conventional client-server applications and the well-known three-tier
web applications. Applications running Transactional Web Services [1] and
cross-site “business transactions” (a.k.a. workflows) require more advanced
transaction models, which are out of the scope of this paper. As we will men-
tion shortly in Section 5, these advanced transaction models would introduce
additional challenges in solving the DQR problem.
2.2 The Threat Model and Intrusion Detection Assumption
Working at the transaction level does
not
mean that malicious transactions are
the only threat we can handle. Instead, as shown in Figure 1, we allow threats
to come from either inside or outside of the transaction-level scope of appli-
cations. Nevertheless, to exploit the application's transaction mechanism to
achieve a malicious goal, both inside and outside threats need to either directly
corrupt
certain data objects or get certain malicious transactions launched.
Outside non-transactional attack actions (e.g., Witty worm) may bypass the
transaction interface and corrupt some data objects via low-level (e.g., file or
disk) operations. In addition, non-transactional buffer overflow attacks may
break in certain running program of the application; then the attacker can
manipulate the program to launch certain malicious transactions.
Inside the transaction scope,
insider attack
[9] is probably the most serious
threat. Since insiders (i.e., disgruntled employees of a bank) are typically
not savvy in hacking, issuing malicious transactions (using a different user
