Cybersecurity and Disaster Recovery — Threat Modeling, Testing, and Near Misses | Security Boulevard Ep. 17

Welcome to the Security Boulevard, the cybersecurity podcast from The Future Room Group. Each episode explores a variety of topics within cybersecurity and the technologies that drive it. com, security Boulevard, YouTube Channel Techstrong tv, and all of your favorite podcast platforms.

Before we dive into today's episode, let's meet today's panel starting with Mitch. Mitch, it's good to see you. Hey, Great to see you.

Mitch Ashley, I lead the software lifecycle engineering practice analyst practice at Rum, kind, dabble in security, working with Fernando and team and software, supply chain, security, all that good kind of thing. That's good to have you and, uh, the other co-host this week. Uh, Mr.

Fernando Montenegro, Fernando, I, I, Montenegro, I lead cybersecurity research, and, uh, we had, we barely started. There's a correction to be made. Mitch doesn't dabble in in security.

Mitch knows security, right? So, uh, um, it's interesting because there is a, a, like, as the industry's changing and whatnot, the, the, the overlaps between, uh, security and observability, for example, right? Uh, he is amazing at this, and, and, and I rely on, on his judgment and knowledge, uh, many, many times during the week.

Well, let's end this episode right there before Fernando changes his mind. Thank you, Fernando. And of course, I am Tom Hollingsworth, event lead for security at Tech Field Day, a part of the Futurum Group.

Let's dive into this episode now as we're recording this. The weekend was a little bit messy for most people. There was a huge weather system that tracked through the United States.

Uh, there were power outages, uh, schools were canceled. They even closed a couple of waffle houses. And for those of you who are not in the us, closing a waffle House is tantamount to shutting down the military, the government, and anything you've got, because it is the most reliable service that we have.

But that made me think a little bit about the way that we plan for disasters, because a giant weather system may not be the kind of disaster that you think is, is going to cause a problem. But what about a security disaster? What if, uh, you know, I don't know, some of your, uh, password files get leaked online?

Or what if somebody manages to abscond with some of your data or crypto lock it? Uh, how do you respond to that? Can you respond to that?

And worse yet, is your response to that, oh, I better go check to see if my disaster recovery plan is up to date. Because we all know that sometimes people don't think about disaster until it's upon them. So I'm gonna open this up to you, you gentlemen.

Have we ever seen one of those situations in the past where it felt like the disaster recovery plan was making it up as we go? Oh, I can, I could name a few names and a few companies, but I think I'd get in trouble if I did that. No, I think, I think, you know, it, it, it's funny.

We call it a disaster recovery or, or business continuity plan, or whatever it might be. It, it, it's sort of like any plan that you create, whether it's disaster recovery or a project plan, is outta date. As soon as you hit save, 'cause the environment changes, something's different, something's new.

You know, the, the CEO comes to you and says, we're gonna do this now. So it's, it's a little tough to create a fixed plan. Uh, so I think you're almost really developing a system, and the plan is just a reference implementation of your system, of what your disaster recovery process systems, people, et cetera, look like.

And I think if you take that kind of an approach, you'll have a little more to borrow a term from, from Fernando's cyber resilience practice, you'll have more resilience into that system as opposed to, well, we did that in, uh, what is it, oh, 13. I think we're a little out of date. We probably ought to update this.

Yeah, a lot of things have changed since two th 2013, so, Yeah. Well, so, uh, the, we also had, so I'm up in Canada, and we also had weather here, uh, I here in the, in the greater Toronto area. I haven't checked the news recently, but it, it may have been like record snow storm, uh, snow accumulation.

Thankfully, it's, it's, uh, relatively light and fluffy snow. So I can, I can deal with it. Don't You call our, I'm sorry to interrupt for now.

No, don't you call our, our kind of storm that we're having, you just call that Monday up there, don't you? Isn't that Sort of No, no, no. Listen, listen, I, and, and, and tying back, tying back to this topic, right?

I think that one of the things about preparedness is that you always have to have a, um, uh, a threat model. Like your threat model needs to have, uh, needs to be realistic to your environment. It needs to meet your requirements and needs to, to account for the things that, that you are, uh, willing to, to, to, to address.

And in many places in the United States this week, uh, they're not, like, they're not statistically ready to, or it's not statistically, um, relevant to them to have preparations for this. So my heart goes out to the people who have been affected by this. I know that, uh, um, I know that, uh, that, uh, it, it was very disruptive in many places where an inch of snow, an inch of ice is literally the community stopping kind of stuff.

So, but yes, like the, the, the, these kinds of amounts up here in, in the greater Toronto area. Yeah, that's, that's Tuesday, right? Uh, funny enough, uh, if you go further north in Canada, right?

People who live further north think that about us here in Toronto, right? So, so like, it's, it's fine. Like it's, uh, it's all relative.

It's all relative. But, but, but Tom, to to, to your point on, on preparedness, right? I, uh, uh, there is that, uh, quote that always attributed to Eisenhower, uh, sometimes variations with, uh, uh, with, uh, Mike Tyson, right?

I mean, the, uh, plans are worthless, but planning is everything. And the other is everybody has a plan until they punch in the face, right? Those are the, you can figure out which ones Howard, which ones Tyson, right?

But, uh, It, it's a really good point. And, and to illustrate that, I actually wanna bring up something since, uh, Mitch mentioned 2013, uh, a lot of people lose track of the planning process because they never actually test their plan. I worked with a customer many years ago at a previous job, and, and we don't get a lot of snowstorms in Oklahoma, but we get the other kind of weather that tends to level buildings, uh, especially in the springtime.

Uh, we are in the middle of tornado alley, and, uh, I was working with the school and they had a solid backup plan. Uh, you know, we're gonna put things on tape, and if something happens, we've got the tapes. And then one day they had to evacuate the main building because of a, uh, a tornado threat.

And someone realized that their backup plan wouldn't work if the tapes were still in the building, if it was gonna get hit. And they had to literally run into the building to grab a box of backup tapes and throw it in their car as they're evacuating. Fast forward a couple of years to 2013, and one of the largest F five tornadoes ever recorded, hit another school district administration building.

Wow. And they had to sift through the rubble to pull out the drives of the servers, to insert them into different servers, to be able to run payroll for the teachers to be able to buy supplies, to start rebuilding their houses and things like that, because they never thought what would happen if we got hit by a, a severe weather event so big? It literally leveled the building.

You don't think about those things until you're in the middle of a disaster. And that's one of the reasons why you have to test your disaster plan, because you need to know where the failure points are. Oh, the generators will immediately fall over if the power goes out.

Really? Did you test it? Will they automatically fall over?

Or does someone have to go hit the big switch to cause a failover? If that's the case, who's gonna do it if everybody's pinned at home in the middle of a snowstorm? And how does, you know, things like DNS records work and what's gonna happen if somebody's logged into the servers when the power cut happens?

Like if you don't test it and then jot down all the failure points, you might as well throw the binder out because it's useless to everybody. And I spot on. And I would argue there's one step before that, which is what goes into the plan in the first place, right?

And I think that that is an area where, uh, bringing this back to cybersecurity, we've had, uh, multiple cases where incidents have happened where it's not like, it's not that they were completely novel, right? It was the case where, yeah, you think this true a little bit, and oh, by the way, that can happen, right? And this is an area where I am, I'm, uh, uh, I'm really interested in the work that's being done in adjacent areas, right?

So in tion, for example, there's an entire field of study on near misses, right? So why did this almost happen, right? And, uh, I know that in cybersecurity, I know that, uh, Adam Schack has written about near misses in the past.

Mm-hmm. And I know that, um, and I think that like, uh, Wendy Na and Bob Lord, uh, uh, were talking about CSA last week. So Bob was at, at CSA not too long ago.

Uh, and, uh, I think that they are doing some work on near misses as well, right? Which is how do we as a community learn from the near misses, right? This bad thing.

Why did something horrible? I mean, it almost happened what got us there, right? So, um, yes, very much about planning and very much about thinking through, sorry, where being creative about what can go wrong, right?

It's risk management. My kids hate when I, when I, when I talk about risk, I use it to tease them, of course, right? But, uh, it's risk management, right?

And I think that, that, that our jobs in, in this industry is to elevate that risk management conversation. Tom, to your point, precisely to think through about these things. By the way, we do have an official mascot now, Nate, the cyber cat has joined us.

So this is Nate, everybody good buddy of mine. You know, it, it's, it's interesting just kind of my own experiences with disaster recovery plans. I think one of the takeaways for me was, you know, even a plan can be a bad plan, right?

Just because you have a plan doesn't mean it's a good plan. And because you've tested it doesn't mean it's foolproof. That the things that worked when you tested it, tested it could still fail, right?

You still could have some problem where the UPS doesn't kick in like it's supposed to. The cooling doesn't happen like it's supposed to. But even more simple, more easy, easy kind of simple things you would think about, don't assume, like one of the, one of the plans that had to just completely revamp.

'cause it was, um, really more than a decade old, and all the technology was changed. Um, but when assumption was that such, and so employees live close to the building, and if this happened, if the computer data center overheated, they could come open the door and cool it down. Well, what happens when you camp the ice storm, the fire, the whatever?

And, and that there were things like that, that we addressed and, and, and fixed and made sure that that wasn't the, wasn't the the main way we were gonna solve it. And then as it happened, within five years, and I think it was then another three years after that, we first had floods that went right up to the edge of the building. Nobody could get to the building.

And a couple years later, they had complete fire. A whole bunch of houses got built down, businesses got, but uh, burned down, um, right near our offices. Again, can't get into it, right?

Can't even get into the neighborhoods to do anything. So physical access is not an option. So I think that's one of the things when you think about the, the, uh, risk analysis, Fernando, is think about what assumptions we make that we shouldn't assume that's true, even if we've tested it.

Does that ring true? I think that one of the things that rings very true is that the world is unpredictable. The world.

Like we can't guarantee anything, right? And, um, one of the, one of the concepts that I learned along the way is that I love, and, and, and it's very, very relevant to this. It's the notion of resulting, not sure if you ever heard of the concept of resulting.

Mm-hmm. So, uh, I read about it from, so Annie Duke, she, she was a poker player and now teaches decision science. And Annie Duke wrote a book called Thinking that, uh, basically how to make better decisions.

And the idea of resulting is when people mistake the quality of the outcome with the quality of the decision, right? And we cannot control the outcome. We can control the decision, right?

But we cannot. And and you may have made a horrible, a poor quality decision that still turned out okay. Oh, I'm gonna, I'm gonna go on my tip toes on this thing to pick up that one thing over there, as opposed to getting the ladder.

And I still fine, right? Um, I say that it's particularly relevant. I don't mean to bring football into this, but, uh, as we're recording this, the, they just defined the, the play, the, the teams for Super Bowl 60, right?

So Seahawks and Patriots, uh, 11 years ago, they had, that was the fame, the fame, uh, uh, matchup. And any, duke uses the example of what happened in Super Bowl 49, uh, as an example of resulting because the, the, the Seahawks made the play at the one yard line that didn't work as people expected. And they were crazy about the, but then when you look into the decision, that was that the decision, that was a sound decision that led to that play.

Sure it didn't work because that's life. That's, that's football, right? That's the, but, uh, sorry, I'm meandering as usual.

But it's this, this notion of what is the quality of the, the decisions that you were making as a professional? Are you, are you thinking through like the checklist that you need to do, Tom, to your point, to make the plans, like to think through, like, how good is your decision process to create those recovery plans, to create those, those plans that, uh, do they match reality? And I think the point that you guys are kind of bringing up that it's important to realize is that a lot of these plans are based on a series of assumptions that we need to make sure that we can validate.

So here's a good one. Let's say you have some kind of a data protection system in place that is creating regular backups that are stored offsite. What if you have to log into active directory to restore those?

What happens if active directory is no longer available because it's been violated or it's been shut off or something? 'cause we're seeing that a lot now in cyber attacks, is that people are going after backups and people are going after active directory to halt any kind of, you know, cross system functionality. Well then how do you get your backups back?

Can, can you get them back without being logged into active directory? And those are the kinds of assumptions that you have to challenge. Kind of to Mitch's point, you know, someone will always be able to go over to the building and open the door, but what if they're not?

How do we plan for that? And I'm sure that you guys are probably sitting there thinking to yourselves in, in the audience, you know, oh, this is just a big tabletop exercise of how all the crazy ways that I can, I can get around this. Well, insecurity, those crazy ways to get around things are exactly what your attackers are thinking of, right?

They, they want to try to hit you from an angle that you're not expecting, that you haven't planned for. I mean, I saw something today about, you know, people trying to get account, um, access by sending text messages or communicating with people, uh, through email going, Hey, this is, uh, at and t we just wanted to reset your password because we noticed somebody's trying to log into it. Can you give us that code that you just got texted?

It's a little legit. All the links work, except, oh wait, that thing that you just got is actually gonna allow me to take over and then I'm gonna start hammering all of your other accounts for two factor stuff and whatever. Like, those are the kinds of things that you have to be ready to adjust in your plan.

What happens if an admin gets compromised? What happens if your CEO's email starts spewing out, um, you know, spam or, or attacks or something like that? You have to think through that.

And I realize that a lot of this feels like exception handling, like, you know, programming an auto, an autonomous car, like what happens if a 7 47 lands on the highway? Like, you're right, the, the likelihood of it happening is low, but it's never zero. So, like, you know, how do you Tom about this?

Go ahead, Tom, about, this is not a linear process either. The, you know, there, the, the, what you see as the attack may not actually be the attack. There may be a secondary action is, which is really to get you to start the backups.

And that's when they're gonna compromise them because the, the system that you're, you're restoring, uh, to is, is actually the one that's gonna compromise and is gonna steal the data. It's kinda like in, in, I guess in tank warfare, not to get too militaristic about it, but a shells that penetrate tanks. It isn't the first, uh, contact with the tank that the shell penetrates.

It, it's really, that's just setting the stage to get through the explosives that happen that actually would then open it up to be penetrated by the follow-on, uh, secondary explosion from the, it's, uh, shell that's attacking the tank. So it's, you have the added factor of what, not only what if, what this happens, but what if we're not able to do what our action, the response is what if we're suspect about whether that environment's compromised or could be compromised if we take the restorative action. So it, it's, it's a multidimensional kind of three dimensional chess, if you will, and tie back to Star Wars and or Star Trek and Spock.

Yeah. And this is what, this is an area where, like, one of the, the areas I work closely with is part of the reason that the practice that, that I run is called cybersecurity and resilience, is that I work very closely with the, with many of the, the, the backup and recovery vendors that are, that, that work in this space, right? And one of the things that they do is precisely this notion of, okay, what does a clean room restore look like in a scenario where we need to restore ad before we do anything else?

As a matter of fact, a number of them are now tiptoeing their way into identity protection precisely on account of that, not to throw the, the AI into it as well. And they're using AI to help, uh, optimize that process. The, so it's, it's an evolution of, of, of, um, it's an evolution of the technologies, an evolution of the capabilities that practitioners have to review their plans and say, okay, alright, what is it that, what assumptions are we making?

Oh, we're assuming that we need to recover ad ourselves. Oh wait, our vendor can now do that for us. Okay?

Can we trust that the vendor can do so? It, the, the, it changes the nature of what you need to do. You're not recovering ad you are making sure that the vendor can recover ad for you, right?

So, uh, the evolving nature of the, the, of the disaster recovery plan is not only that things drift for bad, like I, but sometimes they drift for good. Like, I mean, there are new capabilities into your environment that you didn't have before. How can you make best use of them?

Right? Optimistic. Fernando, question for you.

You know, my thought is just like, you might use AI to analyze your business plan that you're, that you're creating, or maybe it's helping you create one. Certainly AI could be a good, uh, sounding board to run your disaster recovery plan through and test it, you know, put pressure on it. Um, but also could be for scenario testing.

Like what are the scenarios we're not thinking of? What are the latest kinds of scenarios we should start to consider how we adapt to, so AI could be your friend actually in helping you do a better job or keeping current with what's happening. And you can rule out the, you know, far edge cases.

'cause you don't think that's practical for you to even validate or test or protect against. But certainly you're not relying on just your thinking. It's like using an external consultant to help you.

Absolutely. The, the challenge there that the, here, every, every episode at some point, AI comes in, right? Uh, uh, the challenge, the thing I I challenge people there is that, look, yes, I agree wholeheartedly, but who is running the AI and what are you, what are you using the ai, how are you using the ai?

How much are you depending the ai, are you a backup and recovery specialist who is interacting with the AI to ask, hey, um, like precisely as you said to do the, Hey, let's, let's think through this, this scenario. What am I missing kind of thing. Or are you someone who is not of experienced in backup and recovery and you're coming to the AI for, oh, tell me what to do, because I dunno, right?

And if it's the latter that is complicated because you dunno how to evaluate the, the quality of that outcome, right? As well as if you are an expert, uh, and you're just using it as a tool. It, we go back to the AI as a, as a tool for an experienced professional versus, uh, uh, uh, less experienced person using it.

And, and not catching the hallucinations, not catching the mistakes, not catching the, I say this as somebody who's using AI a lot, uh, for my, uh, uh, uh, personal finance tracking, right? I, uh, it's great, but I know what I'm doing, right? I, I know what to ask.

You know what I mean? I, I Think it's important to realize that a lot of the pieces that get missed are kind of institutional knowledge. And I think where AI is gonna fall apart is that no one's ever documented this.

Hmm. And, and that's one of the reasons why I know for a fact, that's the reason why I originally started writing on my blog, was because a lot of the things that I was learning were things that maybe didn't exist anywhere else. Like we all know the XKCD, you know, the infamous one, you know, who are you Denver coder seven, and what do you know?

Because so many questions get asked that never get answered. And when someone does answer it in their head and go, yeah, that's how this works. They don't ever write down what that answer is.

And in the old world, that was, oh, that means that I've gotta solve that problem. But in the modern world, it's AI doesn't have a knowledge base to draw off of to create a solution to that problem. And so we, we kind of find ourselves with that knowledge gap, right?

'cause this is what I have been helped with up to this point, and here's where I need to be and how do I jump that gap? Because I promise you, an algorithm is not gonna be able to jump that gap no matter how many GPUs you throw at it, because it really doesn't know how to think outside of the box. That's where humans are still valuable in the loop.

What happens if these conditions aren't met? What happens if this really random exception occurs? And like, you know, it could be something as stupid as like a race condition.

The power comes back on, but the network isn't up and it starts timing out because it'll not connect. What do I do now? We don't know what the answer is until we have tried it right now, before anybody else goes out there.

Do not walk into your office tomorrow morning and just throw the master switch and go, let's see what happens. You need to kind of, you need to game through this. This is what I want to happen.

This is what I expect to happen. Let's test this in small scales to see what occurs. And then let's analyze what we tested to make sure that if something does go wrong, it's contained and fixable before we try it on a larger scale.

Because if you do that, just yank, let's see what happens. Uh, in the industry, we call that an RGEA resume generating event. You, you do not want to be on the receiving end of one of, especially nowadays.

Funny, like I have so many things. First of all, uh, point avoider, right? Uh, Mitch, you're based in Denver, aren't you?

Yes. Yeah. Yep.

And he knows, like, who knows, he might be that Denver Tom, who knows, right? Could be, could be, Could. But, uh, finally, finally, you mentioned that, that the throwing off the switch back when, when, uh, I was working on, on network security implementations, uh, I remember working with a, a healthcare customer where we built a, a multi-site, uh, uh, network with a firewall modules and switches.

And on the, the test plan was, okay, yank the power from the, the the, from the, from, from one of, from the, the, the, the rack, poof, yank the power watch, okay? For 1, 2, 3, 4 seconds pf converges, okay, we're good, right? Uh, but the, the firewall state crossed over like, okay, we're good, right?

But yeah, we had those things like, but to your point, that was not the test, right? That was one step of a very, very well-designed test plan for, but it was a fun one to do. I still get nervous anytime anybody tells me to do anything destructive on purpose.

And I'm like, are you sure I'm not gonna get in trouble if I do this right? It's in the plan. You're witnessing me do the thing that's in the plan because it, it feels wrong to purposefully break something.

Oh, yeah. But that should be replaced with this, um, joyous feeling of, Hey, my backup plan worked as soon as it happened, whether it's logging into Azure active directory instead of the local copy if something blows up or Yeah. You know, we can get that data back and we can do a fractional restore so we don't lose like three months of database tracking.

It's called an escalation of a resume generation event to career ending event. You'll quickly become the story that gets told at every conference for the rest of your life. Exactly.

Hey, remember that time that Fernando did x I've, I've, I've made a few mistakes that what, thankfully, I don't think any of those rise to that level. I'm sure not sure not, But, uh, but to go back to, to, to the topic, right? I think we're all circling around this notion of people needing to be, uh, needing to, to, to have the space and the knowledge and the, and the, the, the, the systemic thinking around creating the plans and the models and the, the, the countermeasures and so on for what they think is, is realistic.

And, um, one of the areas that the, the this is, and, and, and we need to be pushing ourselves to keep doing that. So we had the whole incident with CrowdStrike ago, right? Listen, very, all realistically, how far do in your testing, in your assumptions before making a decision of, you know what, I'm gonna trust this, and if this blows up, oops.

Right? I dunno. I, I've, I, as somebody who did endpoint security, I'm, I'm, I'm, I'm always nerve with around cradle mold stuff, so, Well, I think it, it, it's an important question to ask because past a certain point, there's not much that you can do.

CrowdStrike was actually a really good example of that. It's like, what happens if the colonel faults and everything goes offline? Well, it doesn't matter what my plan is to bring that thing back up if it will not come back up.

Or we run into the other problem of resource utilization, right? If I only have a limited amount of time or people to bring the business back online, what should they concentrate on? Because, yeah, I don't know.

Let's say we have another AWS outage, like I can't fix that. I, I can do everything I can on my side to make it work as well as I can, but at a certain point, you have to throw your hands up in the air and realize, this is bigger than me. And, and no amount of resources on my side, short of an infinite money glitch will allow me to fix this.

And, and that's the other thing too, because we, we've seen this time and again with disaster recovery plans, like, well, what, what's our option? Well, we can have a warm site, uh, secondary data center where we're doing continuous replication over a private link. I'm like, yeah, that sounds excellent.

And then you hand them the bill for what that's gonna cost per month, and they like all the color drains out of their face because they're like, well, how important is it? You're like, well, if you want that to be a cold standby site, that is a forced data replication. And we're not paying the license for two active active storage units like the cost to go down, but the R-T-O-R-P-O is gonna go up because we are going to have to, you know, physically transfer media over there or something like that.

And it's the back to that trade off. Like, like, I can't plan for everything. I also can't pay for everything too.

And here we're 30 minutes into the conversation talking about economics again, right? Ah, See, we almost made it through the whole episode without saying economics. Thank you guys.

But, but it's Right. But, but, but here's the thing. Our role is to work with our principal.

So the, the, the, the principle in, in, in economics is the principal agent problem, right? Uh, when you hire somebody, right, you want to make sure that they are doing the things that you wanted them to do, right? And that you have enough oversight over them that they're doing it.

I mentioned this in the context that, you know what, creating a, a, a, a full tolerant, active active is such a pain. I'm not gonna do that. You know what?

I'm just gonna grow and, and, and put, uh, couple of my, put the server under my desk here and, and, and, and call it today, right? Uh, if the person who hired me who hired to do that is expecting that active, active recovery, and I'm not, and I just created a, a little server under my desk that is a, that is a market failure. That is a, uh, and the person who hired me has to have enough oversight, has to have enough knowledge of what I'm doing to, Hey, hey, Fernando, why are you keeping a server?

What's, where's our, where's our active active stack, right? Um, it, it's a, it's not a trivial problem. I don't, I don't mean to belabor the point too much, but it's the idea that, uh, you need to have incentives play a part.

And the same person who, who's faced drains, because they don't wanna pay for the active active, what are they, what are they promising to the people above them, right? If I'm an investor in the company and the company is supposed to be bulletproof, and then, uh, that that director doesn't pay for the active active, I'm not gonna blame the engineer who proposed the active and didn't get funded. I'm gonna blame the the person who didn't approve it anyway.

Well, you would hope. You hope. That's how it works.

You know, there, there's kind of taking that same scenario, Fernando, of, you know, someone decided, I don't think I'm not into it today. I'm not gonna do, do an active, active the there, there's also the how far do you take things, right? Because this is, these are rabbit holes.

We can all go down continuously. How far, far and, and that you reach points where now this is out of our control. Um, but is there a remediation or an action that we could take if that happened?

Whether it's a SaaS service or a physical plant thing or whatever it might be. Um, you know, if enough things cascade together that that's a scenario where we would not be able to handle gracefully. Um, and I think that's, that's back to your risk analysis, um, of okay, how these are the kind, we're up good up to here.

We think we're good up to here. And we know that there would have to be several things that could happen together in order for this to escalate further. Can they?

Yeah. Well, they, they sure could, you know, could be a Murphy syndrome, but, you know, we're gonna call the question there and say, that's the level of investment we're, we're worth. We are, um, willing to make, right?

And I think that's the, the economic conversation that's engineer owns is, let me lay out the landscape for you of here's what we need to address, what the, what the cascading rings of, how far we can take it, and what's the risk to the business and the value that we would assign to how much money we spend to protect from that some point. Yep. We're gonna take risks.

That, that's the, the meteor hitting the earth is not one we're gonna protect for, Maybe, maybe not, but uh, I know we're, we're running away. And I go back, that's why I mentioned during the, during the, the chat today, this notion of the quality of your decisions, right? We, we have to, to have the good enough decisions.

We do exactly of the said, Mitch, here's what. And beyond that, that's the role of the life. Well, I think we're gonna have to wrap it here.

It was a good conversation. Hopefully we have, uh, given you some food for thought about your disaster plans and if your disaster plans didn't work out the way you wanted to, maybe this is your opportunity to have a meeting and kind of that, uh, and when you do, you should go definitely check out some of the stuff that my, uh, co-host are working on. Fernando, what's something that you've got coming up that people should be paying attention to?

So I, uh, I just finished a report on, uh, cyber Physical Systems. The, the, the, the public version. I think it's out, if you're return subscriber, you have access to the full report.

Uh, I'm starting to think about my, my next one. And, um, at the same time, we have other reports coming in. And as a matter of fact, I think that Tom, you and I have one coming up in the not too distance future, uh, another signal report.

So that'll be great fun to do together. But, and, uh, prepping up for, uh, the RSAC conference and, and, uh, I absolutely love the, the, the conversations I have there, the travel. Yeah, little, I love a little less, but, but seeing friends in, in, in San Francisco is great.

Well, speaking of RC yeah, I'm speaking of that, you reminded me. I have to get my slides turned in 'cause I have a speaking slot, uh, at R-S-A-C-I. I think one of the things you'll see, of course, I spent a lot of time, um, researching and talking about agent development or AI assisted development, how whatever term you want to use.

Um, and I've kind of coined it as this year as the developer's role evolves to engineering agents in the way that software is created. That's really what the development roles versus coding, working on code. I think a lot of the same kind of changes are happening in the observability role and world.

And one of the things we've done is elevated in my practice observability. You're gonna see a lot more reports coming out from that, which is a nice intersection that, that Orlando, Orlando, Fernando, and I get to work together on. Oh boy, there's a, you know, a winner thought, let's go to Orlando that Fernando and I get to work on together.

So, um, it's, it's changing from being an operational tool to, it's actually moving left. Like we kind of talked about security moving further up the chain, particularly the way AI agents get developed. But even more so the interesting, the interest is change changing, and that's some of the things you're gonna see, uh, coming out from, uh, our respective practices and working together.

So I'm excited about that too. We wanna thank you for listening to this episode of the Security Boulevard podcast. If you enjoyed this conversation, please subscribe on YouTube or your favorite podcast application so you don't miss any of our episodes.

We'd also love it if you'd leave us a rating and a review and a comment to help the show grow. com in the RUM group. com, text strong tv website, or the Techstrong TV app, which is available on pretty much every device out there.

Now, make sure you're following Security Boulevard on X, Twitter and LinkedIn at Security Blvd. Uh, there's a lot more content for you to consume out there. Thanks for tuning in.

We'll see you all next week.