Three interviews: system fragility, operational clarity, and Identity for AI agents - Todd Thiemann, Robin Macfarlane, Kyle Sandy - ESW #471

Speaker A: This week we have three interviews. No news, no topic. Uh, first interview is Robin McFarlane from RRMAC Associates and she is with us to discuss the mattress money principle and system fragility. Then Kyle Sandy from Logically is with us to discuss operational clarity. And finally, Todd Tieman from Omdia is with us to discuss identity security for AI agents. All that and more on this episode of Enterprise Security Weekly. Um, it's the show where we talk security vendors and aren't afraid to name names. It's Enterprise Security Weekly. Welcome to Enterprise Security Weekly and Happy National Lazy Day. If you're already listening to this, you're halfway there. Kick your feet up and enjoy this week's triple interview special. This is episode 471 recorded for Monday, August 10th. I'm your host, Adrian Sanabria and we've got a few announcements before we jump into the interview. First, uh, announcement here. Security leaders, your vulnerability program is overloaded. Thousands of findings, limited resources and no clear way to prioritize what actually matters to the business. Meanwhile, regulators and boards expect measurable risk reduction, not just scan results. You can join the Vulnerability Management Virtual CyberSecurity Summit on July 29 to learn how leading organizations are shifting from volume to risk based prioritization and turning exposure into actionable strategy. Security Weekly listeners can register for free at, uh, securityweekly.com vulnmanagement using the promo code CSS26SW. And both myself and Paul Assadourian will be there in the first panel, so I'm sure we're going to have some fun. Our, uh, second announcement. Cyber Risk TV is proud to be an official media partner of Black Hat USA 2026. Just a couple of weeks out from that, uh, we're broadcasting live from the Black Hat Livewire studio with executive interviews focused on the technologies and strategies helping enterprise security teams defend modern organizations. Our event momentum packages extend your reach to analysts, practitioners and security leaders well beyond the conference. And there are fewer than 10 interview opportunities left, so make sure you grab, uh, one of those. You can go to securityweekly.com exec today, email and reserve your spot before they're gone. All right, with that, we can get to the interview. And, uh, for this first interview, we're discussing the mattress money principle and system fragility. We're excited to have Robin McFarlane joining us today. She's the President and CEO of RR Mac Associates and has over 50 years of experience across nearly every major era of computing. Robin has been a key driver of innovation in mainframe modernization. Uh, uh, applying DevOps to mainframes, uh, which is the first I hear. But welcome to the show, Robin.

Speaker B: Thank you. Welcome. Thank you. Um, yeah, it's been an interesting career. I guess everybody's trying to figure out how old I am now. I didn't start when I was five, so, yeah, I mean, I've seen technology from its early 70s all the way through to where we are today with AI. It's been a really interesting career. I've done just about any job you can imagine, from hanging tapes, wiring boards, installing machines, to programming. Um, I've always been in systems. I've never really been an applications person. But now our main driving force is modernizing, uh, all legacy applications on the mainframe and getting them over to a more modern platform where everybody could collaborate. Most of it's in git. We're doing a lot of work with AI right now also, which is part of where the money M mattress principle came from. So.

Speaker A: Yeah, so before we get to that, it's, um. I was thinking I have used punch cards, but only as bookmarks. Uh, they make really cool, uh, like, fun bookmarks that, uh, people like. That's a weird bookmark. What is that? Oh, this is code.

Speaker B: Uh, yeah, it was. It was interesting. It was interesting. And the biggest fear that we had, especially at one point I was in operations, the biggest fear is that don't drop the tray that had the cards in them because then you had to

Speaker A: be in that order.

Speaker B: Order, yeah, yeah, they had to be in order. That was programmed data, et cetera. So it was interesting, as I said, and I've been blessed that I've been able to do so many different things and build software, built commercial software, and now run my own company.

Speaker A: Yeah. So, um, yeah, before we go much further, we should explain what the mattress money principle is and maybe give an example of, uh, where you can apply that principle.

Speaker B: Okay. So the mattress money principle came out of a conversation that I was having with friends and family. And it was around technology a little bit that, you know, growing up with technology and watching technology evolve, as we were talking about you and I earlier, it's, you know, it was always in the background. Nobody knew it was there, especially in the 60s, 70s and 80s until even Nintendo and things like that came out. And then cell phones and then now intelligent phones. And the average consumer wasn't relying on technology. They didn't know they were. They didn't know what's going on in the background. And now today, everywhere you look, everyone's using a phone or they're using A tablet to do their daily life, to go shopping in the supermarket, to do just about anything. And my fear of that is that if technology were to fail, if we had some major event and technology were to fail, people would not be able to function and we would have to go back to suppose you couldn't use your phone in the shop, right, in the supermarket, or use your phone to do something, what would you do? And we had an incident not too long ago where there was a, one of the major telephone providers, cellular providers went out, had uh, a had a countrywide outage and you couldn't call 91 1. You couldn't do anything here, especially in the Northeast. And there's a friend of ours that works in a hospital and here are people that can't use, they can't call 911. And her concern was that she couldn't use her parking app to park her car because it was on her phone. And ah, my joke has always been make sure you have money under your mattress because what are you going to do if technology is not available to you? How are you going to pay for things? How are you going to barter for things? And the simplest thing is still paper and coin. And that's where it came from.

Speaker A: You're probably sick of the word agent, but here's the problem. Your dev team is handing every new agent in your cloud way more permissions than it needs. And when one goes rogue, you've got four minutes before your data's gone. You need a default deny button that doesn't break every workload. That's Sunree's cloud permissions firewall. Native IAM controls, not newfangled AI. Nonsense. Default deny on every agent and human identity automatically. Learn more@securityweekly.com Sonrai so a fun anecdote there. Uh, I don't know if you uh, heard about this, but the last time Amazon's US uh East 1 region uh, went down, there was a mattress manufacturer, uh, where people could not control the temperature of the mattress, uh, because the app no ah longer had a connection, uh, to the cloud.

Speaker B: Right.

Speaker A: And they were using, uh, they had a hard failure. I guess they weren't set up in any other regions. So when US East 1 went down, people couldn't control their mattresses.

Speaker B: I don't have to remember that one.

Speaker A: A literal mattress example.

Speaker B: Yeah. And that's it. I mean we're so reliant on technology and as I said, I've been very blessed in my career. I've seen what happens when you swipe Your debit card in the supermarket or in an atmosphere, where does that go? I've seen all those networks and where it winds up running on a back end mainframe, you know, in a kicks region, checking your account, coming back to whatever. And people don't realize that every day how much technology is now involved in their life. But what would happen if it wasn't there?

Speaker A: I think one of the things people don't appreciate, uh, and you and I having seen that, I actually got my start in a large payment processor. Like most people aren't aware of the amount of work and effort, uh, that went into making that stuff resilient and reliable.

Speaker B: Right.

Speaker A: And now we see people vibe coding apps and things like that, like with no appreciation, uh, for how much work it takes, uh, to make sure that when all these weird once in a lifetime, once in a year, maybe a couple times a year event happens, you can absorb those events. You can fail over, you know, you can make sure things keep running. And um, in applying that effort based on how important it is, you know, is it 91 1, you know, is it critical to human life or is it just critical to, uh, the business staying up and running? And I feel like a lot of that is missing now that we have people more casually getting into building businesses, building applications, stuff like that.

Speaker B: I agree. Yeah. Now it seems so easy that anyone could go to AI, build an application. They can do whatever and not understand what really is behind that and the risk behind that when you do it. And like I say, for me, I'm old enough that I probably won't have to worry about it in another 10, 20 years, but I need to worry about the generations behind me that don't understand what's really going on around them. You know, it's not just magic. As you said, there's a lot of infrastructure and people involved and technology involved in doing it. But still, for the simplest things, what would we do? And everyone has a disaster recovery plan, but it's just for them. And it's assuming that technology is still going to be there for the disaster recovery plan. And what if it's not? And so those are the things that we worry about.

Speaker A: That's another really good point. Uh, when Kaseya got hit with ransomware, uh, I remember, uh, Swedish branch of the co op, grocery stores had to shut down not because they were a Kaseya customer, but because their payment provider, uh, uh, the provider that ran their cash registers, their terminals, uh, used Kaseya. So it was actually not a third party, but a Fourth party to co op, uh, but they still had to close their stores because of a dependency that they weren't even aware of, you know, across a third party. So like that's, that's one of the things I have a lot of conversations today where, you know, I'm telling companies you can do security perfectly, but if you're dependent on somebody else, uh, you know, depending on how many third parties you have and how critical they are to uh, your business running your data, not getting, uh, you know, permanently erased, uh, you know, you could still be in some pretty hot water.

Speaker B: Yeah, and we do that and we see that. And I guess with all of the checks and balances of everything we have today, which is more than what we had before, I see more and more of these little instruments as you're talking about third party or who else is in your network or who's your provider where their due diligence isn't as good as your due diligence. And you assume that and then you wind up being hurt by it. And as I said, we're assuming technology is going to take care of it and we're not doing our own due diligence to check that. And that's the thing that concerns me because we do a lot of security audits too. We do software audit, security audits and everybody's taking the classes and everybody's doing what they're supposed to be doing on paper. But you can see it. I mean, I forgot someone just got hacked because they fell for the. This is the CEO calling and I can't get in. I forgot my password. And it was a large exposure and it was because of a person. It wasn't even because of a security or somebody got through a server or whatever, you know, so you really have to be careful with who you're dealing with. Yeah, Keep your money under your mattress. That's my thing. Just keep a little bit of cash at home, just in case.

Speaker A: Yeah, yeah, it's um. You know, one of the other things that strikes me is the way we often think about innovation and technology advancing is, um, if we think about phones, uh, there were payphones, we had phones at home.

Speaker C: Mhm.

Speaker A: Then we had mobile phones. Uh, and the pay phones have largely gone away. But in the enterprise it hasn't been like that. Because cloud exists doesn't mean that your company's data center went away. I think at one point we maybe thought that was going to happen. But uh, you know, going back to the beginning of your career, some of those systems are still around Right. When we saw the British Library get hacked, uh, one of the biggest lessons learned that came out of that for me was that they were as much a library as they were a computer museum. Except the computers in there, it wasn't a museum. They were production critical. Right. Like they had a little bit of everything from over the years, from when the British Library was founded in 1973, 1974 and uh, when all those systems were destroyed in basically a day, um, they had to do, take care of 30 plus years of tech debt all at once.

Speaker B: Right, right. And, and I guess, you know, the mainframe has been going away for, I don't know, 20, 30 years now. And it's probably never going to go away. I mean most of, I think it's 70%, 80% of the financial business worldwide still runs on the big IBM M iron, but people don't see it. And it's not sexy like a mobile app or anything else, but it's the engine that's running everything and it's very, very secured. Um, so I guess with any technology, as we evolve and keep evolving, uh, the original legacy systems are still there and they're always going to be there. And just people don't see it and they don't have to see it. They don't even have to know it's there. But the fact that everybody keeps trying to replace it, I think is where the exposure comes. I've seen too many companies go off to servers, come off their mainframes, go to servers, and then wind up having to buy them back at a premium because they can't get the throughput, reliability or security. I mean, you're into security. It's the most secure platform you can run on. So drop your phone and lose your phone and you lose access to everything. People freak. Oh my God, my phone's not working. I can't get to my bank. I can't do anything. Well, you could walk in the bank, but that's not the first thought that they have anymore.

Speaker A: Well, digital estate planning is a big thing now, right? You know, like, like, you know, God forbid, should something bad happen to you, you know, can people log in and pay the bills, you know, uh, were you backing up your data, your phones, your unpublished, uh, novel that you worked on for the last 30 years, like how much of that? And the funny thing is it's security that's now destroying that data. If you haven't planned to share that data with somebody or you haven't given somebody else access to your devices or your password or Something like that. Um, good news, it's really secure. Bad news is it's really secure. That 30, 40 year novel is now lost, uh, forever because uh, we made it so you can't break the encryption.

Speaker B: Yeah. Go looking for mom's recipe book where she wrote everything in the back.

Speaker A: Yeah, it's all on Apple notes.

Speaker B: Yeah,

Speaker A: yeah, for sure. Um, so, you know, I think at this point, um, I should have asked a little bit earlier, but now uh, is as good as any time. Uh, what does uh, rrmac Associates do? What, what is the kind of stuff that you have worked on in the past and what are you working on today?

Speaker B: Uh, well, we're a systems company. I mean we manufacture software to do audits, several things. Most of it around configuration management software. Configuration management.

Speaker A: Um, is it all specific to mainframes or broader than that?

Speaker B: Uh, no, it's enterprise. It's enterprise. So what we're doing is taking those legacy systems where, you know, the old legacy systems, I was, you know, a developer of one of them and converting it now because they're not teaching it in college anymore, you know, people aren't going, wow, look at this 3270 interface for the mainframe. You know, they're looking for, you know, interacting on their phone, Eclipse, you know, visual code. So what we're doing is we're modernizing software development and taking them to a more DevOps platform and more tooling. Tooling that's, you know, that, that they can use for web, you know, mid range mainframe. Everybody's playing in the same sandbox more or less. So what we do is we migrate customers from the legacy systems that they're on, just their configuration management system, security system, migrate them over into a newer, more modern system where all the developers are collaborative. So it's not like, you know, for all these years the mainframers were on one silo, the mid range guys were in another silo. Web developers then were in another silo. Now they're all developing in the same platform of modern tooling and that's what we do. So we built software to automate all of that and modernize some of the things on the mainframe.

Speaker A: Okay so you know, back when I was an industry analyst, uh, 10 years ago or so, a little over 10 years ago, one of the observations I made this was still early in cloud days. Um, cloud was maybe aws, uh, was, was a decade old at that point. Azure was younger, GCP was young. And one of the observations I made was that a lot of IT environments split uh into silos where they previously weren't. So a lot of systems folks uh, were able to make kind of the cognitive leap to uh. Now instead of servers like uh, a server workload can become a shell script in a lambda uh, or something running in a container. We had these levels of abstractions where uh, everything didn't need to be uh EC2, you didn't need to be managing the operating system layer anymore. In a lot of cases the database was now just a uh, platform as a service. Uh, instead of uh, you didn't have to manage Solaris anymore, you could just have Oracle running somewhere in Oracle Cloud and didn't have to patch the server layer. And the observation was that uh, some people had trouble making that leap. Right. So a lot of organizations ended up with the, the folks who manage the data center stuff and the people who manage the cloud stuff. Uh, and in some cases even logically split in the organization. Like uh, I remember early days, I don't know what it's like now. Like at Uber, you know they ran SAP, they had back office stuff. Um, but then the people who ran the app that faces the riders and the drivers, uh, you know all that stuff was uh, a completely different team. Like are you still finding uh, like a struggle, um, how much of it is a struggle to get mainframers using Git and right. Like bringing people to

Speaker B: it really depends on m, uh the company also you know, what is the methodology in the company. And like I say, I mean I'm an old dinosaur so. So it is a new way of thinking. But it brings together where we were so siloed. Now it brings together all of those groups and now you're a developer and you can be talking to the guy that's running your front end webpage for what may be running your back end application. And for the mainframers I think it's difficult just because it's such a big change of tooling. But they're still mainframe developers, they're still writing in COBOL, assemble or PL1, whatever. It's just their interface is changing and they're getting more than what they got before out of the green screen. And the green screen is still there for them in the tooling that we're implementing. You know, whether they're using visual code or whatever. Um, so I see the adoption is much better now because the tooling is better that we're offering them and now that we've been able to bring DevOps into the mainframe. In the beginning it was a bit of A struggle. Now it's much easier. And know that, you know, when you're writing a web app or you're running even a mid range application, you may have, you know, so many artifacts, a couple hundred artifacts. We're moving millions of artifacts. You know, that's jcl, proxy control cards, programs into Git. And um, because of, like I say, the software that we built at rmac, we could do it quickly because we've automated that process and the scripting and getting things across. So that, I mean that's good for us and it's good for the customer because it reduces the time and the cost to do that. But I can see that now we're working a couple big projects right now and I could see the developers as we discuss it more and more and they're helping us. We're not just coming in and saying this is what we're doing. We're working with them to help them reimagine their applications and how they work on their applications. It's going really well and they are adopting it and you have to be competitive. You really do. Because you know, people who are getting ready to retire, that knowledge has to be transferred and it's going to be transferred to somebody that's not 64, can be transferred to somebody who's in their 20s. And they have to be able to use the tooling that they're familiar with but understand their application. So that's another big piece of it. Knowledge and transfer is key.

Speaker A: Yeah, that's so it's interesting, right? Like it's um, what does that pipeline look like for new people doing jobs, uh, that are associated with old technology? Right. Like, I think in a lot of people's minds it's still an AS400 even though it's been rebranded seven times since it was, it was officially called AS400. Right. Um, like it's.

Speaker B: I was never a fan of that machine. Never.

Speaker A: Yeah, the branding is annoying too. Like how do you search the Internet for the letter I? Right. That's your brand for the whole machine. Okay. Um, um. But yeah, how is that evolving? Personally, I don't know of a lot of folks, uh, in their 20s writing, uh, Cobol or getting into mainframes and stuff like that. What does that pipeline look like? And is the way that they're approaching it just completely different from the people going out or the people going out? Like, you know, here's what worked for me. Do whatever you want. But yeah, how's that? Yes, how's it?

Speaker B: Yes. Because yeah, you have Applications that have uh, go back to the 70s and the 80s. I mean a lot of this legacy Cobalt, let's just pick Cobalt is still executing today from things that were designed for insurance companies, banking, whenever, back in the 70s and 80s. So you can't rewrite some of those. You just won't get the throughput. You take a big Cobalt application, rewrite it in Java, you know Python, it's not going to run, it's just not going to perform. So the whole intent is to take those applications and not do these big, where we are doing six month M releases to get them down and it's in the CI CD pipeline as they're doing it today in Sprints and Agile for the, for the other platforms so that we don't have to take on these big, big things. We can make our little changes and do our smaller changes in a DevOps environment. But to give those younger developers the assumption is that they know Java, they know Python, they can learn another language if their tooling is the same and everybody's in the same platform. That's where that whole initiative came from for DevOps. And I see that successful, yes. And I see it successful. No. I mean some people just don't get cobol. You know, there's like, I'm used to, one guy said I'm used to freeform coding and I'm like, well that's not COBOL and that's not assembler. You know, you just can't, you know, just code however you want. There's no DLL for you. Um, so it's, it's a mixed bag. But I think in order to be successful, um, companies are taking the challenge because they know that once that knowledge gap, those people retire. Who's going to manage these applications? There are some companies that are looking to rewrite their applications but as I said, when you're processing millions of transactions a second, I don't see that happening in a Java, in a Java app, you know, it still needs that big iron, you know, to run it and uh, you know, those old applications to run it. So like I say, if they have a good stakeholder and good driving, you know, good driving from the top down, I see them being very successful.

Speaker A: Yeah. And then the, you know, moving from the people side of it back to the systems, uh, side of it. Before we wrap up here, um, addressing the system fragility, uh, you know, that we described in the title of this interview, um, you know, do you think there's still a lot of lessons to be learned from how we used to do things that can be applied to, uh, the newer technology. I feel like, you know, back to my story about the mattress, like from almost day one, AWS has been set up for resilience, geographical, uh, resilience, logical. Like that's the whole reason they have all these different regions. And even within one region, uh, there's redundancy, but people aren't using it. Like still, when this one region that always goes down, goes down, uh, you see a lot of applications go, uh, completely offline, even though they don't have to. Like, if it were me, like, like why not just run an organ by default? It almost never goes down.

Speaker B: It's cost too. It's cost people don't want to pay for. They want it, but they don't want to pay for it.

Speaker A: Economics. Okay, right.

Speaker B: It's, it's still, it's not cheap. So that's some of it. They talk about it, we have it, we have a plan. But oh, what is it going to cost us? And then you'll see them cut back on that. Because even though technology, you know, the, the price of a, a mainframe. When I was a systems manager years ago, what we would have for our budget for a mainframe, one mainframe was ridiculous.

Speaker A: Millions. Yeah.

Speaker B: And millions.

Speaker D: Millions.

Speaker B: I mean like we're talking 20 something million dollars where now you can buy a Z for, you know, under $100,000 and run it and run applications on it. So the cost of the hardware has come down. It's the cost where it was a hardware budget years ago and the software budget was a little piece of it. Now the hardware has come down, the price of chips and everything's come down. It's the software that is the driving force of it. Software is a big cost of people's, you know, enterprise budget right now, aside from trying to be competitive and stay with, you know, the, the, a lot of companies are looking at reducing their cost by having AI generate a lot of their code for them, which is like the biggest risk going because then you don't, your developers don't even know what's in it.

Speaker A: Yeah.

Speaker B: And, yeah, and AI is like 50% reliable right now. So we've made it hallucinate, We've made it hallucinate as a test.

Speaker A: Also, it's not cheap. Right. Like we're starting to find that, uh, maybe people are cheaper than AI, you know, as the token costs go up. But it's not just the cost of the token. It's like one of the ways that we're solving reliability. That 50% issue that you describe is okay, now tell the AI what success looks like and have it grind at it until that 50% becomes 100%. And um, that is a fix, but it's an expensive fix because you're having it waste a lot of tokens and cycles and money as it looks at the, uh, success conditions. Not met. Go back. Still not met. Go back While you're sleeping. It's just spending budget.

Speaker B: But it's also when I mentioned that the hardware budget used to be the big piece years ago and then it swapped to software. Now because of AI, hardware has become an expense just to even run it on a machine or a server, your video card is going to cost you over ten grand. We're looking at just taking our local machines and upgrading them. And the price of the video card just to run AI is running thousands of dollars for that. So that's driving the same thing with the data center. If they start building these AI dentists data centers, what is that price going to be? So now that's driving hardware cost back up again.

Speaker A: Yeah, yeah. And unfortunately with uh, the price of storage and RAM going up, those video cards are significantly more expensive than they were, uh, a year ago. But yeah, an H100 is like 50 to 80 grand or something like that, right? Um, right, yeah, yeah, they're not, they're not cheap. So, uh, you know, kind of parting thoughts here. You know, what are the, what are the lessons that the, you know, the 20 something year olds need to be learning from? The. I know it might be hard to summarize, but, you know, do you have any, uh, good takeaways for us to consider after the podcast ends?

Speaker B: I guess for the AI initiative, um, as I tell my guys, use it for your research, but don't believe everything. Do your own research. Anyway, get your answer, but we are not having to build our code. We're still writing our own code mode.

Speaker A: Okay, good to know.

Speaker B: Yeah.

Speaker A: All right, uh, Robin, thank you so much for joining me today. Uh, fascinating conversation.

Speaker B: Thanks for having me.

Speaker A: Love getting to chat with folks who have, uh, been around and seen all the things. Uh, it's very cool.

Speaker B: Thank you everybody. Have a great day.

Speaker A: All right, stay tuned. When we come back, we're going to talk operational clarity with Kyle Sandy from Logically. Enterprises are adopting AI tools such as AI agents, MCPs, LLMs and skills at ah, 10x speed. These agents have access to business critical workflows, applications, tools and sensitive data. But access without governance and control isn't acceleration. It's exposure and critical risk. The question isn't whether to build or use AI agents. It's whether security teams can govern the AI environment. Akto is the leading AI agent security platform, helping enterprises solve this gap. With continuous agent discovery, automated AI red teaming, agentic guardrails, AI security, posture management, and runtime protection, Octo helps enterprises secure AI adoption across the entire AI lifecycle. Learn more@securityweekly.com October 39 seconds that's all the time it took for an AI agent to delete a, uh, company's entire production database and every backup with it. Autonomous agents are now common in production systems and they will make mistakes. Is your business ready to deal with agent failure? Rubrik Agent Cloud was built for this moment with posture management that can surface dangerous credentials before an agent finds them, with runtime governance that can block destructive actions before they execute and truly isolated recovery that lives outside the influence of your AI. When an agent moves fast, Rubrik makes sure the damage doesn't have to last. Learn more@securityweekly.com Rubrik welcome back to Enterprise Security Weekly, Kyle. Sandy joins us today to talk about operational clarity as the new customer experience. Kyle is the Director of Cybersecurity at Logically. Welcome to the show, Kyle.

Speaker D: Hey, thanks for having me, Adrian.

Speaker A: So let's start off a little bit with, uh, what Logically does and what your role is there.

Speaker D: Yeah, yeah, absolutely. So, uh, Logically is a platform, mssp. Um, and really what that means is that we were many separate organizations, uh, operating all across the MSP space, and now we're kind of a conglomerate. Right. Uh, so 13 kind of child organizations formed under logically, um, about 20 years in the making. So we operate pretty much everything except for, like, custom software development as far as the technology space goes. And my role is to head up operations for the cybersecurity aspect of that. Um, so we've got quite a few management points out there. Roughly about like 50,000, um, you know, over 20,000 network devices that we manage from a security aspect.

Speaker A: Gotcha. Okay. Yeah. So, um, you know, the title here, operational, uh, clarity is the new customer experience. You know, I think it might be useful to break down what we mean by that. Uh, right. So, you know, particularly from, from your perspective, you know, I think more and more we see organizations outsourcing, especially organizations of a certain size, uh, uh, outsourcing to MSPs, uh, for various things. So, um, what does this mean to you, this, uh, this idea of operational clarity?

Speaker D: Yeah, I mean, as far as it goes, I think that we, we don't inherently trust our vendors because they have a SOC 2 report anymore. Right. Or because they should not. Security questionnaire. We shouldn't. Right. At least if you're, you're going to base some aspect of it off of that and verify that it's in scope. Uh, you know, but uh, you know, it really comes.

Speaker A: There's a non zero chance that, that SOC 2 was AI generated, uh, today.

Speaker D: Yeah, um, right. And you get that on your trust site and other things. But as far as that goes, we can't just inherently trust because it was verified at a point in time. Um, and I think seeing operational ease puts everything at ease. Right? Seeing that things operate the way they should, that there is kind of a standard operating procedure for things and that we follow that you kind of get the clear results that you're expecting. Ah, and that goes for, if you're at an enterprise, your customers too, right. They want to see that you're providing the service or the product that you provided reliably. Uh, otherwise they're not going to trust you. So I think especially relevant in the technology space, uh, we have to consistently deliver and we have to provide that operational clarity. What are we going to do if there is an incident? You've got to have that document and then follow it.

Speaker A: Yeah, yeah, for sure. And then, um, so that uh, comes right into uh, customer experience here where yeah, it's you know, a lot of using uh, an msp, like especially for cybersecurity is uh, and I've run into this a lot over the years, like the experience is very different, um, before the incident, without an incident and then during an incident. Right. So like in a lot of cases, um, you know, how do you even choose an msp, right. You know, when the thing that you're choosing them for may never happen. Right. Like, like how do you, how do you uh, you know, I don't know how you guys are going to perform in an incident. I've never seen you do it. I may never see you do it. Right. You know, so that, yeah, seem, seems like kind of a challenge, right?

Speaker D: Yeah, yeah, absolutely. Um, and I think obviously, uh, being able to say that you're going to do something doesn't mean you're actually going to do something, uh, especially do it in a certain way and under pressure. So you know, I think demonstrating that uh, ahead of time, whether that's through testimonials or through, you know, obviously in this industry we go a lot based off of peer to peer recommendations. Um, so I think that helps a Ton. And that just means you always have to be on your P's and Q's because one, uh, negative review is worth 100 positive.

Speaker A: Yeah, no, that is so true. Um, and yeah, like you don't get to manage that conversation either. That happens in a slack, uh, channel, you know, a bunch of CISOs on the Slack channel somewhere like, like that, uh, people will talk about the quality of your, your services or your products, uh, oftentimes where you can't see it. So yeah, you've gotta, you gotta make sure you're, you're managing for the, for the best outcome there. Uh, yeah, make sure, make sure people are gonna say nice things. Um, so, you know, the, the I've spent a lot of my time studying breaches and uh, trying to understand how companies fail. And um, one of the big shifts that I've seen for adversaries, certainly since ransomware became a big thing, I think around 2017, we started seeing ransomware crews going after enterprises, uh, for big payouts. Early days ransomware was opportunistic and it would come in via email or something like that, or drive by in a website and it would target an individual and they'd try and get you for like $500 or something like that. And then at some point went to this multimillion dollar thing and they started out encrypting files. And then at some point, uh, companies, very quickly, companies got really good at backups. Right? Yeah, but you know, encrypting files was not the only way to get somebody to pay a ransom. Uh so I have observed that ransomware actors have, uh, they'll spend some time, they'll take the time to understand what's going to hurt the most, what's going to impact revenue, what's going to make you want to pay a ransom to get the uh, things up and running again. So that need for resilience there, uh, we started seeing that word pop up. Resilience. Uh, not only, you know, forget just preventing uh, a breach. You know, if we have a breach, how quickly can we get back up and running? You know, now, now we see, you know, that boards are very interested in that. You know, anybody that saw Jaguar Land Rover, you know, not only one company went down, but that company that uh, stopped manufacturing cars. Uh, now this entire ecosystem of small businesses and mid sized businesses, uh, that depend on that company, 4,000 companies plus are now like directly impacted. You know, their cash flow is impacted. So it was kind of, I didn't intend it to be so long winded, but you know, Long winded way of saying, um, you know, how has that impacted you guys? You know, and how you handle your customers? You know, is there more focus on not just working the incident or preventing an incident, but, uh, you know, speed to recovery?

Speaker D: Yeah, I think that, you know, the biggest shift that we've had, and I contribute a lot of this to, uh, the AI. Boom. Right. But it's, what can we do to prevent it? Obviously, that's. That's always going to come first. How quickly can we detect it? Which means that we've got to have monitoring and we have to have a good response time. Right. Um, and then from there, okay, if all of our controls fail, our preventative, our detective controls fail, um, we need to have a dedicated incident response team. Right. And they need to be practiced. And terrible as that sounds, means we kind of need incidents for them to work or we need to simulate them. Right. Which is something that we had to do more and more.

Speaker A: Uh, tabletops, Pen tests.

Speaker D: Yeah, exactly, exactly. And then I think the mistake that a lot of people make when they do have an opportunity during something like a pen test, um, you know, don't turn off your monitoring tools. Yeah, your soc is going to have to do a little bit of work. Um, but you need to see what that looks like. Maybe don't even tell them from time to time, make a black box. They've got to go figure out what's going on. Um, so I think that those have, you know, kind of those points have become much more important, um, because the threat actors are a lot faster too. Right. Um, maybe enabled by AI and maybe there's just more of them. But ransomware in particular, I've actually seen less of recently. Um, and I think a lot of that's because the tools are getting better at blocking actual malicious software. I see a lot more extortion these days. Um, they don't even have to worry about taking your operation down. They can just take your information. They don't have to worry about getting detected when they run and threaten to erase it. Exactly, exactly. They put you on their wall of shame and they say, hey, you've got until next Friday or, uh, the world's gonna.

Speaker A: Yeah, yeah, yeah. It's a really good point because, like this, this extortion model, um, right. Encrypting. And we were saying this very early on. I remember back when all of Security was on Twitter, like, uh, we had a lot of threads where, like, okay, what comes after encrypting files? Right? Like, you know, stop treating ransomware as if it's this one trick pony, like encrypting files is the only thing they can do to get you to pay the ransom. Yeah, you know, there's, there's a lot of other potential things they can do there. And then we started seeing it over time and, uh, and even double and triple ransomware, where they don't just go after you, but they go after your partners, they go after your customers. Uh, you know, they try and get payouts from all parties who stand to, uh, have something to lose if that data is, is released or, you know, if it's, uh, permanently deleted.

Speaker D: Yeah, 100. 100. And like, the, the operational clarity aspect of things for that is, you know, what are you going to do? Your network's not down, your endpoints aren't offline, you haven't been ransomed. Um, but how are you going to carry forward your day to day business when somebody's threatening to release your information? Um, yeah, honestly, one of the biggest things that you can do is have good monitoring in place, right? Because then you at least have a good chance of knowing what information they got if you didn't detect. And then, um, you know, kick them out beforehand. Um, you know, if I, if I have a file server and I all of a sudden see a terabyte of traffic leaving it last Tuesday and now today you're telling me you took my information, there's a good chance that terabyte of data went to you. Um, all right, so what was it? And kind of track things down. How important was it? Oh, well, you know, it was just, uh, it was the lunch calendar, right? Like, not really worried about it. Um, and then you don't have to worry about paying the extortion, right? Cause it can be something, you know, it depends on what or what your risk tolerance is.

Speaker A: Or they didn't take anything at all. Like, we see this happen where they just take some data, right? Uh, and they say it's your data. How do you know it's your data? Right? So I've actually seen companies put like data canaries in there where in their customer database, they'll put a fake record in there and then they'll change that fake record like every month or every week or something like that. So not only can they now fingerprint that this was their data and it came from that database because they have this fake record in there that, uh, is just kind of like a watermark. Right. Um, uh, but they can tell what week it was taken, uh, because they change it out over time. So I love that idea of. And you can tell when a breach happens between the companies that were savvy enough to know exactly what was taken because now they only need to notify those people versus uh, the companies who had no idea and basically have to assume everything that they have was taken. Right. You can tell the difference when it gets reported.

Speaker D: Absolutely, absolutely. And we see a lot more of that being embedded in MDR tools and things of that nature now. Right to where um, they may even isolate an endpoint if that file is turned touched. They know that it shouldn't ever have a use for being opened and the second it is they're going to honey token.

Speaker B: Right?

Speaker D: Hm. Yep, exactly. Exactly. So we see a lot more of that just kind of embedded in kind of the industry leading EDR tools these days. Uh, which is great, right, because it can stop something like uh, an extortion kind of attack, whereas we're not relying on malware to be executed at the trigger.

Speaker A: Yeah, yeah, for sure. Yeah, yeah. So, uh, so yeah, a lot of this comes down to preparation. Right. You know, so is that something that you guys start on immediately? Uh, like imagine, you know, if you're doing this for every customer you have, you got to have some kind of a, ah, checklist, but each environment's different.

Speaker D: Right.

Speaker A: You know, so, so talk me through a little bit of what that's like to onboard a customer and say, you know, kind of evaluate what kind of shape they're in and how much work you have to do to get them where they need to be.

Speaker D: Yeah, yeah, absolutely. So there's obviously the baselining phase. Right. That's I think, uh, regardless if you're going to a service provider or not, you need to know what normal looks like. So you've got to baseline everything. Um, you got to know what kind of network traffic are you processing on a day to day basis. Right. And if that spikes all of a sudden and you weren't pushing offsite backups, then well, that's probably an issue. Right. Um, so baseline that. Baseline what tools are deployed because something like Rogarran MEMs are running wild these days, One of the heaviest kind of attack vectors that we see, um, maybe we go ahead and block everything else. Right. Uh, if I know I've got Screen Connect deployed in my environment and all of a sudden teamviewer pops up, uh, probably want my SOC to alert on that, go ahead and remove that app. Um, so the baseline is really going to come in handy and paint the picture of what a day to day operation looks like. And then from there, um, maybe your baseline's not that great and we've got to suggest some tuning. Right? So if you've got four or different RMMs that you're actually using in your environment, then I want to get that down to one.

Speaker A: Exactly.

Speaker D: Because we have no idea what you should be using.

Speaker A: TeamViewer is okay, but if we see any desk that's uh, an ioc, right?

Speaker D: Yep, exactly. Exactly. We want to isolate that and determine what's going on. Um, tech support scams kind of at an all time high right now. Um, one of the things that we've even seen recently, it's kind of crazy. And then I'll circle back to the main topic is like, um, sending phishing emails through an rmm. So it is a legitimate login. There's literally no indicator that, uh, you know, somebody's using your email account. Um, but they've got TeamViewer set up on your PC and they're sending phishing and scam emails straight from your, you know, your actual laptop. Uh, and takes a little bit of extra cycles to track down. Um, that's super fresh. So, you know that the resilient, we have to be resilient because obviously the threat actors are figuring out new tricks all the time. Um, so, you know, as far as that goes, once you got your baseline, once you've kind of tuned up to um, what we, where we want you to be, right. And then anything that we can't, I gotta make sure that whoever actually owns your security posture is actually accepting a risk. If I see it as a risk, you know, and I say, we need to get down to one rmm. And you say, I just can't do that, at least in my industry. I need formal documentation. I'm going to send kind of a risk acceptance letter and say, hey, we're recommending that you do this and if you choose not to, we just need to document it in case something has to happen because I'm not accepting that risk. So, you know, kind of going from there, uh, and then, you know, usually what we see is we make the recommended changes to kind of bring you to a good steady state, give you the clarity. And then we define playbooks. Anything that could happen from there that deviates from the norm, uh, we need to execute. We execute quickly. Who do we notify? Right. What's your, uh, recovery time objective and your recovery, um, point objective if something were to happen. How can we help you get there? Um, have we ever tested your backups? Right, because that's the thing. It's like the uh, uh, everybody knows what they're doing until they get punched in the mouth kind of a thing.

Speaker A: Right.

Speaker D: If you've never actually tested recovery, I don't really care that you have off site backups, um, can you use them? So kind of going through all those motions and making sure that you don't just have a picture of resilience and that you're actually ready to execute is kind of where we start.

Speaker A: Yeah, yeah. I used to say, um, when I did drbcp, like experience quickly taught me that if you haven't tested the recovery method, uh, you've maybe prepared 50% of what you need to and the other 50% you don't discover until you actually try to do the thing and you're like, oh, ah, right. There was this other dependency, there's another system we have to stand on before we bring up this system. Uh, and that was painful in the old days because none of these things were cloud services or anything like that. These were all physical, you know, uh, bare metal systems that we would have to stand up in our Dr. Uh location. And eventually what we ended up doing was just putting HA in place because disaster recovery, uh, there was no way we could meet the objective. Like uh, we did the math and just pushing tapes into uh, the tape drive to do restore for our main uh, CRM application. Like worst case scenario, if it happened the day before the next full backup, uh, after all the incremental backups, like worst case scenario with incrementals was uh, something like 14 days of just pushing in tapes to get the data, uh, to restore the database which was just one component of it. So we're like, yeah, we're going to have to give EMC a bunch of money and put a SAN in two locations and do active replication between those things. But um, but yeah, we had to actually tabletop the thing, actually try it out, test it out to realize, oh crap, this is not gonna work. Our plan for resilience is we need a new plan.

Speaker D: Yeah, yeah, well, and the other part of that too is like I uh, think a lot of the times the IT team or the security team will kind of set the rto, the RPO in a vacuum, right? They think they know how quickly we need to recover and what that point is. But can the business actually operate at that level? Can we survive that much downtime?

Speaker A: And we're even seeing come from the board. Like the board is asking companies, you lost it all, this cloud is gone. You gotta restore to a different uh, and Azure and AWS and GCP are not one for one, right? There's some services that AWS has that there is no equivalent in some other service. And we've got boards asking, well, even if it's like another region of AWS that you have to restore in, because there's an extended, uh, you know, downtime, because, you know, one of them got hit with a missile like we saw happen in the Middle east, right? What's, what's the RTO for the whole business, right? For everything you've got in the cloud. You know, is it 24 hours, is it less than that, is it more than that? And, uh, you know, then you give them an answer, they're going to say, okay, do it. Show me.

Speaker D: Yeah, exactly, exactly. And I think that that's a good, good thing that we're actually seeing, right, is people want to test more often. They actually want to see that it works. And I think a lot of that is because of conversations like this that they catch on a random drive and they're listening to a podcast, right? They're like, oh, wow, I never thought about actually testing this plan. Um, and the other thing that I would, the other thing that I would impart on everyone is like, get a physical copy, store all your plans, your disaster recovery plan, your business continuity plan, store it all off site, put it in the cloud, get a physical printed copy, put it at your desk. You know, keep one at home. Because the last thing you want is to go and try to follow your plan. And, uh, well, it's encrypted, so you can't.

Speaker A: Yeah, yeah, I remember as long ago as maybe, uh, 20 plus years ago. I, uh, had a manager once who would just, he would just create files and put them out on, uh, file Windows file shares, and he'd leave them there for a month and then he delete them. And then he'd go ask the backup guy to, he'd tell the backup guy, hey, this file was critical. I don't know what happened to it. Uh, I need you to restore it. And one, uh, hundred percent of the time he did that, the backup guy was not able to restore those files. So it was like, easy as can be. So I think they were actually backed up. And the problem, there was a skill problem with, uh, that individual. But, um, but yeah, you know, in hindsight, like, I realized how valuable it was to actually put people through these tests because oftentimes we make all these plans. Um, and I think of it like sports. Like, like if you've never actually worked as a team to do an incident, you know?

Speaker B: Yeah.

Speaker A: Ah, do you know how to use your tools correctly? You know, do you know how to communicate? Well, like I've been through so many incidents where three people have the same idea and they all jump into the sim and they do the same query at the same time and they don't realize they're duplicating or uh, tripling their efforts, uh, instead of communicating with each other. So I imagine you run into that a lot too, where communication is super, super important.

Speaker D: Oh yeah. I mean, communication is key. Right. Um, your stakeholders have to be notified. That's got to be, uh, you know, after containment, then it's really your next order of action. Right. You got to notify and then you got to find out how it happened. Um, always stopping the threat in its tracks is number one priority, priority two stakeholders, uh, informed and then, you know, from there enact your disaster recovery, your business continuity. Um, and the incident team gets to run along with uh, the rest of the remediation action. But uh, very important to know who needs to be notified. Right. Who's the system owner, uh, who's the business unit owner, and then obviously it trickles up from there.

Speaker A: And all this should be in your incident response plan, right? Like who you're going to notify, how quickly you're going to notify, how often during the incident you're going to notify them. But talk, uh, a little bit about the difference between your IR plan and IR Playbooks.

Speaker D: Yeah, for sure. So our Playbooks are going to be a lot more specific. Right. So when we have, let's say business email compromise.

Speaker C: Right.

Speaker D: One of the things that's most common, um, we have a very specific set of actions. Right. Go see if there's any new rules, uh, in the inbox. Go see if there's any newly registered apps. Go revoke all the tokens, make sure the devices that are kind of enrolled are correct and we go through those motions. It's very specific and it should be tailored to the type of incident you're handling. And that's also to call out. It's very important to have a new incident, kind uh, of an escalation process Playbook. Um, you've never seen this before. No one has documented how to do it. Shouldn't be worked by a tier one analyst. Right. Um, so that's kind of the next phase of having your Playbooks. Um, but the plan should be very consistent. Right. Think of it like a policy. Um, you should notify by uh, the same people you want, uh, to classify things, preserve evidence, and really just follow the same process regardless, as far as the incident response plan goes. Uh, and Playbooks where you get into this specifications.

Speaker A: Right. And I imagine as you use Playbooks, like you see opportunities to streamline things, to speed things up.

Speaker D: Yeah, yeah. And it should be part of every single incident response plan ever to have an after action review at the end. Right. You got to go and tally up what worked well, what didn't work well.

Speaker A: Easiest part to skip.

Speaker D: Yep. Everybody does. Right. And that's kind of the thing that ends up biting people is let's, uh, say that your actual instant response, uh, you took 20 minutes to contain this time. But if you would have done one thing differently, right. It could have been 12. Just update the plan. Right, but somebody needs to communicate that. And so whoever owns the plan, uh, like for our organization, myself, Right. Somebody's gonna tell me that, that I can, I can update the document and share it out, make sure everyone is aware so we can be faster, do better next time.

Speaker A: Yeah, yeah,

Speaker D: yeah.

Speaker A: So, um, one other thing that I think is kind of underrated or overlooked. Like, I, I watch a lot of breaches in progress and like, I see the employees on Reddit sharing details about the breach and you know, journalists are writing about the breach. Like, like we can all see the breach happening. Right, because your services went away and a threat actor is saying that they hit you and they're saying that they have your data. Um, but there's no company statement. Right? Like, like, uh, you know, you know, people don't think as much. Like, when we're talking about Playbooks, people are thinking about, you know, enriching, you know, phishing emails and, uh, things like that. Technical things. But, um, there's a big difference between a, ah, breach handled well and a breach handled poorly. Like from a customer perspective. Right. Like, I have much more respect for a company that's transparent, uh, communicative, you know, tells you what's going on, uh, versus a company that tries to hide it or, you know, doesn't respond.

Speaker C: And.

Speaker A: Yeah. So, uh, I don't know if you guys handle that as well, but, um, you know, what do you see there? Yeah.

Speaker D: And I think that one of the best things that you can do, obviously, once you've confirmed an incident and assuming that you have it, is to engage with your cyber insurance. Right. Because they are going to be the ones to engage counsel on your behalf. Um, and it really depends on what industry you're in too. Right. Because even if it's suspected you haven't confirmed an incident yet. Right. There may be notification laws. Exactly. And if somebody says, uh, the big bad B word breach, and, uh, that clock starts ticking, you've only got a set amount of time. Right. So engage with your cyber insurance early if you can. Um, and that should be part of your instant response plan. At what point and what incident severity am I going to notify my cyber insurance? Uh, because then they engage the council. Right. And usually, at least, uh, logically, we end up working with them. Um, so we're not making disclosures and things like that. That's counsel. But the biggest thing that you need to engage them for is because then you're under attorney client privilege. Any conversation, uh, that you have past that point, be it with your msp, be it with any other outside entity, you want to have your counsel present so that that entire conversation is privileged. Right. And it's under attorney client privilege, can't be shared elsewhere. Um, and then they're going to tell you. All right, well, the clock is ticking. You confirmed this 18 hours ago. You've got to notify at 72 hours. And these are the entities that you have to notify. Uh, and they can help you with kind of a public statement that keeps you honest, but also maybe doesn't disclose too much because the threat actor is watching.

Speaker C: Yeah.

Speaker A: Well, and maybe the threat actor decides to disclose some of that, too. Like, oftentimes the most details. And it's kind of a frustration for me because I spent a lot of my time trying to understand how a breach happens, how people, uh, fail. Like, what are they missing in this process. And if the lawyers are keeping everything secret. Kind of hard to learn from other people's mistakes.

Speaker D: Right.

Speaker A: So I'm, um, I'm hoping this changes in the future and we're less concerned with keeping a secret because, um, I don't know. In my experience, the companies who are more open about how they got hacked, um, you know, looks better. Looks better for you. Yeah, uh, yeah, it's, uh, you know, that helps to rebuild the trust, I think. Yeah, a lot.

Speaker D: Well, and you're not going to please everyone during an incident anyway. Right. Um, there is a set amount of people that are going to be happy that you shared it early. Right. Um, there is absolutely no one that's going to be happy, uh, that you shared it late. So you just kind of got to take that one on the chin. Right. So just get it out of the way. And that way, those that do respect the decision can be in your corner. But, uh, yeah, even if you don't

Speaker A: have all the details, put something out there.

Speaker D: Yeah, exactly, exactly. We're aware of a data, uh, incident and we're currently working to identify the scope. Right. Like that is as much of a statement as most people need to at the beginning.

Speaker A: So uh, you know, if you're going to narrow it down to three things that um, you know, like, like particularly the stuff you see over and over and over where like companies should just be doing this, they shouldn't need you telling them to do it. But, but we're here, we're recording a podcast. Like what are those three things that everybody seems to be missing that, that they have to hit almost right away when you start working with them?

Speaker D: I mean, uh, there is way too much decision making that is happening at the time of an incident. So that's usually the first thing that we've kind of got to nip. Right. Is uh, let's speak indefinite. What are we going to do when this happens? Um, not I'm going to call are we going to pay head of it? Well, there's that, there's. When do we contact insurance? It shouldn't be waiting for your head of IT or your COO or insert executive here, um, to make a decision. It should be speaking indefinite as much as possible. Right. Because that decision paralysis when the pressure is on is crippling. Right. Um, they're on vacation, they're in a

Speaker A: plane without wi fi. Right?

Speaker D: Yeah, yeah, 100% right. And everybody thinks it's not going to happen to them. Um, so you know, it's that and it's also shifting the mindset of uh, it's not if it is when everyone will have an incident at some point. Uh, if you're in the game long enough, right. If you're operating a business long enough is going to happen to you. Whether that's just a business email compromise or a full on ransomware, uh, incident. Right. So it's going to happen. Um, got to get out of that mindset of it's not going to happen to me. Um, and then it's who's going to command. Right. Um, there's way too many of these where like it, legal leadership, everyone's trying to be the chief and no one's actually taking direction from anyone. Well, you've got to decide who's going to make the call. Right? Uh, who is responsible for making the decisions that can't be definite in your plan. Um, and then I think we see and this has gotten a bit more recently, I think with the age of A.I. uh, people trying to take too much into their own hands. Right. And then they end up destroying evidence and having their claims denied. Because your help desk guy really thought he knew what he was doing. Right. Um, and he asked Jim and I to tell him how to remove ransomware from this piece. Um, you know, those are very common kind of mistakes. Um, and you already hit, uh, you know, the other big one is trying to keep it a secret. Right. Just. Just tell people. There's a percentage of people that will be very happy you did. Um, gonna keep everyone happy anyway, so be prepared to win the trust back.

Speaker A: Yeah. Streisand effect is a real thing. Uh, we see it all the time. Everybody should be familiar with Streisand effect. The more you try and keep it a secret, the more people are interested in that secret. Now you keep their interest. Why are you trying to hide it?

Speaker D: Yeah, well, bad news travels fast, but rumors travel faster, right? Everybody loves the gossip.

Speaker A: Yeah. Yeah, that's it. Well, Kyle, this was delightful. Thank you for joining me today. This was great.

Speaker D: Yeah, absolutely, absolutely. Thanks for having me. I'd be happy to do it again.

Speaker A: All right, and stay tuned when we come back, we're going to talk identity for AI agents with Todd Tiemann from Omdia. Zero Trust is clearly the future as threats get faster, quieter, and harder to detect. But implementing it shouldn't disrupt the business. Threat locker enforces default deny at execution in a way that remains enterprise ready, scalable, and operationally clean. Unknown software is stopped cold. Trusted apps stay contained, and drift is locked down across the environment. It's Zero Trust that works in real enterprises and prepares you for the threats ahead. See why CISOs are adopting it at securityweekly.com threatlocker welcome back to Enterprise Security Weekly. Todd Tiemann joins us today to talk about identity for AI agents. Todd is a principal analyst at Omdia. Welcome to the show, Todd.

Speaker C: Great to be here with you. Adrian. Good to see you again.

Speaker A: Good to see you. And, uh, you came with data. You came with, uh, some information for us to discuss. Uh, we have every episode of Enterprise security weekly since ChatGPT was first released has mentioned AI uh, but we don't always have data about what's going on here. So I get very excited when we kind of back up, take a bigger picture view of what's going on, and kind of analyze where things are going. And that's what you've brought for us today. So tell us a little bit about, um, uh, the data that you've brought today and, uh, uh, what the incentive was for gathering this data and analyzing it.

Speaker C: And I always appreciate having a discussion with a connoisseur of data like yourself because I know you have an analyst background, you've been in the trenches, you know, the ins and outs of this stuff. Um, indeed. Uh, so, uh, just for those that I haven't met, uh, uh, on Enterprise Security Weekly, I'm an Omdia analyst looking at identity security or identity and access management as well as data security as well as data protection, basically backup and recovery. Um, my background is I've been in cybersecurity for 20 plus years, mostly on uh, the vendor side, working in product marketing for various companies. But about two and a half years ago I took a jump to the industry analyst side at Omdia. And uh, one of the things that we're known for is rigorous serving of the market to understand, you know, what, what's making people tick, what the problems are, what's going on with, with different uh, topics. And you're always trying to uh, to catch a wave that's just cresting about a problem space that, that's sort of nebulous, uh, the gray area that you try to make black and white. And for me that was looking at identity security for AI agents. This was something we kicked off the beginning of this year and um, uh, the results came out uh, just before the middle of the year. And basically uh, I was going out to identity security leaders to get a sense of uh, starting high with where are the agents, where are they being used within the organization? And then dropping down to some details, detailed stuff about, okay, where are your target deployment locations? What are the credential types you're going to use? Um, because AI agents really mix um, things up for identity security in general. But one of the interesting things about identity is as you probably realize, is the identity leaders typically have a good perch to see what's going on throughout the enterprise. They're not just focused on the SoC, they're not focused on DLP. They're seeing from a macro level what's happening writ large in the organization. Although you know, there's always shadow or unsanctioned AI agents that they might not know about, but they have a pretty good understanding.

Speaker A: Yeah, yeah. So certainly on the podcast a lot of our conversation has centered around um, uh, AI in the SoC. In fact, I had a prediction that uh, last year that if we didn't see any acquisitions in that area, it meant one of two things. It meant um, either just wasn't working in that use case. Right. AI was found to be less useful than anticipated. Um, or uh, because if it did catch on we would have expected Arctic Wolf and uh, expel and every MSSP out there that's worried about human cost margins to jump into this, right? Or number two it meant that it was easy enough for them to build themselves. Right? And I think it's ended up being number two. Like we've heard that all those MSSPs, uh, all those MDR firms, uh, have built their own AI SOC tooling in house. And uh, you know, so it's just kind of changed the ICP I guess of uh, you know uh, what these AI SOC companies are going to be focused on. So on the podcast we've been kind of over focused I think on that. Uh, we had somebody uh, um, come on talk about detection engineering a few weeks ago. Very interesting conversation but obviously AI agents are not being limited to just this one use case. So you've got some data on where these AI agents are going to um, from that IAM perspective. So uh, is this a good time to start sharing?

Speaker C: Yeah, let's share some data. And it does warm my heart to hear about like MDR and AI agents because I spent some time with uh, different vendors in past lives in that space and that's a great uh, application of AI agents. And the sweet thing about all those vendors is they have all the training data uh, to make those agents very effective. So there should be a big use case there. But uh, so one of the questions I asked uh, going out of the gate was okay, uh, what departments or functional areas are using AI agents? Because yeah there's a lot of talk about AI agents in the SoC, but there's a lot of different departments within any given enterprise. And uh, for those of the folks uh, looking at the video here you can see the chart breakdown where uh, number one uh, place for uh, function using I agents is IT Operations and then okay Business Intelligence Data analytics and number three was the soc, uh Security Operations Center. But what struck me from the data is agents were uh, proliferating within the organization. It's not just an IT function, it's not just a security function, it's Human Resources and legal and ah, pretty much everybody within the enterprise is using or considering using uh, AI agents. And again this, this data comes from the identity uh practitioners, the identity leaders within the organization. But they have a seat at that, that AI governance table and, and have pretty good understanding what's going on and that this was uh, what, what they said in terms of where they thought saw AI Agents being used or piloted or planned.

Speaker A: Yeah. And I, I, I, I wonder if this is uh, maybe not including, you know, because you've seen specified AI agents. So if my legal team is using Harvey, I probably wouldn't consider that an AI agent. Right, that's a SaaS, uh, platform, maybe. So there's probably even more AI use than what this is revealing.

Speaker C: Yeah, there is some ambiguity whenever you put these surveys, uh, out. There can be some ambiguity in how someone interprets the question. Ah, that's one of the arts in doing this is trying to be as precise, uh, as you can. So you don't regurgitate the conventional wisdom with the question, but you get a lot of insights. Um, one of the other things, if you want to flip to the next slide, I asked okay, what function areas using AI agents? But then I said what are the use cases you're looking to fulfill? So this is another cut at similar information, but again the subtext here is throughout the enterprise in a bunch of different use cases. Uh, number one is supporting, uh, I.T. ops, uh, okay, then help desk employee help, and then okay, security operations number three. But it's again throughout the organization. And one of the interesting things is you look at the data and how these things are proliferating throughout the enterprise is a lot of these workflows cross boundaries within the enterprise. And so uh, from a security practitioner, you're having to deal with a lot of different, different departments that, that have, ah, have, have influence, have say uh, that you have to deal with to, to ensure the security of the, that, that AI agent fleet within the organization. But um, when I looked at this data from my, my analyst hat and my analyst Swim Lane, um, from, from uh, uh, an identity standpoint, okay, you're going to need to have an inventory of all these agents. Uh, you're going to need to have uh, observability as to what they're doing. Uh, you're going to need to have a fine grain access control because an agent doesn't need all of Adrian's privileges, it needs a subset to do that job. Or maybe it's sort of a semi autonomous agent. Um, and then you're also going to need to have governance and you're going to need to have life cycle management to, you know, if something goes sideways, the ability to kill it, uh, that sort of thing. But that's from an identity standpoint. And then you look at the, the data security standpoint and you can say oh, you need to have a handle on all the data that's informing These AI agents. So that rag infrastructure training, your models, you're going to need to have data security, posture management to identify and categorize that data. There's going to need to be data loss prevention so you're not giving away the store when it comes to this stuff. And also, well, the DSPM sort of crosses uh, over to DLP because you're going to need to properly label this stuff so it doesn't get uh, manipulated or abused.

Speaker A: Yeah, yeah. And it's um, interesting seeing like the uh, you know, some of the business uh, priorities here as well. It's interesting to see still uh, IT operations being at the top there. And then you know, we've got uh, some other things that are similar there. Uh, as you go down the list like streamlining operations, you know, because uh, you know, to me I think we sometimes need reminding that confidentiality is not the most important thing to the business. It's usually availability. It's keeping things up and running, keeping the lights on. So uh, it doesn't surprise me to see IT operations on top there because I've been looking at uh, cyber insurance data that shows uh, recovery as the biggest cost. Uh, getting things back up and up and running is typically the biggest cost when somebody has a ransomware incident or something like that.

Speaker C: Yeah, it's super interesting. Uh, as I looked at this data and I talked to people, it's sort of like if you've ever heard the story about the blind man and the elephant where someone feels the ear of the elephant and says oh, this is a tent and someone feels the trunk and says oh, this is a hose and some feels the tail and oh, this is a rope but it's the elephant. You know, everybody comes at it with their sort of frame and I agree wholeheartedly. You know, one of the big costs is uh, the possibility for AI agents to maybe disrupt operations. And you're going to need to recover and that's uh, data resilience, um, backup and recovery. Look at pocket OS and that sort of thing. You're going to need to uh, accommodate or recover from that sort of thing. But there's also vulnerability management. There's also basically it affects every domain within cybersecurity in some way, shape or form. And it's, it's good to, to, to zoom out sometimes from, because everybody has their, their, their sweet spot of what they focus on. But there's some macro implications here that, that are good to understand.

Speaker A: Yeah, I, I, I like the elephant metaphor, particularly for cybersecurity because at some Point the elephant doesn't like its tail being pulled and kicks you, right?

Speaker C: Yes, yes, very, very true, very true. That's, that's uh, what keeps things exciting and vibrant, uh, is how quickly things can, can change. And that's, you know, you walk the, some of the trade shows at RSA or I'm anticipating Black Hat. It's, it's a, it's an amazing time to be in cyber security given how quickly uh, things are changing and enterprises are embracing AI, uh, agents. But the, the, some of the security implications are still becoming clear and what the right uh, stack is for securing AI agents is still becoming clear

Speaker A: or less murky.

Speaker C: Yeah, that's a good way of putting it. That's a good way of putting it. Yeah.

Speaker A: Yeah. When I listened, I put together a blog post earlier after listening to all the RSA keynotes, um, I listened to 11 of the big stage keynotes and one of the things that I came away with was that everybody agreed that something needed to be done, uh, to secure AI agents. Um, but nobody even agreed on how AI agents would be used or what they would look like. Right? You had some people up there saying an AI agent's going to be long lived and it's going to learn over time and get better over time. And then uh, somebody else gets on stage and says, uh, actually it's going to be just in time. The agents can exist in a Docker container and it's going to exist for eight seconds. And the moment, uh, what it's done, uh, once it's served its purpose, it's ephemeral, it's going to be deleted, its credentials are gone. And um, I think the truth is probably all of the above. We're going to see every kind of agent you can imagine, uh, at least in the near term when people are experimenting, trying to figure out uh, what works best for each of these use cases. You just shared all these use cases. The same approach to doing AI agent is not going to work the same across all of these 100%.

Speaker C: And it gets, it's interesting in that you have on behalf of agents, you know, on behalf of Todd, um, but then you have semi autonomous agents that might be operating in IT infrastructure. And then when you look at the customer identity and access management or CIAM space, everybody, a lot of folks focus on workforce, but there's this big area of customer identity access management. And you're going to need to take into account how agents are operating in the CIAM space, uh, which is somewhat different than the workforce space. So it's fascinating. One of the other interesting things that, from a data perspective that came out, I asked where does the budget come from for this? And if you want to flash that slide up there, uh, for me, this was one of the AHAs, because whenever you're out there surveying around, uh, a given topic, you're hoping to get two or three, uh, different nuggets of insight here. And this was one of my nuggets of insight because the question I asked was, how's your organization structuring its budget for identity security surrounding AI agent initiatives? And you might think, well, the Identity team, they're going to use their existing CISO or CIO budget, draw that down, uh, from other places and deploy it for AI agents. And yeah, that was true. And about 15% of the folks said, that's what we're doing. We're using that, existing budgets and other identity areas and going to use it for AI agents. But then there was, you know, like 20% that said we're using a, uh, digital transformation budget or some big picture, uh, AI budget.

Speaker A: And then you, the transform transformation never finishes. It just transitions from one technology trend to the next.

Speaker C: There you go. And then you had sort of science projects or innovation budgets. And yeah, a bunch of people were doing that. But the biggest budget area was a completely new standalone budget for AI. Um, and the subtext there, my read on it was you had the executive, the CEO, say to their chief data officer, their chief AI officer, their chief technology officer, we got to take advantage of this AI stuff to improve our efficiency to generate new revenues. Here's a pot of money. Go make it happen. And then there's a identity tax against that budget, or there's a data security tax against that budget. I mean, this data comes from the Identity Team. And this is what they were saying. Um, um, Omdia actually ran this survey like six months prior to this one against an IT audience. And you saw similar data come back from an IT audience.

Speaker B: But

Speaker C: the big pot that was using a completely new standalone budget rather than being 36% for, for the, um, for the Identity Team, it was like 44% for, for the IT team, meaning the, the IT team was being more effective at tapping into that budget for their initiatives compared to the Identity Team. I think, I think they're the, the Identity team has some work to do in terms of improving their, their tin cupping skills, their ability to tap into those budgets. But in speaking to different practitioners, um, this is not something unique to Identity. It's pretty much across security. There's A separate budget. And you have to be able to articulate the business case of why what you're doing in this part of security is helping that AI agent or that AI initiative.

Speaker A: Hopefully that's not the same budget that tokens are coming out of because I hear those are running dry pretty quick, uh, in 2026.

Speaker C: Yeah, I suspect it might be that same budget. Um, but one of the interesting things here is, okay, we did this survey in early or the first quarter of 2026, um, and I suspect if I did it again today, it'd be different and roll forward two years, um, if I want to prognosticate it as an analyst. And uh, you know, we all like to prognosticate as analysts. I'd say things are going to revert to the mean in say two years where it'll go back to coming to a great degree from the CISO or CIO budget. But the fact that matters today is there's that separate budget and you have a real key initiative you need to fund. You're going to need to uh, uh, make sure you're tapping all available budget sources to of do what you think is right.

Speaker A: Yeah, yeah. Do you get a sense of how much of this is still experimentation at this point? Like I do get somewhat a sense that these AI committees are temporary and some of these AI budgets, uh, uh, are exploratory, they're experimental. Um, and uh, once we figure out how all that works, we're going to normalize budgets and it's just going to roll into each department's normal budget. Like what, what is the sense you're getting here and, and maybe you know, can we look at cloud for guidance on how this might go? Or is this too different from cloud to use that as um, ah, to inform what might happen with this in the future?

Speaker C: Yeah, it's, it's, it's kind of cloudy, kind of nebulous. Uh, is uh, uh, my sense. And there's so much, uh, there's so much going on in different organizations. There's no uh, clear rhyme or reason that's out there. I think that the cloud does hold, um, good lessons, sort of the past is prologue. What happened before in this case can be applied to that case, uh, to a great degree. So that would be true in my book.

Speaker A: Yeah, yeah. Um, one of the lessons we learned from cloud is it makes you more agile, but it's not cheaper than running things on prem. I think most people, I don't know where the idea that it would be cheaper came from. Having Somebody else rent the systems to you than you own it uh, yourself. But uh, I wonder if we'll see something similar here. It allows us to do things we couldn't do before AI, um, but it ain't cheaper. Right. And it's not saving us money.

Speaker C: So to that point, I mean I think you're seeing a lot of that coming out in terms of tokenomics. So people are, you know, before, you know, rewind six months ago, everybody's got to use this. And, and I mean we got embrace AI agents and you're a luddite if you're not doing that. And now the, the, the, the m, the budgetary cost is becoming clear hallucinations and, and uh, that some of the challenges are becoming clear. So people are winding back and saying okay, we got to make sure there's a compelling business case for doing this. Um, and one of the challenges for the industry, for the businesses writ large is going to be figuring out um, what someone just token maxing and showing, hey, I'm using a lot of tokens and what's a real productive use of those tokens. Um, that's going to be a challenge. But one of the interesting things in terms of uh, the cloud and maybe not being so effective, I asked the question what were your prioritized locations for deploying AI agents? And the answer that came back was number one, it was uh, the cloud with AWS Bedrock, Google Vertex, Microsoft Agent Studio. Number two was SaaS agents and it was only like a couple percentage points behind. And that's like Salesforce, Agent force, workday, agent, ServiceNow. And then number three was sort of APIs and endpoints. Um, so that's Claude code and codecs and that sort of thing. And something for me, when I first looked at that, I said okay, this is super interesting in terms of the prioritized location and it also speaks to the value of a platform to be able to cover all these different use cases. Um, but then when I spoke to a lot of folks on the ground, practitioners as well as different vendors that are out there, I saw a bunch of different use cases. Um, the use case for that endpoint is going to be different than the cloud. It might be different folks involved in that decision. So it's one of those uh, when it comes to the platform versus best of breed, that play is uh, being applied here where you have a lot of nimble startups that are able to knock down use cases with comprehensive functionality and some of the bigger players might take a little more time for them to provide that sort of functionality.

Speaker A: Yeah, it's going to be interesting as like um, sure, Salesforce is going to have their own agents. So you can't plug in Claude.

Speaker B: Right.

Speaker A: You know you can't bring, bring your own model. Um, but you kind of can now that we, you know, AI can use a mouse and keyboard. You know, maybe you still do use Claude and Claude is just using Salesforce, the UI that was built for humans now uh, works for AI agents. And you can kind of, you know I'm less concerned about uh, the API or you know, what their own agents are capable of. When I can just have it use it like a human does. When I can have it operate a mouse and a keyboard and interact with the, the human based ui. So then that brings up uh, another um, you know like, like the whole capture problem. Right. Like if I'm going to have an AI use an interface built for humans, um, you know are you know, companies like Salesforce, SaaS companies going to try uh, and prevent that with CAPTCHAS and things like that? They're going to try and control it and make you use their agents to that point.

Speaker C: One of the foundational problems we have right now is where folks are giving their AI agents all of their permissions and it's difficult uh, from the telemetry to see okay, what's the human and what's the agent. And it's the basic problem. It's a process problem to a significant degree but it's something that's going to need to be solved uh because that makes life real difficult to. When you can't tell what's an agent, what's a human doing some activity.

Speaker A: It's going to be a great excuse though. That wasn't me, that was Claude. Claude did that. I didn't tell my agent to do that. It wasn't me. Yeah, it's going to be ah, I'm sure HR is going to be hearing that.

Speaker C: Oh yeah. But think about like the customer identity and access management CIAM use case. You know, I didn't buy that Amazon thing. I shouldn't have to pay for that. It's something that, particularly on the ecosystem E commerce side, uh, that's something that is preoccupying and they're spending a lot of cycles trying to make sure that that's locked down.

Speaker A: Yeah, uh, insurance companies don't want to cover that. They've already shared that. Uh, we've already seen them trying to create uh, exceptions for clauses when AI is in the mix.

Speaker C: Um, there will be a lot of

Speaker A: exceptions So I think talking about like what form, uh, you know, how does that AI agent access resources, how does it access data? I think that takes us to our last um, data point. We wanted to share here.

Speaker C: Yes. So I asked the question, okay, what credentials are you using, uh, looking to use today and what credentials do you want to use in 24 months? And you can see what came back today it's OAuth client ID and client secret is number one and okay, number two today was shared service accounts or maybe the human user credentials and then static API keys. So you had OAuth and then you had a lot of long lived uh, static credentials that were being used uh, today. So that sort of underscores the challenge we have with long live credentials. Everybody wants to move to just in time, zero standing privileges. But the fact of the matter is today we don't live in that world to a great degree. Um, but you also look down at the, the bottom here in terms of mutual, uh, TLS was one of the things that was modestly used today, but if you look at where people want it to be in 24 months, it was OAuth and it was MTLS, uh, mutual TLS PKI certificates. So the, those things are actually not mutually exclusive. They complement each other where mtls that'll validate the endpoint that's good to go. Uh, and uh, uh, OAUTH is uh, user application, short lived credential, et cetera. They're complementary, uh, but that's where the growth was. But one of the things that struck me is that those static credentials, they're not going away anytime soon. Even though everybody understands how unpleasant they are and the risks, risk, um, um, it's just uh, they're so embedded in the architecture and it's not like somebody's going to get a promotion by getting rid of or you know, reducing the number of long live credentials that are in their environment. There's not like a compliance hammer or some incentive to get rid of them. So they're going to linger for a bit.

Speaker A: Yeah, yeah, I think it's like the rest of technology, right. Like um, private data centers didn't go away because cloud is a thing. Right. You know, we often see new technologies coming out. Uh, you know, passwordless is a thing but uh, I think we're gonna uh, we're still gonna have um, you know, passwords hashed and stored uh, for a long, long time. There's gonna be a long tail on a lot of this stuff. And also to your point, uh, to your slide earlier with all the different use cases, not all the same credentials are even available in some of these use cases. Right. So it makes sense that as diverse as the agent ecosystem is going to be, uh, the methods and the credentials used are going to be equally diverse.

Speaker C: 100%. 100%. We all talk about AI agents but you have to look underneath and that's like a non human identity API key or something. Something that's underneath that you're going to have to consider. Uh, so it's one of those things that will probably, uh, I'm anticipating this year you're going to see some significant breach and at the end of the day it's going to be tied to an AI agent and identity because identity is at the root of a lot of problems, uh, out there. And with these long lived credentials, it's going to be ripe for abuse.

Speaker A: Yeah, for sure. Well, Todd, um, I imagine we've probably just skimmed the surface of this survey that you've done. You've got a lot more data on it. This report's available somewhere on Omdia's website. Uh, tell us a little bit about where to find it and what that, you know, if I wanted to see the whole report.

Speaker C: So, uh, the whole report and some of the uh, ancillary, uh, items are on the Omdia Go to Market, uh, portal. So for subscribers you can get it there. Um, I'll put this, uh, we'll put these slides uh, on, associated with the, with the Enterprise Security Weekly if I understand things correctly. So these, these, these uh, data points you have there. Um, but those would be the, the two locations, uh, where you can get it. And I put some of this data out in different blogs that I put out there. So that'd be the third location.

Speaker A: All right, great. Uh, Todd, thank you so much for joining me today. Uh, great conversation.

Speaker C: Adrian, always a pleasure, Always a pleasure to see your smiling face.

Speaker A: Likewise, likewise. And uh, yeah, maybe, uh. Are you going to Vegas?

Speaker C: I'm going to be in Vegas. See you at Black Cat.

Speaker A: All right, I will see you there. Um, people listening to this will see it just after that week. This will come out on uh, August 10th. Um, but yeah, that's the reason we're pre recording it is. I will be there as well, uh, in person. All right, um, big thanks to everyone watching or listening to this week's episode of Enterprise Security Weekly. Next week we'll be talking to Andrew Dunbar about Universal Commerce Protocol and whether bug bounties still make sense in the age of AI vulnerability discovery. He's the ciso over at Shopify. So I'm very excited for that, uh, conversation that should be very interesting. And thanks again, Todd.

Speaker C: Thanks, everyone.

Speaker D: Cheers.