I recently had an opportunity to work
on some existing event correlation infrastructure in a large
environment. I found there were a lot of considerations that came
into play to get the event correlation aspects functioning optimally.
I found understanding the quality of the data that came into the
device from its sources, intelligent design of incident creation, and
assuring a proper grasp of the configuration options and limitations
within the event correlation software were all particularly
important.
As I have said, the event correlation infrastructure
already existed. Unfortunately, it appeared that whoever had worked
on it had not had much time available to learn the way to properly
configure the software. Rather than let this dishearten me, I decided
it was a great opportunity to learn more about event correlation.
Most of the existing rules designed to create "Incidents"
which needed additional action were not triggering in an expected
fashion. They were either generating a large number of false
positives, or there were a lot of false negatives that on the surface
were invisible. As this software was being used primarily for
antivirus software, this was obviously not the best outcome. With
some time spent researching what the rules were supposed to do,
reading the manual, and contacting the technical support team for the
product, I was able to get the existing rules working properly.
That
warm up armed me with the knowledge needed for planning additional
incident triggers to benefit the Incident Response Team at this
company. Based on my background in antivirus software and internal
customer feedback, I realized that it was most crucial to have
incidents trigger for particularly concerning events such as root
kits being detected or viruses not able to be deleted by the
antivirus software. I was able to generate these rules with a little
trial and error.
Unfortunately, some of the desired granularity
was lacking. For example, Temporary Internet Files often has
detections of adware and spyware. These files are "locked"
by Internet Explorer and are often unable to be deleted by antivirus
software at the time of the detection. If you manually view the file
that is left, however, you can see that it's a 0 byte file. The
antivirus software did not differentiate between "can't delete
file" and "can't delete 0 byte file" so there was no
easy way to trigger an incident only when the file was an actual
threat. This was obviously not due so much to the event correlation
software as the antivirus software in question; but it required a
reasonably in depth knowledge of the antivirus software. Due to this
I was unable to create a rule that only triggered when there was real
concern. Any detection in Temporary Internet Files would require a
manual perusal to determine whether there was an issue.
After completing this project, the
Incident Response Team has stated they feel much more capable of
identifying issues which require their attention in a much shorter
time frame. I feel that taking the time out of my already busy
schedule to get this software functioning was well worth it from a
cost/benefit perspective. Event correlation software is something I
would recommend to anyone who would like a better tactical and
strategic view of their environment. Obviously any vendor's event
correlation software can be used for much, much more than just
antivirus events.
