cve-dashboard/docs/guides/team-training-agenda.md

STEAM Security Dashboard — Team Training Agenda

Session length: 30–40 minutes Format: Live walkthrough (share your screen on the dashboard) Reference docs: security-posture-workflow.md for full detail on anything covered here

---

Pre-meeting prep

• Have the dashboard open and logged in before the meeting starts
• Sync Vulnerability Triage page so data is fresh when you get there
• Print or share security-posture-workflow.md as a take-home reference

---

Segment 1 — Why this tool exists (3 min)

Talking points:

• We have open Ivanti findings in the 8.5–9.9 VRR range — these are the ones we own and are accountable for
• Every finding needs a documented action within 60 days of detection (the SLA rule)
• Findings that age past their Due Date make a device non-compliant in AEO posture reporting
• This dashboard is how we track, triage, and prove we've actioned everything — replaces manual spreadsheet tracking

---

Segment 2 — Dashboard orientation (4 min)

Show on screen: Navigate through each page in the nav drawer

• Home (CVE Management) — our CVE research library; this is where we store screenshots, advisories, and Archer EXC numbers against each CVE/vendor pair
• Vulnerability Triage (Host Findings) — the daily operational page; this is where you spend most of your time
• Compliance — AEO posture data uploaded from the NTS_AEO xlsx; shows metric health per team
• Knowledge Base — internal docs, runbooks, advisories
• Exports — bulk data extracts when needed

Tell the team: "The Vulnerability Triage page is what we'll focus on today — that's where the workflow lives."

---

Segment 3 — The three things you can do with a finding (5 min)

Talking points — before showing the table, set context:

Every finding in our range gets one of three designations:

1. Remediation — you fix the root cause

   • Firmware/software upgrade → no ticket needed, finding drops off on next scan
   • Configuration change → Archer EXC ticket required (if the config is ever rolled back, the vulnerability comes back — the ticket documents that we know)

2. False Positive (FP) — the scanner flagged something that doesn't actually apply to our platform or version

   • Requires an FP workflow opened in Ivanti
   • Evidence requirements: (a) screenshot from the device showing hostname, IP, and SW version — CLI text is not accepted; (b) vendor documentation (advisory, email, support ticket) confirming it doesn't affect us
   • Upload evidence to the CVE database on the Home page so we can reuse it when the FP expires

3. Risk Acceptance (Archer EXC) — we can't patch, for a documented reason

   • Vendor hasn't released a patch yet
   • Device is EOL/EOS — needs mitigation steps + remediation plan in the ticket
   • Business constraint — needs justification and compensating controls
   • Format: enter EXC-XXXXX in the finding's Notes cell after the ticket is created

Tell the team: "Knowing which path you're on before you touch the dashboard makes triage fast. The workflow is just deciding which of these three it is."

---

Segment 4 — The 5-step workflow on the Vulnerability Triage page (15 min)

Show on screen: Vulnerability Triage page, live walkthrough on a real finding

Step 1 — Sync and sort (1 min)

• Click Sync top-right, wait for timestamp to update
• Click Due Date column to sort ascending — reds first, then ambers
• Red = overdue, Amber = due within 30 days — work these first

Step 2 — Identify the host (3 min)

• Use the IP address in the row to verify the hostname in Infoblox (preferred) or IPControl
• If Ivanti has a stale hostname: click the Host cell directly in the table — it's inline editable
• An amber dot appears on overridden cells; original value is preserved and can be restored
• Show the revert button (↻) so they know corrections aren't permanent unless they want them to be

Step 3 — Check who owns the asset (2 min)

• Look at the BU column
• If it's NTS-AEO-STEAM or NTS-AEO-ACCESS-ENG → our team, continue
• Anything else (or blank) → not ours → CARD queue
  • Check the row checkbox, select CARD, click Add to Queue
  • IP address is captured automatically for the CARD search
  • Process CARD items in a separate session

Step 4 — Look up the CVEs (4 min)

• Each row shows up to 2 CVEs; hover the +N badge to see more
• Go to Home page, search for the CVE ID
  • If it exists → review existing notes, docs, and any EXC numbers already linked
  • If not → click Add CVE, enter the CVE ID, NVD auto-fill populates the rest
• Research: vendor advisory portal (Juniper PSN, Cisco Bug Search) — determine if it's an FP, can be patched, or needs an Archer ticket

Step 5 — Take action (5 min)

• Patch available (firmware/SW) — plan the upgrade, add a note to the finding row, done
• Config change only — checkbox → Vendor → select Archer → Add to Queue → process in Ivanti later
• False Positive — collect screenshot + vendor doc, upload to Home page CVE entry, then checkbox → Vendor → select FP → Add to Queue → submit FP in Ivanti in a separate session
• Can't patch (Archer) — same as config change path; once EXC number is issued, paste it into the finding's Notes cell (EXC-XXXXX format)

---

Segment 5 — The Ivanti Queue (5 min)

Show on screen: Click the Queue button, show the panel

• Purpose: tag findings as you triage, then batch all the Ivanti / Archer work in one focused session instead of context-switching constantly
• Three types: FP (amber), Archer (sky blue), CARD (green)
• CARD items show the IP address so you can search directly in CARD
• Check the green checkbox on an item when the Ivanti/Archer action is done
• Multi-select delete: check the small red boxes, click Delete (N) in the footer
• Queue is personal to your login — each person has their own; it persists across sessions

---

Segment 6 — Workflow badge colours (3 min)

Show on screen: Workflow column on the Vulnerability Triage table

Quick rule: red = act now, amber = act soon, blue = monitor, no badge = needs triage

Badge	What it means	What to do
Red — Expired	FP ticket lapsed, finding re-opened	Submit a new FP in Ivanti
Red — Rejected	Security team denied the FP	Remediate — do not resubmit without new evidence
Amber — Reworked	Reviewer returned the ticket	Open in Ivanti, update justification, resubmit
Amber — Actionable	Ticket flagged for team response	Open in Ivanti and respond
Blue — Requested	FP submitted, awaiting approval	Monitor; follow up if SLA is approaching
No badge	Never been triaged	Run it through the 5-step workflow

---

Segment 7 — Quick tips (2 min)

Quick features worth pointing out before Q&A:

• Filter to untriaged only — click the Pending segment on the Action Coverage donut chart
• Find all findings tied to an Archer ticket — click the EXC badge on the Home page CVE row
• Filter by vendor, IP, SLA status — click the filter icon (⊙) on any column header
• Save evidence once, reuse it — uploading screenshots/advisories to the CVE database means when an FP expires you already have the files

---

Segment 8 — Q&A (remaining time)

Suggested prompts to open discussion if no questions come up:

• "Walk me through what you'd do if you saw a red 'Rejected' badge on a finding."
• "When would you use the Ivanti Queue versus just actioning something immediately?"
• "What's the difference between Path B (config change) and Path D (risk acceptance) — when does each apply?"

---

Takeaway for the team

Point them to:

• docs/security-posture-workflow.md — the full process guide with all the steps, evidence requirements, and decision matrix
• docs/security-posture-workflow-diagrams.md — the Mermaid flowcharts if they're visual learners