Ten Reasons Log Data is Not Enough #8: Reacting FASTER
November 3, 2009
Can you react as fast as The Flash?
So here’s the thing. As we’ve been talking about (and I’m assuming you are bored with the topic already), log data is not enough. One of the key reasons we usually overlook is the reality that logs are a BACKWARD looking indicator. If it’s in the logs, it’s already happened and therefore you may be too late to stop an attack which already happened. Unless you have a time machine, that is.
Now to be clear, looking backwards is very important. Doing a post-mortem after any kind of incident is absolutely critical. And the log data is critical for forensics purposes to figure out what happened and ensure a data breach is contained and the damage controlled. But unfortunately, by the time your logs see something, it’s already happened and therefore it’s fairly unlikely you’d be able to intervene and stop the attack.
For many years (back from my Security Incite days), I’ve been talking about this concept of REACTING FASTER. My contention was that you can’t get ahead of the threat, so you better be able to figure out what’s happening so you can remediate and contain the damage. You can’t do that with logs. But you can react EVEN faster if you are looking at these other data types. For instance, by correlating the data you get from configuration assessment and performance metrics, combined with the events – you are more likely to catch something that is happening, than if you were just looking at the logs themselves.
It’s a concept known very well to lawyers of all shapes and sizes. Despite your potential disdain for all things legal (especially if you’ve had a disclosure event), the need for corroborating evidence makes a lot of sense. It turns out that having information to corroborate the attack vector and root cause is key to being able to react faster. I’ve yet to meet a security professional who’s told me he/she has too much time. We don’t get to finish everything on our list every day, so we need to work smarter and that means reducing the number of false positives and also investigating only the alerts that present the greatest threat to your environment. If you can prioritize more effectively, your security will improve – guaranteed.
It reminds me of my days in the anti-spam business. We wouldn’t rely on just one detection method to determine if a message was crap. We’d use over 50 different techniques and analyze the results to get a more statistically relevant answer. That’s what eIQ does with all the additional data types. It allows customers to get closer to the truth before spending a lot of time going down the proverbial rat hole.
And saving time is a good thing for everyone.
Ten Reasons Log Data is Not Enough: #4. Network Blind Mice
September 17, 2009
As we discussed in the last post in the Ten Reasons Log Data is Not Enough series, configuration data provides an important additional set of information to help pinpoint potential attacks and make sure that in the absence of log data (if logging is turned off, for example) attacks can still be detected.
Network flow data is another data type that can yield important and interesting corroborating data to go Beyond Security Information and Event Management (SIEM) and Log Management. First what is network flow data? Basically, every network device tracks some simple information about who is talking to whom and what protocols they are using. Cisco’s data is called NetFlow. Juniper has a format called (surprisingly) JFlow and there is a more standard format called cflowd.
Regardless, this network flow data comes in fast and furious, with millions of flow records being generated every second. So scaleability is a key requirement if you are planning to analyze and correlate network flows, along with everything else.
Why is being blind to network flows a huge problem for security professionals? Basically, the network sees everything, at one point or another. In the event of an attack, the attacker needs to move data either within the environment or outside of the environment. Typically you wouldn’t see huge amounts of data moving to a server in Eastern Europe. Or an open FTP server in Brazil. Or in a government processing center in China. So these are good indications that something may be a bit funky.
Now to be clear, network flow data is not going to be a definitive answer to the presence of an attack, which is probably why the network behavior analysis (NBA) market never really took off, especially for the security use case. But the data can tell you what isn’t normal and give you some more information to analyze and correlate. It’s really about having another data source to provide additional corroborating evidence to the potential presence of an attack.
As a bit of a unplanned benefit, your network operations folks could be very interested in building their own alerts based on network flows because not only can flow data detect attacks, it also pinpoint network performance issues pretty effectively. So here is yet another reason that log data is not enough, and security professionals need to go Beyond Log Management to keep pace with today’s attacks.
Ten Reasons Log Data is Not Enough: #3. What’s the Configuration, Kenneth?
September 10, 2009
As we resume our series on why Log Data is Not Enough, the 3rd reason we have underscores the importance of configuration data as part of the security analysis. As we’ve repeatedly mentioned, log management systems are driven by log data. And as we showed in Reason #1, logging can (and usually is) turned off – by savvy attackers anyway.
So how do you detect an attack, if you have no log data to analyze? Basically you need other data sources to figure out what’s happening and that is where configuration data comes in. Every device (whether it’s a firewall, switch, Windows Server, Linux Server, desktops, etc.) has a configuration and you can poll that configuration (with proper authorization) to figure out what’s going on.
Note you have to PULL the config data out of the device. It’s not going to just send it to you (like with log data), so this is actually a big deal to have in a security management platform. It’s a totally different way to gather data and is very hard to do in a scalable fashion with the reliability enterprises demand.
Once you have the configuration baseline, then you can compare new versions of the config to the baseline at a user defined interval. If something changes (like logging is turned off, a new service is turned on, or a registry change happens, for example), it will create an event in the system that can then be used with other data types to determine if it’s really an attack.
Remember systems relying just on log data can’t do this level of analysis. And those vendors that say they do require customers to buy a totally different product with a totally different management interface. Many of these other folks ONLY track network device configuration as well.
So this is another reason that Log Data is Not Enough, and those folks that know they need to go beyond compliance know they need to go beyond log management.
Ten Reasons Log Data is Not Enough: #2. Partial Regulation Coverage
September 8, 2009
For those organizations looking specifically to check the compliance box, log management is one of the things towards to top of their shopping list. I mean, the product is called out specifically in Requirement 10 of PCI, and is a “best practice” in many other regulations and frameworks.
And a lot of organizations just figure if they only deploy a log manager, and a web application firewall, and a regular firewall, and anti-virus – they’ll be in good shape when the PCI assessor shows up to put your organization through its paces. And depending on the assessor, you may be right.
But to be clear, those thinking that log management = compliance are sorely mistaken. Putting on my master of the obvious hat, log management products are driven by logs (duh!). But the logs can’t tell you if AV is installed on a device and if the signatures are up to date. It can’t tell you how the database device is configured. Logs don’t tell you whether the default passwords have been changed on sensitive devices or whether the firewall policies are in place.
To get answers to those questions, you need to go beyond log data and look at the configuration and asset data of these devices. eIQ is the only security information and event management (SIEM)/log management solution to aggregate and analyze configuration and asset data as part of security analysis. And we don’t stop there, we also look at performance, vulnerability, and network flow data, in addition to logs.
As we continue through the 10 reasons, you’ll hear all about these other data types. But in the meantime, just remember that log data is not enough.
Till next time…
LogDataisNOTEnough.com
April 15, 2009
Today we launched both a major update to our corporate site (http://www.eiqnetworks.com) as well as a new site called Log Data is Not Enough (http://www.logdataisnotenough.com). LogdataISNotEnough.com features a funny video about a data breach and it’s impact. If you like 24, you’ll like the video. There is also a bunch of educational material on the site about dealing with a data breach and the like. Enjoy, and tell your friends about it.
