Information Technology Reference
In-Depth Information
As illustration, a formalization in our language of the above fraud-detection
policy is
∀
u.
∀
s.
[
SUM
a
a.
[0
,
31)
withdraw
(
u,a
)](
s
;
u
)
→
s
10000
.
(P0)
The
SUM
operator, at the current time point, groups all withdrawals, in the
past 30 days, for a user
u
andthensumsuptheiramounts
a
. The aggregation
formula defines a binary relation where the first coordinate is the
SUM
's result
s
and the second coordinate is the user
u
for whom the result is calculated. If
the user's sum is greater than 10000, then the policy is violated at the current
time point. Finally, the formula states that the aggregation condition must hold
foreachuserandeverytimepoint.
A corresponding SQL query for determining the violations with respect to the
above policy at a specific time is
SELECT SUM
(
a
)
AS
s,u
FROM
W
GROUP BY
u
HAVING SUM
(
a
)
>
10000
,
where
W
is the dynamically created view consisting of the withdrawals of all
users within the 30 day time window relative to the given time. Note that the
subscript
a
of the formula's aggregation operator in (P0) corresponds to the
a
in the SQL query and the third appearance of
a
in (P0) is implicit in the query,
as it is fixed by the view's definition. The second
a
in (P0) is redundant and
emphasizes that the variable
a
is quantified, i.e., it does not correspond to a
coordinate in the resulting relation.
Not all formulas in our language are monitorable. Unrestricted use of logic
operators may require infinite relations to be built and manipulated. The second
part of our solution, therefore, is a monitorable fragment of our language. It can
express all our examples, which represent typical policy patterns, and it allows
the liberal use of aggregations and functions. We extend our monitoring algo-
rithm for MFOTL [7] to this fragment. In more detail, the algorithm processes
log files sequentially and handles aggregation formulas by translating them into
extended relational algebra. Functions are handled similarly to Prolog, where
variables are instantiated before functions are evaluated.
We have implemented and evaluated our monitoring solution. For the eval-
uation, we use fraud-detection policy examples and synthetically generated log
files. We first compare the performance of our prototype implementation with
the performance of the relational database management system PostgreSQL [22].
Our language is better suited for expressing the policy examples and our pro-
totype's performance is superior to PostgreSQL's performance. This is not sur-
prising since the temporal reasoning must be explicitly encoded in SQL queries
and PostgreSQL does not process logged data in the time sequential manner.
We also compare our prototype implementation with the stream-processing tool
STREAM [2]. Its performance is better than our tool's performance because, in
contrast to our tool, STREAM is limited to a restricted temporal pattern for
which it is optimized. Although we have not explored performance optimizations
for our tool, it is, nevertheless, already ecient enough for practical use.
