![](bg3.png)
(Agrawal, R., Evfimievski, A., Velu, R., 2007) an
approach to rank suspicious queries is presented.
Three different measures are provided to measure
proximity there. (Motwani, R., Nabar, S., Thomas,
D.) extends this work and provides a formal
foundation to audit a batch of SQL queries.
(Chen, S., Jeng, J., Chang, H., 2006) uses CEP
for business performance management. The focus is
on an extension to the Zurich Correlation Engine to
allow structural events in XML format to be
processed as well. (Lee, W., Fan, W., 2001) employs
data mining algorithms for intrusion detection
systems. Data mining is used to react to different
attack patterns. For data auditing, the access pattern
is always the same, thus eliminating the need for
data mining algorithms.
The proposed data auditing architecture in this
paper is also suitable for the business activity
monitoring approach presented in (Mangisengi, O.,
Pichler, M., Auer, D., Draheim, D., Rumetshofer,
H., 2007).
The remainder of this paper is organized as
follows: Section 2 proposes an architecture for an
enterprise-wide audit solution. It presents a
categorization of locations – so called audit hotspots
– where audits can be performed. A technical
introduction to auditing based on complex event
processing based on a simple example is provided in
Section 3. Section 4 describes two audit scenarios
for the proposed auditing architecture. Finally, a
conclusion and future work are presented in
Section 5.
2 DATA AUDITING
ARCHITECTURE
We use a sensor based data auditing architecture.
Sensors are lightweight agents whose task is to listen
on simple audit events, for example a query sent to a
database management system. The sensors are
scattered across the enterprise and communicate
detected audit events to one central audit event
processing system. After the events are processed,
the audit trail is forwarded to the central reporting
system.
Usually, it is very likely that different applications to
be audited require different types of sensors. For
example you could think of a sensor for the file
server to get access information to files that contain
sensitive information. We call the location at which,
a sensor is installed an audit hotspot. Figure 1 shows
a categorization of possible audit hotspots for an
information system that implements a three-tier
architecture:
Audit hotspot 1. Auditing is implemented
within the client application. This is the only
approach where the data can be audited that
actually has been seen by the user, e.g., in a
GUI driven application an audit event is only
created when the user actually switches to the
area containing sensitive information. The
main disadvantage of this approach is that it
requires to be implemented for each client
application type, so it is not a generic solution.
Audit hotspot 1. Auditing is implemented
within the client application. This is the only
approach where the data can be audited that
actually has been seen by the user, e.g., in a
GUI driven application an audit event is only
created when the user actually switches to the
area containing sensitive information. The
main disadvantage of this approach is that it
requires to be implemented for each client
application type, so it is not a generic solution.
Audit hotspot 2a. Traffic between the client and
the server is scanned at the network level. This
generic solution provides an audit solution for
all client applications communicating to the
application server. It is non-intrusive, which
means, there is no influence on application
performance. The challenge in this approach
comes with the analysis and interpretation of
the audit data. Direct access to data, bypassing
the application, will not be audited (for
example: privileged users that use a
development tool).
Audit hotspot 2b. Communication between the
client and the server is intercepted by the
sensor that is implemented as a proxy
application. This approach is similar to the
previous one, except that the whole client
server communication runs through the
sensor. This allows the sensor to react on
malicious activities on data. It is much like a
data firewall for intrusion detection systems
and is able to enforce privacy policies.
Audit hotspot 3a. Auditing is implemented
within the application server. Built-in features
of the application server are used. This
approach represents a generic solution for all
client applications using the application
server. On the other side, generic built-in
auditing features of the application server may
not provide the required audit granularity.
Audit hotspot 3b. Services are extended to
perform the audit. This intrusive approach
requires that all services have the auditing
COMPLEX EVENT PROCESSING FOR SENSOR BASED DATA AUDITING
487