AI as SOC / Classroom Force-Multiplier
43 slides · ← Back to Day 4 · Download .pptx
Day 4 — AI as SOC / Classroom Force-Multiplier
Hands-On SecAI+ · Working Connections 2026 · Thu, Jul 23 · 9:30 AM – 5:30 PM Central
- Domain focus: D3 — AI-Assisted Security (24% of the SecAI+ exam)
- By lunch: you've built a real MCP server and driven it from a local tool-calling model
- By end of day: AI-generated Sigma and Suricata detections that pass static validation, and an AI-assisted CVE triage over real data
Speaker notes
Frame the flip: for three days we secured AI systems; today AI joins OUR side of the SOC. Emphasize the through-line from Day 1 — human-in-the-loop is not a nicety today, it's the load-bearing control. Everything still runs locally and offline, same posture as all week.
How this deck works (30-second refresher)
- Advance with the buttons or the Left / Right arrow keys (Space also advances)
- Checks-for-understanding appear inline — pick an answer, then reveal
- Slides link straight into today's lab when it's time to go hands-on
- This deck is a DRAFT for instructor review
Speaker notes
Same mechanics as Days 1–3 — 30 seconds, tops. Remind instructors the speaker-notes toggle exists if they're reusing this deck in their own classrooms.
Today's objectives
- Implement an MCP server (2025-11-25 spec) for log triage and CVE summarization using the Python mcp SDK
- Use an AI coding agent (generate → statically validate → repair loop) to produce Sigma and Suricata detection rules
- Evaluate generated rules against static validators (sigma-cli, suricata -T self-test) without live packet capture
- Conduct AI-assisted vulnerability triage on a bundled CVE dataset (no live NVD — avoids hallucinated CVSS)
- Identify when to escalate from local model to hosted API based on task complexity and hardware constraints
Speaker notes
These map 1:1 to the objectives block on the Day 4 page and to SecAI+ domain D3 — at 24%, the second-heaviest domain on the exam. Three builds today: the MCP server, the detection loop, the triage pipeline. Note the network-rule wording: the lab validates Suricata rules (Snort-family syntax) with suricata -T.
The lens flips today
- Days 1–3: AI as the thing being SECURED — vocabulary, attack surface, guardrails, data protection, governance
- Day 4: AI as the thing doing security WORK — triage, detections, prioritization
- Same stack, same models, same offline posture — new job description
- The controls you built this week still apply: today's AI systems need them too
Speaker notes
A nice symmetry to say out loud: the AI SOC assistant you build today is itself an AI deployment — it has a context to protect (Day 3), an injection surface (Day 2), and a governance story (Day 3 afternoon). Defenders who build AI tooling wear both hats at once.
Where AI actually helps the SOC
AI helps most where analysts drown in volume and repetition:
- TRIAGING alerts — separating signal from noise at scale
- SUMMARIZING logs — compressing thousands of lines into a readable narrative
- DRAFTING detections — skilled, repetitive rule-writing work
- PRIORITIZING vulnerabilities — more CVEs than anyone can patch at once
Speaker notes
Anchor on the pain the room already knows: alert fatigue and CVE backlogs. The pattern in all four is the same — high volume, repetitive structure, expensive human attention. That's the sweet spot for a draft-generating model. Ask who has an alert queue they've given up on; every SOC hand goes up.
The durable pattern: AI drafts, human decides
- Every generated artifact — a detection rule, a triage call, an incident summary — is a PROPOSAL
- A validator checks it, then an ANALYST confirms it, before anything is trusted
- Human-in-the-loop is non-negotiable today, not a checkbox
- This discipline is what separates a force-multiplier from an automation liability
Speaker notes
This is the thesis slide of the whole day — everything that follows is an instance of it. Day 1 introduced human-in-the-loop as a principle; today it becomes the operating procedure. If a generated Sigma rule went straight to production, you'd have automated your own blind spots at machine speed.
Force-multiplier vs. automation liability
- Force-multiplier: AI produces drafts fast; humans spend their attention on judgment, not typing
- Automation liability: unvalidated AI output flows into production controls unreviewed
- The difference is not the model — it's the pipeline AROUND the model
- Today's pipeline: generate → statically validate → repair → human review
Speaker notes
Drive home that the same model in two different pipelines is either an asset or a hazard. The generate-validate-repair loop is the day's central artifact — attendees build it twice (Sigma, Suricata) and reuse its logic for triage. Preview: we'll also see the same loop in the attacker's hands at the end of the day.
Check: the operating discipline
Check for understanding
Your model generates a Sigma detection rule for an incident. According to today's operating pattern, what is that rule?
- A.A production-ready detection you should deploy immediately
- B.A draft/proposal that must pass static validation and human review before anyone trusts it
- C.A guaranteed-correct rule, because the model was given real log data
- D.Useless output — generated rules can never be used
Reveal answer
Correct: B. A draft/proposal that must pass static validation and human review before anyone trusts it
Generated artifacts are drafts. A static validator (sigma check) catches syntax/structure errors, a repair loop fixes them, and a human analyst confirms the result before deployment. AI drafts, human decides — that discipline is what makes AI a force-multiplier instead of an automation liability.
Speaker notes
Set the frame before the tooling: if the room internalizes 'draft, not decision' now, every later slide lands correctly. Option D is worth addressing too — the answer isn't to reject generated rules, it's to gate them.
The integration problem
- A model is only as useful as what it can REACH: logs, CVE data, ticketing, enrichment
- The old way: bespoke glue code for every model-to-tool integration
- N models × M tools = N×M custom integrations, each a maintenance and security liability
- What's needed: one standard interface between the LLM and external capabilities
Speaker notes
Motivate MCP with the pain, not the acronym. Everyone who has written API glue knows the N×M problem — it's the same story that gave us ODBC for databases and LSP for editors. The security angle: every bespoke integration is another place credentials and data handling get reinvented, usually badly.
Model Context Protocol (MCP)
- An OPEN PROTOCOL that standardizes how an AI application connects a model to external TOOLS, DATA, and CONTEXT
- Instead of per-integration glue, a model speaks one protocol to any MCP server
- A common interface between the LLM and capabilities like triage_logs() and lookup_cve()
- Exam framing: MCP standardizes the CONNECTION, not the model, its training, or its pricing
Speaker notes
This definition is exam material — the end-of-day quiz asks exactly what MCP standardizes, and the distractors are training, encryption at rest, and API pricing. The one-liner to repeat: MCP is to AI tools what a common driver interface is to databases.
Spec discipline: MCP is versioned by date
- The lab targets the stable 2025-11-25 MCP specification
- MCP releases are dated — cite the dated spec, the way you cite OWASP editions and NIST versions
- We use the Python mcp SDK — FastMCP for the server side
- Same habit as Day 2 and Day 3: name the framework AND the edition
Speaker notes
Continue the week-long epistemic-hygiene habit: 'MCP' without a date is as underspecified as 'the OWASP Top 10' without an edition. The protocol is young and moving; pinning the spec version is the same reproducibility posture as our digest-pinned images.
Anatomy of an MCP server
- A server EXPOSES tools — each with a name, a description, and a typed parameter schema
- The schema is what the model reads to decide WHICH tool to call and WITH WHAT arguments
- In the lab: FastMCP from the Python mcp SDK — a decorated Python function becomes a tool
- The server runs as its own service in our stack, next to Ollama and the runner
Speaker notes
Keep this concrete: in mcp_server.py a plain Python function plus a FastMCP decorator IS the tool — the SDK derives the schema the model sees. Good tool descriptions matter enormously: the model chooses tools by reading them, so a vague description produces vague tool choices.
Our two SOC tools
- triage_logs(logs) — rule-based log classification: offline, deterministic
- lookup_cve(cve_id) — CVE lookup from the BUNDLED dataset (no live NVD)
- Both return ground truth the model cannot invent
- Small on purpose: two tools is exactly the reliability envelope of today's 3B model
Speaker notes
Point out the design choice in triage_logs: it's rule-based and deterministic, NOT another model call. Tools should be the trustworthy, auditable half of the partnership — the model reasons, the tool provides facts. lookup_cve reading bundled data previews the afternoon's triage exercise and the no-live-NVD rule.
The tool-call round-trip
The heart of agentic security tooling, in five steps:
- 1. A natural-language task goes to qwen2.5:3b along with the tool schemas
- 2. The model returns a structured tool_call — the tool name plus JSON arguments
- 3. The RUNNER executes that call against the MCP server
- 4. The tool result is fed back to the model
- 5. The model produces a GROUNDED final answer
Speaker notes
Walk this slowly — it's the mental model for every agent framework attendees will ever meet. The key beat is step 3: the model never executes anything. It emits a structured request; deterministic code carries it out. mcp_demo.py prints every step of this round-trip so the room can watch it happen.
The model reasons, the tool provides ground truth
- The model NEVER runs the tool — it emits a structured request; the runner executes it
- That separation is a security boundary: you control exactly what a tool_call can do
- Tool results ground the model's answer in real data instead of recall
- Model reasons + tool provides ground truth = the heart of agentic security tooling
Speaker notes
Two payoffs to name. Security: because execution lives in your runner, least privilege and auditing attach to the tool layer, not to model weights. Accuracy: a grounded answer cites what the tool returned — the antidote to hallucination, which returns as the main theme of the CVE triage block.
Check: what MCP standardizes
Check for understanding
The Model Context Protocol (MCP) is used in today's lab to connect a model to security tools. What does MCP standardize?
- A.The way a model is trained on new data
- B.How AI applications connect models to external tools, data sources, and context in a consistent way
- C.The encryption of data at rest
- D.The pricing of hosted AI APIs
Reveal answer
Correct: B. How AI applications connect models to external tools, data sources, and context in a consistent way
MCP is an open protocol (the lab targets the 2025-11-25 spec) that standardizes how an application exposes tools and context to a model — a common interface between the LLM and external capabilities like triage_logs() and lookup_cve(). It replaces one-off, per-integration glue.
Speaker notes
Mirrors the end-of-day quiz. If anyone picks A, revisit the definition slide — MCP touches nothing about training. The wrong options are all real topics from earlier days (training, encryption at rest), which is what makes them plausible distractors.
Why today's model is qwen2.5:3b
- Days 1–3 ran qwen2.5:1.5b — fine for chat, summaries, and demos
- Tool-calling demands WELL-FORMED JSON arguments matching a schema, every time
- Very small models (0.5–1.5B) frequently emit malformed tool_call args
- qwen2.5:3b reliably produces valid tool-call schemas for 1–2 tools — the smallest model that does the job
Speaker notes
This is the concrete, memorable example of matching model capability to task complexity. It's not that 3B is 'smarter' in a vague way — it's that one specific capability (schema-faithful JSON emission) has a size threshold, and tool-calling lives above it. The quiz asks this exact question.
Right-sizing: a judgment, not a reflex
- The lesson is NOT 'bigger is better' — it's 'match the model to the task'
- 1.5B was the right size for three days of work; 3B is the right size for tool-calling
- Over-provisioning wastes latency, memory, and (hosted) money; under-provisioning fails silently with malformed output
- Escalate model size when a specific capability demands it — and be able to NAME that capability
Speaker notes
Generalize before moving on: 'name the capability that forces the escalation' is the discipline. For Day 4 the capability is reliable tool-call JSON. Later today the same judgment recurs at a bigger scale — local SLM vs. hosted API — with data sensitivity added to the trade-off.
Check: why the bigger model
Check for understanding
The lab uses qwen2.5:3b for Day 4 instead of the qwen2.5:1.5b model used earlier in the week. What is the reason?
- A.The 3B model is cheaper to run
- B.Reliable tool-calling: sub-2B models tend to emit malformed JSON in tool-call arguments, while the 3B model produces valid tool-call schemas
- C.The 1.5B model cannot generate any text
- D.Larger models are always required for every task
Reveal answer
Correct: B. Reliable tool-calling: sub-2B models tend to emit malformed JSON in tool-call arguments, while the 3B model produces valid tool-call schemas
Tool-calling demands well-formed JSON arguments. Very small models (0.5–1.5B) frequently produce malformed tool_call args; qwen2.5:3b reliably emits valid schemas for 1–2 tools. This is the 'escalate model size to task complexity' judgment — right-size, don't over-provision.
Speaker notes
Mirrors the end-of-day quiz. Option D is the misconception to squash hard — the previous slide exists so nobody walks out thinking 'always use the biggest model.' The 1.5B model did three productive days of work; it just can't do THIS.
Lab, part 1: the MCP round-trip
Time to build it. Head to the Day 4 lab and run the first exercise.
- mcp_demo.py — the full tool-call round-trip against your MCP server
- Watch qwen2.5:3b read the tool schemas, emit a structured tool_call, and get grounded results back
- mcp_server.py is the FastMCP server exposing triage_logs and lookup_cve — read it; it's shorter than you think
- Offline as always: the model is pre-staged; ollama_client.py raises a hard error rather than pulling
Speaker notes
Send everyone to the Day 4 page lab section (button below). Nudge attendees to actually open mcp_server.py — seeing that a decorated Python function IS an MCP tool demystifies the whole protocol. Note the 3B model was pre-staged in pre-stage.sh; nothing downloads at demo time (ADR-5).
Detection engineering: the next AI target
- Writing detection rules is SKILLED, REPETITIVE work — exactly the profile where AI drafts help
- Skilled: you need the log source, the field names, the attack behavior, and the rule format
- Repetitive: the hundredth brute-force rule looks a lot like the first
- The catch: a plausible-looking rule that doesn't parse — or doesn't fire — is worse than no rule
Speaker notes
Transition from 'AI calls tools' to 'AI writes artifacts.' The catch bullet is the setup for the whole block: plausible-but-wrong is the signature LLM failure mode, and detection rules fail SILENTLY — a broken rule just never fires. That's why validation is structural, not optional.
Two rule formats today
- SIGMA — the generic, YAML-based signature format for LOG events; write once, convert to your SIEM's query language
- SURICATA — NETWORK detection rules in the Snort-family syntax
- One describes what to find in logs; the other, what to find on the wire
- Both have static validators we can run offline — which is what makes today's loop possible
Speaker notes
Keep the taxonomy simple: Sigma for logs, Suricata for network. The 'static validators exist' point is load-bearing — the generate-validate-repair loop only works for artifact types you can check mechanically. Mention that Suricata rules use the Snort-family rule syntax, so the skill transfers across that ecosystem.
The generate → validate → repair loop
- GENERATE — the model writes a Sigma YAML rule from an incident description
- VALIDATE — sigma check (sigma-cli) statically validates structure and syntax, offline; for network rules, suricata -T syntax-checks the rule
- REPAIR — validation failures feed back into a repair prompt (up to two attempts)
- Output: a syntactically-valid DRAFT rule — which a human still reviews before it touches production
Speaker notes
The day's central pipeline. Walk the loop on the slide, then note what each stage contributes: generation gives speed, validation gives correctness-of-form, the human gives correctness-of-intent. A rule can be perfectly valid YAML and still detect the wrong thing — that last gap is why review never disappears.
Why the validate step is essential
- LLMs produce PLAUSIBLE-BUT-INVALID rules: wrong field, malformed YAML, invented syntax
- A static validator catches structure/syntax errors mechanically — no human time spent on typos
- Failures become repair-prompt input: the error message is exactly the feedback the model needs
- The loop turns unreliable generation into reviewable, syntactically-valid output
Speaker notes
This is quiz material stated plainly. The elegant part to highlight: validator error messages are machine-generated, specific, and textual — ideal repair-prompt content. You're closing the loop with the compiler, the same trick every AI coding agent uses. Cap of two repair attempts keeps the lab bounded; persistent failures escalate to the human.
Check: the validate step
Check for understanding
The lab generates Sigma detection rules with an LLM and runs a 'generate → validate → repair' loop. Why is the validate step essential?
- A.It makes the rule run faster in production
- B.LLMs can produce plausible-but-invalid rules; a static validator (sigma-cli) catches syntax/structure errors so the model can repair them before a human trusts the rule
- C.It encrypts the rule
- D.It is optional and only used for logging
Reveal answer
Correct: B. LLMs can produce plausible-but-invalid rules; a static validator (sigma-cli) catches syntax/structure errors so the model can repair them before a human trusts the rule
Generated rules are drafts. Running sigma check (and suricata -T for Suricata rules) statically validates them offline; failures feed back into a repair prompt. The loop turns unreliable generation into reviewable, syntactically-valid output — always confirmed by a human before deployment.
Speaker notes
Mirrors the end-of-day quiz. If the room is solid here, the day's core lesson has landed. Option D deserves a beat: in this pipeline validation is the gate, not telemetry — nothing proceeds without it.
Static validation only — a deliberate boundary
- sigma check: parses and validates rule structure — no SIEM required
- suricata -T: a configuration/rule self-test — NEVER live packet capture
- No live SIEM, no live traffic: the lab stays offline and REPRODUCIBLE
- Static validation proves the rule is well-formed; behavioral testing against real telemetry is the next step in a real pipeline — out of scope today
Speaker notes
Be explicit about what static validation does NOT prove: a valid rule can still miss the behavior or false-positive wildly. In production you'd follow with detection tests against sample telemetry. We stop at static validation deliberately — it keeps the lab offline (ADR-5), deterministic, and runnable on every laptop identically.
The incident scenarios
Three classic incidents drive the generation exercises:
- SSH BRUTE FORCE — repeated authentication failures from a single source
- WEB-SHELL UPLOAD — suspicious file drop onto a web server
- ENCODED POWERSHELL — the obfuscated-command classic
Speaker notes
Chosen because every SOC recognizes them and each maps cleanly to a log-visible behavior — good first targets for generated Sigma. Encourage attendees to compare the model's field choices against what they'd write by hand; the deltas are where the human-review conversation gets interesting.
Lab, part 2: generate, validate, repair
Back to the lab for the detection-engineering exercise.
- sigma_demo.py — the full loop: qwen2.5:3b drafts Sigma rules for the three incidents, sigma check validates, failures trigger repair
- Then the network side: a Suricata rule, syntax-checked with suricata -T
- Watch the repair prompts — the validator's error text goes straight back to the model
- Final artifacts are DRAFTS: read them like a reviewer, not a customer
Speaker notes
Send the room back to the Day 4 lab section. Have them keep one eye on the repair iterations — watching a malformed rule get fixed by its own error message is the day's best demo of the loop working. Wrap with a two-minute human review of one generated rule as a group.
The CVE problem: more than you can patch
- Every org faces more CVEs than it can remediate at once — prioritization IS the job
- Raw CVSS alone doesn't decide: exposure, asset criticality, and YOUR environment matter
- Triage is repetitive, structured reading at volume — the AI-assist profile again
- The model's role: draft a prioritization with rationale; the analyst's role: confirm it
Speaker notes
Same shape as detections: volume plus structure equals a good drafting target. Note the framing shift from 'find vulnerabilities' to 'order the work' — the model isn't scanning anything, it's helping a human sequence remediation. And per the day's thesis, the output is a proposal.
Grounded, not recalled
- The lab loads 12 real 2024 CVEs from a BUNDLED dataset — no live NVD query
- Two reasons, both from the course's offline rules (ADR-5): no runtime internet fetch, and grounding on TRUSTED data
- Asked from memory, models HALLUCINATE CVSS scores and CVE details with total confidence
- Feeding authoritative data means the scores in the output are real, not plausible
Speaker notes
The hallucinated-CVSS failure is worth dramatizing: ask the room how they'd catch a confidently wrong 9.8-vs-6.5 in a wall of triage output. You wouldn't — which is why the design forbids recall and requires grounding. Same principle as the MCP round-trip: the tool/data provides ground truth, the model reasons over it.
The triage output
- Each CVE gets a label: PATCH IMMEDIATELY / PATCH THIS WEEK / MONITOR
- Plus a one-line rationale referencing YOUR org profile — exposure and asset context, not just the score
- The org profile is what turns a generic severity list into a prioritization
- And once more: the labels are DRAFTS for an analyst to confirm
Speaker notes
The org profile is the interesting input: the same CVE list triages differently for a hospital than a web startup, and the rationale line is where the model shows its work. Reviewing rationales is faster than doing triage from scratch — that's the force-multiplication, measured in analyst minutes.
Check: why the bundled dataset
Check for understanding
In the AI-assisted CVE triage exercise, why does the lab use a bundled CVE dataset instead of querying the live NVD API?
- A.The NVD API is too expensive
- B.To keep the lab fully offline AND to prevent the model from hallucinating inaccurate CVSS scores — the bundled data has authoritative scores
- C.Because CVEs change every second
- D.There is no technical reason
Reveal answer
Correct: B. To keep the lab fully offline AND to prevent the model from hallucinating inaccurate CVSS scores — the bundled data has authoritative scores
Two reasons align with the course's offline design (ADR-5): no runtime internet fetch, and grounding triage on a trusted dataset so CVSS scores are accurate rather than hallucinated. The model prioritizes (Patch Now / This Week / Monitor) using real data plus your org profile.
Speaker notes
Mirrors the end-of-day quiz. The 'AND' in the correct answer matters — offline discipline and anti-hallucination grounding are two distinct benefits that happen to share one design choice. Both should be nameable separately by now.
Lab, part 3: AI-assisted CVE triage
Last build of the day.
- cve_triage.py — qwen2.5:3b prioritizes the 12 bundled 2024 CVEs against the org profile
- Output: Patch Immediately / Patch This Week / Monitor, each with a one-line rationale
- Your job is the ANALYST seat: agree or overrule each call, out loud
- Notice what grounding buys you — every CVSS score in the output is from the dataset, not the model's memory
Speaker notes
Send the room to the Day 4 lab section one more time. The analyst-seat exercise is the point: pick two or three triage calls and debate them — especially any where the org profile should have changed the label. Disagreement with the model, articulated well, is the skill being trained.
Go deeper: three focused Day-4 mini-labs
Three more bundles on the Day 4 page — each hardens one idea from today.
- day4-detection-eng — a deeper generate → validate → repair pipeline: more incidents, sigma-cli compile plus suricata -T, still zero live capture
- day4-mcp-soc-tool — extend the MCP server: design and add a NEW SOC tool of your own with FastMCP
- day4-ai-triage-ir — AI-assisted triage plus an IR runbook over a bundled CVE/alert dataset (no live NVD)
Speaker notes
Position these as catch-up / go-deeper modules for fast finishers and after-hours work — each is self-contained with its own bundle. Pairings: detection-eng extends the loop, mcp-soc-tool turns MCP consumers into MCP authors, and ai-triage-ir adds the incident-response half of triage. All lab content is DRAFT for instructor review.
From loop to pipeline: CI/CD and agents
- Generate-validate-repair generalizes: an AI AGENT proposes a change (a rule, a script, a config)
- Automated validators gate it; a HUMAN approves the merge
- In CI/CD terms: the validator is your test suite, the human review is the required approval
- The same guardrails you'd demand of ANY automated contributor
Speaker notes
Zoom out from the day's lab to the industry pattern: an AI agent in a pipeline is just an untrusted contributor with superhuman typing speed. Everything the room already knows about protecting a repo — required checks, protected branches, review gates — transfers directly. The novelty is the contributor, not the controls.
Agent hygiene: least privilege + audit trail
- LEAST PRIVILEGE for the agent — it can touch only what its task requires. Non-negotiable
- An AUDIT TRAIL of everything it proposed and everything that ran. Non-negotiable
- Familiar? These are the same controls Days 2–3 applied to AI systems — now applied to AI workers
- An over-privileged agent with no logs is Shadow AI you built yourself
Speaker notes
Close the loop with the week: the gateway/least-privilege thinking from Day 2 and the audit-logging discipline from Day 3 apply verbatim to agents. The Shadow-AI callback usually gets a laugh and lands the point — a well-meaning ungoverned agent is indistinguishable from the thing Day 3 warned about.
Right-sizing, round two: local vs. hosted
- Today's micro-version: 1.5B → 3B because tool-calling demanded it
- The macro-version: escalate from a local SLM to a HOSTED API only when the task demands it — harder reasoning, larger context
- AND only when the data-sensitivity / compliance posture allows sending data off-box
- The trade-off surface: cost, privacy, latency, capability, compliance
Speaker notes
Same judgment at two scales. The capability question ('what does this task actually require?') meets the governance question ('may this data leave the box?') — and BOTH must pass before escalating to hosted. This trade-off is the subject of the Day 5 roundtable, so plant the five factors now.
The flip side: AI-enabled attack vectors
The same power cuts both ways. Defenders must now anticipate AI-enabled offense:
- DEEPFAKES and VOICE CLONING — synthetic audio/video for fraud and social engineering; identity verification must adapt
- AUTOMATED, PERSONALIZED PHISHING at scale — the cost of convincing lures collapses
- AI-ACCELERATED TOOLING — faster reconnaissance, exploit drafting, and evasion
Speaker notes
Deliberately placed after a day of building AI-assisted defense: nothing you built today is defender-exclusive. The deepfake/voice-clone item hits hardest — helpdesk identity verification built on 'recognize the voice' is already obsolete. This is also quiz material: distinguish AI-ENABLED vectors from ordinary security failures.
Check: AI-enabled offense
Check for understanding
Which of the following is an example of an AI-ENABLED attack vector that defenders must now anticipate?
- A.A misconfigured firewall rule
- B.Deepfake audio/video and voice-cloning used for social-engineering and fraud
- C.A physically stolen laptop
- D.An expired TLS certificate
Reveal answer
Correct: B. Deepfake audio/video and voice-cloning used for social-engineering and fraud
AI lowers the cost of convincing deepfakes, voice cloning, personalized phishing, and automated attack tooling. These are AI-enabled offensive capabilities — the flip side of AI-assisted defense — and change the threat model for identity verification and social engineering.
Speaker notes
Mirrors the end-of-day quiz. The wrong options are all real security problems — the discriminator is whether AI is what ENABLES the vector. That precision (AI-enabled vs. merely security-relevant) is exactly what the exam item tests.
Symmetry of capability
- Every AI-assisted defense you built today has an offensive mirror
- Assume adversaries use the same generate-validate-repair loops you do
- Design detection and identity controls accordingly — the bar for 'convincing' has moved
- Your edge isn't the model — it's ground truth, validation discipline, and the human in the loop
Speaker notes
End the threat block on the actionable asymmetry: attackers and defenders share the models, but defenders own the ground truth (their logs, their telemetry, their environment) and the validation pipeline. That's where the durable advantage lives — not in model access.
The classroom is a SOC too
- Everything today transfers to teaching: AI drafts course materials, quiz items, lab variations — the INSTRUCTOR decides
- Same pipeline: generate → validate (does it compile? is it correct?) → human review before students see it
- Same grounding rule: feed the model YOUR syllabus and materials rather than trusting recall
- And a sanctioned, local stack like this week's is the Day-3 answer to classroom Shadow AI
Speaker notes
For the educator half of the room — this workshop's audience — make the mapping explicit: force-multiplier means reclaiming prep time, not outsourcing judgment. A hallucinated quiz answer is the classroom's hallucinated CVSS score. The Day 3 Shadow-AI callback matters here too: students are already using unsanctioned AI; a governed alternative beats prohibition.
Day 4 wrap-up
- You built an MCP server (2025-11-25 spec, Python mcp SDK) and drove the full tool-call round-trip with qwen2.5:3b
- You ran generate → validate → repair to produce Sigma and Suricata rules, validated offline with sigma check and suricata -T
- You triaged 12 real CVEs from a bundled dataset — grounded data, no hallucinated CVSS
- And you kept the human in the loop at every step — drafts in, decisions out
Speaker notes
Recap against the morning's objectives — all five covered, including right-sizing (1.5B→3B, local→hosted). One-sentence takeaway: AI multiplies the analyst who validates and decides; it endangers the one who doesn't. Ask each attendee which of the three builds they'd deploy first at work.
Before you leave + what's next
- Take the end-of-day quiz on the Day 4 page (self-check, no score recorded)
- Fast finishers: the three go-deeper bundles (detection-eng, mcp-soc-tool, ai-triage-ir) are on the Day 4 page
- Tomorrow: Day 5 — the week in review, the local-vs-hosted roundtable, and the SecAI+ workshop exam
Speaker notes
Point to the quiz block at the bottom of /day/4 — it mirrors this deck's checks. Tease Day 5: the review session pulls the whole week together before the exam, and the roundtable picks up today's local-vs-hosted trade-off (cost, privacy, latency, capability, compliance). Encourage a skim of the Day 1–4 quizzes tonight.