SecMon State of the Union: Revisiting the Team of Rivals

Posted under: Research and Analysis

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 not really overlapping. It was more about how can they coexist, as opposed to choosing one over the other. But nowadays, the overlap is significant and you have existing SIEM players basically bundling in security analytics capabilities and security analytics players positioning as next generation SIEMs.

Per usual, customers are caught in the middle trying to figure out what is truth and what is marketing puffery. So Securosis is (again) helping you figure out which end is up. In this Security Monitoring (SecMon) State of the Union series, we’ll give you some perspective on the use cases that 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 of buyer and appreciate our Totally Transparent Research model.

Revisiting Security Analytics

Security analytics remains a bit of a perplexing marketing terms becasuse almost every company providing security products and/or services claims to do 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 have:

  • Data Aggregation: It’s impossible to analyze without data. Of course there is some question whether the 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 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, and you will want them prioritized by importance to your business.
  • Drill down: Once an alert fires analysts need 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 attacks.

These attributes still reflect the requirements of a SA tool. Yet, over the past year we’ve seen these capabilities not just in security analytics tools, but also appearing in more traditional SIEM products. Though to be clear, traditional SIEM is a misnomer since none of the market leaders are built on circa-2003 RDBMS technology or are sitting still waiting for new entrants with advanced algorithms to make them irrelevant.

In this post (and the rest of the series) we’ll discuss the degree 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 cloud and IoT impact your security monitoring strategy and toolset.

Wherefore art thou Team of Rivals?

As the lines between SIEM and security analytics have blurred (as we predicted), what should we expect the vendors to do? First understand that any collaboration/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 of not having enough market presence to maintain growth. The risk to a customer is buying a bundled SA solution with your SIEM can be problematic if the SIEM vendor acquires a different technology and eventually forces a migration to their in-house solution. Again, this underlies the challenge of vendor selection as markets are shifting and collapsing.

We feel pretty comfortable the security monitoring market will play out as follows, in the short term:

  1. SIEM players will offer more broad and flexible security analytics capabilities.
  2. Security analytics players will spend a bunch of time filling out their 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.

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

Short-term Plan: You are where you are…

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


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

Thus at this point, your main objective is to get as much value out of the existing SIEM as you can. The process forward for you is pretty straight forward. First you refine the alerts coming out of the system to increase the signal coming from the SIEM and focus your team on triaging and investigating real attacks. Then you can integrate threat intel to get a sense of the attacks happening to other organizations, which may allow you to respond faster to emerging threats.

Then you add new capabilities that 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 little before choosing a side.


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

The first (and most impactful) gap tends to be compliance reporting. The SIEM tools have ridden this use case to great success over the past decade and many teams depend on the 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. Although the good news is that the reporting tools are far better (and intuitive) today.

After making sure you address the compliance use case, you can look at additional tools for response and forensics, since SA won’t have as mature or complete functionality in those areas. There are a bunch of options there, specifically coming out of the next generation endpoint protection vendors that provide far better response capabilities.

Although the best advice we can give you is probably to get comfortable with “good enough,” since in the areas that SA is deficient relative to SIEM, really think about the capabilities you need and then start pushing the SA vendor to get to feature parity fast. All of the stand-alone security analytics vendors see the larger market for SIEM as the target, and are working quickly to address their short comings relative to SIEM functionality.


Then there are the organizations that have the luxury of not having to chose. You’ve implemented both, continuing to rely on the SIEM to detect standard attacks (those you know to look for) and generate compliance reports. You’ve deployed SA to profile the activity in your environment and highlight potentially malicious actions that may represent adversary activity and warrant more investigation.

If this is your situation, we recommend you stay a holding pattern with the tools you already have (meaning don’t add more use cases) until you determine what your strategic platform is going to be, and then you can make investments and determine a migration path forward.

We probably don’t have to state the obvious, supporting both tools can work in the short term but probably isn’t sustainable (or wise) as a long term answer. You need staff trained on both. You need to be able to work through contradictory info when the tools draw different conclusions (on possibly the same data). And you also need to pay for both tools. Details, details.

Civil War

The SecMon State of the Union is that a Civil War is imminent. You will need to pick a strategic platform because it really doesn’t make sense to have both a SIEM and security analytics platform over time. And as we’ve seen in other security markets (like 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 what’s at stake in this battle.

So when faced with these kinds of difficult strategic decisions, you go back to the beginning. What problem(s) are you trying to solve with security monitoring? That line of thinking leads you to the strategic answer. That means going back to the use cases, which we’ll do in the next post.

– Mike Rothman
(0) Comments
Subscribe to our daily email digest

*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by [email protected] (Securosis). Read the original post at: