What to do with vulnerabilities on a CI that has gone to retired?

[cmcclendon]

Scenario A : An active CI has five vulnerabilities.The active CI state changes to Retired.

What is best practice / industry standard for VI's related to CI's? Do we close the VI's?

Scenario B : An active CI has five vulnerabilities. The CI has not been seen by Qualys or Discovery in 30 days.

What is best practice / industry standard for VI's related to CI's? Do we close the VI's?

[maulik_shah]

Yes, if the asset is decommissioned/ retired, you should be closing the vulnerable items. We are building an auto-close feature that will allow you to close based on the asset last scanned or the vulnerability last seen on a CI and plan to release that in June. 

[dmae]

Any chance the auto-close feature will allow filtering such that you can set a different number of days per each scan source?

[andy_ojha · Accepted solution]

Hey there - good question...

This is one area where your data fidelity and general environment would drive a tailored strategy.

Consider the scenario of a CI in the CMDB, with an `Operational Status` of "Retired"...   

• How likely is it that the host in question is still active on the network (as in, it's not actually retired)?
• Is it possible that the CI is operationally reflected as "Retired", but the host in question is still on the network and is subject to being scanned by the vuln scanner?

You might want to start with reporting on this scenario first - to gauge the environment and get a feel for the lay of the land, before apply automated logic here around closing Vulnerable Items when their associated CMDB CI record is retired:

• The report might be something like "show me the count of Vulnerable Items that are Active, last found in the past 15d, and tied to a CI flagged as operationally retired in the CMDB"...  or "show me the count of unique CIs tied to an Active Vulnerable Item, where that CI is flagged as retired in the CMDB:...

Ideally, you want to avoid the State of the Vulnerable Items flapping between "Closed" <-> "Open"; and monitoring this first, to see how prevalent this scenario would be is worthwhile.  

As you mentioned Qualys, the baseline filtering that brings in the "daily deltas" from Qualys to ServiceNow includes pretty good fidelity around the "last found" date, that a detection was last observed on a Host...

• You might want to start there first, driving the closure of stale Vulnerable Items primarily based on when they were last observed by Qualys 

Then, after you collect some data / monitor your environment with the reporting mentioned above (having clarity around CIs actually being retired, vs being flagged as retired but are still on the network and having vulnerabilities reported on them) - you can decide whether or not you want to extend the logic for closing stale Vulnerable Items to also be influenced by the CI's Operational Status.