Software Supply Chain Security, AI Networking & Observability Strategy | Security Boulevard Ep. 19

Welcome to Security Boulevard, the cybersecurity podcast from The Future Room Group. Our episodes explore a variety of topics within cybersecurity and the technologies behind it. com, the Security Boulevard, YouTube channel, text on tv, and every one of your favorite podcast platforms.

Yes, even that one. I'd like to take a moment to introduce our co-hosts and guests for this week before we jump in, starting with, uh, one of my stalwarts, Mr. Mish, Ashley.

Mitch, it's good to see you again. Good to see you on this both warm and cold day, depending on wherever you're in the world. Yikes.

And, uh, joining us for the first time is another friend of mine, Mr. Steve Plucka. Steve, tell everybody who you are A pleasure to be here.

I'm Steve Plucka. I've been, uh, in computers and networking since the mid eighties, uh, retired most recently from the service provider side of things, running security and, uh, and the network architecture in that space. And definitely looking forward to talking about this, And we're looking forward to having you join us.

Of course. My name is Tom Hollingsworth. I am the, uh, person for all things security at Tech Field Day, which is a part of the Futureum Group.

And let's jump into today's episode because I wanna talk about supply chain hacks. No, I'm not referring to that Bloomberg article, and you know which one I'm talking about. I'm talking about a very interesting supply chain hack that we found out about last week.

It involved everyone's favorite, IDE Notepad plus plus. If you're someone who has been doing programming for a while, and I'm talking about real programming, not vibe coding, uh, where you actually have to type out the, the syntax, you probably know what Notepad plus plus is. It has become universally lauded as the thing that Notepad should be.

And a lot of people have downloaded it over the years and it's constantly being improved. But one of the things we found out was that it was improved in a specific way over the last couple of months. Someone was able to inject code into the update system that would allow nefarious actors to redirect certain people downloading Notepad plus plus to a different download location that would then allow them to serve up a, uh, version that had been compromised.

And there's a lot of talk about this on the internet. In fact, I thought it was rather hilarious that I found out about the hack only after I had watched a video that had been posted on YouTube talking about the history of Notepad plus plus. I'm like, wow, this is kind of fortunate.

And then like two days later, I'm like, oh, that's why they published the video and we're so big at the end about talking about how they were gonna be authenticating downloads from secure mirrors and things like that. So I wanna kind of open up the, the room here to, uh, my guests for this week. Have you used Notepad plus plus before?

Were you aware that it, you know, it was a smaller shop and, and what are your thoughts kind of around this whole supply chain hack that people were able to pull off with it, Jump in with a, it's, it's a well established tool as you were kind of alluding to there. Tom been around for a long time and used by the technical community. I don't happen to use it much anymore using other IDs, but you know, it it, it serves the purpose in the, in the ecosystem, if you will.

In one way, this is not a, not a new thing, right? We've seen supply chain hacks and this is coming through, you know, redirecting you to a different update server, which happens to have updates you probably don't want to get. And unbeknownst to you, this ran from like June through December or something like that.

Some, some for some while before it was detected. So my, my curiosity about it is, hmm, why did it take so long to get updated? Hacks are gonna happen.

Um, package managers are a huge supply chain, uh, attack source, uh, target, if you will, um, just like update servers are, it's kind of reminiscent, if you will, of, you know, that the one you were talking about in Bloomberg, Bloomberg that, uh, happened with the distribution of code updates. It, it's part of what we have to defend against. So it's not just about secure code, it's about the infrastructure that distributes secure code.

And I wanna make a point real quick that you brought up the fact that this is not something that's new. If you used a Windows laptop from the year 2000 on in an enterprise, you have dealt with a redirected update chain. If you've ever used Windows Update services, that is literally what it does is it pulls down the entire Windows update catalog and it redirects your local domain connected machine to that server so that you're not constantly going out to the internet, pull down service packs and things like that.

So this is known technology. We've known about this for years. I think it's interesting that, you know, this kind of came to the front because we've seen other attacks like this.

I want Steve to kind of get his thoughts in here before we talk about, you know, another famous supply chain hack that happened a few years ago. Yeah, I, I definitely aware that, uh, notepad plus plus is a big part of, especially the enterprise side of things. But most of the companies I've been at, um, you know, since in, in actually the vast majority of my career, we've been running on Max.

So we're not using Notepad plus plus, which is a Windows based system. But in, um, enterprises that I've, uh, had contact with, it is very common, uh, to, for the developers to be using this because of the feature set that they, um, by developers for developers and really, um, you know, stellar in, in that regard. So, um, you know, I I think the, that given the target that the, they appear to be going for and, and as you mentioned, using the existing technology that's designed to do what it's designed to do, it was, um, you know, a very, very clever insertion into the technology and, and using everything that would be expected to be seen.

And it doesn't surprise me that it took six months to be noticed. And, and just so everybody knows, the attribution that we've seen right now is that it was a nation state backed group that did this. And I think that the fact that they were very quiet about it is the reason why escape detection for so long, they weren't redirecting everybody.

They were redirecting specific targets. And that is why I think people started to, to kind of get into the fact this was nation state backed. If this had been, you know, a, a we'll just pick a random group out of a hat, like a lapsis group, not that they're known for this kind of thing, they're more insider threat type people.

Um, they would've just blanketed it, right? Like everybody would've had the, the compromised version and someone would've done a hash check on the files and went, wait a minute, this isn't right. And they would've gotten, found out probably after a couple of weeks.

But the fact that this was extremely targeted, that it, it escaped eva or it escaped detection as long as it did until someone finally said, wait a minute, something doesn't work here. Um, this feels an awful lot like the comp, the SolarWinds compromise from a few years ago where they injected compromised DLLs into the, the build process so that they could essentially have presence where they wanted it, but they didn't like make a big deal about it, right? Because we know from the, the wonderful post-mortems that have been done for years that they were targeting US government agencies and large enterprises to exfiltrate data.

They were not saying, oh, well I'm gonna like crypto lock your monitoring infrastructure and like demand a a bitcoin from you to unlock it. No, the, this is the not the smash and grab type stuff. Like, like we, because we talk about this all the time, right?

Like we, we tell all of our, our people in cybersecurity, lock your doors, lock your windows. And they're like, well, what good is a door lock? And I'm like, against casual thieves.

A door lock is amazing, but if you are targeted, no door lock can save you. You just have to hope you never get targeted. And that's what we're seeing here, is that the group behind the, the notepad plus plus Compromise, they had very specific people in mind when they did this.

It's, um, you know, they're, they're both supply chain hacks and they're, they're, uh, different parts of the supply chain, if you will. You mentioned SolarWinds and being part of the build process, it was pretty sophisticated process of being able, able to hide so that while you were doing builds it, if it seemed to be drawing in attention, it would ratchet down what it was doing. In this case, they got access to, I think it was a PHP process that, uh, did a call out to, I think is wind gu that it was doing updates from.

So it wasn't actually the, the notepad plus plus code, but another component that it relies upon in getting access through that way. So I, I think what it it informs is, is, yeah, it can be your code, it can be your build environment, it can be the supply chain that you're, uh, of what gets created through other sources. It can be the sources that distribute that supply chain into your processes.

And here they got access to a, a hosting environment to, to replace that PHP process to point it to some different servers. And of course, it all came down to, I believe it was, um, seeing IP addresses suddenly going out to China in large quantities, and which draw the attention. Of course, there's ways to hide that.

So why did that, you know, you would think that the, the, uh, bad guys would've hidden that, um, you know, maybe the busy hiding other things, who knows what the reason was. But it came down to some, just some basic incident management sleuthing to figure out what happened. I think the, the, the key difference between these two events, the SolarWinds and the current Notepad plus plus is the, the, the vehicle of entry, you know, they compromise the hosting provider and we're doing redirects there at the server level of the hosting provider as opposed to compromising the actual company itself and the, and the stream of, of data in there.

So it allowed them to be more stealthy, um, as a result of that. Now, some of those did end up going back to, to China, but the vast majority didn't. And some of the incident reports that I'm reading shows that the targeting is really worldwide, um, um, you know, enterprises in South America and in Southeast Asia and, and of course the United States as well.

So it was a very, very selective and, and targeted effort. Um, the other thing I haven't seen verified is that the, the, the notepad plus plus themselves may have been, um, made this slightly easier by, um, by the way they handled certificate, um, authentication in the process. And, and by inserting themselves as a, as a unique certificate authority, um, apparently they, they, they made the process of inserting, uh, these harmful files easier.

I think they were trying to make it easy on their users, right? Because that's one of the things that we've seen over the years, especially as we try to create these secure infrastructures. Like when, when we put all these things in place, like you have to have matching certificates and things like that.

Like we, we actually just saw that with the Apple iOS as we're recording this, apple had to release a whole bunch of new certificates for older versions of iOS that are technically not supported anymore, because if they didn't, like a lot of services were gonna break because the certificates were expiring. We've also seen it from companies like Cisco where they let a certificate expire on a sassy box and it, it knocked the whole thing offline for like a day. Um, it's, it's always the balance, right?

In security, we have to have a system that allows people to do their job, but securely. 'cause I was thinking about this, like, how would you defeat this without creating this ones system of double checks and certificates? And my first thought was, pop up a hash value.

Like all you gotta do is have the hash value fetched from Notepad plus plus servers, and then pop the hash value of the package that you downloaded. And if those two things don't match and just put it up on the screen and go, here's the hash value, here's the downloaded hash value. If these two things don't match, stop what you're doing right now.

It, it worked in this case though, because it could have intercepted that communication. You, you're right. But, but here's the thing, and this, this goes back to the door lock analogy.

If there's an extra check that you're not expecting, that means that the casual idiots can't find it, the really dedicated ones will catch it. And you know, it's like making sure that you're modifying every little thing so that it passes all of the checks. Sometimes that's less valuable to people because it's more work, but it, but then you get into these, you know, the chicken and the egg problem of I need to secure this, but it's gonna be too difficult.

Well what, then how do I do it? You're always gonna be chasing this, right? Because in a lot of places, like, you know, Microsoft solution would've been, we'll just use Notepad because it's integrated into the OS and we control it.

Um, yeah. And that's, corporate America was response was probably like, don't use Notepad plus plus anymore, which all of us would've turned around and went uhhuh. Yeah, sure.

Uh, anyway, going back to using Notepad plus plus, so like how can we create infrastructures that balance, ease of use with, uh, enterprise level security? I think, I think what this points to is something that I've disagreed from day one, which is this shared responsibility model, shared security model that, um, it isn't one person that's responsible, it's all of us. At the end of the day, you're responsible.

If it's your app, if it's your service and all the providers you use to deliver it, it's your butt on the line. And when something happens, right? So you just said, why don't we just replace Notepad Plus Plus?

It wasn't their fault that this happened, it was a hosting provider, right? Did they pick the wrong one and they were derelict at it? No, I doubt it.

It's probably just a flaw. Maybe some credentials got stolen, who knows how the hackers got access to this particular server. And as you mentioned, Steve, they were intercepting this in the hosting environment outside of, you know, really what the, uh, what the app builder had control of.

So, you know, the question is, where were the faults in the hosting provider Now they've since I think, changed to a different one, which is a natural thing to, to do. Nothing to say that couldn't happen at somewhere else. So at the end of the day, I think we have to be really clear about, yeah, there may be a shared responsibility model, but the end of the way the but on the line is yours when you're delivering the service, no matter who your partners and service providers are.

And I think the, in this case too, you know, what I really didn't like about the way this is coming down, um, is that everybody wants to blame somebody else. And the truth of the matter is, everybody made a mistake here. 'cause this wouldn't have worked without all of those mistakes coming together and being exploited as a team.

So I thought it was kind of, um, almost childish to say, oh, well we fired that Hostee provider. Ha ha. It's like, no, you know, you had your own mistakes too, with the way you're handling the verifications and the certificate authority.

I mean, it was not smart to put yourself in as a root certificate authority. I mean, that was your mistake. You own, you own part of this too.

And to try to post, to say, oh, well we fired them, this happen again. It's like, well, you were partner in there. It was your thing too, was an only you.

And and that's the, that's the thing I liked about the shared security model is we have to be a team with our vendors. And especially in software, because this stuff, nobody writes a hundred percent of the code for 30 years. You know, you're getting bits and pieces everywhere.

You are a team, whether you like it or not. If you don't like the guy playing third base tough, he's there. You don't like the coach.

Tough. He's there. Gotta work with these people.

But I think that, go ahead, Mitch. As A captain, every team has a coach. It's not a, it's not a commune of software people that, uh, get together and assemble code and it kind of goes out the door.

And ultimately, if you're running a business or you're producing an open source project or whatever, someone is in the lead, right? And that's who's gonna be held accountable. What least visibly, you know, what, what the consequences are a whole nother thing.

And you're right, it wasn't, there wasn't one c***k in the chain or link in the chain that had an issue. It was multiple. So I, I think just blaming the supplier to your point is that, yeah, it's not my fault.

'cause this is a shared responsibility model. They didn't hold up their end. Maybe they didn't, but maybe you didn't either.

And, and the other thing I'll say kind of to that team mentality is there's another piece of the team that loves to point fingers and that's legal and risk compliance, right? Because to them, if I can prove it wasn't me, then it's not my fault. And then I don't have to provide any services.

I don't have to pay out insurance policies, what have you. And, and I, I feel like a lot of times developers and and technical people are very much of a mindset of, yeah, it's a problem and we need to fix it, but it's not our problem. I don't care.

We need to fix it. Like we need to go help that team figure it out. We need to go do this.

And legal's like Uhuh, we're not touching it because then we own it and now it's our problem. And the, you know, we, we have that mentality because so many times when economics gets involved, yeah, Fernando's not on the show, but I'm gonna talk about economics folks. Um, when economics gets involved, it is the reduction of resource outlay is the primary driver, right?

Can I prove this wasn't me? Then I don't have to pay anybody for this. If, if I can prove that it wasn't my fault, fault, I don't have to improve my processes, which is a resource contention issue.

And, and rather than that, you know, I take a page out of Harry Truman's book, the buck stops here, somebody has to answer for all of these things and fix the problem. And I, and I feel like you know, that that's kind of what the shared responsibility model is, is it's forcing people who don't want to be involved in that process to be involved in that process. And they have to be because no, look at how this came down.

No one company, no one person can fix this problem. This is a team problem and a multi-company problem. And, and most of the, the high level hacks like this are so, you know, yeah, I I I, I do, I have seen that attitude with the, you know, with the responsibility, the, the fiscal and, and legal.

But in, in my opinion, that's, that's going the wrong direction and that's bad for a company. And the people doing that are undermining a company in the process. Even they may save you $10 today, but they're undermining your company in the process.

Like all things, it's usually never one and one thing or the other. Right? There's a multiple factorial problem, right?

So you have multiple interests. Yes, there's a financial damage, uh, and liability issue that you know who's gonna bring up. And that's always gonna happen.

It's part of your incident response process to bring in all the communications and legal and all the different processes, a part about how we're gonna respond to this instant. And unfortunately, it isn't just the right thing to do all the time. It is the right thing to do for the company and their customers, which isn't necessarily what we might believe they should do as individuals or even customers for that matter.

So I don't think that system's changing anytime soon. And I think it's just how do we best work through it, right? There's times your legal is gonna be all over you about it.

You can't say that you can't, you know, be open with it and then you're gonna have other times like CrowdStrike where the CEO's out there talking openly about here's what we did, here's what we're at fault, here's what we're doing. Yeah. And they get sued.

But, um, you know, their customers appreciate it, to your point, right Steve, when you're being open and transparent about it. Yeah. Yeah.

And, and obviously the bigger the company, the more at stake and the more likely you are to have those kind of restrictions put on you and also the business that you're in too. You know, the more, the more that's at at risk. Yeah.

My, my contention would be that if you're, if you concentrate on the issue at hand and working as a team to solve the issue at hand, that's gonna put you in a much better place when it comes down to the end of the day in the year two years when, when the court battles are over, the actions you took in that proactive way in that open and, and an honest way is gonna, is gonna actually pay off in, in financial terms in those lawsuits. So I, I just had this random thought because I think it would actually kind of help this process along a lot. So we, you know, in, you know, our, uh, offensive security type things, we have the red team and the blue team, right?

Red teams are the, you know, attackers that are trying to destroy the infrastructure. And the blue teams are the ones trying to figure out where the holes are and defend it. What if we had red teams for policy?

So like we go in and we're like, I'm gonna try to shoot holes in your risk management system in your policy. Like, oh, your disclaimer didn't cover that very specific instance, which means I get paid out. Like, I feel like if you could shred that and and force people to adapt the way that they do things, it would actually go a long way to helping organizations kind of get past that comfort level.

Like, like you mentioned, like one of the things that they thought was okay was, you know, we'll just install this root certificate from notepad plus plus and you won't have any problems. That was a solution to a problem years ago and now it doesn't work anymore because we have the compute power, we have the capability to basically spoof that. So that forced them to using a global signature of the download.

And I'm not saying that, you know, Robert Redford and his group of EW Wells from sneakers, great movie by the way, would've been able to Yeah. Would've been able to do this. I'm just saying that if you get complacent with your policies and your procedures, that's when people start attacking.

They're not going to attack your guard post at the fence line at four o'clock on a Monday. They're gonna attack it at 3:00 AM on a Sunday when everybody is relaxed and nobody thinks anything is gonna be going wrong. Those are, I think that's a very good example of what I refer to as stress testing, right?

It's stress testing the process, stress testing assumptions, stress testing, what we think are axioms or unmovable or unchangeable things, our environment and whatever I may believe about what the lawyers are willing to, you know, agree to may not be accurate, right? Maybe just my perception or bias or whatever it might be, to your point. And I think that's part of the red teaming could be just about as much about policy as process as it is technology.

I think, I think to the point is ultimately I kind of feel like, um, you know, we're, we're ultimately interested in seeking the truth. Now what gets disclosed and how it goes through all those processes and all of that, we really want to understand what happened. Because if we seek partial truth, then we look for blame, right?

Because we don't wanna disclose what really happened. 'cause then we'll get blamed for it. Now we wanna understand what happened, right?

What what really occurred. And, uh, you know, false ignorance isn't gonna help us when we, you know, we show up in court and they show us the evidence of that we weren't willing to face ourselves. And it helps the community too, you know, if you, the, the best of these, uh, post-incident reports, give all those details and those details don't just help your customer understand what happened to you.

They help the blue and the red teams everywhere saying, oh, that could happen to me. Let's take a closer look at this and fix my own things. So it doesn't happen.

It, it gives that, that unique information because this hack in this way hasn't happened before. Now we know about it. And because you've disclosed the details, everybody knows about it and they can start to protect themselves as well.

And I, I, that's why I like the postmortems that go into detail about why things went wrong. Um, if you want an example, if you're listening to this podcast, you're like, well, how do I write a postmortem that, that does that? Just look at anything cloudflare's ever done.

CloudFlare writes the best ones. Uh, and they do assume blame when something goes wrong. I remember, you know, we were talking about the one of the CloudFlare outages last year, and the CEO and the CTO flat out in Lincoln Post said, we failed you today.

Like, you don't have to like fall on your sword, but you do have to help people understand and not just stopping at the moment where you figure out it was these people's fault. Because I feel like that's, you know, it's, it's like a cognitive impairment, right? It's like, oh yeah, it was, it was the hosting provider.

Well, we're out of the, the mix. How could you have prevented that? That's what you should be asking.

I do we need to switch hosting providers. Do we need to switch the way that our architecture works? If you can work through every problem like that, you'll have a much better solution.

And if you can't implement it, you can talk to people about how to implement it. It's like, Hey, we noticed that this happened. We're gonna change our system to do it like this.

But you should be changing it for not only us, but for other people, so that this doesn't happen either. But Emphasis you put there on not assigning blame. The the best companies that I worked for when we had these incidents and we did the, you know, we had an outage or whatever, not necessarily a security incident, but an outage caused by, you know, a, you know, a failure of one sort or another.

The best companies never mentioned the name of the engineer who made the mistake. They just outlined what went wrong and why it went wrong, and why we have a new procedure or what procedure should have been followed so that these outages would not have occurred. It's, it should never be about blame.

It should be about process and making things better going forward. Well, and I think too, maybe it, maybe it, it's just maybe my view on shared security model and the flaws in it. I, I think that the real issue is you could, you could change providers, cloud providers and carry with you some of the same problems that led to the problem happening in the first place, right?

It there, there's parts of it that you own as well, maybe all of it. As well as you can also argue that by working through the process with that provider, you may determine, look, it's so broken. We don't, we don't want to be here.

But more than likely, uh, you're gonna work with them and say, okay, we see where the flaws in the whole process were, what we did, what they did. Maybe it was a communication breakdown. Maybe there are other things are working together.

I think it's more of a collaborative security model, right? Because ultimately that's what, what you have to do in situations where something does break, is you've gotta collaborate to find the truth of what happened. And then you want to know what everybody, what actions are appropriate that everybody's taking, they've decided they need to do, we've decided we need to do, et cetera, to, to understand that we've really made the situation better and hopefully alleviated that happening again, or the likelihood of it happening again.

Yeah, I think that's a much better word, uh, shared, uh, collaboration instead of shared. And, and I do, I do understand what you're saying as a a, I would say AWS in particular tends to use the shared model as a way to push off, um, responsibility for having to do things. But the idea that no one entity in a, in a hosting environment, especially, you know, the customer and the host are both have responsibilities in this.

It is a shared model, but collaboration is a much better way to think about it than shared. I agree. But you've gotta get buy-in from everybody, right?

Because one of the things that ultimately ends up happening is you get almost everybody on board and then one group decides to torpedo the whole thing because, well, that's not how we should do it. Like, this feels wrong or it goes against the way that we've always done it. And, and I feel like we're starting to see more and more of those outliers causing those problems.

It's like, if you would follow the process, it would just work every time. But I don't wanna follow the process. And, you know, sometimes you get away with it, but it's like, you know, anything that you, you, you can think of when it comes to statistics, you may get away with it this time, but on a long enough timeline, the chances of you getting away with it every time are zero.

And, and you can't dodge that bullet forever. And, and I feel like some people just, well, we know this for a fact, people are bad at math. Um, there's a reason why prediction markets exist and it's because people are bad at math.

Yeah. The lottery, the tax on people who failed math Or, or otherwise known as Vegas, right? Well, It, but it does feel like that, right?

It's like every time you pull that slot machine handle, because there's a thing sitting out there, uh, whether it's, you know, a supply chain attack from notepad plus plus or opening an open claw instance to the entire internet on accident because, well, I didn't know, well, they won't notice it. But then there are force multipliers that cause that to become more of a, a, a math problem against your favor. Like, uh, shodan scanning for all of these things or, you know, stuff like that.

Like, I, I think people need to understand that, um, it's better to be lucky than good, but it's way more effective from a security perspective to be good all the time than lucky. A little bit alright Than a beer. I just have to be faster than the guy that's gonna get caught by one.

Yeah. It's not a great strategy when there's the only one person the bear's chasing. Uh, just one other thing about this incident that, uh, I I think should get everybody thinking is those, um, high level groups like the Chinese and, and like the Russians are, are very likely to succeed in in getting to you.

So one of the things I think every company now needs to start thinking about is who are my customers that are their targets? And, and if I have customers that are their targets, what do I need to be watching for? And and that's perhaps where the hosting provider or Notepad Plus plus may have been, um, better in their, in, in their blue teaming operations.

A conduit to the real target. Right? Well, I think that's probably a good place for us to wrap it here.

I mean, we could go on for a long time about this. Maybe we'll come back to it. Uh, yeah.

Um, so I, I wanna take a moment for our guest to kind of share some of the stuff that they've got going on. Mitch, of course, is probably one of the busiest people that I know. Every time I turn around he is getting quoted in another publication or he is coming up with a new report.

Mitch, what are you currently working on that people should be looking out for? I've been spending a lot of time in the observability space and, and rethinking how we embedded to embedded observability, whether it's for security or governance or operational aspects. And we've always talked about shift left for security.

Well, that, that model's kind of broken and we've never really used it to in a way that's helped us. And there's, I have this concept about, uh, observability native solutions, meaning that we built it into, and I'm working on a, uh, framework for the agent control plane, the whole environment that agents are created, operate, run, governed, et cetera. So I'm working on a analyst insight report on this framework that I'm gonna be launching.

Um, and hopefully it, uh, you know, it's helping me understand this a little bit better. 'cause it's, it's certainly a very complex environment to figure out how do we do this in the world of ai, more or less in, you know, in today's environment. Still a complex environment to do that in traditional software too.

Awesome. And Steve, if people wanna see some of the cool stuff that you've been working on or learning about, where can they go to do that? Probably the best place to, to follow the things I share is on, on LinkedIn these days, or, uh, I've got a, a Blue Sky account as well.

But, uh, I would say I'm, I'm mostly interested right now in understanding how the tooling of AI is gonna affect the, the networking industry going forward. I see a lot of really cool and exciting things happen. This is equivalent in, in my mind to, uh, what happened in, in videography in the, in the nineties and the early two thousands where, you know, instead of needing engineers to do, you know, videography, everybody had it in the palm of their hand by the end of the, the cycle.

And now everyone can do video and I think networking's going down the same path with the help of ai and I'm really excited to see what's gonna happen here. Super interesting. I'd love to to read some of that, Steve, when you're ready.

Sounds awesome. com. We just posted some videos, uh, as we're recording this from an event that Steve was a part of AI Infrastructure Field Day.

We also have, uh, some upcoming things related to cloud. I of course will be at RSAC this year, along with several of our future and group folks, and we'll have some great tech Field day content coming out of that. We want to thank you for listening to this episode of Security Boulevard.

If you enjoyed this conversation, you know what to do. Head over to YouTube, subscribe. Uh, you can also subscribe in your favorite podcast application of choice because we don't want you to miss any of these wonderful episodes.

And the other thing is, if you wanna leave a rating or a review or even a comment on any of our stuff that really does help the show grow because those platforms love to highlight things that people take the time to talk about. com and the RUM Group. com.

You can also check us out on the Text Drunk TV website, or if you're more of a mobile person, use the Text Drunk TV app that's available on Apple tv, Roku, iPad, iPhone. Uh, if anybody wants to get it running on a blackberry, I'd love to see that. But otherwise, make sure that you're following Security Boulevard on X, Twitter and LinkedIn.

Just look for security BLVD. There's lots of great content out there that you're gonna wanna tune in for, and we hope that we'll see you next week.