cve-dashboard/docs/security-posture-workflow.md

Security Posture Workflow — Host Finding Review & Remediation

Document Type: Process Guide Applies To: STEAM Security Dashboard — All Pages Audience: NTS-AEO-STEAM / NTS-AEO-ACCESS-ENG team members Last Updated: 2026-03-27

---

Table of Contents

1. Overview
2. Dashboard Orientation
3. Vulnerability Designations
4. The Host Finding Review Workflow
   • Step 1 — Sync and Sort by Due Date
   • Step 2 — Identify the Host
   • Step 3 — Identify Asset Ownership
   • Step 4 — Review the CVEs in the Finding
   • Step 5 — Determine and Execute the Required Action
5. Using the Ivanti Queue
6. Workflow Status Reference
7. Quick Reference Card

---

1. Overview

The STEAM Security Dashboard centralises vulnerability management for the NTS-AEO-STEAM and NTS-AEO-ACCESS-ENG business units. It pulls host findings directly from Ivanti/RiskSense and gives the team a single place to triage, track, and action every open vulnerability.

Scope: This document covers severity findings in the 8.5 – 9.9 VRR range. All findings in this range require some form of documented action. A finding that is not actioned before its Due Date results in the device being recorded as non-compliant.

SLA Rule: By default, all vulnerabilities must have an action taken or in-flight within 60 days of detection. The Due Date column on the Reporting page shows the exact deadline. Metrics and compliance reporting are based on vulnerabilities aged under 60 days.

---

2. Dashboard Orientation

Pages

Page	Purpose
Home (CVE Management)	Track and research individual CVEs across vendors. Store supporting documentation. Log Archer EXC ticket numbers against CVE/vendor pairs.
Reporting (Host Findings)	The primary operational page. Live view of all open Ivanti findings with filtering, sorting, inline editing, the Ivanti Queue, and export.
Knowledge Base	Internal document library — policies, runbooks, vendor advisories.
Exports	Bulk export tools for reports and data extracts.

Reporting Page — At a Glance

When you open the Reporting page for the first time in a session, click Sync (top right) to pull the latest findings from Ivanti. The page shows:

• Four metric charts at the top — Open vs Closed, Action Coverage, FP Finding Status, FP Workflow Status
• Findings table below — every open finding for the configured BUs, one row per host finding
• Ivanti Queue panel (click the Queue button, top right) — your personal staging list for batch-processing FP and Archer workflows

The charts and table update together. Clicking a chart segment filters the table to that subset.

---

3. Vulnerability Designations

Every finding in the 8.5–9.9 range requires one of three documented actions. Understanding these upfront makes triage faster.

3.1 Remediation

The vulnerability is addressed by fixing the root cause.

Remediation Method	Archer Ticket Required?	Notes
Firmware or software update	No	Upgrading removes the vulnerability entirely. The finding will fall off the report on the next scan.
Configuration change	Yes	A config change does not remove the vulnerability — if the config is ever rolled back, the vulnerability returns. An Archer Risk Acceptance ticket is required to document this.

3.2 False Positive (FP)

A false positive occurs when the scanner detects a vulnerability that is not actually present or does not apply to the platform or software version in use.

An FP workflow must be opened in Ivanti. The workflow requires:

1. A screenshot taken directly from the device showing:

   • Hostname
   • IP address
   • Software / firmware version

   Important: This must be a screenshot. CLI text output or copy-pasted command output is not accepted.

2. Vendor documentation confirming the vulnerability does not affect the platform — one of:

   • Direct vendor communication (email, support ticket)
   • Published security advisory stating the version or platform is not affected
   • Proof that the vulnerability does not apply to the currently installed version

Supporting files (screenshots, emails, advisories) should be saved into the CVE Database (Home page → upload documents against the relevant CVE/vendor pair) for future reference and re-use if the FP expires and needs to be renewed.

3.3 Risk Acceptance / Archer Request

An Archer Risk Acceptance ticket (EXC-XXXXX) is required when a vulnerability cannot be patched for a documented business or technical reason. Common scenarios:

Scenario	Required Action
Patch not yet available (waiting on vendor)	Open Archer ticket; close it when patch is deployed
Device is End-of-Sale (EOS) or End-of-Life (EOL)	Archer ticket required with mitigation steps and a remediation plan
Business constraint prevents patching	Archer ticket with justification and compensating controls
Configuration-change-only remediation	Archer ticket required (see Remediation above)

For EOL/EOS devices the ticket must include:

• Current mitigation steps (network segmentation, compensating controls)
• A remediation plan — what will replace or retire the device and when

If vendor communication is needed (patch timeline, configuration guidance), open a vendor support ticket and use the vendor's response to fill out the Archer remediation plan field.

Archer EXC numbers are tracked in the dashboard. Once entered on the Home page against the relevant CVE/vendor pair, the EXC badge appears on that CVE row. Clicking the badge navigates to the Reporting page pre-filtered to findings with that EXC number in their notes.

---

4. The Host Finding Review Workflow

Work through the Reporting page top-to-bottom by Due Date. The goal of each session is to ensure every finding either has an action in-flight or gets one started.

---

Step 1 — Sync and Sort by Due Date

1. Navigate to the Reporting page.
2. Click Sync (top right). Wait for the sync to complete — the timestamp updates when done.
3. Click the Due Date column header to sort ascending (soonest due date first).
   • Red due dates = overdue
   • Amber due dates = due within 30 days
   • Start with red, then amber

If you want to focus on findings with no action yet, click the Pending segment on the Action Coverage donut chart. The table will filter to only findings with no FP ticket and no EXC number in notes.

---

Step 2 — Identify the Host

Each finding row includes a Host (hostname), IP Address, and DNS column.

1. Use the reported IP address to verify the hostname in:

   • IPControl (read-only, historical IPAM data)
   • Infoblox (current IPAM — preferred for current state)

2. If the hostname shown in the dashboard is incorrect (Ivanti sometimes reports stale data):

   • Click the Host cell in the finding row — it is inline editable.
   • Type the correct hostname and press Enter or click away to save.
   • An amber dot (●) will appear on the cell to indicate an override is in place. The original Ivanti value is preserved and can be restored using the revert button (↻).
   • The same applies to the DNS column.

Overrides survive Ivanti re-syncs — your corrections are not overwritten when new data is pulled.

---

Step 3 — Identify Asset Ownership

Check the BU column to determine ownership.

BU Value	Ownership	Action
NTS-AEO-STEAM	Our team	Continue to Step 4
NTS-AEO-ACCESS-ENG	Our team	Continue to Step 4
Any other value, or blank	Not our asset	Add to CARD queue (see below)

If the asset is not owned by our BU:

1. Check the checkbox at the left of the finding row.
2. A popover will appear. The CARD workflow type should already be selected.
   • No vendor entry is required for CARD — the IP address is captured automatically for use when searching in CARD.
3. Click Add to Queue.
4. The finding is now staged in your Ivanti Queue under the CARD section.

CARD queue items are processed in a separate session — see the Ivanti Queue section and the dedicated CARD process documentation.

---

Step 4 — Review the CVEs in the Finding

Each finding has one or more CVEs listed in the CVEs column (up to 2 shown; hover the "+N" badge to see the rest).

For each CVE in the finding:

1. Check if the CVE already exists in the database.

   • Navigate to the Home page.
   • Search for the CVE ID in the search bar.
   • If an entry exists for this CVE and vendor, review what's already documented — there may be existing notes, documents, or an Archer ticket already linked.

2. If no entry exists, create one:

   • Click Add CVE on the Home page.
   • Enter the CVE ID — the NVD auto-fill will populate the description, CVSS severity, and published date automatically.
   • Select the correct vendor/platform.
   • Save the entry.

3. Research the CVE to determine the required action:

   • Check the vendor's security advisory portal (e.g., Juniper Security Advisories, Cisco Security Advisories / Bug Search Tool)
   • Determine whether the CVE: (a) is a False Positive for this platform/version, (b) can be Remediated, or (c) requires a Risk Acceptance

---

Step 5 — Determine and Execute the Required Action

Based on your research in Step 4, choose the path below.

---

Path A — Remediation (Firmware or Software Update)

No Archer ticket required if the fix is a firmware or software upgrade.

1. Plan and schedule the upgrade with the relevant team.
2. No dashboard action is required beyond ensuring a note is added to the finding (click the Notes cell) confirming the upgrade is planned or complete.
3. After the device is upgraded, the finding will fall off the Reporting page on the next Ivanti scan if the vulnerability is no longer detected.

---

Path B — Remediation (Configuration Change)

An Archer Risk Acceptance ticket is required when the fix is a configuration change.

1. Check the checkbox at the left of the finding row.
2. In the popover, enter the Vendor / Platform (e.g., Juniper, Cisco, ADTRAN).
3. Select Archer as the workflow type.
4. Click Add to Queue.
5. Process the Archer ticket in a dedicated session — see Ivanti Queue and the Archer process documentation.

---

Path C — False Positive

1. Collect the required evidence:

   • Log into the device and take a screenshot showing the hostname, IP address, and software/firmware version.
   • Obtain vendor documentation confirming the CVE does not affect this platform or version (security advisory, vendor email, etc.).

2. Save supporting files to the database:

   • Go to the Home page and find (or create) the CVE entry for this vendor.
   • Upload the screenshot as type screenshot and the vendor communication as type advisory or email.
   • This ensures the evidence is accessible when the FP expires and needs to be renewed.

3. Stage the finding in the queue:

   • Check the checkbox at the left of the finding row on the Reporting page.
   • Enter the Vendor / Platform.
   • Select FP as the workflow type.
   • Click Add to Queue.

4. Open the False Positive workflow in Ivanti:

   • Process queued FP items in a dedicated session.
   • See the dedicated FP workflow documentation for the full Ivanti submission steps.

---

Path D — Risk Acceptance (Archer Ticket)

1. Collect information as you would for a False Positive (device screenshot, version info).
2. If vendor communication is required (patch timeline, EOL statement, recommended mitigations):
   • Open a vendor support ticket requesting remediation steps, configuration guidance, or a patch commitment date.
   • Use the vendor's response to fill out the Archer remediation plan.
3. Stage the finding in the queue:
   • Check the checkbox on the finding row.
   • Enter the Vendor / Platform.
   • Select Archer as the workflow type.
   • Click Add to Queue.
4. Open the Archer Risk Acceptance ticket:
   • Process queued Archer items in a dedicated session.
   • See the dedicated Archer process documentation for the full submission steps.
5. Once the EXC number is assigned, enter it in the finding's Notes cell on the Reporting page (format: EXC-XXXXX). The dashboard will recognise the pattern and include it in the Action Coverage chart under "Archer Exception".

---

5. Using the Ivanti Queue

The Ivanti Queue is a personal staging list built into the Reporting page. Rather than interrupting your review to context-switch into Ivanti, you tag findings as you go and then batch-process all the Ivanti work in one focused session.

Adding Items to the Queue

1. On the Reporting page, check the checkbox at the far left of any finding row.
2. A popover appears anchored to the row.
3. For FP and Archer items: enter the Vendor / Platform (free text — e.g., "Juniper MX", "Cisco IOS-XE").
4. Select the workflow type:
   • FP — False Positive request to be submitted in Ivanti
   • Archer — Archer Risk Acceptance ticket to be opened
   • CARD — Asset not owned by our BU; IP address is captured automatically
5. Click Add to Queue. The row checkbox turns solid blue to indicate it is queued.

Opening the Queue Panel

Click the Queue button in the top-right of the Reporting page. A slide-out panel opens from the right showing all your queued items.

• CARD items appear at the top of the panel in their own green section, with the IP address displayed for easy CARD search.
• FP and Archer items are grouped alphabetically by vendor/platform below.
• Each item shows: Finding ID, CVEs (or IP for CARD), and the workflow type badge (amber = FP, sky = Archer, green = CARD).

Working the Queue

Marking items complete: Once you have submitted the FP or Archer ticket in Ivanti (or actioned the CARD item), check the item's green checkbox to mark it complete. Completed items are shown with a strikethrough at reduced opacity.

Deleting items:

• Click the trash icon on an individual item to remove it.
• To remove multiple items at once: check the small red selection checkbox on the left of each item you want to remove, then click Delete (N) in the footer.

Clearing completed items: Click Clear Completed in the footer to remove all marked-complete items at once.

Queue items are stored in the database and are personal to your login — they persist across sessions and page refreshes. Other team members see only their own queue.

---

6. Workflow Status Reference

The Workflow column on the Reporting page tracks FP# tickets — False Positive requests submitted in Ivanti. The badge shows the ticket ID and its current state, colour-coded by urgency.

SYS# workflows are auto-generated system tracking records. They are not displayed and do not require team action.

Status Colour Codes

🔴 Red — Act Immediately

State	Meaning	Required Action
Expired	An FP# ticket existed but the exception window has lapsed. The finding has re-opened.	Log into Ivanti and submit a new FP request for this finding. Reference the previous ticket if relevant.
Rejected	The security team reviewed the FP and denied it. The finding is a confirmed, exploitable vulnerability.	Remediate the vulnerability. Apply the relevant patch, configuration change, or compensating control. Do not resubmit an FP without new evidence.

🟡 Amber — Action Required Soon

State	Meaning	Required Action
Reworked	The FP request was challenged by the reviewer and returned for revision.	Open the ticket in Ivanti, review the feedback, update the justification, and resubmit.
Actionable	The FP ticket has been flagged as needing team action.	Open the ticket in Ivanti and respond to what is required.

🔵 Blue — In Flight, Monitor

State	Meaning	Required Action
Requested	An FP# ticket has been submitted and is awaiting security team approval.	No immediate action. Monitor for approval or rejection. If the SLA window is approaching with no response, follow up with the approver.

— (No Badge) — Untriaged

State	Meaning	Required Action
No workflow badge	No FP ticket has ever been submitted for this finding.	Triage the finding using the workflow in Section 4. Determine whether to remediate, submit an FP, or open an Archer ticket.

Decision Flowchart

Finding appears in Reporting page
│
├── Check the Workflow column
│
├── No badge (—)
│   └── Triage → follow Section 4 workflow
│
└── Has a badge → check the colour:
    │
    ├── 🔵 BLUE (Requested)
    │   └── Monitor. Follow up if SLA window is approaching.
    │
    ├── 🟡 AMBER (Reworked / Actionable)
    │   └── Open Ivanti ticket → review feedback → update → resubmit
    │
    └── 🔴 RED
        │
        ├── Expired → Submit a new FP request in Ivanti
        │
        └── Rejected → Remediate the vulnerability

---

7. Quick Reference Card

Action Decision Matrix

Research Outcome	Config Change?	Action Required
Can be patched (firmware/software)	N/A	Upgrade device — no ticket needed
Can be patched (configuration change only)	Yes	Archer Risk Acceptance ticket (EXC-XXXXX)
False Positive — not applicable to platform/version	N/A	FP workflow in Ivanti + evidence in CVE database
Cannot be patched — patch pending from vendor	N/A	Archer Risk Acceptance ticket (renew when patched)
Cannot be patched — EOL/EOS device	N/A	Archer ticket with mitigation steps + remediation plan
Asset not owned by our BU	N/A	CARD queue → CARD asset disposition process

Workflow Badge Quick Reference

Badge	State	One-Line Action
🔴 Red	Expired	Renew FP request in Ivanti
🔴 Red	Rejected	Remediate the vulnerability
🟡 Amber	Reworked	Update and resubmit FP ticket
🟡 Amber	Actionable	Review ticket in Ivanti and respond
🔵 Blue	Requested	Monitor — no action yet
—	No badge	Triage: follow Section 4

Dashboard Shortcut Reference

Task	How
See only untriaged findings	Click Pending segment on Action Coverage chart
See findings due this week	Click a date on the Home page calendar widget
See all findings for a specific Archer ticket	Click the EXC badge on the Home page CVE row
Correct a wrong hostname	Click the Host cell inline on the Reporting page
Save a screenshot or advisory to a CVE	Home page → CVE row → Upload document
Stage findings for a batch FP/Archer session	Use the Ivanti Queue (checkbox column on Reporting page)
Filter to a specific vendor or SLA status	Click the filter icon (⊙) on the relevant column header

---

Related documentation: FP Workflow Submission (Ivanti) · Archer Risk Acceptance Process · CARD Asset Disposition Process · MOP: Workflow Status Colour Codes