Security Information and Event Management Futures

Transcription

1 G 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 SIEM Futures: The Big Five...13 Expanded Context Data Collection and Analysis...13 Shared, Distributed Intelligence...18 Emerging Environment Monitoring New and Expanded Algorithms for Historical and Real-Time Analysis Application Security Monitoring Using Logs, Context and Other Data SIEM Futures: Wild Cards...31 Strengths...33 Weaknesses...33 Recommendations Recommended Reading...35 Notes... 37

2 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 Table 4. Shared, Distributed Intelligence in SIEM Table 5. SIEM Analysis Algorithm Usage...24 Table 6. SIEM Data Analysis Evolution...26 Table 7. SIEM for Application Monitoring List of Figures Figure 1. Log Maturity Curve 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. Page 2 of 38 Gartner, Inc. G

3 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). Gartner, Inc. G Page 3 of 38

4 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. Log management and compliance reporting 2. 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. 1 On the other hand, the other side of SIEM: Page 4 of 38 Gartner, Inc. G

5 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. Sarbanes- Oxley 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. Gartner, Inc. G Page 5 of 38

6 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. G

7 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. Gartner, Inc. G Page 7 of 38

8 Table 1. Basic and Advanced SIEM Use-Case Examples Compliance Use-Case Types Threat Management Use-Case Types Niche Use-Case Types Basic Use Cases 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 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 Gartner, Inc. G

9 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 Gartner, Inc. G Page 9 of 38

10 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 Gartner, Inc. G

11 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. Source: Gartner (May 2012) 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. Gartner, Inc. G Page 11 of 38

12 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 Gartner, Inc. G

13 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 Gartner, Inc. G Page 13 of 38

14 (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 Gartner, Inc. G

15 Table 2. Sources of Context Data Context Type User Context Asset Context Vulnerability Context Configuration Context Data Context External Context Application Context Business Context Location and Physical 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 Source: Gartner (May 2012) 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. Gartner, Inc. G Page 15 of 38

16 Table 3. Context Analysis Evolution Types of Context Data Today 2014 through 2015 Vulnerability 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 Configuration N/A Ongoing and automated system and network configuration data import Correlation of configuration changes with other data User Asset Limited user context (user name-> real name via AD) System-level asset information (IP-> system name and some system properties) 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 Data Not common Bidirectional integration with DLP and data discovery tools 2 Correlation rules to alert on access to discovered data Application Not common Application context import direct from applications Application log enrichment using context data Runtime application data collection and analysis Network Not common Network management systems, network behavior analysis and network forensics tools Application-level network traffic analysis correlated to application context information External Basic IP address blacklists Intelligence feeds and other sources of various threat, vulnerability and attack intelligence Business Not common Business rules, practices, workflows and processes Location Not common Use of user and device location information for correlation and profiling Source: Gartner (May 2012) Page 16 of 38 Gartner, Inc. G

17 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. Gartner, Inc. G Page 17 of 38

18 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 Gartner, Inc. G

19 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, 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. Gartner, Inc. G Page 19 of 38

20 Table 4. Shared, Distributed Intelligence in SIEM Today 2014 Through 2015 Direction of sharing Community or vendor feed - > SIEM unidirectional Community or vendor feed <-> SIEM bidirectional Shared objects Blacklists and reputation lists for IPs, s, files and so on Detailed reputation information for IP addresses, hosts, domains, s, 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 Source: Gartner (May 2012) 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 Gartner, Inc. G

21 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 Gartner, Inc. G Page 21 of 38