Keeping Vulnerability Scanner Data in Sync for Vulnerability Remediation
- Sep 27, 2022
- Guest Author
All Risk-Based Vulnerability Management (RBVM) platforms include integrations to multiple vulnerability assessment products. In addition to vulnerability findings and asset telemetry, the data ingestion from the scanner includes the existence of any exceptions that have been applied to the vulnerability scanner data, typically in the form of a False Positive or Risk Acceptance flag which is a feature found in all vulnerability assessment tools. Though business logic for correlation and de-duplication varies between RBVM platforms, the end result of the data ingestion should be quite similar across them for vulnerability remediation.
One of the main benefits of an RBVM platform is that it can become the central platform for logging and tracking vulnerability exceptions across all vulnerability assessment sources, including network, dynamic code, static code and container scanners. Instead of managing exceptions in each platform individually, doing so in the RBVM platform drastically eases reporting and metrics and allows companies to implement a standard exception request and approval processes across all vulnerability assessment platforms.
While there is substantial value in consolidating vulnerability exception management in the RBVM platform, there is one major challenge that must be accounted for: As exceptions are added to the RBVM, counts of open vulnerabilities and the number of vulnerabilities subject to exceptions will rapidly move out of sync between the vulnerability scanner and RBVM.
Best practice for managing an RBVM platform includes continuously monitoring ingested data for indications that the correlation and de-duplication logic are working as designed. Large unexplained spikes in asset or vulnerability counts should be investigated — typically by reconciling the data being reported by the scanner with the data contained in the RBVM.
As the scanner and RBVM get out of sync, this process becomes more challenging — and for many shops, the volume of exceptions being tracked makes data reconciliation impossible.
One company told us that they spent months trying to reconcile a 750k difference in vulnerability instance counts between their scanner and RBVM that they thought was being caused by this exception sync issue but turned out to be caused by a bug in the reconciliation logic that the exception sync issue was effectively hiding. Needless to say, this episode resulted in lost trust in the metrics, reports and SLA assignments produced by the RBVM and caused additional friction between the Vulnerability Management and IT Ops Remediation teams.
At NopSec, we identified the issues related to scanner exception sync very early on. Working with members of our Customer Advisory Board, we designed a solution that has since been a core feature of all of our scanner integrations — bi-directional syncing.
Multiple times per day, the UVRM platform runs a synchronization job that pushes all exception changes since the last sync back to the vulnerability scanner. This sync includes newly added or removed exceptions, Risk Acceptances that have expired, and even changes in expiration dates. This ensures circular updates won’t occur as any vulnerability record with an exception that was originally logged in UVRM won’t be updated by incoming exception flags from the scanner. As a result of this synchronization, vulnerability counts can be easily reconciled; and, as a result, it is much easier to monitor and resolve data quality issues related to de-duplication and correlation logic.
RBVM platforms all have the ability to push tickets to an ITSM such as ServiceNow or JIRA on an automated basis so that remediation actions can be managed in the same system that the remediation team members manage their other assignments. A ticket typically addresses a single vulnerability and includes remediation information along with a list of assets on which the remediations need to be performed. Unfortunately, many RBVM platforms use a “Fire and Forget” approach to ITSM integration where the tickets are pushed and a ticket ID stored in the database for reference purposes — but with no synchronization afterwards.
The challenge from a management and reporting perspective is that there is no easy way to match the workflow status of the ticket with the status of the individual assets once the remediation process starts.
Once pushed to the ITSM, the vulnerability remediation ticket will be assigned a workflow status that indicates the current stage of the remediation process. Typical statuses would include stages such as Remediation in Progress, Remediation Complete, Exception Requested, Exception Granted, etc. Workflow status changes are manual inputs by the owner of the ticket and can easily get out of sync with the status of the vulnerabilities as reported by the scanner.
NopSec’s bi-directional ITSM integration handles all of the scenarios where the ticket and scanner statuses can get out of sync and will automatically change the status of the ticket under the following scenarios:
As a result of the bi-directional sync, it is much easier to keep the IT OPS teams responsible for remediation in sync with the Vulnerability Management Team’s view of the vulnerability scanner data which minimizes cross functional friction, strengthens data quality, and optimizes the remediation efficiency.
Accurately prioritizing risk around exploitability and criticality is a top objective for cybersecurity leaders. See the other Vulnerability Management trends cybersecurity professionals face with the most recent State of Vulnerability Management report.