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.

But regardless of preferred attack vectors and attacker profiles (which organizations have relatively little influence over), the most telling statistic in the entire report relates to implemented security controls (which organizations most definitely do have influence over): 87% of data breaches were considered avoidable through simple or intermediate controls.

So if these controls are so easy to implement, why aren’t organizations doing so?  Information security, to borrow a common turn of phrase, is not rocket science.  Lots of sources out there (such as the Verizon report) give us a good, empirically-based understanding of who’s trying to get at our data, and how they’re doing it.  Organizations need to start getting better at implementing security controls, and especially the kind of low-hanging fruit singled-out by Verizon: monitoring, and especially for attacks over time.  According to the Verizon report, in over 50% of data breaches, the attacker (person or code) wandered around for a period of time between days and months before data was compromised.  And, in almost 50% of data breaches the amount of time it took for organizations to discover the breach of their data was measured in months.

Monitoring is the Achilles heel of most security programs — especially those driven by compliance standards or other mandates – because people tend to view compliance as a point-in-time event, rather than an ongoing process.  That’s not the case.  PCI DSS, SOX, FISMA — they all require covered entities to continuously monitor the security profile of their systems.  Any organization that views PCI DSS (for example) as a checklist exercise is simply begging to be breached.  Moreover, you have to have tools that can correlate data over time.  Low-and-slow attack profiles are intentionally designed to avoid point solutions that look at only one type of data; you need to be able to correlate across multiple types of data, or as we like to say around here, log data is not enough!

Yet, that goes with the territory of building a product that redefines the market space. Maybe I’ve been breathing the eIQ exhaust for too long, but I see the recent product announcement from RSA on enVision 4.0 as clear validation of the technical direction eIQ pioneered almost 3 years ago when building SecureVue.

Basically RSA added a number of new capabilities to their log aggregation product, namely the ability to pull in asset data and also vulnerability data. This gives them the capability to get a little more intelligent about which events should result in alerts because of a broader correlation.

If you ask us, they are on the right trail, but they don’t go far enough to truly impact how a customer manages their security and compliance processes. By contrast, eIQ also gathers configuration, performance and network flow data. We put all this data into our correlation machine and draw more intelligent conclusions and help customer more effectively prioritize activities because we are looking a more diverse data stream.

We’re actually pretty comfortable that our technical differentiation will last for a while. And it’s not because that exhaust is so sweet smelling. It’s because gathering these additional data types is hard. Why do you think most of the vendors in the space are forced to use different appliances for SIEM and log management? Right, their data models don’t support the types of data at the speed and scalability required to solve both problems.

Lest the other folks in the space think we are resting on our laurels and standing still, you can forget that. We’ve got some stuff in limited customer deployment that will pretty much turn the industry inside/out. But I’m not in the business of pre-announcing anything, so that’s about all I’m going to say about that.

Of course, this is all the vendor’s version of he said/she said, and in reality most customers are just trying to solve a problem, be it doing better security with fewer resources or making the auditor go away with a smile on their face. They want the answer, not to hear about why our widget is better than theirs.

So I’ll just thank RSA for realizing that log data isn’t enough.

Photo credit: “Copycat” originally uploaded by miconian

On the surface, this law – and the defined standards behind it – is strikingly complete for a state-level law, and is more comprehensive than what we’ve seen from other states.  Most unexpectedly, the standard includes a broad set of process controls (containing governance and assurance requirements) that, while not entirely complete (for example, data retention and restoration are not addressed), represent a very strong, programmatic approach to information security and privacy.  The process controls include mandates for: a comprehensive information security program; risk management; written policies (with sanctions!); access control; third-party certification; limited scope of the use of data; asset identification and classification; physical security; periodic review; and security program documentation.

The system security controls also mandated by the law and its corresponding standard include the scope of controls you would expect to find in a major security framework: secure authentication; access control; encryption for data in transit; encryption for data at rest; monitoring; system security mechanisms like firewalls and antimalware; patching; and employee awareness and training.

So what does this all tell us?  It tells us that states are starting to take security and privacy requirements seriously, in the absence of either federal mandates (which may explicitly cover personal data, but are not comprehensively audited) or industry standards (which may be audited frequently, but the scope of which does not specifically include personal data).  It also suggests that state-level security and privacy mandates are becoming more mature as time goes on: the overlap between state-level mandates and major security standards like ISO27001/2, COBIT, and NIST800-53 are decreasing, and as such, every organization operating states with these mandates needs to start looking at more complete, effective, and programmatic approaches to implementing security and privacy.

Most of all, it’s likely that, as time goes on, these state-level mandates are going to have some teeth to them; you can bet that cash-strapped states are going to look to fine-based sanctions for failure to comply with these regulations as a way to close burgeoning budget gaps.  Let’s hope that organizations can proactively address these requirements before they get hit with significant penalties.

For decades, this analogy used to hold to for IT, as well; IT departments managed the end-of-life (EOL) for enterprise assets, ranging from end-user desktops and laptops, to enterprise servers, to network infrastructure, applications, and management software.  Back in the good old days, vendors would establish support windows and EOL and enterprises of all sizes could bank on upgrading their equipment and software to ensure that they met industry-standard measurements of performance and capacity.

In today’s economy, however, this is not exactly how things work.  As the economic climate continues to worsen, the need to keep extending the life of existing equipment, software, and IT tools is critical to the profitability – and in some cases, survivability – of enterprises both large and small.  The problem is, of course, that older stuff tends to have fewer features than newer stuff, and usually doesn’t perform as well either.  Moreover, vendors are rarely extending their support to older technology, because (let’s face it) it’s expensive to support older software and hardware, and naturally, they want to keep a pipeline of new revenue coming in from upgrading customers.
So, this leaves customers in a bit of a pickle: enterprises of all sizes need to make existing systems and technologies last longer, to squeeze as much value as possible out of them.  And of course, if support isn’t available from the vendor, they’re left holding the bag of managing these assets until things turn around, or the cost of support exceeds the cost of upgrade.

This is a painful proposition; however, there are some useful, proven techniques for extending the life of technology while maintaining your sanity:

• Know your service agreements, when they expire, and whether the vendor offers extended support them.  For many technologies, third-party companies offer good deals on extended warranties and support for EOL’d technology, especially hardware.
• Identify the risks associated with aging assets.  Included in this is establishing thresholds to determine if/when technologies need to be replaced after the costs of supporting them are no longer worth what you’re getting out of them.
• Monitor everything you can, to pinpoint problems before the occur and justify decision making.   This includes not only the normal event-related stuff that is typically required for security, but other metrics that support capacity planning and help justify EOL when an asset is no longer worth supporting; this includes metrics like performance (e.g. CPU utilization), bandwidth (e.g., disk and network utilization), and asset data (such as versions of software that may be limited to running only on certain hardware).

It’s not easy going through periods of forcibly supporting aging hardware and software technologies; however, it does periodically happen, and organizations need establish a game plan to deal with making existing technologies go further as part of the inevitable budget stretching that will occur in lean times.

First up is COSO.  Several years before widespread adoption of the Internet, and before IT security became a concern to most organizations (and by definition, the confidentiality, integrity, and availability of IT data, infrastructure, and processes), COSO established a framework for how organizations could control and manage their own internal processes (financial, operational, or otherwise).  Originally authored by Coopers & Lybrand under the review of the Treadway Commission (itself a product of corporate malfeasance in the 1970’s), COSO establishes a way that organizations can organize and manage almost any business process (although it was specifically designed for financial accounting functions).  COSO also established the concept of a “maturity model” for organizations to measure the depth (think “degree of evolution”) of how they implemented these processes.  While COSO is a general framework (i.e., its governance model, risk model and controls are not specific to finance, IT, or any other business area), it can be (and often is) applied specifically to IT, especially those IT processes and controls that are governed by SOX.  First and foremost, COSO is focused on processes, and then associates information and controls with those processes.

COBIT, an IT-specific framework first published in 1994, is loosely based on COSO; that is, it a framework for processes, specific to IT.  In addition, COBIT provides hundreds of specific controls for each of these processes; in this way, COBIT describes high-level processes related to planning, implementing, and maintaining IT systems, while also giving them specific statements of how this should be done.  COBIT is, in some ways, analogous to the ISO27002 standard: it provides a recommendation of how to implement stuff that needs to get done for IT to function.  Unlike ISO27002, however, COBIT is not solely focused on information security – it addresses things like review and acquisition of technology and performance measurement, which are outside the traditional scope of security.  Also, unlike COSO, COBIT is focused first and foremost on information, and then associates processes and controls with this information.

From an implementation perspective, then, how do SOX, COSO, and COBIT relate to each other?  Much like the pieces of a puzzle, each connects with the other, while still providing something unique.  First off, it’s important to remember that no public company must use either COSO or COBIT; as long as an organization can demonstrate to an auditor that their controls and processes are reasonable, they should pass an audit – however, Big-4 firms have seized on these two frameworks as their own benchmark to determine whether their clients’ controls are adequate.  Second, although there are some points of connection between COSO and COBIT, they are not really competitive with each other.  Because COSO is a general framework, and COBIT is specific to IT, they can be – and often are – used simultaneously together: COSO as the criteria to audit general accounting processes, and COBIT to audit against IT-specific processes.  Regardless of whether an organization chooses to adopt COSO, COBIT, or a combination of the two in order to meet SOX compliance the fact that they are using a known, accepted framework for managing processes and controls puts that organization on the path to compliance.

Today, SIEM technologies generally rely on a fairly limited set of data: operating system and application log data (from sources such as syslog), Windows event logs, and (in some cases) vulnerability data from scanning engines.  While the events and other data collected from these sources are certainly related to each other from a security perspective, they don’t represent a truly complete set of data.  Looking at a typical security incident – such as a system breach initiated from either inside or outside the network – it’s clear that having access to other security-related data would provide organizations with a more broad set of information to properly identify and mitigate such an incident.

As an example, a SIEM tool is useful for determining when a system is compromised, since this information is generated in log events; but what happens when an attacker disables logging on a compromised system?  How can a SIEM determine when a malicious user installs trojaned code on a compromised host, or creates a new administrative account, when logging is disabled?  In these cases, having access to a broader set of data collected through methods other than logging – such as configuration and asset data, transport-layer or (preferably) application-layer network data, and even individual host performance metrics (e.g., CPU, disk usage, network bandwidth, etc.) gives organizations critical additional security information to maintain the confidentiality, integrity, and availability of data.

Another use case is compliance management; while the ability to capture, monitor, and alert on certain types of events is a critical function that SIEM solutions serve well, in reality, compliance is about a lot more than events; regulations and best practices such as PCI, COBIT (and by extension, SOX), ISO27002, and many others mandate not only the capturing of specific types of events, but also ensuring system configuration standards, and – in some cases, such as internal standards and metrics measurement – performance and capacity management.  Without the ability to capture configuration and asset data (e.g., installed applications, system patch levels, and file integrity checks), the role of SIEM tools in the world of compliance automation will be limited to small “wedges” of the compliance universe.  Until SIEM solutions evolve into more comprehensive engines for capturing a broader array of security data, their use will likely continue to be relegated to specific point solutions in customer environments, rather than functioning as enterprise platforms to support enterprise-wide security, risk and compliance.

Next Up: Why scalability becomes increasingly important for SIEM.

This customer – like so many others across the spectrum of vertical industry and size, from the SMB market to global enterprises – is in the process of looking to security information and event management (SIEM) solutions as a valuable tool to address a burgeoning glut of unique threats, regulations, and other drivers affecting information security.  And the fact is, there’s no question that SIEM technologies can help organizations in a variety of ways:

• Providing centralized correlation and reporting of events across disparate applications, systems, and platforms to support both security and network operations functions
• Providing a cross-platform pool of event data to support forensics and other security operations
• Centralizing and retaining pristine log files to meet legal retention requirements
• Providing evidence of selected technical controls associated with regulations, best practices, and standards

Unfortunately, while it’s clear that SIEM technologies are incredibly beneficial, this particular customer made it clear that his requirements (and doubtless many others’) around security information and event management are rapidly outstripping the capabilities of most SIEM solutions.

This led me to do some soul-searching around SIEM technologies, and ruminate for a bit on some of the limitations of today’s SIEM solutions, including how solution vendors can better address customers’ real business needs by improving specific aspects of their software.  Over the next couple of posts, I’ll be discussing some of these limitations, and the tremendous value SIEM vendors can provide to their customers by improving these deficiencies.

Next Up: Why most SIEM platforms today are not as comprehensive as customers need them to be.

Traditional spamming and phishing techniques are being augmented by both technical methods (typosquatting, trojaning, baiting) and social engineering methods (pretexting, quid pro quo) to create a powerful set of tools established for the purpose of getting access to confidential information. When major events occur like the current financial crisis, it’s just not rational to assume that employees will abide by, for example, acceptable system use policies, and won’t attempt to catch up on news, check their bank account, or try to transfer their 401(k) to less volatile instruments – all of which can expose them to any and all of these techniques. While information security can partially enforce good user behavior, there is no technology in the world that will prevent a person from divulging their social security number, their username or password, or non-public details about their company.

What does all this mean for the enterprise security professional? It means that, more than ever, security tools, technologies and platforms are not enough to protect your environment, your users, and your organization. Anti-malware, proxies, and other technologies are definitely vital to your environment, but addressing the human factor is just as important as implementing the right technology; to that end, employee awareness of information security threats is a critical countermeasure to protecting your people, processes, and technologies. It’s critical to ensure all your people – employees, contractors, vendors, and suppliers – understand not only that a policy is in place (“do not divulge private company information to anyone outside the organization”), but more importantly, why it is in place; knowing both the consequences and sanctions of treating information securely will augment your security technologies and help ensure that your people become a critical part of your security program.