Scenarios explained · for the demo

FOR YOUR UNDERSTANDING

1Start here — what's a "scenario" and why do we have them?

You're running a demo, not a production deployment. In a real CSX environment, vulnerabilities arrive on their own schedule — a Microsoft Patch Tuesday on the second Tuesday of the month, a vendor advisory whenever Cisco or Siemens decides to publish one, a CISA KEV uplift whenever an exploit goes wild.

You can't wait for that schedule in a demo. So we built scenarios — buttons that simulate a real-world security event happening right now, so you can show the platform reacting to it on screen.

SAY: "Each scenario simulates a real-world security event — Microsoft dropping Patch Tuesday, a Cisco zero-day disclosure, a Siemens OT advisory. Click one and the platform behaves as if that event just happened in your environment. You see the agents pick it up, enrich the findings, plan the fixes, and route them through policy — all on screen, in real time."

How the "simulate" mechanism works under the hood

  1. You click "Run" on a scenario card in Command Center.
  2. The simulator persists an Advisory — a database row that represents the vendor's security bulletin (Microsoft Security Update Guide entry, Cisco PSIRT advisory, Siemens ProductCERT advisory, etc.).
  3. The simulator picks affected assets from your inventory — by vendor + product match. For example, if the advisory is "Siemens RUGGEDCOM RX1500 SSH bypass," it queries all assets with vendor="Siemens" and product="RUGGEDCOM RX1500".
  4. For each affected asset, a Finding (Vulnerability row) is created with the CVE, the asset reference, the source scanner that "saw" it, and a starting status of DISCOVERED.
  5. The Supervisor agent drives each Finding through the 12-agent pipeline: Threat Intel enriches, Patch Hunter resolves vendor URL, Impact Analyst joins CMDB, Change Risk scores, Safety Officer reviews for OT, Remediation Planner builds the plan, Policy gate routes to approval queue or auto-apply.
  6. You see the result on screen as new plans appear in /plans and as agent messages stream in /activity.
The key idea: "Simulate" doesn't mean fake. The agents are real Python code making real database transactions and emitting real audit records. The only thing that's "simulated" is the trigger — the event that would normally come from a scanner alert is injected by clicking a button instead.

2Glossary — the words you'll see

CVE
Common Vulnerabilities and Exposures. A globally unique identifier (e.g. CVE-2023-20198) assigned to each vulnerability when it's catalogued. MITRE Corporation maintains the list. Every CVE has a record at nvd.nist.gov/vuln/detail/CVE-XXXX-XXXXX.
PSIRT
Product Security Incident Response Team. The vendor's internal team that publishes security advisories for their products. Microsoft has MSRC, Cisco has Cisco PSIRT, Siemens has Siemens ProductCERT, Red Hat has Red Hat Product Security. They publish bulletins like "MS17-010" or "cisco-sa-iosxe-webui-privesc-j22SaA4z" or "SSA-573348" — these are the IDs you see in the plan detail.
Advisory
The vendor's security bulletin — the document that says "here's the vulnerability, here's the affected version range, here's the fix." In Mythal it's a database row with fields like source, vendor, product, version_range, fix_version, references. When you "Run" a scenario, the first thing it does is create one of these rows.
Finding (also "Vulnerability" row in DB)
The instance of a vulnerability on a specific asset. "CVE-2023-20198 on switch mcr-net-ios-xe-0006" is a finding. An advisory says "this vulnerability exists" — a finding says "and it's on THIS specific machine." One advisory can produce many findings (the same CVE shows up on dozens of switches).
Plan (RemediationPlan)
The platform's response to a finding. It contains the ordered fix steps, the tool that runs each step, the rollback path, the approval scope required, the maintenance window. Plans go through a lifecycle: PLANNED → AWAITING_APPROVAL → APPROVED → EXECUTING → VERIFIED → CLOSED.
Persist
"Save to the database." When you see _persist_advisory in the code or hear "the simulator persists the advisory," it just means we wrote it to the Advisory table so the rest of the platform can find it.
Drive (drive_finding)
The action of taking a finding through the agent pipeline. "Driven through agents" = handed to the Supervisor, which dispatches it to each specialist in turn.

3About Qualys and "QIDs vs CVEs" — you asked about this

You're right that Qualys doesn't speak CVE directly in their internal data model. They use QIDs (Qualys Identifiers). Here's the relationship:

LayerIdentifierExample
UniversalCVECVE-2023-20198
QualysQIDQID 92121
TenablePlugin IDplugin 182168
Rapid7vulnerability IDcisco-ios-xe-cve-2023-20198
MicrosoftKB numberKB4013389
Microsoft bulletinMS-prefixMS17-010
Cisco PSIRTcisco-sa- prefixcisco-sa-iosxe-webui-privesc-j22SaA4z
Siemens ProductCERTSSA- prefixSSA-573348

Every QID in Qualys is mapped to one or more CVEs in the QID metadata. Mythal's Scanner Liaison agent reads the QID + CVE list from Qualys, normalizes everything to the CVE-level so the rest of the platform speaks one canonical language, and stores the QID alongside as a back-reference so we can round-trip back to Qualys if needed.

What this means for the demo

SAY (if asked): "You're right — Qualys speaks QID, Tenable speaks plugin ID, Defender speaks recommendation ID. Mythal's Scanner Liaison agent does the mapping. Every QID Qualys reports comes with the CVEs it covers, and we normalize to CVE-level so the rest of the platform speaks one canonical language. The original QID is preserved as a back-reference for round-trip lookups."

4Scenario A — Patch Tuesday at 06:00

A
Patch Tuesday at 06:00
Microsoft just released their monthly batch — 60 new CVEs hit your scanners

What it simulates

The second Tuesday of every month, Microsoft (and others) release their security patches. Sixty (or more) new CVEs land in your scanner overnight. Your security team walks in Tuesday morning to a wall of red findings.

What happens in code when you click Run

  1. The simulator generates 60 advisories — real CVE IDs drawn from a pool of well-known CISA KEV entries (CVE-2024-21412, CVE-2023-29336, CVE-2021-44228, etc.), biased 65% to Microsoft + 35% to Cisco/Palo Alto/Red Hat/Siemens.
  2. Each advisory gets persisted (saved to the Advisory table).
  3. For each advisory, the simulator picks an affected asset matching the vendor — Windows hosts for Microsoft, Linux for Red Hat, Cisco switches for Cisco, etc.
  4. A Finding is created linking the asset to the CVE.
  5. Supervisor drives each through the agent loop — enrichment, patch lookup, planning.
  6. Patch Hunter resolves the real vendor advisory URL (msrc.microsoft.com, sec.cloudapps.cisco.com, security.paloaltonetworks.com).
  7. Each plan gets routed by the policy gate to auto-apply / single approval / dual approval based on asset criticality and patch reliability.

Where to point on screen — exact URLs

1. Live activity: /activity — point at messages streaming in. Each row is one agent talking to another. "You see Scanner Liaison → Threat Intel → Patch Hunter happening in real time. 60 findings, each going through every agent, all in seconds."
2. New plans: /plans — refresh. You'll see 60 new plans appear, mostly in "Awaiting" tab. "60 new plans created. The policy gate routed them — some auto-applied because they were low-risk Windows updates, most went to the approval queue for a human to sign off."
3. Drill into one: Click any plan row. "Real CVE — CVE-2024-21412. Real Microsoft bulletin. Real msrc.microsoft.com URL. The Patch Hunter resolved it."
4. Findings list: /findings — sort by "Seen" descending. The newest 60 are right at the top.
SAY: "This is the wave that hits every security team on Patch Tuesday morning. 60–180 new findings. In a typical environment your team spends the week triaging. Watch what Mythal did in the time it took me to say one sentence — every finding has been enriched, mapped to the right vendor patch, and routed by policy. A human only sees what their judgment is actually needed for."

5Scenario B — Cisco IOS-XE Web UI vulnerability

B
Cisco IOS-XE Web UI privilege escalation
A real critical Cisco zero-day from 2023 — CVE-2023-20198 — hits your Cisco switches

What it simulates

In October 2023, Cisco disclosed an authentication-bypass vulnerability in the IOS-XE Web UI. Within days, researchers had identified tens of thousands of compromised Cisco devices on the internet. The patch was available the day of disclosure — but operators who couldn't apply it fast enough got compromised. This is a real, named, well-documented event.

What happens in code when you click Run

  1. The simulator persists the real Cisco PSIRT advisory cisco-sa-iosxe-webui-privesc-j22SaA4z with CVE CVE-2023-20198, severity Critical, fix version 17.9.4a.
  2. Queries the asset inventory for Cisco IOS-XE switches — finds 17 in the MCR estate (mcr-net-ios-xe-0001 through 0017).
  3. Creates 17 findings — same CVE, 17 different switches.
  4. Each finding driven through agents.
  5. Patch Hunter resolves the real Cisco PSIRT advisory URL: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z

Where to point on screen

1. Plans page: /plans — type "Cisco" in search box. 17 new plans for IOS-XE.
2. Click any one: Plan detail opens. The green "Vendor patch located ✓" card has the real Cisco SA bulletin. "This is the real one. Click the URL."
3. CLICK THE CISCO URL IN FRONT OF CSX — opens Cisco's actual security advisory page in a new tab. "Real Cisco page. Real CVE record. Not a mockup." This is the most powerful moment — it proves Mythal isn't fabricating data.
SAY: "This is a real vulnerability from 2023. CVE-2023-20198. Within days of disclosure, attackers had compromised tens of thousands of Cisco devices on the internet. The patch was available the day of disclosure. The delta between availability and application is what got people compromised. That's the asymmetry Mythal closes."

6Scenario C — Siemens RTU at Substation 14 (the OT veto)

C
Siemens RUGGEDCOM / SIMATIC vulnerability — operational systems
Real Siemens advisory (SSA-573348, CVE-2022-41358) — Safety Officer in action

What it simulates

A real Siemens ProductCERT advisory for an industrial control system class vulnerability. This is the kind of finding that would normally cause a CSX OT engineer's blood to chill — a vulnerability on equipment that affects substation operations, where you cannot reboot during operations.

What happens in code when you click Run

  1. Simulator persists the real Siemens advisory SSA-573348 with CVE CVE-2022-41358.
  2. Queries inventory for Siemens RUGGEDCOM assets — typically finds 8 in the substation zone.
  3. Creates findings flagged as OT zone and CCS (Critical Cyber System).
  4. Drives findings through agents — but the Safety Officer agent vetoes direct patching because of the OT/CCS flags.
  5. Remediation Planner builds plans with compensating controls (firewall ACL tightening, IPS signature push, monitored isolation) INSTEAD of direct firmware patching.
  6. The firmware update gets scheduled for the next planned maintenance window with dual approval required.

Where to point on screen

1. Plans page: /plans — click the OT tab. Plans tagged OT and CCS appear.
2. Click any OT plan: Scroll to the amber "Safety Officer review" card. "Verdict: VETO. The agent refused direct patching."
3. Compensating controls card: "Instead of patching — ACL tightening, IPS signature, monitored isolation. Risk reduced NOW. The firmware patch is queued for the next planned maintenance window with both Security and OT Operations required to sign."
SAY: "This is the agent that makes Mythal viable on a railroad. The Safety Officer has veto rights on anything operationally sensitive. It built the plan, deployed compensating controls right now to reduce risk, and handed the firmware update to your operations team to apply on their schedule. A generic vulnerability tool would happily patch a wayside device during operations and stop a train. This one doesn't."

7Scenario D — Ransomware actor adopts a CVE

D
CISA KEV uplift — yesterday's routine finding is today's priority
Threat landscape changed, reprioritization automatic

What it simulates

CISA just added an existing CVE in your environment to the Known Exploited Vulnerabilities (KEV) catalog with ransomware-actor association. Yesterday it was a routine medium finding. Today it's actively being weaponized in the wild. The threat landscape changed without you doing anything.

What happens in code when you click Run

  1. Mythal picks an existing open finding from the database (any non-KEV one).
  2. Flips its kev flag to true.
  3. Flips its ransomware_associated flag to true.
  4. Threat Intel agent records the uplift narrative in the reasoning trace.
  5. Supervisor re-drives the finding through the policy gate — now in the priority lane.

Where to point on screen

1. Live Feeds: /live-feeds — KEV count up by 1.
2. Findings KEV filter: /findings — filter to "KEV only". The newly uplifted finding shows the red KEV + RANSOMWARE badges.
3. Click into it: Reasoning trace shows the threat_intel agent's KEV_UPLIFT note. "This finding wasn't urgent yesterday. Today it is. The platform saw the change, reprioritized automatically, surfaced it where the security team was already looking."
SAY: "This is the asymmetric reality. A finding is routine until suddenly it isn't. CISA adds it to KEV, a ransomware actor adopts it, and now you have hours not weeks. The platform notices the change in the threat landscape, reprioritizes automatically, and tells your team."

8Scenario E — Audit week (TSA evidence package)

E
An auditor is asking for evidence — today
PDF generated in seconds, real auditor-grade content

What it simulates

A TSA inspector or your internal audit team is asking for your evidence package. Today. Without Mythal, the security team spends days assembling tickets, email approvals, and spreadsheets. With Mythal, you click Export.

What happens in code when you click Run

  1. The Compliance Reporter agent queries the compliance_evidence table for all evidence units tagged to TSA SD 1580-21-01.
  2. For each closed plan, it pulls the CVE, asset, approvals, executions, verification result, and reasoning trace excerpt.
  3. Renders all of that into a multi-page auditor-grade PDF (cover, executive summary, control mapping, per-finding detail, methodology, integrity signature).
  4. Returns the byte size in the scenario response.

Where to point on screen

1. After Run, the toast shows "PDF generated · NN KB"
2. /compliance — select TSA SD 1580 → click Export → real 30 KB PDF downloads
3. Open the PDF in front of CSX. Show the cover, the executive summary, the per-finding detail pages. "30 KB. Multi-page. Every closed plan has its own page with the CVE, the asset, the signed approvals, the executor steps, the verifier result. HMAC-signed at the bottom of every page."
SAY: "This is the auditor experience. No assembling spreadsheets from ticket systems. No combing through email chains for approval evidence. Hit export, hand them the PDF. The reasoning trace IS the audit log. The signatures are the proof. This is the side-effect of doing the work properly the first time."

9The narrative arc — run them in this order for maximum impact

OrderScenarioWhat it provesTime
1stB — Cisco IOS-XE"Real CVEs · real vendor URLs · we resolve them"~1 min
2ndA — Patch Tuesday"Volume — 60 findings handled with policy routing"~1 min
3rdC — Siemens OT"We DON'T touch your sensitive systems — Safety Officer veto"~2 min
4thD — KEV uplift"We adapt when the threat changes — automatic reprioritization"~30s
5thE — Audit PDF"Audit is a side-effect, not a project"~30s

Five clicks. Five minutes total. Five proof points. That's your demo.

10What if a scenario shows "0 targets processed"?

What's happening: The scenario's target filter matched assets that already have findings for that CVE (idempotency check). It's not a failure — it just means the seed already covered that case.

If this happens during your demo, recover with this line:

SAY: "Looks like the scenario already populated this case earlier in the seed. Let me show you the findings it generated last time — same effect." Then navigate to /plans and filter to the relevant tab. The plans are still there.

Or just click a different scenario. Scenario A always lands fresh findings because it generates 60 new advisory IDs each time.

11The one-pager — print this for your phone

SCENARIO A — PATCH TUESDAY
60 advisories · 60 plans · most go to approval queue · proves volume + policy routing
Show: /activity (live), /plans (60 new), click one to see the trace.
SCENARIO B — CISCO IOS-XE
Real CVE-2023-20198 · 17 plans · proves real vendor URLs
Show: /plans search "Cisco", click one, click the cisco URL in front of them.
SCENARIO C — SIEMENS OT
Real CVE-2022-41358 · OT veto · compensating controls · proves OT safety model
Show: /plans → OT tab, click a plan, scroll to Safety Officer veto.
SCENARIO D — KEV UPLIFT
An existing finding gets KEV+ransomware flag · proves automatic reprioritization
Show: /findings filter KEV, click into the newly uplifted one, see the trace.
SCENARIO E — AUDIT PDF
Multi-page PDF generated on demand · proves audit is automatic
Show: /compliance → TSA → Export → open the PDF in front of them.
Scenarios explained · Mythal · for the CSX demo
Open the deck: /presentation/client-deck.html · Script: /presentation/demo-script.html