Security Analytics Team of Rivals: Coexistence Among Rivals
As we described in the introduction to this series, security monitoring has been around for a long time and is evolving quickly. But one size doesn’t fit all, so if you are deploying a Team of Rivals they will need to coexist for a while. Either the old guard evolves to meet modern needs, or the new guard will supplant them. But in the meantime you need to figure out how to solve a problem: detecting advanced attackers in your environment. We don’t claim to be historians, but the concept behind Lincoln’s Team of Rivals (Hat tip to Doris Kearns Goodwin) seems applicable to this situation. Briefly, President Lincoln needed to make a divisive political organization work. So he named rivals to his Cabinet, making sure everyone was accountable for the success of his administration. There are parallels in security, notably that the security program must, first and foremost, protect critical data. So the primary focus must be on detection and prevention of attacks, while ensuring the ability to respond and generate compliance reports. Different tools (today, at least) specialize in different aspects of the security problem, and fit in a security program different places, but ultimately they must work together. Thus the need for a Team of Rivals. How can you get these very different and sometimes oppositional tools to work together? Especially because that may not be in their best interest. Most SIEM vendors are working on a security analytics strategy, so they aren’t likely to be enthusiastic about working with a third-party analytics offering… which may someday replace them. Likewise, security analytics vendors want to marginalize the old guard as quickly as possible, leveraging SIEM capabilities for data collection/aggregation and then taking over the heavy analytics lifting from to deliver value independently. As always, trying to outsmart vendors is a waste of time. Focus on identifying the organization’s problems, and then choose technologies to address them. That means starting with use cases, letting them drive which data must be collected and how it should be analyzed. Revisiting Adversaries When evaluating security use cases we always recommend starting with adversaries. Your security architecture, controls, and monitors need to factor in the tactics of your likely attackers, because you don’t have the time or resources to address every possible attack. We have researched this extensively, and presented our findings in The CISO’s Guide to Advanced Attackers), but in a nutshell, adversaries can be broken up into a few different groups: External actors Insider threats Auditors You can break external actors into a bunch of subcategories, but for this research that would be overkill. We know an external actor needs to gain a foothold in the environment by compromising a device, move laterally to achieve their mission, and then connect to a command and control network for further instructions and exfiltration. This is your typical adversary in a hoodie, wearing a mask, as featured in every vendor presentation. Insiders are a bit harder to isolate because they are often authorized to access the data, so detecting misuse requires more nuance – and likely human intervention to validate an attack. In this case you need to look for signs of unauthorized access, privilege escalation, and ultimately exfiltration. The third major category is auditors. Okay, don’t laugh too hard. Auditors are not proper adversaries, but instead a constituency you need to factor into your data aggregation and reporting efforts. These folks are predominately concerned with checklists. So you’ll need to make sure to substantiate the work instad of just focusing on results. Using the right tool for the job You already have a SIEM, so you may as well use it. The strength of a SIEM is in data aggregation, simple correlation, forensics & response, and reporting. But what kinds of data do you need? A lot of the stuff we have been talking about for years. Network telemetry, with metadata from the network packet streams at minimum Endpoint activity, including processes and data flowing through a device’s network stack Server and data center logs, and change control data Identity data, especially regarding privilege escalation and account creation Application logs – the most useful are access logs and logs of bulk data transfers Threat Intelligence to identify attacks seen in the wild, but not necessarily by your organization, yet This is not brain surgery, and you are doing much of it already. Monitors to find simple attacks have been deployed and still require tuning, but should work adequately. The key is to leverage the SIEM for what it’s good at: aggregation, simple correlation (of indicators you know to look for), searching, and reporting. SIEM’s strength is not finding patterns within massive volumes of data, so you need a Rival for that. Let’s add security analytics to the mix, even though the industry has defined the term horribly. Any product that analyzes security data now seems to be positioned as a security analytics product. So how do we define “security analytics” products? Security analytics uses a set of purpose-built algorithms to analyze massive amounts of data, searching for anomalous patterns indicating misuse or activity. There are a variety of approaches, and even more algorithms, which can look for these patterns. We find the best way to categorize analytics approaches is to focus on use cases rather than the underlying math, and we will explain why below. We will assume the vendor chooses the right algorithms and compute models to address the use case – otherwise their tech won’t work and Mr. Market will grind them to dust. Security Analytics Use Cases If we think about security analytics in terms of use cases, a few bubble up to the top. There are many ways to apply math to a security problem, so you are welcome to quibble with our simplistic categories. But we’ll focus on the three use cases we hear about most often. Advanced Attack Detection We need advanced analytics to detect advanced attacks because older monitoring platforms are driven by rules –
