Summary
In studying the event types we used for our test
cases, a common basic token structure is being shared. Five tokens are
always present in these event types: header, subject, attribute, path, return.
This common structure allowed us to define a database that could easily store
these event types. In case new events are to be detected using this model, it
does not need to be modified at table structure level: it just has to be added
the new token types involved in the event. For maintainability purposes this
is a very useful approach.
Advantages
This method of representing our data is much cleaner that the Flat Schema
approach. Most DBAs will feel more comfortable working with this sort of a
structure.
Disadvantages
This approach will increase the number of joins needed to find an intrusion,
which may become a serious deficiency as the size of the tables and complexity
of the detection queries increases. It still does little to address the
redundancy issues that we face.
|