Gartner Blog Network

SOAR and “Curve-jumping” in Security Operations

by Anton Chuvakin  |  October 20, 2017  |  7 Comments

Lets think about this together — can you really jump to the “next curve” in security, or do you have to travel the entire journey from the old ways to the cutting edge?

This is a harder question than it appears and there are temptations on both sides of the argument. Also, there are false answers on both sides, tempting though they may be (e.g. “always buy stuff with ‘next-gen’ in the name and you’d be at the cutting edge!” pitfall)

For example, should you try to maximize the value you can get from your traditional anti-virus or jump to some NG thing? Should you try to build a SOC circa 2002 and then evolve it to the modern SOC stage? Or should you try your hand at elite practices like threat hunting when you barely got to configuring your SIEM in a useful manner?

The main risk with the approach of incremental steps and traveling the same journey, that the top tier organizations have traveled, is that in 10 years, you’d still be 10 years behind…

The risks with curve jumping are many: you can jump and miss (wasting resources and time) or you can jump at the wrong curve or you simply have no idea where to jump and where the next curve is. After all, CRAWL-WALK-RUN is there for a reason, and there is no CRAWL-JUMP-JUMP…is there?

attrib license

Intuitively, it feels that jumping to NG tools (however defined) is possible (leaving whether it’s desirable aside, for now). But what about jumping to NG processes like, say, agile and DevOps (or DevSecOps, if you know what this is) – or even hunting and threat intelligence fusion? Does jumping to the next curve in terms of security processes and practices really require that your current processes are very mature – or not? In fact, can excessive current-gen process maturity make you excessively rigid, and thus less likely to jump to the next curve and to some next-gen process?

As it relates to SOAR and SOC/CIRT automation, this reduces the discussion to the following: should I implement manual processes first, refine them, refine them more and then progress to (partial) automation via a SOAR tool? Or, should you “curve-jump” to some next-gen SOAR-centric security processes, perhaps using SOAR magic?

Finally, please don’t hold it against me, but if I am given no additional context and no sufficient information, I usually lean towards incremental change and not jumping. In essence, I prefer to suffer from the risks of not jumping [which are very real!] vs the risks of jumping and missing (or jumping the the wrong curve) [which are just as real]…

[Discussion topic idea credit goes to Ben].

Blog posts related to this topic:

Category: monitoring  orchestration  security  soar  soc  

Anton Chuvakin
Research VP and Distinguished Analyst
5+ years with Gartner
17 years IT industry

Anton Chuvakin is a Research VP and Distinguished Analyst at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio

Thoughts on SOAR and “Curve-jumping” in Security Operations

  1. Shawn Riley says:

    I see a lot of people get wrapped around the axle on SOAR, and a lot of people seem to focus on the last step of the Cyber OODA Loop, Acting with machine language scripts rather focusing automation at the beginning of the cyber OODA loop on Sensing and Sense-making. Focusing on automating the sense-making of alerts and events with cybersecurity science processes like Claim + Evidence + Reasoning = Explanation (scientific argument) that informs decision-making is a more logical place to start. We want to build trust in AI and automation and sense-making is the right place to start since it is where we gather up the information and context and reasoning to make sense of the situation.

    • Thanks for a super-insightful comment. Indeed, we think obsession with “automated ***acting/blocking***” is mostly B.S. We see very little of that IRL, even though everybody talks about it. More valuable realistic SOAR use cases seem to be about collect, enrich, reason, etc and not act/block/clean.

      • Amos Stern says:

        I think it is hard to imagine those “blocking” actions in real life because most dont yet have the basics of retrieving all the data in place. For most its hard to imagine what automating collect/enrich/reason looks like, let alone jumping to block. It will take some time to build confidence in this process and would slowly grow to add more active responses (similarly like we allow our endpoint protection to block potential malicious detections (and even generic/heuristic ones).

        I think there is a balance in the middle.
        >> Automating the pre and post activities, not the decision making itself AKA empowering the analyst.

        I believe that we need to automate as much as possible from that OODA loop, but not in a way that removes the analyst from the equation.
        On one hand, as much collection and enrichment should be automated to be able to asses and present the full scope of the event to an analyst, leaving them to analyze and make a decision rather then collecting data. Then, on the other side, after a decision is made and a course of action is selected, there is no reason automation cant take over again to execute the course selected.

        In analogy, a pilot in a fighter jet gets all the info about a target collected and displayed to allow fast decision making, then after a decision is made a click of a trigger can send a missile that automatically tracks the target and essentially carries out the rest of the job. Leaving the pilot to focus on the next decision.

  2. Amos Stern says:

    Again I think that the answer is in the middle :)

    You dont need to “curve-jump” and teleport to the future, but you can fuel-rocket yourself there.
    In my opinion, a good SOAR solution should be able to help you through the journey and essentially help pave the way to get around this curve fast.

    You asked “should I implement manual processes first, refine them, refine them more and then progress to (partial) automation via a SOAR tool?”

    In my view, the real value of SOAR starts way before you get to automation. SOAR starts at the beginning of that question, not only at the automation in the end.
    It allows you to implement and improve those security operations processes, track them, manage and measure the operation, which in a second step you can start weaving the automation into.
    You dont use Salesforce because it can help automating processes, you do because it helps you manage, track and measure (aka orchestrate) – thus improving and allowing a more efficient sales operation – then you add automation where relevant to further improve that orchestrated process.

    • Amos, thanks a lot for your super-insightful comments. Indeed, it seems like very little of real-world use of SOAR is about A, but much more about workflow and a bit on O, but not really A by any reasonable definition.

  3. […] SOAR and “Curve-jumping” in Security Operations […]

  4. […] SOAR and “Curve-jumping” in Security Operations […]

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.