You found the backup wrap up your go-to podcast for all things
backup recovery and cyber recovery.
In this episode, we'll explore the critical concept of minimizing the
blast radius of a cyber attack.
Once again, we're joined by cybersecurity expert Dr.
Mike Saylor.
We'll talk about implementing lease privilege, access, network segmentation,
controlling outbound traffic, and other ideas on how to reduce the
impact of your next cyber attack.
By the way, if you don't know who I am, I'm w Curtis Preston, AKA, Mr.
Backup, and I've been passionate about backup and recovery for
over 30 years, ever since.
I had to tell my boss that there were no backups of the really
important database we just lost.
I don't want that to happen to you, and that's why I do this.
On this podcast, we turn unappreciated backup admins into Cyber Recovery Heroes.
This is the backup wrap up.
Welcome to the show.
Before I continue, if I could ask you to press that subscribe, like
or follow button so that you will always get our amazing content.
And I am w Curtis Preston, AKA, Mr.
Backup.
And with me, I have my very expensive chair disassembly consultant.
Persona.
Malaiyandi how.
Are you upset that I am returning my very expensive chair?
Are you saddened?
I am not, because chairs are one of those things that are very subjective
and what work, what works for one person may not work for
another person, So I get it.
those, those that listen to the podcast regularly know that I
recently purchased a pretty, for me, pretty expensive office chair.
I.
From Crandall office Furniture, not a sponsor.
Um, and that, uh, as a very nice chair, it was actually a Steelcase chair.
And, um, I think I spent like 800 bucks on it, which was, you know,
a lot of money for me for a chair.
And I did it all
Not, not, but if you think about,
what,
yeah.
Well, two things.
Yeah.
Your existing chair would constantly squeak, especially if
you go left, right, left, right.
like this.
Oh, I can't hear it anymore.
Yeah, well, maybe I better mic placement.
I don't know.
The first is, yeah, the squeak.
And then what was the second one?
Oh, if you think about the cost per hour of buying that $800 chair and
how much time you sit in that chair,
Yeah.
And.
a penny
a
It was a $1,200 chair that I got for 800 bucks.
But, but anyway, Crandle was great in terms of, I'm like, listen, I,
I just really don't like the chair.
They were great with the return policy, so I'm very happy.
But disa assembling it was quite the chore.
Um, so, uh, on, on a completely different note, non-sequitur,
my favorite Latin term.
Uh, we're gonna be talking this week about minimizing the
blast radius of a cyber attack.
And once again.
Fans of the show will recognize our guest today, Mike Sailor.
How's it going, Mike?
It is going well.
How are you guys?
Doing well, doing well.
Doing all right.
I'm back.
would get a bit new chair though.
I'm back.
I'm back to my old chair, which is, which is for me is fine for now.
But, uh, what, what do we, what do we mean, uh, Mike, when we talk about
minimizing the blast radius of an attack?
Sure.
It's also today the new term is called Exposure management.
Ooh.
Exposure
I.
I like it.
You know, it's not a new term, it just means something
different today than it used to.
It used for me, it just, it meant, it meant, uh, knowing who my daughter was
going out with before they left the house.
But, uh, today,
also a.
exposure.
Yeah.
Today.
Exposure Management really encompasses kind of the, the, you know, i
governance, like good controls and policy, and knowing where your stuff is.
It, it, it in it involves good operations, sound operations,
good quality, consistency.
It involves incident response.
It involves insurance and.
Risk mitigation and it's, it's very broad, but uh, specific to attack surface stuff,
um, a lot of, a lot of organizations and, and I've been in it for 30 years,
uh, I can count probably on one hand the number of the number of organizations that
have a good handle on their environment.
Like how many in, when I, when I ask how many assets do you have?
Oh, well, I maybe go check the spreadsheet or let me run my scan real quick.
They don't know.
Uh, and that's a problem in certain industries, especially like oil and gas,
where you've got all that stuff out in the field and you don't, I have no idea.
Well, then how can you protect what you don't know and how?
And then there's other implications like licensing and patching and all.
If you don't know what you're.
You're in charge of, then how can you be effective at it?
So there's that.
Uh, but then the exposure management or the, the blast radius is also
all those controls that would be designed or implemented to minimize
the impact of a given situation.
Like, this laptop gets ransomware.
How do I make sure it doesn't go other places?
Or at least not to the critical stuff.
Um, you know, if users get in fact in infected, then, you know, they
get the day off or whatever, but at least it's not taking down my server.
Um, but then other
considerations too, based on how your business operates and the people you
work with, are there ways to limit risk, uh, to, to that scope of, uh,
you know, your, your little ecosystem?
You know, if you're a company that just does business in Texas, then why are you
accepting internet traffic from China?
Yeah, good
Kind of a simple example.
And one thing, Mike, as you were talking about, sort of understanding
like what's in your environment.
I know sometimes we don't think about like companies who are developing
software and they, or even just using a third party software, sometimes
those have vulnerabilities that can.
That get flagged.
And if you don't know what software is running in your environment, how can
you make sure that you don't have any issues or you realize, Hey, I should
really be patching this, or I need to take some mitigation steps to prevent
myself from being attacked and being exploited by a certain ex, uh, exploit.
Absolutely.
And that seems like a very straightforward, uh, conversation to have.
But the moment that we, we start sitting back and talking about changing
our patch management policy and, and what systems get antivirus and what
don't, and for whatever reason I.
It's, it's not just us having this conversation anymore.
We've gotta involve the business and how what we're doing is gonna impact
people's ability to do their job or
watch Netflix on their lunch break.
But then also, uh, is there a cost associated with that?
Now we're gonna be paying more or differently.
Uh, and then at the end of the day, uh, if our policy is what drives an
incident, then, then you're on the hook.
Um, and so I think a lot of it environments kind of.
Take the, the, the risk averse approach.
Let's, let's like be as.
Uh, implement as much coverage as we can without
Hindering the
responsible.
Uh, for, especially when the business doesn't give us the feedback or the
direction we need to be more effective.
We, we become the default, uh, you know, scapegoat.
Uh, I mean, think the CrowdStrike situation, uh, where they, you know,
this update went out, I believe it was an involuntary update, so it doesn't
really apply to patch management, but if we knew about the criticality of the.
Um, or the value or the function of a server or machine
that had CrowdStrike on it.
The moment that problem arose, we would know the impact it was gonna
have over the next day or week.
Uh, and we would be.
I was reading a, a blog, uh, this morning.
I was reading a blog about the over-reliance on
individual vendors, right?
Um, and, uh, the, the funny thing is the blog was on, uh, CrowdStrike's, uh, blog.
Um.
It was a blog that they wrote a little while ago about, you know,
the overreliance on a single vendor.
It's just, it's just, when you think about what happened with
CrowdStrike, it's just rather ironic.
Um, yeah, I, so when we talk about, you know, there, there are things, let's
first talk about the concept when we're trying to minimize that blast radius.
Um, the, one of the first things that comes to my mind is the
concept of least privilege.
I.
Um, you want, you want to talk about that a little bit?
Sure.
That that lends itself to some comments I've already made.
And so let's just take you gentlemen, for example, Curtis, if you're just
a normal user, I'm just gonna give you the ability to do your job.
And so that's internet access, the ability to print, maybe access your,
you know, your email and maybe access, you know, some role specific server
or application within the environment.
Well, that takes time on the operations side for me to develop.
Who has access to what, based on job role,
which is called what role?
Role
based
based access control, right?
Or RA.
Yeah.
so that's a, that's a, that's a mature version of, uh, of, of just having the
questions a asked, uh, when new users get.
Uh, new user access, uh, is requested.
And,
and so in a small shop that's, that's not so somewhat of a problem, but even in a
small shop that has a lot of turnover, where you've got these large enterprise,
you know, small, medium, large, you know, and then enterprise, the different sizes
of organization may dictate the need for better, uh, more mature approaches to.
Allocating or provisioning access.
So if we can reduce what a user has access to, we're reducing their
exposure of that asset and that user.
Um, when, if, if they're compromised, their credentials are compromised, their
assets compromised, whatever it is, that user profile, the limit of, of that user's
profiles, that the access to do other stuff, uh, should mitigate the risk.
And a good example of that is in some environments.
When it resources are limited and we don't have the ability to go fix all
these problems at people's desks, we're giving users, normal users, local
administrator, access to their machine.
Um, and if we're not looking at stuff on the network, like network shares
and who has the ability to do whatever, uh, the exposure there, the risk, uh,
is much greater because you've given those users, those profiles, those
assets, more access than they need.
Well, I think when we start talking about least privilege and and RBAC.
Where this really comes to play is the more privileges that you have as part of
your job, the more RAC and the concept, the least privilege applies, right?
So if you are, you know, back in the day again, you and I have been around a
minute, and back in the day if you, if you were part of the IT team, you got root.
Right.
You got root on all the systems and you could do all the things.
And if you wanted to, if you wanted to blow up Oracle, you logged in as root.
You sued Oracle.
You did stuff in Oracle, right?
You basically were all powerful in the data center.
And I guess what, what I'd like to recommend here is that.
The more power that you're giving to someone and the more powerful that
their role is, the more you should think about this concept of limiting
the privilege that, that they have.
Right?
So you don't give root to everybody.
You don't give the Oracle like, like again, back in the day, you
just gave the Oracle password.
To the person that was going to be in charge of Oracle rather than
forcing them to become themselves.
And then su to, and again, I'm using very eunuchs terms, but, um, you
know, I'm old and that's what we did.
Um, although that still applies.
great responsibility, right?
Yeah, exactly.
Um, persona, I mean, you, you, you, you've dealt with this as well, right?
Oh yeah, yeah.
No, and that's always the case is how do you make sure?
Well, I think it's the trade-off, right?
Because people want easy, seamless access to do things they have to
get done, and they don't always do those operations over and over.
So if you introduce some of these hurdles, it becomes
difficult for them to do things.
At the same time, I totally agree a hundred percent that,
hey, I can't do this anymore.
Like our, I wanna restrict access because it's just too much exposure.
And so really only what you need access to, you should have, so an example
is in the CrowdStrike case, right?
If you look at what the recovery step was, right?
You had to go sort of go to each individual machine, enter their
recovery key before the user could even get to safe mode in order to be
able to try to recover their machine.
And this was, you had to go to every single endpoint and do that, right?
If you said least privilege, and you said, look, as an end user, you should
never have access to this key, right?
Because you never need access to it.
Now you're kind of stuck having an IT person manually go to every
single desk, and there's no sort of
self-help
mitigation, right?
So I think that's why there needs to be a balance, right?
It can't just be one or the other.
It's just like everything else in it.
Right?
It's easier to do it, you know, like you said, it's easier
to give everybody, everybody administrator on their laptop, right?
Um, it's easier to give everybody the recovery key.
It's also riskier to do all of that.
What were you gonna say, Mike?
I, I'll add a couple things.
You're right, it is a balance.
The more security you have, the less usable things are.
Uh, and that's, that's just a.
Balancing act between operations or usability and security.
But, uh, a couple things I'll add and, and this kind of, uh, continues the,
the threads that both of you mentioned.
Um.
Even, even administrators should have a normal non-ad administrator account
for doing normal non-administrative things like checking my email
and writing reports or whatever.
I don't need to be logged in as admin for that.
And it could still be Mike admin, but also have a Mike normal user account.
We want that accountability that, that, that I can attribute
network activity to a user
Yeah.
Can can
I add, can I add on that?
Can I add on that, Mike?
Um, and you should, as a matter of policy and a matter of logging
and monitoring and enforcement, I.
Enforce the idea that you do, you do not ever log in as
administrator or log in as root.
You log in as you, and you become the role that you need that creates logs,
that creates all of these things.
Uh, and that, and that way if anyone ever does log in as administrator
directly, that should be setting off the, the CLS on alerts everywhere, right?
So that goes back to the logging and alerting part.
Um.
And you're right, that's policy.
So you need to have a policy that dictates that privileged users have normal user
accounts and that they, they use those accounts to then gain administrator what,
whether it's their own administrator account or it's pseudo or su to, to
a, uh, an a router admin account.
Uh, the other thing I'll, I'll, I'll contribute is
privileged, privileged access.
Um.
Is often applied to more than just users.
There are service accounts that get privilege.
And so you've really gotta assess whether service accounts
really need that privilege.
And I know a lot of vendors in IT shops will give it that privilege for, for the
ease of deployment and troubleshooting.
Like, it's not gonna be a problem if it's, if it's an admin.
Uh, unfortunately, even, even security tools.
Um, and I think we, we, we, we may have mentioned red teaming at some point when
we, when we red team an organization.
We look at service accounts, and in a lot of cases, those security tools that
are supposed to protect you are also running as a privileged service account.
And in a lot of cases, we're able to actually compromise those
security service accounts in order to compromise the network.
Yeah, we talked, we talked about that.
We talked about those service accounts quite a bit a, a couple episodes ago.
Um,
but that's policy.
Policy needs to dictate that least privilege is, is something that, uh,
needs to be applied to everything.
Yeah, absolutely.
Uh, let's move on to another topic.
Um, least privilege.
Really important.
You know, implement it wherever you can, as much as you can.
There is a balance that you have to have, right?
Um, and I do think that idea of like, you know, administrators need to
have administrator, but they should not be logging in as administrator.
They should have to become administrator.
And I do.
Um, I do very much prefer pseudo to su, uh, because you, you use your password,
right, rather than the, the root password.
Anyway.
Um, let's talk a little bit about network segmentation.
You talked a little bit about laptops.
Um, one of the things, you know, a laptop we can limit to a certain degree
what servers a laptop has access to.
But I think that in, in almost every case, we can put laptops on a
separate network that should never be able to talk to each other.
does a laptop ever need to talk to another laptop directly?
Well, it's it, because it's running windows, first of all.
But, um, their their windows is so chatty when you look at network
analyzers, it's, it's crazy.
But, uh, absolutely you should have a, a, a, like your core
network should be on its own
segment.
Your if, if you have a voiceover IP network that
needs to be on its own segment.
Uh, your backup network, your administration, uh, there's, there are
so many different ways to, to architect your network that can reduce exposure when
there is a problem, because deploying, uh, access control, uh, creating rules around
segments, all that stuff is one console today with the virtual, you know, the, the
interface and a lot of these switches, it's so much, it's so intuitive.
Creating VLANs and all that stuff.
It's, that is one of the best and most timely ways of mitigating
network, uh, network layer, uh, intrusions and, and incidents is se
being able to, you've already got it.
You've already got it set up.
If there's a problem with the, the, the user environment, just
go to your switch and tell it.
They can't talk to anything else for a while until you figure this out.
Uh, so there's a lot of, a lot of very effective and, and, um, timely, uh,
things you can do, uh, once you've implemented, once you've architected
segmentation, the tools are out there.
And Mike, I think, and wanna get your take on this, I guess so.
Segmentation is great, and firewall rules are great only
if you use 'em correctly, right?
Because there are a lot of times where people might say, have a trunk port
passing all the BAN tags across it, which basically defeats the purpose of having
segmentation, especially for end users because you can automatically switch
between different VLANs and now you have access to networks, which you should not.
So just making sure you are using the switches and.
The network configuration and also your firewall rules correctly
is also a big thing as well.
Yeah, you've gotta have a strategy for your architecture.
Implementing parts of this are better than not in most cases, but
implementing segmentation can actually create more overhead if you don't do.
Um, and then, I mean, there's, I, I, I listed a couple.
You could also create a, a segment for your remote access, uh,
users that are calling in over, you know, VPN or what have you.
But, um, the, the idea though, and even other locations, if you've
got different buildings, that those buildings should be on their own segment.
Uh, if, if you're running like an MPLS or internal, uh.
Networking scheme for that,
but the idea then is making sure you have a good understanding of how your network
operates and how it supports the business so that you can configure that right.
On a previous episode, actually, I think it's the one that went live just
this week, um, in recording World.
It's, it's, it's different.
It's different on the episode world.
But, um, you know, one of the things that I harp against a lot is RDP, right?
Uh, which I call the ransomware deployment Protocol.
Um, and if, if you are going to enable RDP, I think RDP should be on its own
segment, that in order to use RDP, you must be either physically present.
In a particular place, or you need to be VPNing in, uh, to that, that you should
not be able, you should not have RDP on, on every server and have that rd have
those RDP ports accessible everywhere.
Right.
Um, that's another, can you think of anything else like that, that
we would really wanna segment off?
man, I can, I can, I can probably spend the, the rest of the
day, uh, talking scenarios.
But the important thing, the important thing to do is assess the
way your environment operates, the things that you use to support your
environment, your users and the company.
And then what, what I'm gonna say, what risks are associated with that?
Like RDP, if you don't have it configured well, all that traffic is unencrypted.
Uh, if, if, you know, so are there other tools you're using?
Uh, and, and how are those configured?
Like Service Desk or, uh, ninja, RAMM or, or some of these others if those
are great tools, but if the endpoints are con, are configured to auto answer
without user interaction and putting in a token and all that stuff, that's a risk.
And that's, so that's an example of look at the tools you're using and.
Can we use, can we use them secure?
And if not, are there, is there an alternative?
And like there are alternatives to RDP that are low or no cost, that
are more secure and effective.
They're just not as, they're not easy.
They're, they don't come with the operating system.
So there's
a, there's a, there's a list there of there deployment
and configuration to use it.
Uh, that, you know, maybe some organizations don't have
the time or resources to,
Yeah.
Or, or once again, money.
It's like everything else that, you know, the good tools cost money, right?
Um.
One other thing I was gonna add to what you were saying, Mike, is for some of
these vendors, maybe it's worthwhile to see, do they have like white papers
or knowledge, uh, based articles on how to actually set these up securely,
Mm-Hmm.
right.
Or best practices to
and I, I
know, and, and you're right there usually is because that's just
gonna help them, uh, you know, distribute and market their product.
I know a lot of organizations that are using AI to ask those questions, like,
how, what's a good way to, what's a good alternative to RDP or what have you?
And I'm gonna, I'm gonna, uh, suggest that people be conscious that when
you ask the questions in a public domain, they become public knowledge.
And if I can trace that back to who asked the question, now I know the
technologies you might be using.
Um, and, but also not to trust AI on face value.
Still do your own research.
In fact, finding all that good stuff.
Are you saying AI's not perfect, Mike?
is not perfect.
It's almo.
AI is almost intelligent.
Almost intelligent.
I like that.
The key, the key is the board of artificial, um, that I saw
a meme yesterday and it was a, it was a picture of, um.
What's the, what's the, the, the guy, the young man that comes back
in time to stop the Terminator?
What's his name?
Um, what's the character's name?
No, the, the, the guy that comes back.
The son, the guy that battles all the terminators.
Why can't I think of him?
Yeah, we know who you're talking about though.
Mike Connors.
Mike, Mike Connors and that his name Mike Connors.
Anyway, and he is like, it's like it's a picture of him, like giving
side eye and it's like Mike Connor's watching all of you people befriend ai.
Nice.
Um, all right, so let's talk about a third topic, and that
is, again, this is all under the concept of minimizing blast radius.
One of the things, so, you know, we, we talk on this, on this podcast, we talk
a lot about backup and recovery and DR.
And making sure that you, you have a copy of your data and having it
in a place that is, is blocked from, from, um, uh, you know, access.
You know, so that if, if you do get attacked or when you get
attacked, the, the hackers won't be able to also delete your backups.
Having said that, none of that will help you.
If your data is stolen, right, if your data is exfiltrated.
So the thing that I think people are not spending enough time on is doing what
they can to stop the uploading of their data, um, you know, to, uh, the world.
And we, we, there's a really good episode, uh, of ours back when we had, um, uh,
Dwayne from, uh, the red teaming group.
That where, where he talked a lot about, you know, he talked about
how that actually generally people aren't, the hackers aren't using like
the web, they're just going directly.
They're just, you know, copying the data directly to where they want to
store it because, and this is the crazy thing, no one is stopping them right.
They know that the web traffic is being monitored, and so they don't use that.
And, and he had this analogy, he goes, it's like we're in this wide open field
and the web is like a door in the middle of this field and that door is locked.
So it's like, oh, darn, there's a door here.
We can't use it.
Oh, maybe we'll just go around the door.
Right?
We'll, all these other ways.
So it, it came as a surprise to me, and I guess it shouldn't.
Because historically we didn't limit outgoing traffic.
Uh, and so, you know, what do you think about this idea of basically blocking
everything that's going out and only limiting what should be going out, which
is the, the complete opposite of the way most networks currently are configured.
What do you think about that idea?
I think it's a beautiful idea, but it would take a lot of analysis.
That, uh, most organizations don't, don't go through.
So what, what is normal?
What is allowed?
Uh, where's it coming from?
Where's it going to?
How much volume should I be, uh, considering as normal?
Uh, what ports do, does that data go out?
Uh, what protocol?
All those things,
uh,
talked
can be done.
on your firewalls on observe mode.
Um, first for like a month just to see what actual outgoing traffic.
Uh, and he did tell the story that when they were advising a customer of
this and they turned on their firewall and observe mode, they found out
they were in the middle of an actual attack, um, during the observe mode.
Um, but yeah, that you definitely have to.
You can do a lot of damage.
And I, you know, and I have a story that I've told a lot of times on the
podcast of me working in an environment where they, they blocked everything
and the, the amount of hassle that was to me as a, so here I was, I was the
o they had a very segmented network that server A could not talk to server
B it was, it's, it was properly done.
And this is 25 years ago, so this is really impressive, but.
When me, the crazy man came in and I wanted to do this thing
called backups, and I needed a server to be able to talk to every
other server that blew their mind.
And, and they hated me from day one, and they did a lot of damage to my
ability to do my job, uh, in the process.
So, you know, it has to get their job done, but I, I do think this is
something that you should entertain.
Uh, and I do like this idea of turning on the, the firewall and, and observe mode.
What do you think persona.
I think that's worthwhile.
I think also with sort of some of the, uh, blacklists that are out there,
for instance, you could also be using DNS blacklists and other things like
that to also help filter out some of the common websites or IP addresses,
which have a bad reputation, right?
There's also the reputation score out there, right?
So you can look at some of these and apply them and.
Not necessarily gonna prevent every anyone from trying to get to legitimate
websites, because even in those 30 days when you're running firewall and observe
mode, maybe it's seasonality and I don't go look at certain websites or do certain
things until like the quarter end.
So you're not impacting the business, but at least you're trying to prevent
a lot of the malicious traffic.
He, he did also talk about blocking, uh, things like S-S-H-S-C-P.
Um, he's like, ask yourself, when would we ever, is there a scenario in which
we as admins would ever need to SSH to the outside, outside of our network?
And if the answer is, we can't think of one, then turn SSH off
Or FTT.
or ftp, similar protocols, right.
Um, outgoing, specifically outgoing, FTP.
Right.
Um, can you think of other things like that, Mike, that, that we
might wanna block going out?
Uh, encrypted traffic over your DNS port.
That did come up, I think.
Yep.
Yeah.
that's a good exfil, that's a good xFi port and tactic.
Um,
but then
wanna, explain that?
I know what you mean, uh, Mike, but do you wanna explain that
So it's a port that's usually not monitored.
Uh, it's never, it's never blocked.
You, you, you, you have to have it.
Um, so we don't monitor the DNS port on the firewall.
Um, and bad guys know this, so we're, to your point about web traffic and encrypted
traffic and these other services like SSH and FTP, those run on specific ports.
And so if, if I'm concerned about someone.
Uh, creating a connection outbound that can upload files.
I'm looking at Port 21 and the SSH port SSH port.
But very rarely do we monitor the DNS port and so back and, and
there's a couple things there.
One, uh, very low traffic on that port.
And so we could simply look for any increase, you know, abnormal
traffic volume on that port.
That should be clue number one.
And then clue number two, uh, bad guys.
You know, when we, when we expel data off, uh, through that
port, we typically encrypt it.
So you don't know what we're, what we're stealing.
And so encrypted traffic over that port at, at, at any level should be suspicious.
Um, so yeah.
And this goes back to understanding your business, what, and
whether it's the, the firewall.
Uh, you know, observe mode, uh, or just simple understanding of the different
applications and ways that users interact and data flow and all that
stuff that'll help you determine what can be turned off, blocked, uninstalled,
monitored, uh, that kind of thing.
Uh, and along those lines, and, and, and persona touched on this
with the, the known bad IP lists.
Um, so those are good, but you know, you might have a handful of bad ips
in a geographic area of the world.
Well, if your, again, if your business doesn't do, if, if your
business doesn't care about traffic from that part of the world, just
block that entire geo IP subnet.
Uh, and that'll do two things.
One, uh, or several things.
One, uh, you're not gonna get direct traffic from that part of the world.
You don't care about whether it's malicious or unintentional,
and that should reduce.
Overhead on your firewall, but it'll also limit, um, at least
the direct attack exposure, uh, from, from that part of the world.
Yeah.
I remember a long time ago me deciding that I didn't need any web browsers
from, uh, customers from uh, Russia.
I remember deciding that.
A long time ago.
Um, yeah, this, this reminds me, you know, I'm gonna draw an
analogy to pre nine 11, right?
Um, the idea of the idea that the attackers used the planes.
As the weapons themselves was a new idea at the time.
This is a new idea that we never really had to think about exfiltration
really as the problem itself.
And so I'm just saying to me it's the one problem that you can't.
Stop.
Right?
I'm not, let me rephrase that.
If you, if you experience it, if they download your data,
there's nothing you can do.
You're going to either pay the ransom or take the hit the pr hit of whatever it
is that's gonna happen to your company.
And which is why I remember asking you, um, you know, the, the degree
of people that, or the percentage of people that pay the ransom.
And one of the first things you said was if they did exfiltration.
Generally speaking, they're gonna end up paying the ransom.
And so I guess all I'm saying is it's time to have that conversation.
Maybe you do some of these things, maybe you block known bad IP addresses.
Maybe you, maybe you start blocking, um, you know, uh, outgoing, uh,
SSH and SCP and FDP, uh, any of the file transfer type protocols.
Um, and maybe you consider, at least consider, run your firewall and observe
mode to see what kind of outgoing traffic that you normally have, and
then maybe if you want to take it to the next level, do the, the best thing
again, good, better, best, right?
The best thing would be to block all outgoing traffic, except for
the, you know, the stuff, but yes.
You know, your initial response to that is a hundred percent true.
It's gonna take you a minute to accomplish that,
right?
Well, and just imagine
piss off some people in the process.
What's that?
And just imagine the end users like Curtis.
Imagine if at home you blocked all outgoing traffic,
Yeah,
right?
Imagine what?
Help desk.
Yes.
I.
exactly.
Uh, the um.
Uh, I can imagine that very much.
Um, well, it's been another great conversation.
Um, I, I hope that folks got some ideas about ways that they
can minimize the blast radius.
And, um, this is our part of our continuing, uh, series here
about, uh, defeating ransomware.
Thanks again, Mike.
You are welcome.
And, uh, thanks again, prana.
No, this was fun.
And Mike, I'm glad that there's someone who understands networking because
whenever I talk about networking with Curtis, it sort of just like
goes over his head.
stop.
you're
But I love you, Curtis.
sometimes.
You're mean pana.
Thank goodness for me.
I have our lovely listeners.
We love you guys.
Thanks.
Uh, thanks.
Uh.
For, uh, being there at least I think you're there.
The numbers say you're there.
So, uh, thanks for being there.
That is a wrap.