We can thank PCI for that. At least partially. PCI specifically calls out the need for log aggregation and analysis (Requirement 10) and of course, most customers are just looking for something to check the box and make the compliance issues go away. Log management can do that to a point.

But the next tact I take with these end users is to ask whether they have confused compliance with security. Most (when questioned) don’t fall into the trap of thinking that just because they are compliant, that they are secure. But those same folks tend to accept investing just enough to be compliant, and don’t push to actually protect their data.

And that’s why we continue to see high profile data breaches from these organizations that are “compliant.” Remember, being compliant on Tuesday doesn’t matter, if an organization is compromised on Wednesday. There are lots of precedents that say the regulators will determine the organization is not “compliant,” based on the fact that a compromise occurred. Yes, that stinks, but it’s fact. Deal with it.

So given that we can all acknowledge that compliance doesn’t equal security. And most end users do want to be secure. That they need to push beyond just simple log management and move toward security management. And the vendor community has evolved their offerings along those lines as well.

This need for both security and compliance has driven for convergence of previously separate technologies (security information and event management (SIEM) and log management) coming together. And now most vendors have solutions to address both problems. Of course, we can (and do) debate about what integration really means, which we wrote about recently on eIQviews.

The market only recently figured out that SIEM and log management really need to be integrated, but we at eIQ also believe in the near future we’ll see configuration assessment (the definition and enforcement of standard configurations for computing devices) become part of this security and compliance management platform as well. But, eIQ is ahead of the market requirements on that right now, so we’ll need to keep evangelizing the logic of continuing to integrate more functions into a common platform.

To wrap up this piece, just being compliant isn’t enough, and we know most organizations are looking for a combined platform to do both SIEM and log management. Yet, all of these converged solutions continue to use mostly log data for its analysis. As you know, eIQ knows that “log data is not enough” and the next set of posts in this series will talk about 10 reasons why.

Stay tuned.

You can download the free, 11 page report from IT-Director: http://www.it-director.com/technology/paper.php?paper=761

But since we have your attention now, let us take a moment here to brag, I mean *share*, some of the findings according to Bloor Research [emphasis ours]…
 
 “SecureVue has a number of advantages over its competitors and we regard it as a must-see product.”
 “A major advantage of SecureVue, based on the different types of data it tracks, is that you can follow the track of a cyber attack from a single location.”
“eIQ’s key message is that “log data is not enough”. This is because hackers can disable log recording. eIQ records, monitors and correlates (with a single data model) the widest range of relevant information of any vendor in the market. This means that you can analyze breaches or attacks from a single viewpoint rather than having to use multiple tools.”
“…this makes SecureVue the most complete product in the SIEM market in terms of its breadth of data collection capabilities.”

Ok, that’s enough sharing for now.  You can access the full report on the IT-Director site to get the in depth report and evaluation of SecureVue: http://www.it-director.com/technology/paper.php?paper=761

It reminds me of when I was in the anti-spam business and we came across those customers that wanted to keep everything INDEFINITELY. That’s right, there were organizations out there that wanted to keep everything (spam included). I just scratched my head, and that is really Trent’s point here.

Each organization needs to understand what kind of data will be:

1. Useful from a security operations standpoint
2. Useful from a compliance standpoint.

In dealing with security operations, you need enough data to isolate the root cause of any abnormalities you find in your IT systems.

We also believe this data should be kept for a longer, rather than a shorter amount of time. The reality is with today’s low and slow attacks, a patient adversary may take months to perpetrate an attack. Once you roll over that data or don’t archive it, you can’t get it back. That doesn’t mean you keep stuff indefinitely, but you should be thinking in terms of years, not months.

When thinking about compliance, your assessor will tend to have opinions about what data you need or don’t need. And unfortunately those opinions can vary between assessors (or depending on which way the wind blows). So what enterprises need to do is DOCUMENT their retention policies and be able to defend them.

You can certainly have a difference of opinion with the assessor, but unless you have your data retention policies well-thought out and documented, you don’t have a leg to stand on when the assessor challenges you.

Finally, Trent’s point about the “skeletons in the closet” is exactly right. Every organization has them and hopefully we all have learned the lessons of all the high profile cases where emails provided pretty damning evidence. Just imagine your CEO doing stammer stammer stammer backpedaling during a video deposition. That worked pretty well for Microsoft a couple of times.

So only keep what you definitely need, but that’s only the third decision point – after meeting security ops and compliance data requirements.

Additionally, customers now expect their log management and SIEM capabilities to be “integrated.” Again, eIQ believes this is right on the money. The issue in taking these statements at face value is that the term “integration” is going to be twisted and turned to such a degree, you won’t even be able to recognize it. No one wants to bring a “two headed monster” into the environment.

So let’s lay out a couple of key ideas of what integration really means and then you can ask your favorite vendors to what degree they meet these ideals.

1. Does the vendor make both log management and SIEM technology? – As the SIEM market has evolved, you have vendors from both the SIEM and Log Management spaces converging into the same place. A few have decided to take short cuts and OEM technology to fill the gaps in their offering. So the first question to ask is whether the vendor actually produces both aspects of the solution. An OEM relationship doesn’t lend itself to real integration.
2. Does the SIEM and Log Management functions share a data store? – This is another area that vendors will try to deceive customers. The fact is most vendors in the space offer totally separate products for SIEM and log management. Some use their log management products to address scalability issues with their SIEM. Whatever the reason, if the products use different data stores and hardly even have interface integration, how can they say the solution is integrated?
3. Does the solution go beyond logs? - Log data is great, but it’s not enough. It’s critical to be able to analyze not just logs, but also other data types like configuration, asset, performance, vulnerability and network flow data to figure out what is happening in the IT environment. The vendors can talk about integration all they want, but if they are only looking at logs – then they are looking in the rear view mirror and will not be able to react fast enough to an emerging threat.

You probably aren’t surprised that eIQ can answer all these questions and show REAL INTEGRATION. SecureVue is a single platform, using a single data store for both SIEM and log management. We also do configuration assessment using the same platform and will continue adding functions over time.

The reason we use our own data store is because we couldn’t find one that could meet the needs of both SIEM and log management use cases. It seems other vendors are finding out the same thing and having to use separate data stores to solve the problem.

The two headed monster was kind of cool to see in a horror flick. They also say “two heads are better than one.” Sometimes that’s true, but not in this case. You don’t want to see two heads in your security environment. Clearly customers want integration, just make sure you understand what “integration” really means.

There are two main reasons that logs can be somewhat limiting in detecting attacks.

1. Logs (by definition) are backwards looking – Logs are great and important, especially for investigations and compliance reporting. But when trying to determine if you are under attack, looking in the rear view mirror can be too late. By the time your logs see it, it’s already happened.
2. Logs are really corroborating evidence – Once an attack is launched, there are records of that attack and that is important to isolate the root cause and to eventually remediate the issues.

So what kind of data should we also gather to supplement the information in the logs? From a threat management perspective, there are a number of other important data types.

• Configuration data – most attacks have some impact on the configuration of a device. Maybe it’s a different setting or the opening of a non-standard port. Or turning off logging. Usually there is some kind of trail, unless the devices have some well-known vulnerability that can be exploited.
• Vulnerability data – Vulnerabilities are not a sure path to exploit, but certainly can be. So it’s important to understand what devices are exposed to what, if only to tighten thresholds around specific attacks.
• Asset data – One of the most important pieces of asset data is installed software. Because another typical “tell” of an attack underway is to see if any new software has been installed on a device. This isn’t always indicative of a compromise, but most Trojans and other attacks do involve additional executables on a device.
• Performance data – Understanding if a device is operational and looking for abnormal utilization can be indicative of a compromised device. As with the other data types, performance data by itself is not conclusive, but can certainly be used to define the issues, determine the attack vectors, and understand how critical the issues are.
• Network Flow data – The last data type we’ll mention is network flow data. This is information that comes directly from your routers and switches and provides a lot of information about which devices are talking to one another. Tracking anomalous network traffic can yield clues to attack behavior. For example, if an internal web server is sending data to an external source, it could indicate a problem.

Yet gathering all of these information types is only the first step in threat management. First of all, information in different silos is not really information at all, it’s just data. So all of these disparate data sources must be analyzed and correlated to ensure clear corroboration of the different data types.

Data doesn’t help you understand what you need to investigate and how quickly. And that is what most security professionals really need to understand.

Fundamentally, log management solutions just gather information. Although broader than a typical log management product, eIQ’s SecureVue focuses on monitoring all of these data types and providing information to help security professionals prioritize their activities. But you’ll still have to deal with the threats.

This goes beyond log management and enters the domains of anti-malware, intrusion prevention, and application control, among other technologies. Knowing what is happening is just one part of the battle (though it’s most interesting to us), doing something about it is a totally different discipline.

The next piece in our log management series will delve into some of the nuggets of information found in log files, and how to use them.