Can vulnerable items be stopped from being created if they match a certain CMDB class?

[Wei Yau]

When ingesting vulnerabilities into ServiceNow, they are automatically matched to existing CIs in the CMDB using CI Lookup Rules. If the CI Lookup Rules match the vulnerable item with a particular CI, then I don't want the vulnerable item to be created in the first place. Is something like this possible?

For example, if the VIT is ingested and is matched to a CI with class "VMware Network Adapter", then I don't want any of those VITs to be created.

[tkrishna29]

If you want to restrict the vulnerable items, you have to restrict the detections to be created in first place.

To make that happen, you have to make code changes to the out-of-box script include - DetectionBase, _insertDetection method where you create the detection.

Not sure if that is a recommended way to go.

    _insertDetection: function(detection) {
        var gr = new GlideRecord(this.DETECTION_GR);
        gr.initialize();
        gr.setValue('integration_run', this.integrationRun);
        gr.setValue('integration_instance', this.integrationInstance);
        gr.setValue('confirmed', detection.confirmed);
        gr.setValue('port', detection.port);
        gr.setValue('protocol', detection.protocol);
        gr.setValue('ssl', detection.ssl);
        gr.setValue('proof', detection.proof);
        gr.setValue('status', detection.status);
        gr.setValue('first_found', detection.first_found);
        gr.setValue('last_found', detection.last_found);
        gr.setValue('times_found', detection.times_found);
        gr.setValue('ip_address', detection.ip_address);
        gr.setValue('is_disabled', detection.is_disabled);
        gr.setValue('is_ignored', detection.is_ignored);
        gr.setValue('dns', detection.dns);
        gr.setValue('netbios', detection.netbios);
        gr.setValue('solution_summary', detection.solution_summary);
        gr.setValue('vulnerable_item', detection.viSysId);
        gr.setValue('vulnerability', detection.vulnerability);
        gr.setValue('cmdb_ci', detection.cmdb_ci);
        gr.setValue('src_ci', detection.src_ci);
        gr.setValue('source', detection.source);
        gr.setValue('source_status', detection.source_status);
        gr.setValue('source_type', detection.source_type);
        gr.setValue('detection_key', detection.detectionKey);
        if (this.importQueueEntry)
            gr.setValue('import_q_entry', this.importQueueEntry);
        for (i = 0; i < this._customSourceFields.length; i++) {
            var fieldName = this._customSourceFields[i];
            if (gr.isValidField(fieldName) && detection[fieldName])
                gr.setValue(fieldName, detection[fieldName]);
        }
        var detSysID = gr.insert();
        if (detSysID)
            this.inserted.dets++;
        return detSysID;
    },

[Jason_DaSilva]

Sorry to necro post on this, but we are running into a similar issue where our Vulnerable items is too large to manage at this time.  We have scaled back on assignment rules where we are currently only dealing with external facing devices (tagged with =External Facing=).  The rest are still created and are starting to take up a lot of DB space.  We don't want to exclude by class, but instead exclude by tags (in the resource data field of the sn_sec_cmn_src_ci table) if at all possible.  Once we can get the number of VULs down to a more manageable number, they will want to slowly expand what we are pulling in.  Is this still considered the way to go?

[andy_ojha]

Hey there - for controlling the Vulnerable Items that created (putting a limit on it), there are two primary routes.

1) Depending on your 3rd party scanner, filters can be applied to limit what ServiceNow requests from the scanner (at the API request layer) .. e.g. certain asset groups, vulnerabilities with a certain severity, etc.

2) A newer feature called Vulnerability Exclusion Rules, puts a configurable "gate" in front of what Detections actually translate into a Vulnerable Item.

Detections are still brought in from the 3rd party scanner, it's just based on your conditions - you can control if they make it into the Vulnerable Item table (useful when the 3rd party scanner does not have a robust API filtering mechanism or we have very specific needs that the API filtering cannot support)

"If a new detection meets the conditions of an exclusion rule, the rule gets associated with the detection, but VIT is not created."

 - https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/vulnerability-respo...

[Randy Ritzer]

You should first set the classes you don't want to match against, in the system property.  https://docs.servicenow.com/bundle/rome-security-management/page/product/security-operations-common/task/ignore-CI-classes.html 

We had more than a dozen.  It's also worth noting that IP address and Mac generate really bad matching success.  Mac if something passes through a NAT or load balancing/fail over and IP due to DHCP.