Service Outages & Cybersecurity Failures — Lessons from Cloudflare | Security Boulevard Ep. 10

Welcome to Security Boulevard, the cybersecurity podcast from the Future and group. All of our episodes explore a variety of topics within cybersecurity and the technologies that drive it. com, on Security Boulevard, YouTube, channel Techstrong tv, and every one of your favorite podcast platforms.

Before we jump into this episode, let's meet the co-host panel today. It's, it's one of your favorites, uh, starting with Mitch. Mitch, it's good to see you again.

You were busy the last couple weeks. Oh, yes, yes. You know, flying through the busy skies with, uh, not as many traffic controllers as we would like, but we made it home safely.

Absolutely. And then, of course, joining me again is Fernando. Fernando, I know you've been busy for the last couple of weeks.

Oh, God, yes. Uh, uh, it's, it's high travel season for, for conference and events, and I love, love, love, love the interactions. I don't love, love, love the logistics usually, but, uh, yeah, no, it's, it's nice to be back and, and, and chatting with you guys.

Absolutely. And we're, we're very glad to have everyone joining us this week. It is it, you're, uh, listening to this, depending on what time we've we're recording this week of Thanksgiving in the United States, uh, which means it should be a fairly calm week for everybody unless something on the internet goes down.

Oh, hey, let's talk about that, because that actually happened last week. Uh, we, we joke around about the fact that it seems like the internet is, uh, totally dependent on like three or four services. One of them was CloudFlare, and we noticed that, um, we, it, one thing that happened, we, we got it, uh, I think it was Tuesday of last week, so that would've been what, the 18th, uh, we started seeing these massive, uh, warnings that things were, were not right.

Uh, lots of websites were going offline. There were lots of, uh, people that were panicking because they couldn't get to chat GPT anymore among all the other things that were going on. And, and I remember sitting there thinking to myself, I'm like, well, one, they're gonna get it fixed because that's what CloudFlare does.

And two, we're gonna get an awesome postmortem when we actually do get that. And, and one thing I will say that I was very happy to see is that everyone from the CEO down posted on LinkedIn, and they specifically said the words, we are sorry for breaking the internet Like that. That to me, was a huge thing of saying, we, we realize that we should do better.

But I wanted to, uh, jump in. Mitch suggested this episode today. Let's talk about the security implications of what happens when a service as big as CloudFlare kind of gets knocked offline, because a lot of things that we thought shouldn't have broken suddenly weren't available.

Mitch, I wanna open with you, what was your takeaway from this from a security perspective? Because I, I have to wonder how many people security tools suddenly were inoperable and failed open when CloudFlare was not available? It is a little tough to, uh, make sure your, your offering is secure if you can't get to it, right?

Because we, our security tools often go through the same cloud provider, uh, like a CloudFlare or an Akamai or whoever it might be, um, to, for these services. So the, they're also frequently blind, or maybe there's another path to get to it that you've gotta make sure you've got constructed, which brings up a, you know, what's the plan B when this happens? 'cause it will happen again, right?

Um, there were a couple things about this. One is, you know, I always reflect back onto the CrowdStrike, right? Because that was very much a, we're gonna be transparent, here's what happened here.

You know, we'll fall on our sword, but we'll also tell you what we're doing to fix it. And there's a claim of transparency here, uh, at least initially. Uh, but it really wasn't that genuine in my, my estimation because it was, it was, the outage was blamed on a, on a configuration file for their bot management system, which is, you know, vital to to, to using the service.

We are a customer of CloudFlare. We use it in our infrastructure as well as others, um, which caused, uh, configuration files to grow too big and cause something, you know, to crash and not work any longer. And it's those situations where something isn't working, something might crash, et cetera.

It may not be a security incident that causes it, but that also opens up potentially service provider, uh, to attack as well when that happens. So you can imagine in a situation like this, it wasn't caused by a cyber attack, but you, you know, the cyber criminals rushed in to say, all right, how do we exploit this so it can become a security incident? I don't believe it did, um, you know, necessarily, but they, they suspected that some of the symptoms were caused by DDoS attacks that followed on to the core issue.

Right? Exactly what I'm talking about. So just because it's an outage not caused by cyber, doesn't mean it is an cyber related incident.

So everything's cyber related, right? Especially when you're a security professional. But, but it's, right.

I mean, we can debate for those of us have been around for long, like the, there's that, there's that debate whether the CIA triad is accurate and whe whether we needed the, the Don Parker, right. That had others as well. But availability is a key component of security.

It's a key objective for security. So yes, absolutely. If I can't Get the firetrucks to roll because the network's down, that's a security issue, right?

I mean, it it is, Yeah. The, the, the, the, the back holes and the squirrels that take out networks and, and, and power grids and whatnot. Sure.

It's not cybersecurity as we, as we normally do it, but it is availability, it is related, like your organization is relying on, on the availability, the integrity, and the confidentiality of services. And many of us have been around environments that will actually prioritize things like availability over things like confidentiality, right? So the healthcare industry, for example, is, is known for, uh, uh, doctors and, and, and nurses and, and frontline staff.

They, they will have a very, um, uh, how should I say it? They'll, they'll have a very clear preference for, I need to get to this, or people die, right? So I, uh, cybersecurity teams should keep that in mind as we're, as we are designing things for those, for those, uh, user communities.

And, and you bring up a good point there, Fernando, we've become so dependent on a lot of these services as we've migrated them into the cloud that we, we don't know what happens when things go down. I mean, it's not like we had a, an incident that happened a couple weeks before that, right? When Amazon deployed a bad DNS update.

Oh, wait, we did. And, and that should be kind of the canary in the coal mine, that no service is completely reliable. Yes, CloudFlare and Amazon and, and Microsoft and a bunch of the other ones are probably more reliable than most.

But even as we saw, Mitch, you brought up another good point. Uh, Azure got hit by a giant DDoS attack. And even if services like CloudFlare and Azure and AWS can eat these things, uh, I remember a, uh, a great presentation that we got at, at Tech Field day a few years ago from thousand eyes before they got acquired by Cisco.

And they were showing a Bank of America DDoS attack, and they said there were six DDoS scrubbers that were supposed to eat all this traffic. Five of them worked, one of them didn't. That was the one where everybody was able to get in and DDoS the Bank of America.

We, we deployed this infrastructure in the hopes that we can prevent these attacks from happening. And, and, uh, to quote the IRA, again, all we have to do is get lucky once and, and it exposes these kinds of things. Yeah.

So, so, so this is, this is one of the areas where I, uh, um, I tend to not agree with that. We only have to be lucky once thing. I know, I know what, I know what was said.

And because we do hear it in cybersecurity all the time, the problem we have is that, uh, we have infrastructure that is very complex, that has many moving parts, and we don't seem to have as good of a grasp of the overall picture as perhaps we should. Right? And there's a, there's a quote I like, it's been attributed to, uh, I I it's been around.

I know that Frank Borman, who was one of the commanders on Apollo eight used it many years ago. And, and, and I'm summarizing, but he said something along the lines that the, the superior pilot utilizes their superior judgment to not put themselves in situations that would require they are superior skill, right? So what can organizations do apply, they are superior judgment to how things work so that they don't need to be in situations where they need they or superior skills.

And where I'm going with this is that I, I think that this goes back to threat modeling, right? And I think that this goes back to how do we get teams to work together, and how do we get security executives to make it easier for security engineers to have the conversations with application developers, application architects, et cetera, et cetera, et cetera. So that these kinds of incidents can be factored into whether you're using stride or pasta or octave or whatever threat modeling methodology you want to use, so that, yeah, we can plan for these things and we can avoid them.

So, um, anyway, fer, I'm dabbling as usual, but it's, uh, Fernando, you stole my Frank Borman quote, but thank you. No, I wasn't, I wasn't gonna use that. I'm just kidding.

But it's a, you're right, it's a great, a great quote. It's a phenomenal quote. Know every One of these incidents points at, you know, one of one of different kind of factors.

It can be an operational, you know, error, things that happen, whether it's a CloudFlare or like the situation with, uh, with, uh, CrowdStrike. Um, oftentimes it's assumptions too that we make about things that will work and will stand up, but they don't stand up under all conditions or can be a security incident as well. I, I think we're, we're at a moment of it's time to rethink this.

Uh, just like we rethought, do we, do we have bastion hosts? Do we, do we treat things as moats and firewalls and, and protect things from the outside and just hope, you know, they won't get in. No, we not today, we talk about zero trust and we say, yeah, it's gonna happen.

Things get in, things will get, get attacked, things will be compromised. But how do we minimize, minimize the blast radius, stop it sooner? Those kind of things.

And I think in, in the, when you add complexity to a system, to your point about complexity, Fernando, um, we don't often address. Um, yeah. But what happens when that falls because it, it will fall down, whether it's a database configuration file that generates something for bot management, um, or it's something else, right?

Things fail, uh, just have to be hardware or just bugs in software processes are, edge conditions can be met where we didn't expect that, or we didn't have that issue when traffic was, you know, two thirds of what it is today. But now at that volume, it constantly is. So, you know, do you build in restart mechanisms?

Do you build in fail back mechanisms? Do you do things like that? So, and I'm not critiquing the cloud CloudFlare response 'cause I don't know specifically all the things they did or didn't do.

This is not about that. Um, but, but you do have to think about, well, what can we do from a resiliency standpoint? Yeah, we can shift track traffic, we can reroute things.

Those are great, those are very comfortable for us. But what about services that fail about, um, going back to the prior, uh, pri prior version of a bot configuration, if that is found to be a root cause. And then the secondary aspect is these are, these are like supply chains, right?

There's a ripple effect when, one, there's a disruption at some point in the supply chain, in this case, in a, in a very large complex network, making that change where there's a DNS change, like for AWS or fixing this, this bot file issue, um, take, it takes a while for it to work its way through the system. Meanwhile, you're battling other files that that fires that cropped up like a DDoS attack that's taking advantage. So it's kind of fighting a front on fronts, on multiple fronts on, on a war.

Um, it, it, it's not easy to do, but you've gotta think about it from a resilience, stand resilience standpoint. And what can the system do to also help keep itself stand, stood up and working. I, it's, it's funny you brought up the word war because the, the thing that as we were chatting about the, the topic for today, one of the things that came up to me first and foremost was that, that, uh, that concept that was originally, I, I think it's been originally attributed to vitz, uh, which is the fog of war, right?

What happens at the moment that stuff happens, right? And some people refer the, the, the left of, left of boom versus right of boom, right? How can organizations be ready for that moment, right?

I think that in, in emergency medicine, I've heard the term, uh, golden hour, right? That, how, how that initial, what you do at that beginning, how that has an impact on how things turn out. Again, it may not be an hour, it may be 15 minutes, it may be two hours, doesn't matter.

But that, that moment of when stuff happens, how do you go from there? Like what do you plan for that? And it's a phenomenal topic.

Like we can spend days talking about it. We could, but I think one of the problems that we run into is how do you run failure testing on necessary services? Like, like, I know how you do it for emergency medicine or pilots or things like that, because I was talking to, uh, the, one of the people who used to be in my Boy Scout troupe.

And the way that they do that for pilots is they take you up in an airplane and they start shutting stuff off, and they wanna see how you react to that. Oh, hey, the fuel line just got cut to your right engine. What do you do?

Uh, oh, hey, the rudder controls are now locked. What do you do? Like, they're looking for, basically, how do you go through the checklist, right?

And how do you do that on a service that's basically providing things to the whole internet? Well, we know how Netflix did it, right? They created the Chaos Gremlin, the, the, the Chaos Monkey would go out and it would randomly disable stuff to see if the, the engineers at Netflix built it properly so that it would actually come back online.

That's great. If you're a video streaming service that has, you know, a few million customers, what if billions of packets, trillions of packets go through your service a day and suddenly, you know, like you accidentally disable, uh, your bot configuration file size checker. And then, like, Mitch, to your point, a lot of what happened on the internet was not the initial outage from CloudFlare, because I think they had that fairly quickly resolved within it less than an hour.

It was the ripple effect that we see through the whole system of this is offline. Well, it keeps retrying because that service should never be down, and so then it gets knocked offline, which causes other things to go offline. It's the classic problem of traffic, right?

A slowdown in one area of a, of a city creates gridlock miles away because the, the changes have to flow through the system in order to exit. And, and I don't know that you can test for that. It's, it's the exception rule problem.

What's more likely my hard drive being, uh, you know, the, the, the platter going out in it or someone hitting it with a meteor. Well, I know which one's more likely, and I don't really have a failure scenario for the second one other than should play the lottery today. But, uh, there's the, the, there's the quotes by Twain that I like, right?

It ain't what you don't know that's gonna get you, it's what, you know, that just is ain't so like, and, and I probably misquoted it, right? But it's the kind of thing. So I, I think that all of these downstream, that there's two sides here.

You are absolutely right about Chaos Monkey and, and, and what Netflix did with, uh, with their resilience. Uh, shout out here to, uh, Kelly Shortridge and Aaron Reinhardt, they, they wrote the book about security, chaos, engineering, right? Which is really interesting.

But, um, the thing here is that to what extent the failures downstream were caused by, by, by architectures that assumed CloudFlare is gonna be up, that, that, that assumed that this thing is going to work. And those are testable things, right? How do you change, how do you, how do you, I'll go back to threat modeling, right?

Unless we have a, a comprehensive architectural view of a system, right? And we, and we come together as security, as architecture, as development, uh, slash engineering, right? As lines of business, whatever.

And we agree on this is what the system is supposed to be doing, and here are the failure conditions and these are the conditions that we're gonna choose to accept to that these are the conditions that we accept as failures. These are the ones that we cannot have as failures, right? So, okay, perhaps the alternative, and I'm not saying that this was the case here, but, um, perhaps the alternative to an outage with a CDN like CloudFlare is you keep two and you keep 90% of your traffic on, on your primary and 10% on a secondary, right?

Akamai, fastly, like so many others, right? Lemme take Another, lemme take another view of it. Um, please, because this is something I had to challenge my own thinking about, is, um, a known, known is no longer possible in our world, meaning we don't really know what the network looks like because it's constantly changing.

I don't mean the traffic on it, I mean the configuration of it. We have people writing code that are running as edge processes, right? In our network.

I don't control that. That's part of the service that we offer. We may have it sandboxed off, we may not.

That's just a simple example. We're making constant changes to the network, right? It may not all be known by any one system or one person that heck has that entire scope.

Um, if you want to project forward, and this is what I bring up constantly, is you add AI into the picture someday. That's writing its own code as it works, right? It's okay, now you've really got a, a self changing system.

Um, and maybe to some degree there is, you know, variations, small variations of that today. So I think there's both perspectives, Fernando is this is what we know and this is how, this is what we're gonna protect from or against or respond to, and we'll do our whiteboarding, our, our red teaming against all of that. And here's the, we don't, there's the universe of things we don't know, but how are we gonna deal with something when it happens?

We don't know what that thing will be that will cause it, but a configuration error, um, and an overage on traffic on a certain node, um, you know, a piece of hardware that decides to, uh, start taking its commands from some foreign nation instead of our, our management system, whatever it might be, right? We, we have to have some kinds of ways of thinking about resilience for the unknown unknowns. And every one of those will become known right as we learn it.

Not to, to get, to get too, too far back into the known and unknowns thing. But I think you have to also think about it as, now let's, now that we've assumed that we know what the network looks like and what it's all its state is what happens when we don't, because there will be times when we don't. Maybe that is today or not.

So, So I can't believe I get, I get to be the first person to bring this up because all of the answers to your questions are money. It, I get to say economics before Fernando did. But, but that's the problem, right?

Is that no matter what this issue is, I can solve it if I can just throw enough money at it, kind of to the point, what if I'm running all my traffic through CloudFlare? Well, 50% of my traffic goes through CloudFlare and 50% goes through Akamai, but Akamai wants a hundred percent of my traffic because they want to charge me for it. And there's always this price battle, right?

Of how, how do I balance this appropriately? I mean, let's be honest, that's the whole reason why multi-cloud exists, is because people wanna exploit cloud arbitrage, right? It's cheaper in, in Azure for the next 45 minutes.

So I wanna run all my big workloads over there and get, you know, save 38 cents per VM or whatever. The problem is is that people get so obsessed with this idea that I can save money by loading everything over here, that they forget that there's a cost to that that's not dollar related now, but will be dollar related later. Like, uh, you know, people were attaching billions of dollars to the AWS outage.

People were attaching billions of dollars to the CloudFlare outage. And all of the AI providers that we know of, open ai, uh, anthropic, all of them ran on CloudFlare. And so their models were offline for users to get to for that foreseeable whatever.

So now they're having to deal with the fallout of that angry customers that couldn't write term papers or, or whatever it is. But more importantly, how do they fix that in the future? Do they, do they demand more of their providers?

Do they write more stringent SLAs to say, I need this to operate at a better thing? Worse yet, Mitch, you, you kind of alluded to this at the beginning, what happens if there's a, uh, a breach during that time when my security systems are offline? Is it my fault because I did everything that I could?

Or is it your fault and can I get money out of you for it's your fault, either you or my insurance company? You know, so, so let me, um, sorry, Fernando, and then I'll back off here. So even, even that Tom, um, assuming that I can solve it with money, actually you can't solve it with money.

There's no infinite amount of money that would solve it. Part of the reason is because what I think it, what, what I think the way I think things are today is not gonna stay the same. So I'm gonna push half of my traffick or a third of it here, and a third of it there, and third of it over there.

Tomorrow some business deal gets struck that changes that, right? That I don't have any control over that, you know, Akamai buys some company we didn't expect 'cause, but that's who we were pushing traffic to or buying a service from as a backup to, so that that system doesn't stay static and change. Um, and now we have to adapt to it.

We didn't, we didn't know what to expect that, but we can't count on that being the way it is at the point in time we hit the save button on the plan. So this is where I, I I go back to, we are evolving as an industry, right? And I think that, Tom, thank you for bringing the, the economics first, right?

That, that's, that's lovely. Uh, but I think that this is, we, one of the major trends we're following at Futurum is this broader evolution of the market, much more strategic and so on. And I point you and, and, and we see people, for example, uh, our cybersecurity decision maker has people indicate a clear preference for platforms over point products, for example, right?

Doesn't mean that it's, it's complete, it's never gonna be one, et cetera. But, but people do have the preference. But this is where I look to other industries for inspiration.

If you go look at major airlines, right? Major airlines don't run their entire fleet on a single provider, right? You have Boeing and Airbus.

Now those two major aircraft platform has emerged, but airlines choose to run both, right? So airlines are taking the cost of, hey, it would be much easier to have all my mechanics, all my maintenance, everybody, all my pilots just certified on one on one type of airframe. But no, we're, we're paying them to have, like, we'll have the cost of doing both, right?

I think technology is the same, right? We are going down that path. I'm gonna put a little, I'm gonna put a little pin in that.

Fernando, please, ma, most major airlines are running both because of supply chain issues. I fly Southwest, they fly one plane, the Boeing 7 37, now it's the seven, the eight, the eight max, whatever. And they have so far used that to their advantage where it has been low cost because they only have one set of mechanics.

And if something happens, they can just swap a plane out. But when they go down, they go down hard because like when the Im Max Eights were grounded, that really snarled up everything, right? And, and I think that you're rolling the dice there.

You are hoping that the amount of money that you're saving now translates into enough of a war chest that if something does go wrong down the road, you have money to fall back on. Except we know that's not what's happening, because the savings that you're making are actually either getting plowed back into stock buybacks or, or, or other things where that money is being sucked up. And I think that what we have to do is get back to a scenario like we've seen in cybersecurity for years, where the rules say that you have to have circuit diversity, that you have to have service diversity.

That, that it is built into the system that you can't monkey with things like you said, Mitch, that oh, better deal came along. Well, I'm gonna swap to it for the next 30 days. You know, to me, that reminds me of the people who will sign up for a service like, uh, home internet, and every 30 days they'll call and cancel it to get a better deal, you know, through the, the retention department.

Well, eventually that's gonna run out, and then you're stuck holding the bag. So is the, is the answer that we just have to mandate from a security perspective that you must include this in your planning and don't just hope for a rainy day? Well, I'm, I'm gonna, I'm way woefully behind on my quotes.

I made a note. I've gotta make, I I've gotta make, I love really bone up on my quotes, so I'm gonna share one teeing off of what you said about looking at other industry. Aal.

Alan Kay, who is an Apple fellow, he actually worked on zero at Xerox Park and came up with the idea of the Dina book, which is the precursor to the laptop. He has a great saying, I don't know who discovered water, but it wasn't a fish. So you've gotta look outside of your system, right?

To bring in new thinking, fresh thinking, um, whether it's, and, and I had, I had one of those moments too, Fernando, uh, earlier in my career, I was doing due diligence on an airline reservation system. I was a DBA, right? That was my job at the time.

I walked into the data center, red lines flying across the main console. Every one of 'em said database pointer error. And nobody was doing anything.

Nobody was like, there's no panic, there's no what, you know, they're all just kind of sitting there doing it. I'm just like, what the f is going on, folks? This is like, is somebody fixing this?

And they're like, no, you don't understand. And this is such a high capacity system. We accept a certain amount of errors in the system to be able to handle the volume.

So that's okay if there's database errors, you know, when the, when the person at the desk hits the enter and says, oh, I, I need to, the system's being squirrelly today, they're doing the transaction again because the first one failed due to a database there, but we make it up in volume. That was a mind blowing, like, ah, I thought everything had to balance at night. But I guess not in the banking industry, but for airlines it's different.

And this is super interesting because it ties to, I think there's a, a psychological phenomenon called the normalization of deviance, right? Which is the idea that you get used to these kind of errors and then at some point, and then at some point it is an actual error. Oh, look, 49 times, we've, we've had this echo failure, what, not al, but like, uh, whatever the 50th time it's there, right?

And I think that this is, uh, goes back to that preparation that teams should be doing, right? How do you prepare for, uh, how, how do you keep your teams sharp to be able to address those kinds of things, right? Anyway, I think it's a, it's an important point.

In layman's term, I call it, it's all good till it's not. Yeah. The, uh, the common term I hear a lot is alert fatigue, right?

Oh, that, that thing's red and it's red, it's always been red. Well, what happens when it's not red? What happens when something goes like it goes off or whatever?

And, and a way that a lot of security companies are actually solving this problem is, we had to say it, they're, they're using ai. Uh, they're, they're, they're providing context why? Like, you know, Mitch, to your point, yes, a certain number of transaction failures are acceptable, but what happens when you go outside of that?

What, when is the threshold for this is now significant amount of transaction failure? Which I think is, is ultimately what needs to happen here. We need to be able to provide context around these things for people to really understand what's going on.

If we don't, then yeah, we're just gonna get numb to it, right? It's like, oh yeah, things are just acting squirrelly today. Well, what's the difference between squirrely DNS resolution issues and massive outage?

Uh, it's about 20 minutes of Amazon engineers going, I don't know what's going on. And, and that's where we're gonna get to as more and more of our systems become dependent upon these things. Like, you know, I, I've completely gotten rid of all DNS resolution on site, and now I use, you know, pick your favorite resolver public resolver platform.

You know, I don't store things on my local storage anymore. I store them all in the cloud. Well, that's great until you're, until S3 has a hiccup.

Like, like, we, we've got to understand that if we're willing to trade these things for lower costs, we have to be willing to accept the fact that we no longer control them. And, and I don't know how to write that into security plan. And, But, but you know what?

That's fine. I think that there are things that we, as organizations should be, we should have enough of a, of, of a view of what can go wrong and then we pick our poison. We are okay with this.

Uh, uh, Southwest is perfectly fine in their value, in the value that they provide, given the business strategy that they have chosen, right? Uh, air Canada or United, similarly, they, they, they need the extra fleets, right? And it's, uh, uh, uh, you brought up, uh, uh, regulation, right?

I think this is the area where we need this evolution of, uh, secure by default, right? We need this evolution of, uh, secure by demand, right? How are we going to get, how are we improving the, the, the, the current status of things so that yes, these things are more resilient, they are going to cost more.

Are you willing to do that or not? Right? It's, uh, it's economics.

It's, it's always economics, sorry, right? And, um, but it, but this is the, this is the, the scenario where we are, this is the evolution that we are doing. So if I, if I have to leave people with one piece of advice is work on your threat modeling for something.

Have that conversation with your teams to know, look what happens if this goes down. Oh, listen, we don't care about that. That's fine.

You know what? You made a decision. You live with the consequences.

Oh, no, no, no. That's super important. Okay, let's, this is, this is what it's gonna cost you, you okay with that?

That's the conversation that we should be having. I think, I think part of that threat modeling, Fernando, is extending it to the applying This will accept a certain amount, but when it ha but when it does happen, wherever it happens, um, our security response isn't necessarily to the config file issue. It's a, oh, hey, I, a config file issue over here in Australia, alright?

Uh, level two on our, you know, resilience around security, because we know there's gonna be attacks kicked off from that. And we, that potentially could be a threat, but we also could be DDoS, we could be da da, da da. So your, your response plan on security isn't by a initial security threat.

It's as a consequence of another problem. We now have security issues, right? Escalating, Uh, absolutely.

Yes. Yes. And, and, and to, to, to end with, uh, I, I think it was, it was, uh, it was Jefferson, right?

The, the, the price of freedom is eternal vigilance or something like that. Was it Jefferson? I don't remember.

Right? Or, Or Franklin. Uh, Benjamin Franklin, you know, we have a demon.

We have a demon. We're republic if we can keep it. So there you go.

I, I'm keeping up with you. I'm trying, I'm doing my best, Fernando, make Everyone out there in our listening audience has homework. I need you to go to Wiki quote.

I need you to confirm all of these. And more importantly, I need you to find an appropriate quote and leave it in the comments for this video, because I wanna hear what you Guys have to say. Um, that's just about do it for this episode of the Security Boulevard podcast.

I thank everybody for tuning in this week. com. Uh, there's some great reporting that's coming out.

I know there's gonna be some great articles coming out because we've got one more big show of the year AWS reinvent. Um, then we're kind of getting into that quiet period in December where we're gearing up for more stuff going on in January. com to find out more information about that.

If you enjoyed this conversation, do us a favor, subscribe on YouTube or in your favorite podcast application of choice. That way you don't miss any of our episodes. We'd love it if you'd leave a comment, uh, maybe a rating on a podcast app and a review that really helps us grow the show to new audiences.

com in the future and group. com. You can also find us on the Textron tv website or in the techron TV app.

It is the best way to put on the tv. Instead of listening to one of those boring crackling, you'll log fires over the holidays. You can listen to Fernando talk economics and Mitch disagree with, uh, some of the things that he says.

Uh, make sure you're following us on Security Boulevard, uh, on X and Twitter or on LinkedIn. Look for Security Boulevard s at security BLVD 'cause we don't believe in vows around here. And, uh, we wanna thank you very much for tuning in and we'll see you after the big Turkey day.