Ten Reasons Log Data is Not Enough #7: Your SIEM forgets
October 13, 2009
Am I being attacked? Don't know, I forget...
Today’s attackers are very patient. The old “smash and grab,” where the attacker tries to get as much data as quickly as possible is gone. Basically because most enterprises have gotten pretty good at detecting those kinds of attacks. The correlation engines built into security information and event management systems (SIEM) are finely tuned to look for these kinds of attacks. And the attackers know that.
So like any other businessmen (and women), the bad guys have adapted. They know the defenses, so they are working around them to ensure a constant flow of stolen data. They have lots of mouths to feed, don’t you know! One of the ways they’ve adapted is to mount a low and slow attack, since they know the SIEM product can only correlate across a few days (typically 3-5) of data. So they know if they wait for 10 days between stages of their attacks, they are less likely to get caught. And more likely to keep stealing information.
It’s actually kind of dastardly ingenious. They compromise a device, turn off logging, install stuff, turn logging back on and then wait. A few days later, they go back into the machine, look for additional vulnerable devices, compromise another and then wait some more. Yes, these attacks can happen over a few months. But don’t feel bad for the attackers, I doubt a lot of them have low golf handicaps. They are working hundreds of attacks on thousands of zombies at the same time.
So how do you detect this kind of low and slow attack. Well, we’ve already discussed how to deal with the reality that logging will be turned off by the attackers. Another method we use at eIQ is to extend the correlation window. That’s right, SecureVue correlates data for up to 90 days, outside the attack windows of even the most patient attacker.
Gosh, that seems too easy. Why don’t other SIEM vendors do the same thing? Because it’s hard and it requires a purpose-built architecture to maintain that much data in memory to do correlation across that length of time. Other SIEM and log management offerings would need to totally rebuild their offerings to provide a similar capability, and we know that isn’t going to happen.
You can think of most SIEM products as having Alzheimer’s, as sad as that is. They have very limited short term memory and their long term memory is shot. And that’s what the attackers are counting on. Which is another reason that log data is not enough.
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.
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
Correlation is in the eye of the beholder
August 6, 2009
As I’ve written frequently, both privately (here) and for eIQ (link), one of the key issues with the SIEM market has been the failure to meet customer expectations. A lot of that has to do with correlation, or lack thereof.
How about this eye?
Just to refresh our minds, the idea of correlation originated very early on IT management disciplines and involved the need to take events from lots of different places and make sense of them. The need for correlation has become acute over the past few years as the velocity of everything has increased. IT systems are deployed faster to more customers providing access to private and sensitive data. Those systems create attack vectors and present potential exploits to allow the leakage of said data.
Compounding this are today’s attacks designed to circumvent traditional defenses and stay “under the radar,” so the perpetrators can continually mine an organization for more sensitive data. The ability to cloak an attack has also improved, mostly through the use of compromised machines (zombies) as proxies to undertake the attackers dastardly tidings. So not only is more sensitive data available for compromise, it’s easier to attack and harder to track the attackers. No wonder so many security folks are miserable.
All this activity results in more stuff to track and inevitable causes more noise than ever before. Noise is the security professionals arch-enemy because we only have 18-20 hours a day to investigate potential security issues. Who needs sleep anyway? If we wanted to investigate every potential attack, we’d have to deploy that time expander and get maybe 50-60 hours of activity into each day.
That’s right, we need to be more efficient, without sacrificing effectiveness. The only way I know to do this is to automate as much as possible and that’s where correlation comes in. If we can have a machine looking at all the data, matching patterns and highlighting potential issues, we can focus our (human) efforts on only the attacks that represent the biggest chance of compromise.
Which is the crux of the issue. How do you define those patterns that potentially represent a significant attack? I could lie to you (like most vendors in the space) and talk about how wonderful my widget is OOTB (out of the box capabilities) and how all you have to do is plug it in and it’ll tell you exactly what’s happening. I could, but it would be the wrong thing to do.
The right thing to do is to manage your expectations appropriately. Every vendor’s OOTB capabilities are a STARTING POINT. eIQ ships with 250+ pre-built correlation policies. Quite a few will be appropriate for your environment. Others will not. And the only way to figure out which is which is to analyze the data and refine the policies.
The idea of a “self-tuning” SIEM is hogwash. Yes, by analyzing data, baselines can be determined and a set of initial policies be deployed. But those policies need to be fine tuned and revisited frequently. Not because they are wrong, but because the world is a dynamic place and things change – frequently. Which means your security monitoring must change frequently as well.
The reality is if more customers went into a SIEM project understanding that correlation is like a funnel and at first the top of the funnel is big. Over time (and with effort) the funnel can be narrowed, until things change and then you have to recalibrate and refine. Over and over again. Yes, it’s a treadmill, but so is everything in security.
Effective correlation is possible. And with the right expectations and resources, it’s even probable. But not if you expect it to happen OOTB.
Defining SIEM/Log Management “Integration”
July 22, 2009
integrate
verb [ trans. ]
1 combine (two things) so that they become a whole
Based on market dynamics and confirmed with the recent Gartner MQ criteria, there are no longer separate log management and SIEM markets. Thus,
Oil and Water: Not Integrated
every vendor is talking about their “integrated” solution. What’s comical is how many of the players in the market define “integrated.” So before I define our idea of integrated, let’s talk about what integrated is NOT.
- If a vendor requires you buy two different technology hardware platforms, with (at least) two different data stores – it’s not integrated.
- If a vendor requires two platforms, one to collect data at high speed and another to analyze the data because they can’t analyze fast enough – that’s not integrated either.
- If the vendor’s correlation engine is outsourced, acquired, or licensed from another technology vendor , the solution is not integrated.
- If the vendor has totally different interfaces for their SIEM and log management offerings, that’s not integrated by a long shot.
- If the product doesn’t correlate all data because that’s too hard and their product would require a Cray supercomputer to keep pace, which forces a log-only collection layer to capture all that data – it’s not integrated.
- If a product needs to archive data off their platform after 30 days because it slows down the correlation engine, and then forces you to use a separate appliance to do a forensic search of the archived data – you got it, it’s not integrated.
- If the vendor talks about network configuration management, but it’s nothing more than a bolt-on of a failed product they acquired for cents on the dollar – that’s not really integrated either.
- If a vendor talks about an integrated solution, yet their design looks like the schematic of a nuclear reactor – you got it, it’s probably not integrated.
So what does eIQ mean when we say “integrated.”
- Single platform and single data store – SecureVue is one INTEGRATED product. You buy it once, deploy it once and both the SIEM and log management capabilities are built into the platform natively. No separate boxes or different interfaces are required.
- Scalable from the entry level to the largest enterprises – Data collection can happen on same box or within a multi-tier architecture, with same level of correlation, reporting, dashboards. SecureVue is linearly scalable, there is no need to deploy a front end logging layer to overcome a dog-slow correlation engine.
- Correlation is done on ALL data – SecureVue uses all data in its correlation analysis, there is no “selective” data forwarding from the logging layer to reduce the amount of data to correlate.
- Reports and Compliance Audits are pulled from ALL data – Similarly some of the competition basically discards data they don’t term as “relevant” for reporting and audit information. SecureVue doesn’t have those limitations, so reports can be pulled on all data collected and archived.
Delivering an integrated system is hard. That’s why most of the vendors out there wave their hands a lot, but don’t really want you to look behind the curtain. Integration requires a single interface, not a cobbled together console with totally different user experiences. Integration requires a purpose-built data store, not your favorite relational database. These folks built on a relational back-end would need a brain transplant to do all the processing required to do integrated SIEM/log management on a single platform. Brain transplants are hard too.
So they don’t DO integration, they just talk integration. They just glue an “integrated” sticker in the front of the multiples of boxes and hope no one really asks what integrated means.
Hopefully Mr. market is smarter than that.
SIEM still struggles (and it’s our own fault)
June 18, 2009
One of the research positions that I took in my old research shop was that SIEM (security information and event management) never really met the needs of customers and suffered from a value disconnect. The solutions basically were too expensive, took too long to implement and required too much tuning to achieve value quickly enough to make it worth the effort.
And even after 10 years of trying to get it right, according to a recent Aberdeen Group study [highlighted in this Dark Reading piece), the industry in general is still screwing it up. Here is a pretty telling quote from the Aberdeen report:
“The majority of respondents have not yet achieved those quantifiable benefits, and in some cases are seeing increases in audit deficiencies, security incidents. and operational costs associated with security management.”
They go on to say it’s not the tools, it’s the way the tools are implemented. Given that the sponsor of the study, Vigilant is in the business of SIEM implementation – the conclusion is far from surprising. And it’s also right, the technology has matured significantly over the past few years. And folks like eIQ are adding more data types and pushing the envelope on scalability and the ability to detect new attack vectors.
Yet, it seems to always get back to expectations. The vendors positioned the technology as the Rosetta stone of all things security, and sorry folks – there is no Rosetta Stone. Unless you want to learn Mandarin or some other foreign language. No set of technologies or automation is going to eliminate the need for having smart folks who understand your environment, looking for bad things.
What SIEM (and the larger security and compliance management platform) can and should do is give those analysts BETTER INFORMATION. The point isn’t to eliminate those folks, it’s to make them more effective and efficient. It’s about focusing on the short term problem (you know, the one that has funding), but making sure to pay attention to the longer term strategy. I call this “buying tactically, but with an eye to the future.” So you may be solving a compliance problem right now, but doesn’t it make more sense to make sure you also get security operations help and also forensics and configuration audit?
But to be clear, a successful implementation requires investment. Not only the product itself and likely services to implement (like the stuff Vigilant does), but also a senior level commitment to embrace automation and rework security operational processes to use the tools. In the short term, it’s always easier to throw people at the problem, but that’ s not really feasible in today’s economy. And given the increasing complexity of today’s technology environment, it’s also the wrong answer strategically.
So automation is the only way you are going to keep pace, but embrace automation with your eyes open. It takes work. Work we’ve seen that’s well worth the effort, but it’s work nonetheless. Regardless of what the vendor is telling you.
It’s too bad the security management market continues to set the wrong expectations, as clearly evidenced by the Aberdeen study. Messages like “easy PCI compliance” are hurting the perception of SIEM technology and giving everyone a black eye. At eIQ, we try to paint a realistic picture of what’s going to be required during the implementation.
Customers have choices in who they select as their security management partner. They can keep their happy ears and pick the vendor that tells them what they want to hear. But truth be told, I’d rather not win those deals. Because there really is no “winner” at all, the customer will be disappointed and the vendor will get a black eye.
And everyone loses.
How to use Gartner’s SIEM MQ
June 16, 2009
Yes, that’s right. Our friends at Gartner have published their 2009 Magic Quadrant on Security Information and Event Management for Gartner clients. eIQnetworks is placed in the visionary quadrant.
Mark Nicolett hijacked John Pescatore’s blog for a day to clarify how to use the MQ. In the post, he describes leaders and visionaries: “Vendors that are in the leaders or visionary quadrant meet the major functional requirements of the broad SIEM market.“
The difference between a leader and a visionary? The post states: “Visionary vendors have scored lower in ability to execute (most often due to smaller company size or installed base or growth rate) as compared to leaders.” eIQ has been addressing the enterprise space for a touch over two years (as compared to the other leaders and visionaries in the space for 7-10 years), so we are pleased with our placement.
Yet, Mark Nicolett cautions customers against reading too much into the placements in the chart.
The written research is intended as a starting point for a product selection decision. We really encourage Gartner clients to use our inquiry process to augment your use of the published research. The idea is to get on the phone with us so that we can provide more specific advice based on the client’s environment.
Being a former analyst, I totally agree with Mark’s assessment here. It’s easy to just look at the chart and pick only the leaders to engage with and be done with it. But it would be the wrong thing to do, since visionaries usually bring a different perspective and set of capabilities to the table. At least eIQ does.
Rothman on Beyond the Perimeter Podcast
June 10, 2009
My friend Amrit Williams, CTO of BigFix, invited me to speak on his “Beyond the Perimeter” podcast yesterday. Big mistake for him. Kidding aside, we had a good conversation about a number of things, including how security needs to evolve and why his podcast is called “Beyond the Perimeter.”
Amrit Williams, CTO of Big Fix
Amrit used to cover SIEM (he claims to have originated the term back in the day, while he was burying Jimmy Hoffa, clearly) for Gartner, so we chatted quite a bit about how the industry has evolved and where it’s going, especially relative to emerging compliance requirements.
Here is Amrit’s description:
Episode 26 – Situational Awareness Inside and Beyond the Perimeter
Amrit Williams, CTO of BigFix, Inc. speaks with Mike Rothman, founder of Security Incite and recently hired Senior Vice President of eiQ network on the need to secure information wherever it resides or travels, and a pendulum shift away from log management back to situational awareness. According to Rothman, the emphasis on log management trend stemmed from organizations taking a “check off” approach to information stewardship compliance programs. The renewed interest in situational awareness results from realization that log management alone is not enough to understand, respond, or prevent security breaches–in short, what’s really at stake in information security.
Going Beyond Traditional SIEM
March 18, 2009
We recently recorded an audio program with Gartner’s Marc Nicolett to discuss issues related to security and compliance based on what he is seeing out there in the market. To listen, you’ll need to register on the eIQ website.
Here is the description:
Join this exclusive eIQnetworks podcast to hear Gartner’s VP and
Distinguished Analyst Mark Nicolett and Mike Rothman, eIQnetworks Senior Vice President of Strategy, discuss the important ways that SIEM can solve enterprise problems today. Mark Nicolett delves into why organizations should consider a holistic approach to security and compliance management to more effectively monitor for potential attacks, anomalies and trends, and how this data helps enterprises enforce compliance mandates spanning laws, regulations, best practices, and internal requirements. Mike Rothman then presents trends he is seeing in the market, which underscore why security and compliance management must transcend traditional SIEM data to include broader visibility into enterprise IT.
Follow this link to check it out: http://www.eiqnetworks.com/news/Gartner_Podcast.shtml
