How to Define and Communicate Vulnerability Risk Across Your Company

This is a guest post by Rapid7 customer Steven Maske, the Information Security Manager of a manufacturing, retail, and distribution company.

Like any endeavor there is a degree of risk in operating a company—there is always a certain level of risk that must be remediated or accepted. The key is to assess the probability and impact and communicate it to the risk owners and executive leadership. In this post, we’ll discuss how risk can be defined within an organization, the differences between risks, threats, and vulnerabilities, and how to effectively communicate this to risk owners and leadership teams.

How to assess and define an acceptable level of risk

Risk is a measurement of probability and impact—what’s the chance that something bad will happen and how bad will it be? How a company measures risk needs to be determined by weighing the probability of the risky outcome against the cost of resolution. For example, let’s say you have proprietary data that, if stolen, could cost your company $100,000. If the cost to remediate the issue is $1 million, you wouldn’t spend that on the potential that you could lose a fraction of the amount.

Different industries also face different levels of risk. For example, say a retailer and a newspaper are both compromised by a database exploit that leaks names and email addresses. For the retailer, it’s a list of names and emails, but for the newspaper, it’s a list of sources. While embarrassing to the retailer it does not have the same impact if the data becomes public. The breach at the newspaper could lead to physical harm should the list of sources fall into the wrong hands.

Risk levels also vary based on company type. If you’re a government agency, your risks are different than if you were a mom-and-pop shop. To be clear, there generally isn’t an overall risk score for a business as a whole. Instead, the risk scores differ across different areas of the business.

The Common Vulnerability Scoring System (CVSS) is a good framework to get you started, but it does require additional context in order to validate the severity score. For example, if you have a vulnerability with a CVSS score of 10 but the system is sufficiently isolated, is it really a 10? Probably not, so added context matters.

Risks, threats, and vulnerabilities: How are they different?

To talk about risk, we also have to talk about threats and vulnerabilities. They are frequently used in the wrong context, which is why it’s important to distinguish them:

• A threat is the “who” or the “what” that’s causing the issue.
• A vulnerability is the weakness that is being exploited.
• A risk is a function of the two: the measurement of the probability that something bad will happen that produces that result.

When determining your level of risk, there are many other factors to consider beyond the simple fact that you are or aren’t vulnerable. Let’s say a new exploit becomes public. If your machine isn’t connected to the internet, the probability that it will be impacted is lower than if it were on the internet.

You also need to know your environment. This includes cloud assets, employees, systems, machines, and so on. Social engineering is a common threat vector that affects these by exploiting human vulnerabilities. People want to trust others, which is why risk rises just by a machine or system being online.

How to communicate risk level to executives

I attempt to communicate risk using analogies because they’re easy for the layman to understand regardless of how much they know about security. When first explaining what risk is, I often put it this way: If I ask you if your house is secure and you have an alarm system, you’d probably say “yes.” However, you still have glass windows, which means you’ve accepted the risk that someone could break through a window and get in before the police arrive. If you live in a dangerous neighborhood, you might evaluate this risk differently and implement additional safeguards such as putting bars on your windows.

Overseeing risk resolution

As a security team, it’s our job to identify and advise on risk levels. We don’t own the risk—it’s owned by the system or process owners. When a risk is identified, we bring it to the appropriate person’s attention and work together on a resolution. Our job isn’t to be a hammer and pound people into following our recommendation. Instead, we must be a compass and guide the way.

To keep projects on track, it’s suggested that regular meetings be held with risk owners to provide status updates on remediation efforts. Any risk that hasn’t been accepted or mitigated requires a regular update within the risk registry to maintain progress and evidence management oversight.

When you know all of your risks, it’s important to recognize that not each and every one can be addressed immediately and many will require a coordinated project involving multiple employees. Some risks are simple tweaks that take minutes to fix, while others require infrastructure changes that could take weeks or months to complete.

Lastly and perhaps most important, you need to have a working relationship with system owners and IT. Without “buy-in” it becomes incredibly difficult to communicate and make decisions in the best interests of the company. Communication is the crux of a risk assessment program, as it enables teams to provide visibility and collaboration. These are key components to an effective and timely resolution.