<!-- @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } --> 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.
More...
09-02-2008
