Module 8: Defensive operations & the SOC

Estimated time: 4-5 hours (including the lab) · Prerequisites: M0-M7 (especially M2 networking and M6 identity)

This is the module that maps directly to the #1 entry job: SOC Analyst Level 1. Everything here is the day-to-day reality of that role: the alert queue, the triage decisions, the tools named in Australian job ads, and the documentation habits that make hiring managers say yes.

Security+ SY0-701 mapping: Domain 4: Security Operations (the biggest domain in the exam), plus parts of Domain 2 (Threats & Mitigations).

What you'll get from this module

Describe what a SOC is and what each tier (L1/L2/L3) does.
Explain an L1 analyst's hour-by-hour work: queue, triage, enrich, escalate or close, document.
Distinguish an event, an alert, and an incident.
Explain what a SIEM and an EDR do, and name the products Australian employers use.
Triage an alert using the true positive / false positive / benign true positive model.
Walk through the incident response lifecycle (NIST SP 800-61).
Use MITRE ATT&CK and the IOC-vs-TTP distinction to talk about threats like a professional.
Write an incident note good enough to put in a portfolio.

1. What a SOC is, and who does what

A Security Operations Centre (SOC) is the team (in-house or outsourced to an MSSP) that watches an organisation's systems for signs of attack and responds when something happens. Think of it as a combination of air-traffic control and an emergency department: constant monitoring, rapid triage, and escalation of the serious cases.

SOCs are usually tiered:

Tier	Role	What they do
L1: Triage analyst	Your first job	Watch the alert queue, triage each alert, enrich it with context, then escalate real threats or close false alarms, documenting everything.
L2: Investigator	1-3 years in	Take escalations from L1, dig deeper across systems, lead incident response, tune noisy detections.
L3: Hunter / engineer	Senior	Proactively hunt threats nobody alerted on, build new detections, engineer the SOC's tooling.

An L1 analyst's shift, hour by hour

Handover: read the notes from the previous shift: open incidents, ongoing issues, anything to watch.
Work the queue: alerts arrive continuously, each with a severity. You take the next one, investigate it (typically 10-30 minutes), and disposition it.
For each alert: read what fired and why → pull the surrounding logs → enrich (who is this user? what is this IP?) → decide: real, false alarm, or expected behaviour → escalate or close → write it up.
Handover out: leave notes clean enough that the next shift can pick up instantly.

Shift work reality: attacks don't keep business hours, so many SOCs run 24/7 rosters: nights, weekends and public holidays included, usually on a rotating pattern. Some Australian SOCs run "follow-the-sun" with overseas teams instead, and MSSP contracts vary. Ask about the roster in every interview; night shifts often carry loading (extra pay), which is genuinely useful early in your career.

2. Telemetry: the raw material

A SOC can only see what gets logged. The main telemetry sources:

Source	Examples of what it records
Endpoints (laptops, servers)	Processes started, files written, registry changes, logons
Network	Connections in/out, DNS queries, firewall allows/denies, proxy traffic
Identity (M6)	Sign-ins, MFA prompts, password changes, privilege grants
Cloud (M11)	Console logins, resource changes, storage access, API calls

Three words you must keep straight:

Event: any recorded occurrence. A user logging in is an event. Millions per day; almost all harmless.
Alert: a rule has decided some event(s) might be malicious and flagged them for a human. Hundreds per day.
Incident: a confirmed (or strongly suspected) actual compromise or harm. Rare, and formally managed.

The SOC's core job is turning a firehose of events into a manageable stream of alerts, and separating the handful of real incidents from the noise.

3. The tools: SIEM and EDR

SIEM (Security Information and Event Management) is the SOC's central nervous system. It does three things: aggregate logs from everywhere into one place, correlate them (join a sign-in log to a network log to a file log), and alert when detection rules match. As an L1 analyst, the SIEM is where you'll spend most of your day.

The two SIEMs you'll see constantly in Australian job ads are Microsoft Sentinel (cloud-native, queried with a language called KQL) and Splunk (queried with SPL). Learn the concepts on one and the other is a syntax change, not a career change.

EDR (Endpoint Detection and Response) is an agent on every endpoint that records detailed activity (processes, files, network connections), detects malicious behaviour, and lets analysts respond remotely: isolate the machine from the network, kill a process, pull files for analysis. Market examples you'll see in job ads: CrowdStrike Falcon and Microsoft Defender for Endpoint.

Curated resource (CC BY 4.0 technical docs): the Microsoft Sentinel documentation is free, openly licensed, and the best way to see what a real SIEM looks like before you have hands-on access.

4. Alert triage: the L1 methodology

Every alert you touch ends up in one of three buckets:

True positive (TP): the alert fired and something malicious really happened. Escalate.
False positive (FP): the alert fired but the activity was harmless; the detection was wrong (e.g. a backup tool flagged as data theft). Close, and flag the rule for tuning.
Benign true positive (BTP): the alert correctly detected the activity, but the activity was authorised (e.g. a pen tester the company hired, or an admin doing sanctioned maintenance). Close with evidence of the authorisation.

To decide which bucket, you enrich the alert with context:

Enrichment	Question it answers	Free tool
IP reputation / geolocation	Is this IP known-bad? Where is it?	VirusTotal, AbuseIPDB
File hash lookup	Has anyone seen this file before? Do AV engines flag it?	VirusTotal
WHOIS / domain age	Who registered this domain, and when? (Phishing domains are usually days old.)	any whois service
Internal context	Is this user on leave? Is this server meant to do that?	HR/IT systems, asking people

warning

Never upload a confidential company file to VirusTotal or any public service. Uploads are shared with the security community. Look up the file's hash instead. This is a classic new-analyst mistake.

Most SOCs give you a playbook (also called a runbook) for each alert type: a step-by-step checklist of what to check and when to escalate. Playbooks make L1 work learnable. You're not expected to improvise on day one, you're expected to follow the procedure carefully and think while doing it.

Here's the whole L1 triage loop in one picture:

The L1 triage flow, the same steps and three verdicts described in the text and table above, ending (always) with the write-up.

5. The incident response lifecycle

When an alert is confirmed as a real incident, response follows a standard lifecycle. The classic reference is the four-phase model from NIST SP 800-61 Rev. 2 (a US government publication in the public domain; described here with attribution to NIST as a courtesy). It's the model to know for Security+ and everyday SOC work; note that the 2025 Rev. 3 update reframed incident response around the NIST CSF 2.0 functions (govern, identify, protect, detect, respond, recover) you'll meet properly in M10. The phases below still map cleanly onto it:

Preparation, before anything happens: plans, playbooks, contact lists, tooling, training.
Detection & analysis, spot it, confirm it, work out scope: what's affected, how did they get in, what have they done?
Containment, eradication & recovery: stop the spread (isolate machines, disable accounts), remove the attacker's access and tools, restore systems safely.
Post-incident activity (lessons learned): what went wrong, what to fix, update detections and playbooks so it goes better next time.

The NIST SP 800-61 incident response lifecycle (the numbered list above). Note the loop: lessons learned feed back into preparation.

As an L1, you live mostly in step 2, but you'll execute containment actions from playbooks (isolating a host via EDR is often an L1 button-press) and your notes become the raw material for step 4.

6. Threat intelligence: IOCs, TTPs and MITRE ATT&CK

Threat intelligence is knowledge about attackers, used to defend better. Two levels matter at entry level:

IOCs (Indicators of Compromise), specific artefacts of an attack: an IP address, a domain, a file hash. Cheap to check, but attackers change them easily (a new server, a recompiled file). Useful for detection today, stale tomorrow.
TTPs (Tactics, Techniques and Procedures), the attacker's behaviours: "phishing with a malicious attachment, then credential dumping, then lateral movement over RDP." Much harder for attackers to change, so defending against TTPs is more durable.

The shared language for TTPs is MITRE ATT&CK, a public, freely accessible knowledge base of attacker techniques, each with an ID (e.g. T1566 is Phishing). SOC teams, job ads, detection rules and incident reports all reference ATT&CK IDs. Spend 20 minutes browsing the matrix now; being able to say "that maps to T1078, Valid Accounts" in an interview signals you speak the industry's language.

7. The underrated skill: writing good tickets

Here is the open secret of SOC hiring: managers can teach tools faster than they can teach clear writing. Every alert you triage produces a written record (the ticket or incident note) and that record is read by L2, by managers, by auditors, sometimes by lawyers. Career changers from admin, teaching, journalism, law or any writing-heavy field have a genuine edge here.

A good incident note answers, in plain English:

What fired: alert name, time (with timezone), severity, affected user/host.
What you checked: the enrichment and log evidence, with the actual values (IPs, hashes, timestamps).
What you concluded: TP / FP / BTP, and why, the reasoning, not just the verdict.
What you did: escalated to whom, or closed, and any containment actions taken.

Vague notes ("looked into it, seems fine, closing") are how incidents get missed and analysts get performance-managed. Precise notes are how L1 analysts get promoted.

🧪 Lab 8: Triage tabletop, the impossible-travel alert

No tools needed. This is a thinking exercise, exactly like a triage interview question. Work through it before opening the model answer.

The alert (fictional):

ALERT: Impossible travel detected · Severity: Medium User k.nguyen@example-corp.com.au signed in from two locations too far apart to travel between.

The sign-in logs (fictional, invented for this exercise):

2026-07-08 17:42:11 AEST  user=k.nguyen  result=SUCCESS  ip=203.0.113.45   location=Sydney, AU      device=LAPTOP-KN01 (registered)   mfa=satisfied
2026-07-08 23:17:52 AEST  user=k.nguyen  result=SUCCESS  ip=198.51.100.212 location=Frankfurt, DE   device=Unknown (new)              mfa=satisfied (SMS)
2026-07-08 23:19:03 AEST  user=k.nguyen  action=NEW_INBOX_RULE  rule="move all to RSS Feeds, mark read"
2026-07-08 23:24:40 AEST  user=k.nguyen  action=MAIL_SEND  count=3  subjects="Re: Invoice payment details update"

Triage it, ask yourself:

Is the travel actually impossible? (Sydney → Frankfurt in 5.5 hours: yes, impossible.)
Could it be a VPN? (Legitimate corporate VPNs are a common cause of FP impossible-travel alerts. Does example-corp have a Frankfurt VPN exit? That's an internal-context question you'd check or ask.)
What's the device? (Unknown, newly seen: a registered device would lean benign; an unknown one leans malicious.)
What happened after the sign-in? (A new inbox rule that hides mail plus outbound "invoice" emails is a classic business-email-compromise pattern: attackers hide the victim's view of replies while sending payment-redirection fraud.)
MFA was "satisfied (SMS)". Could the attacker have phished a code or SIM-swapped? SMS is the weakest MFA factor (as covered in M6).

Verdict: the follow-on behaviour makes this a true positive until proven otherwise. Escalate and contain. Don't just close it because MFA passed.

Model incident note (yours should look like this):

Alert: Impossible travel — k.nguyen — Medium — 2026-07-08 23:17 AEST
Triage: TRUE POSITIVE (suspected account compromise / BEC). Escalating to L2.

Evidence:
- Successful sign-in from 198.51.100.212 (Frankfurt, DE) at 23:17 AEST,
  5h35m after a Sydney sign-in. Travel not physically possible.
- Device unknown/new; prior sign-in was from registered LAPTOP-KN01.
- Corporate VPN has no DE exit point (checked internal VPN doc) — not a VPN FP.
- 23:19: new inbox rule created moving all mail to RSS Feeds folder marked
  read — consistent with BEC mailbox-rule concealment.
- 23:24: 3 outbound emails, subject "Re: Invoice payment details update" —
  consistent with payment-redirection fraud.
- MFA satisfied via SMS — phishable factor; does not clear the alert.

Actions taken (per playbook PB-014 Account Compromise):
- Revoked all active sessions for k.nguyen; account sign-in blocked.
- Preserved the inbox rule and sent items for investigation (not deleted).
- Escalated to L2 (J. Rivera) at 23:41 AEST with this note.
Recommended next: contact user out-of-band, review other sign-ins from
198.51.100.212, notify finance re: invoice emails sent.

Portfolio tip: write up your own version of this triage (or invent a different scenario and triage it) and put it in your portfolio repo. "Here is an incident note I wrote" is rare and impressive from an entry-level applicant.

Keep going (linked labs, free tiers): TryHackMe has a dedicated SOC Level 1 learning path: guided, browser-based rooms covering SIEM, network and endpoint analysis. It's the single best practical follow-on to this module. Also create a free VirusTotal account and practise looking up a few well-known-file hashes and IPs so enrichment feels natural.

Self-check

Answer before you reveal. The attempt is what makes it stick. Your score and card ratings are saved on this device only.

This is the vocabulary of the L1 job: triage verdicts, tools, and the IR lifecycle. It's also the biggest domain in the Security+ exam. Rate yourself honestly and the cards come back on a spaced schedule.

Flashcards · spaced repetition

Drill the key terms

Say your answer out loud (or in your head) before revealing. Recall is the workout. "Knew it" pushes a card's next review further out; "Review again" brings it back today.

Card 1 of 16

Prompt

Event

Next module

➡️ M9: Web & application security, how web apps break: the OWASP Top 10, SQL injection, XSS, and safe, legal places to practise.

What you'll get from this module​

1. What a SOC is, and who does what​

An L1 analyst's shift, hour by hour​

2. Telemetry: the raw material​

3. The tools: SIEM and EDR​

4. Alert triage: the L1 methodology​

5. The incident response lifecycle​

6. Threat intelligence: IOCs, TTPs and MITRE ATT&CK​

7. The underrated skill: writing good tickets​

🧪 Lab 8: Triage tabletop, the impossible-travel alert​

Self-check​

Check your understanding