The Business Case for Risk-Based Cybersecurity

This is Recorded Future, inside threat intelligence for cybersecurity.

Dave Bittner:

Hello everyone, and welcome to episode 154 of the Recorded Future podcast. I'm Dave Bittner from the CyberWire.

On today’s show, we welcome back Recorded Future’s senior vice president of global intelligence, Levi Gundert, to discuss his newly published book, “The Risk Business: What CISOs Need to Know About Risk-Based Cybersecurity.”

In our conversation, Levi makes the case for risk-based cybersecurity and describes the various challenges that organizations face when implementing it. He also proposes updated frameworks and explains the value of strategic threat intelligence. Stay with us.

Levi Gundert:

Well, I was doing a lot of flying and traveling coast to coast internationally and I had a fair amount of time where there wasn't really anything left to watch and I have a tough time reading on planes, so I decided to start writing because I was visiting with a lot of CISOs across our client base and some of our prospects and I saw a gap between what was happening on the operational side, the people that put hands on keyboards and the highest levels or tiers of the organization. There seemed to be a disconnect between what was happening in operational security and how senior executives and the board were thinking about risk.

I really wrote this book over the last two-and-a-half, probably almost three years now on a seat-back tray table with T-Rex arm posture. It took a while to put together, but I'm happy it's done and happy to start evangelizing some of the ideas in the book.

Dave Bittner:

Well, let's dig in together. I mean, what are some of the key things that you're covering here?

Levi Gundert:

At a high level, what I'm talking about is the focus of an information security program, a cybersecurity program. When I started working in information security almost 20 years ago, things were different in terms of the types of threats. I joined the Secret Service and I spent a couple of years investigating cybercrime. At the time, the mantra was really "defense in depth." As you know, if you rewind about 15 years, that's really what everyone was talking about was defense in depth.

That mantra, it sounded good, but in practice, it didn't really work because there was always a lack of resources for complete implementation, then the speed that adversaries were shifting tactics was too quick. It's not that defense in depth is a bad idea, but the actual implementation of it is difficult.

In the Secret Service, you think about adversary TTPs and how they change. They don't change a whole lot in the physical world. One example would be drones. Drones are a relatively new technology that present a threat to physical security. The Secret Service obviously has to worry about things like drones, but those types of TTPs don't come along that frequently. In the cyber domain, however, new TTPs are constantly changing and evolving, TTP being the tool, the tactic, the procedures that adversaries are using, and they're constantly shifting.

If you fast-forward a little bit, the next mantra in the information security community was intelligence, we need proactive intelligence. We can't wait around for bad things to happen to us. We have to be proactive and build intelligence that helps us make changes to our security operationally and that's really what we need.

It also is a good mantra, but what happens is that a lot of folks coming out of the public sector staff these intelligence teams and they typically think about this in public sector terms, government terms of where they've been working in law enforcement or intelligence. The way that they think about intelligence is that there's an outcome and the outcome is usually some sort of decision, a decision to take some sort of kinetic action on an actor or an adversary in the physical world.

There is a demand for intelligence to make these decisions, but in the private sector, it's a very different dynamic. The dynamic in the private sector oftentimes is that there really is no outlet for it. You can write intelligence reports, but understanding how those intelligence reports connect to the business is very challenging sometimes.

Then when we fast-forward a little bit more, we talk more today about automation and automation of intelligence at scale and that's also really important, but what we at Recorded Future have started talking about now is security intelligence, which is being able to actually measure the reduction in operational risk across all of your security functions.

Being able to do that means that you're able to actually talk about risk and quantify risk in a different way. If you can't measure an outcome and you can't communicate an outcome within the private sector operationally, then it's not really a valuable workflow. It's not really something that you want to invest resources in. That's something that I've spent the last couple of years really trying to hone in terms of how the measurements and the communication translates into that senior executive quantitative risk piece.

Dave Bittner:

Well, let's go through this notion of security intelligence together. There's several things you outlined here. Can you share some of the details?

Levi Gundert:

Yeah, we talk about the fact that most enterprise security teams, anyway, they have security operations, incident response, security operations, vulnerability management, third-party risk, or exposure within the GRC group. There's the intel group, which is usually responsible for some sort of brand protection, and then you also have business continuity. There's all these security groups in the enterprise. We talk about how to think through what you're trying to achieve operationally.

In the SOC, in the incident response team, if you're using intelligence, the outcomes that you should be driving are things like quicker indicator verdicts. If you have a level-one or level-two analyst that's "clearing glass," as we say, they should be able to verdict indicators much more quickly with good intelligence. What that means is that they're actually able to triage more tickets or alerts in a given day. The same thing on the incident response side is being able to triage incidents much faster. You have to have the measurements in place to be able to do that, but once you're measuring those things, you should start seeing improvements that you can communicate again to senior business stakeholders.

On the business continuity side, if you're more involved in intelligence on a geopolitical side, can you respond to emerging physical events quicker, can you improve personnel and site security planning? Brand protection, how many credentials are you resetting in a given time period? Based on intelligence from what you see externally, are you able to track how many credentials you're resetting in a given week or month or quarter or whatever it may be? Domain takedowns is another great metric where you have a confirmed type of squatting domain that's impersonating your brand and attempting some sort of social engineering attack.

Then marketing may want to get in on the response on social media when there's some event that they have quicker access to. Then sometimes, the internal in-house counsel would want to take action on some sort of RhodeCode repository. These are metrics that are specific to the silos. Same thing with third-party exposure. There's so many organizations that are really worried about third- and fourth-party exposure right now, looking at maybe mergers and acquisition doing the evaluation to figure out: Is there a hidden risk before we actually do the merger?

Then just generally, hundreds to thousands of vendors and suppliers out there and being able to prioritize those vendors and suppliers and help them, being able to articulate to them when something changes in their risk profile, being able to articulate that to them and work with them to make the necessary improvements is really, really helpful and really important to measure.

Then on the vulnerability management side, improving patching prioritization and being able to better articulate the need to expedite patching across different lines of business is really important. Those are all metrics that intelligence is helping to create and inform.

Dave Bittner:

One of the things that I've certainly seen over the past few years is this shift where the members of the board are interacting more directly with the cybersecurity leaders. They're giving them a seat at the table and recognizing that they have a real part to play when it comes to managing risk here. How does that align with the things you're tracking?

Levi Gundert:

Yeah, that's a great point. I think we've talked about this before, Dave, the need to look at quantifying risk because today, it's very hard for the board and senior executives to necessarily understand what's going on just based on the traffic light models that we tend to use in the enterprise: red, yellow, green, or high, medium, low. It doesn't appropriately communicate what risk is. You and I have talked about this before, but really, at their level, what they care about is answering the question: Are we going to lose revenue? Are we going to lose money? If so, how much? There's a lot of sentiment in our industry that there isn't enough data to create useful models to answer those questions.

In the book, I talk about the fact that based on the work that others have done here, specifically, there's a great book: How to Measure Anything in Cybersecurity Risk by Douglas Hubbard and Richard Seiersen. You can absolutely build useful models and there has been some movement in the industry around FAIR, F-A-I-R, but what I've personally seen is the concepts with FAIR are great in terms of quantifying risk, but the implementation has been very difficult. I've talked to a number of people who have tried to implement it and it's taken them a year or two years and they've actually given up on the effort just because the implementation has been very convoluted.

In the book here, I come up with a new proposal called "threat category risk" or TCR. Threat category risk is based on the same quantitative risk principles, but it's meant to be very easy and very practical to implement and it doesn't require specific software. You can do it in an Excel spreadsheet. That model is designed to help bridge the gap between senior stakeholders and operational defenders in being able to answer those questions around loss. I think that's where our industry's going to be going over the next five to 10 years. Again, primarily because of that gap.

Dave Bittner:

One of the things that you highlight in the book are what you describe as "limitations" of a couple of the models, the threat-focused model and the compliance-focused model. Can you take us through where these fall short?

Levi Gundert:

Yeah, absolutely. You're right. There's really two emphasis areas where I see most security programs. When I ask, "What does the win look like for a security program? For you, what does that look like?" a lot of times, the answer I receive is something related to a compliance-focused program. They say, "Well, we're trying to move maturity in this cybersecurity framework with a ISO of 27,001. We're trying to move our maturity from a two to three," or three to four, however the rating system works. "That's really how we measure success is, are we more mature this year than we were last year."

The problem with a compliance-focused program is that the frameworks that they're using, they don't necessarily keep up with the pace and the scale of changing adversary tactics. They will release updates maybe annually, maybe biannually, every other year. It's very difficult to just pin everything in terms of success for that program because they're not giving you everything in terms of a real-time framework.

The other problem is that if I tell you and the compliance framework says, "Hey, you need to build a fence," and you build a fence out of bacon, you have fulfilled the letter of the requirement, but not the intent. I think that's the problem with the compliance-focused security programs is, it very much becomes a check-the-box mentality where "We can check that box and move on," "We can implement the firewall and move on," or whatever it may be. The problem is that it's not always the best implementation or the most well thought out implementation because everything, all the emphasis is on expediting the checking of the box against the compliance requirement.

I'm not saying that you don't have to adhere to governance and compliance requirements, you obviously do, but if you're pinning and you're focusing the entire security program on that, you're probably missing the mark.

Then on the other side, some programs are very threat-focused. The problem with being super threat-focused is that you're jumping around trying to address various threats topically as they start to pop up or appear. The problem when you're always chasing the flavor of the month, you're not necessarily doing the due diligence to understand whether that threat represents a risk. If it's not actually a risk for the business, then you're wasting resources, you're wasting time, and you're potentially wasting financial resources running after something that you know is not necessarily relevant or pertinent as a risk to the business.

That's why I talk about the two failed models in compliance and threat and moving to a risk-driven cybersecurity program. There are three steps to that:

Number one is understanding your security controls and where you have gaps.

Then number two is understanding what I call "relevant threat deltas" or RTDs. Relevant threat deltas are those changing TTPs as I was talking about, the ones that specifically present a risk to your business based on your understanding of your security controls and where you have gaps.

Then number three, once you're able to do those two things, then you have good inputs for a quantitative risk model to be able to calculate probabilities and quantify actual loss amounts tied to those relevant threat deltas.

If you think about, again, the drones in the physical scenario with the Secret Service, you think about the risk that drones pose to protectees, it's the same thing here. Identifying relevant threat deltas or identifying drones or even, as new categories, but also maybe even new types of drones within the category where you have, it may be short term or long term security control gaps, and then being able to quantify those means you can talk at a senior stakeholder level much more intelligently and actually have conversations about the tradeoffs in terms of future security investments.

Dave Bittner:

That third point about calculating probabilities and quantifying, I think that's so critical. I mean, I think about, for example, someone who is located on the West Coast has a different threat assessment when it comes to things like earthquakes than someone who lives on the East Coast, even though both of them probably, it's good to ask the question, "What's our concern with earthquakes?" but depending on who you are and where you are, you get a different answer.

Levi Gundert:

Yeah, that's absolutely true. It really is. It's exactly the same. Recorded Future is a SaaS company and our profile in terms of our security controls is very different from a security enterprise that hosts some of their infrastructure on site and that has some of it in the "Cloud." That has multiple geographic presences and locations. It's industry-specific. There's so many variables in that, so that's absolutely true.

Dave Bittner:

In terms of someone getting started, beginning this journey, and starting down the path, to shift how they come at these things, what do you recommend there? What's the best place to begin?

Levi Gundert:

Well, I think if you read the book, it's a quick read, by the way, it's not a long read. Just starting with the model and starting with how to think about estimation and how to get some initial inputs into your threat categories, one of the things, I think it's chapter four or five, I talk about the threat category risk model. It's designed to be flexible and practical. I've laid out some high-level threat categories, but it doesn't mean that those are the only ones. You can be more granular, you can be less granular, you can add other categories into it. Just sitting down and starting with some inputs to the model and getting some outputs out of the model, I think it really spurs conversation with the different folks within the security program and the organization.

When you start looking at the model outputs and asking yourself "Is that right, generally?" and then going back and looking at your inputs again, it's a really interesting exercise where we've done this with a couple of our clients because they start thinking about factors they hadn't considered before, things like cyber risk insurance and they start thinking through their controls, they start thinking through what downtime actually means in dollar terms depending on data availability or data confidentiality or integrity. They really start thinking through what it all means in dollar terms.

I think just doing the initial exercise is an eye-opener. Having those conversations and doing that is a day, maybe two days at most where you can start to see some of the outputs of the model and then really think through what you want to do with that and how you want to talk about those outputs and how you want to potentially bring in other teams and other stakeholders in the organization.

I think what we've seen up to this point is that doing the modeling is not difficult. What is difficult is having those conversations with other teams because risk tends to be calculated a certain way within most organizations for other types of risk, whether it be geopolitical risk, financial risk, physical risk. This is a little bit different in terms of the model and the assumptions and the variables in the model. Having those conversations about the assumptions and having those conversations about the outputs is probably the most challenging and difficult part. We've seen some organizations that have done it really well and other organizations that have struggled to basically try and win hearts and minds internally.

Most organizations today use a very basic model: likelihood of occurrence times impact. The problem with it is just that there's no rigor behind the values that go into it, so somebody just will throw out a number or figure in and whoever's responsible for running that equation will do it, but it's basically garbage in, garbage out. It really is a bigger challenge of, again, trying to evangelize some of these concepts internally and come to an agreement about how you're actually going to talk about risk when it comes to cyber.

Dave Bittner:

Our thanks to Recorded Future's Levi Gundert for joining us. The book is titled “The Risk Business: What CISOs Need to Know About Risk-Based Cybersecurity.” You can download a copy on the Recorded Future website.

Don't forget to sign up for the Recorded Future Cyber Daily email, where every day you'll receive the top results for trending technical indicators that are crossing the web, cyber news, targeted industries, threat actors, exploited vulnerabilities, malware, suspicious IP addresses, and much more. You can find that at recordedfuture.com/intel.

We hope you've enjoyed the show and that you'll subscribe and help spread the word among your colleagues and online. The Recorded Future podcast production team includes Coordinating Producer Monica Todros, Executive Producer Greg Barrette. The show is produced by the CyberWire, with Editor John Petrik, Executive Producer Peter Kilpe, and I'm Dave Bittner.

Thanks for listening.