General Guidelines when using vulnerability based Risk Meters

The Cisco Vulnerability Management platform employs asset level scoring, yet in many organizations vulnerability remediation and patching work is distributed across multiple teams (Infrastructure vs Application). In these cases,  Risk Meters can divide the vulnerabilities between those teams for remediation, yet the scoring remains at the asset level.

This poses some challenges related to risk reporting at the asset level as shown in this example:

  • Asset Group = host1, host2, host3, host4  
  • Vulnerabilities on each asset in the group: v_score100, v_score80, v_score70, v_score60

Infrastructure team Risk Meter includes all assets / v_score100, v_score70

Application team Risk Meter includes all assets / v_score80, v_score60

Risk Meter score for both teams will be 1000 even though the Application team's highest vulnerability is 80, and even if the Application team fixes all 80 vulnerabilities, the scores will not drop until the Infrastructure team fixes the 100 level vulnerabilities. See Asset Scoring in Cisco Vulnerability Management

 With that understanding here are some general guidelines when using vulnerability based risk meters:

  1. Always have an overall risk meter which shows the health of the assets with ALL vulnerabilities included. Overall risk and identification of under-performing remediation teams using the vulnerability based meters will be judged at this level. It is important to ensure that the ALL meter is clearly tied to a set of remediation meters that account for all assets and all vulnerabilities of the ALL meter, otherwise score changes will not align (r1, r2, r3 = r1+r2+r3)
  2. Use a 'dual task list' method for the remediation team. They should pull from top fixes that come up for their meter but should also pull from an additional "high risk meter" (vulnerability_score:>66) with the goal of getting that risk meter to 0. This 2nd risk meter serves several purposes:
    • It creates a finite list of items that can be tackled by the remediation team which will result in a big, fat, green 0 at the end. This ensures that teams are able to "prove" they are doing their part to knock down risk.
    • It makes it visually easier in the dashboard for the overall asset owner to discern why risk may or may not be dropping as needed.
    • The high-scored risk meter focuses teams only on the highest vulnerabilities. This helps tackle the highest vulnerabilities first, but may not be the most efficient way to reduce the overall risk meter score as risk reduction calculations in Top Fixes consider not only the vulnerability score, but how many assets are affected by the vulnerability. Therefore, Top Fixes may not be accurate in vulnerability based meters but will still reflect high value remediation items. 
  3. Periodic review of top fixes on the overall meter is recommended as this is where score reduction calculations will be most accurate. 
  4. Evaluation of remediation teams using the platform should focus on overall reduction of vulnerability count on their risk meters and reduction of high vulnerability counts rather than relying on asset based graphs in the reports. 


Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.