Overview:
With the ingestion of many different assets from many different scanners, we may run across the situation where we have items in the “unmanaged” ci class tables of Unclassed hardware [cmdb_ci_unclassed_hardware], Incomplete IP Identified Device [cmdb_ci_incomplete_ip] or Unmatched CI [sn_sec_cmn_unmatched_ci] that have not been scanned in many moons, and no longer are applicable based on an internal policy and/or no longer exist on the network.
Scenario:
Lets say, we as an organization have been utilizing the Vulnerability Response application within ServiceNow for quite some time, and we have grown our unmanaged classes within the CMDB to a large extent. Our intent is to have these table structures “managed”, at least to a point where if they are not scanned within the last 30 days, we can consider they have been taken off-line, or are no longer applicable to our Vulnerability Response process. We want to focus on the active, live, most recently found vulnerabilities tied to those assets which are being scanned so that we can address the highest priority vulnerabilities and not be diluted by old, no longer applicable vulnerabilities tied to assets that have not been scanned in 30 days.
(Ideal scenario is, we'd have these all as real "managed" configuration items, but in some cases, we don't)
Understanding:
Currently, there is not an OOB process, pre-built, to go and find these assets based on last scanned as there would be for a common discovered CMDB item. Through the typical discovery process, we will have a last discovered time, which we could key off of; though with these unmanaged classes, we do not have this luxury, this information is housed on the Discovered item [sn_sec_cmn_src_ci] table, with the Last scanned field being populated with the ingestion from the security scanners.
Solution:
The ideal solution would be to have all CMDB related retirement correlated to one place, and that place would be.. CMDB Data Manager! If you have not heard of the CMDB Data manger, this solution is a policy-driven framework for bulk management of CI life-cycle operations in accordance to CSDM.
The benefit of utilizing this solution to drive the a resolution to our stale, not scanned in many moons assets are as follows:
- Minimal customization / configuration (minor script)
- Able to retire the CI’s directly from Data Manager with pre-built sub flows!
- When retirement transpires, Discovered Items will be changed to “CI Decommissioned”!
- After Decommissioning, VIs will fall in suit and get off the radar of items to be remediated, opening up valuable time and energy to focus on true vulnerabilities!
Few caveats that must be understood before this will work is we need a few properties set to appropriately cascade the closure of the exposures that are tied to that retired/decommissioned CI.
Additionally, we need to make sure we have the property set to appropriately check the CI Lifecycle source for the discovered item to be set to decommission, this is found in this property.
- sn_sec_cmn.ci_lifecycle_status_source
Documentation - Working with retired configuration items
Now, once that is in place, we can set up our Data Manager policy.
For this example, I’m going to target Unclassed Hardware with the Policy type of “Retire”.
Next, I am going to configure my condition of what to target.
This is where some complexity comes into play. If you recall previously I mentioned that we don’t have the last discovered set on the Unclassed hardware record; well, it is set on the Discovered Item. This is where Related list conditions can come into play. One caveat is with the related list condition in the Data Policy filter is, there can be only one.
If we have the scenario where we ONLY have one discovered item (scanned asset) to one CI. Then the related list could work, the reality is, this is most likely not the case... there could be MULTIPLE Discovered items tied to ONE configuration item; so, we will need to account for that.
I’m going to lean back on my good old embedded javascript calling a client callable script include that will be specifically spelt out to return my specified sys_id’s of the CI’s I want to target, then cross reference and make sure they DON’T have a recent last scan discovered item. In this script, I’m making two queries specifically for unclassed hardware, one to find my potentially targeted Cis, the other to validate that they ONLY have the last scan > than my date provided and not another that does not meet the condition. Then, just return the sys_ids.
You can get creative with this part, specific function for unclassed hardware, incomplete ips, ephemeral devices that spin up and spin down rapidly, etc.
Example Script include code below:
var DiscoveredItemDataManagementUtils = Class.create();
DiscoveredItemDataManagementUtils.prototype = Object.extendsObject(AbstractAjaxProcessor, {
//Days to check back
DAYS_AGO: 30,
BASE_QUERY: 'discovery_sourceSTARTSWITHVR',
/**
* unclassedReturn
* @description
* returns subset of sys_ids from cmdb_ci specific to the cmdb_ci_unclassed_hardware table
* where the discovery source starts w/ VR as well as has a tied discovered item to it with the last_scanned
* date before the DAYS_AGO value; it will then check against those specified cis returned if they have a ealier last_scanned
* discovered item tied, if they do, we will remove from our array (since there can be multiple discovered items to a ci)
* @returns {array} sys_ids of specified cis
*/
unclassedReturn: function() {
var ids = [],
uCgr = new GlideRecord('cmdb_ci_unclassed_hardware');
uCgr.initialize();
uCgr.addEncodedQuery(this.BASE_QUERY + '^RLQUERYsn_sec_cmn_src_ci.cmdb_ci,>=1^last_scan_dateRELATIVELT@dayofweek@ago@' + this.DAYS_AGO + '^ENDRLQUERY')
uCgr.query();
while (uCgr.next()) {
ids.push(uCgr.getUniqueValue());
}
uCgr.initialize();
uCgr.addEncodedQuery('sys_idIN' + ids + '^' + this.BASE_QUERY + '^RLQUERYsn_sec_cmn_src_ci.cmdb_ci,>=1^last_scan_dateRELATIVEGT@dayofweek@ago@' + this.DAYS_AGO + '^ENDRLQUERY');
uCgr.query();
while (uCgr.next()) {
var idIndex = ids.indexOf(uCgr.getUniqueValue());
if (idIndex >= 0) {
ids.splice(idIndex, 1);
}
}
return ids;
},
type: 'DiscoveredItemDataManagementUtils'
});NOTE: I'm all about sharing code on the community to help my fellow peoples, but, we need to be aware of what we are utilizing. This code above is an example, a template if you will... please vet this script with the appropriate governance and controls that you as an organization have to make sure you are protecting you and your organization! Adjust to meet your need; tune, refine... test, test, test! Anyway.. lets proceed.
This script then can be called by my Data Manger policy, and on a scheduled basis filter down to my specific Cis.
Refreshing the list, I get my specific CI’s returned.
From there, I go through my additional configuration steps (assignment, subflow, schedule) and then review the setup to make sure all looks correct.
Then I can publish my policy and allow for the schedule to process on its intermediate timing; this runs via the ‘CMDB Data Manager Retire Policy Processor’ scheduled job, it is run daily OOB.
Results:
After the Policy has run, I go back and check my Unclassed records that met the conditions; here below is an example of one that was retired:
We can see that this Lifecyle status was updated to “Retired”, as well as the Discovered Items associated being moved to a state of “CI Decommissioned”.
If we have the appropriate Auto-close rule in place, on a nightly basis a scheduled background job will be triggered, and then close the related detections to those “CI Decommissioned” Discovered Items. Then, the related VIT (if all detections a re closed as CI Decommissioned) will be closed as such as well.
Now, I’ve got all my CI’s retired that should be, Discovered Items moved into a CI Decommissioned state, as well as the related detections and VIs closed in a CI Decommissioned substate, depleting noise and freeing up time to focus on active most recent non-removed asset scans to help reduce my surface exposure.
