It’s brutal running a security operations center (SOC) today. The attack surface continues to expand, in a lot of cases exponentially, as data moves to SaaS, applications move to containers, and the infrastructure moves to the cloud. The tools used by the SOC analysts are improving, but not fast enough. It seems adversaries remain one (or more) steps ahead. There aren’t enough people to get the job done. Those that you can hire typically need a lot of training, and retaining them continues to be problematic. As soon as they are decent, they head off to their next gig for a huge bump in pay.
At the same time, security is under the spotlight like never before. Remember the old days when no one knew about security? Those days are long gone, and they aren’t coming back. Thus, many organizations embrace managed services for detection and response, mostly because they have to.
Something has to change. Actually, a lot has to change. That’s what this series, entitled SOC 2025 is about. How can we evolve the SOC over the next few years to address the challenges of dealing with today’s security issues, across the expanded attack surface, with far fewer skilled people, while positioning for tomorrow?
We want to thank Splunk(you may have heard of them) for agreeing to be the preliminary licensee for the research. That means when we finish up the research and assemble it as a paper, they will have an opportunity to license it. Or not. There are no commitments until the paper is done, in accordance with our Totally Transparent Research methodology.
SOC, what’s it for?
There tend to be two use cases main use cases for the SOC. Detecting, investigating, and remediating attacks and substantiating the controls for audit/compliance purposes. We are not going to cover the compliance use case in this series. Not because it isn’t important, audits are still a thing, and audit preparation should still be done in as efficient and effective a manner as possible. But in this series, we’re tackling the evolution of the Security OPERATIONS Center, so we’re going to focus on the detection, investigation, and remediation aspects of the SOC’s job.
You can’t say (for most organizations anyway) there hasn’t been significant investment in security tooling over the past five years. Or ten years. Whatever your timeframe, security budgets have increased dramatically. Of course, there was no choice given the expansion of the attack surface and the complexity of the technology environment. But if the finance people objectively look at the spending on security, they can (and should) ask some tough questions about the value the organization receives from those significant investments.
And there is the rub. We, as security professionals, know that there is no 100% security. That no matter how much you spend, you can (and will) be breached. We can throw out platitudes about reducing the dwell time or make the case that the attack would have been much worse without the investment. And you’re are probably right. But as my driver’s education teacher told me over 35 years ago, “you may be right, but you’ll still be dead.”
What we haven’t done very well is manage to Security Outcomes and communicate the achievements. What do we need the outcome to be for our security efforts? Our mindset needs to shift from activity to outcomes. So what is the outcome we need from the SOC? We need to find and fix security issues before data loss. That means we have to sharpen our detection capabilities and dramatically improve and streamline our operational motions. There is no prize for finding all the vulnerabilities. Like there are no penalties for missing them. The SOC needs to master detecting, investigating, and turning that information into effective remediation before data is lost.
Improved Tooling
Once we’ve gotten our arms around the mindset shift in focusing on security outcomes, we can focus on the how. How is the SOC going to get better in detecting, investigating, and remediating attacks? That’s where better tooling comes into play. The good news is that SOC tools are much better than even five years ago. Innovations like improved analytics and security automation give SOCs far better capabilities. But only if the SOC uses them.
What SOC leader in their right mind wouldn’t take advantage of these new capabilities? In concept, they all would and should. In reality, far too many haven’t and can’t. The problem is one of culture and evolution. The security team can handle detection and even investigation. But remediation is a cross-functional effort. And what do security outcomes depend on? You guessed it – remediation. So at its root, security is a team sport, and the SOC is one part of the team.
This means addressing security issues needs to fit into the operational motions of the rest of the organization. The SOC can and should automate where possible, especially the things within their control. But most automation requires buy-in from the other operational teams. Ultimately if the information doesn’t consistently and effectively turn into action, the SOC fails in its mission.
Focused Evolution
In this series, we will deal with both internal and external evolution. We’ll start by turning inward and spending time understanding the evolution of how the SOC collects security telemetry from both internal and external sources. Given the sheer number of new data sources that much be considered (IaaS, PaaS, SaaS, containers, DevOps, etc.), making sure the right data is aggregated is the first step in the battle.
Next, we’ll tackle detection and analytics since that is the lifeblood of the SOC. Again, you get no points for detecting things, but you’ve got no chance of achieving desired security outcomes if you miss attacks. The analytics area is where the most innovation has happened over the past few years, so we’ll dig into some use cases and help you understand how frameworks like ATT&CK and buzzy marketing terms like eXtended Detection and Response (XDR) should influence your SOC plans.
Finally, we’ll wrap up the series by taking the what (accurate detections) and turning them into the how (effective remediation), resulting in positive security outcomes. Operationalizing is a key concept in that context. So buckle up and come along on the SOC evolution ride as we define SOC 2025.
Reader interactions
One Reply to “SOC 2025: The Coming SOC Evolution”
Have you considered the SOC Assessment program from MITRE ATT&CK; Defender? Or the SEC450 output from SANS?
Here’s the outcomes I see for SOC/CIRT:
* Fast and Accurate Detection of Incidents by Alerting
* Minimize Impact of Incidents
* Provide an advantage over Threats
* Maintain awareness of systems, manage Threats, and coordinate Protection
Automation hasn’t been working right. Detection is getting better, but there is no “Shift Left” mentality. By this, most definitions of Threat Hunting and Detection only consider the endpoints and/or the UTMs (e.g., firewalls or secure-web gateways), and not the Active Directories, the Messaging Systems (or Messaging Security Platforms), or the cloud APIs/infrastructures.
My suggestion for Automation is to worry about case management first, and really only. A lot get lost in how they can speed up tasks in the SOC/CIRT, or solve compliance/vuln-mgmt puzzles to add more work to the SOC/CIRT. “If only we could respond to phishing submission faster” is the sort of approach — and it’s wrong — and I’m about to tell you why and how. It all goes back to the definition and areas of analysis for Detection… we need external threat hunting added to internal threat hunting before we can drive outcomes for these areas and beyond. To focus on case management means to focus on things like Incident Categorization and Prioritization — and even ask and answer correctly to “What defines an Incident (vs. a security Event, Alert, Observation, Investigation, etc)?”.
To focus on external threat hunting is to lever abuse, takedown, and other relationships that exist outside of the org. Here are some questions to consider: “What are the effects of long-lived C2 to our org, and how will it impact us compare to shorter-lived C2?”, or “How can we takedown stages and phishkits as, or even before, the actors put malware stages or corp credphish pages up on that infrastructure?”. In a lot of cases, livehunting VT and simple dynamic analysis on the results provides malstages to takedown, while for phishkits an org can grab the phishkits related to their problem set, report the exfil email to abuse contacts, close out API keys so that they no longe work, find out external resource calls, and block them.
No SIEM, SOAR, or XDR is going to help you do any of the above, so let’s stop focusing on them, and start moving towards the platforms that enable SOC/CIRTs to “Shift Left”