14.1 Blue/Red Teams, Hierarchy, and SOC Roles
Key Takeaways
- Blue defends, red tests with authorization, and purple is a joint way of working—not a third army and not a rank above Level 2.
- A common hierarchy runs Board → CISO → security operations director / SOC manager → shift lead → L2 → L1, with IR, detection engineering, and threat intelligence as specialist neighbors.
- Follow-the-sun hands the queue across time zones; in-house single-site coverage uses local staff plus on-call; MSSP hybrids outsource some of the queue—handoff writing still belongs to L1.
- L1 owns first-touch triage, workbook steps, tickets, verdicts, and matrix-based escalation; L1 does not freelance full DFIR, rewrite production detections, or speak for the CISO.
Who sits in a SOC, and who sits next to it
A Security Operations Center (SOC) is the function that watches telemetry, triages alerts, and starts response when something looks wrong. TryHackMe's SAL1 training content (24 March 2025) places SOC Team and Responsibilities under SOC workflows: blue and red teams, types of security teams, a common security hierarchy, and SOC roles with emphasis on what people actually do in a SOC environment. This independent OpenExamPrep section covers those topics so you can place a Level 1 (L1) analyst among neighboring teams. It is not a claim that every employer uses the same boxes on a chart.
You will spend most of a junior shift inside blue operations. You will still read red-team findings, consume threat intelligence (TI), and file work for detection engineering. If you cannot name those neighbors, you will either escalate everything to the Chief Information Security Officer (CISO) or sit on a confirmed intrusion because "forensics is not my ticket."
Blue, red, and purple at a basic level
Blue team is defensive work. Blue operators keep controls running, watch logs, hunt, contain, and recover. The SOC is the most visible blue desk, but vulnerability management, identity engineering, and security architecture are also blue work. When SAL1 says blue, think defend and detect, not a sports jersey.
Red team is offensive testing authorized by the organization (or a hired firm). Red operators emulate adversaries: phishing, initial access, lateral movement, and command and control (C2), then report how far they got and which controls failed. Red is a scheduled, scoped test. An uninvited attacker is not "the red team," and a SOC analyst must not launch exploits "to confirm" without an approved test window. That is how you become the incident.
Purple team is not a third standing army that fights both colors, and it is not a promotion past L2. At the SAL1 level, purple means blue and red working the same scenario on purpose: red executes a technique, blue checks whether detections and workbooks caught it, and both sides write gaps. A debrief where detection engineers sit with the red operators is purple in spirit even if nobody's badge says Purple.
| Color | Primary question | Typical output | How L1 meets it |
|---|---|---|---|
| Blue | Did we notice and stop this? | Alerts, tickets, containment, tuned detections | Daily home: the queue |
| Red | Could an adversary do this here? | Attack path, missed controls, scoped findings | Readouts and announced test windows |
| Purple | Did the test make detection better? | New workbook steps, rule coverage notes | Exercises and after-action reviews |
Trap: treating purple as a rank, or treating red as the enemy of the SOC. Red's job is to find holes before a real adversary does. Blue's job includes using those findings. Rivalry that hides missed detections is a process failure, not a personality quirk.
Types of security teams around the SOC
Color labels are coarse. Organizations also split functions. L1 does not staff all of them. L1 must know who owns the next step when a ticket leaves the queue.
- SOC / detection operations — live queue, triage, first response, shift handoff.
- Incident response (IR) — deeper investigation and containment once an incident is declared (or when a workbook demands forensics-level work).
- Detection engineering — write and tune detection rules so the queue is about real problems instead of junk.
- Threat intelligence — actor, malware, and indicator context so analysts are not guessing in a vacuum.
- Vulnerability management — scan, prioritize, drive patching (chapter 13). The SOC often sees scanner traffic as alerts; vuln management owns the finding lifecycle.
- Governance, risk, and compliance (GRC) — policy, audits, risk register, evidence for regulators.
- Identity and access management (IAM) — accounts, multifactor authentication, privileged access.
- Application security (AppSec) — review and testing of software before and after release.
- Security architecture / engineering — design of networks, logging pipelines, and controls.
- Managed security service provider (MSSP) — an outside company that may own some or all of the 24/7 queue.
A small company may combine three of these into two people. A bank may have each as a named team. The SAL1 skill is functional literacy: when the alert is "service account used from a new country," IAM and the SOC both have a stake; when the alert is "SQL injection blocked on the public site," AppSec and the web application firewall owners belong in the ticket, not only the L1 who saw the block.
Common hierarchy (who reports to whom)
A frequent pattern, from the top down:
- Board / executive leadership — risk appetite and budget. They do not triage SIEM alerts.
- CISO — owner of the security program. Page the CISO through the incident process, not because an informational alert is red in the UI.
- Directors — often split among security operations, security engineering, and GRC.
- SOC manager — staffing, shift model, tool budget, and service-level agreement (SLA) conversations (chapter 15).
- Shift lead / senior analyst — live supervision of the queue; usually L1's first human escalation.
- Level 2 (L2) analysts — deeper investigation, multi-tool correlation, mentoring L1 during the shift.
- L1 analysts — first touch on alerts and tickets.
IR, detection engineering, and TI may sit inside the SOC as specialist desks or beside it under the same director. Either way, during a shift your operational boss is the shift lead, not the CISO. Skipping the chain ("I Slack'd the CISO because High looked scary") creates noise at the top and a hole in the queue.
Follow-the-sun versus in-house (and hybrids)
In-house, single site. Analysts live in one country or campus. Nights are on-call or a skeleton crew. Strength: shared context and fast hallway escalation. Weakness: 03:00 coverage is thin unless the company pays for nights.
Follow-the-sun. Two or three SOC sites hand the queue across time zones so someone is always on a local day shift. Strength: 24/7 without forcing one team onto permanent nights. Weakness: a ticket that says "looks bad, will check later" is unusable in another city. Handoff quality is the coverage model.
MSSP / hybrid. An external 24/7 desk handles L1, and the customer keeps L2/IR—or the reverse. Strength: staffing. Weakness: the MSSP cannot know that SCAN-VULN-01 is the approved scanner unless the customer maintains documentation, asset lists, and allow lists. L1 on either side still writes those facts into the ticket.
SAL1 does not grade you on picking a "best" model. It grades whether you understand that who is awake changes how strictly you must write, and that L1 still owns first-touch quality in every model.
SOC roles: L1 versus L2, IR, detection engineering, and TI
L1 analyst (SOC analyst I / triage analyst) owns the alert queue for the shift: take the next item, follow the workbook, enrich, assign a verdict, update status, open or update a ticket, and escalate when the matrix says so. L1 is not "only password resets." L1 is the control that stops a real intrusion from sitting in New for six hours. L1 is also not a silent detection engineer: if a rule is noisy, L1 files a quality ticket with evidence; L1 does not disable production detections without authorization.
L2 analyst takes work that needs more time or more tools: reconstructing a process tree, pivoting across SIEM indexes, deciding whether five tickets are one incident. L2 often approves containment that L1 proposed from a workbook.
Incident responder enters when an incident is declared or when playbooks demand forensics, legal hold, or wide containment. IR may image disks, run the incident bridge, and coordinate with legal and communications. L1's job is to feed IR a clean package (times, hosts, users, indicators), not to freelance a full digital forensics and incident response (DFIR) exam on every medium alert.
Detection engineer owns rule logic, thresholds, telemetry gaps, and the backlog of false-positive reports. They convert queue pain into better detections. They are a proactive function that still depends on reactive evidence from L1.
Threat intelligence analyst curates indicators, actor reports, and internal sightings. L1 consumes TI (look up this IP, this hash) far more often than L1 authors a finished intelligence product.
SOC manager / shift lead owns staffing, exceptions, and "page IR now" when the matrix is ambiguous.
What L1 owns—and what L1 must not freelance
L1 owns: watching the queue; first-pass investigation in SIEM, endpoint detection and response (EDR), email, and documented lookups; classification using the verdict set in section 14.4; ticket hygiene; escalation according to the matrix (high level here, detail in chapter 15); and shift handoff notes.
L1 does not own unless a workbook explicitly grants it: unilateral production firewall changes that were never in a playbook; rewriting correlation searches; telling the CEO the bank was breached; running red-team exploits "to confirm"; or closing a likely true positive (TP) as noise so the queue looks empty.
Worked example: 03:12 UTC at Cedar Bank, follow-the-sun
Cedar Bank runs a follow-the-sun SOC (Dublin, then Singapore). Dublin L1 Priya pulls a High alert: powershell.exe spawned from winword.exe on BR-WKS-22 in a branch VLAN. Store documentation says tellers do not run macros from email. Enrichment: unknown hash, parent Word, outbound HTTPS to a domain registered 48 hours ago. Priya classifies TP, writes times and indicators on ticket INC-22019, and escalates to on-shift L2 plus IR because point-of-sale-adjacent host plus C2-like traffic meets the urgent path. She does not page the CISO herself, does not ask red team to replay the payload, and does not wait for detection engineering to rewrite the rule before containment starts.
At 07:00 UTC Singapore takes the queue. The ticket already lists host, user a.nguyen, hash, domain, verdict, and that IR is on the bridge. That is L1 ownership: a complete first hour, not a hero investigation that never gets written down.
Independent study of these SAL1 SOC-team topics is about knowing your lane and your neighbors. Later simulator scoring cares whether you classified and escalated like an L1. This section is who that L1 is.
A company schedules an internal exercise where red operators run a known phishing-then-beacon technique while SOC analysts and detection engineers watch whether existing rules and workbooks catch it, then both sides write coverage gaps. What is this collaboration called at a basic SAL1 level?
During a live shift, which statement best describes what an L1 SOC analyst owns versus neighboring roles?
Cedar Bank uses follow-the-sun (Dublin hands to Singapore at 07:00 UTC). What does that model require of Dublin L1's tickets that a same-room in-house night shift might get away with verbally?
In a common security hierarchy, who is usually the L1 analyst's first human escalation on a confusing High alert during the shift?