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 · Accepted solution]

Hey there - great questions.

1. sn_sec_cmn.filterOutDecommissionedCI

• Correct - there's actually a notable enhancement here - in that it checks the older "Install Status" on potential target CI records, along with the newer CSDM "Life Cycle Stage Status" value 
• If the "Install Status" is <Retired> or the CSDM "Life Cycle Stage Status" is <Retired> on a given CI, it will not be a candidate for the SecOps CI Lookup rules (i.e. it will be skipped)
• Unfortunately, changing the value on it - is not retroactive - it's more point in time 
• There is a Re-Apply function on the SecOps CI Lookup Rules that may help if a retrofit is desired 
• Notable tip:
  • We may see a series of CIs in CMDB that appear to be "Retired" and a duplicate entry that is Not Retired
  • We may also see that some CIs appear as Retired, but are still valid / live on the wire according to our 3rd party vuln scanner 
  • In our CI Lookup Rules, we can shape the matching logic to first attempt to match on "valid CIs" (i.e. not Retired).. then, if no match occurs, attempt to match to any Retired CIs as a fallback.. then, if no match occurs proceed to the creation of the CI (via IRE)
  • This way, you have a fallback path - you still put preference to matching to valid CIs, but before giving up match to a retired CI if it exists - especially handy for higher fidelity attributes like DNS, FQDN, Hostname - not ideal for IP Addr, MAC addr

2. sn_sec_cmn.ignoreCIClass

• You are correct, when a host is brought in from the 3rd party scanner - and the SecOps CI Lookup Rules are invoked to attempt to find a matching CI in the CMDB, we can shape what CI Classes (or tables) we want to exclude matching on
• This may be useful, where our CI Lookup Rules are searching the entire [cmdb_ci] tables and we want to ignore certain CI Classes that may cause incorrect matches 
• E.g. Web Sites, DNS, Certification Classes 
• Notable tip: For Host / Infrastructure VR (e.g. Servers, Computers, Network Gear) 
  • You may want to look at shaping the CI Lookup Rules, to start with searching the Hardware table (and any table that extends hardware) ... i.e. [cmdb_ci_hardware]... 
  • This way, you are not querying the entire [cmdb_ci] table .. and then playing the game of ignoring irrelevant classes
  • Start with the known good subset of CMDB (hardware and extended tables)
    
    
• If a match does not occur - the system doesn't actually directly go and create an Unclassed HW CI record 
  • The payload of the host / asset, is sent to ServiceNow CMDB IRE 
  • Then, IRE has it's own series of Lookup Rules (IRE Identifier Rules) that it runs to attempt to find a CI 
  • If IRE does not find a CI, then it inserts 
  • Only when the VR Scanner provides a Host with IP and another attribute, would it insert into Unclassed HW
  • More details on this available at: https://www.servicenow.com/community/secops-articles/the-more-you-know-secops-and-cmdb-interactions-...
    

3. sn_sec_cmn.autoPromoteFields

• I actually like to refer to this as the "walk-up" property... which results in a "indirect match" to a CI 
• When the SecOps CI Lookup Rules land on a "lower level CI" - such as an IP Address, IP NIC, IP Network Adapter, Virtual Network Adapter
  • Instead of matching to that lower level device, attempt to "walk-up" to it's Parent CI 
  • Think of it as, the vuln scanner is reporting a "Windows vulnerability" .. that does not exist on the NIC or Network Adapter, but rather -- it exists on the actual Windows Server that the CI is connected to 
• The way to setup the property, is to define comma separated values with
  • ["the target lower level CI Class":"the reference field that has the actual CI you should walk-up to"]
  • ["cmdb_ci_nic":"cmdb_ci"]

[ZbigniewBednare]

@andy_ojha 
HI Andy,

Great reply. Thank you very much for all these important information and explanation. Really appreciate that and for sure it was something that I was looking for. I have one additional question to following part:
"sn_sec_cmn.filterOutDecommissionedCI

• In our CI Lookup Rules, we can shape the matching logic to first attempt to match on "valid CIs" (i.e. not Retired).. then, if no match occurs, attempt to match to any Retired CIs as a fallback.. then, if no match occurs proceed to the creation of the CI (via IRE)
• This way, you have a fallback path - you still put preference to matching to valid CIs, but before giving up match to a retired CI if it exists - especially handy for higher fidelity attributes like DNS, FQDN, Hostname - not ideal for IP Addr, MAC addr"

My understanding is that at the end with higher order I should add additional CI Lookup Rules for also Hostname, FQDN, DNS etc but these rules should look a much also for retired Cis. Is that correct ?

Thank you,

ZBigniew

[andy_ojha]

Hey there - thanks!

It would depend on the environment, and what we see when trying to match to target CIs.

These are just some methods / tools that can be employed for the "unhappy scenario"... Where we see that Retired CIs are candidates for matching for a given reason (and to avoid creating new duplicate CIs).

We may see:

• Only a single CI for a given host, but shows as Retired in CMDB
  • This could still be a last resort candidate for matching (a rule towards the end)
  • That way the rules above honor the exclusion of decommissioned CIs - but before we give up, we try one last time and allow for matching to Retired CIs...
    
• Duplicate CIs in the CMDB for a given host, 1 Retired and 1 Operational 
  • Ideally the lower ordered rules would match to the Operational CI (as they run first)

[ZbigniewBednare]

Hello @andy_ojha 

Thank you for your reply. I tried to built a lookup rule as simple as possible to cover the Decommissioned Cis at the end.

I have "sn_sec_cmn.filterOutDecommissionedCI set to true, so in all of the rules I skipping Decommissioned Cis, but as suggested I would like to have last rule with the higher order which will be covering Decommissioned CIs as well - unfortunately I'm not able to make it working (maybe there is some additional logic behind that I'm not aware). I created following script for CI lookup rule:

// _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", "");

    gs.setProperty("sn_sec_cmn.filterOutDecommissionedCI",'false');

    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);

    gs.setProperty("sn_sec_cmn.filterOutDecommissionedCI",'true');

    if (cmdbci)

        return cmdbci.getUniqueValue();

    return null;

    }

)(rule, sourceValue, sourcePayload);

It set the property to false but does not set it back to true and all other rules taking the value of property set to false 😞 Any clue how it should done make it working in correct way ? 

Thank you,

Zbigniew