top of page

The Autonomous SOC, is It Here Yet?

Updated: Jul 6

One of my first jobs back when I was in high school was a PBX Operator at a Hospital.  It was a new experience for me as I did the weekend graveyard shift and got to learn the hospital systems, their units, and all the policies and procedures around communications.  The job in itself was to answer and route calls to the right person and departments.  I was required to understand all the units of the hospital (ICU, NICU, Oncology, Radiology, OR, ER, etc).  In addition to this there were emergency codes in place, and as the operator, I was responsible for announcing this on the PA system! 

Why was this important? 

It’s important for every hospital staff member to understand what was going on, contextual awareness for proper response to the codes.  All hospital staff played their own parts in response efforts.  Many times it was all hands on deck, other times it was assisting in matters or communications to other staff so they can do their job.  In the most tragic incidents, it could mean death.  I remember the director of operations telling me…”it’s important to know what these codes mean, if you don’t, how are we going to prevent, detect, and respond?”

Prevention, Detection and Response.  Funny how those same terms are also used in cyber especially in the SOC.   Thinking back about when I was a responder, nothing was automated.  Down to the indicators of compromise we had to manually look for.  There was no such thing as an EDR.  It was good ol’ Firewalls and Antivirus.  And of course that was not enough!  We knew this and we responded by attempting to automate indicator searches (Antivirus would be blind to), via visual basic scripts on a continuous loop!  Containment, you ask?  Oh yea that was basically with registry queries, deep down in one of the registry hives.  Of course, the last resort option was physically pulling the plugs.  It was horrendous. 

The SOC has come a long way using nifty EDR/XDR solutions which have some “Autonomous” methods built-in.   It can automatically trigger on indicators of compromise, auto-triage, contain, and even get deep forensic details in a matter of minutes.   As a security analyst you look at these color coded alerts, just like the code oranges, reds and yellows in the hospital.  But more important, response needs to happen, just like in the hospital!  The real work begins as you retrieve other inputs and contextual awareness, to contain the threat and hoping that there is no tragic incident or loss.

Now the question is, are XDRs still enough?  Is the analyst trained and know how to respond regardless of the semi-automation in place? The “Autonomous” part needs to come in the fact that the actual security operations still need to move forward in that direction too. 

Some questions you may want to ask yourself on how to move towards an Autonomous SOC…

  1. Do you have threat intelligence built into your tech stack?  Most probably, YES to some extent.  But where is the “TI" coming from?  How often is it updated?  Are there numerous sources, or just one?  What are they and can you rely on them? 

  2. Are there any further analytics done with the feeds into your tech stack? 

  3. Are you relying on only tactical indicators or are there other strategic intelligence you focus on to understand adversary tactics, techniques, and procedures?

  4. What other curation efforts are in place?

  5. Is curation applied to all indicators or just some? (atomic vs computed vs behavioral)

  6. Lastly, can the analyst collaborate with others (humans and machines) in an automated method asking for questions as they go and get immediate feedback to move to the next stages?

The intersection of this all comes down to where humans meet technology and processes to do it all in a concerted fashion…and only then we truly have an Autonomous SOC.

The original article can be found here.

2 views0 comments

Recent Posts

See All


bottom of page