The SOC Anatomy

Disclaimer: Images were generated with AI. The written content is entirely my own.

What is a SOC ? Where does it live? What does it eat?

Introduction

Security Operation Center - or SOC, because cybersecurity loves acronyms (as you might already know or soon will) - is the place where a peculiar species known as information security (or cybersecurity, if we want to be precise and slightly dramatic) professionals live, breathe, and occasionally argue with dashboards and queries.

The SOC is responsible for continuously monitoring and evaluating the security posture of an environment. In other words, that means tracking everything that happens across the infrastructure and responding when something looks weird, wrong, or very, very wrong. It’s where ongoing security operations are managed, incidents are investigated and sleep schedules go to die.

This is achieved by collecting logs from a wide range of sources - routers, endpoints, servers, firewalls, cloud services, and that one legacy system nobody dares to touch. This logs are transformed into events and fed into a centralized, always-hungry, log-eating beast known as Security Information and Event Management system, or (SIEM). Don’t worry, we’ll dissect it’s anatomy later.

If we had to summarize the functions of a SOC in one sentence, it would be:

Protect the CIA triad - Confidentiality, Integrity and Availability - of the data in cyberspace.

Now that we’re past the opening statement, my suggestion is for you to dust off your hard drive - or SSD, if you are younger - and lay the groundwork for some once forgotten (or ignored) information security concepts and important keywords. Before alerts, incidents, and on-call rotations, we need a quick INFOSEC refresher: risk, access control, trust, policies, controls, and the frameworks that quietly hold the whole SOC together.

And yes - this part matters more than people like to admit it. Check it out HERE.

I’ll wait for you to finish

Back to the SOC

All concepts discussed in Information Security Refresher don’t live in isolation. They are actively used, monitored, and enforced inside the Security Operations Center. The SOC is where theory meets reality - and where things rarely go according to plan.

To first understand how SOC operates, we first have to understand the people behind it.

SOC Roles

SOC is typically structured in tiers or levels, where each one has different responsibilities, expertise, and caffeine intake.

Tier 1 - Analyst (L1)

First line of defense. Responsible for monitoring alerts, reviewing logs, and performing initial triage. Their job is to determine whether something is a false positive or requires further investigation. Other activities that encompass their responsibilities are incident triage, first-line analysis and investigation, documenting and reporting, escalation and collaboration, continuous improvement and cross-training.

In pizza terms: they are the ones watching the pizza room cameras, noticing something suspicious, and asking, “Is that Bob… again?”.

Tier 2 - Analyst (L2)

First escalation point for cases the tier 1 analyst couldn’t solve. L2 analysts perform deeper investigations, correlate events, and determine whether an incident is actually occurring.

L1: “Something looks weird”

L2 “Yep, this is definitely a problem.”

They are responsible for analyzing logs, verifying anomalies - if Bob was really in Japan five minutes ago, and confirming whether the pizza is actually under attack.

While responsibilities vary between organizations, Tier 2 analysts are typically more senior and often take ownership of the Incident Response activities, escalated alerts, identifying patterns and trends, and developing mitigation strategies.

Tier 3 - Analyst (L3)

At this level, the approach shifts from reactive to proactive. Tier 3 analyst are the threat hunters, responsible for handling complex security incidents, developing detection rules, and integrating threat intelligence to improve defenses.

Think of them as detectives who start asking questions before a compromise happens. They investigate behaviors, track patterns, and study attacker techniques - essentially watching the suspicious person outside the pizza room before they even try the door.

SPECIALIZED ROLES

Incident Responder

The specialist who knows the environment inside out - and the pizza… I mean, the systems and devices. They operate in the middle of chaos and are responsible for containing, eradicating, and recovering from incidents. They understand the tools, the processes, and how everything connects, helping improve defenses and response capabilities over time.

Malware Analyst

Responsible for analyzing malicious programs, files and the awkward looking olive on the pizza. He understands how the executables work in a lower level and reverse engineer malware to identify behavior, and help develop detection and protections.

They don’t just see the pizza stolen - they figure out how the thief picked the locked, what tools were used and how to stop it next time.

Threat Intel Analyst Focuses on studying the external threat landscape to track adversaries, campaigns, tools, and techniques, providing context that helps the SOC anticipate attacks.

They are the ones reading about types of pizza thefts across the campus and warn the security teams before it happens here.

Security Engineer

Bob the builder. Builds, configures, maintains security tools and infrastructure (SIEM, EDR, IDS, etc.). They ensure everything runs properly and that detections are effective.

“If the SOC is the kitchen, they are the ones installing and fixing the oven.”

Vulnerability Manager

Identifies, prioritizes, and tracks vulnerabilities across the environment. Works closely with teams to ensure remediation happens.

“They make sure the door to the pizza room isn’t left unlocked - or at least that someone fixes it quickly”

Forensic Analyst

Investigates incidents after they occur, collecting and analyzing evidence to understand what happened.

“They reconstruct the crime scene and explain exactly how the pizza disappeared.”

Compliance and Governance

Ensures the organization follows regulatory requirements, standards, and internal policies.

“They make sure there are rules about pizza - and that people actually follow them”

Security Awareness and Training

Educates users, creates training programs, and reinforces security policies across the organization.

“They teach people not to accept free pizza coupons in exchange for opening the door.”

MANAGEMENT

SOC Team Lead

Oversees SOC operations, manages analysts, and ensures processes are followed. Keeps the team aligned and operations running smoothly.

“Let’s all do their job to protect the pizza, and Steve, don’t eat it this time”

Director of Security

Responsible for broader security strategy, aligning SOC operations with business goals.

“They decide how important the pizza really is to the company”

CISO (Chief Information Security Officer)

The executive responsible for the overall security posture of the organization. Defines strategy, risk appetite, and long-term direction. And sometimes, provides the pizza.

“They decide if the company invests in protecting the pizza…or accepts the risk of losing it”

SOC Functions

SOC functions can be broadly divided into two groups: Reactive and Proactive.

Reactive functions focus on responding to threats that have already been detected, while proactive functions tries to anticipate, prevent, and improve defenses before incidents occur.

Acting when someone is already trying to get a slice of pizza is reactive. Verifying everyone’s background before they enter the pizza room is proactive.

REACTIVE FUNCTIONS

Day-to-day operations of most SOC teams. Responding to alerts, investigating incidents, and dealing with whatever is currently on fire.

Monitoring and Detection

Continuous monitoring of systems, networks, and logs to identify suspicious activity. Alerts are generated and the SOC becomes aware of potential threats.

Incident Response

A confirmed threat that may impact the company needs to be handled. The action to contain, eradicate, and recover from the incident fits here.

Forensic Analysis

Throughout investigation after an incident to understand what happened, how it happened, and what was affected.

Malware Analysis

Reversing a malicious binary, code or file to understand behavior, impact and collect IoCs for further investigation

PROACTIVE FUNCTIONS

Aim to improve the SOC’s ability to detect and prevent attacks before they happen. Nothing beats predicting the attackers before they act right?! If only we could apply the same logic to lottery numbers.

Threat Intelligence

The art of collecting and analyzing information from various sources to track threats, trends, attackers, and campaigns. It provides context and help improve detection capabilities.

“There have been multiple pizza thefts in other finance offices, where a blue-shirt individual was seen before the compromise. We might be next… maybe keep an eye on that guy watching birds”

Threat Hunting

The hunters of the blue team. They proactively search for threats that have not triggered alerts, using hypothesis and behavioral analysis, often supported by the threat intelligence.

Vulnerability Management

The process of identifying, prioritizing, and remediating weaknesses in systems before they can be exploited.

Security Awareness Training

Educate users to reduce human-related risks. Because sometimes the biggest vulnerability is not the system, but the users using it.

“Teach user well, and most threats won’t even get the chance to say ‘surprise, surprise’”

A mature SOC doesn’t just react to pizza theft, it learns from it, predicts it, and eventually stops it before it even starts.

SOC Cycle

Throughout the day, SOC analysts follow a set of activities that can described as a cycle - a repeatable process that turns raw data into decisions and actions.

This routine can be divided into four main stages:

Monitor

The first step is to monitor organization’s environment using tools such as EDRs, IPS/IDS, SIEM, and others.

This stage provides visibility into what is happening across systems, networks, and users.

This is where the analyst watches the pizza room - who’s coming in, who’s leaving, and who is acting a bit too suspicious.

Detect

Next comes detection, making sense of what monitoring provides.

This is where alerts, rules, and events highlight potential threats or anomalies that could indicate malicious activity.

This is not just someone near the pizza, this someone trying the handle or asking about the lock.

Analyze

Once something is detected, it moves into the analysis phase.

Here, the analyst investigates the alert, correlates data, and determines what is actually happening. The outcome of this step typically falls into one of the following categories: False Positive, True Positive, False Negative and True Negative.

Is Bob actually stealing the pizza… or just lost again.

Respond

Finally, the response phase determines what actions should be taken based on the analysis.

If it’s a confirmed incident, actions may include containment, eradication, recovery, or escalation. Topics we’ll explore further in the Incident Handling section of this blog. If not, the alert may be closed or tuned to improve future detections.

This is where the playbooks, SOPs, and runbooks guide the next steps, ensuring consistency and efficiency in handling incidents.

Pizza is gone. Time to act, lock the doors, check the logs, restart the AI Robot (which won’t help much, but it keeps the CEO happy), and maybe have a serious talk with Bob.

SOC Procedures

For SOC to be able to function effectively - and for analysts to avoid getting lost in the ocean of alerts, logs, and incidents - a structured set of procedures must be in place.

These documents act as guides, especially for new analysts, ensuring that actions are consistent, repeatable and aligned with organizational standards. And not just chaos and firehosing through the environment.

Security Operation Procedures (SOPs)

This is a high-level, structured procedures that define how the SOC operates.

They outline standard processes, responsibilities, and workflows for handling different types of activities and incidents.

In our pizza metaphor, think of SOPs as the official rules of the kitchen - how things should be done, no matter who is cooking.

Playbooks

Step-by-step guides for handling specific types of incidents or scenarios.

They provide structured responses for common threats, such as phishing, malware infections, or unauthorized access.

If someone tries to steal the pizza, the playbook tells you exactly what to do.

Runbooks

The most detailed of the three procedure documents, it is highly detailed, made of technical instructions for executing specific tasks, often automated or semi-automated.

These are more granular than playbooks and focus one execution rather than decision-making.

Press this button, run this command, isolate that system.

True / False Positives & Negatives

After analyzing alerts, the outcome usually falls into one of four categories. Understanding these are critical.

True Positive (TP)

A real threat that was correctly detected. Alert fired, and it was right.

Bob was stealing the pizza

False Positive (FP)

An alert was triggered, but no real threat exists.

Something looked suspicious, but it turned out to be harmless.

Bob opened the pizza room, but just to check if there was any left

True Negative

No alert was triggered, and there was indeed no threat.

Everything is working as expected

No one touched the pizza, and no alerts were raised.

False Negative

A real threat was not detected.

Worst scenario of them all

Pizza is gone… no one noticed.

SOC Metrics

For us to be able to understand how SOC is performing, we need data that measures efficiency, effectiveness, and areas for improvement. “We feel we are doing a good job” doesn’t usually work well when meetings with management or showcasing.

Mean Time to Detect (MTTD)

Average time it takes to identify a threat after it occurs.

Lower is better

How long did it take for someone to notice the pizza was being stolen?

Mean Time to Respond (MTTR)

The average time it takes to contain and remediate an incident after detection.

Lower is better

How long did it take to stop Bob once we realized he had the pizza?

Mean Time to Investigate & Acknowledge (MTTI&A)

Time it takes for an analyst to pick up an alert, acknowledge it, and complete the initial investigation

How long did it take for the analyst to say: “Yep, Bob again”

Incident Detection Rate (IDR)

The percentage of actual incidents that are successfully detected by SOC.

Higher is better.

How often do we actually catch the pizza theft when it happens?

False Positive Rate (FPR)

The percentage of alerts that turn out to be harmless.

Lower is better.

How many times did we accuse Bob…when he was actually just passing by?

False Negative Rate (FNR)

Percentage of real threats that were not detected.

Lower is critical

How many times was the pizza stolen and nobody notices?

Key Performance Indicators (KPIs)

High-level metrics used to evaluate SOC performance (MTTD, MTTR, alert volume, etc) and even personal projects

Numbers to show to management and prove the pizza is under control.

Key Risk Indicators (KRIs)

Metrics that indicate increasing risk exposure within the environment.

Sings that more people are getting interested in the pizza than we’re comfortable with.

Service Level Agreements (SLAs)

Defined timeframes for responding to and resolving incidents.

How fast are we expected to react when the pizza is under attack?

SOC Types

There are multiple ways to deploy a SOC within an organization. Let’s take a look at the most common approaches.

In-house SOC (Internal)

A SOC fully built and operated within the organization.

This gives the company full control over processes, tools, and data, allows for deep knowledge of the internal environment. On the other hand, requires more investment in people, technology, and continuous operations.

You own the pizza, the kitchen, security cameras, but you’re also staying up at 3 AM watching them.

MSSP - Managed Service Provider (External)

SOC function is outsourced to a third-party provider, which becomes responsible for monitoring and, in some cases, responding to security events.

This allows organization to leverage analysts who have exposure to multiple environments, attacks, and incident scenarios - without needing to build everything from scratch.

It also reduces the burden of maintaining a 24/7 operation internally.

The trade-off is reduced visibility and control, reliance on external partners, and less familiarity with the organization’s specific environment.

You hired someone else to watch the pizza room, and you just hope they care about it as much as you do.

Hybrid - Best of both Worlds

A combination of internal SOC capabilities and external support.

Typically, the organization keeps critical functions (incident response or threat hunting) in-house, while outsourcing monitoring or Tier 1 to an MSSP.

Balances control and scalability, but requires good coordination between teams, and a BIG budget.

You watch the pizza during the day, someone else watches it at night - and you both agree that BOB is still a problem.

SOC Maturity Level

Everything in life follows a maturity curve - from the early stages where you’re just figuring things out, through more structured phases, and eventually reaching a point of efficiency and control.

The same applies to a SOC. As organizations evolve, their security operations also mature, moving through different stages - each with its own characteristics, challenges, and level of effectiveness.

It’s important to note that this isn’t a model developed by any organization, but rather based on my my practical experience and how a SOC tends evolve in my experience of real-world environments. - I’d appreciate your feedback if you think differently.

Level 1 - Initial

This level is mostly reactive and perimeter focused. At this stage, security efforts are focused around basic controls such as network defenses and simple identity management. Visibility is limited, and threat intelligence integration is minimal or non-existent.

The SOC operates with very little context and is heavily dependent on alert.

We locked the pizza room door and hope for the best.

Level 2 - Developing

Visibility and correlation define this stage.

Here, things start to become more structured. Security telemetry is integrated, network flow data is used, and basic threat intelligence is introduced. Analysts begin correlating events instead of treating alerts in isolation

Threat hunting, while still informal and opportunistic, occasionally happens through searches of suspicious patterns based on recent alerts or news, but there is no structured process.

We don’t just see people near the pizza - we track patterns and behavior

Level 3 - Managed

Prepared and aware. At this stage, the SOC becomes more structured and begins shifting toward proactive behavior. There is strong situational awareness, vulnerability and configuration management, and pre-event preparedness becomes part of operations.

Threat hunting begins to take shape, with simple hypothesis-driven hunts, but they are still occasional and not fully integrated into workflows.

We check the locks, monitor who enters, and occasionally ask: “What if someone is already inside?”

SOC is no longer reacting, but also preparing.

Level 4 - Advanced

SOC starts learning from itself. Post-event analysis feeds improvement into detection and response. Lessons learned are fed back into detection and response. Processes are refined, and gap in both technology and operations are actively addressed.

Threat Hunting becomes a core function. Regular, hypothesis-driven hunts, usage of threat intelligence to guide hunts, identification of detection gaps and feedback loops into detection engineering.

At this stage, hunting is no longer optional, but expected.

We don’t jus deal with pizza theft, we study how it happened, anticipate new methods, and actively look for signs before it happens again.

Level 5 - NextGen

Finally, we have the most advanced stage of SOC maturity where adaptive and intelligence meet.

Automation, AI-assisted analysis, and deep integration across platforms enable faster and more efficient operations. SOC continuously adapts to new threats while aligning people, processes, and technology.

Highly advanced and augmented threat hunting take place, with AI-assisted hunting (pattern recognition and anomaly surfacing), continuous hunting models (not just scheduled), cross-domain correlation (identity, endpoint, network, cloud) and integration with automation and response.

Learning systems and automations play a major role at this stage, enhancing SOC metric and overall efficiency. AI-assisted analysis helps accelerate triage, while integration across multiple security platforms enables better correlation and visibility.

At the time of writing, the use of AI in security is still somewhat messy and, at times, clumsy. However, there are strong use cases - especially in parsing and triaging large volumes of data for a faster response.

While this is not yet a fully mature or standardized approach across the market, I strongly believe that AI agents, if deployed securely, can enrich alerts automatically, correlate simple data across sources, assist with investigation and trigger response actions when appropriate. (I’ll be covering my own agent architecture in a future post - stay tuned).

This enhancement allows analysts to move one step higher, focusing on decision-making, threat hunting, and improving processes, rather than repetitive tasks.

We don’t just protect the pizza - we have systems watching it, learning patterns, predicting threats and locking the door before someone even get close… while we supervise to make sure it doesn’t lock out the delivery guy and the robot mostly works - well for keeping things clean at least.

Closing

Thanks for putting the time into reading this. Hope this added some knowledge to your studies and hopping to see you on the next blog post about event management and incident handling.

Thanks for taking the time to read this. I hope this added some value to your studies and helped clarify how a SOC operates.

From roles and functions to metrics and maturity, the goal was to connect the pieces into something practical - not just theory, but something you can actually visualize and apply.

This is the first post of many in a small journey from beginner to advance blue team topics.

I’ll be diving deeper into event management and incident handling in the next post, so hopefully I’ll see you there.

Until then, protect the pizza.

References

TCM SOC101 - https://tcm-sec.com/academy/security-operations-soc-101

HTB - SOC PATH - https://academy.hackthebox.com/app/paths/390/details

LetsDefend - SOC rooms - https://app.letsdefend.io/path/soc-analyst-learning-path

Blue Team Handbook - https://www.amazon.com.br/Blue-Team-Handbook-Condensed-Operations

Some personal experience