WTH is Modern SOC, Part 1
In recent weeks, coincidentally, I’ve had several conversations that reminded me about the confusion related to “modern SOC.” Some of them were public (example and example), while others private. One particular person went on a quest through several “leading” companies’ security operations to see how they have implemented a “modern” SOC. However, what she found was a lot of companies improving on the classic model, with visible elements of NOC and help desk “DNA” showing (bye-bye 1990s, hi 1980s!)
Brief History
Back in 2016 when I was a Gartner analyst, I was obsessed with the same question. As I said in my now-dead Gartner blog, a lot of security operation centers looked like they were built on a blueprint of a classic paper written by somebody from ArcSight around 2003 (don’t get me wrong, that was an epic SOC paper … for 2003!). As a result, the original “modern SOC” Gartner paper that we wrote in 2016 (“How to Plan, Design, Operate and Evolve a SOC”) focused on what the differences between a modern and a classic SOC may be (later we evolved this a bit in the updated 2018 version and there is a current version too, but of course without me…). However the conversations I mention above imply that we collectively still lack clarity on the modern SOC concept …
Autonomic Security Operations or “SOCless ‘SOC’”?
Note that there is another element to this discussion. Those who read the original Netflix 2018 SOCless paper would be very familiar with an engineering-led model for D&R operations (a more recent example). It is tempting to point at that approach, as we did in our original ASO paper, as the best model for modern “SOC” (even if you don’t want to call it “a SOC”, because the letter “O” is not truly relevant anymore).
However, 2018 is half a decade away and it pains me to say that the elements of this model are not widely adopted by many organizations, outside of the cream of the cream of the crop of tech companies. That model, while extremely effective (like “it would blow your mind if you knew the truth” effective), seems to be living exclusively in these ultra-elite companies [why? long story, probably Part 3 of this blog :-)].
So, is there anything else? If you see a SOC today, how would you know if this is a modern SOC? What is the essence of modern SOC? Is there such a thing? Or, what makes one operation traditional, even if (heavily) optimized, while the other one is truly modern?
False Promises
Some elements from our 2016 paper still look modern, but can be done a) in a non-modern manner or b) in a manner decoupled from a SOC. For example, you can have a SOAR tool (with its wild promise of automation) that you either cannot handle, or only use for phishing playbooks (what in my analyst days I called “baby’s first playbook”). Another example: you can hunt (outside the SOC), but then not flow the findings into detections powering your SOC.
Expansion beyond SIEM/logs was modern circa 2015, but now everybody has EDR. Everybody sane moved or is moving to SaaS SIEM. Threat intel use gradually expanded (even though few SOCs became truly intel-driven), but there is no revolution happening here — just improvements.
We treated selective use of outsourcing and MDRs (rather than the coarse-grained in/out old way) as a sign of modernity in a SOC, but as an auxiliary one at that (Augusto, thanks for the reminder here!). Automating L1 and L2 jobs is a goal, not a characteristic (How? What needs to be done for this? What would you gain if you do this?). Similarly, redoing the team structure away from the L1/L2/L3 funnel is a byproduct of a SOC transformation, not a goal.
So, can we do better? Ah, yes, sorry: AI! Sure, but if you add AI to a 1990s style operation, you will still have the 1990s-style operation, just with AI spouting stuff at the humans. AI does not transform anything on its own, humans do.
Glimmer of Hope
Now I offer a glimmer of hope here. I think the center of gravity for a modern SOC is automation.
Duh? “Anton, you sound like a 2013 SOAR vendor whitepaper!” Well, this blog is not from a chatbot spouting generic drivel, I’m trying to make an actual point..
Specifically, there is a dramatic difference between a CIO picking a vague theme of “SOC automation” from the proverbial airline magazine and building a modern engineering-led detection and response (D&R) capability.
It is the relentless drive to D&R automation powered by a rapid and thus effective feedback loop and engineering — led mentality.
To put it mildly, automation in a SOC is commonly misunderstood. In my travels, I’ve encountered many misconceptions such as:
- It is about removing all humans from SOC (that’s a non-goal BTW)
- It is just about buying a new tool (like SOAR) or writing an occasional script for something
- It is about automating L1s away or about hiring L1s with less knowledge/talent
Eh… no, not really!
Modern SOC, as I hypothesize here, is about a relentless drive to automate yourself out of a SOC job, something that SRE people did before us.
However, notice that I am talking about automating yourself out of the job in the context of SO. Well, Anton, how does this apply to a SOC team with a chasm between analysts and engineers or with no engineers anywhere in-sight (like a SOC running solely on vendor-made content)? For an analyst to automate themselves out of a job, they also need to be an engineer!
Is this engineering mindset common in SOCs? In a word, “no.”
So, we have a bit of a road ahead… I am thinking of another blog (Part 2) that examines other dimensions (beyond automation) that describe a modern SOC circa 2024. Please share ideas on what they are!
Thanks to Augusto Barros for a very valuable discussion!
Related resources:
