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](#1-overview)
2. [Dashboard Orientation](#2-dashboard-orientation)
3. [Vulnerability Designations](#3-vulnerability-designations)
4. [The Host Finding Review Workflow](#4-the-host-finding-review-workflow)
   - [Step 1 — Sync and Sort by Due Date](#step-1--sync-and-sort-by-due-date)
   - [Step 2 — Identify the Host](#step-2--identify-the-host)
   - [Step 3 — Identify Asset Ownership](#step-3--identify-asset-ownership)
   - [Step 4 — Review the CVEs in the Finding](#step-4--review-the-cves-in-the-finding)
   - [Step 5 — Determine and Execute the Required Action](#step-5--determine-and-execute-the-required-action)
5. [Using the Ivanti Queue](#5-using-the-ivanti-queue)
6. [Workflow Status Reference](#6-workflow-status-reference)
7. [Quick Reference Card](#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](#5-using-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](#5-using-the-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*