Security Event Correlation: Looking Back, Part 2

In my last post Security Event Correlation: Looking Back, Part 1 I discussed a story from November 2000 about security event correlation. I'd like to now look at Intrusion Detection FAQ: What is the Role of Security Event Correlation in Intrusion Detection? by Steven Drew, hosted by SANS. A look at the Internet Archive shows this article present as of August 2003, so we'll use that to date it.

[A]s pointed out by Steven Northcutt of SANS, deploying and analyzing a single device in an effort to maintain situational awareness with respect to the state of security within an organization is the "computerized version of tunnel vision" . Security events must be analyzed from as many sources as possible in order to assess threat and formulate appropriate response... This paper will demonstrate to intrusion analysts why correlative analysis must occur in order to understand the complete scope of a security incident.

Ok, let's go. I'll summarize the article rather than post clips here because I can make the point in a few sentences. The article shows how an adversary scans for CGI scripts phf, formmail, and survey.cgi, and how four data sources -- a router, a firewall, an IDS, and a Web server -- see the reconnaissance events. First the author shows the view of the "incident" from the perspective of each of the four data sources. Next he describes how looking at all of the data together results in a better overall understanding of the incident. He provides this "Ven" (sic) diagram and the following text:



The diagram shows that removing the analysis of even just one of the device's log data, our understanding of the incident can drop dramatically. For example, if we remove the analysis of the web server error_log, we would not have known that the script access attempt failed. If we had not analyzed the router, we would not have known the probing host scanned the entire class C of addresses for web servers. If we had not analyzed the www access_log, we would not have known that the probing host was likely using Lynx as the web browser to check for the scripts. If we had not analyzed the network IDS logs, we may not have known that the activity was related to well known exploit attempts. (emphasis added)

Do you see the same problems with this that I do? This is my overall reaction: aside from the access failed ("404") messages from the Web server error logs, who cares? Port scans: who cares. Using Lynx: who cares. Snort saw it: who cares. All that matters is the activity failed. In fact, since it was only reconnaissance, who could care at all? People who spend time on this sort of activity should be doing something more productive.

It appears that getting to the heart of the matter, i.e., looking at the target application logs (i.e., Apache) yields the information one really needs for this sort of incident. In other words, correlation isn't the governing principle; access to the right sort of evidence dominates. If the analyst in this case didn't have access to the Web server logs, we'd be much more concerned (or maybe not).

Furthermore, notice there is zero mention of whether the target of this incident matters, or what compensating controls might exist, or a dozen other lacking contextual issues. As I mentioned in my last post, these sorts of problems are the true obstacle to security event correlation.