CIS-VR Vulnerability Response Practice Questions

The creation of a Vulnerable Item (VIT) requires both a matched CI and a recognized vulnerability from a third-party source (like NVD). The Discovered Item record holds the raw data from the scanner. If this data lacks a valid identifier (CVE, Nessus ID, etc.) that can be matched to an entry in the Vulnerability [sn_vul_vulnerability] table, ServiceNow cannot create a VIT, even if the CI is successfully matched. The process stops after creating the Discovered Item.

Remediation Target Rules are essentially SLAs for vulnerabilities. They define a time-based target for remediation based on conditions, most commonly the risk rating of the Vulnerable Item. For example, a rule might state that all 'Critical' vulnerabilities must have a target resolution date of 15 days from detection. This target date is then used for reporting and escalation.

When a VIT is marked as a false positive, the system looks for other open VITs that share the exact same combination of Vulnerability, Configuration Item, and Port. This ensures that only identical findings are closed automatically. For example, if CVE-2023-1234 on port 443 of server 'web01' is a false positive, other VITs for the same CVE on the same server and port will also be closed.

The Vulnerable Item [sn_vul_vulnerable_item] table contains each specific instance of a vulnerability on a configuration item. To find the most common vulnerabilities, you would create a report on this table, group the results by the 'Vulnerability' field (which references the CVE), and then sort by the count in descending order to find the top 10.

Container Vulnerability Response extends the CMDB with new classes to accurately model containerized environments. A specific container image (e.g., 'nginx:1.21.1') is stored as a record in the 'Container Image' [cmdb_ci_container_image] table. Vulnerabilities found in that image are then linked to this CI record.

The most effective and scalable solution is to create a new, high-priority CI Lookup Rule. This rule explicitly tells the matching engine how to correlate the data provided by the scanner (FQDN) with the data in the CMDB (name field on the server table). This automates the process correctly for all future imports. Manual reassignment is not scalable. Modifying the base table or the integration itself is more complex and less aligned with best practices than using the built-in lookup rule functionality.

ServiceNow assignment rules are processed in order. The most effective way to handle this is with two separate rules. The first rule (with a lower order number, e.g., 100) should have the condition 'CVSS Score >= 9.0' and assign to 'Tier 3 Security'. The second rule (with a higher order number, e.g., 200) would handle the condition for Oracle DBs in specific locations and assign to 'EMEA DB Admin'. This ensures the high-criticality override is always processed first. Trying to combine this logic into a single rule with complex OR/AND conditions is prone to error and less maintainable.

The correct, out-of-the-box process for deferring a valid vulnerability is to use the Exception Management feature. From the Vulnerable Item (VIT), the user can request an exception, which formally documents the reason for the deferral, any compensating controls, and a requested duration. This request then goes through a formal approval process, providing an audit trail. Marking as a false positive is incorrect because the vulnerability is real. Closing it would remove it from active tracking. Changing the state to 'In Review' is not the final step for deferral.

Application Vulnerability Response (AVR) is the specific ServiceNow module designed to ingest, track, and manage vulnerabilities found in application code by tools like Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) scanners. CVR is for container images, ITOM VR is a broader term, and Configuration Compliance deals with misconfigurations, not code-level vulnerabilities.