Caffeinated Risk
Caffeinated Risk
Inherent risk & business strategy with Patrick Hayes
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
There are few business strategy conversations in 2026 that don't include the term AI, yet like the digital "game changers" before such as mobility, voice over IP, Cloud computing and of course the internet, after the hype fundamentals still matter in business.
Patrick Hayes , a cyber security thought leader long before it was fashionable, recently released the second book in a series exploring assurance within digital business systems and services. Most organizations are now in a continuous state of digital transformation in one form or another, AI has increased the speed, scope and potential impacts almost overnight minus guard rails. Integrated Assurance introduced the framework, Relevant Impact is a field guide for both delivering an protecting value in this highly volatile time.
While frameworks and strategic thinking tend to morph slowly, AI and it's impact on the digital aspects of all organizations is extremely fluid. Follow Patrick's current research in this space via his regular publications.
This is a caffeinated wrist espresso shot. The other thing we're missing in security, and I think uh especially with the ESRM focus of this podcast, we regularly talk about lots of different ways that your business can be disrupted. And we we joked about APT losing their brand. Yeah. But, you know, realistically, nobody's scared of APT anymore. They're scared of Criminal Gang X, Criminal Gang Y. Fair enough. But as an organization, maybe in some cases your crown jewels is your brand. Like the only reason people buy from you over somebody else is because of this brand name. And you bring up a number of things in the assurance papers around trust with the marketplace, I'm assuming. And I think AI has just made that a dice roll daily. In some ways, it's amazing we would even sign up for this, but we're all in, which is even stranger.
Patrick HayesWell, some of us are all in, not all of us are all in. No, us as an industry, like uh IT, business, whatever. Yeah. Well, I mean, so we as as practitioners think, wow, this is pretty cool, cool set of tools, right? Um, think back to when the internet launched. I mean, that's where my career started, right? It's like, woo, there's 50 people connecting um over the internet, and somehow we grew to a hundred thousand in a matter of a year. And and I mean, this is how I landed in security. I was like, wow, you give a person an internet connection and suddenly they do bad things. Yeah. And then suddenly Patrick's a security, suddenly Patrick's in security, right? Because you know, I'm starting to see these trends where people are doing bad things because they have internet. Um, I mean, not how much bad stuff can you really do in like 1998 with an internet connection, but you'd be surprised, right? Oh, you still got into trouble. Absolutely. Yeah, you still still still definitely got into trouble. But and it got worse as soon as they figured out compression, right? Because as soon as you could send any kind of images, damn it, it was naked. Yeah, that's that followed right away, right? Um, and and so when I think about um kind of where we're where we're clamoring to here, is I think that uh well the biggest thing I struggle with is a lot of organizations, they still don't understand the concept of inherent risk and residual risk, right? So every business has inherent risk, right? Whether you're a bank, whether you're an e-commerce retailer, whether you're, you know, you run uh a chain of gym members, you know, gyms and and have memberships and stuff, there's a level of inherent risk that comes with that. Now, your teams, right? IT, governance, you know, your your audit team, they all try to put controls in place, right? You get your policies, then those control objectives spill out to the organization, and they try and put in process and technical controls to be able to satisfy those policies. And what's left over, because there's always left over, is called residual risk. That's before you add the business strategy on top of that. So let's say you're a bank and your inherent risk is yes, you run a bank and you have all these factors of inherent risk, but you're also a bank that wants to grow aggressively through mergers and acquisitions, and you want to buy six other banks this year. That changes your risk profile. And I think there's a huge disconnect in the language that we speak between security practitioners and architecture and the business to say we can help you buy more banks and achieve your business objectives by applying some of these things to do it securely so that we don't open ourselves up for attack. But you know, a lot of these organizations are like, what the hell? I can save you know three million dollars by deploying AI to buy these banks this year. And you know, we could run, we can run our modeling based on, well, forget who you know, fully forget hallucinations for a second. We could run our modeling through, you know, through AI, and now we can buy 17 banks this year and there's no governance around it. There's no, there's really no way to test is the model doing what the model is intended to do, because there's really no policy for the model. There's no governance over overseeing the model. So when it actually executes, they don't even know if, well, what if somebody was to put you know uh poisoning in there, right? Like to inject bias into the into the model that produces hallucinations on the other side. There, there's there's no end to it, right? I mean, think back to our oil days, right? I know some of you guys, you guys are still kicking around in there, but you know, what are the three biggest things that an oil company that's that's that's pumping oil out of the ground care about? They care about not pumping oil out of the ground and making money, they care about natural disasters, and they care about loss of human life. And almost in that order, right? Like, so let's not kid ourselves, right? Yeah. And and the reality is if there's any way to do that faster, they'll do they'll do that faster. Oh yeah. But you know, nobody thinks about, well, what happens if an attacker can get to our royalty management system that projects how many royalties we have to pay to the farmers or the landowners that we actually have pumping stations on? And what happens if they poison that data and say, no, you actually are not come, you know, you're not producing 200 barrels a day from there. You're actually put producing 2,000. Well, maybe we should slow production because we have too much inventory. That's an attack. Now you've messed with their supply chain. Now you've actually messed with their inventory levels and you've actually, you know, impacted or disrupted potentially their business because now they go to their reserves and say, What the heck? I thought I was doing 2,000 barrels a day. Yep. I'm doing like 10. And I slowed production and because it mismatched my, you know, a simple royalty management system that nobody thought of as a part of their threat modeling. And I think we do a lot of that today. Like we we seem to neglect the broader scheme of what a threat model needs to include, and AI just makes that worse. Like it makes it significantly worse.
Doug LeeceYeah, and I think because you're like uh a lot of the attack surface management has to somehow incorporate threat modeling into these uh designs. Yes, you know, I I'm I'm almost getting, you know, hives talking about threat modeling now because I've been a fan of this forever. Yep. And yes, you know, it was bad, it was in P test before it was uh a thing, and Shawstack's books have been excellent on this. Yeah. And yet I don't see organizations even starting to try and do this. I remember trying to inject threat modeling into the front end of our pen testing practice and customers just kind of staring at you like, what is this?
Tim McCreightWell, because it's work, right? It's extra work, and and it requires a couple things that security professionals haven't been great at in the last 40 some years is understanding the business and then understanding what the business considers to be important. Yes, but then incorporating all of that into the modeling. So back to Patrick's example, if you were gonna do the threat modeling, you would look at all the ancillary systems that support getting black stuff out of the ground to make money, and the royalty program would be one of them. Yeah. So if I if you looked at that and went, well, you mean I can go in and I just have to change a formula so that it's a divide by a hundred.
Patrick HayesYeah.
Tim McCreightAnd no one's gonna catch it because there's no process in place to actually validate the change in code. Awesome. But that has to be included, and we're not we haven't been particularly stellar at that in the last 40 years because we look at the primaries, but we forget everything that supports it. And that's why some of these amazing systems that have been breached in this last 20-some years, it's because they weren't included in the original threat model. Because, you know, Doug, to your point, it's like, Well, why am I why are you doing this? Why your quote was for X, and now we're looking at system Y. Get back to X, just do the pen test on X. And yeah, yeah. That's what we've been having to deal with. That's shit we've been dealing with for 20-some years. Is that kind of shit? It's like, no, you said you were just gonna look at this, but this system supports it. Get get back to testing X, right? Don't look at Y for Christ's sake, get back to X.
Patrick HayesYeah.
Speaker 2Sorry, I'll get off my rant now. I'm better now, right?
Patrick HayesSo yeah, no, man, it doesn't, and it and it doesn't, and it doesn't get better because you know, um imagine if you're not planning for threat modeling as a part of your product development lifecycle or your system development lifecycle, because test-driven development and security-driven development are two very difficult things, right? I've been trying to do secure SDLC for years, as you guys know, and and that the real challenge is the business context, right? Imagine taking an organization through threat modeling and you introduce OWASP and their SSM model, right? And they find that painful. And the OWASP model is not painful.
Doug LeeceThat's a light touch compared to stride.
Patrick HayesIt's very light touch compared to stride, right? You think about that. And you know, I had to take one fairly large uh software organization through FedRamp, um, moving them from the public sector to FedRamp and getting them primed to move into that environment. And I did take them through um that OWASP security maturity model, and it was it was painful, but you know, what we got on the other side was what was um, I mean, it was really magnificent. But here's the thing a lot of organizations, especially when you're talking about larger, older organizations, they're still dealing in old two-tier applications, old code. Most of the time they don't know who owns the application, right? It's like we, you know, we did this project for an old company, we said, okay, so this is actually your crown jewels. We need to figure out who so who owns it? Well, you know, Joe over in OT systems owns it. Oh, so if Joe had to replace this system, he would write the check. Oh, no, no, no, that's not Joe. That would be so-and-so. Well, that's who owns the correct. I need to talk to him, right? So, yeah, that's the guy. And that's the problem, is so there's a disconnect between the ownership of risk and and the people that are the trustees or the custodians of risk, like guys like you and me, right? Yes. And then on top of it, we don't prepare for that. Like, you know, how many organizations, you know, have a sandbox environment or have a testing environment? I mean, Doug, you remember we did a test on an emergency management system and it was their production environment. And they said, kid gloves, because don't bring it down for Christ's sake. It's the only one we have, right? Like, it's like, wow, how can you how can you do that? How can you have no fail safe? How can you have nothing to fall back on when you provide emergency services, right? Like, forget it.