What’s disturbing, however, is hearing these same potential customers say to us, “SIEM vendor [x] sent us over their data sheet, and they collect configuration data just like you guys do…” obviously, the FUD and “creative marketing” are in full gear at some of our competitors.  Let’s be clear: log-based configuration data is not true configuration data.  Any LM/SIEM vendor who tells their customers that they can achieve effective security and/or compliance solely by piecing together configuration-related events, without actively querying systems for configuration data, is doing their customers a tremendous dis-service, and potentially placing them at risk.

But why, you might ask?  Can’t you log just about everything related to system configurations, from installed applications and services, to hardware and device changes?  Yes… and no.  Like many things, the problem with log-based configuration data is in the details:

• What if Logging is Disabled? While basic logging is enabled by default on most operating systems, logging services can be disabled by malicious users and rogue applications. Attackers know that organizations rely heavily on log data for security, and will disable logs whenever possible to cover their tracks.
• What if Logging of Configuration Data is not Enabled? By default, many different types of security information are not logged – for example, changes to Windows registry settings, and events associated with many different UNIX daemons. In addition, most firewalls, routers, and other devices do not have any configuration auditing enabled by default. To capture this information, a system administrator must forcibly enable logging of this data, and ensure that enough log space is available to store it.
• What if Required Configuration Data Cannot be Logged? Certain types of security configuration data simply have no native mechanism for logging, such as Windows registry access control settings. To capture this data in logs, system administrators must build “adapters”, “connectors” or other shim-type solutions to capture this data – if this can even be done for the configuration data required.
• What if Historical Log Data Doesn’t Reflect Actual Configurations? Log data can only piece together individual events that “should” represent the current state of what a system looks like. But does this reflect the actual and current system configuration?
• What if Logs Become Full? Systems and network devices maintain a finite space for log data. Enabling certain high-volume log events, such as system performance metrics, can rapidly fill up available log space, causing the system to either begin over-writing log data or – even more dangerously – begin dropping information that can’t be written to full logs.

And of course, capturing real configuration data is still only half the story; to be really useful, security solutions that collect both log and configuration data need to be able to correlate them; if a potential attack occurs on a system — a large number of failed logons, or perhaps an IDS event suggesting a system compromise – it’s critical to be able to correlate this with changes on the system over time.

LM/SIEM solutions are getting better with time; vendors are finally listening to customers who are demanding comprehensive solutions that address a broad range of security data, not just logs and events.  But it’s critical to understand that different vendors mean different things when they say that they collect “configuration data” — choose wisely.

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.

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.

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

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?

“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.

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.

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