eIQviews

In this final piece on the limitations of today’s SIEM solutions, the last issue is operational suitability.  In a nutshell, because SIEM tools don’t provide enough data (as mentioned earlier, event and vulnerability data are hardly the “complete picture” of security) and don’t provide access to this data quickly enough (due to their performance limitations related to correlation and reporting), their use is much more reactive than proactive in today’s IT environments.  Customers tend to use SIEM technologies for more reactive efforts, such as post-event forensics, rather than as a true correlation solution to determine unusual behavior or policy violations before they have a chance to affect systems and data.  While reactive capabilities are useful, organizations could be using SIEM solutions for much more proactive analysis, such as baselining normal usage patterns, detecting variations over time, and proactively alerting appropriate personnel — if only the technology adequately supported these use cases.  As SIEM point solutions evolve into true enterprise security management platforms, organizations will be more likely to transform their use of these tools into a more proactive capability.

The first issue we need to look at regarding the current state of SIEM is, quite simply, the breadth of data that SIEM solutions can address.  Typically, I look at technology solutions as tools to solve business problems; I’ve never been a big fan of the “technology for technology’s sake” approach to I.T.  So, in that vein, the first question that comes to mind is, “why do we need SIEM in the first place?”  I’d like to discuss two of those use cases here.

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.

One of the things I really like about interacting with customers is that they provide perspective that, as a vendor, we sometimes don’t get to see first-hand or experience ourselves.  Meeting with a large-enterprise customer yesterday, it was fascinating to hear him talk about some of the business problems he’s encountering as he tries to manage the security posture of thousands of hosts and infrastructure devices, containing hundreds of databases and applications that support revenue-generating business processes.

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.