How long to keep security data?
August 24, 2009
In digging back through some of my bookmark archives, I came across this post from Burton’s Trent Henry about how much (and what kind) of log data should you be storing. Now to level set, Trent is talking specifically about logs and we all know that Log Data is Not Enough, so I’d extend the same conversation to include a broader data set, including configuration, asset, performance, vulnerability and network flow data. Yet the general discussion and concepts are consistent when considering the idea of security data, regardless of how broadly you define that term.
Keep those logs till their petrified, y'all!
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:
- Useful from a security operations standpoint
- 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.
What we learn from Log Data
April 9, 2009
As we continue through our series on Log Management, let’s evaluate the kinds of information that are available from the typical log records we see and what we can learn from them.
First, keep in mind that pretty much everything can generate a log file for just about anything that it does. So one of the first places we’ll look is the firewall. Why? Simply put, the firewall is the first line of defense. So what kind of stuff are we looking for in the firewall logs? Here a little list:
- Traffic for unused ports – This is a pretty simple one because it’s usually indicative of some attack. After all, why would legitimate traffic be sent using ports you don’t have on. Right, it wouldn’t. So this is typically reconnaissance traffic trying to figure out what holes the attackers can start to exploit.
- Failed logons – This is self-evident as well, given that one sure-fire way to compromise a firewall is to log into it. So brute force attacks are definitely something you’ll see. This is another reason changing the default password and not using a predictable user ID (like “admin”) is critical.
Outbound connections – Given the prevalent attack vector of compromising a server and then transferring that data outside of the organization, it makes sense to scrutinize strange outbound connections. Of course there are a bunch of other things to look for as well. And a log management system that is configured to watch for strange results in these logs can save your bacon.
Similarly, you can look for information in your intrusion detection/prevention (IPS) device as well. Things to look for here include:
- Attack signatures – since the IPS is firing, we know some kind of rule was violated. The attack type is helpful to understand what you are up against.
- IP addresses – You can learn a lot from the IP addresses of attack packets. Are they spoofed packets with an internal IP address? Do they originate from a web server in your DMZ? These are all clues to some type of successful attack.
There are similar nuggets of information in database logs (like connection type, application ID, transaction type, etc.), server and application logs as well. So there is no lack of log data to collect and analyze.
Not even Einstein could make heads or tails of all this log data that is gathered on an ongoing basis, especially given that the typical large enterprise has hundreds of network devices, tons of databases, and thousands of servers. Wading through Gigabytes of log data every day isn’t really practical (though it would make for an interesting Dilbert series).
Thus you need to automate the analysis and correlation of these logs. In future posts, I’ll discuss how this needs to work, and why merely correlating log files is inherently limiting. The key takeaway here is that there is a lot of great data in the logs; you just need to know how to leverage it.
The next topic in our Log Management series will discuss the intersection of log data and identity. Stay tuned for more information on log management.
Imitation and Flattery
March 11, 2009
You know the old saying, “Imitation is the sincerest form of flattery.” And that’s true, unless someone is imitating you. Then it’s just irritating.
Yet, that goes with the territory of building a product that redefines the market space. Maybe I’ve been breathing the eIQ exhaust for too long, but I see the recent product announcement from RSA on enVision 4.0 as clear validation of the technical direction eIQ pioneered almost 3 years ago when building SecureVue.
Basically RSA added a number of new capabilities to their log aggregation product, namely the ability to pull in asset data and also vulnerability data. This gives them the capability to get a little more intelligent about which events should result in alerts because of a broader correlation.
If you ask us, they are on the right trail, but they don’t go far enough to truly impact how a customer manages their security and compliance processes. By contrast, eIQ also gathers configuration, performance and network flow data. We put all this data into our correlation machine and draw more intelligent conclusions and help customer more effectively prioritize activities because we are looking a more diverse data stream.
We’re actually pretty comfortable that our technical differentiation will last for a while. And it’s not because that exhaust is so sweet smelling. It’s because gathering these additional data types is hard. Why do you think most of the vendors in the space are forced to use different appliances for SIEM and log management? Right, their data models don’t support the types of data at the speed and scalability required to solve both problems.
Lest the other folks in the space think we are resting on our laurels and standing still, you can forget that. We’ve got some stuff in limited customer deployment that will pretty much turn the industry inside/out. But I’m not in the business of pre-announcing anything, so that’s about all I’m going to say about that.
Of course, this is all the vendor’s version of he said/she said, and in reality most customers are just trying to solve a problem, be it doing better security with fewer resources or making the auditor go away with a smile on their face. They want the answer, not to hear about why our widget is better than theirs.
So I’ll just thank RSA for realizing that log data isn’t enough.
Photo credit: “Copycat” originally uploaded by miconian
The Change We Need (in Security Management)
January 26, 2009
In the aftermath of the historic inauguration of Barack Obama as the 44th President of the US, one of his catch phrases during the campaign really resonated with me.
“We can’t afford four more of the last eight.”
Now when we think about the security and compliance management markets, the same statement can be made. Sure it’s a little bold, but those of you familiar with my work before eIQ probably aren’t surprised. For the last eight years, security professionals have struggled with increasingly sophisticated attackers searching increasingly lucrative targets.
The old methods of trying to correlate event logs from our defensive tools like firewalls and IPSs aren’t working. I could argue that the approach never really worked. The attackers are too smart for that and half the time they shut off logging and the SIEM is none the smarter. That’s why we harp on the reality that log data is not enough.
And current generation SIEMs are just too hard to use, too expensive and provide limited value. Sure it’s a vendor speaking, but that’s what our customers are telling us.
Many of the companies I speak to are looking for change. They don’t necessarily expect to get “ahead of the threat,” but they need to be able to prioritize their efforts more effectively. Based upon what’s at risk, not just what’s being attacked.
That’s why eIQ focuses on a broader data set. Some of the competition have figured out that network flow data is useful in corroborating when an attack happens. But that’s just a start. We also look at configuration, asset, performance, vulnerability, along with event logs and network flows. This richer data set allows us to see things the competition can’t detect.
Interestingly enough, the existing generation of SIEM solutions have been around for about 8 years.
Photo credit: “Time for Change” originally uploaded by David Reece
