Following is a second set of excerpts from an extended interview with John Sapp, CISO of Texas Mutual Insurance, on his approach to cyber risk governance and how he built a platform with AppSOC to streamline processes, create greater visibility, and prioritize risks based on business context.

A lot of tools rely on CVSS scoring, and in practice they produce far too many ‘critical’ results to manage. What other factors do you use to slice down the data?

I use the AppSOC platform to do that. It automates what I used to try to do with spreadsheets and ties everything together. CVSS scores have a purpose within their singular context. But when we look across the totality of my environment, I need to factor in the business criticality of the asset where that vulnerability exists. I also need to factor in what type of data is being stored or processed on that asset. And what business process does that asset support? 

This provides a more comprehensive view because we've aggregated all those different variables and factors, and now we can truly compare apples to apples. I've created a level playing field where things have been normalized giving me much clearer visibility.

With this platform I can also understand the software dependency tree and I can drill down into. I call it the traceability factor – being able to trace it from the top level down. Let’s say I know there's a server that has an application running on it. I also need to know the components of the application such as microservices, or libraries, and who owns them. When it comes to patching vulnerabilities, this is one of the hurdles that every CISO in America is trying to overcome. Usually, there's someone different who's responsible for infrastructure, so the two groups need to work together to patch all these things on the desktop, the OS and above, as well as the application and its components.

Without this approach you can go in circles. Let’s say there’s a Java vulnerability but I can't patch that because I don't know what it's going to break, and I don't know who the application owner is for the underlying piece. And so, you stay on this merry-go-round, and those vulnerabilities often don't get patched. We had this struggle with Log4j – just finding out who it belonged to. After months of alerts and research, we found the vulnerability on a legacy piece of hardware, so we were effectively chasing something unimportant.

This gets into the areas of software supply chain security. Is that an area where you also get better visibility and traceability?

Absolutely. That was one of the key things that for me, when I started mapping out the requirements for this platform. I needed to be able to see down to that level and the platform gives me an unparalleled degree of visibility. When I talk about traceability, I think about risk management in three different lenses including: 

• The operational technical lens, which is that foundational layer. That's where the folks in the trenches are responsible for remediation of the vulnerabilities discovered. They need to know and understand what they should be focused on. 

That rolls up to the next levels, which are:

• IT management and business management. Because in our world, the business owners of the applications need to understand why we are requiring them to patch a certain vulnerability – they need to know “what's in it for me, why do I care?”

For example, let’s take our primary insurance application, which connects to our policy holders. If there's a vulnerability there, policy holder services want to know and understand why we are focusing our time on fixing that vulnerability as opposed to new building features. But, if you're able to make the case that this risk could cause a denial of service, which could take your application offline and interrupt your business operations that service your policy holders, they are much more supportive. 

That's how you need to frame it. They shouldn’t be expected to understand the technical details of how it works if you give them visibility and context, and how it could impact their world. With the business owners buy in, they can ask their IT partners, “hey, are you guys fixing this?” Because they see it's in the high-risk category, it's critical and could disrupt operations. So now we've turned the table, and they are demanding that we fix vulnerabilities as opposed to us pushing back, because now they understand the business risk context. 

Prioritizing large numbers of possible threats is always harder than it sounds. How do you isolate the 5% of risks that require the most immediate attention?

If all your data goes into a funnel, what you focus on is what's at the bottom, because you shouldn’t need to worry about everything that went in at the top. When I look at my environment today, we only need to focus on about 3% of the total. Literally 97% is noise – redundancy, false positives, or non-critical alerts. This gives me a much more realistic starting point for my team to pursue.

I also need to tell this story visually because a picture is worth a thousand words. Showing this accurate funnel and heatmap speaks volumes. Because we have a validated approach that prioritizes critical findings in the top right corner, they understand that the top 3% of vulnerabilities are where the real risks are. This helps them understand and trust the risk-based approach that we're taking.

Does this focused approach help with assigning resources?

Yes, that’s a clear benefit. I think of my security team as a platform team. We provide a platform of security with multiple enabling capabilities for the business. For example, we provide application scanning and infrastructure scanning so that they can deliver their services in a secure way. Application developers aren't inherently secure by nature, but if we give them an enabling capability, a tool that allows them to scan code and generate clear data easily, then they will use it and do a better job writing more secure code.

Now they resolve any critical vulnerability they discover and fix it within seven days. I will challenge anybody in the industry to say that they have something better than that. But there’s always the challenge of data overload. I must give them a prioritized view they know what to focus on first. 

Not all critical alerts are the same, nor should you ignore all medium alerts, because they might be more disruptive if they have a higher probability of being exploited. That's the beauty of threat and vulnerability management orchestration, because it can help find that one medium alert that might be a bigger problem for my environment.

You must think about what attackers are trying to accomplish. My uncle was a chief of police and one thing he taught me was this: to catch a criminal, you’ve got to think like a criminal. When I think about it, if I were a cybercriminal, would I focus on the zero-days that everybody's talking about and scrambling to fix? Instead, I’d probably use a medium level threat that’s been sitting there unnoticed for years. It's easy to exploit and it exists in 90% of the environments today. This might not show up as a CVSS critical alert, but if you factor in exploitability, I can prioritize risks that most people aren’t looking for.

How do you make this process collaborative, especially with developers?

It absolutely requires collaboration because they help build the process. If you include them in the architecture and process flow, you help them understand the value from the outset. That's where the buy-in occurs, and in our organization, we have that buy-in from the developers, their managers, the business leaders, the IT management, and up to the business managers. They all understand what’s in it for them, as well as the extended value to the broader enterprise. That is arguably the most powerful part. When we talked about the hierarchy of how this data is summarized and assigned to those teams, they’ve had a say in how that rolls up in the platform.

You have this concept of business units, applications and microservices. They get to participate in how we put that data together. Developers might be looking at the microservices level, and the management team might be looking at it from an application layer, and they might decide that they want to address a high risk, low maturity vulnerability, because the application is business critical. 

This process also helps tell the story to our customers. If you look at our corporate responsibility report, one of the major topics is how we protect stakeholder data, and this helps us provide some substance to how we do that.