Today on our Tech for Business podcast,
we're joined by Nate, our Director of Cyber Security,
and Andrew, our Security Incident Response Team Lead.
This month, we've been talking about incident scenarios
and what you can do to avoid them.
We started with close calls,
we went into some email compromise and wire transfers,
and today, we've got 10 different examples about ransomware.
Before we really jump in,
I'm going to throw my first two questions to Nate.
First, what terminology do we need to know,
what are those beautiful acronyms that we should know
to understand today's podcast,
and then what is kind of the number one thing
or a couple of things a customer could do
to stay off of this list?
Yeah.
The, in terms of different acronyms to remember here,
so we're going to call out EDR nonstop through this, I'm sure.
So endpoint detection response,
it's a, you know, traditionally you had antivirus,
now you have EDR, there's a lot of different acronyms,
EDR, MDR, XDR, I'm not going to go into depth of those ones,
but essentially what it does is it's bringing in behavioral
monitoring into your traditional antivirus solution,
trying to catch the unknown risks,
something that even if it's not malicious software,
but it behaves abnormally in a malicious way,
it can still take action on that type of stuff.
So that's going to be a big one, MFA,
multi-factor authentication or two-factor authentication,
depending on what you're used to hearing.
We might bring up, you know, IC3,
we talked about that a little bit
on the email compromise wire transfer.
It's the Internet Crime and Complaint Center,
which is the FBI's reporting division of cyber crime.
The, I might bring it up, RTOs, RPOs a little bit,
so recovery time objectives, recovery point objectives,
business continuity planning, all of that type of stuff
is all going to be tied to your backups,
how fast you can back things up,
at how much data can you potentially lose throughout that.
Those are the big ones that I can think of,
off the top of my head.
And then I would say the biggest things
to try and stay off of this list is,
EDR and multi-factor are going to be the two biggest ones
that come to mind.
Unfortunately, in most of these cases,
you're going to find that having one or both
of those solutions would have prevented a lot of this stuff
from happening in the first place.
Removing local admin permissions,
otherwise there's also application of whitelisting
is another one, so no new software can be introduced
into your environment unless it's previously approved,
because every one of these ransomware cases,
the threat actor had to introduce new malicious software
into the environment to encrypt data or steal data.
And so if you have some type of application
whitelisting tool in place,
you're going to very quickly prevent yourself
from being on this type of list.
Sure, I don't know if you had anything else.
I think one thing, DR disaster recovery.
You're talking about with the RTL or RPO.
So yeah, I think disaster recovery
is the only other one that I think
that we are going to be talking quite a bit about.
For sure, and all the names and some information
have been changed to protect the innocent,
just saying our little legal spiel.
But yeah, how do you want to start us off today?
I guess I'll start off with the first one.
This was a relatively recent incident.
It was from a threat actor group called Akira.
This client, they were compromised through their VPN,
the Cisco VPN, very prevalent now in ransomware cases
just because there are plenty of vulnerabilities
that have come out for the Cisco and Cisco VPNs.
What happened was, Tacker got in,
they were able to move laterally,
escalate their privileges due to weak password policies,
overused admin, the same admin password
for all the local devices.
In this event, the attackers were able to encrypt
their backup server, their backup server,
essentially encrypted the backups off in the cloud.
So essentially they ransomware themselves
by having this server get encrypted.
Important things for that to prevent.
EDR would have been a big and important tool
to have in place, making sure that you do not reuse
local admin passwords, Microsoft Laps.
That's a free tool that can be deployed, very easy to do.
As far as other things, I would also say,
making sure your VPN and all points of egress
on your network are up to date.
Firewalls, your VPNs, any sort of SD-WAN,
anything like that, where somebody from the outside
can come in, it's the most up to date as possible.
Another event that happened was through a threat actor
called Lockbit 2.0.
Again, this was a compromise of a Cisco VPN,
very similar in timeframe from the past one
that we spoke about.
This one, the client did have EDR,
but they did not have EDR on all of their endpoints.
So the attacker was able to compromise a device without EDR
and then just hammer on every single other device
until they were able to encrypt other devices.
So again, making sure that your firmware is up to date
on all externally facing devices,
and making sure that you have full coverage
of all the devices that come into your network
that you own, make sure they have an antivirus solution,
preferably EDR, but have some sort of
software protection in place.
Because while EDR did make their job harder,
no tool is perfect.
And as we've talked about the security onion,
layering your defenses, EDR defended,
but attackers found other ways
because they had that foothold.
Yeah, that one was super interesting
just for some additional context behind that one,
because in the EDR portal, we saw that the VPN,
again, there was an account that was on that VPN
that was compromised.
So again, multi-factor would have been a nice way
to help prevent that.
But from the logs, we saw the Thread Actor attempt
to escalate privileges to the servers
over and over and over again.
And so in the logs, we saw the same attempt
to all the different servers that had EDR installed.
And then the next logs that we saw
was coming from an internal host,
or workstation that did not have the EDR installed.
And then they tried doing the same thing
from that to the servers.
And again, the EDR solution protected a lot of that stuff.
What happened was that one internal device
that they didn't have EDR deployed on
had access to the file shares.
And so it started trying to encrypt all that data.
Now the EDR solution was able to start restoring
a bunch of data as much as it could
based off of, I'm not gonna get too much of the depth here,
but on the way that that typically works,
but it was able to start trying to restore
as many files as it could.
Unfortunately, they did have to start pulling from backups
because there were some limitations of data coverage
of what was acceptable.
So this is again, where we're starting to talk
about things like recovery time objectives
and recovery point objectives is if,
let's say you're taking a snapshot every 24 hours
or every five hours, but you actually needed data
within the last hour, you might still need to pull back
from a backup or potentially update your backup frequency
to help accommodate the way that the actual business needs
are.
But again, for me, that was a really, really interesting
one seeing the tool continually block and block and block
until it found that device that wasn't protected.
So I guess if you're keeping track of
or just watching through all these different podcasts,
org eight in our list here or three today is one that
this is a customer that was doing almost everything right.
They didn't have EDR deployed when this happened,
but they did have network monitoring.
They had phenomenal backups.
They had multi-factor widely rolled out
across the organization.
Unfortunately, their users did have local admin as well.
And so what happened in this next case was that
there was a group called Conti.
So this is an interesting group that has now shut down.
So this is a group that's historically composed
a lot of the Russian and Ukrainian hackers,
obviously with the war, they kind of split apart
and everything like that.
But essentially what happened was
we found that there was a document in this environment,
which was an Excel file with a malicious macro
associated with it.
So a user received that phishing email,
clicked on the Excel document, was able to run that.
And then that's what kicked off the ransomware incident.
So the biggest thing was they didn't have EDR
because we deployed that for them.
And then that's what found all these remote connections
in their environment out to the threat actor.
It's what helped find the initial Excel file
sitting in their download folder.
But what we were able to do is
because they had solid and tested backups,
we were able to get their entire environment operational
in less than four hours,
let them continue doing the workday
as while that environment was running,
we were able to continue doing full restores and forensics
without impacting the business.
So again, if you start to pair all these different solutions
in place and have a proper methodology
to protecting the business,
a ransomware incident can be extremely minor impact
compared to the traditional impact.
Andrew, what's the latest downtime on average
for a ransomware incident?
Two weeks, I think is the number,
but it could be even longer now
with how the attackers are doing their stuff.
So for two weeks, downtime,
like restoration of business kind of time.
That's probably your least favorite news to tell a customer
when we tell them that they're potentially
gonna be down for two weeks, isn't it?
Yeah, it changes the mood of the conversation
as just, hey, this is an inconvenience to,
hey, this could be business ending,
especially businesses that run on slim margins.
They don't have a lot of money coming in to pay everything.
They depend on the ongoing business
and being down for two weeks
where they don't have that incoming business,
it can end the business.
And so that really changes the conversation
if that they know it's,
we shoot to have it up as soon as possible,
but average downtime is about that two week.
Yeah.
I think that I'll kind of use that as a segue
into the next organization,
because this customer, they had great backups that worked.
However, they didn't do a great job at testing them
with a disaster recovery test
to ensure that they could restore as quickly as possible.
And so even though we were able to get the business
operational and limping along in the first couple hours,
they essentially were majorly impacted for two weeks.
And so this was one where the customer had a Sonic wall,
VPN that hadn't, it was actually end of life at the time,
hadn't been updated in years,
there's vulnerabilities on it,
but they just kept using it and everything like that.
You know, going back, we even told them,
hey, this is end of life, you need to get rid of it.
It's a security risk.
Didn't upgrade it, therefore it led to this incident,
but that VPN was compromised.
And so with the backups, essentially what happened was,
they had these backups keeping all of their different servers
restored and again, testing them every single day
that they could backup appropriately,
but what went wrong in this case was that this customer had,
I think it was six different servers
that all had to inter-communicate with each other
to provide the total solution.
And what happened there was the appliance
that was running those backups and backup recoveries
could only spin up three or four of them.
And so they had a couple servers that you could not run.
And so then you had to spend time
doing full restores on those ones
rather than running them in a virtualized state.
Therefore the business is still down.
And so that's what just dragged it on another couple days,
which again, it was a significant amount of money lost
in productivity for that organization.
Customer also didn't have EDR implemented out there.
So people are able to move laterally
as new malicious software is being loaded in,
trying to steal data outside of the organization.
That's another big issue.
They did have sensitive data about customers
sitting on their network that was lost as well.
So then you had to go through legal reporting off of that.
And then I believe the last thing
that I wanted to mention about that was,
their organization was,
sorry, I'm also trying to make sure
that I'm not sharing a little too much info here.
It was business altering.
We'll just put it that way is they had to completely change
how their business operated due to this incident,
even though they were able to successfully restore.
So.
The, Kelsey and Ariel,
I don't know if you have any questions along that.
I've been talking a lot here.
I was almost-
Yeah, I'll let you, I've got kind of
a little bit of a wrap up question.
I mean, I'll ask that later,
but this feels very stressful.
If you're in this situation as a company,
I mean, what do you do?
Like, do you call your IT?
Do you call the president and CEO?
I mean, if you're in this situation
and you're looking at your business
potentially being down for two weeks,
what does that kind of that first step look like?
If I may.
What's the first step on our incident response plan?
Basically.
Well, make sure you have an incident response plan.
Yeah, exactly.
That's really important.
You never hope to have an incident,
but make sure you have an incident response plan.
Who is responsible for what applications?
Who is the call tree?
Who are the important people in the mix?
When it comes to IT, when it comes to finance,
when it comes to everything,
it's important to know these things ahead of time.
So then you know what to do
because it's really no fun to get on a call
and we have to learn everything about the network
before we can actually start helping you.
Yeah.
The fact that came to mind was on our internal incident
response playbook essentially,
the first step that we have to find on that
is take a deep breath, call your family
and tell them you're gonna be late home
and it's gonna be a long couple of weeks.
It's just the nature of it, right?
Is for Andrew and I on that last customer
that I talked about,
Andrew, I think you and I were up for almost three days straight
for the first, yeah, the three days,
just trying to get that customer operating and moving along.
So, you know, we put in almost two weeks of time
in the first three days and over the next two weeks,
I couldn't tell you how many memes and gifts
and everything we sent to each other
just to keep ourselves sane during that engagement.
But that was also one of my favorite times at CIT
because I don't know if we were just so slap happy or what,
but...
There might have been a lack of sleep delirium
or something like that.
But that is the first thing for, you know,
as you face these types of situations is take the breath,
tell people that you're gonna be late.
It's going to be stressful.
We know that.
Our job is to help reduce that stress,
help provide the empathy, help provide the...
The skill set and guidance to help you navigate
that situation.
You know, I guess the one big thing here,
and I talked about it a little bit is,
how do you prevent yourself from being on this list?
And one of the things that come to mind is,
if there are security recommendations that come out
of either CIT, another provider,
your own internal employees, please take it seriously,
because oftentimes something like,
we need to update our firewall.
That seems minor, but we just talked about
three different cases of the VPN being compromised
due to outdated software or, you know,
MFA not being implemented for a user accounts there.
This is serious stuff.
And then also is oftentimes what we see is that
organizations say, I don't have the money to do that.
It might only take you an hour or two of time
to implement that.
But the alternative to that is thousands and thousands
of dollars of incident response or forensics responses,
legal responses, everything like that.
And it seems like organizations always seem
to find the money afterwards.
So being a little more proactive on it.
The saying I like is, you know,
pennies before an incident, dollars after,
because, you know, if you pay some pennies here
before something happens as a preventative measure,
it's gonna help you not have to pay dollars later.
Yeah, the last thing I had about that is,
to implement EDR, you can typically spend
10 years of EDR payments just to cover one security incident.
It makes no sense why that would not be an investment
because the risk is so high, the impact is so high,
and the cost of EDR is so low.
Multi-factor, most of them included for free these days.
There are pain solutions.
They have a couple extra bells and whistles,
but 10 years of protection compared to one security incident.
So, but...
Sure.
I'll touch on two, two more,
and then I'll hand it over to Andrew for a little bit.
This customer, they were not sitting in a great spot
ahead of this security incident.
They didn't have EDR, they didn't have a great antivirus,
they didn't have multi-factor, anything like that.
And so, but I wanted to talk a little bit more
about the response capabilities and the response progress
because that's what really impacted it the most.
And so, this one was traditional phishing links,
someone clicked on it.
Their users did have local admin, which is terrible
because it greatly expedites the attacker's ability
to grab admin credentials in that environment.
But one of the interesting things was we implemented EDR
into this environment, we found 40 different computers
that all had remote connections going out of the network,
trying to maintain persistence to that threat actor.
And so, what happened there was,
even though you might have taken a machine offline
and tried to clean it, you still had 39 or so computers
that had access, so it was extremely dug into their network.
Now, when we deploy that EDR,
it found all those and shut them down really, really quickly.
But where the issue lied with this environment
was that the IT admins out there said,
we are losing thousands of dollars every day
with this system being shut down.
And so, while we were going through
the incident response process,
which it has to be extremely meticulous and methodical
of when do you bring up certain servers in particular order
to help minimize reinfection of those
brand new configured or restored systems,
while it's still in a hostile environment,
they kept bringing up these servers
without the guidance of the forensics
or CIT and center response team.
And so, they actually ended up having to rebuild
those systems three times because their internal IT
kept spinning them up against guidance
of the incident response and forensics professionals.
And it led to additional downtime
than if we had just gone through the proper process.
And so, one of the big things here is
when Andrew comes in and tells you
that you're gonna be down for a potential two weeks
on average and the customer wants to be up yesterday
there's a delta there that you have to address
on the emotional level almost and say,
we know you want to move fast,
but to move slow is to move fast
because if you do it the proper way,
you'll be up faster than having to do this
two, three, four times again.
And also in that slowness,
if you do have cybersecurity insurance,
there is requirements for them to pay
that certain things are done.
And if you do them out of order, you lose logs,
they can deny your claim and then you're really up the creek.
So it's important to move slowly, to move fast in the end.
Yeah, and Andrew's talking about the OFAC check.
This is something that the US Treasury put into place,
I believe it was 2020 now,
where they will prohibit payments to ransomware groups
or nation states that are on a sanctioned list.
And so in those cases,
if you are compromised and it's known to be a
sanctioned threat group,
you're not authorized to make payment to that group,
to restore data or retrieve files.
Otherwise you could actually face a fine
from the US government as well
for making that payment on top of that.
Therefore, and then also for a managed service provider
like CIT, we cannot assist you with that
because we could also face similar fines
from the government for assisting you with that.
So the government, CIT, we all say,
do not pay the ransomware demand.
The biggest thing is again, all this preventative time
to prevent it from happening in the first place
because it will easily dwarf whatever the cost
of a major security incident is.
Last one, this one holds a special place in my heart
because it's the first one I ever had to respond to.
Sorry to the customer if you're listening
that this is someone that just called into CIT.
I was brand new into CIT at the time
and they just said, hey, our environment's down,
can you come help us out?
And I went out there and started helping out
with ransomware and doing a little investigation,
trying to figure out what happened,
what does the environment even look like,
everything like that, because again, brand new to us.
And I found that there was RIAC ransomware,
which used to be one of the most expensive ransomware groups
out there on demand payments.
I believe that's a group is no longer in place.
I'd have to go double check that.
But the way that it impacted their network
was the systems out there were operational,
but their server was down,
which was driving their ordering software.
They were still able to make phone calls.
And so their order department was literally
just writing down customers' names, credit card infos,
whatever they wanted to order on pieces of paper
while I was there, just trying to keep
the business operational.
And then once they could restore the systems,
and they'd have to go manually enter all that data back in.
What I found out there was that every single workstation
in the environment was end of life,
so it was no longer receiving security patches.
They didn't have any type of EDR in place out there.
Their server was a 2003 server, also end of life.
And then as I was walking around,
and I noticed that there was a hard drive
plugged into the back of this,
sorry, it wasn't even plugged in,
it was sitting behind the server.
And I asked them, hey, do you have backups for your server
that we can maybe restore from this?
And they said, yeah, we do.
I said, is that the hard drive that was plugged
or sitting right behind that server?
They said, yeah, it was until we unplugged it.
It's like, okay, let's take it onto a different system
and see if we can get it up
because the server was completely corrupted,
brought it in, and I saw that ransomware
started going down the files of their backups as well.
And it stopped three files short
of their entire customer database.
And so we were able to actually restore that,
but they said that if it had hit that file,
they would have closed up their shop.
But unfortunately, well, fortunately for them,
it corrupted the server a little too quick
and shut down the server
before it encrypted their backup there.
And so in that case,
we were able to actually get the customer backup
and operational.
I believe that one was about two weeks
to almost completely rebuild that environment.
But the premise of that is you have to have
what they call immutable backups.
These are ones that cannot be tampered.
And then also there's the three to one rule.
When it comes to backups,
and now I'm gonna totally blank on that.
But essentially having multiple copies of your backups,
having different locations where they're stored,
and I should probably look that up for the details again
on what the three to one specifics are,
but essentially having good solid test backups,
not a hard drive plugged into the back of your server.
On to the next client here.
This event was due to an unpatched exchange server.
So publicly facing,
running an older version of exchange.
We had deployed EDR to their network
because they did not have it previously.
And we found that there were about 60 sessions
connecting to the threat actors.
I had the attacker slips in my mind here right now.
In the event of this compromise,
the attackers were able to encrypt their backup server
as a Veeam server.
I like that Nate brought up immutable backups here
just a minute ago because these backups were not immutable.
They were still locally stored.
So the attacker on the network was able to
encrypt all of those backups.
It actually required some actual data recovery,
taking the physical device to be
manually restored down at the block level.
It was very expensive and time consuming.
That was truly two plus weeks before even business
was functioning slightly close to what they were before.
I did find what the three to one was again.
Three copies of your backups,
two different methods of storing it.
So again, if it's on like a drive level
versus cloud level, that would be two different versions
of how it's stored and then one offsite.
So the one that Andrew's talking about was,
they had two copies, one form of storage,
two locations, because there was an offsite one,
but it was doing the same replication.
So it wasn't following the full three to one rule.
So sorry, Andrew.
Yeah, good.
That was essentially my story there for that one.
Yeah, that was an interesting one
because we actually had a call in forensics
and data recovery on that one and take all their data.
And that was the hill Mary play to try and get their data back
and thankfully it was successful.
Thanks for finding that.
I was also googling on the side like,
oh, you gotta find this.
But yeah, Andrew, I had a couple more instant responses
you wanted to share.
Yeah, another instant here.
This is by threat group called doppelpear.
The incident started with a suspicious FedEx email.
Now, obviously not from FedEx.
The attackers were able to convince a user
to open the document and from there,
the attackers were able to compromise the entire network.
I think it was $600,000 was the initial payment.
And then after the time expired,
the payment doubled up to 1.2 million.
With this incident, there were a lot of end of life devices
in the network and maybe more servers
than they probably ever needed period.
So it gave a very large attack threshold
for the attackers to gain foothold Esquivel privilege.
They did have RSA MFA in place,
but that wasn't enough with the end of life servers
that the attackers were able to compromise.
Again, did not have EDR in place at the time.
Now, I guess I have another story about a incident
that was relatively new to me.
It was still a network compromise.
It was still a threat actor,
but they did not encrypt the data.
All they did was get into the network,
ex fill data and leave a little note that says,
hey, I got all your data, pay me.
It's interesting, I guess.
I get what the thought process is.
They're not ending business because business ends,
you don't get paid.
They can still function,
but it was definitely an interesting attack
that was due to weak password policies,
especially a legacy account
that password was set for it many years ago.
It was used for many services.
The pain to change that password was an assumed risk
because they didn't want to have to go through
all this other stuff to update it.
That was a difficult one to deal with.
I didn't hear the end of that one,
the internal IT handle, the rest of it,
but it was definitely an interesting one.
I think, Nate, I'll let you handle this very last one.
Yeah, the one thing that I did want to add on
about the threat groups that don't always encrypt data,
even if they do encrypt data,
the tactics of these threat actors change over time.
It's really been interesting to see this
where typically they would just encrypt the data,
say give us money, and then that was the end of it.
Then they switched to what they call double extortion,
was they would take the data and then encrypt the data,
and then if you didn't pay, they'd say,
well, we still have your data that we can potentially leak.
I think org-8 or org-3 that I mentioned up above
was one that they had a lot of sense of data.
They did pay to prevent it from being leaked further,
but then they used those backups to become operational.
Those are the ones where that double extortion
does tend to sometimes work.
One of the other things that we've seen,
and so there's been threat groups like
Tommy Leakes, Kara Kurt, anything like that,
where they don't encrypt the data, but they take it.
But then what is really interesting about these ones
is they don't just tell you that you have the data.
They'll start calling your employees and say,
tell your IT team and the business leaders to make a payment
because we already know that we have your data.
They're ignoring it because that's the other thing.
They monitor the chat logs,
and so if you're hopping in and out of that portal,
trying to see if there's any updates,
they see every single time that you're in there,
which then prevents better negotiation tactics.
And so one of the things there is we've also seen it
where they have obtained a customer list of that in business,
then they started calling the customers
or emailing the customers saying,
go tell your vendor or partner to pay us
because we have your data
and they're not being responsible
to prevent that from being leaked.
So now you have your customers calling you saying,
what happened?
You know, the cat, is that the cat?
Is that one of the bag?
I forgot the saying there, but yeah, the cat's on the bag there.
And so there is a lot of new techniques being done there.
And then the last thing I'd say is that there was a bank
that we ended up working with.
I won't go into too much of the details,
but the biggest thing was this customer,
although they didn't have EDR in place,
they had everything else done very, very well.
And so we identified that there was ransomware
in this environment at BLEEVIO's 5 AM,
and then we had the entire environment operational
by 7 AM.
So when the first customer walked through the front doors
of that bank, they could do business.
Customers never suspected a thing,
but that's just how I wanted to kind of wrap that up
and say, when you don't have something like multi-factor
or patch devices or EDR in place,
as of fallback, making sure that you have the proper backups
tested to ensure that you can do a full recovery in the timelines,
restoring the same amount of data that is acceptable of loss
to you within, again, everything is adequate to the business
needs, because in that case, ransomware was a minor issue
out there.
It was just, yep, we have ransomware two hours later,
we're back up and now we'll go deal with the residual effects
of that.
But no one knew about it.
It didn't impact their business.
They had no financial loss other than, you know,
having to do their cybersecurity insurance claim,
but that was the extent of it.
So.
I'd like to also add something to that,
is that you can do everything perfectly.
You can spend, you know, lots of money on all these tools
and layer defenses.
It's very important to do, but it does take one week link
that the attackers can exploit.
You know, you have to protect everything.
The attacker just has to get one thing right to be able
to compromise you.
The goal is to make the attackers job difficult that they'll go
to somebody else.
They don't want to spend 45 hours trying to figure out how
to get into your network where they could go to some guy
down the street and spend 15 minutes and then get the same
amount of money.
So, you know, you can do a lot of things right,
but it does take a lot of layering your defenses and making
sure that the right tools and people and things are in place
to help prevent it, because if a security person ever tells
you you are 100% safe, they're lying to you because no one is
100% safe at any point in time.
So, on that vein to kind of wrap us up,
so you've convinced me, I'm an IT admin.
I need all of these things.
How do I start that conversation with my C levels?
I mean, going in and asking, free tools are great and maybe
there are some out there, but you know,
sometimes you need to pay for those tools.
How do I start that conversation?
Yeah, one of the big things is just talking risk to the
business is security.
You know, we're not here to say no to everything, right?
We're trying to help just do risk reduction to organizations.
That's everything that cybersecurity is about.
And so, if there is some type of risk to the organization of
saying, we don't have great backups today,
so what is the impact if we lost data today?
You know, maybe our backup server completely crashed and we
weren't able to restore data.
What does that cost the business?
Is it $20,000?
Is it $100,000?
Whatever it is for all that data that you lost.
That's one thing.
Now, if we said we have solid backups,
but it's going to take me two weeks to pull all this data
from, you know, tape drives or something like that because
we're still using a legacy version of it.
What does your business make within two weeks?
Calculate that and say, that's how long we would be down
and not generating revenue.
Now, that might be $50,000 a day.
It could be, in some cases, we know customers that are
generating $1 million a day of revenue, right?
So, that very, very quickly will pay for your backup solution
there.
Same things with EDR, right?
Is if we know that these are so successful at preventing
things like malware and, you know, everything like that,
taking what, again, whatever that downtime is
for some type of security incident and whatever the cost
is to go bring in a third-party forensics, third-party
incident response firm, that'll very, very quickly start paying
for those tools.
But taking everything and correlating it back to the risk
and operations of the business is critical.
It's not just going to them and saying, please give me another
$3,000 or whatever it is for the solution.
Show them that you're trying to help keep the business
operational and moving forward.
Nate did hit on it quite a bit.
I would say putting it into dollars and cents
because to a C-level person, they don't care that, you know,
all these bits and pieces of all these ways the attackers
can get in.
You know, if you put in that perspective of you're down
for two weeks, how much money you're losing,
this tool is one 1,000th that price.
Let's talk about it.
The thing our CISO likes to say is the boiling frog analogy,
I guess.
It's, you know, you don't throw a frog in boiling water.
You put them in the pot and you turn the heat up.
So let's get the MFA.
Let's get the EDR.
Let's put those in place.
Make sure you're in and you're good.
And then slowly work your tools upwards.
I wouldn't say to buy all the tools, all the whiz bangs as
fast as possible because you're not going to know everything
about every tool.
You're not going to make sure everything's all in place
because you have all the things you're dealing with.
Make sure that you have the best thing for your dollar
and make sure that you have it well configured before you
move on to something new.
Yeah.
This is, this will be as you're wanting to be a little bit
more mature on the risk conversations,
but there is something called FAIR.
It's a FAIR model.
And what it does is it takes it, takes risk and tries to
quantify that whatever the total loss is.
And then you can start helping take that model to talk about,
you know, what's the cost?
What's the impact?
What's the likelihood of these different security threats
and then help, again, quantify and better communicate that
to the business?
Well, thank you both.
Thank you, Dean and Andrew, for joining us today.
If you liked this podcast, please like, subscribe,
reach out to us.
If you have a question or topic you'd like us to discuss,
you can email us at info at cit-net.com or head out to our
website, cit-net.com slash podcast.
And we'll be back next week with an all new episode.