Where do SOC “Tier 1” and “Tier 2” come from?

In late 2024, I still hear people using the phrasing of “Tier 1” and “Tier 2” SOC. I bet you do, too. Maybe you’re one who does? Do you know where it comes from? Are you actually doing the difference between “Tier 1” and “Tier 2”?

What about “Tier 3” and “Tier 4”? I sometimes hear people say those, too.

Sometimes, you’ll even hear people say “L1, L2, L3…” (which is actually a giveaway for this term’s origin).

In so many ways, “Tier 1” and “Tier 2” SOC is just another version of The Pot Roast Story.

#The IT Roots

Once upon a time, when computers and the Internet were new, even big companies only had small teams of technical people running IT. Those people did everything: new projects, upgrades, support, whatever. As time went by, roles specialized, and the concept of “IT Support” was introduced.

As businesses grew in complexity and need, the IT Support teams had to grow to match. Businesses quickly realized that an entry level support person was adequate for a large percentage of support requests, leaving the more technically advanced people available to solve the more challenging problems. The concept of layered support was born.

Even before the year 2000, it was fairly established among the enterprise and mid-market segments to have a Level 1 and Level 2 Help Desk organization structure. Level 1 answered phones and worked support cases that came into queues via email. What they couldn’t handle went to Level 2. What Level 2 couldn’t handle went to the various teams that “owned” the applications and infrastructure associated with the problem, often referred to as Level 3. Sometimes inside those “product owner” teams, there was a super senior principal technical architect blah blah blah titled person, who, if the ticket came to them, would be considered Level 4.

Something like this diagram:

Sometimes, organizations would refer to the IT Support Levels as Tiers. See where this is headed?

#Security Teams were Born

When “computer security” or “network security” as it was often called in the early days, followed by “Information Security” more commonly after that, there wasn’t an immediate emphasis on Detection and Response. In those days, most everything was about Prevention, which we’ve discussed before in Where do Detections Come From and Left and Right of Boom. When Detection became important, the supporting response workload was often dropped on the entirety of the Security Team, even after hours. Smart teams developed call rotation schedules. Smarter teams tried to involve their Level 1 and Level 2 Help Desk for extra support.

Somewhere along those lines, it became apparent that a dedicated Security Operations Center (SOC) was needed: a team consisting of people who were all trained on security, but maybe at varying degrees, just like the Help Desk. While there were some early adopters, this concept largely sprang into existence between 2000 and 2010 for enterprises, with mid-market organizations trailing.

As we discussed in Adversaries are Speeding Up, the earliest public metrics on adversary dwell times (the time from when an adversary gained unauthorized access to the time they were noticed–not necessarily blocked) did not exist until 2011 from Mandiant, and at that point the average was more than 400 days! Why does this matter? Because if you just started cybersecurity in the last couple years, you’d understand there is a significant emphasis on speedily addressing threats that are discovered inside your environment, but that emphasis was NOT the same 15-20 years ago! The absence of urgency was certainly a compelling reason why SOC teams could afford to adopt the Tier 1 / Tier 2 concept.

#What exactly is Tier 1?

Tier 1 was born out of that Help Desk era, long before automation tools like SOAR. Just like on IT Support teams, there was a need for more people to help, but there weren’t enough qualified people to work incidents start-to-finish, so the idea was to hire more junior people and have them help with the early stages of alert triage. Alerts would come into the SOC, unenriched, often without context, often repetitively and noisily, and without regard to the time impact on the SOC to process them. The idea was simple: newer, more junior people on Tier 1 would do a first pass on alerts and then hand off important alerts to the more senior people on the Tier 2 team, whose time was limited.

It’s also important to note that when people (in 2024) use the terms “Tier 1” or “Tier 2” and “SOC,” I often ask them to define those terms, because there is a bit of a sprawl in definition and meaning (as you’ll see below). Generally speaking (with all the challenges that come from speaking generally) cyber people tend to mean “initial triage” with the term “Tier 1” and “initial response” with “Tier 2.” But if you take nothing else out of this article, take this: just ask your audience what they mean when they say “Tier 1” or “Tier 2.”

#Tier 1 deals with Vulnerabilities?

There are still some sources out there that define “Tier 1” as dealing with “vulnerabilities.” That definitely doesn’t happen in large enterprises, as vulnerability management is a whole category unto itself. Maybe smaller organizations, who probably don’t care about these Tier 1/2 terminology distinctions at all, might do both, because “Security Operations” is anything unplanned, and a new vulnerability being discovered and on fire on the internet definitely meets the definition of “unplanned.”

That said, even the products that support vulnerability management tend not to bother with the “Tier 1” or “Tier 2” nomenclature any longer. So why there are still semi-reputable resources online claiming “vulnerabilities” are part of the Tier 1 SOC work is a little confusing.

SOC teams definitely will respond to detections and alerts about vulnerabilities being exploited, but that’s entirely different.

#The Flaws in the Tier 1/2 Model

Regardless, there are flaws in the idea of separating SOC workflows this way:

1. The idea that it’s possible to hire someone too junior to work cases all the way through, but smart enough to know what to dismiss to save the Tier 2 Analyst’s time, doesn’t make sense. There’s no way around it: the junior Tier 1 person is making decisions on alerts. If they’re not qualified to make decisions, why pretend they’re not making decisions? What if they erroneously dismiss the wrong things?

2. The counter to problem #1 is usually “Yeah, well, we train Tier 1 Analysts to just look for certain things before they dismiss.” OK. But if the list of things to look for is simple enough to train someone brand new to cybersecurity, wouldn’t it also be simple enough to automate? (Hint: the answer is Yes!)

3. Some SOC teams use their Tier 1 person as sort of a gopher. “Take this unenriched alert out of our SIEM. Look up the IPs, domains, hashes, hostnames, usernames, user metadata, anything else we can know about the host … maybe even sprinkle in the weather report and the current NASDAQ summary … and then update the case with this information so a Tier 2 Analyst can review it.” In other words, they want Tier 1 to act like a summer intern, except don’t go fetch our coffee, because you need to “keep your eyes on glass” (the SOC team’s workbench console UI). The problem with this is that any enrichment you can ask someone so junior to do can also be automated. Years ago, when dwell times were 400+ days, this was fast enough, but in a modern SOC where the threats are imminent and a swift response is expected, the “summer intern” approach takes too long!

#What exactly is Tier 2?

You can make the inference that, again generally speaking, “Tier 2” analysts are the ones who make the decisions about how to act on alerts that fire in the SOC.

I sighed as I wrote this, because this isn’t always the case. In the name of being efficient, SOCs years ago started handing off certain types of alerts or cases for “Tier 1” analysts to resolve start-to-finish, just like Level 1 IT Help Desk analysts started to complete common tasks that would be escalated to Level 2 Support. When something seems repeatable and well-understood, pass it down. After awhile, this blurs the lines and initial reasons of the two tiers.

#Isn’t Tier 1 or 2 just a Job Title?

HR departments, wanting to help, often started organizing SOC teams into job titles that match these roles, like “SOC Analyst I” and “SOC Analyst II.” Commonly, you’ll find a third tier title reserved for an individual contributor who is senior, such as “Senior SOC Analyst” or “SOC Analyst III,” but that doesn’t often refer to a “Tier 3” in the SOC. It typically represents someone who becomes the standard bearer for quality and training the other analysts.

Of course, there’s also the Team or Shift Leads; supervisory positions and job titles that reflect the people leadership of other analysts. Also: not another “Tier.”

So, yes there are job titles, but no, don’t get them confused with the intent behind the Tier 1/2 concept. In fact, it’s super common to see SOC job titles with various “decorators” (I, II, III, IV, Senior, etc.) and it has more to do with how much the person is paid, which has more to do with their interview and negotiation skills, than it does with the specifics of the work that is required of them in their role.

#Is there a SOC Tier 3?

This is where this whole model really breaks down. I’ve heard people refer to “SOC Tier 3” as “Incident Response,” which means that, presumably, an alert came in, was initially triaged or college-intern-enriched by a “Level 1 Analyst,” who then moved the case forward to the “Tier 2” ticket queue, and then a “Tier 2” analyst reviewed it and realized this was the proverbial tip of the iceberg above water, and a full incident needed to be declared. THEN … a “Tier 3” role became involved with the case. In my experience, it’s more common to refer to these people as “Incident Responders,” and not with a “Tier 3” designation, but you will likely hear or read that at some point. This is also why I frequently ask people what they mean by “Tier 1” or “Tier 2.”

I’ve also heard people say “Incident Response” happens at “Tier 2,” so is it any wonder we confuse people new to cybersecurity?

If we can’t all talk about it uniformly, we definitely aren’t all doing the work uniformly.

Sometimes people say “Tier 3” is the tier where “Threat Hunting” happens, i.e. proactively searching for signs of compromise, rather than waiting for instrumentation and telemetry to indicate compromise through pre-existing detections and alerts. Sounds logical, maybe, except I’ve also seen people say “Tier 2” does “Threat Hunting.” It just goes to show how all over the place cybersecurity is on such an important function: Detection & Response. And if we can’t all talk about it uniformly, we definitely aren’t all doing the work uniformly.

#Is there a SOC Tier 4?

Oh please no. I just can’t.

So, this is (probably) how most people view the SOC Tiers, at least from a legacy terminology perspective:

#Is the Tier 1 and Tier 2 Model Dead?

I’m not pronouncing the terms dead. They’re dead already. They’re confused, even by cybersecurity practitioners with a decade-plus of experience. The terms overlap and there appears to be no real authority about them at all. The concepts and work are hardly dead. We’re doing them right now, as you read this!

Chances are, if your organization still uses these terms, you’re really just referring to a ladder of career progression, and maybe indicating that a junior person’s work is reviewed by a more senior person. That’s fine, but it’s not the intent behind the original Tier 1/2 concept or terms.

#What terms should I use instead?

So let’s suppose you don’t want to perpetuate the confusion around the Tier 1 / 2 terms (which presumes you’re not emotionally invested in these terms, of course). What terms should you use instead? I can tell you what I tend to use to make sure whomever I’m talking with understands exactly what I’m saying, the main verbs from eaech step:

• Triage: the process of sorting alerts (but not everyone uses the word “triage” to require a “verdict” so we call “verdict” out on its own next)
• Verdict: the final judgment of whether the alert is actionable or not
• Containment: steps to minimize the damage represented in the alert
• Incident Response: a formal process that includes forensics and a big picture set of containment steps, necessary when one or more alerts indicate a threat actor likely has persistent access to an environment.

#Did SOAR Kill Tier 1

Well, yeah. Sort of. Should have.

I, and many other SOC leaders, have implemented SOAR in large scale SOCs in such a way that the need for a Tier 1 analyst to manually perform queries to enrich alerts is long gone. So if your definition of “Tier 1” is enrichment, then yes. If your definition is to weed out noisy, known false-positive alerts, properly disposing of them, then maybe. It is certainly possible to do that (I did that at a large MSSP with 300+ enterprise clients and $100M ARR).

The primary problem with SOAR or hyperautomation is defining good processes, not implementing them.

Yet, SOAR projects failed miserably at many mid-market organizations and SMBs rarely (if ever) have them, because integrating and tuning them require time and expertise. Even many larger enterprises struggle with this, hence the entire hyperautomation (SOAR++) category was born. The claim is that organizations can’t write the code required to implement SOAR. My counter to that claim is that low-code and no-code SOAR have been around for a long time, with some adoption, and also with many of those same challenges. The primary problem with SOAR or hyperautomation is defining good processes, not implementing them.

If you define “Tier 1” as assigning verdicts to alerts, i.e. definitively asserting whether each alert is actionable or not, then no, SOAR didn’t do that, hence why organizations who couldn’t afford to hire, train, and retain SOC people would typically buy MDR/MSSP services instead.

#What about AI & LLMs?

There are several GenAI / LLM products that are new to the market in the last year or two. No LLM SecOps solution that I have seen will confidently state they will do the work of both Tier 1 and Tier 2 SOC analyst. Most state they reduce the amount of effort required by the SOC or that they’ll “replace Tier 1,” but as seen above, many (including me) did that before with legacy SOAR. This is part of the reason we have chosen not to implement LLMs as part of our approach. The inability to predict how an LLM based solution will handle a given alert or detection is reason enough to require humans to review the output of every case thoroughly, and if you’re reviewing every case, you’re basically doing the work yourself. It’s not removing much, if any, labor (and possibly adds more labor overall from the QA processes required).

#WHY DO I EVEN CARE ABOUT TIER 1/2?

Well, thank you for reading this far (or just quickly scrolling to the bottom)!

The only reason this matters, and why I’m taking the time to recap the history and the relatively conflated definitions of the terms, is to point out where Wirespeed resides when compared to the SOC Tier model.

Here’s our view of how the Tiers should be defined:

1. Tier 1 is summarized as Triage. All alerts are enriched. False positives are disposed. Related alerts are grouped into a single case. Cases have verdicts: actionable or not actionable.

2. Tier 2 is summarized as Containment. Actionable cases perform containment steps against endpoints, identities, and workloads.

3. Tier 3 really isn’t a Tier. It’s really just Incident Response and only for major incidents in which the initial alert telemetry suggests something very bad is happening. Why only “initial alert telemetry?” Because if alerts have fast and accurate containment steps, the only alerts that become major incidents are those alerts which indicate an attacker was able to take one or more initial access steps undetected. At Wirespeed, an example of this is how we handle Late Stage malware events. Initial access malware that is contained is no big deal, really, but late stage malware, even if contained, means we’re only seeing the tip of the iceberg and requires full Incident Response.

4. No more tiers. Definitely no Tier 4. Just overall program management (governance).

#Where Wirespeed Lives in the Tiers

I’ve given Wirespeed demos and at the end had someone say, “Oh, so you’re automated Tier 1.”

My gut reaction is to say: “No, we’re automated Tier 1 and Tier 2,” but in practice this gets confusing becauase nobody is using these terms the same way.

So here is the simple way to spell it out:

• Wirespeed does automated enrichment of all alerts.
• Wirespeed automatically groups similar and related alerts into cases.
• Wirespeed does automated triage, assigning verdicts to cases.
• Where needed, Wirespeed automatically asks users questions (via Slack, Teams, Email, SMS) to complete investigations and assign final verdicts.
• Wirespeed then does automated containment, for some or all cases requiring it, based on your preference. Wirespeed will even ask you, the Security Team, for permission first, if that’s your preference.
• If the telemetry indicates containment may be incomplete (see the iceberg above), Wirespeed automatically recommends full Incident Response.

Or how we like to think of it, we automate Right of Boom, and we’re really, really fast and accurate at it:

---

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