Linux Threat Hunting - PSW #942

This week, first up, we have a technical segment on Linux threat hunting.

We'll start this series, as it were, by covering the best places to look for

IOCs on Linux systems and devices. This week, we'll start with startup

services. We have time, we'll move to schedule tasks, if not, we'll do that the

next time. And I'll kind of set it off by talking about the places where I

like to look for IOCs on Linux systems. That in the security news this week,

Sonic Wall Zero days again. AI finds a pile of Cisco bugs, and also Cisco has a

root RCE. Cloud Code Auto Mode has some dangers.

BGP hijacks your unsigned software updates. California Linux and age

verification. Free movies and complimentary malware. Citrix puts Linux alongside

Windows, what could possibly go wrong? Signals air quotes secure enclave.

An expired domain answers military phone calls. More cheap Android devices arrive

pre-owned. That saga continues. Cis are red teams are going up against critical

infrastructure with interesting results. Papercut vulnerability cuts both ways.

Big Tech asks everyone to secure its AI future.

Pacemaker monitoring, DOJ files on a criminal leak site.

War to utility security right after the breaches. All that and more on this episode of Paul

Security Weekly.

Broadcasting live from G unit studios in Rhode Island. It's the show where exploits run wild.

Packets aren't the only things getting sniffed in the cocktails flow steady.

It's Paul Security Weekly. Coming to you from the Hackers Syndicate Studios. This is Paul

Security Weekly. It is episode number 942 being recorded on Wednesday, September 2nd,

2026. I'm Paul Sodorian joined by Mr. Lee Neely. Lee welcome.

Hey, it's good to be here. Nice to contact switch. The event most of the last 24 hours working

on my train layout. So it's nice to talk about cyber. Let's do it. Mr. Jeff Mann is here with us.

It's old timer night.

On Paul's own time.

Yeah. It's an interesting, like I said, it's going to be interesting to talk about this tech segment

in the context of not much has changed in 50 years. I think it's a good intro to it. A couple

of quick announcements before we get started. Attackers are really good at finding your stuff.

The problem is you're probably not seeing everything they are. Shadow IT. Forgotten assets. Exposed

services. It all adds up. So how do you close the gap at the AI at not the AI, but at the attack

surface management virtual cyber security summit on September 16th. You'll learn how to continuously

discover assets and reduce your real attack surface. Security Weekly listeners can register for

at securityweekly.com forward slash ASM. Use the promo code CSS26-sw. I like how we have

CSS attacks and assembly language all the acronyms for them.

Course info sick world's coming up. Unlock the full info sick world experience with your

all access pass featuring premium workshops exclusive content VIP experiences and expanded

opportunities to connect with cyber security leaders across industries. Join them in Orlando,

October 12th through the 14th. Listen to save 30% on their pass with the code. Get ready.

ISW26-sw savings at securityweekly.com forward slash info sick world to 2026. Both of those links

and discount codes are in the show notes. So make sure you go read those.

We do put together show notes every single week which is nice.

We do technically that one's not coming through as a link because it doesn't have HEGPS in front of it.

Yeah I'm holding it. We need to edit that. We'll get that sorted out.

But it is you know if you cut and paste it it would work.

Yes. I do want to start the show with a technical segment that will run about a half an hour

and there's a lot more to share. I will probably spin up a new GitHub repo based on some of this work.

This of course overlaps with work that I'm doing at my day job thinking about

how we when we look at Linux systems today where would we look to find indicators of compromise.

I was telling Lee in Jeff just before the show that it's interesting as I dwell on this topic.

I've come to realize that in many ways not much has changed in the past how old is Unix 50,

50 years and I'm just making a wag as we call it. Let's just say Unix has been around 50 years.

It's probably longer than that. Well that's probably between Unix or Linux.

Okay Unix is yeah it goes back to the 70s. 70s. So yeah Ruffa 50 60 years old at this point

depending on me, depending on how you count. But what's so I kind of defined,

started defining these pillars and what's interesting is these pillars of like where to look

were derived from not just institutional knowledge but also threat actor behavior today.

Now largely the lens for this is not just Linux desktops or Linux servers but Linux devices as well

which changes that lens a little bit as to how you threat hunt because devices typically have

our IoT or network edge devices have a very well defined scope. So variations to that scope

can set off flags. Whereas on a server for example administrators are installing software,

removing software, creating schedule tasks, removing schedule tasks, it's more of a commonplace.

But on some of these embedded devices or network edge appliances, I mean if there's a new system

startup service and you have an applied an operating system update recently, that's more than

likely malware that's been a new system. Right so the lens is important. What I find interesting too

is thinking about this from an incident response standpoint. Right so there's a couple of ways

to conduct these investigations. There's the kind of live incident response. Oh my God we think

something's hacked. We need to go collect evidence. Then there's also like the ongoing monitoring

indoor threat detection. You might have an EDR, you might have an AV, you might have a SIM,

some other technology that's helping you monitor your Linux systems and or devices,

their health and whether or not they are presenting IOCs, IOXs or indicators of compromise.

So just to kind of lay the the groundwork when we're doing this type of work,

that memory wins, right, that taking a memory snapshot snapshot is awesome. It gives you the running

state of everything and if things are memory resident, obviously you wouldn't get those after the

system reboots or if you haven't snapshoted memory and you're just looking on the file system,

EBPF is extremely powerful for loading programs into kernel space that can potentially do

harm or hide artifacts. Which is the next point like Linux root kits, kernel module root kits or

EBPF root kits. They're going to tell programs or get in the execution path of a program and tell

it to hide artifacts. And again, this is like one of the first things that I learned when doing

incident response on Unic systems was never trust the binaries that are on the system.

That when you run the PS command, whether it's Linux or whether it was Unic's 50 years ago,

when you run that PS command, if it's on the system that's been compromised, it could be lying to

you, right, they could have swapped out the binary. They could have hooked the system call

processes, loaded the library in front of it, hooked the kernel for that process that when it runs,

it's going to give you what the attacker wants to see, not what you're looking for.

So it's always best to bring your own binaries when you're doing this work,

which is kind of interesting when you think about how you do it at scale or how you have some kind

of agent or software that's inspecting your Linux devices, hey, is this device compromised?

If you're relying on the utilities that exist on disk, you have to realize that they could be

modified and or their view of the world may have changed through a number of different mechanisms.

I have an old timer question. Yeah. Back in the day, when we were attacking Unic's

based systems, we used to rely very heavily on something called a cordon.

Is that still a thing in modern Linux times? And is that

different these days from the memory dumps that you were just talking about?

Yeah. A cordon is a system's diagnostic file that's a capture of memory. Memory forensics

or memory diagnostics done by an analyst typically uses other tools, which are outside the

scope of this particular technical segment. I do want to cover those on a future one as well.

There are various ways to collect memory snapshots across all operating systems for forensic

purposes. That's like a high-resistant thing. Back in the day, memory was more of a premium

and the cordon was getting stuff out of the stack itself. Right. But now probably there's much more

juicy information that's out in memory since memories cheaper these days. Well, not anymore.

But what makes me think, remember the way you know, things used to dump

cord a lot in the way you'd get it keep running up with a bunch of core files as you would put

a directory called core in the directories where you didn't want to profile a file.

Right. Because if you just made a file, it would overwrite it. But if it was a directory,

it couldn't turn into a file. I'm also thinking, you know, the interesting what you said about

bring your own binaries. I mean, first, we worried about people messing with the path. So use

the full path to the binary as opposed to assuming the one in your search path. Then you went to

like where possible, statically linked because people were messing with loadable libraries.

But now they're messing with the kernels. They're moving the the flexion point. Right.

And so I'm thinking, as you were starting talking about scaling, I'm thinking, if I'm bringing my own

binaries, when do I get to the point where I almost have to boot off my own distro before I start

doing analysis? Are we there? There's different levels of that too. Yeah. I think one of the things I ran

across I want to dig into more is like have a read only so it actually cloud suggested this like have

a read only mount volume where you have statically linked busy box and system utilities. That's kind of

nice. Of course, booting, you know, if you're going to reboot booting off of bootable media or

just bringing your own unremovable media is a lot to unpack there. Same with recording the session

which I kind of like as well. There are ways in Linux to like capture everything that's happening

in your terminal so that when you go back and review your forensic investigation, you have a log

that was captured at that time. Again, the topic I want to revisit at a later time. Also, like every

command you run in a live system is going to modify files modified file times or ePOT, right?

Modify those the file system and so that could potentially overwrite, destroy or obscure evidence

on the system. Zero trust is clearly the future as threats get faster, quieter and harder to detect.

But implementing it shouldn't disrupt the business. Threat locker enforces default deny at execution

in a way that remains enterprise ready, scalable and operationally clean. Unknown software is

stopped cold, trusted apps stay contained and drift is locked down across the environment.

It's zero trust that works in real enterprises and prepares you for the threats ahead.

CYC so is our adopting it at securityweekly.com forward slash threat locker.

So I had another question just came to me as you were saying that. You know, used to be really

in the in the in the New York world, you applied the updates you rebooted that was now when you

apply updates, if it can restart services, it will about the only thing it says I can't handle

is restarting the kernel, of course. So what I'm wondering is, is that is that translating systems

being booted less? Therefore stuff now are hanging around. It could longer. Untitled Linux show was

talking about MK ultra multi kernel Linux, which is interesting to talk about in this context where

you can have multiple running kernels and swap in between them. I don't think it's highly practical

for most of us. I think if you're running specialized workloads, that's a thing in containerization

virtualization largely solves people's problems rather than running a multi kernel thing. I think

academic thing to study the multi kernel thing is super interesting. And one of the techniques

there is that to swap out kernels or have multiple running kernels so you don't have to reboot.

I think red hat did some work on that as well. So but also the more kernels you have, the more

attack surface you have, the more things you have to investigate it greatly complicate these

matters. Same thing with VMs and containers, right? Which is more instances of things where you have

to go inspect. So I think some good advice in kind of live response tips are when things disagree,

that's when you have a higher degree of confidence that something's been compromised. In other words,

there's places where you can look and you'll see it some of that in this segment too. So you can run a

command that'll show you the state of something or you can go look and like slash proc or some other

directory that shows you exactly where that stuff is stored that the command is just kind of reading from.

And so if you do both of those and now analyze both those places and they disagree,

that means an attacker has changed your view of something which is a huge indicator that something's

been compromised. So I started by, so I talked about I have like seven to 10-ish pillars and I'm

trying to focus on the ones that are most abused by attackers. And these actually translate to

any operating system. Like it doesn't matter if you're Windows, Mac OS, Linux, or whatever

SOT, operating system you have, I believe that these are like standard pillars, I call them

that you can look at. So one is like house services start. Not to be confused with fundamentals

basics where the foundations that we were talking about. Yeah. I mean, all of those telephyses.

These are places where you could look like in a generic high level possible places you should look

for indicators of compromise. And one is we'll talk about today startup services.

When your system boots and your kernel loads and it starts running services,

what are the mechanisms that do that and how you should inspect those? Scheduled tasks are

another thing. Scheduled tasks are a huge abuse in Windows. Obviously, Cron is also abused in

Linux and Unix systems as well. And that translates to how any other operating system that

supports any type of schedule task is a place where attackers may hide.

That translates to authentication. How are people authenticating to the system? What services,

programs, services, configuration files, support that authentication, and how would you look at those

to see if they've been tampered with as an example? Process listing. Look at what processes are running.

Look at what listening ports you have on the system is another in other place to look.

I have a stupid question, Paul. Why in 2026 do you feel compelled to list this stuff out?

Because this is really, really basic stuff that's at a high level. This is very basic. However,

as you'll see, Jeff, when we dig into how these are implemented on specific devices and

operating systems, it's in onion that has many, many, many different layers.

This is best practices from the days of the foundations and fundamentals and the basics.

However, we also determine how to handle every single one of these pillars that we're

doing. You've rightfully called it out. This is stuff we've known for 50 years, and this is basic

stuff. However, I can tie every single one of these back to multiple pieces of known malware

in the past year that have implanted themselves and tried to hide and or execute in these places.

And that's today. So what it tells me is that since these campaigns are successful, we're not all

looking in the right ways in the right places, even though we know at a high level, yes,

these are things we should be looking at. I'd contend you're doing one more thing, Paul.

It's the old, remember, the old hack that still works, the old vulnerability is still there.

You got right on the screen. We got the system D, the old system five in it scripts, which

mentions RC.local, which I contend was originally a Berkeley thing. It doesn't matter. But those

still work. It's not all in system D. Malware today is still implanting itself in, we'll start with

system five in it scripts, right? Etsy RC.D and it.D. Regular shell scripts that handled the

starting up of services in a specific order on your system. And there are many embedded systems,

IOT devices, network, edge appliances that still use the older system five in it script thing.

There are still malware that is successful today in implanting itself. In fact, I believe it was

fire and was a campaign conducted against a few different targets, one of which were Cisco

iOS XR routers that run Linux as a sub system underneath and use the system five in it scripts.

And guess what? Attackers took advantage of that to gain persistence on that system.

If you're not looking there, like you should be like we all know we should be,

then you're going to miss it. System D is also a rabbit hole as you'll see. There are multiple

places where system D start up scripts can live. There are placeholders for if you install the package,

it puts it start up script in user lib. If you're an administrator and you want to create a new

start up script to start a service, you would put that in Etsy system D. And then there are also

things such as overrides, which you can then say, hey, rather than run this start up script,

run this other one or append this other one. So Paul, I think the better analogy rather than

rabbit hole is actually peridog hole. Yeah, because there's lots of entrances to a peridog

burrow. Yes, rabbit holes typically only have one or two. Yeah, and I think the assumption is like,

oh, you should look at your let's we're starting with start up service configurations.

And when I start on this, I'm like, oh, it should be easy. Like I should just be able to grab all

the system D configuration files, analyze them and determine if they've been tampered with or it's

executing malware. But they live in so many different places. And again, the overrides thing is

is a big thing that you can basically extend and say like, hey, not only are you going to run this,

these commands when you start the service, but I'm going to append these new commands that I also

want you to run. And there was like reasons for that to start different things or do different things.

But attackers abuse that me like, oh, you know what, when you start SSH, that's great from that

script to start SSH. But by the way, I'm going to give you an override and I'm going to append this

other startup file and you're going to execute that as well. And if you're only looking at the startup

file that shipped with open SSH, you'd be like, everything's fine. But if you're not looking for

these other overrides, you're going to miss it. And that's just one example of the things that I

turned up. There's also user level system de-configuration. So in the, now these don't execute as root.

My previous examples so far execute as root. User level units are in your user home directory

in your config.config directory. And they run without root. But an attacker can certainly implant

things there that will run as the user. So if you're not checking every user's home directory,

for a specific sub directory in configuration file, you will miss other programs that will start

up as that user. And attackers will also like to hide there as well. But Paul, correct me if I'm wrong,

but most Linux out there in the world is very much server based and delivering most of our websites

and probably our cloud platforms. Are there in those types of systems that many users logging on?

Because the ones that I see typically are very few use. Nobody's using it as a workstation.

Yeah. My workstation used to be a Unix workstation and all this stuff really applied.

Yeah. I think there's differences between systems that have interactive users.

Maybe administrative users. Certainly. Yeah. I mean, there's usually

administrative users right on those systems. And then if it's not a desktop system,

you know, someone's not really logging in every day, but you still have administrative users

as well. There is one towards the end of my list. It is a desktop Linux desktop specific one.

And again, I don't pay a lot of attention to those Linux desks helps or not. The majority of

the market share, but when you start your desktop, there are other user specific ones that can run

when you start your desktop. That would be limited to desktops. Servers have well-industrators.

And even IoT or embedded systems may have an interactive user that logs in as an administrator

over SSH and could execute some of these startup scripts as well.

Well, and to answer my own question, a lot of the Linux systems that I see in my travels and my day

job are not... It's more common the last couple of years, but for a long time, the Linux servers

are out in the web farms and things like that. We're not attached to the domain, the active directory.

Yes. That happens more often than not. So they all necessarily had only local accounts to look at,

which made doing all this stuff that you're using to describe it. It's no good. It's no good.

Filos, which are part of my assessment work.

Very interesting area that I'm looking at is that understanding how the system authenticates users

and then looking for deviations. This crops up on a lot of like routers and switches that may use

TACACs or LDAP or some other authentication protocol like you mentioned. And if they do that,

well, what about those still the local accounts that may exist on that system?

I think that's a good discrepancy to look at that. Hey, when we log into our routers and switches,

we use a federated identity, if you will, or an authentication provider. There really shouldn't be

local accounts. If new local accounts are being created, you should observe those in scrutiny,

as those heavily, because that could be an account created by an attacker.

I don't want to derail your presentation that much, but I do have a question in terms of,

have you given thought or have you in your research found any indicators of why things are so

bad in the Linux environment? Is it because Linux didn't used to be looked at it as a primary

target from Alweir, which we used to call viruses, and you know, whereas Windows, it was a plethora.

Is it a false sense of security? Is it administrators of these systems relying on network

security controls or access controls? Any, any hunches or leanings?

Yeah, it's a number of things. I think, well, first, it's not an untapped resource by attackers.

They're definitely going after it. A lot of these systems are

appliances or devices where the user doesn't have those controls to enact, to rely on, to protect the

system, and threat actors are taking advantage of it. When you get to Linux servers, there's so

many different ways to configure, secure, and monitor your Linux systems that I think attackers

are really finding the cracks to go in, to go, yeah, great. You can figure this and not that,

and configure this other thing, but if I do this, I squeak in through the cracks because there's

so much control given to the administrators and so many different options on how you can figure it,

that attackers are finding the cracks in where to hide and be effective.

And that was certainly, again, just looking at startup services, I learned some things doing this

study, like system degenerators, or arbitrary binaries executed early on every boot.

They are special system de-configurations that load before everything else loads on your system.

And if you were to, as an attacker, plant something there, it would run, and I was like,

why, I didn't even know about those. And then I did a search on the threat landscape, and I'm like,

I've not seen this in the wild. This is one where there's an opportunity for attackers to hide

there, but I've not seen it in the wild. That's crazy. You heard it here first. There's also

non-service units. So this is like system D's Cron service. So system D kind of has its own

timer and Cron service. So an attacker that's able to schedule a timer or a job in system D,

effectively the same thing as Cron, but it's in system D. Like, well, that's an awesome place to

run malware. Also, you're going back to interactive users. Again, an administrator might log in

to a system and have their own Etsy profile, bash, or C file. Those are really just shell scripts

that can execute whatever you as the user wants or an attacker wants to. So an attacker could also

poison those. And while it's not a traditional startup service, every time the user logs in,

this code will execute in this another place where attackers like to put code. Also one that I had

not considered, remember the MOTD message of the day. And this is typically the banner that gets

displayed once you interactively log in. It's essentially not even essentially. It is a shell script

that executes every time someone logs in. So if you were to put malicious code long, long time ago,

it was set UID zero. Yeah. And it's sometimes it executes this route, right? And so if you were to

put malicious code there, you can execute in MOTD. I'm like, well, that's another place where we can

execute code in addition to the classic LD preload, which we've seen before, of course, which is

basically loading a library before your program runs. And you could have that library do it. And

it basically execute this code before this program runs type of thing. So

really awesome to think about. I had not considered like, and I think the other thing is as Linux grows

in complexity and offers even more options. I mean, we just went through, you know, eight or nine

different things in different components within startup services on Linux systems that depending on

the configuration are in play. So I did have a techniques to analyze all of these things. And I

will I am working on publishing these. So these are scripts or short commands that you can run to

identify all the conditions that we talked about. So we can see what has been extended or over

written in in system D. Those are two different things, right? There's the run the system startup

and then run this, which is extended. Then there's the I want you to run this. But instead,

I'm actually going to override that in a new file kind of thing. And one important note there is

when a package ships on a major Linux distribution, you install a package from

apt on apt repository on Debian, all of the files that are contained with their contain hashes.

And you can run commands on the system to compare the file that's on your system. It's almost

like Tripwire built in like this package says it installs these 25 files, all those 25 files each

have a unique hash. You can run a command that goes through every file associated with a package

on your system and compares it to the package maintenance hash that should be on your system,

which you should do by the way. Also, a lot of this is being built into my tool that I call FETL

as well. So it has an experimental feature for startup services that I implemented that I have

to go do some more QA on, but this stuff is there to check your systems are in good order. And it

already had that capability to run those built in commands to check those hashes. And so these are

just kind of variations of that making sure it's in good working order are there malicious patterns

inside of your startup files? Check those directories that no one else checks that can actually start

up services. There's some scripts for that. Are there new system D unit files or startup scripts

system because of unit files that are on your system in the past 30 days? If you haven't installed

a new software in the past couple days, but there's a new startup system D unit file on your system

that could be suspect. System D analyze security is actually a command, but what it does is it looks

for the sandboxing feature in system D. I'm not sure exactly what the sandboxing feature does,

but many packages have chosen not to implement the sandboxing feature. And I'm not sure why yet.

So that was kind of interesting. And it'll actually score all of your startup files and tell you

whether or not they're implementing the protect system feature. Again, there's a little more

research on my part to understand what that does. I'm finding there are a lot of Linux security

primitives, if you will, features that are available that aren't very common and don't have widespread

usage. And I'm not sure that's because they have certain limitations or drawbacks or because

every Linux system is a unique snowflake and configured in a certain way. And implementing that in

a broad, you know, wide scope would break things. And therefore the default is to ship it

insecure and let the user sort it out. That's kind of the, you know, all these security features

kind of fall into those different categories. One thing that I do like about where I'm going with

this is, you know, you we've identified all of the different places where attackers and malware

can hide and abuse system startup services. How do I audit my systems on an ongoing basis to

detect these anomalies? And one way is with audit D, right? Audit D is a sub system that can create

logs based on any number of different indicators or events on your Linux system. It was awesome is,

you know, Cloud help me kind of develop what rules in audit D should exist that monitor for changes

in your startup files so that it gets written to an audit log that you can go query later.

So these I actually tested, I'm actually tested amount of my system today. When I say tested,

I mean, syntax wise, they will go into audit D and they will generate some logs that's as much

as I've tested it. If they generate a copious amount of logs or incorrect logs, I haven't validated

that yet. But I think these are good things to start monitoring with audit D. Collect it now

analyze it later. You know, my feeling is perhaps in FETL, something that looks at your audit

D logs and makes sense of those tells you about anomalies, weeds out things you don't care about,

weeds out false positives, identifies the things that you should look for is good. And again,

we talked about the basics. However, there are five bullets there of recent malware,

four Linux systems that are abusing these facilities inside of Linux to persist on Linux servers,

Linux test hops, Linux embedded devices, network and appliances. It covers all the bases there.

So you can go read those articles. I will again, I just started on this technical segment series.

Again, you know, based on a lot of research I'm doing for work and just really trying to nail

down all the details as to how do we effectively hunt on Linux systems today. And again,

Linux systems being an overloaded term again, could be a desktop, could be a server, could be an

IoT device, could be a network edge appliance. How do we hunt on these systems? And again, it turns

out that we're just we're looking in the same places we've always looked, but maybe with a lot

more unpacking to do because there's a lot more options and configuration available to us today

and to attackers. So one thing I ran into is looking looking for my logs and it's just now you

got to go talk to journal B. Yeah, and every Linux system is different and all the configuration is

different. And I went down that same path, Lee on my systems because you know, or every Linux

distro packages these things slightly differently. Some are enabled by default, some are not. I had

to enable audit D. I had to I had to do different things on arch Linux than I did on some of my

Debian Fedora Ubuntu test systems where I'm testing Fettles. So it's all different. And again,

I think that some of the problems that we have today is that these security primitives aren't standard

has every Linux distribution does it differently. And then people customize every Linux

distribution and they ship it and what's called a network appliance and then it's different there

as well. And I think that's what to Jeff back to you or I think it's a great point, right? That's

what attackers are banking on is I know that this works and it probably works in this case and you're

probably not monitoring it because it's such a unique snowflake in your particular instance of

your Linux distro. It's kind of where the freedom and options we have available in Linux work to our

detriment. Does this imply that there really isn't a good not picking on them but as an example,

CIS benchmark for Linux or is it because there's so many flavors it's hard to really create something

like that. It makes it hard. When I think about it from a detection engineering standpoint,

I have to have like a lot of intelligence and templates to go like on this system, here's where I

check and this is what I check for. But in this system, it's different. So I have to look in this

place and check for this different thing. Trust me, I know I've done that process for years. We've done

it manually. We've done it on it. So I've done the same thing, Jeff. Yep. Yep. I know we're running over

time. I do want to take a short break. I do promise that I will start publishing this stuff out there.

This was just the first one in the series. So if you like this, send us feedback. If you want us to

cover more specific things or go in a certain direction, please give us feedback. I'm happy to do

that. I think this is a fun conversation. And with that, we'll take a short break and come back with

the security news. You're probably sick of the word agent, but here's the problem. Your dev team is

handing every new agent in your cloud way more permissions than it needs. And when one goes rogue,

you've got four minutes before your data is gone. You need a default deny button that doesn't

break every workload. That's Sunrise Cloud permission firewall. Native IAM controls,

not new fangled AI nonsense. Default deny on every agent in human identity automatically.

Learn more at securityweekly.com forward slash Sunrise. That's S-O-N-R-A-I.

Welcome to the security news for this week. Very exciting. Talk about a number of different stories

that we have. Where do you guys want to start this week? We're going to a lot to talk about as usual.

I think critical infrastructure was a was a thread we can pull on. Of course, A-I's a thread, but

so critical infrastructure. Who wants to talk about critical infrastructure?

Who doesn't want to talk there? Jeff, you want to start there? I'm happy to start there.

Do we all have this story? I'm sure we all store it. We saw multiple stories this week.

Multiple stories. I'm not sure which one we're starting with.

Well, for me, the neat story for me for critical infrastructure was the stuff they started out in Texas

with the project watershed 250, where they've got a whole bunch of vendors chipping in support to

get their water systems down there. Head start on cyber. How many times do we see them?

You know, I find it interesting. I don't know if it's just coincidence or not, but I know Josh

Corman's working a lot in improving security for our water systems specifically here in the US.

Recently, I see a lot of activity happening in securing our water systems.

Hopefully, Josh is working as magic and pushing people along in the right area.

While there's a lot of critical air quotes critical, it may be not air quotes critical infrastructure.

We can lump a lot of things in there. Water is certainly important as a critical resource in

infrastructure in every country, not just here in the US. And securing the systems that help

monitor and supply water certainly important. And also a sector we've talked about being

woefully behind in terms of cybersecurity maturity, because I agree it disagree, but largely

we've covered over the years points to that. I tend to call it more neglect than anything else,

because there is no regulation that requires specific cybersecurity standards or thresholds.

Is that true? Name one.

We should add Josh on for the second. Well, yeah, he would nail it, but I think there's inferences

and references, but I'm not aware of any regulatory standard that's like specifically focused on.

We talk about power, we talk about power, we talk about NERC SIP, right?

Certainly, but there's no equivalent to that. I can't think of one either.

I'm not thinking of one. I think at the federal and state water providers have plenty of regulatory

requirements, but I don't when you look at the small operators, you know, from here to

but it's largely small. We covered a story years ago where many much of the water

infrastructure is not run by the federal government or the state that is an independent provider.

It's not well, it could be independent or it could be small government,

county city, right? But the regulations are scarce in comparison to electricity.

I'm happy to be proven wrong, but I'm not aware of anything. I think, I think, and I'm just

started doing a couple of searches, but I think what you if you looked up regulations relating to

water systems, you're going to find stuff about safe water and water quality as opposed to cyber.

Cyber, right? But those go ahead. That's kind of that's kind of really important.

It is super important. And maybe some of those have a reference to cyber, but I'm sure it's

you know, it's kind of like, what's the old one? Socks, where there was like one line in socks that

had something to do with computer security and everybody had to do socks. It was a GLBA, one of those

two had very few. It came out on the same time. Yeah. Yeah. And yes, but so I mean, I remember talking

to a friend about they were in a small community, they were getting a new water provider that was

doing a much stuff, including cloud services and all that stuff. And she had a cyber background,

but of the rest of the board, nobody had a freaking clue. It was all smoke and mirrors. And the guys

were like, he was blowing smoke up their ass and they were like drinking it by the gallon.

Sorry to mix my metaphors. But yeah, so we need some we need some good guidance. And on those small

and water utilities, I think those enough to decide whether they're secure or not may not even know

or care. I hope they care. You get bigger. That's, you know, metropolitan level. I think you're

you're not bad. But if I'm reading this right, it's like, even if you've got it nailed, you can

sign up and get an assessment for free in the next six months. I don't know if they're going to come

in and install a bunch of products for free that in six months, you have to license. But

I was trying to find information on how to join the program or, you know, gotchas or anything

and I couldn't find it. I got really excited about this. But I don't know if I'm excited or offended

that they're making a big political thing like, hey, this is something new. But it's something we've

been aware of for decades. It's needed some it's needed some love and some cyber. It's it's

there's over 50,000 water service providers in this country. Would you agree or disagree? It needs

government, not oversight, but government sort of take the take the reins and provide a lot of

security. Not just the requirements, but actually the protections. So the question, my story number

13 brings up actually Jeff is, do we need to red team critical infrastructure or just have them

fix their stuff? I mean, this red team assessment was interesting in that it looks like one

organ of target they had was pretty good. It actually detected them and responded in the other

wasn't. Was your 13 also leaves SISO? Is it? I think SISO? Yeah, might be the same. I think it's not the same.

Well, maybe I just saw it on your phone. I have a SISO. It's the SISO red team. Yeah, the SISO's red

team, right? Did two critical infrastructure organizations, I don't think they disclosed what sector

they were in perhaps? My guess is water since all the stuff I'm seeing about the water lately.

Let's just call it water. Yeah, let's say it was water in any vertical, but let's just say water.

You're going to get this right? You're going to get an organization that

pays attention and it's like, oh, we're under attack and we need to respond and you get another one

that goes after the assessment, oh yeah, if we look back, we would have detected you if we were

paying attention. Both of them obviously have one more than the other, but failures included,

this one kills me, default credentials, ADCSS, misconfiguration, SCCM secrets,

weak cloud workload controls, noisy alerts, and silo responses. I mean, that's my,

I'm not going to have an opinion on this structure. That could be any organization,

nonprofit, for-profit, critical infrastructure or not, all have these things that they miss.

So that kind of marries with my article, which is about their vulnerability report for the last

group, because they're basically saying people are missing the basics, you know, the change of

default credentials, strong authentication. I mean, it's just implying the same thing, Paul.

And it's, it's, it all comes, it's a circle that keeps repeating itself.

So yes, and my take on it is, you know, back when I was doing this out in the private sector 30 years

ago, when companies were just getting onto the internet, it was all about, we didn't really call

it red teaming back then, we just called it pen testing, but back then we defined a pen test as

what now is to find more of a red team. Show us how to break in. And again, it's all based on that

hacker movie that I like that Paul is okay. Sneak. No, I like it. I just like other ones better.

But, but the premise is and the, and the belief back, I love it. I should say I love it.

Okay. Good. It's timeless, by the way. Yeah. And it's timeless for this very reason, but

the idea back then was, it was more like a scared straight type of thing. We got to show you how bad things are

by breaking in and showing you how easy it is and showing how poor as you are, with the belief that

this will make a difference. This will get everybody to be secure and start changing their ways and their habits and

secure everything and hard and everything. That's the part that hasn't worked. So I see in this exercise,

there are almost recycling back. I wouldn't say we got to raise awareness. I wouldn't say it hasn't

worked. I would say it's not necessarily the most effective mechanism, but I think human nature. And

so here's what got me thinking about this. Give me an example, but I'm going to give you an example.

Okay. I'm going to give a real world example. Then we can talk about cyber security examples. But

my real world example is I'm going to pick my son up from soccer practice. Yesterday. And the bus

schedules have apparently changed. There's not enough money to have as many buses as we did last year.

So we have less buses, which means buses are dropping kids off much later than they were before. So

when I go at that time to pick my son up from soccer practice, I'm like, wow, I'm stuck behind buses.

Like two hands from like this sucks, but I notice the bus monitors. When they get off the bus,

they let the kids out. They make sure the kids get to wherever they're going safely. They're out of

the street. And then every single time they look, they go in the front of the bus, they look under

the bus and they look behind the bus. And then they get back on. And I believe, I believe that is

because there was at least one incident where tragically a child lost their life more than one,

because they were they were run over by the bus, which I mean, it's awful. Like I thought about

that. I'm like, so a child or perhaps more had to lose their lives before we created this very

basic safety measure that we always did to prevent that from happening, which adds maybe

20 seconds to each stop if that slightly inconveniences people. But make sure that tragically no

children are losing their lives. And all of us have children hosting the show. Many of us listening,

of course, like we would all agree that's a perfectly valid safety measure to prevent that that

tragedy. But we didn't implement that until bad things happened. And I feel like also the way

we had to test work, we had to see these bad things happening before we put the slightly,

or sometimes more slightly inconvenient measures in place to assure security. Yeah, but Paul, I

would I would disagree with you in that the exercise, the pen test or the red team, because it's not

real has not had the effect that same effect. Yeah, the actual bad things happen if they had run

over a doll. Right. I mean, a right team that could throw in a mannequin. They threw it a mannequin,

right? And they were like, yeah, well, that could happen. But you're right, Jeff, until that

actually happened. And I wasn't and I was genuinely interested in seeing if you had a scenario.

I'm not aware of any company, at least the ones that I've dealt with, which is in the hundreds over

the last 30 years, that after a pen test and after a passive exercise or a good guy exercise,

say, oh, yeah, we should change a lot of things. I mean, one of the reasons I stopped pen

testing. No, I think that I think that varies, Jeff. I'm sure it varies. Right. But my experience,

let's just say it doesn't, I think it doesn't happen in every case. And that I agree with.

I would say that some percentage less than 50, probably not more than zero. But also in those cases,

do they change all the things or some of the things? I think they change some of the things,

not all. Well, they tend to change what was exploited. Correct. And they don't and they're like,

oh, yeah, we should probably look into all those other things, which we'll get to when we start

talking about the chaining attacks, because I think we used a couple of us had this story.

Remind me to bring this up again. But you're right. A lot of, if they do make a change,

it's often more often than not, in my opinion, a specific change based on the output of that test,

not a holistic change. Right. That's like, oh, we need to change our processes. And well,

how we how we conduct business in our behaviors, it's typically, oh, yeah, we should go change

the default behaviors or processes. Leads, I'm just saying. Well, I was actually, I think on a

parallel path with Paul, I was thinking they chick, they'll fix the six flaws in the system that were

identified, not the path that identifies how they got their error, you know, looks more thoroughly

for other. Going back to my text, I mean, right, not looking at every different scenario where

attackers may implant in this one area in implementing wide sweeping monitoring of all of those

different scenarios for this one area to address that. They'll just go, yeah, I'm going to patch my

Linux systems and I'm like monitor this one thing or put this EDR on all my Linux systems and not

really configure it. And I'm going to check the box and be done. Yeah. And part of that is time.

I want to get you a gain to a little bit of security and maybe increases your security posture a

little bit. If your answer is, well, I'm just going to patch them in a slap in EDR and all my

Linux systems without really investigating and investing the time and resources appropriate,

it gets you some moving the needle forward, but not not a whole lot. Not a whole lot. And unless

it's under the category of a regulator or an auditor, right? In other words, if you, if you've

self-elected for a pentast, you know, you do it the heck you want. Hopefully you do stuff,

but you might elect to do nothing. But again, it's not every organization as well. Yeah, it's

every every organization's response to a pen distro of breaches different. Mm-hmm.

That's what keeps you. But again, the breach is a lot different than I've seen two. I

read you in 30 years. I've seen two things at work. One is they had a really bad day.

Mm-hmm. Two regulation requirements. And you know which regulation that I'm referring to.

But it's made a difference. Yeah, no, it has. You know, but those are the two reasons that have

that have made what I would call for lack of a better term institutional foundational changes in

organizations. And I've worked with companies that did not have security before the very bad day.

And it took a few years, but they were committed to doing it happened to overlap with the PCI thing.

But I have never, I'm sure they exist out there. I've never seen a company out there that just

does everything because it's the right thing to do that isn't regulated to do it or they had a very

bad day. Yeah. I agree with you. It's easier that way. I mean, there's a lot of wins for PCI,

but there's other regulations that have also caused wins. Oh, I'm not saying they're not.

Oh, I'm saying regulation. I don't want to mention that. Let's talk about age verification for

operating systems and other technology. I'm also a regulation. I know it's a California law,

damn. You know, but I've evolved in my views in that I used to get this like have this

take on this that all regulation was bad. No, no, right. We just throw it out there. All

regulation is bad. A lot of times you'd be right, but also a lot of times you'd be wrong in my view

evolved over the years in that smart legislation actually works. The problem is we don't often get

smart legislation as with California in the age verification in California because they

approved a law that had a lot of issues with it. I think had to approve an amendment that would

exempt qualifying open source operating systems from the mandated age verification requirements.

Now the original law requires operating systems to collect a user's age aged tier during setup

and send an age signal to app developers, but that model assumes that centralized account

management like Windows, Mac OS, iOS and Android. This exemption would protect Linux distributions that

don't have that centralized man. Anyone can use this is the part of freedom that I love.

Anyone can contribute to it. Anyone can use it. And under many different licenses, you can use it

however you want. And I love that. I think I think there's a huge part of me that gravitates towards

software should be free and open and free as in you can use it however you want. Kind of thing.

Even if that usage is particularly evil, then it's not the software that's evil. It's the user

that's evil. And I do get on board with that. But I agree we need to protect children from

danger. I'm not sure that age verification for software does a whole lot to protect children.

Like what do you, especially in Linux, like what do you, you know, you're not protecting children

from Linux. Children should use Linux to learn and exercise those freedoms. Now I get it. They're not

adults and they do require some supervision. And I think the perhaps the law is targeting

the maybe lack of parental supervision or loopholes in that in that process if you will, where

children want to use software the way it's not intended or for nefarious purposes that can harm

children without parental supervision. And therefore you need a law that helps negligent parents.

I guess I just come out and say that right. Is that the purpose of this law?

I mean, I think yes, we need to protect children. I remember I'm thinking back to what my mom used to

do years ago is she had her computer was set up for her. My nephews would come over to use it.

They just start using it in her account. So in the age verification, they would show somebody in

their 70s, right? Good to go. And yeah, they buggered up her computer because they would install

and download stuff on it. It was really dumb. You know, but as long as I was there, we used to say like,

hey, if you're going to have a computer at home, put it in a centralized place. So at least you can

kind of keep an eye on what yeah, and how everyone's using the computer. But now every person

everybody's in their corner. Yeah, everyone's got their own multiple personal devices. They got a

phone, they got a tablet, a laptop, they got a TV, they got whatever. They've got all these

devices and you can't possibly monitor all these devices. So therefore we need regulations to

keep the children safe. I'm not sure that's quite the answer that we're looking for here.

Well, and I heard on and I was watching the TV news earlier this week and I forgot to look for

a written article about it, but meta has agreed to limiting access to their various social media

platforms for you. Did you guys hear about that? Yeah, I think where I stand on this is I think we

should have the freedom to develop awesome technology and make that available to everyone. And I

think in a lot of cases, we also need when it comes to children, like not adults, we need to give

adults a way to monitor those channels. So like it's okay to use Instagram and actually meta has

done some of this in the past with like Facebook Messenger for kids. You want children to use

the technology for productive means and to keep that in a productive environment, you need to give

parents the ability to give some oversight to that. And that's that's totally fine with me. I think

regulation should encourage visibility and monitoring from parents to help the children use the

technology in the right ways. So and I'm not saying like children are going to use it for

to violate the law. I'm saying parents need to monitor children so they're not abusing the

technology that's detrimental to their health. So they're not spending all day scrolling. So they're

not viewing sensitive content. Like, but they're still able to use the platform because for the benefits

that are positive to a child's health, not detrimental to that. So I would like to say regulation that

requires technology manufacturers to give parents the ability to be able to to monitor to gate some

of that to direct some of that. You're also making a really important point, Paul, beyond the technology,

whether it's a job that says this level of content for this device or time limits or whatever.

You've got the parental involvement because we all know technology fails or is it end

around or whatever. Pick your catchphrase. It doesn't matter. You need that human judgment in

there. And you can't watch, you can't helicopter or but you can. You need the parental, but to your

point, you need the parental judgment, right? Like, yeah, if they're communicating with someone,

if there's an indicator that something bad is happening, a parent should get a notification of

that, right? And we have amazing technology today. And they're totally enabled that,

you know, triggering and monitoring for like, oh, like, communications going south,

like, creep zoid wants to go meet up with a child, that should be a notification to a parent.

We totally have the technology to give us those indicators to help those situations. And not

I know, not 100% of course, no technology is 100%. No, but you know, accurate, but we, I believe we

have the technology to help parents help children not become victims of a number of different things.

And by victim, I mean, not just talking to an adult and getting into a situation.

Something something pillars, something something basics, something something fundamentals.

The basics and fundamentals of security apply to so many different things. I was thinking of

parenting, but you know, parenting, it's the basics, right? But it's a fine line to a parent and

I've had the conversation with my kids about privacy and rights. And it's a fine line between

privacy and safety. Yeah. And we debated this a number of times on the show. In the context of like

your children and the internet, it's still like a fine line. You do want your children to have some

privacy and understand what privacy means, but you also want them to have some safety in how do

you, and how do you balance that, right? Well, some of it is education, but not everyone can

educate our kids and our family like we can. And I think that sometimes we run into that like,

well, everyone should just we should just monitor and educate everyone. But not everyone is like

us, like the three of us in so many listening that have worked in this field for more than 20 years

that can instill that knowledge. My wife just today, I got this email from Amazon. And she's

my account is somehow under suspicion, right? And I was like, no, it's not. It's not. Don't

click any links in the email and ignore it. Now, I've been doing this is not even as long as you

guys have. And again, many of our listeners can we guide our family on that all the time. But that's

not everyone. Not everyone works in cybersecurity news flash. People have all their careers and other

specialties outside of this. So how do we enable that for the masses? And the other piece in

there, I mean, you had the trust your wife had the trust in you to come and say this doesn't look

right. Right. Because that's a case that we've done. This is this is messed up dad. What the hell?

But you guys know, we've instilled that out of our friends and family that if they see something that

looks my even mildly suspicious, like just ask us, hey, I'm getting, I'm getting to the age where

I'm getting all sorts of, you know, things targeting me because I'm a senior citizen, which I

finally mildly humorous at one level. We're just also sickening that attackers prey on senior citizens.

Yeah. To your point. So philosophically, because, you know, when you began this discussion, you used

a language that was reminiscent of arguments against gun control, which is, oh, you picked up on

that didn't you? I did. Bill of rights, a second amendment is the gun control issue.

But in the balance of the discussion, I'm thinking more about, you know, a minimum age to get

a driver's license, a minimum age to be able to drink alcohol. You know, they're similar, but

different. And, you know, are there constitutional rights involved with the drinking age and the

driving age? I just think back to when I was a kid trying to get my driver's license, it was

instilled in me that driving is a privilege, not a right. Right. And so is the internet and access

to the internet and all the things that that embodies? Is that a privilege or a right? I think it's

I think it's different. I think each case is different. And I think it's the

technology you're based on the individual. I think I'm based on the use case. And I think

the way laws are either passed or ratified or rescinded depends on the use case and depends on

how much power we want to give the states in which case. And I think states have been given a lot

of leeway to regulate things like alcohol, tobacco, perhaps even driving privileges. In fact,

I, you know, having kids around that age, right, state to state greatly varies. How they get their

license, what kind of testing they need to pass. How long they have to have their permit

in Rhode Island. You have to be of a certain age to have so many people in the car to drive

after a certain time. And that very state to state. And so states have been given some leeway to

regulate the driving. The internet is like a ubiquitous thing that crosses many different

borders. And I don't know if it's treated differently. I don't know. There's a lot of

well, the access to the internet is ubiquitous these days, which I think

impacts the conversation. But back in the early days when you're paying for your phone bill

and long distance, or I even watched the kukuzeg Nova special the other day.

It's a great one because the cliff stole. Yeah, yeah, yeah. Talk was released. I'm like, I'm

going to go back and watch the Nova special again. And you know, 75 cents is what started all

that thing. A discrepancy of 75 cents in the bill. Not my point. The point being it used to be

really expensive to have the privilege of being on the internet. Yeah, where nowadays it's really

free because it's, you know, it's definitely free. In fact, it's hard to make young people understand

that it didn't always used to be this way. I mean, it's what spawned a generation of hackers.

Like, how can I get the internet without paying a lot of money? Right. I mean, that's what

the hackers were doing back. It was in early hacker stories, man. A lot of it is about

I need to steal. I need to get I need to steal to get access to the internet. And then they also

talk about how they're, you know, good people and they were not doing anything wrong. Right. Yeah,

debatable. It's debatable. It goes back to the phone system too. A long distance calls are

expensive. How can I circumvent that? Is that theft? Is that fraud? Yeah, a lot of cases. Yeah.

So it's unfair. But the thing we debate like was it fair for the phone companies to be these large

conglomers that are charging a lot of money for a service that we felt communication should be

accessible to everyone. What could say we have a similar debate with AI?

Right. Should we have large conglomerates that are gating this large expensive models that

could enhance your productivity in other things and only those that can afford them or only

those that qualify for a program can use them. Well, let me muddy the water even more for you, Paul.

Because you're talking about use case and determining whether access to the internet and all the

things that it that implies is a privilege or a right. What about things like personal privacy?

Privileged or a right? Reasonably safe and secure. I mean, that boarder is more on those

those concepts. Privacy is right. I firmly I will go on the record. I think they go back. I think

those two items can be traced back to the bill of rights. Yeah. And interpretation.

Privacy, I will go back to go on the record saying the US lags far behind. We've said this on the show

in the past. The lags far behind. And we go back to the classic example. And I think that

what really grinded my gears was when we learned, and I think this is this is well known

that instead of getting a something that looks like the something like the EU CRA or other,

what's the other EU privacy GDPR? GDPR. Instead of getting something like that,

we got the Patriot Act because September 11th happened. Well, and there's a lot of evidence to

point to that there was legislation that looked more like privacy rights for the US citizens that

got backed off. And then like we lost the battle. I think we're we're behind in terms of privacy.

So don't look it up. Cory, Dr. Rose, in certification, 100% read that book, listen to that book,

listen to Cory's, I listen to Cory multiple podcasts interviews with Cory on that. And he is spot on

in pointing out huge problems with our our digital privacy, specifically digital privacy rights

that we don't have in the US specifically. So when we talk about privacy laws or privacy act in

the United States, don't look it up. What year are we talking about? What legislation year?

2004. Yes. Give. Give. What's 1974? Oh, I was right. Yes, it is. The privacy act is 74. The Patriot Act did

some stuff and it fell away and stuff. But the the the base that's still there that keeps getting

pointed back to it 74. I'm kind of a why the hell hasn't that been updated? I mean, that's it's

it's it's found foundations are good, by the way. I can tell you what that was being because all

these companies make too way too much money. Look at the major tech companies to change. They have

too much money and too much control, which is a good sake a lot of money on our sacrificing our privacy.

That's a good segue and it's it's going to relate and because I want I'd love to get leads taken

this before he has to yeah, barbecue. My story number two is talking an article about 100 firms

getting together and doing an open letter about we need cyber defense. The actual open letter is

my story number three. So all that we're just saying into Paul's point these big companies

are making too much money. Now these big companies are going on record is we need to secure everything.

We need to have cyber defense. We need to everybody everybody to take care of this.

There's a word for that and I'm not sure what if I can come up with it. I was about to say whining,

but I didn't think that's the word you were looking for. No, I wanted a stronger word. Patronizing,

is that the word I'm thinking? Okay. Um, the meaning, I mean, the pot calling the kettle black,

it reminds me of apocalypse now. Have you seen that movie Paul? Do you remember that one? Oh,

Stanley Kubrick is one of my favorite movie directors of all time. Okay. So he's Tarantino before

there was Tarantino. That's a very true statement. It gives me new respect for Tarantino all of a sudden

because I think his movies are weird often. But I digress. In apocalypse now, there's a scene where

they're on the river and they come pass a family in a boat and you know somebody blinks and so they

just wipe everybody out with machine guns and then they hop on the boat and they find one person

is still breathing and they're like, oh, it's administer first aid in the captain, you know,

goes and, you know, mercy kills the person. We don't have time for that. To me, it's the same type of

thing. It's a little bit different. But, you know, all these companies have created this mess.

And now they're putting a public appeal out to say, hey, we need to think about security

for all of this stuff that we've created. I mean, we do need to, but I'm not sure this is the

right way to get there. I'm just skim through it and your comments on it. I mean, I've repeated

Italy scene, you know, the, you know, you get the newest patch reports have like, you know, they,

they, you know, are too big because they're using AI to discover and hopefully patch

vulnerabilities, except they're finding the patches don't always work.

But they're trying to move the bar, but what's happening is you get this huge influence of stuff.

And that's just from the ethical use. Then you got our adversaries who, you know,

yolo, let's just do whatever it'll do to go, go, go and kick down the doors and slash the tires.

Now you're, I'm going to get in trouble now because

what, everything, what you said I can pull on a thread specifically with a specific vendor.

And I want to pick on vendors, but, um,

Ford in that is like the shining example we just talked about.

Mm-hmm. Because they just had a situation where they released a patch and then

and it was a popular threat actor technique that they tried to patch, which is the simlink vulnerability,

which enabled persistence. And then they said, well, they bypassed that patch because it turns out like

a double slash instead of a slash bypass that technique. Now look, I get it. I've been in technology

a long time. I understand there's a lot of nuances. There's, it's fine. They released a new patch.

But also to monitor that for Ford in it, that if your Ford in it devices have like succumb to

this vulnerability, the number one technology that you can acquire is from Ford in it. It's

Ford to guard to monitor your devices. So Fordin it sells you the product. They say you should

monitor this for anomalies. By the way, you can pay us more money to monitor for those anomalies. By

the way we had a vulnerability, we thought we fixed it, but we didn't really fix it. And so you

need to apply another patch in oh, by the way, you can subscribe to this other product to monitor it.

Now again, I'm not throwing Fordin it under the bus. They're not the first vendor to create

software. They're not the first vendor to have vulnerabilities. They're not the first vendor to

create both software and defensive mechanisms. Because the flip side of that is

Fordin it actually is a good company in that they are fixing the vulnerabilities and allowing you

the to purchase the technology to detect those intrusions as well. Yeah. So I think you could take

either side, right? So again, I don't want to throw Fordin under the bus, but it's one of those

scenarios where different vendors may do it differently. I'm not saying don't go buy Fordin it.

I'm not saying that. I'm not saying you should buy Fordin that because of XYZ. I'm neutral on that

on that point. But all these things got to make you wonder like how do I monitor my environment

moving forward? How do I effectively patch, mitigate, and monitor all of these different

scenarios? Do I trust one vendor? Do I have multiple vendors? If you look at any Fortune 500

company, they have more than Fordin that. Also, you could also, I'm going to, if I'm

signing with Fordin that, I'm going, if I'm a huge Fordin net customer, I'm a Fortune 500

company. How much am I really paying for that Ford guard subscription? I don't want to speculate,

but I'm just saying, you're going to negotiate that. My experience, I'm not speaking for Fordin

or anyone who has Fordin at product, but if you're negotiating that, you're like, yeah, I'm spending

this much with you. You're going to give me this product that helps me secure my stuff at a

deeply discounted or probably zero rate to help secure my stuff. So I think there's more positive

negative in that scenario. But the point you bring up, Lee, is like, who's watching the watcher?

Right. We have all these technologies. Who's watching the watcher?

So, but really, when it comes down to this whole thing, is I think there's, and I've got to go

in a minute here, is that, I mean, if you're sitting there in the cyber, you don't panic,

just go cyber hygiene and defense in depth are still valid response to threats for AI.

Then on the other side, you have, we've talked about AI governance to or blue in the face. That's

really a thing when it comes to how it's impacting your environment and how it's being used.

And the third thing, we do it, we stay educated. Get up on it. I mean, I just had a guy

write to me that he had a talk he could give for for my local ISH chapter. He's calling AI 101,

the basic things that everybody should be doing when it comes to AI. You need to be educated.

Now, you may have it. Fine. Good. Go forth and be process, but not everybody does.

It's stuff we know and we know how to help people do that. We got to start there,

but I don't think people should be panicking or say we put the genie back in the bottle. That ain't

going to happen. Right. I mean, it's stuff we've talked about for years. It's just going faster,

but we can still, we still have to survive.

There is a there is this concept of the probability of doom when you come to AI,

but I generally agree with you, but I just I mean, also, look at Cisco. I mean, they just had

a couple of advisories that dropped yesterday or today, right? XR software got a hardening release,

which is interesting after we had the fire and campaign that was targeting, I believe XR

based router switches. I think that's a switching technology. I didn't put in this

episode of full breakdown of Cisco's product lines. What they are and what the underlying

you know, OS is on them, but first by the so Jeff, they had an iOS XR hardening advisory,

which I thought was like a supply chain thing, but turns out actual vulnerabilities in Cisco XR

or technology. This one, they claim they used a frontier model. So it's like this Cisco,

but what I do is mythos saying they found a pile of iOS XR bugs in our shipping abroad hardening

release. It's in the control plane. No configuration work around. It is Linux native. So Linux runs

like the hypervisor, but it's still at the end of the day, a Cisco router, which is interesting.

There's a whole other layer for your research on Linux hardening configuration. They also had

my story number three, nine thousand series switches, which run an XOS, which is essentially a

Linux backed operating system from Cisco. They had a remote remote code execution vulnerability

in their data center switch software, which is an XOS. And it's interesting Cisco says

they're not aware of public exploitation. However, when you in Cisco publishes this like Cisco says,

are you they state, are we seeing this exploiting in the wild? No. How did you learn of this vulnerability?

And sometimes that's an internal team used a AI model, frontier model. Sometimes they say that,

sometimes they say something similar. We used an AI model. We found this vulnerability and fixed

it fine. But in this case for the NXOS, they say we discovered it via a attack case,

which is Cisco's like support when I worked at university. We had a problem with Cisco software. You

open a attack case, you get help from an engineer. That's suspicious to me. Did they learn of a

vulnerability that they fixed from an active support case? Is that because the vulnerability condition

was triggered not because of a breach or a threat actor? Or it was some other condition.

I think more likely than not, if they're learning about it from attack case, it's because there

was a threat actor that exploited that vulnerability, call some kind of adverse condition, reverse

engineer and go, oh, there's a vulnerability there. So from my story number four, iOS XR,

I think that was a vulnerability discovery with AI from Cisco that fixed a bunch of stuff in

their code, which is fine. I don't knock again. I don't want to knock any vendor for the

Net Cisco or whatever, right? Great. You found vulnerabilities, you fixed them, you were

these patches. What I question is my story number three, where switches basically were listening on

these ports 43, 210 and 43, 211. Those are two of the reserve ports on the guide. Yeah, like

listening on ports and their vulnerabilities there. And these vulnerabilities came from attack case.

I wouldn't be surprised if this ends up getting added to the Cisco. Right, after that, right?

Well, that will be proof. The proof in the pudding as it were.

Yeah. Lee and I fortunately had several overlapping stories. So I don't feel like we'll miss him.

Well, we'll miss him. But we'll try to do justice to some of his stories. My first story,

which he also had was in reference to paper cut, announcing that they had several vulnerabilities

with CVEs issued that particular article that I found. What is paper cut?

It's a paper printing management service, or something like that. There's more of a description in

Lee's article because he provides the summary where I was focusing more on the vulnerabilities.

Because I saw in the title of my article, the threat actors were chaining together vulnerabilities.

I thought, oh, this will be a good example to hammer home to my countless clients that I warned.

You got to fix your lows and mediums because they can be chained together very often to

produce an attack. So when I was reading my article and I actually clicked on the CVEs to see what

they were. Oh, one's a critical enterprise. So paper cut, ng in paper cut, mf,

are self-hosted enterprise print management platforms. What can go wrong? What can we build a

security of printing? Right. Is pristine over the years. And if you've worked in InfoSec

for a day or 30 plus years, you know you're laughing right now.

Printing security is terrible. Right. Yeah. And you had me go out to be a security

influencer that wasn't the where we used 10 years ago. You sent me out to HP. Yeah, yeah, yeah.

It wasn't. It was HPE. They're the ones that do the printers. Or they're no. It's the other.

It was HP. It was HP because that's a plug at that point. So yeah, I was learning all about

printers and they were, they did a demo where they were going out and pulling all of the

their own printers that were reachable and showing how many of them could be easily compromised.

Like sure. Shouldn't be doing that. I think it's one thing we like to throw shade at vendors for

security faux pas, if you will. Right. But if you're running the latest models with the latest

software, a lot of times you're in a much better position. Right. So like years ago, how many years

ago was that Jeff, you went to HP and you sat at their headquarters. I want to say there's at least

10 years ago. Yeah, like 10 years ago. Right. So they're hyper security of, hyper aware of security

on their printers 10 years ago. Right. Which means like the newer models are learning from models,

not AI models, but newer models of their devices and their software have learned from that. And I've

seen that with again, like I threw a little shade at Fordnet, but like modern Cisco, Fordonet,

HP insert any other large vendor. Right. The latest hardware, the latest software I find has learned

from many, is it infallible? No. Is it much more resilient than previous versions of said hardware

from a software? Yes. So there is a, there's a silver lining. Well, I think in a lot of this,

right? Yeah. There's certainly been an evolution in terms of things that worked 20, 30 years ago

from the software and from the hardware and the operating system perspective. There've been

improvements. The same things, you know, right. We were talking about set UID scripts earlier.

I, you know, there's not that many of them out there, at least like there were. No, that's still a problem.

Here's it's still a problem. Yeah. But, but back when I was learning, learning the craft, you know, 80%

or any 80% of the executables on Unix were sent UID. Yeah. It was just, no, I agree. Linux Unix,

they've learned from that mistake as well. Hardening by default, making more

resilient software. But I think it's what, you know, the old t-shirt we used to have, you know,

we drank because you don't change your default password. Yeah. That's a 15 year old t-shirt now.

Yeah. But it makes, it makes those fundamental basic things that people don't do that much more

frustrating. I think about this problem as people have, but the problem is people run older stuff.

Mm-hmm. And so many times on the show, Jeff, we talked about how the newer versions of the things

might be more secure, but the people still run the older last year. Right. But, but what I'm saying

is going back to your, your tech segment though, is there's so much not being done. There's so

many fundamentals missed. The one article you were just talking about, the iOS vulnerability, I think

was that one where one of the vulnerabilities was a default credential. Yep. You know, those,

those basic fundamental things that get missed a lot of times because there's a presumption while

we're just going to move to the latest version, the newest version. I, I have seen a presumption with

my clients over the years. If I'm using it, it must be secure because somebody's looked at it,

somebody's vetted it, somebody's hurt it. It's not my responsibility within the organization,

but I wouldn't certainly wouldn't be allowed to use it. I've gone through it. I see, but I, I think

there's a scale. Mm-hmm. It's interesting. The more higher security maturity organizations

distrust more vendors and what they're getting more. Yep. So then organizations that have a less

security maturity model. Yes. Right. Like when I go to the Fortune 50, largely financial

organizations, they greatly distrust anything they get from a vendor. Right. But as you move down the

stack to smaller organizations, I think because maybe that's because of lack of resources,

they like inherently have to trust what's coming from the vendor as secure. That in that, I've

never verbalized that before. It's interesting, Jeff, you you triggered that that thought process

in my brain. Well, this is why I was looking forward to it. You and I just bantering for. Yeah,

like that's really it is. It's, I think it's the bane of both of our existence, right? Like,

oh my god, like if you're a small organization, like you can't trust anything that's coming from

any security vendor, because it's not secure and yet secure organizations do trust you do because

they have to, right? It's not because they are scrutinizing everything and going, yep, I trust

that because I valid I trust but verify. Hmm. They're trust because I have to because I don't have

the resources to validate. Right. You go to Fortune 50 and they go, well, we have a lot more

resources and guess what? When we try and validate that, we're like, I know, like I've worked for

in you and I both have worked for major cybersecurity vendors. The larger customers you go to,

the higher scrutiny they have, they will scrutinize your own software and go, hey, like you're

delivering me this cybersecurity software. And if it's not compliant with this and it's not

doing this and it's not doing this, I don't want to my environment to make changes,

right? Make sure that it's resilient enough to use in my environment, right? But that's like,

again, like the Fortune 50. You go outside of that and that bar, the further you smaller organization

you go to, the less scrutiny they have. Out of curiosity, why do you go Fortune 50 instead of

Fortune 100? Do you think there's that much of a drop off? It could be. I'm just out of curiosity.

Because it would be a, but you know, that would be a good,

where is that? As much as I hate surveys, Jeff, I would love to have like a research,

air quotes research, right? Different kind of research, but a research organization.

See Array had one of those others, right? They would like give a questionnaire to companies

as to how they scrutinize their vendors. You know, I think we would see differences.

And at the same time, measure them on size, air quotes. In some, yeah, I think there would be

differences as to how you scrutinize your vendors between Fortune 50, Fortune 100, Fortune 500,

and everyone else. See, I'm more curious to know where the,

where the thresholds are between, you know, I'm assuming it's, I mean, everybody knows the

enterprise at the top, whether you refer to Fortune 50 or the mythological enterprise.

You know, but one that all the vendors are selling to, that organization, that use case,

you know, our friend Wendy, neither, I, you know, I guess she coined the term, the,

the, oh, the poverty line, the, the cyber security poverty line. I bet I will bet you it ties

very closely to not just revenue, but maybe profit margin of these companies. Yes.

And also, I think vendor scrutiny, right? Like if you were to take all those data points,

you, there would be an interesting study. It would be an interesting study. And I would also,

because it's been a while since I did this, but I have on more than one occasion looked at the

Fortune 100 and gone through it to see whether it's a company that's subject to PCI or not. And yeah,

like I said, I haven't looked at the, who the Fortune 100 is in a couple of years now. But when I

had done it probably five, it's probably before COVID, because everything was before COVID.

The last time I did it, it was like 95% of the companies had at least a branch or division that,

you know, accepting credit cards. They were selling something and there was credit card involved.

You know, it's not just retail. It's not just what I used to tell our previous employer.

This is not a retail thing. This is also insurance companies, hospitality,

hotels, you know, oil and gas companies because they own gas stations, guess what they,

you know, how they accept payments. I have this theory that all this critical infrastructure

we're talking about, like even the water companies, the water utility companies, most water

utilities are just, you know, power utilities, that particular critical infrastructure category

that I'm aware of allow their consumers to pay their bills with a credit card,

which means PCI is in there somewhere. Now they might have, you know, descoped and outsourced

to third parties and minimized it. Oh, you and I both know they did that. But, you know,

there's all this clamoring for, you know, regulation and scrutiny and attention and who's going to

take responsible responsibility for these types of organizations. I'm like, yeah, we don't need to

reinvent the wheel. They've got the PCI standard in there somewhere if they would just use it.

What I'm interested in doing more research on or talking, having more detailed conversations

with people that are actively involved with OTE is do the fundamentals of security, which are

outlined in the PCI standard. Do they apply to OTE or do they not? Where how do they vary? How do

they shift? Because we know that they, we know that they still apply to IT, the jury's out on AI,

but like what Lee was saying, it's the same stuff just faster. I still am operating on the belief that

the principles, you know, what we argue is the fundamentals of the foundations, but the,

you know, the analogy that I've been working on because I want to turn this into a talk is,

if you think of building a building, you know, like I think about back when they were broke

ground on the house that I live in now, they didn't just show up and just start digging a hole in

the ground and start pouring concrete. They had a plan. And, you know, so we talked about regulatory,

yeah, regulatory compliance to meet. They had rules and permits and everything was regularly.

Other checks and balances they had to go through before they started.

Right. So there was a lot of stuff that went into digging the first hole. Where did you dig it?

How deep do you dig it? Laying out the forms where the foundation was going to be poor.

So we talk about the foundation and we think that's the basis. And I say, but there's so much that

goes into it before you pour the foundation. So I think there's analogy there to what I'm

in trying to say about cybersecurity is there's so much stuff you have to think about before you

actually go out and start buying all the technology and listen to the vendors you're not or trust them

or not, put all the stuff in place, have some sort of clue about what you're trying to accomplish.

I think there's an interesting, speaking of winning the other research, right? Like in the

Security Poverty line, interesting intersect between the trust level you have with your vendors

overlaid with how large you are and where you are on the Security Poverty line.

Yeah, because I think in terms of security maturity, you are the greater you pay attention

to scrutinize your vendors. I've never thought of it through that lens. Like the most security

mature organizations do not trust anything that comes from any vendor. And then like as you move

if you will down the stack of the less security mature organizations have this propensity to go

like I basically have to trust because I don't have the resources to verify. And that's

that shouldn't be the case, right? Like I think we should all be, it should be a commodity.

We should all be able to verify and then trust and we shouldn't have to or know that some regulatory

body has done the right, you know, like the UL label on appliances type of thing.

I got to talk about that. I don't have a team like a lot of you talk about OT, right? I know there's a lot

of OT, critical infrastructure. The larger ones have a team that does the security research

and reverse engineering of every device that comes in their environment. Well, not every organization

has the resources to do that. So that has to be if you will federated so that we can have some

external stamp of approval to go. These devices are good. We validated them. This one in

there's a tier. There's a marker. We've talked about cyber UL like a marker.

Yep. These are more secure than the other ones out of the box. Yeah. I deal with that a lot

of my day job, right? Because we get into things like firmware. A lot of organizations just want to

trust that firmware is good because they don't have the resources, the tooling to validate that

what I'm getting from the vendor from a firmware perspective is I think you're being generous.

I think they are primarily concerned. Does it work? And they hope it's secure if they even think

about that at all. Does it work? What I mean, cost is probably the number one. You wouldn't have

both no costs to the number one. Is the cheapest solution? Is the first criteria? The second one is

does it work? Right. Like how much work do we need to put into make sure it works? And then like

security integrity, all that stuff is definitely third or later in their decision tree.

Yep. Which and I finally came up with the word I was looking for for this open letter from

all the tech companies. It's sanctimonious, self-righteous. Hey, we thought we just decided we're

going to put it out there that all this stuff that we've created and the problem that we've

created. You know what's interesting? There were two stories this week that dealt with Android

TV supply chains. And it speaks to the, I think one of the things we're speaking to Jeff is

the economics of it all. Right. The more affordable a device is, it quates to sacrifices in

the security and integrity of the device. Yep. And this really does translate to

entertainment. And I know this doesn't translate to necessarily like enterprise

companies and software. But let's just put this in the lens of your consumer.

If you spend a lot of money purchasing an entertainment device, I think you have a higher

degree or probability, higher probability that that device will maintain its integrity and security.

I can speak to from experience. Invidia makes outstanding entertainment devices.

They are on the higher end of the price spectrum, probably the highest end of the price spectrum.

However, they are one supported for a really long time, implement great security controls,

and are largely free of a lot of this malware that two of my stories are talking about.

As you march down the in the price point, and so let's say the Nvidia device is $300 on average,

wherever it is, when you go to like the $25 price point, you're getting a seemingly functional

device. However, the security is so bad that malware is baked into it. And so my story number three

is a $25 Android TV box that came pre-owned with malware. Or as technical also covered

a device of a similar price point, I don't know what story that was in my stories,

but our technical also talked about a different device that's basically the same thing.

Basically a cheap device that you're a part of a botnet.

I go back to the movie one or was that the first one in your dog?

Free one. What was the free the free movie one? That's your story eight. Yeah, my story eight is

the free movie one. So R said that plume research showing that a super box media streaming device

in similar Android TV devices turn home networks into residential proxies and malware delivery

platforms. The other one is an independent researcher that much like I did validating other

people's research. They're still implanting malware in these cheap Android TV devices.

These didn't come from Amazon, they came from eBay and a number of different sources.

And some of them advertise like, oh, like free media streaming access to things and

teasing users to go, oh, I want to buy that. And the reason I believe they can offer that at

the lower cost is because indirectly, maybe the manufacturer, maybe not, someone is profiting

from the fact you bought a $25 device. It comes with malware. And some threat actor is profiting

from that because it's part of a botnet, right? Which is just unbelievable to think about.

And we're really clever. Depending how you know, it's clever. But what frightens me is this

still going on. Like I wrote about this a few years ago, two or three years ago.

And what I was writing about had been happening probably two years prior to that. Right.

So we're going on five plus years of basically, I go on whatever shopping, wherever I want to buy

my TV streaming device. I get a TV. I don't like what's built in. I want to add some other device.

One was the last time you technically bought a TV. Not just a monitor. They're all smart today, right?

Yeah. Yeah. And in some of the TVs have succumbed to this as well. And again, it kind of speaks to

the lack of regulation we have here in the US to combat these kind of things. One was the last time

you got your TV channels over the air. And a lot. And then they're praying upon. They're playing.

We used to talk about cutting the cable. Yep. Right. Yep. We don't want to pay cable. And instead of

paying cable, I pay for internet. But in order to get media, I have to buy Netflix.

Well, I was referring to before the real cable. There was broadcast. Yes. Right.

But I digress. That's going way back. Like when I used to watch Star Trek, it was an analog signal.

An analog signal. Which still you can get over the air today as well. But have that library of

stuff that you consume. So some of my stories double back on things that we've been talking about

already. So we're sort of, I feel like we're bouncing around. But what the heck?

My one story about that. I have to go pee. Yeah. We're right back. All right. I'm going to do a

soliloquy now. Yes. And Paul doesn't get to argue with me. My story, which was the number

one story about the paper cut. Where I was going with that story was they talked about

chaining vulnerabilities, which is something that pen testers and hackers have talked about for

years, your people that are involved with vulnerability scanning companies, which is Paul and I have

been doing for years, or we used to years ago. The idea that you want to address not just the

critical and high vulnerabilities, but also address the medium and low. I'll throw PCI in since

Paul's not around to stop me. PCI in version four, which came out a couple of years ago,

makes companies have a remediation plan or an action plan for dealing with the mediums and

lows and informational findings. They don't stipulate how soon you have to address them. They just

want you to have a plan for addressing them. And it's got to be a number. It's got to be a

sum amount of time. And it has to be based on what they're calling a targeted risk analysis. So

since the very beginning, critical patches that address critical vulnerabilities have had to

have been installed within 30 days and everything else was kind of falling. And after that,

you know, highs were 60 mediums, maybe with an 120 lows, if we ever have time, we'll be around to

a type of thing. And interestingly enough, the PCI standard was based on the patches being

available for the critical vulnerabilities. The action that was usually taken from my clients

was on scan results, your pen test results, where they had a vulnerability and they needed to install

the patch. The first problem with that was I'm still a little equalizing on the way people don't

deal with vulnerabilities if they're lower rankings. Because I'm back to this paper code article

they said the bad guys are actually targeting victims by chaining together these two vulnerabilities.

And these two vulnerabilities turned out were only released back on August 28th. So they've only

been around less than a week, at least from the publication of the CVE. And one's a critical and

one's a high, which need to be addressed anyway. So I thought this article was, you know, I wanted to

use it as an object lesson for you got to address all the vulnerabilities, but I'm like, wait a

minute, they would have to get, they would have to deal with, you know, whoever's using this stuff

has to deal with the critical's and highs. Anyway, you know, assuming that there's a patch out there.

You don't need to comment on that. I can leave it stand the way it did. The other story of mine that

I wanted to point out was my story number six, which is a lotter co-op they called it, you know,

getting back to the whole, you know, critical infrastructure discussion. And it sort of underscores

the what I was saying earlier about companies don't do anything unless they have a really bad day.

Apparently, this company had a really bad day. So this article is talking about the out there.

They're going to really increase their cybersecurity and physical security because they had a really

bad day. That's much more than norm in our society rather than, you know, all these water companies

are out there. They're doing the right things, spending a lot of money that they can't afford,

billing the clients or not or, you know, the government's intervening and underwriting some of

the stuff. That's not the article we don't that we usually read. It's they had a bad day and so

they're making changes. What the changes are, who knows. And they're doing it primarily because

it's how they're going to get off the hook for whatever regulatory thing that they might fall

under. I'd still love to find out if there is anything cyber security specific, but more likely

than not. It has to it's it's happening to address the litigation. It's coming against them.

So, you know, it's interesting, Jeff, we talk about vulnerabilities and remediation

in like of specific vulnerabilities, but oftentimes this is my story number 11 highlights.

This isn't the first time we've highlighted this scenario where

for gotten infrastructure has led to attackers being able to conduct successful attacks.

Right. And I think this manifests itself in a lot of different scenarios that we've talked about

over the years. And you it kind of speaks to like you could patch and remediate everything, but

one of those I like to call them dusty corners is you haven't reclaimed or or or like managed all

of your infrastructure. And I think this problem grows over time as we amass all this infrastructure.

We moved a new infrastructure. We forget about the old. And so this this took place in the UK.

In the core issues is basically old telephone routing infrastructure was still pointing at a

domain that no one renewed. And so enum is a facility for basically DNS for phone numbers. So

phone number can be turned into a DNS name under e164. Which is ironic because DNS we used to

describe is a phone directory for the internet. Right. So it's come full circle.

So that you could query and then go, Hey, where does this number route to inquiry DNS and route

that over IP rather than routing it through the phone system network. So you could route it over

VoIP rather than the phone system network. So plus two four six becomes the DNS zone. And then

you would query that zone to figure out which which phone numbers and where where route them.

So they found that three of those zones delegated to older name servers. Those zones mapped to

various locations. One name server was no longer resolved. And the backup name server was called

enum.org.uk, which was a domain that expired. So the researcher registered that domain for five

euros. Gave them control over anyone looking up phone numbers over DNS to route those over VoIP

essentially. And so if you queried, so let's say you're a carrier that was like, Hey, where

should I route this phone call? You queried DNS. Now an attacker, in this case, fortunately,

was a researcher when an attacker could say, Well, that record doesn't exist, which would force

the carrier to route that over traditional telephony, which would cost money. But you could also have

a malicious server answer and say route any of like look up any phone number that resolved to

that top level domain route them to my sip server. And then your sip server would route them to

the real destination that could snoop on that call, potentially interrupting or intercepting that

call data. So they set up one of these servers, but months later, they thought they first set it

up and they were like, Oh, this doesn't reveal any data, but then months later, they realized they

had a whole bunch of data, including reverse phone number, time stamps, and resolver IPs. And a lot

of these were tied to like military installations. So even that metadata could be sensitive.

Right. And gosh, I forget what the term for who you just referred to as metadata, all the

information about a phone call, the call log. Yeah. I mean, that is similar. I mean, it's similar

data that I had a different name for it. Because when I used to work for the frying company,

you know, that was the type of information that, you know, the phone company had, but the

government or the law enforcement would have to go through hoops and get warrants to be able to

get access to that. And it wasn't even the country. I remember that from the movie, the snota movie,

right? About the Patriot Act. In post September 11th, time frame, the Patriot Act through

loopholes like gave them the NSA, I believe, capabilities to collect.

Well, yeah, I mean, who at what time? It, you know, in the theory, NSA never used to do that,

capturing all that data, although the phone companies did and have been doing it forever,

and was the Patriot Act that gave that capability. And the loop hole was they created a law.

And in the FISA courts, right? They didn't. Well, that was part of it. It was the

five, it was the five, they could just go to the FISA court and they would say, yeah, go ahead.

Right. And it was, and again, I forget the term, but it was sort of a standing, yeah,

you can do this as long as you have a good reason or reason to write some kind of a little down

or probable cause, but it wasn't an official warrant in this a separate process. But,

and I don't know this definitively, but what I had been told at the time was NSA was capturing

the similar metadata. They were not recording all the phone calls. Correct. But they could go to

the court and get a warrant and start wiretapping. So they weren't based on evidence they collected

that was out from the metadata, right? Right. From the metadata, right? Yeah. The way that was

portrayed in one of the movies about the Snowden leaks was there was like a famous scene and it

looked like they were in a basement. And I think it was the character who portrayed Snowden was like,

wait, you're just collecting telemetry on everyone's phone calls, who may or may not have been

involved in any terrorist activity, which was like there was the terrorist. And there was people

communicated with the terrorists, but there was people who communicated with the terrorists,

they communicated with other people. Right. And it was those communications with the people who

communicated with the terrorist in anyone else that they were able to get those call logs for.

And then they could go and collect that phone call. So like, let's just say you and I were talking

Jeff in in our contact list with someone who was suspected of a terrorist they could collect our

not to say Larry. Yeah, right. Like, right. It gave them it. I think I think it was Obama who

eventually realized that was overstepping the bounds and peeled back that level of monitoring.

Yeah, I mean, it's highly debated in our industry, whether that was

pro-projects. I'm sure we know people that know the definitive answer, but they're sworn to secrecy.

And again, that's from the movie. Right. I mean, there's a certain amount of

well, well, let's just put it this way. In this article, if you can intercept that

in through the means we talked about and collect that metadata about who's calling who at what time.

That is a lot of evidence. Yeah, let's just say that hypothetically,

there might be a lot of information out there and a lot of people talking about scenarios like

of this and how it works and what kind of details. And some amount of that information might be right.

And some amount of that information might be wrong. And certain agencies that might care if

it's right or wrong, they're more than happy to let the wrong information take center stage.

Wrong information dictate who's captured and taken into questioning. No, that's how I'm saying.

I'm saying they're they're perfectly happy to let all the conspiracy theories run around

rather than well, the truth is out there. Somebody picked picked up on us, you know, it's like the old movie

the Pelican brief. Yes, you know, similar to that, somebody just kind of putting

connecting that out is putting two to two together that nobody would have ever suspected that

they would do that. That's to watch all the all the old movies are so relevant. Yeah. What today,

we mentioned Pelican brief. What was the other one we talked about today?

Apocalypse now. Apocalypse now. Yeah. Maybe we go back and watch old movies, Jeff.

Hey, next time you have all the cigar buddies together, let's make it a movie night. Perhaps.

I see a lot of clips off topic, but I see a lot of clips from 70 sci-fi portrayal of AI

in how that comes to fruition today. Even we could go, you mentioned Star Trek earlier, right?

Right. Like TV shows as well and their portrayal of AI and how that means something so real today,

above and beyond what it did 40 or 50 years ago. Yep. Well, and you challenged me several months ago,

or you asked me, you know, how much AI is in Star Trek? So I've been working my way through

the original series. There's a lot. There's a lot. And you also asked me, or somebody had asked me

when we were talking about it, whether there was food replicators in the original series.

I've seen two episodes where they're there. They don't call them replicators.

It was kind of like a, but the writers didn't know what they had. I think at the time. But the

technology was there that the easy way to do it. They didn't know how much of a prediction that was

in terms of the AI we used today. Right. And maybe they did. I don't know. Maybe they maybe they

did have a like some days people are going to look back on this and be like, wow, that's reality.

Well, they certainly had themes. And I mean, that's one of the beauties of science fiction is

dreaming about the future and what might be. But the, my favorite, most people's favorite episode of

the original Star Trek is the trouble with Tribbles. And in that episode, the guy that was the one

that put the Tribbles on the space station in the first place, forget his name, big heavy-set guy

wearing fur. Because it's like a trailer. I remember that. When they're having the big bar fight.

Yeah. Yeah. Yeah. Yeah. He's over at the bar, punching buttons in the wall. And the thing

opens up and he's pulling out all sorts of cocktails. That's a food replicator. But they call it

something else. Right. There's another episode that I saw that that had that. Yeah, that is a

digression. But a, well, and I actually, I messaged this open letter. I saw that got the Evrons

company is not, not, is not listed as one of the participating companies. But Bug crowd is not

the KC Ellis is involved anymore directly. But I messaged both of them. We're on a, we're on a chat

together. And I said, what do you got? What's your guys take on this thing? Because again, I think it's

kind of sanctimonious for all these companies that have made gazillions of dollars in our

positioning themselves to make gazillions of dollars off this technology.

Putting out a call to, we need to secure this and they're calling government to do it and they're

calling for essentially personal responsibility on behalf of companies and a couple other

thing, you know, public citizens and things like that, which is interesting too because, you know,

we haven't talked about it in depth for a couple of months either. But the, the national cybersecurity

strategy, rather, you know, has seven bullet points. And one of those, at least one of them has

to do with deregulation and making the government less responsible, but also taking away a lot of

the regular regulation that companies have had fall under from a cybersecurity perspective. And

that just does not coalesce for me, you know, governments, the government saying, yeah, you can

essentially do what you want. Don't have to worry about cybersecurity regulation where we've

been talking about all evening, the need for, and, you know, many times on the show, the need for

some sort of regulation, some, you know, some testing firms, some independent third party,

third party to put the seal of approval on it. Somebody's got to pay for it, probably not

private citizens, probably not corporations, you know, usually that type of thing falls back to

the government, at least to seat it. I don't know, United Laboratories, age, they still exist,

and where did they get their funding from originally? I want to research. But that's the type of thing

where, you know, all these companies are going to feel really good about themselves because they

put out a call for, we do increase cybersecurity, but they've created the problem in the first place.

But it's interesting, though, when you think about AI in, in, in this context,

many of us internally as you observed, Jeff, I've been talking about how the various AI

companies have been gating this technology, putting up guardrails. And I think that's largely

a knee jerk reaction and to a detriment of this technology. We talked about software being free,

technology being free. It's very much not that way with AI in that certain companies have access

to mythos. If you've got a large budget, you can use large models like Fable 5. But if you're,

even if you're validated in the cybersecurity programs for anthropic in open AI, like I am,

in many of us, we still run into guardrails. And that's limiting us in the capabilities

to use AI for defensive postures. For example, found a new malware sample this week.

And I was like, Hey, I want to someone wrote an article, said, this malware does XYZ.

Here's the malware sample. And I analyze it in as a XYZ. And I'm like, I want to believe you,

however, I want to validate that. That this malware does whatever. In my case, it was like,

does it touch you if I or do a bootkit? And when I went to run it through anthropic models,

anthropic was like, no, no, no, you can't use me for doing that.

And I went to open AI's models. And I was like, oh, happily, I'll do that for you. By the way,

open AI's models were like, I don't think it does XYZ that the researcher claims. And I'm like, well,

now I need to develop detections for this, right? And I need to validate this. So I'm like,

now basically I have to employ my teams, either myself, if I have time or my resource teams to go,

we need to determine what this malware actually does. And by the way, inthropic put up guardrails,

we can't use anthropic for that. So we have to use some other model. I think it hallucinated,

perhaps in the original research that was publicly available says that it did do that.

So now I don't believe either. I'm like, we need to go validate it manually. But why can't we,

we should be able to use any AI model to do this work? I'm not doing anything nefarious. I want

to develop detections for it. I want to help defenders identify the malware, identify the behaviors,

and detect it. And we're limited in that case. And that is a direct contradiction to the

freedoms I think we should have with software. So should the government step in and have regulations,

Jeff, as my question, as to how we're using AI? Is it a privilege or a right or right? And it does

does it require regulatory oversight so that it's not abused? Correct. That's kind of the story of

there is a high probability that people are going to abuse it. But there's also a huge benefit for

using it in the right way. And how do we tell the difference and how should regulation

mediate that relationship that we have with AI? I mean, if you think about it,

maybe this was a stretch of an analogy. If you kind of think of it as a,

a, a, a, a.

It's the best way to phrases. Like a, you know, like a generation ago or generations ago.

You know, oil digging it up out of the ground gave natural resources. If it's like a, a natural

resource, but in internet speak, you know, there's going to be some companies that tap into it and

and make gazillions of dollars and we're seeing that they're going to be the next mega

huge companies.

But all of that requires some sort of regulation that comes in from governments.

But if you go back far enough in time for natural resources, I guess that's a term I was

looking for.

If AI is becoming a natural resource or similar to a natural resource, like the internet,

I mean hundreds and thousands of years ago, wars were fought over natural resources.

So, where are we, what's that look like in modern terms and hopefully we're not going

down a path of yet another world war because I think I grew up in the Cold War, mutually

assured destruction is kind of the thing that got hammered onto me.

I think we're kind of still in the same boat, but it's like that probability of doing.

What's the chance that AI is going to someday cause a civilization terminating event and

whether it does or not, I don't think it's going to be the AI directly like terminator

movies, that brand of science fiction.

I think it's going to be accidental use of it or accidental like, like, or seen orientation.

Like, or seen already unintended consequences, which is another theme of another genre of

science fiction movies, 100% that talk about AI.

Good times, good times, good times.

With that, thanks everyone for listening and watching this edition of Paul Security Weekly.

That'll do it for this week over.

End up.