Learn cybersecurity, with practice after every lesson
8 lessons, about 133 minutes of reading, and 24 multiple-choice questions. Each lesson names the mistake that most often costs people the interview, because that is where the hours actually go. Part of the free coding course.
What a SOC analyst actually does
BasicsA security operations centre watches an organisation's systems for signs that something is wrong, and a SOC analyst is the person reading what comes out. The job is triage: an alert fires, and you decide within minutes whether it is a real attack, a misconfiguration, or one of the many things that look alarming and are not. Most SOCs run tiers, and tier one is where people enter the field — it is one of the few security roles that genuinely hires without prior security experience.
The number that defines the work is how many alerts are false positives. In most environments the overwhelming majority are: a user travelling and logging in from a new country, a backup job touching thousands of files, a scanner the infrastructure team forgot to whitelist. The skill being hired for is not spotting the obvious attack, which the tooling already flagged. It is closing ninety-five alerts confidently and correctly so that the five real ones get attention while they still matter.
The tool you will live in is a SIEM — Splunk, Sentinel, QRadar or similar — which collects logs from everywhere and lets you query across them. Certifications like Security+ are worth more here than in most technology fields, because they are frequently a screening requirement rather than a preference, and CompTIA-style knowledge maps closely onto tier-one work.
Syntax
# The shape of a triage: an alert arrives, you answer four questions.
#
# ALERT Impossible travel — user logged in from Pune and Frankfurt, 40 min apart
#
# 1. IS IT REAL? Check both logins in the SIEM. Same account, different ASN?
# index=auth user="r.sharma" earliest=-2h | table _time, src_ip, country, result
#
# 2. WHAT ELSE? Look either side of the event, not just at it.
# index=auth user="r.sharma" | stats count by result -> 14 failures then 1 success?
#
# 3. WHAT CHANGED? Did anything happen AFTER the suspicious login?
# index=o365 user="r.sharma" earliest=-2h | search operation="New-InboxRule"
#
# 4. ESCALATE OR CLOSE, and write down why.
# "VPN egress in Frankfurt, confirmed with user by phone. Benign. Closing."
# "14 failed then success, new inbox rule forwarding externally. ESCALATE."Key points
- Tier-one SOC is a genuine entry point into security — one of very few that hires without prior security experience.
- The value is in confidently closing false positives, not only in catching attacks. A tier-one analyst who escalates everything is as unhelpful as one who escalates nothing.
- Always look at what happened AFTER a suspicious event. A login on its own is ambiguous; a login followed by a new mail-forwarding rule is an incident.
Practice challenge
An alert fires: one account logged in from Pune and Frankfurt 40 minutes apart. List the four questions you work through before escalating or closing, in order.
1. Is it real — check both logins, source IPs and ASNs
2. What else — failures before the success, other activity on the account
3. What changed AFTER — new mail rules, permission changes, downloads
4. Escalate or close, and write down the reasoning1. ______
2. ______
3. ______
4. ______Show a hint
- The third question is the one beginners skip and it usually decides the verdict
- The last step is still required even when you close it
Check yourself
1. What is most of a tier-one SOC analyst's day?
Show answer
B. Triaging alerts, most of which are false positives
2. Why look at events after a suspicious login?
Show answer
B. A login alone is ambiguous; what followed it shows intent
3. Why does the closing note matter?
Show answer
B. The next analyst needs the reasoning, especially if it turns out to be real
Reading logs and triaging an alert
Working levelEvery investigation is the same shape regardless of the alert: establish what normal looks like, find what deviates, then decide whether the deviation has an innocent explanation. That first step is the one beginners skip. Ten failed logins is meaningless until you know this account normally has none — or that it has forty a day because a service is using an expired password nobody has fixed.
Authentication logs, endpoint logs and network logs answer different questions and you need all three for most incidents. Auth tells you who tried to get in and whether they succeeded. Endpoint tells you what ran on the machine afterwards. Network tells you what left the building, which is usually the question that actually matters — an intrusion that exfiltrates nothing is a very different report from one that moved four gigabytes to an unfamiliar host.
The framework worth learning early is MITRE ATT&CK, which catalogues what attackers actually do, in order: initial access, execution, persistence, privilege escalation, lateral movement, exfiltration. It gives you the question to ask next. If you have found execution, ATT&CK tells you persistence is the next thing to look for, which is far more productive than searching for anything unusual.
Syntax
# Establish normal FIRST, then look for the deviation.
# 1. Baseline: what does this account usually do?
index=auth user="r.sharma" earliest=-30d
| timechart span=1d count by result
# -> normally 3-6 successes/day, 0-1 failures. Today: 14 failures, 1 success.
# 2. Same source? Same as the usual pattern?
index=auth user="r.sharma" earliest=-24h
| stats count values(country) values(user_agent) by src_ip
# 3. What ran afterwards (endpoint)?
index=edr host="LAPTOP-4471" earliest=-2h
| search process IN ("powershell.exe","rundll32.exe","certutil.exe")
# 4. What LEFT (network) — usually the question that decides severity
index=proxy src_ip=10.4.2.19 earliest=-2h
| stats sum(bytes_out) AS out by dest_domain
| sort -outKey points
- Baseline before you judge. "Ten failed logins" means nothing until you know whether this account normally has zero or forty.
- Auth, endpoint and network answer different questions. Bytes leaving the network is usually what decides how serious the incident is.
- MITRE ATT&CK gives you the next question rather than a list of tools — found execution, now go looking for persistence.
Practice challenge
For each question, name which log source answers it: (a) did they get in, (b) what ran on the machine afterwards, (c) how much data left the network. Then say which one usually decides severity.
a) authentication
b) endpoint / EDR
c) network / proxy
Decides severity: network — what actually left the environmenta) ______
b) ______
c) ______
Decides severity: ______Show a hint
- Three different sources, one per question
- An intrusion that exfiltrated nothing is a very different report
Check yourself
1. What should you establish before judging an alert?
Show answer
B. What normal looks like for that account or host
2. Which log source usually decides how severe an incident is?
Show answer
B. Network — what actually left the environment
3. What does MITRE ATT&CK give an analyst?
Show answer
B. The likely next attacker step, so you know what to look for
Detection engineering and alert fatigue
AdvancedDetection engineering is the step past triage: instead of working the queue, you change what enters it. A detection is a rule that turns log data into an alert, and writing good ones is the difference between a SOC that catches things and one that drowns. The trade-off is always the same — a rule tuned to catch everything produces so many false positives that analysts start closing alerts without reading them, at which point the rule has made the organisation less safe rather than more.
Alert fatigue is the real failure mode in security operations, and it is a design problem rather than a discipline problem. If a rule fires two hundred times a week and is right twice, no amount of professionalism keeps analysts reading it carefully by Thursday. The fix is either tightening the rule with context — this process, from this parent, outside these hours, on a host that has not done it before — or accepting that it should be a weekly report rather than a real-time alert.
This is also where the job market rewards you. Tier-one triage is an entry point with a salary to match; detection engineering, threat hunting and incident response are where security pay separates from IT pay. The move is usually made by the analyst who stopped closing a recurring false positive and rewrote the rule that produced it.
Syntax
# A noisy rule and a useful one, for the same behaviour.
# NOISY — fires on every PowerShell launch. Hundreds a day, almost all benign.
# index=edr process=powershell.exe | alert
# TUNED — the same behaviour, with the context that makes it suspicious:
index=edr process=powershell.exe
| search parent_process IN ("winword.exe","excel.exe","outlook.exe") # Office spawning a shell
| search command_line="*-enc*" OR command_line="*-w hidden*" # encoded / hidden
| join type=left host [ search index=edr_baseline | fields host, ps_seen_before ]
| where isnull(ps_seen_before) # not normal for this host
| alert
# Every detection should be able to answer these before it goes live:
# What attacker behaviour does this map to? (ATT&CK T1059.001)
# How often will it fire, and how often be right?
# What should the analyst DO when it fires? (a rule with no action is a report)Key points
- A detection that fires constantly and is rarely right makes the organisation less safe, because analysts stop reading the queue carefully.
- Tune with context rather than by raising thresholds: parent process, time of day, and whether this host has ever done it before.
- Every rule needs a documented response. A detection nobody knows how to action is a report that happens to page someone.
Practice challenge
A rule alerts on every PowerShell launch: 200 alerts a week, right twice. Give three pieces of context that would make it precise, and say why raising the threshold is not the answer.
Parent process (Office spawning a shell)
Command line flags (-enc, -w hidden)
Whether this host has ever done it before
A threshold just makes it quieter without making it more accurate — it hides real events at the same rate as false onesContext 1: ______
Context 2: ______
Context 3: ______
Why not a threshold: ______Show a hint
- Context means what surrounds the event, not how many times it happened
- The failure mode being solved is analysts muting the rule
Check yourself
1. Why is a very noisy detection rule dangerous?
Show answer
B. Analysts stop reading the queue carefully, so real alerts get missed
2. What is the better way to tune a rule?
Show answer
B. Add context — parent process, timing, whether the host has done it before
3. What must every detection have besides the query?
Show answer
B. A documented response — what the analyst should actually do
Write the incident report
Job-readyAnalysis that nobody can act on is not finished work. The report is the deliverable, and in a SOC it is judged on whether a manager who was not there can read it once and know what happened, what it cost, and what to do. Most junior reports fail on the second and third of those.
Structure it so the answer comes first. What happened, in one sentence a non-specialist understands. When — a timeline with timestamps, including when you found out, which is often uncomfortably far from when it started. What was affected, stated as scope and stated honestly, including what you could not determine. What you did. What should change so it does not recur.
Separate what you observed from what you concluded, and mark confidence. "The account authenticated from an IP in another country" is an observation. "The account was compromised via phishing" is a conclusion, and if the evidence is a similar case last month rather than a recovered email, say so. Reports that blur those two are the reason security teams lose credibility with the rest of the business.
Syntax
INCIDENT 2026-0817-014 Severity: Medium Status: Contained
SUMMARY
One finance account was accessed by someone other than its owner
on 17 Aug. No data was downloaded. Access was revoked in 41 min.
TIMELINE (UTC)
09:12 Successful login, IP 203.0.113.44 (ASN differs from normal)
09:14 Inbox rule created: forward *invoice* -> external address
09:31 Impossible-travel alert raised to the queue
09:53 Sessions revoked, password reset, rule deleted
SCOPE
Affected: 1 account (a.sharma@). Mailbox accessible 09:12-09:53.
NOT determined: whether messages were read. Read receipts are not
logged at our licence tier — stated here rather than assumed either way.
OBSERVED vs CONCLUDED
Observed : login from an unusual ASN; forwarding rule created 2 min later
Concluded: credential theft, MEDIUM confidence. No phishing mail
recovered; inferred from the pattern and last month's case.
ACTIONS / RECOMMENDATIONS
Done : sessions revoked, credentials rotated, rule removed
Proposed: alert on external-forwarding rule creation (would have cut
detection from 19 min to ~2), MFA enforced for finance groupKey points
- Lead with the one-sentence summary. Most readers stop there, and it is the sentence that gets quoted upwards.
- Say what you could NOT determine. An honest gap is credible; a confident guess that turns out wrong costs the team every future report.
- Separate observed from concluded and give the conclusion a confidence level. It is the difference between an analyst and a storyteller.
Practice challenge
From an investigation you have: a login from an unfamiliar ASN at 09:12, a mail-forwarding rule created at 09:14, no recovered phishing email, and no way to tell whether messages were read. Write the summary line, one observation, one conclusion with a confidence level, and the one thing you must state as undetermined.
Summary: one account was accessed by someone other than its owner; a forwarding rule was created and has been removed.
Observed: successful login from an ASN this account has never used, followed two minutes later by creation of an external forwarding rule.
Concluded: credential compromise - MEDIUM confidence. No phishing message was recovered, so this is inferred from the pattern rather than evidenced directly.
Undetermined: whether any messages were actually read. Read events are not logged at our licence tier.Summary: ______
Observed: ______
Concluded: ______ (confidence: ______)
Undetermined: ______Show a hint
- The confidence level is doing real work here - there is no recovered phish
- A gap you name is credible; a gap you paper over destroys trust in every later report
Check yourself
1. What belongs in the first line of an incident report?
Show answer
B. A one-sentence summary a non-specialist can act on
2. Why state what you could not determine?
Show answer
B. It is credible, and an unmarked guess destroys trust when wrong
3. "The account was phished" is:
Show answer
B. A conclusion that needs a confidence level
The attacks you will actually see
BasicsSecurity work in practice is dominated by a small number of attacks that recur endlessly, and none of them are the cinematic kind. Phishing is the largest by volume: an email or message that persuades someone to enter credentials on a page that looks right, or to approve a login they did not start. It works because it targets a person under time pressure rather than a system, which is why technical controls alone never eliminate it and why the report-it path must be faster and less embarrassing than clicking.
Credential stuffing is next and it needs no skill at all. Attackers take username and password pairs leaked from some unrelated breach and replay them against every service they can reach, because people reuse passwords. From the defender's side it looks like a burst of failed logins across many accounts from many addresses, followed by a few successes — and those successes are the dangerous part, because they are genuine credentials and nothing about the session is technically wrong.
Then ransomware, which is usually the end of a chain rather than the start: an initial foothold from phishing or an exposed service, quiet movement to find valuable systems, then encryption of everything reachable and a demand. What decides the outcome is almost never the malware, it is whether you have backups that were offline and tested. A backup on a network share the attacker can also reach gets encrypted with everything else, and a backup nobody has ever restored from is a hypothesis rather than a plan.
Syntax
# WHAT THE COMMON ATTACKS LOOK LIKE IN LOGS
#
# PHISHING -> credential theft
# sign-in succeeds, but: new country, new device, minutes after
# an email from an unusual sender. MFA prompt approved at 03:12.
# Tell: impossible travel — Pune 14:02, Lagos 14:40.
#
# CREDENTIAL STUFFING
# hundreds of failed logins, MANY different usernames,
# MANY source IPs, same user-agent, steady rate.
# Tell: high failure rate across accounts, then a few successes.
# (Brute force is the opposite: ONE account, many passwords.)
#
# RANSOMWARE -- by the time files encrypt you are late
# earlier: unusual admin tool use, mass file reads,
# backup deletion, security tooling disabled.
#
# WHAT ACTUALLY REDUCES EACH
# phishing -> phishing-resistant MFA (passkeys/FIDO2);
# a blameless, one-click report button
# stuffing -> MFA + rate limiting + breached-password checks
# ransomware -> OFFLINE, immutable, TESTED backups;
# least privilege so one machine is not all machinesKey points
- Most incidents start with a person, not an exploit. Phishing and reused passwords beat firewalls, so MFA and a fast blameless reporting path do more than another appliance.
- Credential stuffing shows as many usernames failing from many addresses; brute force is one username and many passwords. The distinction changes what you do next.
- A backup reachable from the network gets encrypted with everything else, and a backup never restored from is untested. Offline, immutable and rehearsed is the whole control.
Practice challenge
Classify each pattern and give the control that most reduces it: (a) 4,000 failed logins across 900 different usernames from 300 IPs in 20 minutes, then 6 successes, (b) 2,000 failed logins on one admin account from one IP, (c) a successful login from Pune at 14:02 and the same account from Lagos at 14:40.
(a) Credential stuffing - leaked username/password pairs replayed. Control: MFA, plus breached-password checks and rate limiting
(b) Brute force on a single account. Control: lockout or exponential backoff, plus MFA
(c) Impossible travel, indicating a stolen session or credential. Control: phishing-resistant MFA and conditional access, then revoke the session(a) ______ / control ______
(b) ______ / control ______
(c) ______ / control ______Show a hint
- Many usernames versus one username is the distinguishing feature
- The third is not a login-attempt pattern at all - both succeeded
Check yourself
1. Many usernames failing from many IP addresses, then a few successes. What is this?
Show answer
B. Credential stuffing with leaked password pairs
2. Why is a backup on a reachable network share inadequate against ransomware?
Show answer
B. The attacker encrypts it along with everything else
3. Someone reports clicking a phishing link. Best response?
Show answer
B. Thank them and act — punishing reports destroys your fastest signal
Identity is the perimeter now
Working levelThe network boundary stopped being the control a long time ago. Staff work from anywhere, applications are somebody else's SaaS, and services authenticate to each other over the public internet, so the question 'are you inside the network' no longer separates trusted from untrusted. What remains is identity: who is making this request, on what device, and are they allowed. That shift is what 'zero trust' names, and stripped of marketing it means verify every request rather than trusting a location.
Multi-factor authentication is the single highest-value control, and the kinds differ enormously. SMS codes are better than nothing and are defeated by SIM swap and by a phishing page that simply asks for the code. App-generated codes are stronger but still phishable in real time, because a proxy page can relay them within the window. Passkeys and hardware keys are phishing-resistant by construction: the credential is cryptographically bound to the real domain, so a lookalike site cannot use it even with a fully convincing page and a cooperative victim.
Beyond the login is the session, which is where defenders often stop paying attention. After authentication the user holds a token, and anyone who steals that token is that user without needing the password or the second factor — which is why stolen session cookies are actively traded and why 'we have MFA' is not a complete answer. The mitigations are short token lifetimes, binding a session to a device where you can, revoking sessions on password change, and treating a session that changes country mid-life as an event rather than a curiosity.
Syntax
# MFA IS NOT ONE THING
# SMS code phishable, SIM-swappable weakest
# TOTP app phishable in real time better
# Push approve fatigue attacks: spam until better
# someone taps 'approve'
# Passkey/FIDO2 bound to the real domain phishing-resistant
# -> a lookalike site cannot use it, ever
# THE SESSION IS A SECOND CREDENTIAL
# token stolen from a browser = full access, no password,
# no MFA prompt. "We have MFA" does not cover this.
#
# -> short token lifetimes
# -> revoke ALL sessions on password reset
# -> re-authenticate before sensitive actions
# -> alert on session country/ASN change mid-life
# WHAT TO CHECK IN AN IDENTITY LOG
# impossible travel Pune 14:02 -> Lagos 14:40
# new device + new geo + immediately after an email
# MFA approved at 03:12 (fatigue attack)
# legacy/basic auth still enabled <- bypasses MFA entirely
# dormant service accounts with no expiry
# consent granted to an unfamiliar OAuth app
# The oldest gap: one legacy protocol left enabled
# undoes an MFA rollout for the whole organisation.Key points
- Passkeys and hardware keys are phishing-resistant because the credential is bound to the real domain. SMS and app codes can be relayed by a convincing proxy page in real time.
- A stolen session token is access without a password or an MFA prompt. Short lifetimes, revocation on password change and mid-session anomaly checks are what cover it.
- One legacy authentication protocol left enabled bypasses an entire MFA programme. Check for it before declaring a rollout complete.
Practice challenge
An organisation deployed app-based MFA. An attacker still accessed a mailbox without triggering any MFA prompt. Give the two most likely explanations, say which MFA type would have prevented the phishing route, and name the control for the session route.
Explanation 1: a stolen session token - after authentication the token is access, so no password and no MFA prompt is needed
Explanation 2: a legacy authentication protocol left enabled, which bypasses MFA entirely
MFA type: passkeys / FIDO2, which are bound to the real domain so a lookalike site cannot use them
Session control: short token lifetimes, revoke all sessions on password change, and alert on a mid-session country or ASN changeExplanation 1: ______
Explanation 2: ______
MFA type that stops phishing: ______
Control for the session route: ______Show a hint
- MFA protects the login, not what is issued afterwards
- One legacy protocol can undo an entire MFA rollout
Check yourself
1. Why is a passkey phishing-resistant when a TOTP code is not?
Show answer
B. It is cryptographically bound to the real domain, so a lookalike cannot use it
2. An attacker steals a session cookie. What do they need next?
Show answer
C. Nothing — the token is access
3. MFA is deployed but legacy auth is left on. What is the effect?
Show answer
B. Attackers use the legacy path and bypass MFA entirely
Vulnerabilities, and why 'critical' is not a plan
AdvancedA scanner will hand you thousands of findings and a severity score for each, and the score alone is a poor guide to what to fix. CVSS measures how bad a vulnerability could be under worst-case assumptions, not how exposed you are to it. A critical rated 9.8 on an internal service unreachable from the internet, requiring credentials you do not issue, may matter far less than a medium on your public login page. Severity is an input to prioritisation; it is not prioritisation.
What turns a list into a plan is context. Is the affected system reachable from the internet? Does it hold or reach sensitive data? Is there a public exploit, and is it being used right now — which is what a known-exploited catalogue like CISA's KEV tells you, and it is a far stronger signal than the score. Is there a compensating control already in the path, such as a web application firewall rule or the feature being disabled? Those four questions reorder a scanner's output dramatically, and the reordering is the actual work.
Then there is the part everyone underestimates: patching is a change, and changes break things. A patch programme that ignores this gets one bad weekend and then loses the organisation's cooperation for a year. So it needs a staged path — test, then a canary group, then broadly — with a rollback that has been rehearsed, and agreed windows by severity so nobody argues each time. And where a patch genuinely cannot be applied, the honest answer is a documented compensating control with a named owner and a review date, not an exception that quietly becomes permanent.
Syntax
# CVSS 9.8 DOES NOT MEAN 'FIX FIRST'.
# Score is severity under worst-case assumptions.
# Priority = severity x exposure x exploitation x data.
# FOUR QUESTIONS THAT REORDER ANY SCAN REPORT
# 1. Reachable from the internet? (or internal only?)
# 2. Does it hold or reach sensitive data?
# 3. Public exploit? Actively exploited? (check KEV -- strongest signal)
# 4. Compensating control already in path? (WAF rule, feature off)
# WORKED EXAMPLE
# A: CVSS 9.8, internal build server, no internet route,
# no public exploit, needs valid credentials -> this week
# B: CVSS 6.5, public login page, exploit in the wild,
# listed in KEV, no mitigation -> tonight
# The 6.5 outranks the 9.8. Score alone gets this backwards.
# PATCHING IS A CHANGE. TREAT IT LIKE ONE.
# test -> canary (5%) -> staged -> full
# rehearse the rollback BEFORE you need it
# agree windows once, by severity, so it is not renegotiated
# actively exploited -> emergency, hours
# critical, exposed -> days
# everything else -> the normal cycle
# Cannot patch? Then a WRITTEN compensating control,
# a named owner and a review date -- not a silent exception.Key points
- CVSS measures worst-case severity, not your exposure. Reachability, data sensitivity and active exploitation reorder a scan report far more usefully than the score.
- Active exploitation in the wild is the strongest single prioritisation signal available — a known-exploited listing outranks a higher score that nobody is using.
- Patching is a change with its own risk. Stage it, rehearse the rollback, and agree windows by severity in advance so each patch is not a negotiation.
Practice challenge
Rank these three and justify the top one in a sentence: (A) CVSS 9.8 on an internal build server with no internet route, no public exploit, requires valid credentials. (B) CVSS 6.5 on the public login page, listed as actively exploited, no mitigation in place. (C) CVSS 7.5 on an internal service already blocked by a firewall rule.
Order: B, then A, then C
Why B: it is internet-facing, actively exploited in the wild, and has no compensating control - active exploitation is the strongest single prioritisation signal available
What CVSS measures: worst-case technical severity independent of your environment. It is an input to prioritisation, not prioritisation itself.Order: ______
Why the top one: ______
What CVSS actually measures: ______Show a hint
- Reachability and active exploitation outrank the number
- C already has a control in the path
Check yourself
1. What does a CVSS score measure?
Show answer
B. Worst-case technical severity, independent of your environment
2. Which is the strongest signal to patch immediately?
Show answer
B. Listed as actively exploited in the wild
3. A system genuinely cannot be patched. Correct response?
Show answer
B. Document a compensating control with a named owner and review date
A confirmed breach: the first hour
Job-readyWhen an alert becomes a confirmed compromise, the ordering of your first moves determines how much worse it gets. Containment comes before investigation, because the attacker is still working while you read. That means isolating affected hosts from the network without powering them off, disabling compromised accounts, revoking sessions and tokens rather than only resetting passwords, and blocking the command-and-control addresses you have identified. Every minute spent understanding before containing is a minute of continued access.
The instinct to reboot or reimage immediately is the one to resist, because it destroys the evidence you will need. Memory contains running processes, network connections and often the keys and payloads that never touched disk, and it is gone the moment the machine powers down. Isolating at the network level preserves that state while stopping the harm. Capture memory, then disk, record hashes so the copies are defensible, and keep a contemporaneous timeline of every action with times and names — that log is what regulators, insurers and your own post-incident review will read.
Communication runs in parallel and is where organisations most often make things worse. Say what is known, what is not yet known and when you will next update, on a fixed cadence, to a defined audience. Do not speculate about scope or attribution in the first hour; early estimates get quoted back for months and are almost always wrong. Notification obligations are legal, not technical, and clocks may already be running — GDPR's is 72 hours from awareness — so legal and communications belong in the room from the start, not after the technical work is finished.
Syntax
# FIRST HOUR, IN ORDER. Containment before investigation.
#
# 1. CONTAIN
# isolate host at the NETWORK layer -- do NOT power off
# disable compromised accounts
# REVOKE sessions and tokens (a password reset alone
# leaves live sessions working)
# block known C2 addresses
#
# 2. PRESERVE -- order matters: most volatile first
# memory capture (processes, connections, keys never on disk)
# then disk image
# hash both; record who took them, when
# DO NOT reboot or reimage -- that is evidence destruction
#
# 3. RECORD -- a contemporaneous timeline
# 14:02 alert raised
# 14:11 confirmed: token replay from unknown ASN
# 14:13 sessions revoked for user X (A. Rao)
# 14:20 host isolated at switch (M. Iqbal)
#
# 4. COMMUNICATE -- fixed cadence, defined audience
# known / not yet known / next update at HH:MM
# no speculation on scope or attribution -- it gets quoted for months
#
# 5. CLOCKS ARE ALREADY RUNNING
# GDPR: 72 hours from awareness. Legal and comms in the room NOW,
# not after the technical work finishes.
# Recovery: rebuild from known-good, rotate every credential the
# attacker could reach, and only then reconnect.Key points
- Contain before you investigate. Isolate at the network layer rather than powering off, so the attacker stops while volatile evidence survives.
- Revoke sessions and tokens, not just passwords. A reset password with live sessions still attached changes nothing for an attacker already inside.
- Keep a timestamped log of every action and who took it, and communicate known versus unknown on a fixed cadence. Early speculation about scope is quoted for months and is usually wrong.
Practice challenge
A workstation is confirmed compromised and the attacker is active now. Put these in the correct order and justify the first: reimage the machine, capture memory, isolate at the network layer, reset the user's password, revoke sessions and tokens. Then say what is wrong with two of them as written.
Order: isolate at the network layer, revoke sessions and tokens, capture memory, (reset password as part of the revoke step), and reimage only at the end
Why first: containment before investigation - the attacker is still working while you read, and isolating stops the harm while preserving volatile evidence
Wrong with reimage: done early it destroys the evidence, and memory holds processes, connections and keys that never touched disk
Wrong with password reset alone: existing sessions and tokens stay valid, so the attacker keeps accessOrder: ______
Why first: ______
Wrong with 'reimage': ______
Wrong with 'reset password' alone: ______Show a hint
- Powering off and reimaging both destroy what you will need to prove
- A password reset does not invalidate what was already issued
Check yourself
1. What is the correct first action on a confirmed compromise?
Show answer
B. Isolate it at the network layer, preserving memory
2. Why is resetting the password insufficient?
Show answer
B. Existing sessions and tokens remain valid — they must be revoked
3. An executive asks for the scope in the first hour. Best response?
Show answer
B. State what is known, what is not, and when you will next update
Common questions
Do I need any background to start Cybersecurity?
No. This track begins at its own beginning and assumes nothing, and the first lesson explains what the thing is before showing you any syntax.
How long does the Cybersecurity track take?
About 133 minutes of reading across 8 lessons, plus the practice challenges and 24 multiple-choice questions, which is where the time actually goes.
Is it free?
Yes, and there is no account. Everything runs in your browser.
More: all 15 tracks · what employers actually ask for · the full syllabus