ESG Brief Enterprise Organizations Need Contextual- security Analytics Date: October 2014 Author: Jon Oltsik, Senior Principal Analyst Abstract: Large organizations have spent millions of dollars on security technology, intelligence, and services over the past ten years, yet many enterprises still experience successful malware attacks and security breaches that circumvent security controls and sneak by security analytics tools. Many firms try to address this situation with SIEM systems, but design limitations have led to a situation where SIEM is no longer adequate alone. So what s needed? Contextual- security analytics. In fact, leading contextual- security analytics systems can not only improve incident detection, but also explain cybersecurity in a business context, helping organizations prioritize actions, accelerate incident response processes, and lower IT risk. Overview According to ESG research, 49% of enterprise organizations report that they experienced at least one successful malware attack within the last year (note: a successful malware attack is one in which an organization had to take some type of action, like reimaging a system, announcing a security breach, or alerting customers, in response to the malware attack). Even more alarming, 22% of enterprises admit to more than 25 successful malware attacks over the course of 2012 alone! 1 Why does malware continue to penetrate the network and compromise systems? While there are many contributing factors, many organizations readily admit that they continue to struggle with critical analytics activities like security incident detection and response. In fact, ESG research indicates that many enterprises have weaknesses in a number of areas including security forensics, retrospective remediation, and consuming the latest security intelligence (see Figure 1). 2 Conventional approaches to information security involve the collection and aggregation of all data traversing the network; however, this approach can become a big data challenge. What organizations truly need is a strategy that is driven by contextual- security analytics. 1 Source: ESG Research Report, Advanced Malware Detection and Protection Trends, September 2013. 2 Source: Ibid. 3 Source: ESG Research Report, The Emerging Intersection Between Big Data and Security Analytics, November 2012.
2 Figure 1. Enterprise Incident Detection/Response Weaknesses Please consider this list of incident deteccon/response tasks. Which three are your organizacon biggest areas of weakness (i.e., which are you worst at)? (Percent of respondents, N=315, three responses accepted) Performing forensic analysis to determine the root cause of the problem Using retrospeccve remediacon to determine the scope of outbreaks, contain them and remediate malware 29% Analyzing security intelligence to detect security incidents Determining which assets, if any, remain vulnerable to a similar type of adack Altering security controls to prevent future similar types of malware adacks Gathering the right data for accurate situaconal awareness 27% 26% Understanding the impact and/or scope of a security incident 20% Taking accon to minimize the impact of an adack 13% What about SIEM? 0% 5% 10% 15% 20% 30% 35% Many security professionals will look at a list of incident detection/response weaknesses like the one in Figure 1 and scratch their collective heads. After all, enterprise organizations have security information and event management (SIEM) systems in place to provide for their security analytics needs. Aren t SIEM systems addressing these issues? In truth, SIEM platforms can be helpful, but given the scale, scope, and sophistication of cyber- attacks, SIEM is no longer sufficient in most cases. Enterprise security professionals point to numerous SIEM problems (see Figure 2) because: 3 SIEM data consumption and management can be extremely limited. SIEM systems were originally designed to collect, filter, and correlate log events from security and networking devices. This data is then normalized, indexed, and processed, typically within an RDBMS. There are three fundamental issues here: 1. Log data provides information about individual nodes but it can be difficult or even impossible to trace activities across the network from Layer 2 through 7. 2. By normalizing the data, SIEMs may ignore and throw away valuable historical data that could be needed for future cybersecurity investigations. 3. Log data is one of many sources that can be used for security analytics. While some SIEMs interoperate with other data sources, there is little actual coordinated data analysis. SIEM was designed for event correlation rather than advanced queries. SIEM was designed to churn through events and generate alerts for investigation. Unfortunately, security analysts are then obligated to 3 Source: ESG Research Report, The Emerging Intersection Between Big Data and Security Analytics, November 2012.
3 use other tools for forensic analysis and security investigations. Most SIEMs can only handle basic queries any sophisticated data pivots or complex queries can easily bring a SIEM platform to its knees. SIEM can be difficult to use. SIEM implementation can take months and include custom coding that requires expensive professional services. Once SIEM systems are in place, it can also be difficult to add new rules or fine- tune data correlation and filtering. In the past, many organizations pointed SIEM systems at regulatory compliance rather than security analytics. Given this, it is difficult to then reassign SIEM for incident detection/response especially in today s threat landscape. Figure 2 SIEM Problems at Enterprise Organizations Has your organizacon experienced any of the following problems with its SIEM? (Percent of respondents, N=72, mulcple responses accepted) SIEM tool requires advanced skills and knowledge 36% Difficulty performing custom queries for security analysis 31% Difficulty colleccng certain types of data 29% SIEM tool lacks context around security informacon Too many false posicve alerts Need to customize SIEM to meet my organizacon s requirements Scalability problems with the SIEM s central database 26% Difficult to learn/operate SIEM tool 17% Enterprise Organizations Need Contextual- security Analytics 0% 10% 20% 30% 40% In spite of their limitations, no one is suggesting throwing out the SIEM baby with the security analytics bath water, but SIEM can no longer anchor cybersecurity analytics alone. So what else is needed? This pertinent question has become a point of confusion for many CISOs. Clearly, security professionals need succinct answers rather than additional industry hype! ESG believes that SIEM should be viewed as a component of a greater discipline around contextual- security analytics. ESG defines contextual- security analytics as: The collection, processing, and exploration of large quantities of security intelligence, IT data, and business data that can be used to align cybersecurity operations with business risk. Contextual- security analytics also provides actionable intelligence so organizations can prioritize activities and accelerate incident detection/response processes. To help alleviate market misunderstanding, it is worthwhile to further parse this definition by explaining:
4 Security data. Contextual- security analytics demand the collection, processing, and examination of data beyond log events. For example, network- based data (e.g., NetFlow, IP packet metadata, and full packet capture) is required to add connectivity information and L2-7 analysis to log events from individual assets. Internal security data should also be supplemented with appropriate external threat intelligence around vulnerabilities, malware, and attack patterns. The best threat intelligence will align with an organization s IT infrastructure, industry, location, etc. by supplementing internal security analytics for immediate use. As stated in the definition, CISOs must understand that contextual- security analytics may involve massive amounts of data volume. Business risk. Security analytics are completely skewed toward IT as they view the world in terms of technical characteristics like MAC addresses, IP addresses, packets, flows, etc. Yes, this information is essential, but businesses can t really make intelligent security decisions unless they can equate these technical labels to people, applications, and business processes. Contextual- security analytics must be designed for this type of technology- to- business mapping. Actionable intelligence. This requirement highlights a perpetual problem with security analytics tools. Many systems produce alerts, but then security analysts are left to investigate, prioritize, and respond to these warnings on their own. Contextual- security analytics systems are designed to alleviate this workload by correlating alerts to specific network traffic, systems, individuals, applications, and business processes. In this way, security analysts can actually explain the scope of individual alerts and then determine which ones have the potential to lead to disruption of critical IT services or cause a damaging security breach. The combination of security data, business risk, and actionable intelligence makes contextual security effective for addressing all phases of a typical kill chain (see Table 1). Table 1. Contextual Security Use Cases During a Cyber- Attack Kill Chain Kill Chain Phase Detection Activity Contextual Security Reconnaissance Exploitation Initial infection Command and control (C&C) communications Internal pivot Data exfiltration Determine whether adversaries are conducting horizontal or vertical network scans. Detect initial system compromise. Detect inbound administrative connections to a system. Detect suspicious connections to external hosts. Determine if compromised hosts have connected to other internal systems. Determine if suspicious connections are used for file transfer to external hosts. View connections across systems, ports, and protocols to detect suspicious scanning activity. View system logs and IPS systems to look for successful and unsuccessful attacks. View NetFlow records for anomalous connections to external hosts. Correlate these connections with details about ports, protocols, and data flows to detect evidence of remote access. Compare destination addresses with known C&C networks using real- time threat intelligence feeds. Review network flows to look for internal network scans. Tag high- value assets and create a security alert upon anomalous connections. Correlate operating system and application logs with NetFlow records to find anomalous activities across systems and networks.
5 Contextual- security Analytics Technical Considerations Clearly, contextual- security analytics platforms must be able to consume massive amounts of internal and external data sources, process them, and then provide analysts with the actionable intelligence. To do so, these systems must be designed for: Annotation. To align technology and business processes, contextual- security analytics platforms must provide a way for businesses to mark up the data. This can be accomplished by using things like meta tagging and classification so analytics can be performed in a controlled business- centric vocabulary. Examples of annotation could include translating networks and systems into terminology like partner network or ecommerce system. This will be especially useful for CISOs as they describe IT risk management and cybersecurity metrics to business executives. Data integration and synthesis. A business- centric view demands that contextual- security analytics are integrated with data sources focused on identity, devices, geolocation, etc. Contextual- security analytics platforms must have the ability to align and synthesize this data with network behavior in real time. This requirement demands the right API sets and data models. Machine learning. Aside from traditional security signatures and behavioral heuristics, contextual- security analytics must be instrumented with algorithms that calculate normal system and network behavior so they can quickly identify anomalous activities. To avoid false positives, leading contextual- security analytics will feature nested algorithms that examine anomalies in a multitude of ways before sounding security alarms. Visual analytics. The best contextual- analytics systems will not only feature a proverbial single pane of glass but also present analysts with rich visual analytics images that clearly illustrate abnormal patterns. Furthermore, visual analytics tools must provide the ability to quickly pivot from one point to another, or set up their own custom views and reports around critical business assets. This will help security professionals accelerate security investigations and remediation. Ideally, contextual- security analytics platforms will go beyond incident detection and help organizations automate incident response. How? When contextual- security analytics platforms detect a security attack with high certainty, they should be able to work with security controls like endpoint security software, firewalls, IDS/IPS, and network proxies to update rules, block traffic, or remediate a system. In this way, contextual- security analytics can anchor a cybersecurity lifecycle designed for continuous improvement. The Bigger Truth ESG understands that there is massive confusion in the market today and that many security professionals don t understand what SIEM does and doesn t do or where to turn for help. While this technology muddle is certainly logical, CISOs must also realize that time is not on their side. Given the insidious threat landscape, large organizations must address their security analytics shortcomings as soon as possible. Contextual- security analytics is a superset of SIEM platforms intended to enhance SIEM and deliver actionable intelligence in a business- centric perspective. The goal here is simple: Help the security team prioritize activities, accelerate incident detection/response, adjust to new threats, and lower IT risk. Given these benefits, CISOs should assess their current security analytics capabilities and craft a contextual- security analytics plan as soon as possible. This ESG brief was commissioned by Lancope and is distributed under license from ESG. All trademark names are property of their respective companies. Information contained in this publication has been obtained by sources The Enterprise Strategy Group (ESG) considers to be reliable but is not warranted by ESG. This publication may contain opinions of ESG, which are subject to change from time to time. This publication is copyrighted by The Enterprise Strategy Group, Inc. Any reproduction or redistribution of this publication, in whole or in part, whether in hard- copy format, electronically, or otherwise to persons not authorized to receive it, without the express consent of The Enterprise Strategy Group, Inc., is in violation of U.S. copyright law and will be subject to an action for civil damages and, if applicable, criminal prosecution. Should you have any questions, please contact ESG Client Relations at 508.482.0188.