Day 25 of SOC Training

Introduction

Imagine a hospital emergency room. Doctors don't just react randomly to every patient who walks in — they follow triage protocols, pull up patient history, check vital signs, and use standardized checklists to make fast, accurate decisions.

A Security Operations Center (SOC) works the same way. When an alert fires (like an alarm going off), a SOC L1 Analyst can't just guess whether it's dangerous. They need a structured process, the right context, and the ability to measure how well they're doing.

1. SOC Workbooks : The Analyst's Roadmap

The Simple Explanation:

A Workbook is like a recipe card for investigating an alert. Instead of every analyst investigating an alert in their own random way, a Workbook gives everyone the same step-by-step recipe to follow. This means two different analysts, on two different days, will investigate the same type of alert the same way — and reach a fair, consistent conclusion.

Why This Matters:

Without a Workbook, imagine ten different analysts getting the same phishing email alert. One might check the sender's email. Another might jump straight to the attachment. A third might ignore it entirely because they're busy. This inconsistency leads to missed threats and wasted time. A Workbook solves this by acting as a visualization engine — it visually organizes what needs to be checked, in what order, and where to record findings.

What Does a Workbook Actually Look Like?

Think of it as a digital form with sections that the analyst fills in as they investigate. Here are the typical sections, explained:

Why Workbooks Reduce Alert Fatigue

Alert fatigue happens when analysts are bombarded with so many alerts that they start missing real threats because they're overwhelmed or bored.

A good Workbook speeds up investigation of routine, repetitive alerts (like login failures) so analysts spend their mental energy on genuinely suspicious activity instead of re-inventing the investigation process every single time.

Benefits at a Glance:

• Consistency: Every analyst follows the same process

• Speed: Less time spent figuring out 'what do I check first?'

• Quality: Nothing important gets skipped

• Institutional Memory: Findings are documented for future reference

• Clear Escalation: Everyone knows exactly when to hand off to L2/L3

2. Lookups: Adding Context to Confusing Alerts

The Simple Explanation: Imagine a security guard sees a stranger walk into an office building. Is this dangerous? It depends entirely on context. If the stranger is a scheduled delivery driver, it's fine. If the stranger has no ID and the office is empty at 2 AM, that's alarming. A Lookup is how a SOC analyst gets that same kind of context — it's a quick way to ask a trusted source of information, 'is this normal, or not?'

In technical terms, a Lookup is a query to an external or internal data source that returns extra information about something mentioned in the alert — a username, an IP address, a device, or a file.

3. Assets & Identities: Knowing Your Environment

The Simple Explanation: You cannot protect what you don't know exists. Imagine trying to guard a house without knowing how many doors and windows it has. A SOC needs an accurate, up-to-date inventory of every user, every device, and every application in the organization. This inventory is what analysts check against during Lookups.

Why This Matters for Investigations

• Spotting Rogue Devices: If a device connects to the network that isn't in the inventory, that's immediately suspicious

• Catching Ghost Accounts: Comparing HR records against Active Directory reveals accounts that should have been disabled

• Scoping a Breach: If a server is compromised, the inventory tells you exactly what sensitive data that server holds

• Prioritizing Response: A compromised finance server matters more urgently than a compromised test machine

4. Network Diagrams: The Map of the Battlefield

The Simple Explanation: If assets and identities tell you who and what exists, a network diagram tells you how everything connects. Think of it like a subway map for your company's computer network — it shows which systems can 'travel' to which other systems, and where the checkpoints (firewalls) are.

What's on a Network Diagram

• Internet Boundary: Where the company network meets the public internet, usually protected by a firewall or DMZ

• Internal Networks: The internal departments and their network segments (VLANs)

• Critical Systems: The location of important servers like domain controllers and databases

• Access Points: Ways in, such as WiFi, VPN, and remote access gateways

• Security Devices: Firewalls, intrusion detection/prevention systems (IDS/IPS)

Why This Matters for Investigations

When an attacker breaks into one machine, they rarely stop there — they try to move to more valuable targets, a process called lateral movement. A network diagram lets an analyst answer questions like: 'This compromised laptop is on the Guest WiFi segment — could it even reach the Finance database, or is that segment isolated?' Without the diagram, you're investigating blind. With it, you can accurately reconstruct the attacker's path and understand exactly how much damage was possible.

5. Real-World Investigation Scenarios, Explained Step by Step

Now let's bring Workbooks, Lookups, Assets, and Network Diagrams together into three real scenarios a SOC L1 analyst commonly faces.

Scenario 1: Suspicious Email with an Attachment

The Alert:

'A potential phishing email with a malicious attachment was detected.'

Why This Happens:

Attackers frequently email employees a document or file that, once opened, silently installs malware. The security system flags this before or after delivery based on suspicious characteristics of the email or file.

Step-by-Step Investigation:

Red Flags to Watch For:

• The sender's email address pretends to be from inside the company (spoofing)

• A file named something like 'invoice.pdf.exe' — a fake double extension to trick people

• The file's hash matches a known piece of malware

• The email uses urgent, pressuring language ('Your account will be closed today!')

Scenario 2: Suspicious PowerShell Execution

The Alert:

'A PowerShell process ran with an encoded (Base64) command.'

Why This Happens:

PowerShell is a legitimate and powerful administrative tool built into Windows, but attackers love abusing it because it can download and run malicious code without ever saving a file to disk (making it harder for antivirus to catch). Attackers often 'encode' their commands in Base64 to disguise what the command actually does from a casual glance.

Step-by-Step Investigation:

Red Flags to Watch For:

• Base64-encoded commands (used to hide the real intent)

• Commands that download something from the internet and immediately run it

• Attempts to extract saved passwords from system memory

• The command window is set to run hidden, so the user never sees it

Scenario 3: Network Port Scanning

The Alert:

'A source IP address is performing port scans against multiple internal servers.'

Why This Happens:

Before attacking a system, an attacker (or a legitimate security tool doing a vulnerability scan) will usually 'knock on every door' first — testing many network ports on many machines to see which services are running and might be vulnerable. This is called port scanning, and it's often one of the earliest warning signs of a planned attack.

Step-by-Step Investigation:

Red Flags to Watch For:

• An unrecognized IP address scanning from outside the network

• A very high volume of ports scanned across many different hosts quickly

• Scanning is focused on high-value ports (like Remote Desktop 3389 or File Sharing 445)

• A successful connection occurs shortly after the scan finishes

6. SOC Metrics: How Do You Know You're Doing a Good Job?

The Simple Explanation: Just like a hospital tracks how quickly patients are seen in the emergency room, a SOC tracks how quickly it detects and responds to threats. These measurements are called metrics, and they turn 'we think we're doing okay' into hard, provable numbers. The three most important metrics are informally called 'The Big Three.'

The Big Three Metrics

1. MTTD — Mean Time to Detect

This measures the average time between when a threat actually begins and when the SOC first notices it. Imagine a burglar breaking into a house — MTTD is how long it takes before the alarm goes off (or someone notices). A lower MTTD is always better; it means threats are caught quickly, before they can do serious damage. It's improved through better detection tools, well-tuned alerts, and proactive threat hunting.

2. MTTA — Mean Time to Acknowledge

This measures the average time between an alert being generated and an analyst actually picking it up to start working on it. This is often the very first bottleneck in a SOC — if alerts sit in a queue for hours before anyone looks at them, everything downstream is delayed too. It's improved by reducing overall alert noise and cutting down alert fatigue so analysts aren't overwhelmed.

3. MTTR — Mean Time to Respond

This measures the average time between when a threat is detected and when it is actually contained or fixed. Going back to the burglar analogy — MTTR is how long it takes police to arrive and stop the burglar once the alarm has gone off. It's improved with clear runbooks (step-by-step response guides), automation, and well-trained L1 analysts who can act quickly and confidently.

Other Important Metrics

Alert Fatigue (False Positive Rate)

This tracks how many alerts turn out to be nothing. If 95% of alerts are false alarms, analysts become numb to them and may miss the 5% that are real — exactly like how a car alarm going off constantly in a parking lot gets ignored by everyone nearby.

Escalation Rate

This tracks what percentage of alerts L1 analysts hand off to more senior L2/L3 analysts. If this number is very high, it may mean L1 analysts need more training or better tools to handle more cases themselves.

True Positive Rate

This tracks what percentage of alerts turn out to be genuine security incidents. It's a good indicator of how well-tuned the detection systems are overall.

7. The Management Perspective: Using Metrics to Improve the Team

Metrics aren't just numbers on a dashboard — a good SOC Manager uses them to diagnose exactly where the team is struggling and fix it. Here's how that works in practice, explained through common problems and their solutions.

Problem: MTTA is High (Alerts Sit Too Long Before Anyone Looks)

• Solution: Tune detection rules to reduce unnecessary noise

• Solution: Improve the Workbook so routine alerts are triaged faster

• Solution: Automatically auto-resolve alerts that are obviously false positives

Problem: MTTR is High (Response Takes Too Long)

• Solution: Write clearer, more detailed runbooks (step-by-step response guides)

• Solution: Automate repetitive containment actions (like auto-isolating an infected computer)

• Solution: Train L1 analysts so they're empowered to act without waiting for approval on routine cases

Problem: Escalation Rate is Too High

• Solution: Provide targeted training on the specific incident types being escalated most

• Solution: Assign the right analyst to the right alert based on their strengths

• Solution: Improve Lookups so L1 analysts have better context and can decide with confidence

This is exactly the mindset a SOC Manager brings: look at the metric that is failing, ask why it's failing, and assign the right fix — whether that's better tools, better training, or better process — to the right person on the team.

8. Putting It All Together: Best Practices

For Every Investigation:

• Always use the Workbook — don't skip steps, even for alerts that seem routine

• Always enrich with Lookups before making a judgment call

• Always check the asset/identity inventory to confirm what you're looking at is legitimate

• Always document your findings clearly, so the next analyst (or your future self) understands what happened

The Investigative Mindset:

Don't just ask 'did a login happen?' Ask deeper questions: Who logged in? From where? What did they do immediately after logging in? Does this match their normal behavior? This curious, thorough mindset is what separates a good analyst from one who just clicks 'close alert' without really understanding what occurred.

Conclusion

Being a successful SOC L1 Analyst is not only about knowing how attacks work technically — it's about combining that technical knowledge with structured processes and good habits. Workbooks keep investigations consistent and thorough. Lookups turn vague alerts into clear, actionable ones by adding real-world context. Knowing your Assets and Identities means you always know what 'normal' looks like, so abnormal activity stands out immediately. Network Diagrams let you trace exactly how an attacker could move through the environment. And Metrics like MTTD, MTTR, and MTTA give the whole team, and its manager, an honest picture of how well they're really doing — and a clear path to getting better.

Key Takeaways:

• Workbooks = the standardized recipe for investigating any alert • Lookups = the tool that adds real-world context to raw data • Assets & Identities = knowing exactly who and what belongs in your environment • Network Diagrams = the map used to trace how an attacker could move • MTTD, MTTR, MTTA = the three core numbers that measure SOC performance • A good SOC Manager uses these metrics to diagnose and fix team weaknesses • The best analysts stay curious — always asking who, what, where, when, and how

LEARNING SOURCE :

Defronix Academy — SOC Analyst Training (YouTube) SOC Training — Class 25

#CyberSecurity #SOCAnalyst #InfoSec #BlueTeam #LearningJourney #ContinuousLearning