Things change. That’s the only certainty in technology today, and certainly in security. Back when we wrote Security Analytics Team of Rivals, SIEM and Security Analytics offerings were different and did not really overlap. It was more about how can they coexist, instead of choosing one over the other. But nowadays the overlap is significant, so you need existing SIEM players basically bundling in security analytics capabilities and security analytics players positioning their products as next-generation SIEM.

As per usual, customers are caught in the middle, trying to figure out what is truth and what is marketing puffery. So Securosis is again here to help you figure out which end is up. In this Security Monitoring (SecMon) State of the Union series we will offer some perspective on the use cases which make sense for SIEM, and where security analytics makes a difference.

Before we get started we’d like to thank McAfee for once again licensing our security monitoring research. It’s great that they believe an educated buyer is the best kind, and appreciate our Totally Transparent Research model.

Revisiting Security Analytics

Security analytics remains a fairly perplexing market because almost every company providing security products and/or services claims to perform some kind of analytics. So to level-set let’s revisit how we defined Security Analytics (SA) in the Team of Rivals paper. A SA tool should offer:

• Data Aggregation: It’s impossible to analyze without data. Of course there is some question whether a security analytics tool needs to gather its own data, or can just integrate with an existing security data repository like your SIEM.
• Math: We joke a lot that math is the hottest thing in security lately, especially given how early SIEM correlation and IDS analysis were based on math too. But this new math is different, based on advanced algorithms and using modern data management to find patterns within data volumes which were unimaginable 15 years ago. The key difference is that you no longer need to know what you are looking for to find useful patterns, a critical limitation of today’s SIEM. Modern algorithms can help you spot unknown unknowns. Looking only for known and profiled attacks (signatures) is clearly a failed strategy.
• Alerts: These are the main output of security analytics, so you want them prioritized by importance to your business.
• Drill down: Once an alert fires an analyst needs to dig into the details, both for validation and to determine the most appropriate response. So analytics tools must be able to drill down and provide additional detail to facilitate response.
• Learn: This is the tuning process, and any offering needs a strong feedback loop between responders and the folks running it. You must refine analytics to minimize false positives and wasted time.
• Evolve: Finally the tool must improve because adversaries are not static. This requires a threat intelligence research team at your security analytics provider constantly looking for new categories of attacks, and providing new ways to identify them.

These are attributes the requirements of a SA tool. But over the past year we have seen these capabilities not just in security analytics tools, but also appearing in more traditional SIEM products. Though to be clear, “traditional SIEM” is really a misnomer because none of the market leaders are built on 2003-era RDBMS technology or sitting still waiting to be replaced by new entrants with advanced algorithms.

In this post and the rest of this series we will discuss how well each tool matches up to the emerging use cases (many of which we discussed in Evolving to Security Decision Support), and how technologies such as the cloud and IoT impact your security monitoring strategy and toolset.

Wherefore art thou, Team of Rivals?

The lines between SIEM and security analytics have blurred as we predicted, so what should we expect vendors to do? First understand that any collaboration and agreements between SIEM and security analytics are deals of convenience to solve the short-term problem of the SIEM vendor not having a good analytics story, and the analytics vendor not having enough market presence to maintain growth. The risk to customers is that buying a bundled SA solution with your SIEM can be problematic if the vendor acquires a different technology and eventually forces a migration to their in-house solution. This underlies the challenge of vendor selection as markets shift and collapse.

We are pretty confident that the security monitoring market will play out as follows over the short term:

1. SIEM players will offer broad and more flexible security analytics.
2. Security analytics players will spend a bunch of time filling out SIEM reporting and visualization features sets to go after replacement deals.
3. Customers will be confused and unsure whether they need SIEM, security analytics, or both.

But that story ends with confused practitioners, and that’s not where we want to be. So let’s break the short-term reality down a couple different ways.

Short-term plan: You are where you are…

The solution you choose for security monitoring should suit emerging use cases you’ll need to handle and the questions you’ll need to answer about your security posture over time. Yet it’s unlikely you don’t already have security monitoring technology installed, so you are where you are. Moving forward requires clear understanding of how your current environment impacts your path forward.

SIEM-centric

If you are a large company or under any kind of compliance/regulatory oversight – or both – you should be familiar with SIEM products and services because you’ve been using them for over a decade. Odds are you have selected and implemented multiple SIEM solutions so you understand what SIEM does well…. And not so well. You have no choice but to compensate for its shortcomings because you aren’t in a position to shut it off or move to a different platform.

So at this point your main objective is to get as much value out of the existing SIEM as you can. Your path is pretty straightforward. First refine the alerts coming out of the system to increase the signal from the SIEM and focus your team on triaging and investigating real attacks. Then integrate threat intelligence to get a sense of the attacks happening to other organizations, which may enable you to respond faster to emerging threats.

Then add new capabilities the vendor is bundling into the system, like user behavioral analytics or tracking insider threats. You are basically buying time by leveraging the platform you already have more effectively, and letting the battle between SIEM and security analytics play out a bit before choosing a side.

SA-centric

Perhaps you face sophisticated adversaries and/or have a mature security program and have already decided security analytics is your future strategic platform, and current SIEM vendors aren’t going to get there. So you’ve already made your bet, yet your strategic platform isn’t feature complete compared to your old SIEM. Then your focus needs to be on addressing existing shortcomings of your SA tool.

The first and most impactful gap tends to be compliance reporting. SIEM tools have ridden this use case to great success over the past decade, so many teams depend on these reports to prepare for increasingly frequent audits and assessments. Thus making sure you can generate the reports you need is first on the list. If the reports aren’t built in you are likely exporting data from the analytics tool and going back to the future. You know, the good old days when Excel was your compliance preparation tool. The good news is that reporting tools are far better and more intuitive today.

After making sure you address the compliance use case, you can look at additional tools for response and forensics, because SA functionality in those areas is not yet as mature or complete. There are a bunch of options there, specifically coming from next-generation endpoint protection vendors who provide far better response capabilities.

Although the best advice we can give you is probably to get comfortable with “good enough”. In the areas where SA is deficient compared to SIEM, think about the capabilities you need and then start pushing your SA vendor to reach feature parity fast. All the stand-alone security analytics vendors see the larger market for SIEM as their target, and are working to quickly address their shortcomings relative to SIEM.

Both

Then there are organizations with the luxury of choosing. You’ve implemented both, continuing to rely on the SIEM to detect standard attacks you know to look for and generate compliance reports. You deployed SA to profile activity in your environment and highlight potentially malicious actions which may represent adversary activity and warrant further investigation.

If this is you, we recommend you continue holding with the tools you already have (don’t add more use cases) until you determine what your strategic platform will be. Then you can select and invest in your migration path.

We probably don’t need to state the obvious, but supporting both tools can work in the short term but probably isn’t sustainable (or wise) over the long term. You need staff trained on both, and the ability to work through contradictory info when tools reach different conclusions – perhaps from the same data. And you need to pay for both tools. Details, details.

Civil War

The State of the SecMon Union is: Civil War is imminent. You need to pick a strategic platform because it doesn’t really make sense to run both a SIEM and a security analytics platform forever. And as we have seen in other security markets (including network and endpoint), the next generation and the incumbents all deliver a common set of capabilities and can’t really cleanly differentiate, so the future of Security Monitoring is at stake.

Faced with these kinds of difficult strategic decisions, go back to the beginning. What problem(s) are you trying to solve with security monitoring? That leads you to the strategic answer. That means going back to use cases, as we will in our next post.