The Blue Team and the SOC

While red teams get the glamour, blue teams do the work that keeps organizations running every single day. Their home is often the Security Operations Center, or SOC: a team that watches, investigates and responds around the clock. Understanding it is essential, whether you will attack, defend or write reports for both.

What is the blue team?

The blue team is everyone who defends the organization: security analysts, engineers, system administrators, incident responders. They design protections, watch for suspicious activity and respond when something goes wrong. If the red team is the burglar crew simulating an attack, the blue team is the security staff and the alarm system of the building.

The SOC is the operational part of the blue team: people, processes and tools that monitor security events continuously. Some organizations build their own SOC; others buy the service from a provider; others do a mix.

What a SOC actually does

• Monitor: collect logs and alerts from networks, servers, workstations, cloud services and security products.
• Triage: decide quickly whether an alert is a real problem, a false alarm or something that needs more time.
• Investigate: gather context, check what else happened on a machine or an account, and build a timeline.
• Respond: contain a threat, for instance by isolating a machine, and coordinate with IT and management.
• Improve: tune rules, write new detections, document lessons learned.
• Hunt: search proactively for threats that automated alerts missed.

The people: roles and levels

Many SOCs organize their analysts in levels, although names vary:

• Level 1, triage analyst: first look at alerts. Applies playbooks, closes false positives, escalates real concerns. This is a common entry-level job.
• Level 2, investigation analyst: deeper analysis of escalated incidents, correlation across sources, first containment actions.
• Level 3, senior analyst or responder: complex incidents, forensics, threat hunting, writing detection content.
• Detection engineer: designs and maintains the rules and use cases.
• Threat intelligence analyst: studies adversaries and produces information that guides defenses.
• SOC manager: organizes the team, reports to leadership, handles the relationships with the rest of the company.

A CSIRT or CERT (computer security incident response team) is a related structure, focused on handling incidents and often serving a broader community. In France, the national center is run by ANSSI (cyber.gouv.fr).

The toolbox, described generically

• SIEM: a platform that gathers logs from everywhere, normalizes them and runs correlation rules. You will study it in the next chapter.
• Endpoint detection and response (EDR): agents on computers that observe behavior and can isolate a machine.
• Network monitoring: sensors that observe traffic for unusual patterns.
• Case management and ticketing: where incidents are tracked, assigned and documented.
• Automation platforms: tools that run repetitive response steps, such as enriching an alert with context.
• Threat intelligence sources: feeds of indicators and reports on adversaries.

No tool makes a SOC. Poorly tuned tools produce thousands of alerts that nobody can read. A modest set of well-understood tools used by trained people beats an expensive set that nobody has configured properly.

The big enemy: alert fatigue

Imagine a smoke detector that beeps every time you make toast. You would soon ignore it, including on the day a real fire starts. In a SOC, too many false alerts lead to alert fatigue: tired analysts skim, and a real incident drowns in noise. Good SOCs fight it by tuning rules, adding context, removing useless alerts and prioritizing by business impact. A reduction of false positives is a real achievement, even if it looks invisible from the outside.

Playbooks and runbooks

A playbook is a step-by-step guide for a type of alert: "Suspicious sign-in alert. Step 1: check the user's location and device. Step 2: check whether multi-factor authentication was used. Step 3: contact the user. Step 4: if not confirmed, reset the session and escalate." Playbooks make responses consistent, speed up new analysts and allow automation. They must be updated after each incident, otherwise they become fiction.

Measuring a SOC without fooling yourself

Common indicators are the time to detect (from the start of the incident to the first alert), the time to respond, the share of false positives and the coverage of the techniques the organization worries about. Be careful: a number is a conversation starter, not a verdict. A SOC with a low number of incidents may be excellent or may be blind. Always ask what the number really measures.

Blue team life: skills that matter

• Curiosity and method: asking "what else could explain this?" before concluding.
• Systems and network knowledge: you cannot recognize abnormal if you do not know normal. Chapters 1 and 2 of this course, and the earlier courses, are the foundation.
• Clear writing: tickets and reports that another analyst can read at 3 a.m.
• Calm under pressure: incidents are stressful. Procedures and teamwork help.
• Scripting: automating collection and analysis, as you practiced in chapter 2.

Shift work and on-call duty are common, and they have an effect on health and life. A good employer rotates fairly and gives rest. Keep that in mind when you consider the career.

Why attackers should care about the SOC

A tester who understands how a SOC works writes better reports and designs better exercises. When you know that an analyst sees a sign-in alert with certain fields, you realize why timestamps, source addresses and user names in your own notes are so valuable to the defender who has to reconstruct what happened. Many strong security professionals have worked on both sides.

Your turn: triage three alerts

You are a Level 1 analyst. Decide for each alert whether to close, investigate or escalate immediately, and justify in one line.

1. A user signed in from a new city, once, with multi-factor authentication, on their usual laptop; the user is on a business trip according to the calendar.
2. A server in the finance segment made a large outbound transfer at 3 a.m. to an address never seen before.
3. Fifty failed sign-ins on one account in two minutes, followed by a success from the same source.

See a solution

1. Close (with a note): the context explains it, multi-factor authentication was used and the device is known. Document the reason so the next analyst can see it.
2. Escalate immediately: unusual volume, hour, destination and a sensitive segment. Possible data theft; response should begin quickly, for instance by preserving evidence and preparing containment.
3. Escalate after a quick check of the account: a burst of failures then a success is a classic pattern that suggests the password may have been found. At least investigate urgently and consider forcing a session reset.

Notice that all three rely on context, not on the alert alone.

Portfolio step

In 03-red-blue, add soc-triage-playbook.md: a one-page playbook for the third alert ("burst of failed sign-ins followed by success") with numbered steps, the questions to ask and the escalation criteria. A neat playbook is a very credible entry-level sample for a SOC application.

In the next lesson, the red and blue teams finally work together.