Bank OZK's vulnerability risk index shows patching priorities everyone understands

Explaining vulnerability risk to non-technical executives can be hard. With his CSO50 award-winning Vulnerability Exception Risk Index, Bank OZK CISO Jason Cathey has devised a way to turn vulnerability data into a simple risk metric.

3 patch training update software band aid laptop with virus binary
Getty Images

While regular patching for vulnerabilities is important, not all vulnerabilities are created equal. Their impact on the business can vary widely depending on severity and the system on which it appears. IT teams need time to prioritize critical systems and vulnerabilities, meaning patch debt can accrue.

For boards that don’t understand the ins and outs of vulnerability data, it can be hard to understand how much risk an organization is actually taking on and whether that sits within its acceptable risk tolerance. For patching teams, it can be hard to know where to focus patching efforts.

“Anyone that monitors risk, they always want a metric,” says Jason Cathey, CISO at Bank OZK. “They want an index or a single number that they can trend and watch to see if it goes up or down and see where it sits in line with their risk appetite.”

However, vulnerability data, he says, doesn’t fit easily into a single metric. 

Communicating risk with a single metric

Headquartered in Little Rock, Arkansas, Bank OZK – previously known as Bank of the Ozarks – operates in ten states in the U.S. and has over $20 billion in assets. Founded in 1903, the company has over 2,600 employees across more than 250 locations.

jcathey headshot bank ozk Bank OZK

Jason Cathey, CISO, Bank OZK

Cathey has been at Bank OZK since 2015 and became CISO in November of 2018. His security team consists of nine people: three on the information assurance side and six on operational security, including an internal security operations center (SOC). While the company has a regular patching program and schedule in place, Cathey felt more could be done.

“We were really having a hard time presenting what we felt the risk was and the direction of the patching program,” he says. “There was a challenge of making sure that IT and operational side of the house was applying patching in a timely manner, and, if they were missing certain systems, what was the risk to the bank if that patch was missed on a specific server.”

To better understand and explain the risk any unpatched systems may present to the bank, Cathey created the Vulnerability Exception Risk Index (VERI), a system that creates a single metric to quantify the risk unpatched vulnerabilities bring to an organization. “The VERI is a calculation that looks at the asset group as well as the severity of the vulnerability. For example, if we have a server in the DMZ, it's a lot more exposed to the external network, whereas if you have a work station, you have to go through so many layers of defence to get to that, so we take that into account.”

VERI takes the CVSS score of any vulnerabilities that have not been remediated during the standard patching program on any given asset, weighs that against the sensitivity of the asset depending where in the network it sits, and assigns a score. That score is then grouped within an area — for example, all assets within the company’s DMZ (demilitarized zone) — to give a total VERI rating.

The VERI highlights which systems are accruing large amounts of patch debt or high severity patch debt. This shows where exceptional action might need to be taken outside the usual patching operations. The VERI is an exception risk index, so if everything is patched within the standard, the VERI score is zero.

Bank OZK uses the VERI in two ways: It provides a single, easily read metric for non-technical members of the business — whether in risk, the executive leadership, or the board — to show the level of vulnerability risk any given set of assets has. It also provides the IT operations responsible for patching guidance on where to prioritize their efforts and highlights any areas or assets they might be falling down on.

“It's a static number that we calculate at the end of every month, we report to our executives and board, and then operationally we work with IT so we can help guide their efforts and attention on things that are presenting a higher risk due to either sensitivity of the asset or the criticality of the vulnerability,” says Cathey.

How to calculate the VERI score

The VERI is calculated with an algebraic formula:

(((V*Cc)*A^1.10)+((V*Ch*A^1.05)+((V*Cm)*A))*S

V = the number of vulnerabilities within each asset group

C = the severity weighting of those vulnerabilities based on their CVSS scores: (c)ritical, (h)igh, (m)edium

A^ = the number of affected assets within the asset group being assessed

S = adds a weighting to A^ based on the sensitivity of the asset group

Bank OZK generally sets its VERI on a scale of 0 to 100, and anything below 25 is within the company’s acceptable risk appetite. “We can trend that over time and see which assets are not getting the attention they need, or if laptops are not on the network and we have a fixed set of critical patches that are missed, then that index is going to jump up month over month,” says Cathey. The process is largely automated. Data is pulled from vulnerability scans using predefined queries once a month and is copied over to an Excel file that has the calculations pre-populated.

Cathey has posted details about the VERI on LinkedIn, and people have reach out to him about replicating the index in their own companies. While the algebra might look intimidating at first, Cathey says tailoring the weighting factors to suit your specific environment or organization is the hard part, as the VERI’s value comes from consistent measurement month-to-month and getting the weightings wrong at the implementation stage means your company may be setting unachievable goals in the long term. 

Good vulnerability scanning is key to calculating the VERI, and Bank OZK uses Tenable Security Center to ensure good visibility across the network. “That is the data that feeds the index,” says Cathey, “so if you don't have good processes that are tested, you don't want to start reporting that VERI number until you've validated that your vulnerability scanning is accurate and you're getting full visibility of your network. If you jump into a network where it didn't really ever have any vulnerability reporting, that number's huge [when you start].”

In the future, Cathey says he might look into adding a variable around whether an exploits for the vulnerabilities are available in the wild.

Result: Better patching, more accountable security

Cathey says the board, executives and IT all understand and trust the calculation in relation to what the company’s risk is. “Wednesday morning I'm sitting in my board committees presenting that index, and then in the afternoon I'm sitting with IT operations looking at the details behind that index,” he says. “Being able to shift from a board-level conversation to then jumping in a room with technical guys to remediate is paramount.”

The ability to show non-technical members of the organization vulnerability risk in a simple, non-technical way means not only do business leaders have a better understanding of their environment, but they can also hold IT and security to account if they see something they don’t like. “If everything's in the green, they're happy. If it gets to the yellow they'll start questioning. If it's teetering towards the red, they'll ask why. They don't understand what they're looking at, but they know that there's something that needs their attention,” says Cathey.

“If there's a peak in any of these assets then people question it. Even if it's within tolerance, they still want to know what happened; ‘Why did we jump 20 basis points last month over the month before?’ and they'll start drilling into the details.”

On the technical side, Cathey says the VERI has helped improve patching processes. The VERI score on a set of severs, for example, saw an 89 percent reduction over the last year. “IT was doing their job, and they were doing great, but once we started showing them the vulnerability data, it quickly identified the gaps in their patching process. Nothing changed except for the patching process. The calculation remains the same; all of the weighting factors remain the same.”

Copyright © 2019 IDG Communications, Inc.

Get the best of CSO ... delivered. Sign up for our FREE email newsletters!