Security Information and Eve 227731

This research note is restricted to the personal use of stephanr@slhs.
org G00227731
Security Information and Event Management Futures

Published: 18 May 2012 Analyst(s): Anton Chuvakin, Ramon Krikken
Security information and event management (SIEM) is the principal technology used for security monitoring by enterprises today. This assessment predicts the directions for this technology in the next two to three years and highlights five primary trends that will define the SIEM tools of the near future.
Table of Contents
Summary of Findings..............................................................................................................................2 Analysis.................................................................................................................................................. 4 Introduction...................................................................................................................................... 4 Scope.............................................................................................................................................. 6 Drivers, Requirements and Use Cases for SIEM............................................................................... 6 SIEM Challenges Today....................................................................................................................8 SIEM Futures: Basic Extrapolations................................................................................................ 12 SIEM Futures: The Big Five.............................................................................................................13 Expanded Context Data Collection and Analysis.......................................................................13 Shared, Distributed Intelligence.................................................................................................18 Emerging Environment Monitoring............................................................................................ 21 New and Expanded Algorithms for Historical and Real-Time Analysis....................................... 23 Application Security Monitoring Using Logs, Context and Other Data....................................... 27 SIEM Futures: Wild Cards...............................................................................................................31 Strengths........................................................................................................................................33 Weaknesses...................................................................................................................................33 Recommendations............................................................................................................................... 34 Recommended Reading.......................................................................................................................35 Notes................................................................................................................................................... 37
This research note is restricted to the personal use of stephanr@slhs.org
List of Tables
Table 1. Basic and Advanced SIEM Use-Case Examples....................................................................... 8 Table 2. Sources of Context Data.........................................................................................................15 Table 3. Context Analysis Evolution...................................................................................................... 16 Table 4. Shared, Distributed Intelligence in SIEM.................................................................................. 20 Table 5. SIEM Analysis Algorithm Usage...............................................................................................24 Table 6. SIEM Data Analysis Evolution.................................................................................................. 26 Table 7. SIEM for Application Monitoring.............................................................................................. 30
List of Figures
Figure 1. Log Maturity Curve................................................................................................................ 11
Summary of Findings
Bottom Line: Enterprise architects have to plan for IT deployments of ever-increasing complexity and deal with increasing threats and risks. These and other trends create the need to expand security visibility throughout the entire stack of IT tools and technologies. Security information and event management (SIEM) is a pivotal technology that currently provides security visibility, and it is likely to hold the same role for the next two to three years. SIEM faces opportunities for growth in five core areas: new types of log and context data, shared intelligence, novel analytic algorithms, monitoring of emerging environments, and application security monitoring. Context: Organizations today use a large set of technologies for protecting, assessing and monitoring their environments. SIEM rises above the rest of the technology that promises to aggregate and unify distinct data feeds and information flows about the state of security. SIEM technology has evolved over the last 15 years, but its future will be determined both by its history and by the currently rapid pace of technological changes. Take-Aways:
SIEM tools have been, and are expected to remain, a central point for security monitoring within enterprises. Almost all SIEM deployments are driven by information security and regulatory compliance, with a reported 70% of projects motivated by compliance mandates. Many compliance-driven deployments later evolve to encompass both regulatory issues and security issues that the organization deems important. This situation is expected to persist. It is likely that SIEM will evolve down two separate paths: Enterprise SIEM for more advanced users (and more advanced uses) will evolve separately from a "mainstream" SIEM for the organizations that are lower on the maturity scale and have simpler requirements.
Gartner, Inc. | G00227731 This research note is restricted to the personal use of stephanr@slhs.org
Page 2 of 38
SIEM is a security technology, but it is also a data management technology. In addition to being a data management technology, SIEM is inherently a data analysis technology. This will continue to drive its evolution. Some of the basic extrapolations will continue; these include more log data, more log sources and more types of log data; more environments covered by SIEM; expansion of SIEM use cases; and more SIEM users, both in number and of different types. Five major trends that will define SIEM for the next two to three years are:

Expanded context data collection and analysis Shared, distributed intelligence Emerging environment monitoring: virtual, cloud and mobile New and expanded algorithms for historical and real-time analysis Application security monitoring using logs, context and other data
Recommendations:
Integrate context data into SIEM analytics today to prepare for the future. Organizations should integrate asset and user information and identify use cases where SIEM value can be enhanced by adding such information. At the very least, integrate asset and vulnerability information into your SIEM tool so that internal Internet Protocol (IP) addresses can be mapped to actual computing resources and their security weaknesses. Evaluate your current SIEM product ability to use and share global intelligence, and integrate some of the open-source blacklists into the dynamic watch lists on your SIEM. At a minimum, enable correlation rules and alerts to trigger for any of your systems that are initiating connections to known compromised systems and botnet control servers. Before evaluating and deploying capabilities of SIEM tools and other monitoring solutions, organizations need to realize that newly emerging IT environments must be covered by security monitoring. The need assessment in this case has to come before the tools are ready and can be operationalized. After establishing the base level of SIEM utilization, focus on exploring the data collected and looking for valuable security insights. Use algorithms provided by the vendors and assess their efficiency. If your organization outgrows those algorithms, then look at building capabilities that go beyond what the vendor offers other leading organizations are taking this approach. Realize that analysis of stored data will be required for detecting advanced attacks; simply running reports and queries will not suffice. At least look for the characteristics of normal user and system behavior over time and then slowly move to alerting based on deviations from such behavior, starting from tightly controlled networks (such as the demilitarized zone [DMZ] network segment).
Page 3 of 38
Expand your SIEM deployment from infrastructure to application security monitoring. Try using your SIEM capabilities before moving to dedicated monitoring products. Still, be aware that SIEM technology today is not ready to take over all application security monitoring tasks, so application- or domain-specific monitoring tools will likely be needed for some tasks.
Conclusion: Despite its success, SIEM technology must continue to evolve to stay relevant in the near future. Organizations need to prepare their own security monitoring projects for future requirements and challenges and build a lasting security monitoring architecture.
Analysis
SIEM tools have been, and are expected to remain, a central point for enterprise security monitoring. Preventative security controls such as intrusion prevention systems (IPSs) and Web application firewalls (WAFs) actually block attacks and protect data. But today's enterprise security is increasingly ineffective without visibility across systems, networks, applications, users and security controls. To gain visibility into environments, channel-specific monitoring technologies such as data loss prevention (DLP) and Database Audit and Protection (DAP) are increasingly deployed alongside common preventative controls. Still, SIEM and related log management tools should often serve as both the primary visibility mechanism for security monitoring and a reporting hub for the organization.
Introduction
Gartner defines SIEM technology as a unification of two broad capabilities:
1. 2.
Log management and compliance reporting Real-time monitoring and incident management for security-related events
In particular, the first:
provides log management i.e., the collection, reporting and analysis of log data (primarily from host systems and applications, and secondarily from network and security devices) to support regulatory compliance reporting, internal threat management and resource access monitoring. [It also] supports the privileged user and resource access monitoring activities of the IT security organization, as well as the reporting needs of the internal audit and compliance organizations.
On the other hand, the other side of SIEM:
Page 4 of 38
This research note is restricted to the personal use of stephanr@slhs.org Gartner, Inc. | G00227731
processes log and event data from security devices, network devices, systems and applications in real time to provide security monitoring, event correlation and incident response. [It also] supports the external and internal threat monitoring activities of the IT security organization, and improves incident management capabilities.
1
These components may be delivered as a single product or as a suite of products with various degrees of integration. Nearly all current SIEM vendors deliver both types of capabilities. Some vendors' strengths are in the real-time monitoring domain; others excel in log management and historical analysis. For additional coverage of SIEM vendors, see the Gartner documents listed in the Recommended Reading section. SIEM technology first appeared in the late 1990s and was driven by the need to suppress "false positive" alerts in intrusion detection systems (IDSs). Many years prior to that (starting with the very dawn of computer age), technical professionals already analyzed logs for security purposes. Simple scripts and tools that helped make use of log data existed in the 1980s, and some even predate syslog logging mechanisms. SIEM tools have evolved over the last 15 years to achieve the "top of the pyramid" status for security monitoring; they have even started dabbling with security management and automated response. A notable boost to SIEM evolution came from the regulatory frenzy of the early 2000s. SarbanesOxley Act (SOX), Health Insurance Portability and Accountability Act (HIPAA), Federal Information Security Management Act (FISMA) and Payment Card Industry Data Security Standard (PCI DSS) have made SIEM one of the most common compliance technologies, and they now drive a large percentage of all deployments. This was the time when the distinction between security event management (SEM, which focused on real-time monitoring) and security information management (SIM, which focused on reporting) was relevant; it is increasingly less relevant today. In parallel, SIEM started as a technology applicable only inside the security operations center (SOC) of the global enterprise, and it has evolved (with some degree of success) to become useful to companies that are lower on the security maturity scale. Currently, greater complexity of IT environments and regulatory pressure increase the scope of log data collection from network security devices to a much broader set of log sources. In addition, many types of context information have been absorbed in SIEM. SIEM has adapted to such increasing complexity by becoming more complex itself, and additional monitoring technologies have appeared.
Page 5 of 38
Scope
The scope of this assessment is the following:

SIEM technology The time frame of two to three years and up to five years in specific areas
The current state of SIEM is not covered in this assessment (see the Recommended Reading section for documents that discuss this). This assessment focuses on the technological evolution, not the evolution of the SIEM market. Similarly, this assessment is not about the future of all security monitoring technologies (see "Security Monitoring" for broad coverage of other monitoring technologies).
Drivers, Requirements and Use Cases for SIEM

Before analyzing and predicting SIEM futures, it makes sense to briefly assess its present state. Almost all current SIEM deployments are driven by information security and regulatory compliance, and Gartner research indicates that nearly 70% of deployments are funded due to compliance mandates. As a result, most SIEM use cases concentrate around the following domains:
Threat management and other security issues such as security monitoring of users, systems, applications and data (either within the bounds of an SOC or not and either in real time or via periodic activity review and reporting) Regulatory and policy compliance, activity review, log data retention and reporting
Many compliance-driven deployments evolve to encompass both regulatory issues and security issues that are deemed important by an organization but not prescribed by any external guidance. As such, many organizations end up utilizing both historical reporting and real-time analysis functionality, although in many compliance deployments, log management and reporting remains the dominant feature, and real-time monitoring functionality is used sparingly. A distant third driver is IT operations in the form of unified monitoring of security, performance and availability issues. Select vendors, such as Splunk and SumoLogic, focus on operational log management use cases, which in essence makes them concentrate on log management for operations personnel. However, an entirely separate class of products called IT Event Correlation and Analysis exists in parallel to SIEM's real-time correlation on the operational monitoring side. A brief discussion on a possible convergence of security-focused and operations-focused monitoring tools can be found in the SIEM Futures: Wild Cards section. As of today, these tools exist in separate silos with scarce data exchange in either direction. At a high level, threat management and compliance use-case categories are expected to persist in the two- to three-year timeline and likely much longer. In 2011, Gartner defined six critical SIEM capabilities:
SEM: This capability provides real-time monitoring and analysis of threats and other security events, and it is important for threat management.
Page 6 of 38
Gartner, Inc. | G00227731
User monitoring: User activity monitoring is needed for targeted attack discovery and compliance reporting. The inclusion of user context in event analysis is a prerequisite for exception monitoring. Data monitoring: Data access monitoring and the inclusion of data context are needed for targeted attack discovery and compliance reporting. Application monitoring: Application activity monitoring, when combined with user context, is needed to support fraud detection use cases and compliance monitoring in some industry verticals. Log management and reporting: Log management has become part of the standard of due care for many regulations. Compliance-oriented deployments are simplified when the SIEM product provides a library of regulation-specific and customizable predefined reports. Securityoriented deployments require exception reports for user and resource access. Deployment and support simplicity: The majority of enterprises that deploy SIEM technology have project and support capability constraints that favor ease of deployment and support.
These capabilities are expected to define the core of SIEM tools for the next two to three years. SIEM platforms will continue to become simpler so that the technology can be deployed and managed by smaller, less skilled security teams. Also, SIEM will have to continue to expand the log source integrations to better cover DLP, DAP, file integrity monitoring (FIM) and other security technologies. At the same time, SIEM has to become smarter to better handle advanced threats, including application-level threats configuring SIEM rules for anything exceeding the most basic of threats is already a challenge. Furthermore, the technology will have to handle an ever-increasing volume of data, which will create additional requirements for the SIEM platform's compute and storage infrastructure.
Page 7 of 38
Table 1. Basic and Advanced SIEM Use-Case Examples Basic Use Cases Compliance Use-Case Types Collect and retain log data as prescribed by a regulation Run canned reports and review them occasionally Enable vendor-prescribed correlation rules mapped to a regulation Enable vendor-recommended correlation rules for common threats Use correlation rules to look for compromised login accounts Establish a response process using a built-in case management module Run reports weekly and review them for malicious activities Perform searches across raw data for suspicious IP addresses N/A Advanced Use Cases Create correlation rules for local policy violations and regulatory issues Define reports for each regulation as well as for cross-regulatory control and distribute to all stakeholders using a SIEM tool Establish daily log review procedures and practices to comply with regulations Use pattern discovery tools and visualization tools to look for hidden threats Profile user behavior using log data and look for anomalies by comparing user behavior with others Define models for common attack traces and test them on historical data Correlate log data with flow data and asset context data to find compromised assets Include global threat feeds and create correlation rules for relevant events using global data
Threat Management Use-Case Types
Niche Use-Case Types
Analyze application transactions to find fraud and suspicious transactions Correlate physical access control systems and location context information with IT data to find insider abuse and unauthorized access Monitor industrial control systems for anomalies
Source: Gartner (May 2012)
Additional capabilities might evolve from being a niche capability to being a core capability in the near future. For example, Gartner predicts that, in the future, SIEM tools will enable better security information sharing across the community, which is a niche capability today. In addition, SIEM will likely evolve down two separate paths: Enterprise SIEM for more advanced users (and more advanced uses) will probably evolve separately from a mainstream SIEM for the less demanding or less mature organizations. Finally, although it is impossible to list all future SIEM requirements given the rapidly evolving IT landscape, this assessment will outline key trends and directions for SIEM evolution in order to prepare security professionals for continued effective SIEM deployment and operation.
SIEM Challenges Today

Security information and event management evolution will be in part driven by the challenges it faces today.
Page 8 of 38
The primary challenge with SIEM today is its complexity. This results in some organizations becoming stuck in the initial phases of deployment or even failing outright. Reaching full SIEM potential even when measured against individual organizations' SIEM goals is a difficult task. This SIEM complexity has three aspects:

Deployment complexity Administration complexity Operations complexity
Some of this complexity is inherent to SIEM and connected to its technology mission. After all, SIEM has to connect to many enterprise systems, and many of these systems are themselves complex. In addition to the mere connection, SIEM must often also implement event correlation rules and analyze the data across the data feeds from these systems, which increases the challenge. Complexity of managing and administering SIEM (and not just monitoring it 24/7) has led many organizations to outsource their security monitoring to a managed security service provider (MSSP) or to choose managed SIEM options. When deploying IT resources in public cloud environments, organizations that favor outsourcing might even choose a cloud services provider (CSP) that is also an MSSP and thus have the same organization host and monitor its systems (see "Security Monitoring of Public Cloud Assets"). SIEM is a security technology, but it is also a data management technology for a specific type of data. The amount of data that organizations handle is increasing and this applies to security data as much as it does to business data. Many of the architectural decisions made by the SIEM vendors in the late 1990s (such as heavy reliance on relational databases for event retention or assuming that the customer already runs an SOC with analysts watching the screens 24/7) are hampering progress. These decisions affect SIEM technology today by limiting the amount of data SIEM can handle in a cost-effective manner and steering customers toward workflows that they cannot handle. Furthermore, many legacy SIEM systems are also optimized for real-time analysis and do not perform well for long-term historical reporting and other data analytics. But some of the security challenges of advanced attacks today call for a wider analysis window not hours but days, and not days but weeks and months in specific cases. Emerging attention to "big data" will likely influence SIEM in the near future, and it will particularly affect architectures related to data collection, normalization, storage, processing, retrieval, and even presentation and analytics. The data management aspects of SIEM cover multiple types of data not only timed records (logs), but also many types of context data, which today is mostly utilized for improving the analysis of log data. Thus, SIEM is also a data integration technology that is supposed to tie multiple types of data together to provide a better, more actionable picture of IT reality. DAP and DLP tools will need to feed the results of their analyses into a SIEM system. See "Enhancing Security and
Page 9 of 38
Compliance With Database Audit and Protection" for DAP details and "Data Loss Prevention" for DLP details. In addition to being a data management technology, SIEM is also a data analysis technology. Network management tools have long been used to perform real-time correlation of network events; business intelligence and data-mining tools have also been known for a long time. SIEM technology combines the features of some of these technologies. Today's tools vary in the degree of "intelligence" built into them: Some vendors will unabashedly call an ability to run SQL queries an intelligence feature, whereas others will deliver advanced pattern discovery algorithms. Still, today's SIEM tools are challenged to provide immediately usable, actionable signals without extensive customization, tuning and in-depth IT environment knowledge. SIEM also started as a near real-time technology, often marketed as real-time analysis of security data or even "real-time security awareness." Many an organization's journey to SIEM started from an attempt to perform real-time security event analysis before taking care of simple log collection. As of today, more organizations are following a logical maturity curve: Start from collection, next run reports, and eventually migrate up to real-time alerting. At the same time, recent advanced threats have led to increased pressure for historical data analysis. Real-time event correlation and other event stream analytics need to be enhanced by the ability to analyze historical data for actionable information and bring this discovered information to the attention of the analysts. Such a "morning after" monitoring model is a vast improvement over breach discovery by a third party months after an incident. Therefore, SIEM tools need more algorithms for historical data analysis that focus on discovering actionable insights from stored data. Figure 1 shows an example of a maturity curve.
Page 10 of 38
Figure 1. Log Maturity Curve
Log Monitoring: Security information is monitored in near real time. Log Review: Logs are collected and reviewed daily (delayed monitoring). Log Reporting: Logs are collected, and reports are reviewed every month. Log Investigation: Logs are collected and looked at in case of an incident. Log Collection: Logs are collected and stored, but never looked at. Log Ignorance: Logs are neither collected nor reviewed.
As IT is affected by trends such as virtualization, cloud computing and consumerization, SIEM has to evolve to keep its relevance as the key technology for resource monitoring. Each of the newly emerging environments brings up its own challenges with security monitoring (see "Security Monitoring of Public Cloud Assets"). Finally, SIEM technology promised the proverbial "single pane of glass" for security monitoring. In most organizations that are utilizing SIEM tools, this promise has not been realized, and it is unlikely to be realized in two, three or even five years. Yes, SIEM can integrate many types of data, but clearly, other tools will be needed to perform additional, focused analysis for specific domains. For example, network flow analysis tools will not offload their highly specialized analytics of flows and packets into SIEM (even though some SIEM tools do their own flow analysis), but they will keep providing the analysis results up to the SIEM console (see "Network Behavior Analysis: Moving Beyond Signatures" for details on network anomaly detection). In addition, security investigators will continue digging into other types of data stores raw network traffic, memory contents, disk images and virtual machine snapshots in search for answers.
Page 11 of 38
SIEM Futures: Basic Extrapolations

Before highlighting the five major driving trends that will determine SIEM's future over the next two to three years, it is worthwhile to highlight some of the basic extrapolations that will be in place in the future, just as they were in the last five years or so. These extrapolations are:

More log data, more log sources and more types of log data collected by SIEM tools More networks and environments covered by SIEM Expansion of SIEM use cases More SIEM users, both in number and in type
"More log data, more log sources and more types of log data going into SIEMs" is an easy prediction to make: Volume and diversity of data are both on the track for higher increases. Unfortunately for many of the SIEM vendors, most of the common log sources (sometimes called "devices," even though many are software-only log sources) are already integrated, and what remains is a "long tail" of log source support with "the next 10,000" instead of "the next 10" log sources to integrate. In addition, new types of logs such as runtime software traces may start coming into SIEM tools. In general, organizations that found early success with SIEM tools will expand coverage to more networks: from DMZ to inside and from critical to less critical networks. This will result in increasing log flows, higher volumes of context data and an increase in the number of nodes reporting into SIEM. "Expansion of SIEM use cases" is also a likely extrapolation: More organizations will be expanding from compliance to a combination of compliance and threat management. Some of the niche use cases (such as fraud) may start expanding into broader populations of organizations. See Table 1 for additional examples. Another prediction is an increased population of SIEM users, in terms of both number and types. SIEM has expanded beyond its original use by security analysts to broader audiences, which range from system administrators to (in rare cases) auditors and chief security officers. SIEM technology delivered as a service or via managed or hosted models will further increase the number of SIEM users. As a result, SIEM vendors will have their hands full solving the challenges of yesterday and today while adapting the tools to changing IT realities, all while the amount of log data increases. To make this challenge even more difficult, all this has to be achieved in a manner that is consumable by less mature users and buyers. This is why there may be no other choice but for the SIEM tools to evolve in two directions: advanced tools that grow more advanced in analytics capabilities and basic tools that grow mostly in ease of use.
Page 12 of 38
SIEM Futures: The Big Five

The following five principal trends will drive the evolution of security information and event management in the next two to three years, and possibly up to five years:

Expanded context data collection and analysis Shared, distributed intelligence Emerging environment monitoring: virtual, cloud and mobile New and expanded algorithms for historical and real-time analysis Application security monitoring using logs, context and other data
The next five sections discuss these developments and how organizations should prepare to leverage them. Whatever happens in the technology provider realm in the next two to three years, enterprises have to actually use the capabilities either basic or advanced to solve their problems. It so happens that security monitoring capability is not something one can buy; rather, it is something one has to actually do. Thus, organizations need to prepare themselves for the arrival of advanced analytic features by learning to use the basic ones first.
Expanded Context Data Collection and Analysis

Security information and event management started as a collector and analyzer primarily for log data. However, even early on, the concept of adding information, as context, to log data has been prominently featured. The very first example of context data introduced into SIEM was simply adding a host name to an IP address by acquiring the DNS server. The name (such as example.com) was not in the logs, but the IP address was. The initial use for context data was to enrich the log data and make it better-understood by analysts. Soon after that, context data started to be analyzed together with log data in order to prioritize the importance of log messages and especially alert messages from IDS. Even as early as 2003 and 2004, some SIEM products were able to automatically match attacks detected by the intrusion detection system with vulnerabilities on the host under attack (typically using the MITRE CVE mappings) and perform other analytics, thereby fusing the log data with context data. Even dynamic blacklists that are created by rule-based correlation engines (such as "if source IP is observed to be launching attacks against your organization, put it on the watch list and then check whether the same IP is involved in other malicious activities in the future") are an example of context data matching, even though the content data is created by the same SIEM product itself. An example from later SIEM evolution is asset context information, such as using Microsoft Active Directory (AD) to look up an internal computing resource based on its IP address in order to determine who owns and manages the system. User context helps resolve a cryptic user name
Page 13 of 38
(such as "jsmith45") into a real-world name, user roles, and the associated business unit affiliation; this capability is helpful for both investigation and real-time event analysis. Additional use for context data inside the SIEM is simply to report on such data. Most of the products today have flexible and visually pleasing reporting interfaces. User context data, asset context data and vulnerability context data can be visualized by the SIEM tool for better analysis by the tool user and better communication to others. This applies to environments that turn context data into event data (such as asset configuration state collected, time-stamped with collection time and then sent into a SIEM) and use SIEM tools to review the trends regarding such data. Thus, the primary use of context data today is to enrich the logs, make them more useful and identify their true priority for an organization. In other words, context is just that it is not used as information by and for itself. Gartner defines several types of context that are useful for security monitoring, such as:

User context Asset context Vulnerability context Configuration context Data context External context Application context Business context Location and physical context
As of today, most operational SIEM deployments use at least a few simple types of content. Many SIEM deployments utilize vulnerability and asset context, and some use user context as well. External threat intelligence context, in use by some SIEM tools, and other types of the collective threat intelligence are covered in the next section as a special case of global context data. The context data can come into a SIEM from different sources, which are summarized in Table 2.
Page 14 of 38
Table 2. Sources of Context Data Context Type User Context Asset Context Typical Source Identity management (IdM) system and directory service Asset management system, directory service and internal SIEM asset subsystem Vulnerability assessment (VA) tools, dynamic application security testing (DAST) and static application security testing (SAST) tools CMDB and VA tools with security configuration assessment capability DAP and DLP tools and data management systems Public and private threat intelligence feeds and social media monitoring Infrastructure and business applications, DAST and SAST tools Business unit managers, personnel and business applications, and IT GRC tools GPS sensors built into systems, network location data and physical access control systems
Vulnerability Context
Configuration Context Data Context External Context Application Context Business Context
Location and Physical Context

The use of context information for analysis will have to be dramatically expanded in the future. This will make (and keep) monitoring much more relevant to business and more effective in the age of advanced threats. What's more important, some products will start to actually analyze context data rather than simply using it to enhance event data. Today's SIEM products do not analyze any of the context bits they receive, but future SIEM products will derive intelligence from events and context data alike. This will help fulfill the high-level SIEM mission: to provide situational awareness across the whole environment of risks to the business and information technology. What types of analysis can be performed on context data? Endpoint vulnerability and configuration data, for example, could be matched with network configuration data (a task that requires a separate product today), or it may be analyzed to provide baselining and trending. User context data might be analyzed to determine appropriate user profiles for each role, or their physical location may be used to identify inappropriate access or impersonation attacks. Data context could allow for mapping and analysis of information streams in business processes; by extension, it could be used to find anomalous behavior. Table 3 summarizes some of the new context types that will be collected by future products.
Page 15 of 38
Table 3. Context Analysis Evolution Types of Context Data Vulnerability Today 2014 through 2015
Periodic vulnerability scan report import
Ongoing and automated vulnerability data import Vulnerability information trending and analysis Analysis of vulnerability information with other context such as access control list (ACLs) and firewall rules Application-level vulnerability data from DAST tools added to asset properties SAST code analysis data import and presentation Ongoing and automated system and network configuration data import Correlation of configuration changes with other data Extended user context synchronization from IdM and directories User profiling versus peers and past behavior; behavioral anomaly detection Extended context synchronization from asset management and directory services Context data from new asset types virtual machines, cloud instances and so on Asset profiling; detection of compromised assets based on behavior deviation Bidirectional integration with DLP and data discovery tools Correlation rules to alert on access to discovered data Application context import direct from applications Application log enrichment using context data Runtime application data collection and analysis Network management systems, network behavior analysis and network forensics tools Application-level network traffic analysis correlated to application context information Intelligence feeds and other sources of various threat, vulnerability and attack intelligence Business rules, practices, workflows and processes Use of user and device location information for correlation and profiling
2
Configuration
N/A
User
Limited user context (user name-> real name via AD)
Asset
System-level asset information (IP-> system name and some system properties)
Data
Not common
Application
Not common
Network
Not common
External
Basic IP address blacklists Not common Not common
Business Location
Page 16 of 38
Specifically, user context will be expanded to cover not just basic user name resolution, but also information that allows the tools to perform automated profiling and ultimately detect select insider attacks and abuses. Identity fusion (identifying that "jsmith45" and "john_smith" belong to the same person), peer group comparisons (such as what is performed by tools like Securonix on SIEM data feeds) and other user analyses will become more common. These algorithms are notoriously difficult to commoditize because there is no one "normal" behavior only many facets of normal. However, it is conceivable that future tools can extract enough features of normal behavior so that such profiling becomes operationally useful without research-grade efforts. More importantly, Gartner expects that many of the organizations deploying SIEM for security as well as compliance will integrate their SIEM with identity management and other sources for user context. They would use capabilities that exist today for a more widespread analysis that can help detect persistent threats that often make use of compromised user accounts. Asset information today is mostly used for investigative purposes. In the future, the information will be used for more expanded profiling and anomaly detection to highlight compromised and malicious resources that are taken over by attackers. In addition, systems will have to handle new types of assets such as virtual machines, mobile containers and public cloud assets such as software as a service (SaaS) capabilities. The concept of an asset as something that can be resolved from an IP address at any moment will die off, especially given expanding cloud deployments. Network topology information, such as whether a system is deployed inside the perimeter or in the DMZ, is another example of asset context. Data and application context will allow SIEM to perform better application security monitoring (another SIEM future trend discussed in the Application Security Monitoring Using Logs, Context and Other Data section). Specifically, data context will allow a SIEM analyst to know whether a particular access recorded in logs can reveal sensitive data leakage or theft. For example, a DLP alert may be sent to a SIEM and reviewed by an analyst, who will then execute an API call to perform searches across captured data inside the DLP tool. Business context in contrast to technical context obtained from information systems is the most challenging, but also the most critical for escalating the SIEM importance beyond its network and system infrastructure roots. The easiest example of business context, occasionally utilized by SIEM users, is relative asset importance or asset value. Gartner expects that, in the future, SIEM will be connected to more business process automation systems in order to correlate attacks and suspicious activities with normal business practices and workflows. For example, application and system activities associated with a particular business process may be codified as "known good" activity in SIEM activity profiles or matches to policy templates. At the very least, such information will be brought in to tie system activities observed by SIEM tools to business activities performed by employees and customers and then made available to analysts. Even network context, long present in SIEM tools in the form of IP-related context, can expand in importance. Admittedly, dedicated tools such as RSA NetWitness and Solera would be used for massive packet capture and traffic analysis, but it is likely that session and other information will be channeled back to SIEM (or made available via an API call to a separate tool) to enable SOC analysts to make decisions at that level.
Page 17 of 38
Current examples of this emerging trend are included in the following tools of different types, but unified with the shared-intelligence theme:

HP ArcSight IdentityView presents a dedicated view of user context and its analysis. NetIQ Sentinel bidirectional IdM integration enables both identity data analysis and taking action on user accounts. IBM Q1Labs QRadar Risk Manager analyzes vulnerability and configuration information, together with ACLs and firewall rules, to model possible attack scenarios.
How to Prepare for This Future It is important to realize that many of the technical capabilities for incorporating asset context are present today. However, context usage remains spotty across many SIEM deployments. To prepare for the future, organizations should look for current asset context and user context integration capabilities and identify use cases where SIEM value can be enhanced by adding such information. This will give an organization valuable experience with analyzing additional types of security data, not just logs from the perimeter devices. Context information is likely to become more important for security monitoring of internal assets and applications than it is for monitoring of commodity attacks on the perimeter. For example, an organization should establish a link between its SIEM and its IdM/IAM (identity and access management) system to better monitor internal privileged users. This will allow it to prepare for future advanced analytics on user roles and identities. In general, additional types of context and context data analysis will help SIEM break out of the silo of network security and infrastructure monitoring. However, to do so, an organization must both have the additional data and create processes for using and analyzing the various types of context. To summarize:
In the near term, utilize existing context integration for solving immediate problems, and gain experience with this type of data. In the longer term, evaluate emerging tool capabilities and new types of data and algorithms.
Shared, Distributed Intelligence

For the entire evolution of the security industry, as well as security technologies, every enterprise has by and large faced attackers on its own, in an insular fashion. Sharing threat and countermeasure intelligence beyond a trusted circle of friends has been attempted many times since the dawn of computer security. A recent history of data sharing started from President Clinton's PDD63 in 1998, which talked about "an unprecedented attempt at information sharing among agencies in collaboration with the private sector" and launched the information sharing and analysis centers (ISACs) as trusted sharing "clubs." Despite all the attention, the real sharing across enterprises, between enterprises and government, and even between enterprises and security vendors has been limited, with notable patches of success (such as malware sample sharing).
Page 18 of 38
Today, when advanced attacks are not only targeting the defense sector, but also many other types of organizations, the need for sharing, collaboration and distributed security intelligence is greater than ever. SIEM products already serve as a security monitoring hub within the organization. Although some might claim that they mostly collect data and few succeed in turning the data into intelligence, they're still one of the industry's best shots at combining the data for broad-spectrum security monitoring. The SIEM security monitoring mission and the need to share have led and will lead in the next two to three years to increased sharing of security data to enable collaboration as well as distributed data analysis via crowdsourcing. Current state of the art of SIEM and shared intelligence only involves receiving community information from sources such as shared IP and file blacklists and commercial entity reputation services and intelligence providers, such as VeriSign iDefense, iSIGHT and Cyveilance. Using a different approach, ThreatGrid can build entity reputation lists from live malware analysis and produce both traditional IP blacklists and lists of files, registry keys, domains, DNS queries and so on. SIEM vendors have long used a combination of scripts to include shared community data in correlation and reporting. Such sharing today generally does not go beyond IP blacklists and other IP address reputation lists, but it will likely expand much further in the coming years. Today, more of the niche tools, such as fraud monitoring or even anti-spam, use more global information for the analysis. Blacklists for IP addresses, file names, email addresses, domains, Autonomous System Numbers (ASN) and even countries enhance the value of SIEM for security monitoring. Organizations such as Team Cymru Research, SANS ISC and Malware Domain List provide feeds of various types of IP and domain blacklists, such as botnet IPs, compromised IPs, attacking IPs and spamming IPs. The volume, quality and timeliness of such information are rapidly increasing. For example, emerging vendors automatically analyze privately captured malware binaries and then add the IP addresses that these malware samples are trying to reach to "real-time" blacklists, which vendors share with their customer bases. Other vendors, such as Vigilant, automatically correlate different threat feeds and arrive at a higher-reliability feed, then import it into a SIEM together with rules and reports for such data. However, information sharing is not only about downloading data shared by others; it is also about contributing sanitized data to others in order for a SIEM to play a part in a central distributed data analysis. Table 4 compares today's state of distributed intelligence in SIEM.
Page 19 of 38
Table 4. Shared, Distributed Intelligence in SIEM Today Direction of sharing Shared objects Community or vendor feed > SIEM unidirectional Blacklists and reputation lists for IPs, emails, files and so on 2014 Through 2015 Community or vendor feed <-> SIEM bidirectional
Detailed reputation information for IP addresses, hosts, domains, emails, files and so on Compromise indicator sharing to look for compromised assets; query and search string sharing for rapid detection of recently discovered malicious behavior Correlation rule and other detection template sharing for finding and investigating intrusions
In addition, recent acquisitions in the SIEM market have created a set of companies that offers both managed security services (MSS) and SIEM. HP, Symantec and IBM are three primary examples. These companies have an opportunity to inject the intelligence observed from monitoring their MSSP customers into their SIEM product base in an anonymized and aggregated manner. Such unique data feeds can significantly enhance the quality of security monitoring by deploying shared correlation rules as well as investigative query strings. Analyzing events across their customers is something that most MSSPs have been doing for a long time. However, the opportunity to inject this information into SIEM products is more recent. Current examples of this emerging trend include the following capabilities of different types but unified with the shared-intelligence theme:
HP ArcSight has a number of methods for importing shared intelligence. For example, "ArcOSI is a Python-based utility available for Unix or Windows that scrapes several trusted opensource intelligence sites for known malicious IP's and domains and streams them into ArcSight CEF format via Syslog for use in your SIEM content."
3
Symantec SSIM integration with Symantec's DeepSight intelligence system provides an IP blacklist feed for use in correlation. Vigilant Collective Threat Intelligence can be used to include shared-intelligence feeds in select SIEM products, complete with the SIEM content needed to use the information. RSA netWitness for Logs can use information and shared security data from netWitness Live; also, RSA eFraudNetwork uses global information for fraud detection and investigation. AlienVault Open Threat Exchange enables users to both send and receive threat intelligence for the benefit of their user communities. OpenIOC project by Mandiant may enable easier compromise indicator sharing across different tools.
Page 20 of 38
Finally, distributed and shared intelligence and cross-customer analytics does not require that the SIEM product be delivered as SaaS or through an MSSP. Even for bidirectional information sharing, aggregated information can be sent from the SIEM product into the vendor data center, processed, and then distributed back to the tools in some form. However, it is easier to perform crosscustomer analysis and deploy it in the same platform in case of a SaaS SIEM or MSSP because the data is both hosted and analyzed, and the analysis results are applied, inside a single system. Emerging SaaS SIEM vendors such as SumoLogic highlight this capability as one of the differentiating factors for their technologies. How to Prepare for This Future As of today, an organization's ability to monitor its systems and networks can be improved by using open-source shared-information feeds. To prepare for a future where SIEM and other security tools will use more content produced by crowdsourcing or other types of shared analysis, evaluate your current SIEM product and integrate some of the open-source blacklists into dynamic watch lists on your SIEM. Specifically, watch for your systems initiating communication to any of the blacklist addresses. Consider sharing some of your data in a sanitized form with community organizations, and participate in trusted information-sharing communities such as FS-ISAC and others (based on industry). Demand that vendors develop more shared-intelligence features to improve the security for all of their customers (for additional details, see "Threat Assessment in Dangerous Times"). As vendors deploy more shared-intelligence features in their products, make use of them; they can make you more effective and more versatile in responding more quickly to today's threats. To summarize:
In the near term, gather reliable IP blacklists from the community or commercial vendors and run reports to check whether any systems in your environment communicate with these IP addresses. In the longer term, evaluate newly available data feeds for entity reputation and integrate them in SIEM content types (rules, reports and dashboards) to better find early intrusion indicators.
Emerging Environment Monitoring

Just as vulnerability assessment tools and enterprise vulnerability management practices are expanding to cover new environments (see "Vulnerability Management Practices and Vulnerability Assessment Technology"), security monitoring and SIEM has to follow the expanding IT footprint to the cloud and virtual environments. Vulnerability assessment and security configuration assessment have to adapt and understand architectural and technical components as well as operational practices inside the new environments, and so do security monitoring technologies. For example, tool vendors make assumptions that are always true in traditional IT and are almost never true on public cloud provider networks: fixed server asset IP addresses, rare system restarts, static system grouping, actively managed systems, a system-level (and not service-level) approach to provisioning and so on. For details on using SIEM for security monitoring of public cloud resources, review the upcoming "Security Monitoring of Public Cloud Resources." In an increasingly
Page 21 of 38
hybrid IT and mobile world, monitoring must see further beyond the walls, higher above the infrastructure layers, and deeper into the application context, even for cloud and virtualized applications. On the virtualization side, at the very least, the tools have to understand that the virtual platform represents a new type of asset one that contains assets inside of it. Virtual machines are also provisioned, launched and shut down frequently as needed, thereby complicating some of the monitoring requirements (thus, systems configured to alert on the loss of log data will often be confused by virtualization). This also breaks the assumptions held "holy" by traditional IT. Security in virtual environments is not only connected to hypervisor logging and secure configuration, but also to different operational practices that can both enhance and hamper monitoring and make it more challenging for SIEM tools to excel. The monitoring of mobile computing environments will likely involve more than just log data (and might even be located elsewhere, and not on the device). Still, if SIEM is to preserve its role as the main monitoring technology for enterprises, it has to evolve to enable visibility into mobile assets. Some SIEM vendors, such as Tenable, are experimenting with mobile device monitoring using passive network sensors that feed into a SIEM. Refer to "Field Research Summary: Mobility and Security" for additional details on mobile security. Overall, SIEM will need to cover more environments of different kinds: From SCADA to IPv6 to virtual, mobile platforms and so on. Many of these environments will also contain new asset types such as virtual machines, SaaS applications and application containers rather than the simple "one IP address one IT asset" of today. Some emerging technology environments also bring novel operational models. Many of the companies that utilize private and public clouds manage their systems in a different manner. For example, some of them choose to never update their servers and instead push a new image into the cloud. DevOps and DevOpsSec, described by Gartner, are environments where the operations team, the development team and the security team work together to build, run and secure their IT resources. Finally, emerging IT environments serve a dual purpose in regard to SIEM as delivery form factor and as environments to monitor. Most current SIEM vendors can deliver their appliances in the form of virtual appliances that are deployable on VMware or other virtualization platforms. Specific SIEM vendors are experimenting with deployments inside Amazon and other infrastructure as a service (IaaS) environments. Splunk, for example, has customers deploying both collectors and indexers (engines) across traditional environments, private clouds and public clouds. At the very least, vendors are preparing to deploy collectors to gather log data. SumoLogic is building what it calls a real cloud SIEM, with only a minimum collector at sites, which targets organizations that "want to use a SIEM not manage it" and thus might choose "SIEM as a service." AlertLogic SaaS log management offers its monitoring service to Amazon EC2 customers as well as traditional hosting customers. Some hosting providers may offer SIEM as part of a hosting package, but in such cases, enterprises could still greatly benefit from instantiating their own SIEM where possible. As IT environments change, all security technologies hoping to survive for the next five years will have to adapt to the new IT realm as well as to the new ways business will be conducted in the near
Page 22 of 38
future. Security monitoring technologies, and SIEM in particular, must still be able provide visibility across the new IT domains whether in the cloud or in the mobile device. How to Prepare for This Future Before evaluating and deploying capabilities of SIEM tools and other monitoring solutions, organizations need to realize that newly emerging IT environments have to be covered by security monitoring. The assessment of monitoring requirements across new environments has to come before the tools are ready; the monitoring capabilities can only be operationalized when the entities to be monitored and the issues they should be monitored for are both clear. Next, organizations should ask their technology providers for their coverage of virtual and cloud assets, specific features focused on these environments and how their technology would deal with different operations models. Organizations should then test their existing SIEM tools on their virtual assets, and note any shortcomings and irregularities in how it performs compared with the traditional environment communicate those to vendors as feature requests. To summarize:
In the near term, keep track of IT expansion beyond the bounds of the data center, and define the monitoring requirements for the new environment; discuss your SIEM vendor plans to cover those requirements. In the longer term, deploy SIEM across emerging environments and customer content (reports, dashboards, rules and algorithms) to detect threats relevant to these environments.
New and Expanded Algorithms for Historical and Real-Time Analysis

Given the narrow scope of collected data (firewall and IDS) as well as the narrow scope of problems solved (IDS "false positives"), the analytics included in early SIEM products were both minimal and sufficient. However, later expansion of SIEM use cases and expansion of data collected called for much more advanced data preparation (typically in the form of normalizing and categorizing the data) as well as more advanced analysis algorithms on both stored and live streaming data. As a result, a significant number of SIEM users are complaining about insufficient ability to "get the data out." For some time, many of the vendors focused on log collection performance parameters events per second (EPS) and less on being able to give useful results from the collected data. In essence, analytic capabilities of SIEM products serve the following primary purposes:
Raise alerts in near real time or soon after the event or events of interest have occurred (realtime or stream analysis). Prioritize receiving log messages and generate alerts based on context and other information (event prioritization). Discover and present to an analyst security events of interest that cannot be highlighted in near real time or that require additional information (historical analysis).
Page 23 of 38
Enable the analyst to perform iterative searches for clues in the course of an incident investigation (investigation support).
One can attempt to categorize reporting and summarization, as well as search, as forms of analytic capability, but they only qualify to be called "data retrieval" and not "data analysis." These can be summarized in Table 5 across all uses and all time frames.
Table 5. SIEM Analysis Algorithm Usage Detection of Events of Interest Real-Time Analysis Approaches Hybrid Analysis Approaches Event stream filtering and correlation rules Review of Activities Investigation of Incidents
Real-time dashboards of log and context data
Filters and dashboards
Rules that refer back to historical data; profiling and anomaly detection Data mining; pattern discovery; historical trend analysis
Dashboards comparing current and historical values; visual baselines Reports and data summaries
Real-time search that combines live and historical data Queries and searches across log and context data
Historical Analysis Approaches

For SIEM technology to realize its promise of being the broad-spectrum security monitoring solution, the number of analytic algorithms in SIEM products has to dramatically increase. This applies to stored data analysis, real-time data analysis and hybrid approaches that use historical data to enhance the analysis of incoming events (for example, using historic baselines and anomaly detection and outlier detection). In some cases, the analyzer needs to build a lot of historical context to accurately analyze a real-time event, but in other cases, there is also a need to wait for future data before the analyzer can determine whether something in the past was actionable and security-relevant. In general, some of the promising domains and directions where SIEM analytics can come from are:

Fraud detection Business intelligence and data warehousing Anomaly detection Data mining and machine learning methods
Some of the promising algorithms that are on many SIEM vendors' research drawing boards are user and asset profiling and other anomaly detection methods. Being able to observe the behavior of a user, system, application or other IT resource for a long period and then deriving the characteristics of normal and malicious behavior can lead to effective discovery techniques for
Page 24 of 38
intrusions, insider abuse and operational malfunctions. Although early examples of such features are now appearing in products, their mainstream operational use will likely happen over the next two to three years. User profiling, however, may continue to be a challenge; human behavior, after all, is nothing short of predictably unpredictable, and many user activities on today's networks may look really abnormal while being completely legitimate. Certain technologies can potentially help with future SIEM scalability as well as analytics of largescale, long-term data stores. Select organizations outgrew the analytic performance and scalability of their SIEM tools and decided to build their own data warehouses of security data sometimes reaching petabyte scale. Such forays into security "big data" often use open-source Apache Hadoop data store, security-focused Hadoop distributions such as Zettaset, or select commercial offerings (Teradata, EMC Greenplum, HP Vertica, and so on.). These technologies are known to be used in massive security analysis projects, and some incorporate logs, packets, email and IM conversations, physical security data, application transactions, and essentially every possible timed record collectible at the organization. They typically expand beyond security into fraud analysis, and sometimes into operational monitoring. In fact, data scale and data analysis have an interesting relationship as higher volumes of data, longer retention periods and previously unknown types of data together lead to both new data management challenges and valuable new analysis approaches. On the other hand, simply collecting big piles of data whether in Hadoop or on old-fashioned tape drives but not doing anything with it is unlikely to be a good investment of resources. Thus, organizations that are thinking of approaching the "big data" side of security should know that the goal is not big data storage, but big data analysis. Along the same theme, organizations that have trouble managing and customizing the storage of security data in traditional relational database management systems (RDBMSs) would be "pleasantly" surprised that Hadoop is much more difficult to operate, while the flexible event schema (common in security "big data" implementations) requirement offers both advantages (easier to get the data in) and disadvantages (harder to analyze the data across dissimilar data sources). Data mining and machine learning algorithms such as pattern discovery and unsupervised learning seem to hold their annual promise for security data analysis. However, they've been consigned to research drawing boards rather than production tools. It is likely the situation has to change because of the need to analyze and discover more and more hidden traces of intrusions and indicators of compromise. Some of these algorithms, incidentally, also require extensive amounts of context data to complement the log data. Still, few organizations can utilize the data exploration workflow of "analyze the data of an incident, build a statistical model of features, refine by running it over the historical data and then use it to discover new incidents as they happen." Such activities seem to be the purview of only the most advanced organizations today. These organization are building massive data warehouses of structured data (different from both commercial SIEM and log management tools) to perform such analysis (along with their SIEM tools for near-real-time and shorter-term analysis). Fraud analysis at credit card processors and online auction companies has long utilized advanced analytic approaches on massive amounts of data. Due to a narrower problem space, some of the
Page 25 of 38
algorithms that succeeded in fraud have not yet been ported into general information security use cases. However, the state of the art in this area is expected to advance in the coming years. Overall, because the initial focus on real-time monitoring in SIEM has been somewhat obscured by the compliance-driven focus on reporting, the emergence of new algorithms will rebalance the equation again and make the hybrid analysis using historical data for qualifying incoming alerts a priority for many SIEM users and use cases. For example, Click Security is building a new highperformance stateful analysis engine using a modularized approach in order to analyze logs, flows and other network security data. New algorithms and analysis approaches might call for a different skill set for a SIEM analyst. At some leading organizations, security analysts operating their data analysis technologies had to be paired with statisticians or data scientists who could define and test models on data. These organizations also found out that, for advanced analysis, it is impossible to simply train existing network security analysts. A new role had to be added to the team to make data analysis a success.
Table 6. SIEM Data Analysis Evolution Today Real-Time or Streamed Data Analysis Rule-based correlation of normalized log data 2014 Through 2015 Rule-based correlation of normalized logs and other timed data Rules suggested or automatically created from the analysis of historical data Shared or crowdsourced rules from the community widely available Data-mining algorithms, profiling, as well as additional algorithms for historical data analysis and discovering hidden threats and compromise indicators Ability to tune profiling and other analytics and historical data and automatically learn about monitored activities
Historical Data Analysis
Applying the same correlation rules to stored data, reports and queries Display historical values together with live statistics, use dynamic watch lists
Hybrid Data Analysis
Current examples of this emerging trend include the following capabilities of different types but unified with the analytics theme:
HP ArcSight ThreatDetector tool (now part of ArcSight enterprise system management [ESM]) can utilize data-mining algorithms on stored data. NetIQ Sentinel SIEM can perform basic profiling and display the data for analysis. McAfee Nitro ESM uses its high-speed back-end database to combine real-time analysis with historical data analysis.
Page 26 of 38
Securonix tool combines log data with deep user context data and runs profiling algorithms to detect security issues, risky access, compromised assets, etc. RedLambda seeks to utilize grid computing and neural-network-based approaches for broadscope anomaly detection from binary streams to structured logs
How to Prepare for This Future Organizations that had to build their own analytic tools to be paired with their SIEM, or that otherwise realized the limitations of their SIEM solutions, had to invest significant resources into building their own advanced analytic capabilities and their own "big data" storage. These organizations have discovered the limits of rule-based correlation and short-term data analysis, and they have had to simultaneously explore large-scale data management and large-scale data analysis on their own. Some of the emerging use cases for SIEM, such as advanced threat monitoring, may motivate vendors to invest more in new analytics. To prepare for this future and better handle the emergent threat landscape, organizations have to spend time exploring the data they have collected with their tools. Unfortunately, there is no shortcut to such data analysis activities. However, the motivation for early discovery of attacks, compromised systems and exfiltrated data can drive some of this resource investment. Organizations that have SIEM tools with advanced analytic capabilities should evaluate those features and report successes and failures back to the vendors to speed up tool improvements. To summarize:
In the near term, start exploring the data collected in your SIEM tool and applying the lessons learned to solving the current security problems, especially the problem of detecting compromise indicators on your network. In the longer term, deploy analytics tools provided by the vendors, and make sure to invest time to learn and tune them.
Application Security Monitoring Using Logs, Context and Other Data

Despite more than a decade of progress, many of the SIEM tool deployments today focus on the data from IT infrastructure and network security gear routers, firewalls, switches, servers and security devices. Many organizations choose to decide that infrastructure belongs in IT, while applications represent themselves as a business process encoded in software and thus belongs in business units. Along this line, it is useful to separate application further into "infrastructure applications" (databases, middleware and so on) and "business applications" (financial, HR and other vertical applications). IT owns the routers, but business owns the applications (although IT helps run them). In other words, application security monitoring whether of infrastructure or business applications is unthinkable without a much higher degree of business awareness and business context availability.
Page 27 of 38
One can monitor firewall events for "commodity security issues" that other organizations are seeing as well, but it is more likely that organizations' application security issues are specific to them and their business. After all, everybody runs the same routers without customization, just as everybody customizes and integrates their enterprise applications. Although many tools support log formats of a few enterprise applications, it is well-known that widespread adoption of broad-scale application security monitoring (ASM) is not yet a reality in most organizations. In fact, the concept is not even fully defined yet, and many organizations do not see a need to move their monitoring up from the infrastructure level to applications. Today, people attach the application security monitoring label to various technologies and processes. Specifically, Web application firewalls, basic application log collection, fraud monitoring, decoding network traffic to an application layer, monitoring the runtime software code, and even DLP and DAP are sometimes filed under the "application security monitoring" label. None of the above alone represents a comprehensive picture of application security monitoring, just like network IDS alone does not represent network security monitoring. The tools to achieve ongoing visibility of all security-relevant activities inside the off-the-shelf and custom applications have not even emerged yet. Security in its entirety has to outgrow its network roots first and get some application DNA implanted. In network security monitoring, SIEM receives preprocessed information from other monitoring technologies like IDS, and/or the SIEM vendor creates categorization and normalization rules for incoming off-the-shelf technologies like firewalls. This allows customers to immediately focus on creating rules and reports. For custom applications, however, the customer also needs to create the interpretation logic for what the application log contents mean, and this greatly increases the required effort. Without this information which in essence is application context monitoring capabilities would be minimal. Overall, Web application security monitoring and financial fraud monitoring via application transaction logs are likely two of the most understood use cases. WAF logs, Web server logs, some middleware logs and some database logs (or a DAP data feed) will give an organization a decent shot at Web application monitoring capability. On the fraud side, a lot of dedicated tools are often run outside of a security team. However, select organizations have started successfully using SIEM for these problems while running fraud detection and security incident detection in the same team. "Shallow ASM" such as looking at application authentication records (Who is logging in? Why at 3 a.m.? Why from "Country C?"), select privileged user actions and a few other application events across a few critical applications is growing common as well, but it barely scratches the surface of application behavior and application threats. Monitoring of privileged application users (such as for SoD issues) is there as well, but it is also often handled outside of a SIEM. Another useful way to think about using SIEM for ASM is like a "security brother" of application performance monitoring (APM). In "Criteria Are Maturing for the Magic Quadrant for Application Performance Monitoring," Gartner defines APM as "having five dimensions of functionality," including "runtime application architecture discovery, modeling and display" and "component deep-dive monitoring in application context." Performance monitoring often predates security monitoring for each new technology.
Page 28 of 38
Thus, a demand for comprehensive application security monitoring is very likely in the next few years. SIEM technology today is not ready to take over all application security monitoring tasks. At the very least, many applications simply do not have logging useful for security. In other cases, logs are there but a lot of additional information context is required to decipher them. Still, achieving visibility over security-relevant application activities might become one of the most important challenges that SIEM has to overcome in the coming years. In brief, the following has to happen to make this a reality:
Commercial and custom applications have to actually generate logs, or logs must be obtainable from external components such as WAF, DAP, XML gateways and other middleware. These logs have to include operational logs, as well as business transaction logs, rather than only debugging logs. The logs have to contain security-relevant events and sufficient context to support their analysis. These logged events can be interpreted with a minimal amount of external context rather than requiring the analyst to review the entire application source code to understand the nature of logged events. Required application context has to also be available and exportable for the same tool to collect.
Monitoring applications might happen from outside the application or from inside the application. For example, decoding application-layer traffic or recording user keystrokes as they interact with the application is an example of monitoring from outside the application. Such information can also be sent into SIEM for correlation with other data to achieve indirect application monitoring. On the other hand, native application logs and logs from add-on application modules are examples of monitoring from inside the application. To summarize, such monitoring may happen inside the application (using logs or other methods), outside the application (but with some use of application context) or even from between the application components (such as by sniffing the network or by monitoring application middleware or service-oriented architecture [SOA] XML communication). In addition, application context has to be made available for SIEM tools, such as via APIs or file access. SAST and DAST tools can also provide useful application context for asset investigation, incident response and maybe even future automated analysis algorithms.
Page 29 of 38
Table 7. SIEM for Application Monitoring Today Data Collection Limited stock application log collection HIPS and application whitelisting logs into SIEM 2014 to 2015 Off-the-shelf application log collection Log-generating application modules Application transaction log collection RASP-style live application data SaaS and other cloud application data collection Dedicated content for packaged applications, useful for security and application administrators Application profiling to detect malicious activities Application transaction analysis for fraud and security Monitoring of cloud applications
Data Analysis
Generic rules such as authentication failures to run on application data Reports on application log data
Still the question stands: Will SIEM rise to the challenge, or will dedicated tools be developed to monitor each type of application? This question has to be answered on both a technical level and an organizational and cultural level, such as for expanding one tool to new tasks or buying new tools. At this point, the future is still uncertain: SIEM tools may be directly relevant to application security monitoring, or they may be "one layer removed" from the applications and only collect data from dedicated application monitoring tools. An example of this ongoing battle is database security monitoring: Although DAP tools are dedicated to database monitoring, and their alerts can be sent into SIEM, the number of customers using SIEM to directly monitor databases exceeds the number of DAP users today. However, monitoring via a dedicated tool often offers additional depth of monitoring as well as additional context. Current examples of this emerging trend include the following capabilities of different types but unified with the application security monitoring theme:
HP ArcSight Fortify integration for RASP allows the SIEM to monitor application runtime records (additional analysis will be needed as such records are quite dissimilar from logs). IBM Q1Labs QFlow decodes network traffic up to an application layer, thus providing a useful look at some application network activities. McAfee NitroSecurity ESM and APM integration provides the same capability of detailed application-layer traffic decoding.
How to Prepare for This Future Given the scale of this challenge, one way to start preparing for the future is to define the scope of application security monitoring needed for your organization. At the same time, experiment with collecting application logs into this SIEM and buying, building or otherwise procuring SIEM content such as rules and reports to make sense of the data and help solve your security challenges.
Page 30 of 38
For "infrastructure applications" such as databases, middleware and Web servers, monitoring today includes using both SIEM and dedicated "single channel" monitoring capabilities. For off-the-shelf business applications and custom applications, the organization should focus on adding logging capabilities because there are few others ways of achieving security visibility. For custom and customized business applications, the security team has to work with developers to build or integrate useful application logging inside the applications that have been built and customized. Emerging log standards such as MITRE CEE (see cee.mitre.org for additional details) are of huge value because developers do not have to invent logs useful for security they can simply borrow the templates and ideas from the standard. In general, just as with other application security issues, the cooperation of application developers is essential for using SIEM for application security monitoring of custom applications. Look at application logging modules, as well as the capabilities of external components such as WAF, DAP and middleware (for example, XML gateways), to enhance and simplify the generation of log data. To summarize:
In the near term, start collecting database, Web server and other base infrastructure application logs in SIEM, and utilize existing features and content to alleviate today's security problems while building expertise in application security monitoring. In the longer term, look deeper into application issues such as fraud, application abuse, internal application exploitation and privileged user activities and work on the required data feeds and tool features in order to discover and investigate the incidents.
SIEM Futures: Wild Cards

Apart from the five big trends, a set of wild cards might change SIEM in unpredictable ways in the next three to five years. In summary, these wild cards are:
Broad adoption of log standards, which may refocus most of the same vendor efforts from collection to analysis and result in significant improvements in SIEM analytic capability. Advanced threats (advanced persistent threats [APTs] or advanced targeted threats [ATTs]) drive rapid SIEM technology improvement, resulting in yet unknown analytics advances. Significant convergence of security monitoring with operational monitoring leads to a SIEM merger with another technology. Migration to cloud computing combined with SIEM's inability to adapt to application security monitoring dramatically reduces SIEM's relevance to security safeguards.
These wild cards may affect the future of SIEM technology.
Page 31 of 38
Broad adoption of log standards such as MITRE CEE may allow SIEM vendors to focus more of their energies on analyzing the data and presenting the data in a useful format in other words, focus more on getting the data out and not on getting the data in. Analytics will be much easier as long as the data is produced in a structured format, with predictable fields and unambiguous meaning. As of today, many of the log types are not useful for security monitoring because they are nonstructured and do not contain the information required for monitoring. Adoption of log standards will allow better system interoperability and increase the utility of logging overall, thus escalating the value of SIEM products. Proliferation of advanced attacks, custom attacks and advanced malicious software is already driving the evolution of some security technologies. Such advanced targeted threats (ATT) or advanced persistent threats (APT) have a potential of making security monitoring and SIEM much more important because the value of preventative technologies will drop sharply, and the focus will shift to detection and investigation areas where SIEM excels. In addition, the need to detect such targeted threats based on subtle compromise indicators will also drive SIEM product improvements. Significant convergence of security monitoring with operational monitoring has been predicted many times since the late 1990s. All such predictions have failed to materialize: Security operations centers (SOCs) and network operations centers (NOCs) are still completely separate entities. Only in truly enlightened organizations do these two have an ongoing working relationship with clearly drawn rules of engagement. However, new IT operations models, such as DevOps and ongoing working relationships with companies that have practice in such models, seem to indicate that unified monitoring for security and operational issues do not have to be a pipe dream. For example, providers of SaaS security monitoring tools report that most of their customers use their tools for both operational and security monitoring and do not have a Chinese wall between the teams. Cloud computing and virtualization seem to operate at the silo breakers and may have a potential of driving this change. Operations groups can be an important source for security events. However, attempts to completely converge operational and security monitoring have typically failed, and NOCs and SOCs remain and likely will continue to be run by separate groups, although they share some data sources (for example, logs, NetFlow and packet captures) and work together on investigations and incident response. Indeed, the model "same data collection same tool different analytics" may well finally bring the teams closer together. Organizations that practice the emerging DevOpsSec model will also have security incorporated into the operations team. Security monitoring needs is something that will be with us for as long as we use computers for business and personal uses. Thus, security monitoring can never be dead unless IT is also dead. However, any particular monitoring technology including SIEM technology may go the way of the dinosaur if found unable to adapt to a new environments and new requirements. Although this wild card is the least likely to happen, if most organizations move their IT resources to the cloud and thus deploy no IT infrastructure of their own, and if SIEM fails to evolve to this new world, it can well lose its importance.
Page 32 of 38
Strengths
These are the strengths and boosters for SIEM success over the next two to three years:
Today's SIEM exists at the intersection of security monitoring, data analysis and large-scale data management. Thus, its evolution toward additional analysis and larger volumes of data could greatly enhance an organization's overall security monitoring capabilities, while existing SIEM implementations should grow along with this evolution. Even today, SIEM tools contain some of the broadest intelligence capabilities across all security tools, and they already serve as a hub that supports channel-specific security monitoring spokes (such as IDS/IPS, FIM, DLP and DAP). This intelligence will enable SIEM to increase its role as both a log analyzer and an overall security analytics system. The leading SIEM tools already absorb both log and context data and can evolve to handle expanded context collection and analysis. SIEM vendors' experience with device integration prepared them for monitoring of new emerging environments; thus, SIEM likely will be relied upon for monitoring of virtual and cloud environments. SIEM's ability to process volumes of diverse security data and enhance organization situational awareness makes it a much-needed component in the future, because organizations will undoubtedly need more visibility to compensate for lack of control in emerging IT environments. Because of the fragmentation inherent in modern IT, enterprises will need a broad-spectrum console for their security operations and incident response. SIEM can provide such capability, even when additional monitoring technologies such as DLP, DAM and network behavior analysis (NBA) are used for channel-specific analytics and investigations.
Weaknesses
These are the weaknesses and possible reasons for SIEM's failure (or barriers for success) in the next two to three years:
SIEM technology has a well-deserved reputation for complexity: Deployment, administration and operation can all be challenging. This complexity, which is expected to persist in future versions of these tools, can easily lead to slower SIEM adaptation to rapidly changing environments. Further down the line, it may lead to its decreased relevance. Shared, global information is useful, but building such capabilities may not motivate organizations to share their own data, thus limiting the usefulness of these future capabilities. Despite support for context data, many types of context, such as business context, may be hard to collect and even harder to analyze for either security or operations. New environments will challenge SIEM data models for many reasons, and these challenges will require creative solutions from vendors in order to continue delivering security visibility across all types of environments.
Page 33 of 38
Infrastructure monitoring is still the main focus for many SIEM projects, even though privileged user monitoring across systems and applications is getting more common. IT infrastructure may start to matter less due to virtualization, cloud computing and mobile bring your own device (BYOD) processes. In addition, infrastructure monitoring may increasingly require capabilities that SIEM won't provide, such as network packet analysis. This presents potential challenges for companies that continue to use SIEM and for what its value proposition becomes. Analyzing user behaviors and application transactions is a challenging task. For some problem domains, such as financial transactions, fraud detection algorithms can be developed. However, these algorithms are often highly specific to the domain. General analysis of user behavior, such as to identify latent threat actors, is still difficult from both technical and organizational points of view. As a result of the current state in user and application analytics, application security monitoring represents both a challenge and an opportunity for SIEM. If SIEM does not become the main technology for application security monitoring, some other technologies will have to fill this role, and SIEM relevance might decrease. Still, even if SIEM were to fail to become the key to application security monitoring, it could still be relevant as the consolidator of the alerts from direct application monitoring in combination with alerts from channel tools.
Recommendations
Given that the focus of this assessment is in the future of the technology, these recommendations can help enterprise security architects prepare their environments for the future:
Evaluate, use and then operationalize current SIEM capabilities to establish SIEM as something valuable and central for security monitoring; this technology will continue to be relevant for the next two to three years and likely five or more years. Integrate context data into SIEM analytics today to prepare for the future. Organizations should integrate asset and user information and identify use cases where SIEM value can be enhanced by adding such information. At the very least, integrate asset and vulnerability information into the SIEM so that internal IP addresses can be mapped to actual computing resources and their security weaknesses. Evaluate your current SIEM product capabilities for global intelligence, and integrate some of the open-source blacklists into dynamic watch lists on your SIEM. At the very least, enable correlation rules and alerts to trigger on systems that initiate connections to known compromised and botnet systems. Before evaluating and deploying capabilities of SIEM tools and other monitoring solutions, organizations need to realize that newly emerging IT environments must be covered by security monitoring. The need assessment in this case has to come before the tools are ready and can be operationalized. Organizations that have SIEM tools with advanced analytic capabilities should utilize these features and report successes as well as failures back to the vendors to speed up tool improvement.
Page 34 of 38
Realize that analysis of stored data will be required for detecting advanced attacks and that simply running reports and queries will not suffice. At the least, look for the characteristics of normal user and system behavior over time and then slowly move to alerting based on deviations from such behavior starting with tightly controlled networks (such as the DMZ network segment). Expand your SIEM deployment from infrastructure to application security monitoring. Try using your SIEM capabilities before moving to dedicated monitoring products. Still, be aware that SIEM technology today is not ready to take over all application security monitoring tasks, so it is likely that application- or domain-specific monitoring tools will be needed for some tasks. In general, find your use cases and evaluate cutting-edge SIEM capabilities; these will be the mainstream in a few years.
Recommended Reading
Some documents may not be available as part of your current Gartner subscription. "Security Monitoring" "Security Information and Event Management Technology Assessment" "Field Research Summary: Security Information and Event Management" "2012 Planning Guide: Security and Risk Management" "Magic Quadrant for Security Information and Event Management" "Critical Capabilities for Security Information and Event Management Technology" "How to Deploy SIEM Technology" "Planning for an SIEM Technology Deployment" "Effective Security Monitoring Requires Context" "Using SIEM for Targeted Attack Detection" "Security Monitoring of Public Computing Resources" (upcoming) "DevOps and Monitoring: New Tools for New Environments" "Information Security Is Becoming a Big Data Analytics Problem"
Page 35 of 38
Acronym Key and Glossary Terms

ACL AD APM APT ASM ASN ATT BYOD CMDB CSP DAP DAST DLP DMZ EPS ESM FIM FISMA HIPAA IaaS IAM IdM IDS IP access control list Active Directory application performance monitoring advanced persistent threat application security monitoring Autonomous System Number advanced targeted threat bring your own device configuration management database cloud services provider Database Audit and Protection dynamic application security testing data loss prevention demilitarized zone event per second enterprise system management file integrity monitoring Federal Information Security Management Act Health Insurance Portability and Accountability Act infrastructure as a service identity and access management identity management intrusion detection system Internet Protocol
Page 36 of 38
IPS ISAC MSS MSSP NOC PCI DSS RDBMS SaaS SAST SEM SIEM SIM SOA SOC SOX VA WAF
intrusion prevention system sharing and analysis center managed security services managed security service provider network operations center Payment Card Industry Data Security Standard relational database management system software as a service static application security testing security event management security information and event management security information management service-oriented architecture security operations center Sarbanes-Oxley Act vulnerability assessment Web application firewall
Notes
Mark Nicolett and Kelly M. Kavanagh. "Critical Capabilities for Security Information and Event Management Technology." Gartner. 12 May 2011. 2 Some organizations has reported that they deem DLP data "too sensitive" for SIEM. However, it is likely that DLP alerts will be directed to SIEM more in the future while sensitive content captures will not.
3 1
"Version 3.0 Released." ArcSight Open Source Intelligence Utility. Accessed online 10 May 2012.
Page 37 of 38
GARTNER HEADQUARTERS Corporate Headquarters 56 Top Gallant Road Stamford, CT 06902-7700 USA +1 203 964 0096 Regional Headquarters AUSTRALIA BRAZIL JAPAN UNITED KINGDOM
For a complete list of worldwide locations, visit http://www.gartner.com/technology/about.jsp
2012 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This publication may not be reproduced or distributed in any form without Gartners prior written permission. If you are authorized to access this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This publication consists of the opinions of Gartners research organization and should not be construed as statements of fact. The opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartners Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see Guiding Principles on Independence and Objectivity.
Page 38 of 38

Security Information and Eve 227731

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Security Information and Eve 227731

Hochgeladen von

Copyright:

Verfügbare Formate

This research note is restricted to the personal use of stephanr@slhs.

Security Information and Event Management Futures

This research note is restricted to the personal use of stephanr@slhs.org

This research note is restricted to the personal use of stephanr@slhs.org

This research note is restricted to the personal use of stephanr@slhs.org

This research note is restricted to the personal use of stephanr@slhs.org

In particular, the first:

This research note is restricted to the personal use of stephanr@slhs.org

This research note is restricted to the personal use of stephanr@slhs.org

Drivers, Requirements and Use Cases for SIEM

Gartner, Inc. | G00227731

This research note is restricted to the personal use of stephanr@slhs.org

This research note is restricted to the personal use of stephanr@slhs.org

Threat Management Use-Case Types

Niche Use-Case Types

Source: Gartner (May 2012)

SIEM Challenges Today

This research note is restricted to the personal use of stephanr@slhs.org

Deployment complexity Administration complexity Operations complexity

This research note is restricted to the personal use of stephanr@slhs.org

Gartner, Inc. | G00227731

This research note is restricted to the personal use of stephanr@slhs.org

Figure 1. Log Maturity Curve

This research note is restricted to the personal use of stephanr@slhs.org

SIEM Futures: Basic Extrapolations

Gartner, Inc. | G00227731

This research note is restricted to the personal use of stephanr@slhs.org

SIEM Futures: The Big Five

Expanded Context Data Collection and Analysis

This research note is restricted to the personal use of stephanr@slhs.org

Gartner, Inc. | G00227731

This research note is restricted to the personal use of stephanr@slhs.org

Location and Physical Context

This research note is restricted to the personal use of stephanr@slhs.org

Periodic vulnerability scan report import

Limited user context (user name-> real name via AD)

Basic IP address blacklists Not common Not common

Gartner, Inc. | G00227731

This research note is restricted to the personal use of stephanr@slhs.org

This research note is restricted to the personal use of stephanr@slhs.org

Shared, Distributed Intelligence

Gartner, Inc. | G00227731

This research note is restricted to the personal use of stephanr@slhs.org

This research note is restricted to the personal use of stephanr@slhs.org

Source: Gartner (May 2012)

Gartner, Inc. | G00227731

This research note is restricted to the personal use of stephanr@slhs.org

Emerging Environment Monitoring

This research note is restricted to the personal use of stephanr@slhs.org

Gartner, Inc. | G00227731

This research note is restricted to the personal use of stephanr@slhs.org

New and Expanded Algorithms for Historical and Real-Time Analysis

This research note is restricted to the personal use of stephanr@slhs.org

Real-time dashboards of log and context data

Filters and dashboards

Historical Analysis Approaches

This research note is restricted to the personal use of stephanr@slhs.org

This research note is restricted to the personal use of stephanr@slhs.org

Historical Data Analysis

Hybrid Data Analysis

Source: Gartner (May 2012)

Gartner, Inc. | G00227731

This research note is restricted to the personal use of stephanr@slhs.org

Application Security Monitoring Using Logs, Context and Other Data