Continuous Monitoring (ConMon)¶

Operations guide for the Continuous Monitoring module in the GRC-ITSM platform, covering vulnerability review, deviation requests, alert response, and SLA tracking.

ConMon Sidebar Navigation¶

The ConMon module is accessed from the left sidebar. Key sections:

Vulnerability Review¶

Findings accumulate continuously as scan results arrive; review them on your organization's recurring cadence. Navigate to ConMon > Issues > All Open Issues to see all current findings.

The All Open Issues view displays vulnerability findings with risk ratings, SLA timers, and statuses. Each row is a single finding with the following key columns:

Work through the list reading each finding to determine whether it warrants a deviation or is a real issue that needs remediation.

Triaging Findings¶

Click any finding to open its detail view.

The detail view shows the summary at the top, with tabs for Progress, Related Assets, Issue Details, Issue Dashboard, and POCs. The right panel shows the SLA timer, organization, site, assigned agent, team, category, and mapped Controls, Requirements, and KSIs (including FedRAMP and CMMC control mappings).

The toolbar at the top provides action buttons including Add to Deviation, Note, Private Note, Get AI Analysis, Create Change Request, and Re-Assign.

Triage Decision¶

For each finding, decide:

• False positive (FP) - The vulnerability is not exploitable in this environment (e.g., FIPS configured, component out of scope, mitigating controls in place). Create a deviation request.
• Real issue - The vulnerability is present and exploitable. Escalate for remediation.
• Operational requirement (OR) - The vulnerable component or configuration cannot be removed without breaking the system's operation. Create a deviation request; ORs are often combined with a risk adjustment as OR RA.
• Risk adjustment (RA) - The vulnerability is real but is lower risk based on operational setup, or has been partially mitigated. Create a deviation request with justification.

Creating a Vulnerability Deviation Request¶

When a finding warrants a deviation (FP, OR, RA, or OR RA), create a Vulnerability Deviation for each POAM ID.

Step 1: Create a New Deviation Ticket¶

Navigate to ConMon > Deviations > All Deviations and click + New Ticket in the top right corner. This opens the new deviation form.

Complete the following fields:

ConMon Details (top section)¶

Vulnerability Deviation (middle section)¶

Justification (lower section)¶

Save the ticket once all fields are complete.

Step 2: Review the Deviation¶

Open the saved deviation and review it on the Vulnerability Deviation tab. Confirm the DR Number, POAM ID, Type of DR, CSP-Provided Vulnerability Information, and DR Rationale are all correct before proceeding.

Step 3: Link Issue Tickets to the Deviation¶

1. Navigate back to ConMon > Issues > All Open Issues

2. Use the checkboxes on the left to select all findings that this deviation covers (you can select multiple tickets at once)

   

3. Click the Edit button in the top left to open the dropdown menu with bulk actions

4. Select Link from the menu

   

5. In the Link to another Ticket dialog, search for the deviation ticket you just created, select it, and click Confirm Selection

   

All selected findings are linked as child tickets under the deviation in one action, creating the audit trail.

Step 4: Request Deviation Approval¶

1. Open the deviation ticket
2. Click Request Deviation Approval in the toolbar
3. Set the status to Awaiting Approval and add a note with the action "Request Deviation Approval"

The deviation progresses through the workflow:

New  ►  In Review  ►  Approval  ►  Finalized

These stages map onto the deviation ticket statuses Pending, DR Pending, Awaiting Approval, Approved, DR Approved, Rejected, and Closed. The deviation will appear under Deviations > Pending Deviations until approved or rejected. Approval is by the Deviation Approvers CAB, with an optional organizational stage when your organization has a designated end user with the Deviation Approver role.

Escalating Real Issues¶

Any finding that does not warrant a deviation must be escalated to the engineering team for remediation.

1. Open the finding from All Open Issues
2. Confirm the vulnerability applies to the organization's environment
3. Note the severity, affected assets, and recommended remediation
4. Escalate to engineering with:
   • CVE identifier
   • Affected device count
   • Recommended fix
   • SLA deadline
5. Track remediation progress through ticket status updates

Alerts and Incident Response¶

Security alerts arrive in real time from integrated EDR, ITDR, and security tools, such as Huntress, Microsoft Defender for Endpoint, or other solutions depending on your environment. Navigate to ConMon > Alerts and Incidents > Open Alerts.

Common Alert Examples¶

The specific alerts you see will vary based on which security tools are integrated with your environment. Below are examples from common integrations:

Huntress (EDR / ITDR)¶

• Login without Entra Usage Location - An identity logged in without a configured usage location in Entra ID settings
• Login from unexpected country - A login from an unusual geographic location
• Unexpected VPN - Login through an unexpected VPN provider
• CRITICAL - ISOLATED - A critical threat detected and the endpoint was automatically isolated

Microsoft Defender for Endpoint¶

• Suspicious PowerShell command line - A potentially malicious PowerShell command was executed on an endpoint
• Impossible travel activity - A user account authenticated from two geographically distant locations within an improbable timeframe
• Malware detected and blocked - Defender identified and quarantined a known malware signature

Responding to Alerts¶

1. Acknowledge - Update the alert status from New to In Progress
2. Investigate - Review the login source, device, user account, and related activity. Look into the source of the alert in your EDR/ITDR console (e.g., Huntress, Defender, or other integrated tool) for additional context
3. Determine - Is the activity legitimate (user traveling, authorized VPN) or malicious?
4. Action - Legitimate: document and close. Suspicious/malicious: escalate the alert in place to an Incident (the same ticket converts, keeping its history; no new ticket is opened), follow the IR plan, notify organizational POC
5. Document - Record all actions in the ticket progress notes

SLA Reference¶

Vulnerability Remediation¶

Which remediation model applies depends on the baseline your system is authorized against. Both are configured as Remediation SLA policies and enforced through the platform's SLA tracking.

Alerts¶

Alert SLAs are significantly tighter than vulnerability remediation SLAs and are configurable based on your organization's requirements. The defaults below follow incident response SLA timelines and can be adjusted to match your operational needs and contractual obligations.

Breached SLAs¶

When an SLA is breached:

• SLA Time Left turns red and shows a negative value
• The finding or alert may change to Overdue status