690c30aac0
- Add migration to add hostname column to ivanti_todo_queue table - Update POST and batch POST endpoints to accept and store hostname - Pass hostName from findings data when adding items to queue - Display hostname and IP address in CARD queue section - Display hostname and IP address in vendor (FP/Archer) queue sections
71 lines
5.1 KiB
Markdown
71 lines
5.1 KiB
Markdown
# Requirements Document
|
|
|
|
## Introduction
|
|
|
|
The Ivanti Queue (todo queue) in the STEAM Security Dashboard currently stores and displays `ip_address` for CARD workflow items but omits hostname entirely. Vendor-grouped sections (FP/Archer) display only `finding_id` and CVEs, hiding the `ip_address` that is already stored. This feature adds a `hostname` column to the database, passes hostname through the backend API, and displays both hostname and IP address across all queue sections (CARD, FP, Archer).
|
|
|
|
## Glossary
|
|
|
|
- **Queue_Panel**: The slide-out side panel (`QueuePanel` component) that displays the user's staged Ivanti findings grouped by workflow type and vendor.
|
|
- **Queue_API**: The Express route module (`ivantiTodoQueue.js`) that handles CRUD operations on the `ivanti_todo_queue` table.
|
|
- **Queue_Table**: The SQLite table `ivanti_todo_queue` that persists per-user queue items.
|
|
- **CARD_Section**: The top group in the Queue_Panel that displays items with `workflow_type = 'CARD'`.
|
|
- **Vendor_Section**: Groups in the Queue_Panel for FP and Archer workflow items, organized by vendor name.
|
|
- **Finding**: An Ivanti host finding record containing fields such as `id`, `title`, `hostName`, `ipAddress`, `cves`, and `severity`.
|
|
- **Migration_Script**: A standalone Node.js script in `backend/migrations/` that alters the SQLite schema.
|
|
|
|
## Requirements
|
|
|
|
### Requirement 1: Add hostname column to the queue database table
|
|
|
|
**User Story:** As a developer, I want the queue table to have a `hostname` column, so that hostname data can be persisted alongside each queued finding.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Migration_Script SHALL add a `hostname` TEXT column to the Queue_Table.
|
|
2. WHEN the `hostname` column already exists, THE Migration_Script SHALL skip the alteration and log a message indicating the column already exists.
|
|
3. THE Migration_Script SHALL preserve all existing rows and column data in the Queue_Table.
|
|
|
|
### Requirement 2: Accept and store hostname in queue API endpoints
|
|
|
|
**User Story:** As a developer, I want the queue API to accept a `hostname` field, so that hostname data is stored when findings are added to the queue.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN a POST request is received at the single-item endpoint, THE Queue_API SHALL accept an optional `hostname` string field (max 255 characters) and store it in the Queue_Table.
|
|
2. WHEN a POST request is received at the batch endpoint, THE Queue_API SHALL accept an optional `hostname` string field on each finding object (max 255 characters) and store it in the Queue_Table.
|
|
3. WHEN the `hostname` field is omitted or empty, THE Queue_API SHALL store NULL for the `hostname` column.
|
|
4. WHEN a GET request is received, THE Queue_API SHALL return the `hostname` field for each queue item in the response.
|
|
|
|
### Requirement 3: Pass hostname from the frontend to the queue API
|
|
|
|
**User Story:** As a developer, I want the frontend to send hostname data when adding findings to the queue, so that hostname is captured from the Ivanti findings data.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN a single finding is added to the queue, THE ReportingPage SHALL include the finding's `hostName` value in the `hostname` field of the POST request body.
|
|
2. WHEN findings are added via batch submission, THE ReportingPage SHALL include each finding's `hostName` value in the `hostname` field of the corresponding finding object in the POST request body.
|
|
|
|
### Requirement 4: Display hostname and IP address in the CARD section
|
|
|
|
**User Story:** As a security analyst, I want to see both hostname and IP address for CARD items in the queue, so that I can identify the affected host at a glance.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN a CARD item has a `hostname` value, THE CARD_Section SHALL display the hostname below the finding ID.
|
|
2. WHEN a CARD item has an `ip_address` value, THE CARD_Section SHALL display the IP address below the hostname.
|
|
3. WHEN a CARD item has both `hostname` and `ip_address`, THE CARD_Section SHALL display hostname on one line and IP address on the next line.
|
|
4. WHEN a CARD item has only `ip_address` and no `hostname`, THE CARD_Section SHALL display the IP address (preserving current behavior).
|
|
5. WHEN a CARD item has only `hostname` and no `ip_address`, THE CARD_Section SHALL display the hostname.
|
|
|
|
### Requirement 5: Display hostname and IP address in vendor sections (FP/Archer)
|
|
|
|
**User Story:** As a security analyst, I want to see hostname and IP address for FP and Archer items in the queue, so that I can identify affected hosts without leaving the queue panel.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN a vendor-grouped item has a `hostname` value, THE Vendor_Section SHALL display the hostname below the CVE list.
|
|
2. WHEN a vendor-grouped item has an `ip_address` value, THE Vendor_Section SHALL display the IP address below the hostname (or below the CVE list if no hostname exists).
|
|
3. WHEN a vendor-grouped item has both `hostname` and `ip_address`, THE Vendor_Section SHALL display hostname on one line and IP address on the next line, both below the CVE list.
|
|
4. WHEN a vendor-grouped item has neither `hostname` nor `ip_address`, THE Vendor_Section SHALL display only the finding ID and CVE list (preserving current behavior).
|