Managing Assets Intuitively with Hierarchical Risk Meters

This article guides Kenna customers on how to build out a robust hierarchical risk meter structure. 

As customers’ Kenna deployments grow and mature, their risk-meter collection is sure to explode in quantity and complexity. If you’re unfamiliar with the concept of a risk meter in Kenna, risk meters are data structures that allow users to save a query of assets or vulnerabilities for quick and easy reporting of risk levels.  

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 Kenna admins spend configuring Kenna as opposed to helping end-users remediate their high-risk vulnerabilities. 

To help our customers more easily manage their increasing number of risk meters, Kenna released the ability to organize risk meters in a hierarchical parent/child relationship. Organizing risk meters in a hierarchical structure allows users to create granular risk meters that share common characteristics, such as relating to a specific business unit or operating system. Adopting Kenna’s “Hierarchical Risk Meter” feature provides relief for the usability problems described above 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 tailored to the organization’s business needs such as being able to compare the risk levels of different data centers or business units. 

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. These types of risk meters can be highly beneficial to both security analysts and executives in learning where the business is most at risk of breach exposure. As an example, the Windows workstations group may be patching their assets religiously and showing a low-risk score in Kenna, while Linux servers lag in remediation efforts. This could be an indication that further investment in tooling or headcount may be needed for the Linux group. 

Let’s quickly break down the benefit of each risk meter type:

• SLA Metrics – Provide high-level reporting of how the business  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 endpoints in remediation? 
• Network Segmentation – Quickly report on externally facing assets that 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 this 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 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 Getting Started With Hierarchical Risk Meters if you need help in creating these risk meters and assigning them to users. 

You also don’t need to make a sudden and complete shift from a “flat” risk meter structure to a hierarchical one overnight. 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 Kenna 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 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 Kenna customer success representative for assistance.