Life of a MSSP SOC Analyst

Previously, we talked about how much our society now depends on SOC analysts to keep our way of life intact, despite so many security professionals not receiving the gratitude they deserve for the stress and odd hours of that work. For SOC analysts who work at a Managed Security Services Provider (MSSP), they have all of those challenges and then a handful more. From my time building and leading a large MSSP, and then comparing notes with leaders at other MSSPs, these are challenges that I’ve confirmed are very universal.

#The Knife’s Edge Dilemma

All SOC Analysts have Air Traffic Controller level of stress. It’s Caesar’s proverbial thumbs-up or thumbs-down to decide the fate of an organization. Is the alert actionable? Is it really bad? Or is this another benign false-positive?

The SOC Analyst at the MSSP, however, has stress on another level higher still. Since the MSSP is a third-party to the actual organization that belongs to the detection the analyst is triaging (no matter how much the MSSP Sales Team promises “we are an extension of your team”), there is always a line of demarcation where the MSSP ends and the victim organization is left. For many MSSPs, this line is quite clearly observed when an analyst has to make the decision: escalate or do not escalate.

A SOC analyst on an internal team inside the company often has more direct access to systems, documentation, coworkers (including victim users who do silly things without knowing it), and in many cases more time to run down a case. The MSSP SOC analyst, however, is typically limited to interacting only with the security team at the customer organization.

So when that case comes in, the first thing a SOC analyst may be thinking is: “what if I’m wrong about this?” And “wrong” could mean both directions!

What if I’m “wrong” that the case is benign and can be ignored? What if this is the only signal we receive for a ransomware incident?? What is this is the beach head of an adversary, establishing persistent access? Shouldn’t I tell the customer about it, just in case? Isn’t it better to be safe than sorry?

But then, the devil’s advocate voice kicks in. What if I’m “wrong” and this turns out to be nothing? What I just can’t know what normal behavior is at my customer’s organization and this is completely fine? What if I’m just missing context, and when I send this over as an escalation I’m going to annoy my customer?? What if this is FINAL STRAW that breaks the camel’s back and the customer decides to choose a new provider, because we have too many false positives?

The pressure is not for the feint of heart!

#Learning the Environment

If you are a SOC analyst internal to a small company, it may be possible to learn the names, faces, and voices of coworkers, so when it comes time to ask a coworker about an alert, you can pick up the phone and know you’re talking to the real Jane Doe. But even for an internal SOC team, knowing names, faces, and voices starts breaking down around 250 employees or so. Once the organization gets in the thousands, the culture becomes a little more mechanical out of necessity.

Now imagine the MSSP SOC analyst who has tens or even hundreds of customer organizations, each of them with their own collection of thousands of employees. Knowing some names may be possible. Knowing voices is absolutely impossible. What if the MSSP SOC Analyst has to ask one of those thousands of people if a suspicious event was expected and authorized behavior? We certainly cannot expect them to use their own voice/face recognition to authenticate their response (i.e. GenAI deep fakes aren’t even needed).

Now do the same, but with IP address ranges, computer names (or maybe just naming conventions). It may be possible on some level to learn some of it, but when there are many different organizations bouncing around in your memory, it becomes hard to keep them all straight. This impacts the feel of the delivery to the end customer. If a customer wants a unique-to-them process to be implemented by the SOC, it becomes so difficult to do, while also growing and scaling the company. Every bespoke requirement that requires the MSSP SOC Analyst to do something special for a customer is a giant parachute brake slowing down scalable growth. Yet, the MSSP SOC Analyst has no choice but to try their best. This means keeping good notes and having complicated procedures, which means hiring a new SOC team member results in a daunting onboarding ramp-up time.

Even more difficult still is when a new customer is onboarded and brings with them a handful of bespoke characteristics that the MSSP will now support. Everyone is back in learning mode!

#The Clock is Ticking

To top it all off, MSSP SOC Analysts live and die by the SLA (service level agreement) timers governing their alert queues.

The history of how MSSPs have almost universally adopted the concept of having guaranteed response times based on the severity of cases is definitely worthy of its own separate post in the future. [Spoiler: I’d like to see this disappear from cybersecurity altogether.] Nevertheless … MSSP SOC teams typically have complicated queue logic that prioritizes certain cases over others based on a pre-conceived idea of what severity the case is. [Do you see the problem yet? I’ll spell it out in that future post soon.] For most teams, that means the MSSP SOC Analyst has to pull the most recent case off the top of the queue, because cherry-picking a case that looks interesting or easy for them to handle could result in one or many cases busting their SLA. They don’t get to pick the best case that matches their skillset, just the next case. If they don’t know Windows (they’re only skilled in Linux) or they don’t know GCP (they only know AWS) … they still have to figure it out before the time runs out. In theory, they can phone a friend but everyone on the team may be pulling from the same full queue. Nobody may be available to take a second look in time, or maybe not deep enough.

Once that case is decided, it’s on the next one.

And the next one.

And the next one.

And the next one.

And …

The clock doesn’t stop. An efficient MSSP at scale will have what feels like a perpetual backlog of cases to triage. And on the days when the internet is on fire (e.g. new vulnerability or an epic level outage), it only gets worse.

This adds immense pressure on the MSSP SOC Analyst to make the right decision! The image below is in jest (I’ve never met a SOC Analyst who actually uses a magic 8 ball to verdict a case), but the point is sometimes you have to flip a coin because you’re out of time! And just like that, we are back to the knife’s edge dilemma (above), with added stopwatch pressure.

#Building something better

At Wirespeed, we really want to improve these common MSSP conditions for SOC Analysts. We’ve built entire workflows aimed at eliminating the pain of both the internal SOC Analyst and the MSSP SOC Analyst, and we hope this becomes a catalyst for change to eliminate the burnout commonly associated with these critical job roles! Check out our MSSP use cases and connect with us to see how we can bring this to your team!

---

Want to know more about Wirespeed? Follow us on LinkedIn / X or join our mailing list.