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.
More thoughts on “After the Breach”
October 29, 2009
A couple of days ago, the folks at McAfee put up a very good blog post really delving into the specifics of what to do when you find a data breach. To be clear, there are few days for a security professional that are more important than QUICKLY identifying the root cause of the breach, fixing what can be fixed, and taking down what can’t. Remember, it’s about containing the damage and living to fight another day.
But let’s level set up front. Breaches happen TO EVERYONE. If you have been doing security for any length of time, your networks/systems will be compromised. That’s the nature of the beast. That’s why in my book on building a security program, “The Pragmatic CSO” I advocated a process to define incident response and stressed the importance of documenting and practicing that process.
Interestingly enough, the McAfee post highlights some things about investigation and recovery that are not as commonly known as they should be. First that the attackers are usually long gone before you discover the issue. That does happen sometime, but for those that implement a philosophy of “react faster,” and monitor their key systems (which you need to do for PCI compliance anyway), the hope is that you do catch the bad guys “in the act.”
Secondly, you CAN’T TRUST logs. That’s right, log management is something that eIQ does and I’m still here saying you can’t trust the logs entirely. Why? Because a savvy attacker is going to shut down logging. Or they are going to tamper with system logs. Only by externalizing the log files and supplementing with additional data types can the logs truly become useful. That’s right – log data is not enough.
To be clear, when you are investigating a breach and trying to contain the damage – more data is better than less data. I’m not saying at all that logs aren’t important. I’m saying that you need as much corroborating evidence as you can gather. Anything to validate the attack vectors and more accurately piece together what happened.
The McAfee post goes on to highlight the steps of an incident response plan (identify the breach, contain the damage, make sure it doesn’t happen again) and those recommendations are good. I’d also highlight the need to do an incident post-mortem, document the findings and make sure the situation is discussed at all levels of the organization. Breaches happen, there is no shame in that. But not learning from each successful attack and improving your organization’s ability to defend itself is the real sin.
eIQcast Episode 22: Update on PCI
October 28, 2009
Discussions about PCI-DSS rules this year have focused on how effective the guidelines really are at preventing theft of credit card data. Recent survey data indicates merely following PCI does not protect a wide range of protected data.
In the newest episode of the eIQcast, eIQneworks Product Evangelist John Linkous provides an update on PCI compliance and how far it goes to actually keep credit card data secure.
Running time: 10:38
Direct Link: http://eiqcast.podOmatic.com/entry/2009-10-28T13_09_11-07_00
The Best Security Reacts Quickly to Change
October 22, 2009
I’m certainly not above lifting verbatim research that I believe is helpful to security and compliance practitioners. And the title of this post was lifted from Gartner’s John Pescatore’s post entitled “Who Moved My Soap – The Best Security Reacts Quickly to Change.” Now I could go forth with all sorts of don’t drop the soap in DisneyWorld jokes, but that would obscure the real point, which is not about Pescatore’s hygienic preferences.
Security professionals are not driving the ship. The business folks are. So security folks that are resistant to the ebbs and flows of business will not be successful. We have to face the reality that we (as security professionals) need to adapt our defenses both to the actions of our adversaries, as well as the reality of our businesses. Budgets come and go, projects are re-scoped, and priorities change. That’s business. That’s life. Deal with it.
But you cannot adapt in a vacuum. In order to react quickly (which sounds very similar to my personal REACT FASTER mantra), an organization needs to understand what they are looking for. That means they need to be monitoring as much as they can, establishing what is “normal” in their environment and then watching for what is NOT normal. Things change all the time, but if you don’t know HOW they are changing, there is no way you’ll be able to understand WHY things have changed, and therefore you’ve got no shot to address the issue…before it’s too late.
Oh yeah, did I mention I’m a big fan of security monitoring?
ReadySpace Selects eIQ to Drive Managed Security Service
October 21, 2009
Yesterday, eIQ announced that ReadySpace, a global services provider headquartered in Singapore, has selected eIQ SecureVue as the basis for a new set of managed security services focusing on real-time security posture and compliance automation. ReadySpace’s head of managed services, David Loke, had this to say about SecureVue:
“During our evaluation in a controlled environment, ReadySpace found that eIQnetworks solutions identified, within 3-Clicks, thousands of different attacks on our servers which had subsequently been infected by viruses that other security products would have completely missed. SecureVue, with 2 more Clicks then reported the extent of the infection, successfully identifying that our servers had become the attackers,” said David Loke, head of managed services at ReadySpace. “We agree that log data is not enough to manage the security for our hosted customers, which include well-known brands such as eBay and Singapore Airlines. There is a need to look at and consistently correlate far more information to provide managed service customers with complete visibility. eIQnetworks’ SecureVue provides exactly that.”
I couldn’t have said it better myself. Our competitive win over other SIEM and log management vendors at ReadySpace really highlights the power of using SecureVue in a managed services model. MSSPs can start with a simple security monitoring service and layer on additional services (like compliance reporting, correlation, performance management, and network behavioral analysis) for an increased price. The cost of the SecureVue platform is covered by the first service sold and the rest is PURE PROFIT. It’s a very powerful model for service providers looking to broaden their service offerings to customers.
We are pleased that ReadySpace has joined the eIQ family and are looking forward to working with them to solve their customer’s joint security and compliance problems.
You can check out the full release here.
eIQcast Episode 21: The Role of File Integrity Monitoring
October 20, 2009
In this episode of the eIQcast, Mike Rothman dives into the nuances of file integrity monitoring and why it’s an important aspect of both security and compliance. One of the first things an attacker is going to do is mess around with system files, so having some mechanism to ensure that system files, registry values and the like aren’t tampered with is a big part of “reacting faster” to potential security issues.Mike also discusses how eIQ’s SecureVue security and compliance management platform provides this capability through it’s newly updated agent technology, continuing to show technical innovation beyond simple security information and event management (SIEM) and log management solutions.
Running time: 10:41
Direct Link: http://eiqcast.podOmatic.com/entry/2009-10-20T13_58_46-07_00
Don’t be like Dick and check out eIQ’s video at logdataisnotenough.com
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.
Let’s have a candid discussion about rogue devices, shall we? You know, the unauthorized access point plugged into a port in a conference or under someone’s desk. Or maybe the network behind the off-shore contractors you have maintaining legacy applications. Perhaps someone is running a side business during work hours on a device they bring from home ON YOUR NETWORK.
Each of these scenarios (regardless of how contrived) happen each day. And every new device presents a significant risk to your environment. Which means you need to be constantly watching for these devices and make sure they are not wreaking havoc. In fact, this is one of the key use cases for network access control (NAC). Of course, that technology is struggling, but it’s not because of the lack of a problem to solve.
So if you are looking at a log management or security information and event management (SIEM) product, won’t that tell you about new devices? Won’t it see something funky and flag it? Well, actually no it doesn’t. Log Management requires logs and your typical rouge device isn’t too interested in forwarding its logs to much of anything. That’s right, each managed device needs to be configured to push log files to the log management product. If that doesn’t happen, the SIEM is blissfully unaware anything is going on – until a number of managed devices are compromised – which is too late.
Yes, network devices (at least the right ones) can detect rogue devices and potentially quarantine those until the proper authorization is presented. But what if you don’t have NAC or can’t afford to upgrade your entire switching infrastructure? That’s right, you need to go beyond log data.
As mentioned in reason #4 about network flows, the network never lies. So we’ve got to look for new network devices and then kick off a scan to figure out what it is and whether it’s authorized. eIQ SecureVue makes that pretty simple. You can set a policy to check for any new IP addresses within a specific time period. Then from right within SecureVue, you can kick off a vulnerability scan to figure out what is the story with that device. Once you figure out what it is, then you can understand whether it should be there.
Additionally, you can set network flow policies to check for traffic leaving the network from unmanaged devices. This kind of extrusion monitoring will tell you if a device is moving data off the network. Maybe they should be, maybe not. But the point is to gain situational awareness of what’s happening in your environment. And just looking at the log data is not going to get you there.
eIQcast Episode 20: Seeing Through the Clouds
September 30, 2009
In this the 20th episode of the eIQcast, eIQnetworks SVP of Strategy Mike Rothman discusses some of the challenges of cloud computing with Ross Levanto. Mike goes into the issues of maintaining visibility when networks and systems reside in someone else’s data center, and some of the mechanisms eIQ is adding to SecureVue to help customers address this issue.
Yesterday eIQ announced a new capability within SecureVue to provide enhanced visibility for virtualized data centers and cloud computing models. SecureVue now includes a mapping feature which allows security professionals to keep track of which virtual machines are running on specific hardware devices, which facilitates the investigation and remediation for issues within a virtual data center. Check out the release for more detail on http://www.eiqnetworks.com.
Running time: 11:40
Direct Link: http://eiqcast.podOmatic.com/entry/2009-09-30T05_17_07-07_00
Don’t be like Dick and check out eIQ’s video at logdataisnotenough.com
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.
