Hierarchical Risk Meter Structure Guidance

jaredkalmus · ‎07-13-2023

As customers' Cisco Vulnerability Management deployments grow and mature, their risk-meter collection is sure to explode in quantity and complexity. In addition to causing UI clutter, an excessive number of risk meters also leads to administrative complications. The more risk meters that require query updates and user permission provisioning, the more time platform admins spend configuring risk meters as opposed to helping end-users remediate their high-risk vulnerabilities.

Adopting Cisco Vulnerability Management’s Hierarchical Risk Meters feature provides relief for these problems, but creating a risk meter structure in a logical and efficient manner can feel daunting. While there’s no “right” way to create a hierarchical risk meter structure, we’ve prepared the outline below to help inspire a basic structure for organizations to get started on developing a structure that’s tailored to the organization’s business needs.

Reporting
1. SLA Metrics
  1. Overdue vulnerabilities
  2. Due in next 7 days
  3. Due in next 30 days
2. Asset Types
  1. Servers
    1. Linux
      1. RHEL
      2. Ubuntu
    2. Windows
      1. Windows Server 2008
      2. Windows Server 2012
  2. Endpoints
    1. Windows
    2. Mac
  3. Network Devices
    1. Printers
    2. Switches
    3. Routers
    4. Firewalls
    5. Other Appliances
  4. Cloud
    1. AWS
      1. US-East
      2. US-West
    2. GCP
    3. Azure
  5. Docker
    1. Containers
    2. Images
3. Network Segmentation
  1. Internal Assets
  2. External Assets
  3. DMZ Assets
4. Vulnerability Types
  1. Zero-Day
  2. Malware
  3. Actively Exploited
  4. Risk Accepted
  5. False Positive
5. New Assets
  1. Created in the last 7 days
  2. Created in the last 30 days
Adhoc Risk Meters
1. Log4J - CVE-2021-44228
2. PrintNightmare (CVE-2021-34527 and CVE-2021-1675)
Team Meters by VP or Business Unit
1. Marketing (John Smith)
  1. SLA
    1. Overdue Vulnerabilities
    2. Due in 7 Days
    3. Due in 30 Days
  2. Recently Discovered
  3. High Risk
2. Finance (Jane Doe)
  1. SLA
    1. Overdue Vulnerabilities
    2. Due in 7 Days
    3. Due in 30 Days
  2. Recently Discovered
  3. High Risk

A risk meter structure as shown above allows you to quickly generate some critical reports and identify trends in the risk levels associated with certain devices and segments of the network/business. Let’s quickly break down the benefit of each risk meter type.

SLA Metrics - Provide high-level reporting of how the business as a whole is performing against service level agreements for vulnerability remediation
Asset Types - Identify which types of assets are outliers in terms of risks, i.e. are servers lagging behind endpoints in remediation? Is a certain operating system missing from SCCM patch jobs?
Network Segmentation - Quickly report on externally-facing assets which are at higher risk of exploitation targeting, etc.
Vulnerability Type - Useful for keeping an eye on increases in top-priority vulnerabilities, and vulnerabilities in special statuses which require further scrutiny
Adhoc Risk Meters - Oftentimes it’s useful to spin up a temporary risk meter to track a one-off project or reporting requirement. Bundling these underneath a single parent risk meter will help to keep your risk meter view tidy
Team Meters - Creating risk meters for each team in the organization greatly simplifies user permissions management, as team members only need to be assigned the single parent risk meter in order to inherit any child risk meters. These meters allow you to build risk meters for each team as needed, while also enabling easy high-level reporting for each team in the organization.

Be sure to check out our help article on getting started with Hierarchical Risk Meters if you need help in creating these risk meters and assigning them to users.

Keep in mind that your risk meter structure will never be perfect. Reporting requirements and priorities shift on a constant basis – don’t let “perfect” be the enemy of good!

You also don’t need to make a sudden and complete shift from a “flat” risk meter structure to a hierarchical one over night. The two structures can live side-by-side for a while, or different parts of the risk meter/reporting collection can be migrated over time as you find what works and doesn’t work for your organization. One strategy that we’ve seen work well with our customers is to identify a team that is receptive to change and work out a pilot program with them to gather feedback about an ideal hierarchical risk meter structure before making sweeping changes that would affect the entire organization.

We hope this document gives you a better sense of direction in planning out your future risk meter structure. As always, don’t hesitate to reach out to your Cisco customer success representative for assistance in building out your risk meter structure.