Security Best Practices, Linkous-style
September 25, 2009
Secure Your Stuff or you'll be a pillar of salt
eIQ’s own security and compliance evangelist John Linkous took some time to step away from his bully pulpit to contribute a list of practices for Linda Musthaler’s Network World column. Although he’s no Jim Bakker, John can sling security fire and brimstone with the best of them. He provides some good food for thought for any security professional. Check it out and be converted.
Ten Reasons Log Data is Not Enough: #5. Who dat installing software?
September 21, 2009
As we continue down our analysis of why log data is not enough, the next issue we discover is installed software. Most malware (at least persistent malware) will do some kind of installation of the malicious code to steal data, which could be sniffing network traffic or key strokes or account numbers. The list goes on and on. Many log management or security information and event management (SIEM) products will look at logs to figure out if some software was installed.
So that should solve the problem, right? The host log says software was installed and then you’ll know malware has been installed, act decisively and be the hero. Well, not so much. Do you know how many times a day a typical enterprise installs software on it’s managed devices. Hundreds? Thousands? More? It’s very likely too much for human analysis to figure out. What about those fancy correlation engines that will look for bad software? Hmm. For that to work, it needs to have a list of “good” software – which is always changing. I hope you are good with coding and regular expressions, because you’ll need to build a number of custom rules to make that work in a SIEM product.
The key is to be able to ENFORCE POLICY. As we discussed in Reason #3 about configuration data, the key to reacting faster to emerging threats is to detect something different, anomalous, and not normal. By establishing a set of policies for what software is allowed and then detecting when a device violates that policy, you can reduce the noise of watching every software install.
All of the anti-virus companies are talking about their shiny new, white-listing widget, and justifiably so. Taking a positive security approach (only allowing authorized software to run on managed devices) will definitely reduce the likelihood of infection. So this idea of monitoring for new software installs is sort of a poor-man’s white-listing.
Which is really the point of this entire series. There are many defensive techniques that are required to keep pace with today’s attackers. Just relying on a log management toaster or a SIEM “in a box” is not going to get the results you are looking for. Aggregating, parsing and even correlating on log data is just not enough.
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.
Press Release: ComplianceVue Packages for PCI, NERC and HIPAA
September 9, 2009
Today eIQ announced new ComplianceVue Packages, a turnkey offering to address compliance reporting requirements based on its SecureVue® security and compliance management platform. The ComplianceVueTM packages (PCIVueTM, NERCVueTM, and HIPAAVueTM) provide detailed compliance reporting across more than just log data, greatly surpassing the capabilities of competitive products. ComplianceVue packages are available immediately to address PCI-DSS, NERC CIP and HIPAA regulatory requirements.
“eIQnetworks already correlates data from more data sources than any other solution on the market, and for that reason SecureVue is uniquely positioned to identify sophisticated in-progress attacks or vulnerabilities that log-only solutions will miss,” said Vijay Basani, eIQnetworks’ CEO. “With the ComplianceVue packages, eIQ now offers a turnkey solution for comprehensive compliance reporting across a broad range of security data including events, configuration data, vulnerabilities, and network flows, proving again that ‘log data is not enough’ to properly prove adherence to regulatory rules.”
The new ComplianceVue packages include a SecureVue Central Server, and the associated compliance reporting modules and dashboards required to provide necessary documentation for regulatory-driven audits. Reporting is effortless, and section-specific compliance reports are directly linked to appropriate rules and requirements of each supported regulation, best practice, or standard. Interactive dashboards provide real-time views into key compliance metrics, and provide drill-down into underlying data to support comprehensive internal and external auditing needs.
For more details and benefits on the new ComplianceVue package, check out the full press release on the eIQ site: “eIQnetworks Introduces ComplianceVue Packages for PCI, NERC and HIPAA to Streamline Regulatory Compliance Reporting”
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…
Ten Reasons Log Data is Not Enough: #1. Logging can be turned off
September 3, 2009
Welcome to the latest series here on eIQviews. Over the next 10 days, we’ll discuss a number of reasons that log data is not enough. And no, Bunny (from the movie) will not be making a guest appearance. Sorry to disappoint your folks.
If you ask nicely, maybe they won't turn logging off!
The first of the reasons that log data is not enough is so simple, sometimes you kind of forget about it. Actually, given the amount of time we spend harping on it, I’d hope you don’t forget, but let’s go through it anyway. Log management systems are driven by log data. Security information and event management (SIEM) systems are driven by log data as well. Yes, I know, that’s quite an insight. But one of the first things that even the least savvy attacker is going to do upon compromising a device is to (you ready?) turn logging off.
I know, it can’t be that simple. But in many cases it is. The attacker turns off the logging, does their evil tidings, turns logging back on and the log management and/or SIEM system doesn’t know the difference. Sure, you can set most log management systems to alert if you don’t get logs for a certain amount of time. How long do you think it takes the bad guys to make changes and install malware on a device? Right, not that long.
So unless you have a very short time period defined in that alert (think minutes, not hours), which will create a lot of noise and false positives, you are going to miss the attacker that shuts down logging. So your fancy log management system, which is supposed to make you compliant, isn’t much help.
Then again, we all acknowledge that compliance does not equal security. And neither does log management. Thus, the first reason that log data is not enough.
It continues to astound me the number of end users I talk to that are looking specifically for log management. My first question is why? 90% of the time they say they’ve got a compliance problem. And they are convinced log management is the answer to their compliance problem.
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.
Bloor Research Report on SecureVue
August 26, 2009
Recently Bloor Research published an InDetail report on SecureVue, eIQ’s SIEM/Security and Compliance Management Product.
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
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.
