Security Analytics Team of Rivals: Introduction [New Series]

Security monitoring has been a foundational element of most every security program for over a decade. The initial driver for a separate security monitoring infrastructure was the overwhelming amount of alerts flooding out of intrusion detection devices, which required some level of correlation to determine which of the alerts mattered. Soon after compliance mandates (mostly PCI-DSS) emerged as a forcing function providing a clear requirement for log aggregation, which SIEMs already did. As a result, SIEM offerings (as the primary security monitoring technology) became entrenched to address the needs of both alert reduction and compliance reporting.

Yet everything changes and the requirements for security monitoring have evolved. Attacks have become much more sophisticated and require a level of advanced analysis to detect that is difficult using existing technologies. Thus a new category of technologies, generically dubbed Security Analytics, emerged to fill the need to address very specific use cases requiring advanced analysis, including user behavior analysis, insider threats, and network-based malware detection. These products and services have a common foundation, which is sophisticated analysis of aggregated security data, using “big data” technologies not available when the SIEMs initially appeared in the early 2000s.

This age old cycle should be familiar by now, where existing technologies don’t fit the bill as requirements evolve, and new companies launch to fill that gap. But enterprises have seen this movie before, where new entrants make inflated claims that they address all of the failings of the last generation of technology offering little proof and large price tags. To avoid the inevitable disappointment of throwing all-in behind an unproven technology (again), we always recommend organizations ask themselves a few questions:

1. Can you meet the need with existing technology?
2. Do these new offerings definitively solve the problem in a sustainable way?
3. At what point does the new supplant the old?

Of course, relative to the future of security monitoring, you can’t know all of these answers definitively right now. But what you can do is understand how security analytics works, why it’s different (and possibly better), and understand if/where in your security program the technology can provide value and for how long. Then you’ll be in a position to answer those questions.

Though you can be clear that security analytics is not a replacement for your SIEM – today. So for a period of time you’ll need to support both technologies. Basically, the role of the security architects is to assemble a Team of Security Analytics Rivals to address their needs to generate actionable alerts on specific threat vectors relevant to their business, investigate attacks in process and post-compromise, and still generate those compliance reports to streamline the audit.

It gets better in that many current security analytics offerings were built and optimized for a specific use case. So this Team of Rivals concept is doubly applicable to organizations facing multiple threats from multiple actors and understand the importance of detecting the attack sooner and responding better. As was said in Contact, “why buy one, when you can buy two for twice the cost.” Three or four have to be better than two, right?

We are pleased that Intel Security has agreed to be the initial licensee of the Security Analytics Team of Rivals paper, which will be end result of this series. We continue to be grateful that forward looking companies in the security industry invest in objective research to educate their constituents about where security is going, not just focusing on a chart of where it’s been.

On Security Analytics

As we start this series, we need to clarify our position on security analytics. It’s not a thing. Not for a long period of time anyway. Security analytics represents how you do a thing, which is to _detect attacks__ in your environment. But we don’t believe that security analytics as a product category is something that stands alone.

That doesn’t mean that it necessarily becomes subsumed into an existing SIEM technology or other security monitoring product/service stack, although that’s an option. We can easily build a case for why these emerging analytics platforms become the next generation SIEM. Our point is that the Team of Rivals concept is not a long term solution. At some point, organizations will need to simplify their environment and consolidate their vendors and technologies. They will pick a security monitoring platform, but we aren’t making bets as to what wins right now. Ergo, the need for a Team of Rivals.

Though having a combined and integrated solution at some point doesn’t really help you detect attackers in your environment right now. So let’s define what we mean by security analytics first, and then we can focus on how these technologies work together to meet today’s requirements, with an eye to the future.

In order to call itself a security analytics offering, it needs to do the following:

• Data Aggregation: It’s hard to do analysis without data. Of course, there is a question of whether the security analytics offering needs to gather its own data or whether it can just integrate with an existing security data repository (like your SIEM).
• Math: We joke a lot about the fact that math is the hottest thing in security now, especially given early SIEM correlation and the analysis that drove the first IDS products used math too. But this is different math, based on advanced algorithms and data management to find patterns within volumes of data unimaginable 15 years ago. The key aspect here (and what’s really different) is that you don’t need to know what you are looking for. It’s about having algorithms that help you identify the unknown unknowns. It’s a failed strategy to only look for attacks you’ve seen before and built rules to address.
• Alerts: This is the main output of a security analytics offering. You’ll also want to be able to prioritize the alerts based on criteria important to your business.
• Drill down: Once an alert fires, analysts will need to dig into the for both validation and to determine the most appropriate response. Thus the tool needs to be able to drill into the situation and provide additional detail to assist in the response.
• Learn: This is the tuning process, and any offering needs a strong feedback loop between the responders and the folks running the tool to refine the analytics in your environment, minimizing false positives and wasted time.
• Evolve: Finally, the tool must evolve since the adversaries are not static. This requires a threat intel/research team from the security analytics provider constantly looking for new categories of attacks and adding new ways to identify those attacks in the tool.

Of course, we could write a book about the nuances between the different approaches to security analytics and whether the criteria listed above is comprehensive enough. Or perhaps it’s too broad. The point being as the security analytics term evolves with the requirements of the market, the market will identify the most important criteria and which analytics approach survives. We are going to focus more tactically in this series, concerned only with how you can align your security monitoring technologies and emerging analytics capabilities to better identify attacks in your environment.

And in the next post we’ll start digging into those use cases and integration points that will require the Team of Rivals.

Security monitoring has been a foundational element of most every security program for over a decade. The initial driver for a separate security monitoring infrastructure was the overwhelming amount of alerts flooding out of intrusion detection devices, which required some level of correlation to determine which of the alerts mattered. Soon after compliance mandates (mostly PCI-DSS) emerged as a forcing function providing a clear requirement for log aggregation, which SIEMs already did. As a result, SIEM offerings (as the primary security monitoring technology) became entrenched to address the needs of both alert reduction and compliance reporting.

Yet everything changes and the requirements for security monitoring have evolved. Attacks have become much more sophisticated and require a level of advanced analysis to detect that is difficult using existing technologies. Thus a new category of technologies, generically dubbed Security Analytics, emerged to fill the need to address very specific use cases requiring advanced analysis, including user behavior analysis, insider threats, and network-based malware detection. These products and services have a common foundation, which is sophisticated analysis of aggregated security data, using “big data” technologies not available when the SIEMs initially appeared in the early 2000s.

This age old cycle should be familiar by now, where existing technologies don’t fit the bill as requirements evolve, and new companies launch to fill that gap. But enterprises have seen this movie before, where new entrants make inflated claims that they address all of the failings of the last generation of technology offering little proof and large price tags. To avoid the inevitable disappointment of throwing all-in behind an unproven technology (again), we always recommend organizations ask themselves a few questions:

1. Can you meet the need with existing technology?
2. Do these new offerings definitively solve the problem in a sustainable way?
3. At what point does the new supplant the old?

Of course, relative to the future of security monitoring, you can’t know all of these answers definitively right now. But what you can do is understand how security analytics works, why it’s different (and possibly better), and understand if/where in your security program the technology can provide value and for how long. Then you’ll be in a position to answer those questions.

Though you can be clear that security analytics is not a replacement for your SIEM – today. So for a period of time you’ll need to support both technologies. Basically, the role of the security architects is to assemble a Team of Security Analytics Rivals to address their needs to generate actionable alerts on specific threat vectors relevant to their business, investigate attacks in process and post-compromise, and still generate those compliance reports to streamline the audit.

It gets better in that many current security analytics offerings were built and optimized for a specific use case. So this Team of Rivals concept is doubly applicable to organizations facing multiple threats from multiple actors and understand the importance of detecting the attack sooner and responding better. As was said in Contact, “why buy one, when you can buy two for twice the cost.” Three or four have to be better than two, right?

We are pleased that Intel Security has agreed to be the initial licensee of the Security Analytics Team of Rivals paper, which will be end result of this series. We continue to be grateful that forward looking companies in the security industry invest in objective research to educate their constituents about where security is going, not just focusing on a chart of where it’s been.

On Security Analytics

As we start this series, we need to clarify our position on security analytics. It’s not a thing. Not for a long period of time anyway. Security analytics represents how you do a thing, which is to _detect attacks__ in your environment. But we don’t believe that security analytics as a product category is something that stands alone.

That doesn’t mean that it necessarily becomes subsumed into an existing SIEM technology or other security monitoring product/service stack, although that’s an option. We can easily build a case for why these emerging analytics platforms become the next generation SIEM. Our point is that the Team of Rivals concept is not a long term solution. At some point, organizations will need to simplify their environment and consolidate their vendors and technologies. They will pick a security monitoring platform, but we aren’t making bets as to what wins right now. Ergo, the need for a Team of Rivals.

Though having a combined and integrated solution at some point doesn’t really help you detect attackers in your environment right now. So let’s define what we mean by security analytics first, and then we can focus on how these technologies work together to meet today’s requirements, with an eye to the future.

In order to call itself a security analytics offering, it needs to do the following:

• Data Aggregation: It’s hard to do analysis without data. Of course, there is a question of whether the security analytics offering needs to gather its own data or whether it can just integrate with an existing security data repository (like your SIEM).
• Math: We joke a lot about the fact that math is the hottest thing in security now, especially given early SIEM correlation and the analysis that drove the first IDS products used math too. But this is different math, based on advanced algorithms and data management to find patterns within volumes of data unimaginable 15 years ago. The key aspect here (and what’s really different) is that you don’t need to know what you are looking for. It’s about having algorithms that help you identify the unknown unknowns. It’s a failed strategy to only look for attacks you’ve seen before and built rules to address.
• Alerts: This is the main output of a security analytics offering. You’ll also want to be able to prioritize the alerts based on criteria important to your business.
• Drill down: Once an alert fires, analysts will need to dig into the for both validation and to determine the most appropriate response. Thus the tool needs to be able to drill into the situation and provide additional detail to assist in the response.
• Learn: This is the tuning process, and any offering needs a strong feedback loop between the responders and the folks running the tool to refine the analytics in your environment, minimizing false positives and wasted time.
• Evolve: Finally, the tool must evolve since the adversaries are not static. This requires a threat intel/research team from the security analytics provider constantly looking for new categories of attacks and adding new ways to identify those attacks in the tool.

Of course, we could write a book about the nuances between the different approaches to security analytics and whether the criteria listed above is comprehensive enough. Or perhaps it’s too broad. The point being as the security analytics term evolves with the requirements of the market, the market will identify the most important criteria and which analytics approach survives. We are going to focus more tactically in this series, concerned only with how you can align your security monitoring technologies and emerging analytics capabilities to better identify attacks in your environment.

And in the next post we’ll start digging into those use cases and integration points that will require the Team of Rivals.

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

from Security Analytics Team of Rivals: Introduction [New Series]