Study guide

14.1 Blue/Red Teams, Hierarchy, and SOC Roles

TryHackMe Security Analyst Level 1 SAL1

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current SAL1 Exam Facts 1.2 24-Hour Window, Check-In, and Delivery 1.3 Scoring, Retakes, Validity, and Access 1.4 MCQ Section Strategy

2 SOC Simulator Exam Skills

2.1 Analyst VM, Splunk, and Dynamic Alerts 2.2 Classification and Escalation Scoring 2.3 Case Reports and Investigation Notes

3 Network Essentials

3.1 OSI, TCP/IP, Devices, and the Three-Way Handshake 3.2 HTTP, TLS, VPN, Web Browsing, and Email Transmission

4 Operating System Basics

4.1 Windows and Linux Architecture, Auth, Filesystems, Processes 4.2 Active Directory and Event Logs for Tracing Activity

5 Cryptography, Cloud, Web and Scripting Basics

5.1 Encoding, Encryption, Hashing, and Decoding Tools 5.2 VMs vs Hosts, Cloud vs Virtual Hosting, SaaS and IaaS 5.3 Web Apps, APIs, JSON/XML, Scripts vs Compiled Programs

6 Cybersecurity Fundamentals and MITRE ATT&CK

6.1 CIA, Least Privilege, Human Factors, Log4Shell, EternalBlue 6.2 Navigating MITRE ATT&CK: Tactics, Techniques, Sub-techniques 6.3 Mapping Real Attacks onto ATT&CK Techniques

7 Kill Chain, NIST CSF, and Attack Indicators

7.1 Cyber Kill Chain Stages vs MITRE ATT&CK 7.2 NIST CSF: Identify, Protect, Detect, Respond, Recover 7.3 IoC vs IoA and the Pyramid of Pain

8 Social Engineering and Network Attacks

8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis 8.2 SPF, DKIM, DMARC, and Email Authentication Results 8.3 Port Scanning, DDoS, and Man-in-the-Middle 8.4 DNS Poisoning, ARP Spoofing, Exfiltration, and C2 Traffic Patterns

9 Web Exploitation and Endpoint Attacks

9.1 Client vs Server Vulnerabilities, XSS, and SQL Injection 9.2 Code Injection, Path Traversal, Input Validation, Patching, WAF 9.3 Initial Access (RDP/SSH), Persistence, Privilege Escalation 9.4 Credential Theft, Mimikatz, Sysmon, and Auditd

10 Command and Control, Malware, and LOLBAS

10.1 Forward vs Reverse Shells, Beaconing, Metasploit, Cobalt Strike 10.2 Malware Types, Static vs Dynamic Analysis, LOLBAS

11 EDR, Firewalls, and WAF

11.1 EDR vs AV, Telemetry, Containment, Remote Shell 11.2 Firewall Deployments, Limits, and Log Analysis 11.3 WAF Capabilities, Limits, and Rule Creation

12 SIEM and SOAR

12.1 SIEM Deployments, Parsing, and Raw Logs to Alerts 12.2 Alert Management, Threat Hunting, Triage, Reporting 12.3 SOAR Playbooks, Enrichment, and TI Integration

13 Threat Intelligence and Vulnerability Scanning

13.1 Feeds, Indicators, Classifying IPs, Domains, and Hashes 13.2 YARA and TI Integration with SIEM/SOAR 13.3 External vs Internal, Web vs Network Scanning

14 SOC Team, Activities, and Alert Triage

14.1 Blue/Red Teams, Hierarchy, and SOC Roles 14.2 Proactive vs Reactive: FP Remediation, Detection Engineering, Tabletop, DFIR, Threat Hunting 14.3 Workbooks; Ticket vs Alert vs Detection Rule 14.4 Triage Workflow, Severity, Status, and Verdicts

15 SOC Metrics, Escalation, and Communication

15.1 MTTA, MTTD, MTTR, SLA, and Lookups 15.2 Escalation Matrix, Urgent Remediation, and Cross-Team Communication

14.1 Blue/Red Teams, Hierarchy, and SOC Roles

Key Takeaways Explain This Topic AI

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.

Last updated: September 2026

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 ExamFinch 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.

Loading diagram... Example security operations hierarchy around the SOC