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 |
due_date:<now-90d |
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 |
asset_last_seen:<now-90d |
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 |
asset_last_seen:<now-365d |
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. |
Comments
Please sign in to leave a comment.