Risk Meters for Maintenance and Administration

Risk meters in Cisco Vulnerability Management are traditionally used for reporting risk and controlling access to assets using custom user roles. However, they are also great tools for maintaining the hygiene of your vulnerability management program. Creating a parent risk meter (refer to Getting Started with Hierarchical Risk Meters) to contain risk meters used for tracking adherence to best practices and established processes will keep your risk meters from sprawling. 

Risk Meter Name Filters Query Use
Risk accepted without notes Asset:Active & Vulnerability:Risk Accepted -_exists_:notes There should always be traceability for why a vulnerability is in risk accepted status. This risk meter will identify vulnerabilities that are in Risk Accepted status without an explanation in the notes field.
Risk accepted without approval Asset:Active & Vulnerability:Risk Accepted & Risk Accepted By:none   Every risk acceptance should have traceability to the manager who approved the risk acceptance. Cisco recommends creating a custom field called “Risk Accepted By” and using this risk meter to track for vulnerabilities that do not have an approver listed.
Risk accepted over one year ago Asset:Active & Vulnerability:Risk Accepted status_changed_at:>now-365d Risk acceptance should never be permanent. This risk meter will identify vulnerabilities that were risk accepted a year ago. Review these vulnerabilities and re-open them. If the risk is accepted again then set the status back to Risk Accepted.
Critical vulnerabilities without due date Asset:Active & Vulnerability:Open & Risk Score: 70-100 -_exists_:due_date Identify any critical vulnerabilities that did not have a due date assigned by SLA.
Past due vulnerabilities Asset:Active & Vulnerability:Open not_closed_by_due_date:true Identify open vulnerabilities that are past due for remediation.
Upcoming due vulnerabilities Asset:Active & Vulnerability:Open


Replace the date range in the query to match SLAs. Used to identify vulnerabilities which will be overdue if not remediated soon.
Assets past inactivity limit Asset:Active


Assume the asset inactivity limit is 90 days. This query will identify any assets that may have been created before an asset inactivity limit was set and have since gone stale. These can be manually set to inactive.
Assets past retention policy Asset:Inactive


Assume customer has a vulnerability retention policy of one year. This RM will identify assets which Cisco Vulnerability Management hasn’t seen in over a year. These assets can be deleted to improve performance. 
Assets without Owner Asset:Active -_exists_:owner Identify assets that do not have an owner assigned to them.
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.