We spent the last post figuring out how to aggregate security data. Alas, a lake of security data doesn’t find attackers, so now we have to use it. Security analytics has been all the rage for the past ten years. In fact, many security analytics companies have emerged promising to make sense of all of this security data.

It turns out analytics aren’t a separate thing; they are part of every security thing. That’s right, analytics drive endpoint security offerings. Cloud security products? Yup. Network security detection? Those too. It’s hard to envision a security company of scale without analytics playing a central role in providing value to their customers.

As a security leader, what do you have to know about analytics and detection as you figure out how the SOC should evolve? First, it’s not about [analytics technique A] vs. [analytics technique B]. It’s about security outcomes, and to get there you’ll need to start thinking in terms of the SOC platform.

Defining the SOC “Platform”

The initial stab at the SOC platform already exists with some overlapping capabilities. You already have a security monitoring capability, maybe an on-prem SIEM. As discussed in the last post, the SOC platform should include threat intelligence. Currently, some organizations use a separate threat intel platform (TIP) to curate and prioritize the incoming external data. The third leg of the SOC platform is operations, where validating, verifying, and ultimately addressing any alerts happens. We’ll have a lot to say about security operations in the next post.

Though it may seem the evolved security operations platform is just bolting together a bunch of stuff you already have, we are advocating for an evolutionary approach in the SOC. You certainly could ditch the existing toolset and start from scratch, and as liberating as that may be, it’s not practical for most organizations. For instance, you’ve spent years tuning your on-prem SIEM to handle existing infrastructure, and you have to keep the SOC operating, given the attackers aren’t going to give you a break to accommodate your platform migration. Thus, it may not make sense to scrap it. Yet.

Although you do have to decide where the SOC platform will run, here are some considerations:

• Data Location: It’s better to aggregate data as close to the originating platform as possible, so you keep cloud-based security data in the cloud, and on-prem systems go into an on-prem repository. That minimizes latency and cost. In addition, you can centralize alerts and context if your operational motions dictate.
• Operations Approach: Once the alert fires, what then? If you have an operations team that handles both cloud and on-prem issues, then you’ll need to centralize. The next question becomes do you consolidate the raw security data, or just the alerts and context?
• Care and Feeding: How much time and resource do you want to spend keeping the monitoring system up and running? There are advantages to using a cloud-based, managed platform that gets you out of the business of scaling and operating the infrastructure.

The long-term trend is towards a managed offering in the cloud, but how quickly you get there depends on your migration strategy. If you’ve decided that your existing SIEM is not salvageable, then you are picking a new platform for everything and migrating as quickly as possible. But we see many organizations taking a more measured approach, focusing on building the foundation of a new platform that can handle the distributed and hybrid nature of computing in the cloud age while continuing to use the legacy platform during the migration.

Analysis

Once you have internal and external data collected and aggregated, you analyze the data to identify the attacks. Easy, right? Unfortunately, there is a lot of noise and vendor puffery for how the analytics actually work, making it confusing to figure out the best approach. Let’s work through the different types of techniques used by SOC tools.

1. Rules and Reputation: Let’s start with signature-based controls, the old standard. You know, the type of correlation your RDBMS-based SIEM performed for decades. Adding patterns enumerated in the ATT&CK framework (which will discuss later in this post) helps narrow the scope of what you need to look for, but you still need to recognize the attack. You’ll need to know what you are looking for.
2. Machine Learning: The significant evolution from simple correlation is the ability to detect an attack you haven’t seen. Advanced analytics can be used to define an activity baseline, and with that baseline defining normal behavior within your environment, your detection engine can look for anomalies.

Getting into the grungy math of different machine learning models and cluster analyses probably won’t help you find attackers faster and more effectively. Continue to focus on the security outcomes during your evaluation. Does it find attacks you are likely to see? How much time and effort will it take to isolate the most impactful alerts? What’s involved in keeping the platform current? And ultimately, how will the platform’s analytics make the team more efficient? Stay focused on ensuring any new platform makes the team better, not on who’s math is better.

Use Cases

You may be bored (and maybe frustrated) with our constant harping on the importance of use cases in detecting attacks. There is a method to our madness in that use cases make a pretty nebulous concept more tangible. So let’s dig into a handful of use cases to get a sense of how a SOC platform will favorably impact your detection efforts.

Ransomware

Ransomware doesn’t seem to get as many headlines nowadays, but don’t be fooled by the media’s short attention span. Ransomware continues to be a scourge, and every company remains vulnerable. Let’s examine how an evolved SOC handles detects ransomware? First, ransomware isn’t new, particularly not the attacks — it typically uses commodity malware for the initial compromise. Attackers are more organized and proficient — once they have a foothold within a victim’s network, they perform extensive reconnaissance to find and destroy backups, increasing pressure to pay the ransom.

The evolved SOC platform integrates telemetry and data from external and internal sources, using analytics to identify malicious intent. Many of your controls will be lighting up during a ransomware outbreak, and that’s good. The SOC tooling can take the alerts from each of the controls and pinpoint the type and extent of the outbreak, minimizing noise and focusing efforts on the root cause of the attack.

For example, you’ll first see the ransomware outbreak on the network, along with ongoing reconnaissance and attempts to compromise additional devices. Then you’ll see privilege escalation on a compromised device and likely some more recon to identify the backup systems and other vital assets. The SOC platform can weave these various data sources together to provide invaluable context to help responders understand the situation faster, making a huge difference in containing the damage.

Threat Hunting

Threat hunting is proactively looking for attackers in your environment before getting an alert from another detection method. Hunting involves more art than science as hunters start with a plan to look for certain activities indicating active adversaries. Then they mine security data to find and follow an attacker’s trail to identify what the attackers have done and project what they’ll do next. A modern SOC platform provides broad and deep security data collection, along with the ability to pivot through data effectively.

No security tool will turn an entry-level analyst into a world-class hunter. But the SOC platform can accelerate and improve any reasonably capable security professional’s hunt. Further helping the hunter are common queries, typically pre-loaded into detection tools to kickstart hunting efforts. These rules don’t make the hunt, but they can codify common searches likely to uncover malicious activity — including drive-by attacks, spear phishing, privilege escalation, credential stuffing, and lateral movement.

Insider Threat

The classic “inside job” typically involves an employee acting maliciously to steal data or sabotage systems. The insider knows the company’s defense’s weak points, so this is a particularly impactful and damaging attack. We have a broader definition of insiders, as external actors with control of a device inside the network are technically insiders because they have access and privileges to internal resources.

You use the collection and analysis capabilities of the SOC platform to identify anomalous activity from employees (and their devices). Given that insiders can be anywhere, you’ll need a broad collection effort, including telemetry from all remote employees and cloud resources. In terms of analysis, deviations from the typical activity baselines are the strongest indicators of malicious activity. This capability was called UEBA (user and entity behavioral analytics), but nowadays it’s considered just another use case for a SOC platform.

ATT&CK

We learned in Security 101 class that understanding TTP (Tactics, Techniques, and Procedures) is key to detecting attacks. These help piece together attack timelines, accelerating assessment of attack damage and proliferation. But the challenge of an attack timeline is that it occurs after the attack has succeeded. It’s helpful to ensure protection from that same attack vector in the future, but you are still blind to attacks you don’t know.

What if you could get a list of most of the attack techniques you’re likely to see in your environment? You could use that list to tune your detection techniques to what you’re likely to see coming over the transom. You could identify gaps in your data sources to eliminate blind spots to detection. You could even test your controls against these attacks to determine holes in your defenses. MITRE and other industry contributors have given us this kind of list. It’s called the ATT&CK framework. Of course, you don’t find attackers by running around with a list of TTPs. But ATT&CK can help focus your efforts.

The ATT&CK framework enumerates hundreds of attack techniques. And it’s increasingly expected that SOC tooling will map data into ATT&CK, so you can visualize the gaps in your defenses and determine how to address any deficiencies most effectively.

XDR

Let’s start with a definition: “Extended Detection and Response (XDR) collects and correlates data across multiple security layers – network, servers, endpoint, and cloud.” So how is that different than what we’ve been trying to do with SIEM for two decades? Yeah, it’s not significantly different. But all the same, XDR is very shiny, and any company doing security detection is planting a flag on Mt. XDR. Since detection is one of the critical functions of the SOC, that means we need to discuss where XDR fits into your SOC tooling.

Suppose you consider XDR to be an uber-detector assuming the responsibilities of SIEM, EDR, NDR, and even some cloud detection leveraging a common datastore and performing advanced analytics to find anomalies and attack indicators for broader, multi-faceted campaigns. In that case, that sounds pretty good, no? Who doesn’t want to collapse various monitoring tools into one platform that handles everything more effectively?

Here’s the problem, at least in XDR’s current incarnation. It doesn’t speak to the reality of the installed base within most enterprises. You already have security monitoring technology, which you probably don’t want to (or can’t) forklift. You have a compliance requirement, so you’ve got to keep your SIEM around. While we believe the idea of a common, open way to integrate the telemetry from all of your sensors and do advanced analysis is great, it’s all in how you get there.

You have options to achieve the promise of XDR. If you need to totally overhaul your SOC tooling and have limited compliance requirements, considering an XDR would make sense. But it also may make sense to embrace an “Open XDR” concept that allows you to leverage existing sensors and analytics with supplemental solutions to address weaknesses in the monitoring environment. You can also consider how your existing monitoring vendor(s) are moving towards their vision of XDR, which may satisfy your requirements. Both revolution and evolution are reasonable paths.

We’ll wrap up the series with an idea about how your operational security environment needs to evolve to fully take advantage of the enhanced collection and detection capabilities of your SOC.