Skip to content

Got SIEM? – Part II

November 9, 2008

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.

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: