Skip to content

Configuration Data: The Emperor’s New Clothes

December 14, 2009

Recently at eIQ, we’ve been meeting with some potential customers who have been comparing our SecureVue platform to log management and SIEM tools.  Certainly, that comparison has merit; like LM/SIEM tools, we capture and correlate log and event data from operating systems, network devices, applications, and databases.  Interestingly enough, we’re also seeing these customers really beginning to embrace the idea that log data is simply not enough to address many security threats, or meet compliance with a host of regulations, best practices, and frameworks.  This is great news; we’ve been preaching this for years now, and it’s great to see our competitors finally accept, however grudgingly, that they need to start capturing and correlating more than just log data.

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.

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: