The B2B Podcast Index
Index
All categories
MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
MethodologySubmit
Best of:MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
An independent project byFame
SearchBest episodesGuestsInsightsMethodologySubmit a podcast
Index/Engineering & DevTools/The Industrial Security Podcast
The Industrial Security Podcast artwork

We can't - and shouldn't - fix everything [The Industrial Security Podcast]

The Industrial Security Podcast · 2025-11-21 · 55 min

0:00--:--

Key moments - from our scoring

Substance score

75 / 100

Five dimensions, 20 points each

Insight Density16 / 20
Originality15 / 20
Guest Caliber17 / 20
Specificity & Evidence14 / 20
Conversational Craft13 / 20

Cain McGladry, a 30-year cybersecurity veteran and second-time CISO, challenges the fundamental language gap between security professionals and business leaders. His forthcoming book argues that 'cyber risk is a myth' in the sense that CISOs must stop discussing technical vulnerabilities and instead communicate actual business consequences - whether that's accounts receivable disruption (like the Change Healthcare breach affecting hospital reimbursement), mass casualty scenarios at defense contractors, or intellectual property loss. McGladry works through concrete examples: a vulnerability in an accounts receivable system poses higher business impact than one in accounts payable because money flows in on 14-day cycles versus 90-day payment cycles. The core insight is that not all risks require mitigation; organizations with defined risk frameworks (NIST, ISO) can consciously accept certain risks if business leadership signs off and understands the impact. McGladry describes how CISOs create accountability by requiring executives to purchase cyber insurance for accepted risks - when a $1 million insurance premium appears on a business leader's P&L, they suddenly become motivated to fix a $100,000 technical problem instead. This reframes security from an impossible mandate to fix everything into a business decision-making process.

Key takeaways

  • →Risk communication must tie to business consequences (revenue loss, regulatory penalties, human safety) not vulnerability counts, and CISOs need to master their audience's language - MBA concepts for executives, technical terms for engineers.
  • →Not all risks require fixing; organizations should establish a formal, documented risk assessment process (NIST RMF, ISO framework) where business leadership explicitly accepts or rejects risks with board visibility.
  • →When executives accept a risk, requiring them to purchase cyber insurance on the open market and account for it in their P&L incentivizes them to fund remediation for cheaper mitigations rather than accept expensive insurance premiums.
  • →The top risks at defense contractors include catastrophic outcomes (turning a city into an uninhabitable crater), mass casualty events, and individual loss of life - very different from typical corporate IP theft or payment processing risks.
  • →Junior security staff often believe all vulnerabilities must be fixed, but experienced CISOs understand that risk tolerance varies by company stage (startups accept more unconscious risk, public companies face regulatory mandates, private equity has different risk appetites).

Guests

Cain McGladry

Topics in this episode

Change Healthcare breachISO risk management frameworkBusiness impact analysisNIST Risk Management FrameworkHyperproofCyber insurance requirements for risk acceptanceAccounts payable vs. accounts receivable systemsDefense industrial base cybersecurityRisk tolerance frameworksCISO executive communication

Questions this episode answers

How should CISOs communicate cybersecurity risks to non-technical executives?

CISOs must be master communicators who respect their audience's background - most executives have MBAs and need business language, not cybersecurity jargon. Frame risks around business system impacts (like accounts receivable money flow cycles) and material consequences (lost revenue, regulatory violations, human safety) rather than vulnerability counts or technical capabilities.

What should a company do when a new vulnerability is discovered that's outside its risk tolerance?

The business must assess whether the vulnerability truly breaks existing risk tolerance decisions, then decide whether to mitigate it, accept it with insurance coverage, or transfer the risk. This requires revisiting the formal risk assessment process and potentially changing organizational risk tolerance with board-level approval.

How can CISOs encourage business leaders to actually fix security risks instead of just accepting them?

Require executives to purchase cyber insurance for accepted risks and account for the premium in their P&L; this typically shifts the cost-benefit calculation - a $1 million insurance premium often motivates spending $100,000 on technical remediation instead, since it appears directly on their performance metrics.

Why does Cain McGladry say cyber risk doesn't exist?

He means that technical vulnerabilities alone aren't 'risks' - they only become risks when tied to material business consequences (lost revenue, regulatory violation, loss of life). CISOs often discuss vulnerabilities without defining what bad thing would happen or why the business should care, which confuses rather than clarifies risk.

What's the difference in risk tolerance between a startup, established company, and publicly traded company?

Startups typically accept risks unconsciously because they lack time and resources for formal frameworks; established companies operate under contractual and regulatory obligations; publicly traded companies have board and legal requirements. Each has legitimate, different risk strategies that should be documented and approved by leadership.

What our scoring noted

Our reviewer’s read on each dimension, with quotes from the episode.

Insight Density

16 / 20

The episode delivers substantial, non-obvious insights about risk communication and framing. Key ideas - cyber risk as a business problem not a technical one, the insurance-as-quantifier approach, the risk tolerance framework, and the intelligence cycle applied to threat assessment - are concrete and actionable. However, there are stretches of throat-clearing (weather/umbrella analogy, book publishing tangent) and some repetition of the core thesis that dilute density.

CISOs who have longevity in the space, who succeed in the space, really tie it back to business impacts and consequences. And CISOs who find themselves popping jobs every two years and changing their spending a lot of time on LinkedIn. I think they talk about technical vulnerabilities or they talk about technical capabilities that don't necessarily resonate.
We need to stop doing security for security's sake. Like I mentioned with the Alaskan gold Russian analogy, the folks who are making money in here, those tools vendors, they're not guaranteeing outcomes.

Originality

15 / 20

McGladery's core argument - that 'cyber risk is a myth' and operators should frame security around business outcomes, not technical vulnerabilities - is contrarian and refreshing against the typical vendor-driven, vulnerability-centric narrative. The insurance-premium-as-liability-accounting mechanism is genuinely novel. However, the underlying risk frameworks (NIST RMF, stakeholder buy-in, documented decisions) are standard practice, and much of the advice overlaps with established security governance.

The premise of the book is that cyber risk is a myth and that it actually does not exist.
if you do nothing, we're going to go out to an insurer. We're going to get a quote for insurance. Whatever that money is, we're not going to spend it...we're going to deduct that amount of insurance even though we didn't pay it...this is a way to keep track of that cost.

Guest Caliber

17 / 20

Kane McGladery is a 30-year cybersecurity veteran, two-time CISO, IEEE senior member, and currently CISO in residence at Hyperproof. He has advised across three continents and is actively writing a book on risk frameworks. He speaks from deep operational experience, not theory. His credibility as a practicing executive who has navigated board-level risk conversations is evident throughout.

I am a thirty year veteran of the cybersecurity industry. I've done executive advisory on three separate continents and am a senior I Triple E member. I'm a second time SISO
When I was at a CISO at an industrial design and manufacturing company, our number one risk on our risk register was turning a city into an uninhabitable crater.

Specificity & Evidence

14 / 20

The episode includes concrete examples (Equifax settlement $115M + $1B control spending, Change Healthcare hospital closure, Deep Horizon $69B, Oldsmar Florida water system attack) and specific business mechanics (accounts payable 90-day window vs. accounts receivable 14-day window). However, many claims lack supporting data: threat intel claims about nation-state motivations are asserted without citations, and the insurance-accounting mechanism is illustrated conceptually but without real case studies showing its implementation or results.

That hospital somewhere in the middle of the country of the United States that basically couldn't get any money for reimbursement for medical procedures, and they consequently went out of business because of a third party data breach.
Equafax also had to put in one billion, that's with a B on it, one billion dollars of additional security controls over a decade as part of a negotiated settlement

Conversational Craft

13 / 20

Andrew Ginter asks solid follow-up questions (clarifying non-technical framing, probing the insurance mechanism, asking about high-consequence scenarios) and occasionally pushes back productively. However, many follow-ups are gentle summaries rather than sharp challenges. McGladery is given long uninterrupted segments to explain himself, and moments where Ginter could have pressed harder on assumptions (e.g., whether all low-frequency-high-impact risks *should* be mitigated with insurance accounting) are left unexplored. The closing segment with both hosts recapping feels more congratulatory than critically examining the argument.

The question is, though, if we're not going to talk technical, what do we talk? I mean, you've said tie it back to business impacts?
when you have serious consequences, given that experts disagree about what is credible, you know, how do you draw that line?

Conversation analysis

Computed from the transcript - who did the talking, and the words that came up most.

Most-used words

risk109dollars26insurance26money25threat23cyber20accept20decision20process18risks18security17book16consequences16million15ciso14intelligence14

Episode notes

We know there are problems in our security systems, but we can't and shouldn't fix everything. What do we fix? Who decides? How do we explain what's reasonable to people who do decide? Kayne McGladrey, CISOIn Residence at Hyperproof, joins us to explore risk, communication, and a surprising role for insurance.

Full transcript

55 min

Transcribed and scored by The B2B Podcast Index.

We have new intel. The threat has changed, probability has changed, the impact has changed, and we still feel good about our previous judgment of this. Welcome listeners to the Industrial Security Podcast. My name is Date Nelson.

I'm here with Andrew Ginter, the vice president of Industrial Security at Waterfall Security Solutions, who's going to introduce the subject and guests of our show today. Andrew, how are you. I'm very well, Thank you, Nate. Our guest today is Cain mcgladry here.

He is the CISO in residence at Hyperproof, and we're going to be talking about the wide variety of risk that's out there, from you know, mundane ROI calculations to you know, extremes, trying to figure out how to avoid turning a city into a smoking crater and everything in between. Then, without further Ado, let's get to your interview. Hell Okine, and welcome to the the podcast. Before we get started, can I ask you please to say a few words about yourself and your background for our listeners and about the good work that you're doing at Hyperproof.

Sure. Thanks for having me on the program, Andrew, I really appreciated. I am a thirty year veteran of the cybersecurity industry. I've done executive advisory on three separate continents and am a senior I Triple E member.

I'm a second time SISO and currently is the CISO and residence at Hyperproof. I am responsible for kind of being the face of the company at events and on stage and presentations, but also at private executive retreats and dinners and really trying to emphasize thought leadership. And when I say that, I don't mean marketing product placement, I actually mean trying to contextualize the world that we live in from illegal, from a regulatory, from a contractual, and from a cybersecurity perspective, so that we have an informed view of the market.

Thank you for that. And our topic is your new book about risk. You know people new to the security field that often think risk is boring. They're more interested in the technology of attacks.

People in my experience don't get interested in risk until they've been a manager for a half a decade and failed to get any funding for their projects. So you know, to me, risk is the language of business. Can you talk about your new book? What you know?

What are you writing about? How's that going? Yeah, that's in progress. I'm currently in talks with publisher about getting the book published.

I decided to not self published because I want to know what it would be like to go through the whole process to understand it. The premise of the book is that cyber risk is a myth and that it actually does not exist. And that's base on kind of my experience as a CISO in that when a CISO is talking to the board about the consequences or about the impacts of a given risk, CISOs who have longevity in the space, who succeed in the space, really tie it back to business impacts and consequences.

And CISOs who find themselves popping jobs every two years and changing their spending a lot of time on LinkedIn. I think they talk about technical vulnerabilities or they talk about technical capabilities that don't necessarily resonate. And my position is that these days, smart CISOs really need to be emphasizing the risks to the business, not necessarily risks because of a technology. And that might sound like pedantry, but it's not because if you look at the way that laws and regulations and contractual obligations have been changing over time, we've seen this mental shift from well you won't be breached to well, you might be breached, but you you know, you have to tell us that you were breached and then go fix it to our current state of play, where we know you're going to be breached.

You have to be resilient and you have to maintain the obligations that you've said or that the market has defined for your business. And I think that having that level of understanding really helps CISOs to better frame their conversations, to better communicate with business leaders, and also to introduce consistency in that process. The other thing I've been doing related to this is I've been workshopping a talk. I've presented it at various ISOC two I TRIPOL Computer Society and ISOKA chapters around the country, predominantly virtual, and it's the message really does resonate.

Occasionally somebody will will say, well, a vulnerability is a risk because a bad thing could happen, And then I think is that they start listening to themselves talk they start realizing, well, a bad thing could happen, but you didn't find what the bad thing was, and you didn't find it why anyone would care about the bad thing and that's the problem we have in cybersecurity often is the inability to communicate that if the bad thing happens, what was the bad thing? And then qualitatively, why should anybody care?

From a business perspective. Now, some people might say quantitative is great. I know some folks on the fair board, they are very reasonable people who have a nuanced view of quantitative versus qualitative metrics. But I think overall we need to pivot our language because right now I've watched boards and ciso's talk past one another on three continents, and it's kind of tiresome.

And I'd like to see that change by fundamentally attacking the language problem that underpins all of this misunderstanding. I have to agree that, you know, it can be challenging to find the language of business and vulnerabilities. You know, a vulnerability assessment that comes back and says eurot system has twenty thousand unpatched vulnerabilities is not really useful. That confuses things more than anything else.

So you know, I very much agree with that. The question is, though, if we're not going to talk technical, what do we talk? I mean, you've said tie it back to business impacts? Do we just talk about consequences?

Do we talk about attack scenarios that could bring up about the consequences? Attack scenarios that we sort of believe we can defeat with a high degree of confidence, So we don't need to spend a lot of time on versus ones that we don't defeat with a high degree of confidence. And you're going to have to give me a budget of ten or twenty or fifty million dollars to solve that problem. You know, if we're not talking about the technical vulnerabilities, what are we talking about?

Is it a tax? Is it something else. When a CISO is talking to people, I think they need to be a master communicator and be aware of the audience that they're speaking to. So if CISO is talking to other executives or their board members that they're briefing about something, we need to be respectful and mindful of their intellectual background.

Because most of these folks have got an MBA. And this isn't a clarion call for every CISO out there to go get an MBA. It's an understanding that intellectually they may not have had a great deal of exposure to cybersecurity terminology and some of the things that we take for granted that the assumptions that everyone knows this stuff, whatever it might be, they probably don't and that's not their fault, that's not their responsibility. Our responsibility is to educate them enough so that we can have a meaningful conversation and to bridge that communications gap.

When talking to other executives, I will say I occasionally push for MBA programs to have more include of cybersecurity to the college and the university I work with here, But beyond that, it's still a fundamental understanding difference of where folks are coming from educationally, and then when we're talking to our technical teams, folks who did not come up through an NBA program but may have a computer science background or a technology background, a cybersecurity background, it's very necessary to talk in technical terms because we can have that conversation.

But I think all CSOs at this point should be encouraging their staff or demanding their staff also learn the language of business and start to communicate in the language of business. And in case that sounds abstract, let me give you a worked example. Every business has systems, and systems are a collection of stuff that components of piece parts that do a thing for business that's vague. So let's say about accounts payable and accounts receivable.

Now, accounts pay that's money going out the door. Accounts receivable is money coming in the door. Most companies negotiate contractually. This is important for CISOs and other folks to know that for accounts payable, you've got about ninety days contractually to pay a supplier or to pay somebody.

But if you look at accounts receivable by comparison, it's about two weeks, about fourteen days. So that's money that's coming in the door. And something that I've seen consistently happen is when your lead red teamer comes to you or your lead Blue teamer comes to you, whatever their title might be, and say, hey, we found this vulnerability. Okay, cool, which system does it affect again?

And if they say accounts receivable, right, that's that money that's coming in the door. Then we know we've got about fourteen days to go fix it. And it might be a higher impact vulnerability then something that affects accounts payable, because in accounts payable, that's that ninety days, that's three months. The worst thing that happens is your CFO, your chief financial officer has to wait a little longer to pay a bill.

Most CFOs really don't get anxious about having to wait a little longer with cash in the bank to go pay somebody. And I think that as we encourage our technology teams to frame in systems, that's the first part of it, so we can understand, like, which of these systems does it materially affect, and then what's the level of impact again, if it's we can't get any money coming in the door, which is something we saw happened with Change Healthcare, where there was a hospital somewhere in the middle of the country of the United States that basically couldn't get any money for reimbursement for medical procedures, and they consequently went out of business because of a third party data breach.

Now that data breach affected their accounts receivable process. I think we need to have that conversation of so, what's the material risk here is that we can't do this anymore, we can't do this for a little while, And then finally, what's the risk of that are we losing money? Are we not able to pay our bills? And then taking that framing and extending it to other spaces.

We need to understand what is this risk and do we care about it. When I was at a CISO at an industrial design and manufacturing company, our number one risk on our risk register was turning a city into an uninhabitable crater. And it's an interesting thing for the top of your risk register to say, well, we could just you know, remove an entire city out of the United States, and that's an unacceptable risk. And then we have the secondary risk of well only part like, you know, we have mass loss of human life.

And then our third risk was, you know, we have an individual loss of human life. All those are obviously not great things, and we prioritize those accordingly in the risk register. I think that most companies don't have that as being a regular thing that by taking a contract you could accidentally, you know, remove a city or cause mass human casualties. Interesting thing of working at the defense industrial base, right, But I think a lot of companies do have things like, well, we're going to lose intellectual property.

Okay, Well, what's your risk tolerance for that? And what's the risk associated with a loss of your intellectual property? Does that mean your customers won't buy your thing anymore? Does that mean you have contractual violations?

Does that mean that you're going to be called up on Capitol Hill, which is never a good time. I think that we need to get to that level of granularity. So when we hear there's a vulnerability or a cyber incident that it has occurred, we need to be able to contextualize it very quickly. Is this a risk that the business found to be tolerable or intolerable?

And then strategize accordingly because we can't. It's impossible. No one has enough money or time or resources to fix all the things, whether those are vulnerabilities, or whether those are risks, or whether those are software patches, or there's just not enough time in the day and there's not enough will of the business to go do those things. So we need to be thoughtful and always be framing to what is the risk, what would happen if the risk will materialize?

And then did the business accept that? And I think that last part just to emphasize that it's something that junior security personnel frequently miss. They frequently think we have to fix all the things. We can't have this risk to this system because it would be bad because shrug reasons.

I guess if the business has said this is an acceptable risk, or we're going to take insurance to mitigate this risk. Okay, cool, that's not our remit to say that it's good or bad. That's just what the business chowse. So Nate Caane covered a lot of ground there.

Let me paraphrase real quick, just to sort of keep people all on the same page. He did not use the word credible, But I'm reminded of a recent episode with Kenneth tittle Stuck where we talked about credible threats, credible attacks, credible consequences. Not all consequences of cyber attacks that we sort of on the front line looking at the nuts and bolts of it. Not all of those consequences are credible.

Not all of them are reasonable to believe will come after us. Theoretically possible. Yes, reasonable is a different judgment. And even if you know we believe, we will argue that a consequence is a credible threat given the threat environment.

Not all risks that are that pose credible threats that are credible consequences. Not all of them are necessarily mitigated or accepted or sorry, mitigated or transferred to insured. You know, some of them we just accept. This is a business.

This decision has something to do with the whether the consequence is acceptable or not. You know, is it is it something we can live with? And you know, so the bottom line is it's it's complicated. There's a question of, you know, are these credible threats.

There's a question of you know, who's going to decide. That was an episode with Tim McCrae. We on the front line should not be deciding what risks to accept and what risks to address and what risks to buy insurance for. That is a business decision.

And what's important here is communicating consequences and credibility and you know, risk to the business in words that make sense to the business, so that the business decision makers, usually many layers up in the organization from us frontline workers, can make an informed decision. And sometimes we'll be surprised by that decision. You know, sometimes we don't understand the business impacts and they do. Sometimes the business might be in a hard place and might have to accept certain risks so that they can spend money addressing other even bigger risks to the business.

So, you know, communicating all this is important to the business decision makers. The example is a scenario where in a sense, we have a steady state, we've made decisions about what's tolerable what's not. We have a new vulnerability. The vulnerability that we've discovered, be it a software vulnerability or something else, is exposing us in a way that you know, we or at least the people reporting the vulnerability understand, is sort of outside of our risk tolerance.

It's something just broke. We need to fix it. And you know, in a sense to me, that's that's simple thing. If it broke and it's outside the tolerance, well we do have to fix it.

It is a more challenging conversation, especially with the people who control the budget. It's a more challenging conversation when we have to talk about you know, look, I think we've set our risk tolerance at the wrong place. I think we need to, you know, be less tolerant of these risks because of X, Y and Z, and you know, often it generally has to do with a discussion of the seriousness of the consequences. People kind of understand what we're dealing with, unless it's a completely new project or building and the changing threat environment or changing expectations on a part of the government or the regulator or whoever.

In terms of addressing these consequences, when you have to persuade people that they need to move the needle instead of just, you know, fixing an a problem that pomped up, How do you do that? I'd say it's at many companies it's an annual exercise. I think at some companies it's a more frequent exercise. And it's having a consistent risk assessment process where you know, you can use NISTS Risk Management Framework, you can use ISOs Risk Management Framework.

Goodness knows there are other ones in the world. But having a defined process really does help, and having it written down really does help. And the reason I say that is I don't like subjectivity in this, and I don't really think there's there's a right or a wrong gere. The only thing I could say that could be wrong is not having a defined process that you follow consistently.

If I if I look at the way that things are going right now across the market, the cyberseecurity stance, the risk tolerance stance of a startup is very different than the risk tolerance stance of an established company is very different than the risk tolerance of a publicly traded company, and again is very different than the risk tolerance of a private equity backed company. All of those have very different strategies that all tie back to what their risk tolerance is. A startup that is trying to make a name for themselves in the world, trying to just ship a product and maybe make that first million dollars probably will accept a lot of risks, whether consciously or unconsciously.

Most of it's probably unconsciously because they haven't had the reason to write it down and because if they just got seed funding, they probably don't have the time. A company that's got an established reputation by comparison, especially if they're a publicly traded company, have both contractual and legal and regulatory requirements that they're obligated to meet or to accept that yeah, actually we might not meet those And again that's a conversation that has to happen at the executive level to say this is a tolerable risk.

I have worked with clients over the years who have said that the risk of a lawsuit that has a seven figure or eight figure or nine figure damages is fine. They'll just pay their way out of it and move on and they don't really need to go fix the risk and security professionals inevitably end up in pearl clutching mode where they say, well, you know, there was a known vulnerability and the company didn't fix it and all of these terrible things happened, and somewhere the company that had the bad thing happen made the calculation of yep, that could happen.

We're going to accept that, we are not going to go fix that. And I think that it's not really the rule of the CISO to say this is right or this is wrong. It's the role of the SISO to work with the other business leaders, including chief counsel, the chief executive officer, the chief risk officer, if you've got one, the internal audit committee, the other, you know, the other standard participants, really to figure out what is our risk tolerance, make sure that that's okay with your board of directors, make sure that they've had a chance to see it and comment, and does that really gives some clear bright lines for what's acceptable and what's unacceptable, and then to operate under those circumstances.

It gives everyone very clear guidance and it gets us out of this this you know, futile conversation that we're going to go fix all the problems, are going to go fix all the things that broke, because some of those we might be okay with, maybe not personally. But if the business says it's fine, then it's fine. We don't really have that say to say, well, it's not fine unless we can make a compelling argument that says to everyone else on the risk management committee that this is something where we need to change our risk tolerance and here's your compelling evidence why, and here's your compelling reason why.

Because that's going to shift strategy, and it's going to shift resources, and it's going to shift conscientious of those effects of trying to decide that we're going to change this now for CISOs who I mentioned this in the book as well as in my talk, for CISOs who think that they want that they have a revolving door situation with their risk management process where the business flags the risk that I don't know. Let's let's work a risk. Let's say that the use of AI may lead to lawsuits totally no more than a hundred million dollars right, the use of AI with our intellectual property lawsuits.

One hundred million dollars. Right, that's the high level risk. Now there's a lot of different ways that that could go occur, but that's the basic risk idea. If that's your risk, and you still have every executive saying, yay, it's fine, hundred million dollars or whatever, that's that's no big deal.

We're not going to worry about that. For CISOs who want to start changing that, what I've seen my friends who are CUSOs due to some good effect here, is to say, look, to accept a risk, first of all, you have to sign off on it. Not already causes some discomfort among executives because that means they have to acknowledge that they said that it was okay and a piece of discoverable evidence. And then the second thing that I've seen CISOs do to great effect is to say, cool, when you accept a risk, you have to buy insurance against the risk on the open market for that quarter that says that it's going to cover the breach.

It's going to cover the breach notification, it's going to cover the litigation, it's going to cover setting up the call center, it's going to cover the technical remediation, it's going to cover the external forensics firm that you have to employ if it's not a panel approved one from your insurer. Right, you have to pay for all of that when you go accept a risk, and in most cases not all cases, having folks sign and then have to buy insurance against the risk. Materializing changes the conversation, and it doesn't do it in an obvious way.

What it does is it affects that business leader's P and L, their profit and loss statement if they accept a risk and then they have to go buy insurance, and that insurance costs I don't know, a million dollars. Let's say make the math easy. That means they're making a million dollars less that quarter. That's the type of thing that shows up in their KPIs or their OKRs or however their performance is being managed.

And that's where we can start to have a conversation of cool, so the insurance costs a million dollars, If we'd like to talk about fixinated costs one hundred thousand dollars. They can then do the math in their head and say, huh so for one tenth the cost I can maritilate this risk and only take one hundred thousand dollars hit to my p and L as opposed to a million dollar hit on their P and L. Pretty Much everybody's going to say, yeah, that sounds pretty good. But if we can't phrase it that way, if we say, well, if you accept the risk, you're accepting the risk and shrug, don't know, that's where we get into trouble.

That's where there's a lot of challenges that happen. And that's where i've CISOs get hung out to dry because if no business leader accepted the risk and the CISO has been established as the person who somehow magically owns all of the business risks, which I still don't understand that one, then I think that's where CISOs have a lot of personal and professional liability that comes up that I think CISOs with longevity are learning and they're learning how to. Avoid so Mate, I thought that was an interesting insight on the insurance at using the insurance, you know, kind of bucket when you're talking about accepting risk.

Why did that stand out to you? His post to anything else though you were talking about in this interview, what. He's saying, is that if if a business decision maker, you know, Looksie in the eye and says, how much would it cost to fix that, you know whatever, three million dollars, twelve million dollars and says, well, you know, what are my options? Well, it's risk.

There's the standards, you know, three or four options. You could change that is sign of the system so that the risk vanishes, it doesn't exist anymore. You could mitigate the risk, you know, put security in place to reduce you could transfer the risk, pay an insurance company. You could accept the risk and do nothing.

How much does doing nothing cost me nothing? You're not doing anything? Okay, I'll do that, leave all the money in my pocket. That's you know, that's a trap that's easy to fall into.

And he's saying, no, no, if you do the accounting internally and say we're you know, your division that you're responsible for that should address this risk, or that's you know, responsible for the risk. If you do nothing, we're going to go out to an insurer. We're going to get a quote for insurance. Whatever that money is, we're not going to spend it.

You've decided not to spend the money. You've decided we can tolerate this risk. Great. But what we're going to do is we're going to do in our bookkeep We're going to deduct that amount of insurance even though we didn't pay it.

We're just going to take that off of your earnings this year for your division because you've incurred this risk, and this is how big a risk the insurance company thinks you've just incurred. And this is a way to sort of make the risk real. Accepting the risk makes it real for the business decision maker. Accepting the risk also costs you, and here's a way to keep track of that cost.

Is the insight that I've never heard anyone suggest that before. I thought, that's clever. Yeah, I see what you mean. Do you find in your experience that folks sometimes think about risk as like a free hit, Like, Okay, I'll accept a certain amount of risks and then just move on in the way that you're sort of describing there.

I actually hear people looking at the problem that way fairly regularly, but they don't phrase it that way. Nobody talks about it that way. I see this not so much in the high frequency, low impact area, where you can sort of easily do an ROI calculation. I see it in the low frequency high impact area.

You know, when we say low frequency, it's things that may never have happened. But we look at what's you know, what the enemy's capabilities are, and we say, you know, this could happen if they got it in their mind, they could do it to us. Will they get it into the mind or not? Is it we start having, you know, and we're talking about things that have never happened yet.

And what I hear is, you know, business decision makers saying things like, well, how about we wait till it happens and then we'll know how often it happens instead of spending money on it now. And they put the money in, you know, figuratively speaking back into their pockets, saying we're not going to do anything about this. We're accepting the risk. If you know, again, if we dock from that divisions that business decision maker's numbers for the quarter or for the year, if we dot the money that they would have had to pay to buy insurance, saying well, you decided not to buy insurance.

That's a legitimate business decision. You have, you know, spending authority to make those decisions. But by accepting the risk, you have actually accepted a liability. Here's a way to quantify that liability.

Figure out what the insurance would have been caught that money back. That's you know, to me, that's that's a way to take what would otherwise be a very difficult decision of a discussion about things that have never happened, and turn it into an ROI discussion. Well, once you say, makes sense when you know, it's great to use insurance premiums when we're trying to do ROI discussions with business decision makers. As you said, you know, the math is easy, you can do it in your head.

It gets trickier for high consequence events. Now concrete example. You know, Deep Horizon was not a cyber event, don't get me wrong, but it was a really big safety incident in the oil and gas industry. And I believe that when all was said and done, all of the remediation was done, all the lawsuits were over, British Petroleum announced that the whole thing had cost sixty nine billion dollars, so you know, sixty nine times ten to the ninth and they moved on because they were big enough.

BP is big enough that they can pay sixty nine billion dollars and not go anywhere near out of business. The question is, you know, there's no way, as far as I know, correct me if I'm wrong, there's no way to buy insurance for a sixty nine billion dollars cyber impact. And so you know, you have no choice either you mitigate this and reduce the risk, or you accept the risk. Is it reasonable to accept a risk that big just because you're big enough to do it.

I mean a lot of businesses it would put them out of business. They would probably say it's not reasonable. You know. Is it reasonable for a really big business to accept a risk that big just because they can?

Or is that is that just setting you up for you know, I don't know, a shareholder lawsuit or something because the board is making decisions that are perceived by the public as not reasonable. Can you talk about reasonability and the really high end of consequence. When I think about that? Other than you know, he made me think about Tony Hayward briefly as yet another casualty of the deep water horizon because of him putting his foot so firmly down his mouth.

I think even Harvard has a business school class just about Tony Hayward super fun. I think that some businesses will accept those risks as being very large because they are capable of accepting the consequence of that risk, or at least they believe themselves to be. Let's take an example here, a commercial example that I think affected about half of your listeners. So Equifax is a company that does stuff.

They they had a data breach, and stuff that they do is they collect everybody's information, their personal identifiable information, financial data, and so on, and they aggregated, bundle it all up and say, hey, this person might be okay to give a loan to or this person should get a better credit card than somebody else. That's kind of their business model. They had a bit of a problem and they lost about the data of about half of all of Americans living at the time. It's kind of a big problem.

They got in trouble with multi state litigation as well as with GLBA, and there was about one hundred and fifteen dollars one hundred and fifteen million dollars in settlements if you add it all up from the legal fees and from the multidistrict litigation and from the various federal investigations. One hundred and fifteen million dollars is really something that they could just shrug off and go, yep, that's a that's a slap on them. I think the risk that they did not adequately calculate, and I think that this is one of those things that many businesses do not adequately calculate.

Equafax also had to put in one billion, that's with a B on it, one billion dollars of additional security controls over a decade as part of a negotiated settlement, and I think that the insurance probably could have paid some of that one hundred and fifteen million dollars, but that billion dollars to cyber better to put in adequate controls, to put in adequate processes, to put in adequate tools. Insurance is not going to cover that. And I think that as as risk leaders, and this is not just ciso's I think chief risk officers have to be aware of this.

We've seen many recent incidents. If you think about the Office for Civil Rights ocr their enforcement of HIPPA based on companies having done inadequate risk assessments, they often will first of all implement a fine, but then there'll be negotiated settlement that says y'all have to do better, and you're going to spend money to do better. And I think that needs to be part of the calculation for those companies to say, cool, so the insurance is going to cover part of this. But if we have been neglecting, if we have not been putting in place the adequate controls and evidence of those controls being adequately operated, then that becomes an additional calculation of hey, we could have to spend money on this stuff again.

Some companies are going to say, and that's okay. They're going to say, that's fine, we can put it off because you know what, for not spending that dollar today, we can do something else with that dollar. Other companies are going to say, well, that's that's an unacceptable risk for us, according to our board or according to the legal requirements that we've decided, that are material risk to our entity, and this consequence, they'll do something about it. Does that make sense?

It does to a degree, But let me dig deeper. The U the billion dollars on security is that greater than the business would naturally have paid by itself to address the risk. I mean something happened, and you know, the business was forced to pay a billion dollars to beef up security. Is that money they should have spent on their own anyway, or is that somehow materially greater than what they would have had to do on their own had they done it up front.

I don't know. You know, it sounds like if they had to spend a billion dollars anyway, then delaying it as long as possible, you know, is something that a spreadsheet would say is a good idea. But if something, you know, if one hundred million dollar upgrade turned into a billion dollar upgrade because the government got involved and said, no, no, you have to do way more than you would otherwise, you know, can you talk about the difference there? Well?

I think the part of that difference is just the time spent reporting back that you're doing the thing that you've negotiated as part of your legal segment that you have to go do, right, That's part of the cost calculation that's in that billion dollars or in similar settlements. There's just a reporting obligation there that nobody gets excited about, and it's a report to your regulator or to whoever you've got the negotiated settlement with, none of which is fun and a lot of which tends to be a negative influence on morale, But it becomes a necessary obligation that falls through not having done the adequate risk treatment in the view of whoever you got in trouble with, whether that was HIPPA or whether that was GLBA, or whether it was the FDC, you name it right, depending on who you've ultimately ended up having to settle with, and that might sometimes be multiple parties.

If you've got multi district litigation going on again, it's going to drive spending that has to happen. I think ultimately it's a question of two things. First of all, was the SISO able to make the compelling business argument and collaborate with the other executives and business leaders that that was money that they should have been spending right, and then writing those decisions down is part of the risk assessment plan that the CISO and the Chief Risk Officer proposed that we spend this money on these controls, and after thorough discussion, we decided we're going to accept the risk and not implement those controls.

And here are the signatories of everybody who made that decision right, and that's what you look for as a gold standard. And I say that because it reduces the risk of blowback on everyone involved. The CISO did a reasonable job of trying to present a case. The chief risk officer in that example, perhaps counsel as well made a reasonable attempt.

The business chose to not do something that's okay. What's not okay is not having that written down, And what's not okay is not having a collaborative process by which a business reaches that decision. Can I ask you a sort of a related question we talked about the physical scenario. I mean, industrial security is often about preventing physical consequences, not just financial consequences.

The physical scenario, you know, defense industrial base. You're doing a project, you're inventing something new that, if it goes wrong, would turn a large city into a crater. That's clearly from pretty much everyone's perspective, and unacceptable consequence. But if that consequence could be brought about by a cyber attack, the question becomes how thoroughly should we protect that system?

I mean, the answer is really really thoroughly. The real answer is what does that mean? Given that experts in the field disagree as to what constitutes a credible cyber threat. You know, for any cyber defensive posture, you can imagine an attack that defeats it.

Now your imagination might you know, might have to stretch. The more thoroughly you defend something, the more you got to wretch that imagination. But at some point you have to decide, you know, this bizarre thing I've just imagined is probably never going to happen. It's just not reasonable to spend the extra ten twenty fifty billion dollars to protect against that bizarre thing.

At some point you've got to draw the line and say this is a credible threat. The rest of it is not. When you have serious consequences, given that experts disagree about what is credible, you know, how do you draw that line? Do you do you use analog protections exclusively and say, just wipe out the cyber threat entirely, or you know, can you stay with cyber and accept certain risks because it's not reasonable to believe they will ever come at you?

How do you deal with that? Again? In part just period and when experts disagree as to what's credible. Something that I've learned from having hired folks out of Fort Meade from the intelligence services in the United States all wonderful people.

Is if you get three intelligence analysts in a room and if they're talking about something, if they all agree, they know they need to redo it. And I think that's something that we need to have in cyber is that skepticism of our own analysis and that we shouldn't all necessarily agree, but we should have a defined process by which we make a determination. And this is in the intelligence community. It's called the intelligence cycle, where we can ingest facts.

And in cybersecurity you'll hear that SOULD is cyber intelligence. No it's not. It's not intelligence, it's a product. You're buying some facts about what threat actors might be doing.

You need to contextualize that using the intelligence cycle to figure out is this applicable to us? And then how applicable is it to us? And then what are we going to do about that based on that information. So to your example of turning a city into a crater, something that we've often seen in cyber lately and in ot and is attacks on water systems, whether it's oldsmar Florida, which turned out to be an old goal, an own goal, or that thing that happened up in New York where somebody from Russia allegedly got in and was able to move a dial one way or the other.

I think that the question becomes, what's the realistic threat here? What is the thread intelligence saying? And uniformly, if we go out and troll what's going on, it's prepositioning there's not some adversary out there right now who's saying cool, we're going to pop shells and start popping off dams and just releasing chemicals into the water supply, and we're going to start releasing all this floodwater into these rivers or these municipal systems. Now, what they're trying to do is just establish a foothold.

That's what most of the threat intelligence would tell us today about what adversarial nation states are doing. And if you go look at like the commercial threat intelligence about what the the non espionage, non state based actors are doing. Your criminal gangs, none of them aren't getting excited about ransom wearing a dam and saying cool, nobody can have water anymore. Because I think at some point you breach a level of norms where you're going to get a more comprehensive response from a government entity than we typically would associate with cyber which would be like we'll sanction you.

I think if somebody were to shut off the water supply for a major city, they'd probably have agents in country at their various residences and businesses having a very stern talking to with them, to put it mildly, and I think that as leaders who are evaluating these risks, if we're not looking at threat intelligence, if we're working at any level of mature organization and we're not looking at facts of what's going on in the world that are being packaged up and then applying our own intelligence cycle to us, I think that can lead to overreacting or underreacting if you don't know what's going on.

Like, think of it this way. If you go out of your house. Now, I'm not a person who I live in the Pacific Northwest, so for me, taking an umbrella out isn't something that we do here. So me, I look out the door and I go, huh, it might not be raining right now.

I'm not going to take an umbrella. But I've traveled in other parts of the world where umbrellas are very normal. If you don't check the weather. If you're a person who likes having an umbrella and you don't check the weather, and you go out of the house and you're like, darn, I don't have an umbrella and I wanted to have one with me, it's pretty much the same process of if you don't check cyber threat intelligence, you don't know what the adversaries are up to on a given duration of time they seem to have I don't know if it's agile that they're following at this point or if it's still on a quarterly sprint basis for targeting.

But if you aren't aware of what they're doing and then later something bad happens, the perverbial it rains. You're gonna say, well, geez, I wish I knew that was. And that's what we get out of cyber threat intelligence is that perspective of here's what's being seen at the telemetry level, here's how we can apply that to our own organizations, and if we learn something from that, then that's an opportunity to use our risk assessment process and say we have new intel. The threat has changed, the probability has changed, the impact has changed, whatever it might be and then rerun the exercise and say, do we still feel good about our previous judgment of this, which could have been like, hey we'll buy insurance, or hey we'll apply some controls, or hey, that's an acceptable risk.

But again we have to take that and follow our process. We can't just make a unilateral decision unless it's something where it's such a self evident thing like hey, the city will turn into a crater. That's one where you don't usually have to run the whole process. You say, yeah, let's let's put it in places defense and depth in order to emulate that problem from materializing.

So Nate I asked about that really high consequence event, you know, turning a city into a crater with a military industrial based development, and you know, he talked about threat intel for a while, but he came back to the creator example, and what I heard him say was, look, when it's that consequential, ninety nine times out of one hundred, you have to do something. You've got to put some defense in depth in And this is what I see in the industrial space. When you've got really serious physical consequences, you have to do something.

And you know, for lesser consequences, what I heard him say was, you have to have a process, and this makes sense. You have to have a process. Use the process, use it consistently, document the results, have the you know, the decision makers sign off on the results. This might, you know, I'm guessing, might tend to make the decision makers just a little bit more cautious because it's their name going on the decision.

But you know, they make these decisions. This is this is their business, this is their living. They make business decisions for a living. But you know, it makes sense to have a process and document the results.

Although he was putting a lot of emphasis there on beyond that, just keeping up with cyber threat intel. I like to hear that. It's how I get my checks paid. Sometimes I do wonder whether everybody needs to know about the latest because defenses sometimes stay pretty sturdy.

But in general, keeping up to date important for most absolutely. You know, I read the publications. I read what the government agencies produce in terms of threat intel. You know, Waterfall puts together an annual threat report talking about the threat environment.

You have to keep up with what the bad guys are capable of, and you have to keep up with your best estimate of you know what today's motivations are. You know, you've heard me say many times experts disagree. We've talked about some of that in this episode. Very often the big thing they disagree about is the adversary, the capabilities of the adversary, the the motivations of the adversary.

They disagree about the meaning of the threat intel. So but you know, without the raw data there, without the threat intel, you've got nothing to argue about. So, yeah, it is important, and as far as I know, everybody follows it, lots of food for thought there. I will be thinking about, you know what you said in this episode before I let you go.

You know, I'm also an author. You're you're an author, You're working on your latest book, you're negotiating with a publisher. How's that going? Is there?

You know, is there any advice you'd like to give to other would be authors in the audience? Yeah? So I think that the two things that really come to mind, possibly a third. First of all, go get an overview of how to get a book published.

Go find an overview. Don't just ask an AI, hey how do I get a book published? But actually go figure out, like what is the overall process. And I say that because when I launched in, I opened up Notepad and I started writing, and I mean Notepad dot Ex on Windows, because I really can't handle the red squiggly underline that tells me that I made a typo.

I just figured, you know why, I'll get the words out and then we'll deal with it. It turns out that is not a great strategy for doing any kind of large scale content like book length stuff. And the second thing I'd say is choose a tool that's going to meet your needs, but don't over rotate on that tool. And the interesting thing on that is that in looking at the book publishing market, there are a lot of tools available.

Now I'm just using bog standard Microsoft Word because I am secretly boring, and also because it does references quite well. It turns out I hadn't known that when I started. But there are a lot of other tools out there that you can spend money on and that will help you write a book and that help with formatting stuff. Here's the trick to it.

All of those would like to charge you money, and none of them would like to guarantee that you're actually going to get a book out of the end, and I think that that's one of the things that we often see in cybersecurity, where there are a lot of folks kind of like the Alaskan gold Rush, the folks who were making money were the people selling the pickaxes and shovels. In cybersecurity, there are a lot of vendors that are selling security solutions and not guaranteeing outcomes.

And in the book publishing world, pretty much the same thing. There are a lot of different things you could use to write your book. Pick one, work with it, and hope that it's cost effective, because they're not guarantee that at any time you'll ever actually get a book published. Rather, they're just guaranteeing they're selling you a tool that you could use to write some words down in a consistent format.

And again, don't don't use notepad because it was one of my lessons learned. Well. Thank you Kane for joining us. This is certainly, as I said, something I'm going to be thinking about before I let you go.

Can you sum up for us what should we take away from this episode? I'd say there's two things really. The first is that cyber risk is a myth, and that CISOs and other senior security leaders really need to tie their security initiatives to business risks and also business enablement, so that we're actually helping the business to function in spite of being in a elevated risk or threat environment. I think that's the first thing, and then the other thing is we need to stop doing security for security's sake.

Like I mentioned with the Alaskan gold Russian analogy, the folks who are making money in here, those tools vendors, they're not guaranteeing outcomes. We need to make sure that those tools that we're selecting, those controls that we're selecting tie back to either business enablement or to business risk. And if you'd like to learn more about this, or alternatively, if you have insomnia, please follow me on LinkedIn. I am Kane mcglattery.

Thanks Mom and dad for the unique name. There is exactly one Kane gladtery on LinkedIn. And if you'd like to find out what I'm doing at hyperproof for intelligent risk and compliance management, check us out at hyperproof dot io. And finally, I want to thank the i Tripoli, the Institute of Electrical and Electronics Engineers for this is the fantastic work that they're doing for creating a lot of thoughtful standards around cyber risk management and how to best address some of these new emerging risks.

Andrew, that just concludes your interview with Cain. We have talked a lot on the show about risk. Is is there anything new for you to say about it to close out our episode today? Absolutely.

I mean, one thing I got from Cain here is, you know, he's writing a book on risk, saying we should all stop talking about risk. And I'm reminded that now. I can't remember if it was Doug Lease or Tim McCrae on an earlier episode, but you know they said, look, most people talk about risk and they don't even know what it is. What's the definition of risk.

It's the effect of uncertainty on the mission of the business or of the organization in this case of business. And what I hear Cain saying is, you know he's talking about don't use the word risk one hundred times in a twenty minute presentation. Talk about the mission of the business, talk about the uncertainties that business faces, talk about the effect of uncertainty on the business. That is going to get you farther with business decision makers.

So that makes a lot of sense to me. Sort of, that's in the abstract, in the concrete. I especially liked the idea about getting a quote for insurance, using insurance as a way to quantify risk, because everybody struggles with low frequency Okay, it never happened before, or happened once before, once in the world eight years ago, low frequency high impact events you know, hole in the ground or or you know, mass casualty event, low frequency high impact events. Nobody knows.

Everyone argues over these things. Here's a way to turn that argument into an ROI calculation. Get a quote for insurance. See how big that quote is.

Take that number off of your earnings for the the You know, even if it's just a paper calculation, you know your bonus is less by that much because what you would have paid for in insurance, even if you're if the company is big enough to self ensure, you should still be accounting for the premium, the policy premium that an insurer would have charged you, because you know, that's sort of a liability the company is building up. It will bite them eventually, and this is a way to account for that.

And that sort of makes uh that's a way to do ROI in this very difficult space of low frequency, high impact events. So I like that inside. I'm going to use that in the future. Well, thank you to Cain for sharing that with us.

And Andrews always thank you for speaking. It's always a pleasure. Thank you. This has been the Industrial Security podcast from Waterfall.

Thanks to everyone out there listening.

Related episodes across the Index

Other episodes covering the same guests and topics, from across The B2B Podcast Index.

  • Responding to Ransomware Attack [Case Study] | Interview with Yannick HirtSecure & Simple · on Business impact analysis85 / 100
  • Future-proofing and StorytellingCyber Security Business · on NIST Risk Management Framework80 / 100
  • Empowering Teams to Exercise Judgement in Privacy DecisionsPrivacy in Practice · on ISO risk management framework67 / 100
  • Infrastructure Resilience & Business Risk | DailyCyber 294 with Ben WilcoxDailyCyber The Truth About Cyber Security with Brandon Krieger · on Business impact analysis64 / 100
  • Security vs. Convenience: Can Healthcare Have Both? Cybersecurity at ViVE Podcast · on Change Healthcare breach44 / 100

More from The Industrial Security Podcast

All episodes →
  • Rapid Recovery - When Security Fails [The Industrial Security Podcast]62 / 100
  • Medical Device Cybersecurity Is Tricky [The Industrial Security Podcast]85 / 100
  • Hardware Hacking - Essential OT Attack Knowledge [the industrial security podcast]95 / 100
  • Managing Risk with Digital Twins - What Do We Do Next? [the industrial security podcast]85 / 100
  • I don't sign s**t [The Industrial Security Podcast]88 / 100
Explore the best B2B Engineering & DevTools podcasts →
All The Industrial Security Podcast episodes →