Vulnerability Response -Sys Properties Explanation

[ZbigniewBednare]

Hello,

I'm looking for additional information about following 3 properties:
1. sn_sec_cmn.filterOutDecommissionedCI

My understanding is that if we have this property enabled, ServiceNow will not mach an vulnerability to retired CI, instead it will create new in Unclassed Hardware Class. If we disable this option then it will try to match an vulnerability to the retired CI. Is that correct ?
If above is correct and we had in the past this option set to true so system created many unmatched entries and created CIs in Unclassed Hardware Class , what is the best practice to get rid of these Cis ?

2. sn_sec_cmn.ignoreCIClass
This property defines which CI classes to ignore when running Security Operations CMDB CI lookup rules. What does it mean exactly ? Does it mean that during CMDB CI Lookup rules some classes can be ignored for matching process ?
IF for example I will add to this property cmdb_ci_lb_list, it will not try to find a much between vulnerability and CIs from this class, but my understanding is that "thanks" to this option system will create new CIs in Uncassed Hardware class and we will have Unmatched set at the end ? Is this is correct ?

3. sn_sec_cmn.autoPromoteFields
Can you provide me with detailed information what is it for and in which situation we should adjust this property ?

Thank you,

Zbigniew

[andy_ojha]

Hey there - your observations are correct.

Unfortunately, that property, if turned on - will be bound to all of the CI Lookup Rules and there isn't an easy way to shim it selectively onto specific rules.

------------------------------------------------------------------------

Curious - what observations have you seen in your environment?

Do you have scenarios, where a potential host is seen by your scanner, and the corresponding CI, has:
- x1 entry in CMDB -> retired
- x2 entries in CMDB -> one retired, one operational

If you need to turn that property off, you can add to the GlideRecord query in your existing CI Lookup Rules 

 - Operational Status or CSDM Lifecycle field 
 - SortBy, explicit "is / match", etc.

[ZbigniewBednare]

Hello,

In my situation we have 1 operational CIs + 1 -2 retired Cis.

I will try going the way you described above. Thank you so much 🙂

Best regards,

Zbigniew

[ZbigniewBednare]

Hello @andy_ojha 

We ended up with following script that working fine for matching between DNS (Qualys) and Hostname (servicenow CMDB):

// _queryMatch function checks if the query returns 0, 1 or more than 1 CI.

// it returns:

//    null: if no CI found

//    ci record: if a unique CI was found

//    the first CI record found: if more than 1 CI was found and log a duplicate error message

//    To avoid specific CI classes ,add the class names, comma separated, to the property sn_sec_cmn.ignoreCIClass

(function process(rule, sourceValue, sourcePayload) {

    var sourceField = {};

    var ignore = global.SecProperty.getProperty("sn_sec_cmn.ignoreCIClass", "");

    sourceField[rule.source_field] = sourceValue;

    var hostname = sourceValue.split('.')[0];

    var cmdbci = new GlideRecord("cmdb_ci");

    cmdbci.addQuery("name", hostname);

    if (!gs.nil(ignore))

        cmdbci.addQuery('sys_class_name','NOT IN', ignore);

    cmdbci.query();

    cmdbci = _queryMatch(cmdbci, rule, sourceValue);

    if (cmdbci)

        return cmdbci.getUniqueValue();

    return null;

})(rule, sourceValue, sourcePayload);

It picks up both type of CIs - Retired and Not retired based on the SortBy that you described above.

I tried adding cmdbci.orderByDesc('install_status')and also cmdbci.orderBy('install_status') but it looks like it does not work as expected.

I thought that if we add this we can force system to check first for non-operation, operation statues etc ... and at the end if no match is found to pick up Retired one.

Any clue if we can use such options ?Do you have any ideas how to adjust script mentioned above so we can pick non retired CIs at the first step and next in case of missing such Cis, the system will pick the Retired up ?

We also tried this script - but looks like system does not like it and jump to another lookup rule so no match is found at all:

(function process(rule, sourceValue, sourcePayload) {
    gs.log("Debug: Starting rule processing for sourceValue: " + sourceValue); // Log initial input
    var sourceField = {};
    var ignore = global.SecProperty.getProperty("sn_sec_cmn.ignoreCIClass", "");
    sourceField[rule.source_field] = sourceValue;

    var hostname = sourceValue.split('.')[0];
    gs.log("Debug: Extracted hostname: " + hostname); // Log extracted hostname

    var cmdbci = new GlideRecord("cmdb_ci");
    cmdbci.addQuery("name", hostname);
    if (!gs.nil(ignore)) {
        cmdbci.addQuery('sys_class_name', 'NOT IN', ignore);
    }
    cmdbci.query();

    if (cmdbci.hasNext()) {
        gs.log("Debug: Found matching CI for hostname."); // Log if a match is found
        var cmdbci = _queryMatch(cmdbci, rule, sourceValue);  // Adjusted to use the query result directly
        if (cmdbci) {
            gs.log("Debug: Matched CI sys_id: " + cmdbci.getUniqueValue()); // Log the sys_id of the matched CI
            return cmdbci.getUniqueValue();
        }
    } else {
        gs.log("Debug: No existing CI matched for hostname: " + hostname); // Log if no match is found
    }

    return null;  // Optionally create a new CI or return null
})(rule, sourceValue, sourcePayload);

Thank you in advance,

Zbigniew

[andy_ojha]

Hey there - Sorry about that...

Appears our old trick is no longer compatible 😞

What's happening now, is when the system detects multiple CIs are candidates for a match (even with our OrderBy) --> it is overriding that...

• You can also see this reflected on the Discovered Item, on the field "Other Matched CIs"
  The Script Include "CIIdentify" and function "logDupWhileIdentifying" are controlling this behavior
• In the logs, you'll see something like
  • "Found duplicate CI while identifying rule 'Custom Test Retired ' 15100d22c3738210c8c37e2a05013190 source values={"DNS":"server1234.test.org"} deciding to return this CI 'a57b6fc31b158150cbd142e8b04bcb77'"

----------------------------------------------------

To treat the scenario you mentioned - we could look at two paths

1) In the Lookup Rule itself, perform two lookups 
    a) Happy-path -> try to find non-retired first and return those values
    b) Fallback and return any value we find 

2) Split our Lookup Rules apart - which can be useful for troubleshooting and tuning 
   - On the Discovered Items you could see which CI Lookup Rules won on each record 
   - Retired Rules vs Non-Retired Rules, etc.

cmdbci.addEncodedQuery("operational_status!=6"); // Not Retired 

Example:

// _queryMatch function checks if the query returns 0, 1 or more than 1 CI.
// it returns:
//    null: if no CI found
//    ci record: if a unique CI was found
//    the first CI record found: if more than 1 CI was found and log a duplicate error message
//    To avoid specific CI classes ,add the class names, comma separated, to the property sn_sec_cmn.ignoreCIClass

(function process(rule, sourceValue, sourcePayload) {
    var sourceField = {};
    var ignore = global.SecProperty.getProperty("sn_sec_cmn.ignoreCIClass", "");
    sourceField[rule.source_field] = sourceValue;

    gs.info('VR Log - Incoming Host for testing: ' + sourceValue);

    var hostname = sourceValue.split(".")[0];

    gs.info('VR Log - Parsed host: ' + hostname);

	// *** ACTIVE CI SEARCH ***
    var cmdbci = new GlideRecord("cmdb_ci");
    cmdbci.addQuery("name", hostname);
    if (!gs.nil(ignore))
        cmdbci.addQuery('sys_class_name', 'NOT IN', ignore);
    //cmdbci.orderBy("operational_status"); //Ascending -> Retired = 6, Operational = 1
	cmdbci.addEncodedQuery("operational_status!=6"); // Not Retired 
    cmdbci.query();

    cmdbci = _queryMatch(cmdbci, rule, sourceField);

    if (cmdbci)
        return cmdbci.getUniqueValue();

    return null;

})(rule, sourceValue, sourcePayload);

[ZbigniewBednare]

Hello @andy_ojha 

Thank you for your reply and solution. It looks to be working fine :')

At the end Im going to use two rules:
1. Rule which will be queering All Not Retired Cis - if no match found then

2. Rule which will be queering All Cis including also Retired Cis.

Thank you for your script , all hints as they helped me to develop final solution. Really appreciate that 🙂

Best regards,

Zbigniew