General Guidelines when using vulnerability based risk meters

The Kenna 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, Kenna 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 host: 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 Kenna

 

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
    • As top fix calculations are based on Asset level scores, having the high risk meter ensures that teams aren't solely focused on items whose score reduction value may be inflated due to calculations being done at the asset level*. 
  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 and reduction of high vulnerability counts rather than relying on asset based graphs in the reports. 

*Note: Risk Reduction calculations in Top Fixes are asset based and therefore may not be accurate in vulnerability based meters but will still reflect high value remediation items. 

Powered by Zendesk