The Cybersecurity Vault – Increasing Relevance for the Next Evolution of Cybersecurity Metrics

Welcome to the Cybersecurity Vault. I'm your host, Matthew Rosenquist, CISO, industry cybersecurity strategist and advisor. And today we're going to talk about cyber risk metrics and quantification. And I'm going to be talking with Gavin Grounds. Now Gavin is the CEO and co-founder of Mercury Risk and Compliance. Gavin has been a leader in the cybersecurity risk quantification, information risk management and compliance and security operations space for years. Formerly, he's a senior director of security risk and compliance at Meta and the executive director of governance, risk and compliance at Verizon. Welcome Gavin. It's always great to talk with you and to talk cybersecurity metrics.

Yeah. Well, first of all, super excited. Always a pleasure, Matthew, to hang with you and talk. And I know we'll have some laughs around some serious subjects along the way. But yeah, and anyone that can be excited about metrics, if we can't make being excited about metrics fun, then, you know, we're never going to make progress as a community.

Well, you know, metrics, of course, is sexy, right? I mean, security metrics, come on, everybody loves this.

But I have to say— I would just say know your audience.

That's the advice. Everybody's scratching their head like, whoa, what is this guy drinking? You know, I need some of that.

Well, it's a good roast. There we go.

Yes, yes, it is. It is. It's mandatory coffee here. But, you know, metrics in our industry, they're evolving. And, you know, as there's more pressure to do more with less, to show justification, to, you know, you've got the CEO wondering, "Why are you asking for another 20% budget increase? You know, show me the money. Show me the value here." Metrics is going up, right? Their importance is rising. So, what are you seeing as kind of an overall trend? Do you think it's just kind of a slow increase or do you really see kind of that hockey stick of interest and people clamoring for something to be able to show security, risk, value, all those things. What do you think?

Yeah, I would say even since the last time you and I spent some time together, Matthew, I think the rate of increase in interest in trying to figure this whole space out is exponential. You know, I've had the opportunity to spend probably in the last year, I've gone to several really noteworthy conferences, particularly around security and security risk. And to me, it seems like there's a lot of noise about it, which is a good thing. You know, there's a lot of excitement about it. But I think tying, particularly in cyberspace, tying, you know, risk and cyber risk to value, I think a lot of our colleagues across or our peers across the, you know, our domain are kind of really struggling with it. I think for a number of reasons, but I would say, you know, foundationally. So first of all, to answer your question, yeah, I think the, The level of interest is exponential. I mean, we can just look at some of the recent news again, you know, as to how metrics potentially could have helped to prevent a problem in the first place or at least made the situation more defensible, you know, than it otherwise might be. But I think one of the foundational issues is that a lot of, whether it's CISOs or, you know, technology risk leaders, I think part of the challenge is that as a community, a lot of us come from a technology background or an IT background or an OT background, and there's fewer of us that come from a business background. And then there's some unicorns that kind of come from both. So when we think about— one of the questions I was asked recently at a conference was, so hey, Gavin, with the approach that your company takes, the approach you've taken at your previous companies, is the intent to be able to report to the board effectively? Around cyber risk, for example? And my answer is actually no. Reporting to the board about cyber risk to me is a byproduct of doing actually effective risk management in cyber. Because if you think about the role of the board versus the role of the C-suite and the management of the company, you know, the C-suite and the management of the company are basically there to do exactly that, to manage the company, to take care of stakeholders, shareholders, customers, employees, everyone that's dependent on the community. The board is basically there to take care of the primarily interests of the shareholders. And I know there's some variations that depend on which sector, you know, industry sector we're in. But we think about all the risk domains, the board, for example, are not saying thou shalt reduce risk. What the board is looking for is for the, for the, for the C-suite, for the management of the company, which therefore includes the CISO and kind of all things tech and IT. What they're looking for is to see what the return on risk is. So if you think about it, you know, from as a board member, I would want to make sure that the company management are demonstrating an effective return on capital. Return on equity, return on investment, effective management of net present value, effective management of cash flow, and therefore a return on risk. And so really, when we think about it, the board are fundamentally wanting us to take risk. I mean, that's what growing a business is all about. But what they want to be able to see is what the return on the risk actually is. And I think that's probably a foundational challenge as, let's say, the group of, or community of CISOs and risk management in the tech and cyberspace is we're almost indoctrinated to think our job is to reduce risk when in fact our job is to optimize or help the leadership and the business to actually optimize risk in a very defensible way. So I think that's, as you know, as I look back over the last 12 to 18 months, that's some of the trends I'm seeing. Matthew Rosenquist, there's a lot of interest because we need the interest. There's a lot of static and noise, frankly, about it. But as a community, it's like we're struggling to actually you know, to nail it.

Well, let me challenge you on something because you brought up the board conversations and we're seeing new rulings like the SEC ruling where, you know, the board has to have more insight. They have to be able to publish, you know, in their reports and announcements that they've got a certain grasp on their risk. And you're right, right? Our industry is about managing risk to an optimal level. We don't eliminate risk. It's about managing it to an optimal level. And, you know, the CISO tends to be looked at by the board members to go, okay, explain to me, explain to me how you're managing this ambiguous cloud of nastiness so that I can understand in business terms. And where does metrics play into that? Because I just can't imagine you going, no, CISO, don't worry about metrics to your board. I'm thinking that should be something as part of the story you're telling. As part of how you're conveying what program you have and how effective it is to hit that target, right? Not bulletproof, not weakest in the world, but somewhere where that target is at optimal level. How do metrics play here at the board?

Yeah. No, that's a really good question and good perspective, Matthew. And I think there's a couple of ways that I typically would answer that question. First of all is,— well, I'm going to speak specifically about a CISO. Obviously, you've got other risk management around tech and cyber and so on, but specifically as a CISO, just as an example, what I endeavor to do is look at what, from a metrics perspective, what is useless to the board, right? So if we rock up and say, "Hey, we had 150,000 vulnerabilities in the environment," you know, last quarter, and now we're down to 99,000. It's like, well, is 99,000— like, is that good? Is that— is that— yeah, you know, and I think that— so that's part of the challenge is, you know, identifying what does not resonate with the board. And so, and that's one example, is like, you know, how many—

so are you saying bad metrics can be just as bad as no metrics? —Or even worse.

Well, first of all, yes, I agree with that. Bad metrics are worse than no metrics, probably. Well, ask a lawyer about that. They might tell you what's more defensible. Right? But, you know—

Let's not get the lawyers involved. Let's not do that. No, we're not going there.

However, you know, we could say bad metrics are as bad as no metrics, at least. Right? So we can put the relativity to one side. But I think it really does come down to kind of know your audience, right? So if I'm working with, you know, with a product owner in the company— so we're now talking about the company management. So we've got the product owner, we've got the, you know, the dev shop. They probably are interested, and they should be interested in, hey, what vulnerabilities do we have in this particular platform, whether it's open-source vulnerabilities, libraries, static, dynamic, name your poison, all the stuff we're familiar with, infrastructure vulnerabilities, right? But I think partly where the disconnect is, is being able to answer the question at that level or for that persona, if you like, for that audience, so what, right? So if like Log4j was, to me, was a classic example of that. So like we've got Log4j, feels like a lifetime ago now, but it was like essentially a lot of companies were like all hands on deck, you know, go find where we got Log4j exposure, get it eliminated, you know, just update the libraries, push to promote, promote to production. But what that did for most companies is it meant that there was a redirection of engineering time to go deal with a potential problem, right? Now, what that meant is for all those projects and initiatives and maybe even new product releases that those engineers were previously focused on, the net present value of the business dependencies on those projects was diluted because there was that refocus. So I think that's, you know, one of the opportunities we have as a community, first of all, is that kind of view on metrics, I think, is a gap that we need to fill for that audience, that audience being the, you know, the dev shops, the CIOs, the chief product officers and their organizations. Because then they can say, well, we care about Log4j to this point, but therefore we care about something more. Maybe it's a, you know, a non-open-source library that we care more about here because of that's the piece of business that that supports, and that's the revenue stream or the margin that it supports or the critical mission criticality that it supports. So I think that That view of metrics, that's the gap, I think, first of all there. Taking those, if we were to talk that same report that we would take to those product owners and say, hey, don't care about Log4j below this line, care about something else below this line because that's more significant in terms of how that shows up in the architecture, how that shows up in the business value. That would not be the same view that we would want to take to the board. Because, right, because, you know, there are— so I've dealt with some board members that are absolutely familiar with cyber and risk and even GRC and so on, but it's not many. The question that they want to answer is very simple questions, and this is the way I think about it, is they, you know, for the boardroom, it's like, what are our most critical— so think about, you know, essentially crown jewels programs. What they want to know is what are our most critical assets? And if we come from an IT or an OT background, we might immediately start thinking about databases and virtual machines and machineless environments. That's not what the board's thinking about. The assets of the board is the thing of value. What makes us money? What keeps us operating? What protects our margin? What delivers value to the—

keeps the shareholders happy, you know, valuation. Exactly.

And so therefore, as a CISO, just in this example, in partnership with the CIO and the CPOs and and so on is to be able to do that mapping that says— again, answers the question, so what? So we've got this system here, and we care about it so much because this is the business value that it drives or that it supports. And I'm emphasizing the word business value as opposed to annualized loss or single loss expectancy. Because again, when we think about the air quotes quantification models that we see in cyber today, most of them are focused on annualized loss expectancy, and therefore, you know, coming from producing that from, you know, the frequency of singular loss expectancy. But that's not protecting value, that's trying to avoid loss. And I think as a community of CISOs, as an example, I think that's the part that we've been missing for a long time, that we've been so focused on trying to avoid loss instead of making that connection with tying it to the value, the business value that's being delivered. So then back to your question about, you know, so, you know, are bad metrics or missing metrics, which is worse? It's like both. But I would say the thing that is worse than both of those things are metrics that are delivered without business context, without answering the "so what?" Right. So what?

Well, you know, you bring up a whole bunch of good points here. You know, one, metrics can help and do help with optimizing resources in making those business decisions because it's a business. You may be a security person, but you're part of a business. So you do need to make those trade-offs and figure out where it is to optimize those resources, not just security resources, but your engineering, your product, because they're involved as well. And, you know, there has been a blind spot and I can see why, right? Again, as you said, a lot of the CISOs have come up from a very technical background. That's how they see things and they're not blending it in sufficiently with the business aspects. And if you're talking to the board, you're talking business aspects, right? They don't care what Log4j is. They want to know, is there a problem? That means I can't push out a new product next week, right? Is there something that's going to shrink my total available market? Is there something that's going to give my competitor an edge that they're going to get more market share, right? Can I not keep my average selling price up? Is my margins going to go down 2%, right? These are the kind of questions that they want. And just to follow on with what you were talking about with bad metrics and so forth, which, and there are several out there. I've got my pet peeves. But it's always come back to me that the entire purpose really of any metric, whether we're talking security or not, is it has to support a decision. And if it's not supporting a decision, it may look pretty, it may sound great, but it's a waste of time. It's a waste of attention. It's a waste of effort. And I see that so often in cybersecurity. Where people are creating metrics and they look cool, right? They sound interesting. There's colorful graphs and lines. And yet you look at that and there's no decision to be made. Are we going to do something different? Are we going to stay the same? Are we not? Do we need to allocate resources? Do I need to— nothing. It's just interesting. And I just, it frustrates me that we're still in that space. That we don't tie what you were talking about, that value, right? And the value comes with making good decisions. And that's what the board's going to want to do.

Their job is to make decisions. And so, a couple of kind of comments on that, Matthew. And I think, by the way, for the audience, you know, we can have an interesting podcast that kind of illuminates a problem and perhaps provides additional insights to a problem that we already knew was a problem. But I think what, you know, you and I, I think the approach we always take is to make it say, hey, what could one of our audience members do differently tomorrow? Right. So it's like a real—

I'm just here to vent, you know. Yes, yes, yes. You can play the role of ventor and I will play the role of—

I'll play the role of— Okay. I'll play the role of practitioner.

Practical advice for whatever you do.

Whatever. So, so a couple of things I want to say. So first of all, one of the posts that you put recently on social media, I think it was actually on LinkedIn, and you used a graphic and it was basically a map of the world with hotspots.

Oh, that's my favorite one that I just love to pick on. I think that's cool.

I mean, it's a beautiful graphic, you know. And for the audience, if you're not familiar with it, just go Search LinkedIn, look at some of Matthew's recent posts. Recent as in it would have been in October 2023. So just for the audience, if you just go check it out because the graphic is one of those ones that we've seen, it's like, you know, where are the attacks coming from on the globe? And it's a beautiful picture of the, the earth, you know, and you've got the hotspots of where everything's coming from. It's, it's real information, it's real data. But what it's not for most people it's not actionable. And I think that's the thing, right? What we refer to as addressable risk. So you've got risks that just are, and then you've got risks that are addressable. So if you're producing that graph, it's like, well, this is where all the attacks are coming from geographically. Well, yeah, beautiful little graphic there, but colorful. So what? You know? And I think you're—

You're not going to shut your network down to Europe because you see a couple of dotted lines come across. I mean, no one's going to do that. Do that, right? It's just eye candy. Ah, exactly. So it's like, you know, calm down. Just, you push my buttons today. I'm sorry.

I thought, you know, you might, you might need to like drink less coffee for the rest of the day.

I don't know. I don't understand what that means. What, what did, what, what?

No idea. I think if there was an IV that could bring the coffee in, it would probably do that. But yes, so, so So I think, you know, again, back to the, you know, the conversation about metrics and some practical things that might help some of our— and I'm addressing primarily the CISO community, but again, like I said earlier, you could be a risk officer that's working in technology risk or cyber risk, and I view those two as very kind of tightly intertwined and therefore including IT and OT and so on. Um, but we mentioned earlier about, you know, a lot of our community globally, uh, have come up through a technology background. And I mentioned that some of us have come up through a business background, and then there's some unicorns that have both as an individual. I read a book, and I'm not promoting the book, so I'm not going to mention which book it was, but it was a really, really good read, and it was talking about the role of a CEO. And the general gist of it was, if you're a CEO that came up through sales, for example, you as an individual will know exactly what a sales cycle looks like. You'll know from the whole funnel management all the way through to contracting and then doing the net present value of the deal and the cash flow and all of that because that's where you grew up in sales. And then you become the CEO of the company and all of a sudden you're asked to make a decision about a real estate transaction. Do we sell, do we sublease, do we lease, do we buy? I mean, and that's a whole domain. You're like, "Oh my goodness, I have no idea about real estate management." It's an awesome book. By the way, anyone who's watching, if you want to know what the book is, Matthew will give you some contact details later and just ping me and I'll tell you the name of the book. But it was really good because the point that the author made, and the author is a very successful CEO, and, and it was a male, so he did come through, through the sales kind of path to become the CEO. And he likened it to almost like being a, you know, a war strategist. You know, you have your strategy, but if you've never been in the Navy, you don't really know truly how the Navy operates. Yeah, if you've never been in the RAF—

Air strategist, yes.

Yeah, but if you were, if you were in the Army, you know exactly how the Army you know, you could be a general in the army, but you still don't fully understand how RAF— well, I say RAF, Royal Air Force, or whichever air force it is. Um, so, um, so his, uh, kind of conclusion was you, you surround yourself with people who do know that space. So here's some advice. Yes. Yeah. And, and this might be super elementary, but if you're a CISO And if you came up through a business background and if you're nominating a deputy CISO, make that deputy CISO somebody who's super technical.

If you come from a technology background— That is great advice, by the way. It is. Again, the like-minded people, all your blind spots will remain your blind spots. Whereas if you blend both sides, the technical and the business leadership side, oh yes, I love that.

And equally drive up the hierarchy. So, so allow yourself to be, as a CISO, allow yourself to be corrected. If you, if you grew up in the business side, allow yourself to be corrected by somebody that came up in the IT or OT space.

And vice versa. It's a learning opportunity, right? You're going to learn from them, they're going to learn from you, and both of you are going to be better for it, and the organization is going to be better for it. So yeah, you got to check the ego at the door. I mean, none of us know everything about this. I've been doing this 35 years and I'm still scratching the surface, but I'm slow. But still, I mean, the average person's—

yeah, we have to learn. So, back to your question, Matthew, about, you know, what metrics matter in reporting to the board. And again, I'm just trying to be super practical. You're taking the role of the, I'm really irritated by all this stuff. I'll take the role of the practitioner, right? You know, so if you're a CISO that came up through a technology background, then I would say if this person is not already on your team, find this person, somebody that understands risk management, that comes from a business background, that can put the cyber stuff into a business context, and that person or that team, depending on the size of your organization, will help you to be able to forge messaging that really makes sense to the board. Because again, when you think about every other domain of risk with, with the board, you know, they want to know about market risk. They're not asking the company to reduce market risk, they're asking the company to optimize it. You know, is now the right time to push in the European market? Is now the right time to push in the North American market? Is now the right time to push in the South? You know, if you've got a geo perspective around that, if I come primarily from a technical background, I'd be like, what the heck? What do I know, right? We need to model the way we manage cyber risk in the same way as every other business unit manages their own risk. It could be, you know, FX risk, foreign exchange risk, right? So, so there we're looking at, you know, if we're doing risk management in foreign exchange, then we're like, you know, is today the right day to convert a lot of our euros into dollars or the other way around, or a lot of our yen into euros? That's a whole domain of its own, but it's It's foreign exchange risk management. And then we have credit risk management. So, you know, if we're working within a consumer environment, is today the right day to kind of take on a little bit more risk with consumers that we think might not pay us in the end? And we lose that, you know, we earn the revenue but we don't collect it. The point being is that in business management, we don't find many unicorns. That can manage every single one of those domains. Typically in risk management, what we do is we surround ourselves with experts who can manage those domains. And Matthew, I think that's one of the things as a CISO community in general, I think we've missed that. I think, I think we— a lot of us grew up in IT or OT, a few of us grew up in business, and there's a handful of unicorns that grew up in both. So again, back to— I know it's been a little bit repetitive, but I think it's important for that reason, is it— if you're a CISO or if you're a tech or cyber risk manager. If you're technical, make sure you've got a good business person as your right-hand person. If you're a business person, make sure you've got a really good technical person as your right-hand person, because then as a team— and that could be person or persons, right, depending on the size of the organization— but then as a team, you will naturally understand, now, how do we communicate to the board? And then just to restate it, Matthew Rosenquist, if you don't mind, I'll be a little bit repetitive again. What the board wants to know from a cyber perspective is a handful of things. It's like, do we know what our most critical business value assets are? The things that drive revenue and/or drive growth, or that are strategically significant. You know, something that is probably earning one dollar—

material to the company.

And yeah, the company earns a dollar today and it'll be earning, you know, $100 million like next year, right? So we have the strategic value of it, not just the, the present value. Um, do we know what they are? Do we know what the underpinning systems are that support that? Um, and then do we know how well protected those underpinning systems are? And that's really essentially what the board wants to know. So those metrics down to vulnerabilities, blah blah blah, yeah, that's great for the CIO, that's great for the CPO, that's great for the DevOps, but we need that translation to say, but what does that mean? Answering the question, so what? What does that mean to our asset value or assets, the value of our assets, and what does that mean to our critical systems? Then we can answer the questions to the board. Here's the stack rank of our most business-critical, or, you know, business-critical and business-value processes, products, services, or whatever. And here's how we know that we're protecting those accordingly. The one at the bottom, by the way, this is the system that manages the menu in the cafeteria, although they might be— they might say put that to number 1. Right. But at the top is like, this is the one that delivers our most margin. This is the one that delivers, that is most mission critical to us. That's what the board wants to know. Do you know the stack rank and how do you know that you're protecting it well?

So it sounds like it can't be amateur hour, right? So, you know, I'm hearing a lot and I'm seeing a lot and diving a lot around artificial intelligence and how it can extract, especially from large amounts of data out there, do you think AI will play a role in future cyber risk metrics, either in going from data to intelligence or intelligence into something presentable, recommendations for decisions or things of that sort? One, do you think it's going to matter, right? Or is this going to be something that really needs to stay in the mind of those expert people and they're the ones that have to tell the narrative. Or do you think that AI will be a tool that these risk professionals will use to be able to come to those conclusions faster, maybe cheaper, maybe better conclusions? What do you think? What's the story with AI and cyber risk metrics looking forward?

Yeah, that's actually a really, really interesting topic, Matthew. Obviously, and What I'm about to, you know, I'll respond to you and I'm speaking specifically around generative AI because obviously, you know, there's more than kind of one AI model. So with generative AI, the short answer to your question is, strategically, and however long that strategy takes for us to execute depending on which company we're in, yes is the short answer. I think AI is going to play a big role. Again, back to the practitioner view, I would certainly encourage our viewers and listeners to be judicious about the rapid adoption of AI, like in this moment in 2023, 2024. And the reason I say that is because you have essentially the AI, you have the whole LLMs, so like large language models and so on. And so there are a couple of challenges with that as we sit here in the final months of 2023, as we're going into 2024, is if, for example, we were to use— am I allowed to say things like ChatGPT?

I guess that's been used. Absolutely. Yeah, name it what you want.

It's all good. So there are some amazing things about ChatGPT and there are some challenging things about ChatGPT. One of the amazing things, it's got like a massive LLM. It's, you know, there is just a super rich dataset and data sources already, which is one of the upsides of it. There are two downsides to it. One is it does not understand the context of your business operations. That's big issue number one. Big, big issue number two, it is essentially public. So, you know, so if I put something into ChatGPT, that's probably not dissimilar than me doing a Google search, right? I do a Google search on something and there is AI in the background, as in Alphabet-owned AI, that says, hey, this person just searched for this stuff.

"This person just put trade secret information in. Cool. Let me index that and publish it.

Yes." Yeah. And pre-AI, I saw enough examples of where for good motive, it wasn't ill-motivated, for good motive, somebody's got a problem with trying to— they've got some syntax error in Python or C++ or whatever. They publish it out to this board and say, hey, I just cannot solve this syntax problem, you know, can anybody help me? And they— great, you know, they get the resolution of the problem, but they just put potentially IP out there into it.

Yeah, they just put their code out there. There you go. Hey, anybody can grab that.

Yeah, great. But that would have been— let's say if that was 10 years ago and, you know, those boards, you know, still are available today, but they were available about 10 years ago. So again, the practitioner's view, you know, as a CISO, and I'm again just targeting CISOs for the purpose of today's session, but, you know, I would encourage our viewers and listeners to be super excited about what AI can deliver because it will deliver. That's the point. It absolutely will deliver. But where we are as we exit 2023 and going into 2024, realize that if we're going to use some of these more public LLMs, then everything we ask it is going to have two things in common. Number one, it's going to be very public. And number two, it's going to be without the context of our business.

And if we're in a large— Which leads to hallucinations and all sorts of fun stuff from an LLM. Yeah, exactly.

Um, so, um, so, so, so, you know, my, my view on it, Matthew, is yeah, AI, um, definitely has a place. Uh, it will have a more effective place, I think, like 12 months from now, because I, I think by, by the time we reach the end of 2024 as a, as a, as a global community, um, we'll have figured out how to create these LLMs, but in the context of our own business units, plural, right? Because depending on the size of our company, we might have one product and one business unit, or we might have 20 business units with multiple products per business unit. I think about just an example like the gas and oil industry, you know, you, you have upstream, midstream, downstream, you have exploration, you have trading floors. I mean That's a great example of a business of businesses, you know. Um, but each gas and oil company has its own competitor, right? So, so I would say, yeah, don't use public, public AI right now. Uh, experiment with it to see the, to see the art of the possible. Um, but your strategy should be where you can have and develop your own LLMs that are contextual to your actual business or businesses and make that part of your, you know, 24, 36-month roadmap.

Okay, so I'm hearing be open to embrace it, but realize how immature it is and move with caution, right? Anything you're doing on public LLMs, the keyword there is a public, public LLM. So move with caution. That's, that's a good All right. So, last question for you, right? You know, we probably scared a whole bunch of people about metrics, and I'm guessing there's some people thinking, "I knew I needed better metrics. I need to be able to talk to the board better. I need to be able to talk to my product team better. I need to be able to have more insights, you know, with my peers at the C-level in regards to resource optimization and what I should be doing." Don't even get me started when budget time comes around because I have to justify all of that and I need some hard numbers. I can't just go in and go, you know, give me money because, well, we're all scared, right? And use fear, uncertainty, and doubt. So what would you say to somebody in that mindset of, okay, I know I need better metrics. Where should I start? Obviously, it's not with AI. You know, just don't run to ChatGPT and put in all your problems. But where do I kind of start? What do I need to start doing or thinking about doing? Yeah.

So Matthew, you and I have spent some time together before, but in case anyone in the audience is hearing this for the first time, so throughout today, if you've been trying to figure out my accent, it's like, is he Is he like from the UK? Is he Irish? Or what is he? Is he American? It's like, yes, yes, and yes. So my family were Irish. I was raised just outside of Liverpool in the UK. And this is relevant. You'll see why.

I'm wondering how you're going to connect these dots.

I will connect them all.

And the weather on Mars today is— where are you going, Dan?

7. Not quite yet. We haven't colonized Mars yet. But as you might not detect, I've been based in Texas for the last many years. But the reason why I'm saying that is when I was a kid, my nan, she's passed since, but she was an amazing woman and she was super funny as well. And so I just remember a couple of times when I was a kid, She'd be like, you know, somebody would walk up to us in the street and they'd ask for directions and they'd say, I don't know, you know, excuse me, can you tell me how do I get to St. Mary's Park? Or actually, if it was St. Mary's Park, excuse me, could you tell me how I get to St. Mary's Park? Is the way they, or, you know, which bus goes to the village? And her answer being completely, it's on Southern Irish, by the way, just for those of you that might be Irish, Southern Irish, Southwestern and Limerick. They'd ask for directions and she would just say, "Well, I wouldn't start from here if I were you." And that would be— and I was like knee-high to a grasshopper. I was like 7 or 8 years of age. And the person would look confused for a minute and then they would laugh. And then they'd be like, So where should we start? And then she'd give her— she'd give them directions to where they should start from and then give them directions from there. But what I learned from that is, as funny as it sounds, is there's only one place we can start from, and that's exactly where we are right now, right? So now I think all of us have either said or heard said 'You've got to start somewhere.' Now, when you think about it, that's as ludicrous as well, right? Because that's as ludicrous as saying, 'You've got to start— I wouldn't start from here if I were you.' That's like saying, 'Oh, well, you've got to start somewhere.' You know, it's the same ludicrous statement. The reality is we have to start from where we are. So back to your question, Matthew, and therefore connecting these dots, why that's relevant is You know, it again, speaking predominantly, you know, to the CISO community, but again, it could be a technology risk or cyber risk operation as well. We have got a boatload of information that's already available to us. We really do. You know, think about the average CISO, and then I'm speaking probably less to you now, Matthew, and perhaps more to our collective audience here. How many dashboards are available to the average CISO?

You know, uh, how many single dashboards do they have?

And your vulnerability dashboard, and then you have vulnerability dashboards that claim that they have some kind of risk parameter to that or whatever. Then you've got your third-party risk dashboard, uh, and it's not really a third-party product risk or third-party service risk, it's just the companies. Like, okay, are we really going to ever stop doing business with Intel? I don't think so. Are we ever going to stop doing business with AMD? I don't think so. So this arbitrary information that we have in the name of third-party risk, right? But we have this dashboard and that dashboard and this dashboard. I don't know about you, Matthew Rosenquist, but coming from Ireland and England and European blah blah. Here in the US, I do it. I'm sorry for anyone that's offended by this. I actually do drive a muscle car, so it's not an electric vehicle for me. I did grow up racing, by the way, so that's a whole other story. But my car has one dashboard, and last weekend I flew back home from, actually from Dublin, Went home, Dublin— well, not Dublin, Ireland is kind of home and England is home, but you know, flew back to the US. And I wasn't in a military aircraft, which meant that the aircraft I was in had one cockpit. So my car has one dashboard, and that flight that I took, that 787 Dreamliner or whatever it was, has one cockpit. But for the average CISO, and now I'm looking directly at our audience and anyone that can see or hear this, right? How many dashboards do you have? Right, we have so many dashboards, and in many ways we don't know what to do with them. But here's the amazing thing that we do have. We have all of the data. That feeds those dashboards. So I'll share some— and what I'm about to share is data that's publicly knowable. So when I was at Verizon and we published— not published, we, you know, we did the risk quantification thing, put it in the context of business value and so on and so forth, as opposed to trying to minimize loss. This is publicly knowable. We, they, we at the time, you know, this was shared publicly. We were processing about more than 2 billion data elements in any 24-hour period. And we were doing about 3,000, 3,500 risk assessments every 15 minutes. And it was all codified. But the value wasn't in the volume. The value is in the insights that that gave us, right? So it became a decision-making— so it's like, okay, so what are we going to do this weekend? We have a finite budget, we have a finite number of resources, we have a finite number of change windows, right? What do we do first? And so we could look at it and say, well, I'm not going to do anything about number 1 because we have a rehydration that's going to happen like 45 days from now. So the rehydration will take care of that. But I will address numbers 2, 5, and 7. But the point is, is that 2 billion plus data elements did not exist because of the program that I drove. Those data elements were already in existence, right?

So look around for the data around you, right? And convert that to what you need, and then figure out what you're missing because you may have that information, but it may not be what you need to go to the board or you need. And that's where you bring in that— that— that Ruth's professional asset, whatever.

Exactly. So, the mantra that I've been driving throughout my whole career is start with what you do know. Improve based on what you could know and always aspire to what you should know. So, Matthew—

sage words, sage words, my friend.

But I'll repeat it one more time. Start with what you do know. So, so everything you've got, whether it's coming from your vulnerability scans, whether it's coming from your infrastructure scans, your, your audit scans in your cloud environment, what— whatever it is as a CISO, right? I would say do not trust the risk score that your product providers are providing you with. Trust the underlying data that feeds that risk score. That's the gold right there, right? And then you take that and you put that in the context of answering the question of, so what? Right? So I've got these vulnerabilities. I'm running Black Duck. I found these vulnerabilities in Black Duck. Okay, so what? Okay, well, they're supporting these particular products. Okay, fantastic. Which ones are producing the most revenue? Which ones are producing the most margin? Which ones are strategic? Which ones are we sunsetting? Just using that as an example, right? But as CISOs, we have so much data that's already available to us and we're just not using it well. And so one thing that I'd— so again, I'm going to repeat that mantra one more time. Because for me, for my career over, I mean, I got married when I was 5. That's my story. I'm going to stick to it. So, so my career over more than, more than a decade, and we'll leave it at that, has always been based around start with what you do know, improve based on what you could know, always aspire to what you should know.

So your grandmother would be proud of you, I think. She would be proud.

She would for like a minute and then she would say, but that's not good enough.

All right. All right. Now, you recently founded Mercury Risk and Compliance. Real quick, what is its mission and how can people reach out to get you and your insights? What's the best way?

Yeah. So, Mercury Risk and Compliance. The name Mercury, first of all, let's talk about that. We're not talking about the toxic metal that could kill you. That's not the analogy. Mercury was, in ancient times, was the god of speed. And so I think one of the challenges that we have as a CISO community or a risk management community in cyber and tech risk is, for the most part, by the time we finish doing our assessments and everything else, that they are moment in time, point in time, and they're already out of date. So with Mercury, what we've done is we've developed essentially a proven methodology of everything that is potentially knowable at near clock speed, then it's knowable at near clock speed. And that's become— or rather, that's based on the experiences between our co-founders at some of the, some of the companies you mentioned earlier, Matthew, uh, you know, that, that trajectory over— excuse me— over time. Um, so that's, um, that's essentially is like how do we get to as close to near time as possible of what our risk profile actually is. The second foundational thing around Mercury Risk and Compliance is, um, is that we are fully centered in, um, data, what's knowable about the environment. By the way, if, if you do look and, you know, you see like it'll say Grounds Rules, that's not being— that's not me being a megalomaniac. That's, um, that, that the, the Grounds Rules, um, was a designation. There's two companies, one of which is Gartner, that are arguing over who came up with that idea first because my surname being Grounds. So it's not just an algorithm, it's not just a technology, it's like a principle. Like we talked about earlier, Matthew, it's like we're not focused on loss avoidance. What we're focused on is how do we map, for example, control frameworks right, and, and the way the control frameworks deliver value to the business. And to answer that question, we have to start at the other end. We have to start the values of the business first. And, and, you know, like, and again, just being a practitioner, um, you know, we might find that we have a control framework and maybe we have, I don't know, 350 different controls and standards and so forth, right? But, right, I see you're laughing right there. But we, as a community, we— I think we all understand that not all controls are created equal. And what I mean by that is they don't all deliver the same value, right? So if you've got a control framework of 350, 360 controls, maybe you have 1,000 controls, I've seen that too, right? But with the ability to map the business value, not the loss prevention. That's, that's a really key thing. We are not focused on loss prevention. It's like, what's the value that we are protecting, right? So, so then for each control, how does each of those controls, or how do each of those policies, or how do these standards and implementation procedures, how do each of those contribute to the business value? And the business value is not just about revenue production. It's also about, you know, regulatory citations that we have to meet under certain regulations or contractual obligations and so on. So that's really what we've done at Mercury is we've kind of flipped the thing on its head.

Well, how do people find out more information? Should they go to your webpage? Is there a conference they should be going to?

Yes. So, so, so first of all, the webpage is a great place to go. On LinkedIn, we have, we have the, the company page, Mercury Risk and Compliance, on LinkedIn as well. Any, any of the audience, please do reach out to me directly if you want to just DM me and just, hey, I'd like to know more. We are not a hard sell company either, Matthew. I think, you know, that's something that I do want to kind of share. Of course, we are a for-profit organization. But, you know, as I watch and as we watch— when I say we, like, you know, my co-founder— as we watch the industry, I think we've all as a community kind of struggled with the same things. And if you don't mind, I'm just going to go on a little bit of a tangent. Think about, like, the most recent issue with MGM. Right? So whether it's MGM or Clorox, but let's just look at MGM for an example. Um, when you look at the root cause analysis of what happened at MGM recently, fundamentally it was down to social engineering, right? And so I made a prediction that there would be, number one, a lot of noise on LinkedIn and social media about MGM and their compromise and you know, the root cause being humans, you know. And the second prediction that I made is that then people would be like battening down on, yeah, humans are the weakest link and blah blah blah. And then all of the controls that we have tried to put around humans for the last 20 years, people will double down on those same approaches. And that reminds me, I don't know who quoted this, or I don't know who originally said it, so I apologize that I can't do the APA on this. But it's the old adage of, you know, the definition of insanity is repeating the same process.

That was Einstein.

Yes. Einstein. There we go. Thank you. Right. So here we are now. You know what was Previously, the SANS top 20, you know, and whatever it is these days, probably of the 20, 3 or 4 have changed, but it's the same thing. And so as a community, we're repeating the same things like, oh yeah, we need to double down on the same controls that have failed us for the last 20 years and that just failed MGM all over again. So at Mercury—

We have to learn better. We do. We do. Yeah. And we're at time here, but I'm sure I'm going to have you back. I always love talking metrics and your insights here. Thank you all for watching. I will put a link in the description so you can go out and take a look and learn more and reach out to Gavin here. And thank you all for watching. Be sure to subscribe and catch all of the Cybersecurity Vault episodes where we chat with industry leaders like Gavin. To dive into the most relevant and interesting cybersecurity challenges, perspectives, and best practices.

Always a pleasure, Matthew. Great fun.