Somebody showed up at my door the other day and said “I want to buy some correlation!” Don’t get me wrong – I love correlation; I developed correlation rules for a living some time ago. Correlation is totally fun. That’s why I wrote a couple dozen papers defining and explaining security event correlation (example here, here, here).
Despite all that, I am still shocked when I see people who define their requirements for an expensive security product (such as Security Information and Event Management – SIEM) in that form: I want to buy correlation. BTW, I ridiculed this as one of the “worst practices” here in this fun presentation – see slide 11.
First, correlation engine is … well… an engine. What can you do with an engine? Unless you are an engine mechanic and think that it is fun to just tinker with it, you probably prefer this engine to be embedded in a car. And car is that thing that allows you to get from A to B faster [than walking … unless you drive up RT101 in the morning]. So, you are buying “transportation” and not “correlation.” Or, in our security realm, you are buying [a chance for] automated near-real-time detection of incidents. Or a tool to simplify your security monitoring.
Second, engine needs oil and gas to operate. What is correlation “oil and gas”? Content! This jargon term simply means correlation rules, alert/notification templates, views, workflows and reports that define how correlation will actually solve your particular problem. That is not everything that allows the engine to contribute to solving “the transportation problem,” but it is pretty darn important. Even engine mechanics drive their cars using oil and gas, even after they build that extra turbocharger on the side :-)
Third, the above two points should tell you that you need to know what problem you are trying to solve with correlation before you go “shop for correlation.” And here is something magical: don’t pick a problem of “improving food quality in a buffet on a ‘Titanic'.” Pick ship survivability instead! (BTW, “Titanic” was compliant!) What I mean here is that if you are not ready to handle real-time notification of incidents, then focus on investigations first with log aggregation, indexing and searching. This paper should jolt your brain in this useful direction.
Now, if your organization is looking for some help defining the requirements for a SIEM or log management product, choosing the right tool etc, figuring out how to operationalize it, I can definitely help.
BTW, this is posted by the scheduler. I am away attending to a family emergency; response to comments will be slow.
Possibly related posts:
