Contents of Hands-On AI SOC Analyst: Build AI Agents for Security Operations
The whole course told through one real attack, what you should already know, and the lab you will use from the first page to the last. The book has 77 pages: the opening pages and 9 parts. 12 of them are published so far. The free pages open for everyone; the rest open when you buy the course.
See the early-access price and what the course covers
Your progress0 of 6 checks answered right
It fills only when a prediction matches the measured result. Reading a page does not move it. It is kept in this browser.
Start here
The opening pages
The whole course told through one real attack, what you should already know, and the lab you will use from the first page to the last.
3 pages, all published
- Introduction: what this course buildsOne real password-guessing attack on the course lab, followed from the first wrong password to the alerts Wazuh raised, and how the AI agents you build will investigate it while a person decides. Free
- Before you startThe terminal and Python basics the course assumes, the tools to install, and the course lab built in your own AWS account, with its cost, a budget alert and a one-command teardown. Free
- Your lab's first alert, checked end to endRunning the administrator's ordinary work and the Kali attack on the lab from "Before you start", and checking each alert against the log line it came from. Locked
Part 1
The SOC from zero
What a SOC is for, what an alert and a log really are, and how a junior analyst works through the queue, all done by hand before any tool helps.
8 pages, all published
- What a security operations centre does all dayWho works in a SOC, what tier 1, tier 2 and tier 3 analysts do, and why most of the day is deciding which alerts matter. Free
- What an alert is, and why most alerts are noiseTrue and false positives in plain words, alert fatigue, and why a quiet SOC is not the same as a safe one. Locked
- Logs are the evidence every investigation starts fromWhere logs come from on Linux, Windows, macOS and the network, and why the time, the host and the user matter in every line. Locked
- Reading a Linux login log by handRunning a real SSH password-guessing attack against a lab machine and finding it in the auth log with grep before any tool helps. Locked
- Windows event logs and Sysmon in plain wordsThe event IDs an analyst learns first (4624, 4625, 4688, Sysmon 1 and 3), read from public sample logs and from the Windows server in your own lab. Locked
- How an attack unfolds, step by stepThe stages of a real intrusion, so that every alert later in the course has a place in a story. Locked
- The triage routine a junior analyst followsOne alert worked from start to finish by hand, with the questions an experienced analyst asks every time. Locked
- Writing an incident ticket by handWhat goes in a ticket (what happened, the evidence, the impact and the next step), and the habits that make a ticket useful at 3 in the morning. Locked
Part 2
Wazuh, a real SIEM, hands-on
What a SIEM does, how Wazuh turns raw logs into alerts, and how to write, test and tune your own rules on your own lab.
10 pages, coming
- What a SIEM doesThe problem a SIEM solves, explained before any product name, then the same idea in Wazuh, Elastic Security and Splunk.Coming
- How Wazuh is builtFollowing one log line from the agent on the practice server to the alert on the dashboard, with every port it passes through.Coming
- Adding machines to WazuhEnrolling agents, checking that they report in, and what to do when an agent stays disconnected.Coming
- Watching a real attack become an alertThe rule ID, level, groups, the MITRE technique and the source IP, read on the dashboard and as raw JSON.Coming
- Searching alerts like an analystFiltering by host, user, rule and time, and asking the same questions from Python, which the AI agents will use later.Coming
- Noticing when an important file changesWatching a folder, changing a file in it, and seeing who changed what and when.Coming
- Finding vulnerable software and weak settingsVulnerability detection against the Wazuh CTI feed and the configuration checks, and reading what each finding says.Coming
- How a raw log becomes an alertTesting a log line with wazuh-logtest and watching which decoder and which rule fire, and why.Coming
- Writing your first detection ruleA custom rule in local_rules.xml (IDs 100000 to 120000) mapped to an ATT&CK technique, tested, deployed and tuned on real traffic.Coming
- Blocking an attacker automatically, and why to be carefulBlocking the guessing IP after five failures, then locking out your own test user on purpose to see the danger.Coming
Part 3
MITRE ATT&CK and detection engineering
A shared language for attacker behaviour, safe attack tests, Sigma rules that work in any SIEM, and detections kept in Git and tested like code.
9 pages, coming
- MITRE ATT&CK in plain wordsThe 15 tactics of ATT&CK v20 (including the newer Stealth and Defense Impairment), techniques, sub-techniques and the detection strategies MITRE now publishes.Coming
- Reading your own alerts through ATT&CKPulling the techniques from your alerts and showing your coverage on an ATT&CK Navigator layer.Coming
- Running safe attack tests on your own labRunning real ATT&CK techniques on the practice servers in your own lab, and checking which ones Wazuh caught.Coming
- Sigma, a detection rule you can shareReading a real rule from the public SigmaHQ repository line by line: the log source, the detection and the condition.Coming
- Running a Sigma rule against Wazuh dataThere is no official Wazuh backend, so the rule is converted to an OpenSearch query and run on the Wazuh indexer, then rewritten by hand as a Wazuh rule.Coming
- Writing your own Sigma ruleFrom the attack test, to the log it left, to a rule, to a match, with a false positive found and fixed on the way.Coming
- Keeping detections in Git and testing themA small detection repository with a GitHub Actions check that converts every rule and replays a saved log against it.Coming
- Measuring whether a rule is any goodTrue positives, false positives and alert volume per day, measured on a week of lab traffic.Coming
- Catching attacks that only show up as a patternTen failures then one success from the same address, written as a Wazuh frequency rule and as a Sigma correlation rule.Coming
Part 4
Threat intelligence and threat hunting, by hand
What indicators of compromise are, how to check them against free public sources, and how to search for an attacker no alert has found yet.
6 pages, coming
- Indicators of compromise, and their limitsWhy a hash is easy for an attacker to change and a behaviour is not, explained with the pyramid of pain.Coming
- Enriching an alert with public threat intelligenceChecking an IP and a file hash with your own free keys, reading the answers critically, and respecting each service's terms and rate limits.Coming
- Sending Wazuh alerts to other toolsA custom-* integration script that posts each high-level alert as JSON to a local web service, which the agents will read later.Coming
- What threat hunting isWriting a hunting hypothesis from an ATT&CK technique, and deciding what evidence would prove or disprove it.Coming
- A real hunt on a public attack datasetLoading a recorded attack into the Wazuh indexer and finding it step by step with queries.Coming
- Writing up a huntThe hunt report, what was found and what was not, and the rule it turns into.Coming
New part
Vulnerabilities and the software supply chain
What a vulnerability is and how the world names, scores and tracks it, how to decide what to fix first, and how to see every package your software is built from, ending with a prioritised fix list for your own cloud lab.
9 pages, coming
- What a vulnerability is, and what a CVE isHow the CVE Program, sponsored by CISA and operated by MITRE, and the CVE Numbering Authorities give a flaw its ID, often before it is made public, and reading one real CVE record line by line.Coming
- CWE: the weakness behind the bugReading CWE-79 (cross-site scripting) and CWE-89 (SQL injection), and how one weakness explains a whole class of CVEs.Coming
- CVSS: how a vulnerability is scoredThe metric groups (base, temporal in 3.1 or threat in 4.0, environmental, and 4.0's new supplemental group), scoring a real CVE by hand, and what the score leaves out about your own systems.Coming
- CPE: naming the software that is affectedReading a CPE name part by part, version ranges, why many recent CVEs have no CPE yet, and why a near match is how real teams miss a vulnerable server.Coming
- Looking up a CVE in the NVD, by hand and with a scriptFinding a CVE's CVSS score, CWE and CPE names on the website, then fetching the same record with a script, using the free API key that raises the rate limit.Coming
- What to fix first: EPSS and the KEV catalogThe estimated probability that attacks on a CVE are seen in the next 30 days (EPSS, from FIRST) next to the CVEs that CISA has confirmed are exploited in the wild (KEV), compared on the same CVEs to show why severity alone misleads.Coming
- SBOM: the list of everything your software is built fromCycloneDX and SPDX in plain words, generating an SBOM with Syft for a real image in your lab, then scanning it with Grype and Trivy and comparing what each finds.Coming
- Package and supply-chain attacksHow attackers get code into your build through look-alike names (typosquatting) and public packages that take the name of your private ones (dependency confusion), shown with a harmless test package that your lab's scanner and Wazuh catch.Coming
- Finding and ranking the vulnerabilities in your own labBuilding on Wazuh's vulnerability detection from Part 2, each finding on the lab servers joined to its EPSS score and KEV status by your own script, and a fix list a team could act on this week.Coming
Part 5
AI agents from zero, for analysts
What a language model really does, what an agent is, how to give it safe read-only tools on Wazuh, and why every log line it reads may be written by the attacker.
1 of 8 pages published
- What a language model really doesSending one real Wazuh alert to a model, reading the answer, and reading the bill.Coming
- Getting answers your code can checkA verdict with a fixed set of fields (malicious, suspicious or benign, the reason and the evidence) instead of free text.Coming
- What an AI agent isThe difference between a script, a workflow and an agent, and when an agent is the wrong choice in a SOC. Free
- Giving an agent safe tools on WazuhSearch alerts, get an agent's details and look up a rule, written as tools that can read but never change anything.Coming
- Every log line may be written by the attackerSending an SSH username that contains an instruction, watching a naive agent obey it, then building the defence.Coming
- Building a triage agent as a graphThe same triage routine from Part 1, written as a LangGraph graph that you can read and test step by step.Coming
- Making the agent ask a person firstPausing before a block, showing the analyst the evidence, and resuming with approve, edit or reject.Coming
- Knowing what each investigation costsA cost log of tokens, dollars and seconds per alert, and a trace of every tool call.Coming
Part 6
The AI SOC team
One agent per job, each with narrow tools, a supervisor that runs the case, and a person who approves every action that changes anything.
9 pages, coming
- Grouping an alert storm into one caseTurning two hundred alerts from one attack into one case with the right priority, using plain code before any model.Coming
- The triage agentThe triage agent run on the real alerts from your lab, with the evidence for every verdict.Coming
- The enrichment agentParallel lookups with caching, rate limits and a clear note when a source had no answer.Coming
- The hunting agentAn agent that writes OpenSearch queries, with a checker that refuses any query it should not run.Coming
- The incident report writerA report built only from evidence the other agents collected, with every claim linked to an alert ID.Coming
- Proposing containment, with a person approvingAn approval bound to the exact action and host, a re-check before running it, and a full record of who approved what.Coming
- The supervisor that runs the caseHand-offs, a step budget, and stopping cleanly when the agents disagree.Coming
- A simple console for the analystA small web page showing the case, the evidence, the draft report and the pending approvals.Coming
- When the agents go wrongThe failures seen while building this course, each reproduced and each contained.Coming
Part 7
Attack graphs with Neo4j
Why connections between hosts, users, addresses and techniques reveal what a list of alerts hides, and how an agent can ask a graph questions.
6 pages, coming
- Why an attack is easier to see as a graphThe same incident drawn as a table and as a graph, and the question only the graph answers.Coming
- Neo4j from zeroStarting Neo4j Community in Docker and writing the five Cypher patterns used for the rest of the part.Coming
- Loading MITRE ATT&CK into Neo4jTactics, techniques, groups and software as a graph, and asking which groups use a technique you saw.Coming
- Turning your alerts into a graphA loader that reads the indexer and writes the graph, run on the attacks from your lab.Coming
- Finding the path an attacker tookPath queries from the first alert to the most valuable machine, and what to watch next.Coming
- Letting the agent ask the graphA tool with fixed, checked queries, so the agent cannot run anything that changes the graph.Coming
Part 8
Prove it, and get the job
An honest evaluation of the agents, a red team against them, a full capstone exercise, and the portfolio and interview preparation for a SOC role.
9 pages, coming
- What it means for a triage agent to be goodThe measures that matter in a SOC, agreed before any test is run, with why a missed attack counts more than a false alarm.Coming
- Building a labelled test set from your own labRecording alerts from attack tests and from ordinary use, labelling each one by hand and freezing the set.Coming
- Scoring the agents by codePrecision, recall and the confusion table for the triage agent, run with one command.Coming
- Judging the incident reports fairlyScoring reports for accuracy and completeness, and measuring how often the model judge agrees with you.Coming
- Numbers you can trustWhy one run proves nothing, and how to tell a real improvement from luck.Coming
- Attacking your own agentsA block rate for every kind of attack, measured, with the failures written down.Coming
- Capstone: one full incident, start to finishA new attack the agents have not seen, run end to end, with the evaluation numbers and the report.Coming
- The report a SOC manager asks forThe monthly numbers, computed from your own lab, and how to present them honestly.Coming
- Turning the course into a jobWhat to show, how to explain it, and the questions tier 1 and detection engineering interviews really ask.Coming