One pattern I spotted after looking at the evolution of IT and security organizations over the years, including my time at Gartner is: change is hard, but transformation is harder.

Perhaps it is an IT Axiom of some sort, with a Theorem I that follows: many who say they want to transform, really don’t.

And Theorem II: many wish for purported results of a transformed operation, but cannot bear many (any?) of the costs.

So when I hear that a certain security team or a security operations center (SOC) wants to transform to a new, modern model, numerous challenges arise. One significant factor is the tendency of individuals to become attached to the familiar processes and tools they have been using for an extended period, after sometimes investing a lot of blood, soul and fortune (vendor S comes to mind, but I digress … this is not really about SIEM). Additionally, there may be a concern that the new model will be more complex or challenging to manage, leading to even more reluctance to adopt it. This attachment can create resistance to change and make it challenging to embrace new approaches no matter what happens outside the organization.

It seems like there’s a desire for so-called “transformation lite” where few things change, but the results are comparable to that of a transformed organization. It is very clear to me that such a thing is utterly impossible.

Let’s bring this to our ongoing discussion of modern SOC. For example, in our now-infamous Ghost of SOC presentation (and a related paper), we have highlighted that some organizations really should go for an incremental improvement, not a transformation (the saddest part is the organization that perfectly fits out criteria for “need: maximum, must transform” and also fits our criteria for “capability: absent, absolutely unable to transform”… you won’t believe what happens next)

Hey, even Gartner agrees with this!

As you recall, we outlined a vision that we used to call autonomic security operation in the original paper (still a very useful resource despite a 2021 date). The pattern, as we have noticed over the years, is that many organizations that run traditional security operations centers are scared of a required scale of change. One prospect I spoke with humorously yet wistfully observed that he thinks “they can evolve there in 200 years.”

Modern SOC blog also highlights the fact that such “relentless drive for automation and engineering-led mentality” are difficult for many teams.

Thus, I cannot promise that I would …

a) give you three things to do which are also simple and reminiscent of your old practices, and

b) that you will get results compared to a truly transformed organization.

You really get to pick a) or b), not a) and b), GenAI or no GenAI.

Worse, since the Autonomic Security Operations (ASO) paper was published, I’ve been leaning to a view that the DNA of your SOC largely determines its fate (slide 11). SOCless DNA means you can scale with the threats and assets, 1980s NOC DNA means you will struggle or, at best, grow slowly.

OK, thanks for tolerating my rant! So the real topic of this is, What is the minimal set of practical and implementable requirements that would give you the biggest value and possibly send you down the path to SOC transformation? Perhaps the idea is that of a “Minimal Viable Transformation” here…

First, we need to agree to a few things (What? More rants, Anton? Well, yes!):

• You need to understandably tame your expectations. This is at best “transformation lite”, and at worst, merely using the ideas that others used to transform to slightly improve.
• Some of the magic happens at later stages of the transformation, even though the work happens starting from the first stage. In other words, work increases linearly, but some value occurs at later stages.

Eh… got any good news, Anton? In this “transformation lite” approach, the tooling may not need to be replaced at the initial stage. For some organizations, however, it is easier to replace the tools than to change the processes in any significant way, so this is “minor good news”, perhaps.

So, here is what I have:

If this is too complicated still … eh… then the first item that I always highlight when speaking on this topic is making sure that people who respond to alerts in your SOC (analysts) start to get closer to people who produce detections (engineers). This may mean having lunch once a month, rotating into each other’s roles for a week, or doing other things that send them down the path of understanding each other better and in some cases becoming the same team later on. So, if you truly need 1 thing, that is that it… but this won’t transform you, to be sure.

Some related posts (there is a lot more here):

• New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center”
• How to Banish Heroes from Your SOC?
• SOC is Not Dead Yet It May Be Reborn As Security Operations Center of Excellence
• Kill SOC Toil, Do SOC Eng
• WTH is Modern SOC, Part 1
• Stop Trying to Take Humans Out of SOC … Except … Wait… Wait… Wait…
• More SRE Lessons for SOC: Release Engineering Ideas
• EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil
• SRE books

Baby ASO: A Minimal Viable Transformation for Your SOC was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from Stories by Anton Chuvakin on Medium authored by Anton Chuvakin. Read the original post at: https://medium.com/anton-on-security/baby-aso-a-minimal-viable-transformation-for-your-soc-d6f922cac838?source=rss-11065c9e943e------2