TaoSecurity Blog

Last year at this time I wrote a series of posts on security event correlation . I offered the following definition in the final post: Security event correlation is the process of applying criteria to data inputs, generally of a conditional ("if-then") nature, in order to generate actionable data outputs. Since then what I have found is that products and people still claim this as a goal, but for the most part achieving it remains elusive. Please also see that last post for what SEC is not , i.e., SEC is not simply collection (of data sources), normalization (of data sources), prioritization (of events), suppression (via thresholding), accumulation (via simple incrementing counters), centralization (of policies), summarization (via reports), administration (of software), or delegation (of tasks). So is SEC anything else? Based on some operational uses I have seen, I think I can safely introduce an extension to "true" SEC: applying information from one or more data...

This my final post discussing security event correlation (SEC) for now. (When I say SAC I do not mean the Simple Event Correlator [SEC] tool.) Previously I looked at some history regarding SEC, showing that the ways people thought about SEC really lacked rigor. Before describing my definition of SEC, I'd like to state what I think SEC is not . So, in my opinion -- you may disagree -- SEC is not : Collection (of data sources): Simply putting all of your log sources in a central location is not correlation. Normalization (of data sources): Converting your log sources into a common format, while perhaps necessary for correlation (according to some), is not correlation. Prioritization (of events): Deciding what events you most care about is not correlation. Suppression (via thresholding): Deciding not to see certain events is not correlation. Accumulation (via simple incrementing counters: Some people consider a report that one has 100 messages of the same type to be correlation. ...

I'm back with another look at security event correlation . This time it's a June 2008 review of SIEM technology by Greg Shipley titled SIEM tools come up short . The majority of the article talk about non-correlation issues, but I found this section relevant to my ongoing analysis: "Correlation" has long been the buzzword used around event reduction, and all of the products we tested contained a correlation engine of some sort. The engines vary in complexity, but they all allow for basic comparisons: if the engine sees A and also sees B or C, then it will go do X. Otherwise, file the event away in storage and move onto the next. We'd love to see someone attack the event reduction challenge with something creative like Bayesian filtering, but for now correlation-based event reduction appears to be the de facto standard... Ok, that sounds like "correlation" to me. Let's see an example. For example, one of the use cases we tackled was the monitoring...

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 rathe...

I've been thinking about the term "correlation" recently. I decided to take a look back to determine just what this term was supposed to mean when it first appeared on the security scene. I found Thinking about Security Monitoring and Event Correlation by Billy Smith of LURHQ, written in November 2000. He wrote: Security device logging can be extensive and difficult to interpret... Along with lack of time and vendor independent tools, false positives are another reason why enterprise security monitoring in not easy... The next advance in enterprise security monitoring will be to capture the knowledge and analytical capabilities of human security experts for the development of an intelligent system that performs event correlation from the logs and alerts of multiple security technologies. Ok, so far so good. For example Company A has a screening router outside of their firewall that protects their corporate network and a security event monitoring system with reliable ar...