You found the backup wrap up your go-to podcast for all things
backup recovery and cyber recovery.
In this episode, we tackled the critical topic of incident response plans.
Once again, we've brought our resident cyber expert, Dr.
Mike Saylor from Black Swan Security, who starts by defining what an IR plan is and
how it's different from DR and BC plans.
We then talk about how you need different kind of response plans
for different kinds of incidents.
Like a cyber attack versus a failed RAID array.
We also delve into RACI diagrams and how they define who is
responsible, accountable, consulted and informed on any incidents.
Then we dig into where this plan should live and how you should make sure you
have access to it and the bad guys don't.
This is a packed episode I think you're gonna really like.
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 this topic for over 30 years.
Ever since I had to tell my boss that our production database was toast
and there were no backups of it.
I don't want that to happen to you or anybody, 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.
If I can ask you for just a quick second to go, press, subscribe or
follow so that you'll always be able to get our content, that would be great.
I am w Curtis Preston, AKA, Mr.
Backup, and I have with me a guy who keeps trying to get me to watch
this weird new version of the Lord of the Rings Prasanna Malaiyandi
ah, yes.
And you still have not seen it, although I did.
So my parents, so what I'm referring to is there's this new, it's not
even a Bollywood movie, I think it's technically a Telugu movie.
It's so tollywood, but it is called ky, A 2398 or something like that.
So it's supposed to be Yes, very.
Fantasy oriented.
Supposed to be really good shot in the modern day era or actually in the future.
And it has some pretty famous actors.
So from both the Telegu scene and the Thumb, and also from Hindi cinema.
So pretty much star in all star cast.
But I've been asking you, my parents actually went and saw it.
They said it was like three and a half hours and it was really long, but.
That might be like a.
couple naps.
Yeah, but it might be a couple naps.
for you, But it's only one episode or one movie.
I've been also trying to get you to watch Bahoo Bali one and two or the beginning
yeah.
That's the Lord of the Rings.
When I was talking about though, isn't it?
Oh, that's y.
Oh, you're right.
That is the Lord of the Rings
and that's like seven hours.
That's like seven hours long.
that's six hours.
But, uh, my wife and I, we did watch it y or over the weekend and so it's fine.
And it's really good though, Curtis, you should watch it.
You have until August 6th.
Uh, okay.
So as of this recording, I have one week to watch it.
Yes.
All right, well, we have with us again, our, um, can, can we call you our,
our resident cybersecurity expert?
Can
I feel like I've, I, I, I feel like I do reside here now.
I think so we've done enough episodes.
Um, so, uh, the CEO of Black Swan Security, Mike Sailor,
welcome to the show once again.
Thanks guys.
Great to be here.
So this week we want to talk about, we talk a lot about this.
It comes up a lot, uh, you know, in shows.
And everybody says you need a response plan, right?
And, uh, you know, an incident response plan.
And we talk, some people talk about a ransomware response plan, a cybersecurity
response plan, an incident response plan.
Can you just help?
Define all of those, like what, you know, do they, do they fit?
And, and of course I talk about a disaster recovery, uh, plan.
Where do all are, are these like Russian nesting dolls?
Well, and what's an incident response plan to start with?
Yeah.
are Russian nesting dolls.
Uh, so an incident response plan is what are you gonna do in the event that an
event, in the event that an event occurs?
you then classify as an incident.
And so first part of an incident response plan is, how do I do that?
You can't, you, you gotta define the difference then if
you're gonna use that event
That's where I'm, that's where I'm going.
Oh.
part is, the first part of, of your incident response plan is how do
I, how do I intake an event report?
Uh, could be smoke, it could be, uh, my computer's acting weird.
It could be.
Um, the website's down, uh, and then how do I classify that event as a type of
incident and then as a type of incident, what, what level of incident is it?
1, 2, 3, or, or however your organization classifies things.
And so the first part is that that analysis and categorization of an
event into, uh, an incident and, uh, incident type and criticality.
Right, and, and then
go ahead.
So then you have an incident, and based on what that incident type is, you
would have what's called a playbook.
So that playbook could be ransomware, that playbook could be denial of service,
the website's down, uh, operational, you know, uh, outage type of playbook.
Uh, or it could be, uh, misconduct, uh, you know, employee, employee misconduct
or trying to access stuff that shouldn't, unauthorized access type playbook.
Um, and you would.
You, you would do an analysis of your organization's most likely threats
and build playbooks based on those.
And then playbooks are like we've talked about in the past, just
sort of everything documented.
Hey, if this happens, here's all the people involved.
Here's all the steps that everyone takes.
Here's who's responsible for what actions, here's who I have to
talk to, and all the rest of that.
Right.
And here's who needs to be informed.
Right.
At least an outline.
Uh,
something's better than nothing.
And then, and then back to Curtis's question about disaster recovery.
And how does incident response plan it?
It is nested because an event becomes an incident and an incident
can then become a disaster.
'cause essentially a.
The, you know, you have a Dr.
Runbook, right?
Or a play, you know, you're saying playbook, playbook,
runbook, same thing to you.
Yeah.
It is.
So, um, it, it's a, I I think of it a, a bit like programming where Dr.
Runbook is, you know, is a function, is a library that can
be called by the bigger program.
Right.
So that, that to me is like the.
The, the deepest, nested part, right, because only after we've had an
incident, we've classified an incident.
We've classified it as a cybersecurity incident.
We've classified it as a, it's a ransomware event, and it's a
ransomware event that needs restore.
Right now we, you know, and then we have done our preparatory steps that
we need to do because, you know, I talk about a lot about this a lot,
and that is one of the big differences between a disaster recovery response
and a, a ransomware response is that almost always the disaster is over.
Right.
The flood has receded.
Um, because you, you can't start, you can't start your recovery
until the flood has receded.
The winds have stopped, the earthquake is over, the fire has
been put out, whatever the disaster was, it's over call the DR person.
The, the big difference with a cyber event is that the attack is ongoing
and you've got to put that fire out.
Uh, to, to use that analogy before you can ever call the DR person, and that's why
I'm saying it's sort of the most nested within, within the, the nesting dolls.
What do you think of that comment?
Completely agree.
And, and just to add a level of complexity with regard to backups,
uh, during your incident response.
If it's a ransomware where there's some compromise that happened
that led to the ransomware, then you've gotta make sure then also
that the backups you're restoring don't also include the compromise.
That you're trying to,
to tie off?
Correct.
lot more, a lot more attention to detail and, and analysis, uh, during
an incident than for sure, than, than, uh, cleaning up after a disaster.
So you have these, so you said you take the event, you identify it,
you put it into the right bucket of incidences, and then you.
Put a severity alongside it, and then you just sort of execute
your incident response plan.
Now, are these like, I am sure it's hard to cover every single incident
and severity or priority, right?
That goes alongside it.
So how do you sort of decide like, which ones am I actually going to
create an incident response plan for?
Which ones do I not need to?
Because it all comes down to.
Like resources in the company, right?
It does.
And, and that's where you're gonna start.
So in, in your incident response plan, and this, this goes.
Kind of back to the left a little bit in understanding the business
and the, the way it operates and how technology supports the business and,
and all the critical components of, uh, where, where the, the business
revenue and, and, um, focus is.
Uh.
Create an inventory of, of your, of your resources, both on the IT side.
We should already have that, especially from a disaster recovery perspective.
And I'll add this comment too.
If you have a mature disaster recovery plan, then a lot of
the work that you're gonna.
Put into creating your incident response plan should have already been done.
I've got an inventory of all our, our IT assets and where our data is
and the SLAs for, you know, if this machine's offline for an hour, we, we
lost a million dollars type of thing.
Well then, and the, and the, the resources we need to address those
disaster recovery activities.
Who's the sy?
Who owns that system?
Who's our network administrator?
Who's our active directory?
Who's who?
Who's our website?
You should, you should know who.
All those subject matter experts and stakeholders and owners are both on
the IT side and the business side.
Right?
So understanding that, um.
That environment of resources is critical to being successful in incident response.
All right, well then to your question about do we, you know, we can't possibly
have a playbook for everything, but what, what you'll learn, especially
after you, you do your first playbook and your first tabletop exercise,
is that there are very common
elements of every incident response.
You've got a leader.
That knows how to, that understands the environment and knows how to
categorize an event appropriately.
And then from that categorization of incident and priority can assemble
the right people from this inventory of resources to be effective
at responding to that incident.
You know, if it's ransomware, it's kind of an all hands on deck thing,
but if the website's down, I, I already know, I, I can look up who to call.
I need our
ISP, our host, our hosting site, the the person that wrote the website,
the person that knows all the backend systems that support the website.
I've got all that hammered out, and we'll get on a call and I've got their phone
number and their email and where they live and account numbers and all that stuff.
So you don't have to basically cry wolf every single time.
You don't, and you, and you should not.
Uh, so you know when, when an incident happens and, and or an event happens and
you're like, this is a true incident.
You don't go push the button.
You, you, you call the next person and get some, some, some feedback and
some collaboration, uh, and then you start to expand the team as necessary.
You don't, you don't call everybody to the table for every answer.
and, and I think you, I think you.
You mentioned this a little bit earlier, but I just want to, um, you know,
when you, when you said that a lot of the work would've already been done,
if you have a DR plan, that's great.
If you don't have one, uh, that's not good.
But, but I want to say that if this is the first time you're
doing any of this kind of work, the really key first thing is the BIA.
Right?
It's like.
Because, you know, as nerds as it people, we, we, we very often, we, we
focus immediately on the, you know, the cyber aspect or the recovery aspect
or the backup aspect and you know, how are we gonna get our network up?
Okay, okay.
We need to figure out what actually matters, right?
What makes the company money?
What's going to cost the company money when it's down?
Right.
What are things that we can do without and, and how long and
how long can we do without them?
Uh, how much money are we losing when this part of the company is down?
Right?
Um, and when this part of the company is down, is there something else that
the people that work on that part of the company can do to continue
to make money for the company?
Uh, or do we just send them home?
Um, you know, so they're not twiddling their thumbs.
and Curtis, when you said BIA, you meant business impact assessment, correct.
you.
Thank you.
What do you, what do you think, Mike?
Any, any additional.
Absolutely.
And so the BIA is valuable in so many ways.
BIA will help you on your insurance.
It helps you on your business continuity, your disaster recovery, your incident
response, all your risk assessments.
It's, it's very critical.
And any, any due diligence for like acquisitions and mergers and all
that stuff, it's, it's very critical.
It's also a good, uh, it's also a good tool for process.
Uh, improvement and overhead analysis.
Uh, it, it's, it's, it's really good.
Well then, uh, to touch on something you mentioned, uh, you know, if,
if this incident, or if this event happens and people can't do their
work and you send them home, or what else could they be doing?
Uh, that also touches on business continuity.
So how do we keep running the business without technology, which is really
what disaster recovery focuses on.
Business continuity is that.
that.
that contingency plan for, you know, I can't use the phone anymore or, or
that system's down and, and now we've gotta revert to pen and paper and,
uh, how do I, how do I keep taking orders or scheduling
repairs or whatever the case might
Somebody go find a big box of carbon paper.
Yeah, like Curtis's, uh, doctor's office or
that direct show that happened in the Midwest summer.
Remember that episode Curtis?
Yeah.
The derecho.
Yeah, that's a great episode.
We, we, we did have somebody on here who, who lived in a place,
um, and they experienced a derecho.
Have you ever even heard of a derecho?
I've heard the term, but I don't, I'm, I'm assuming It,
it's a,
it just means a, a hurricane that forms over land.
Um, don't have any idea why it's called what it's called,
but that's what it's called.
Um, so yeah, so we've done our, our business impact analysis.
We, you know, we, we, we know all the parts.
We know the.
We know where to focus our efforts.
And then we need to focus on the things that are likely to happen, the things that
are likely to give us the biggest impact.
And, you know, persona you talked about, you know, we can't do everything.
We talk a lot on here about good, better, best, right?
Good.
Is to have something, to have some kind of outline for anything.
If you have nothing, anything is better, is better than nothing.
On a back of an napkin is fine too.
Yeah.
Um, and the what if you've got nothing, once you've done the impact analysis and,
um, you've decided on, you know, we're gonna focus on, I, I think it wouldn't be,
it wouldn't be crazy to say we're gonna focus on a ransomware event that takes
out our, you know, priority one servers.
What would be your next step?
Well, I'll add some, I'll add some color to that scenario because part of
your analysis may, may indicate that in the event of an, of an incident like
that, you cannot reallocate people.
Those people have to keep doing whatever it is they're doing.
So your incident response plan should identify resources that you
can bring in to augment your staff.
And address the incident or vice versa.
Maybe it's your, your full-time, people addressing the incident, but
then you need to bring in staff, you know, some contractors to continue
daily operations or whatever that is.
Or that you've got zero capability of responding to that incident and
you've gotta bring in a third party, 100% to, to support and you're just
providing them guidance or oversight.
And I mean, it's, it's kind of like, uh.
The, the flood, the flood response, the blackman mooring or whoever it is
Yep.
where you've got a flood.
Nobody, I don't know how to clean up a flood or respond to a flood.
I know how to, I may know where the water shutoff valve is, but 100% of that
response is gonna be some third party.
And so that business impact analysis is gonna help you determine.
What proportion of inside, outside, you know, extra help you're gonna
need and who's gonna do what?
All right, so then, then the event happens, uh, and you're gonna, you're
gonna use that resource playbook depending on what that that event is,
um, to bring in the right, the right resources, the right people, and,
and start managing that response.
So.
If you'll have your playbook or your incident response
plan, you've executed on it.
You knew who the resources to pull in.
I'm sure along the way, as you're going through this actual event,
you probably see some gaps.
Maybe you're probably fine tuning, tweaking, adjusting, adding to
your incident response plan to update it so the next time it
happens, you're better prepared.
I guess the one question I have is.
Environments change.
We've always talked about it, right?
New systems come on board, new sites come up, new applications get deployed.
There are new threats out there.
What sort of frequency should people be thinking about going and revisiting
their incident response plans?
Because it's not helpful if, say, today, right?
You have an incident response plan for how to deal with telephone communications
from like 30 years ago, right?
So how do you make sure that your plans are also up to date as the
world changes, as your environment changes and as the people change too?
as a, as a good, as a good practice, good governance would be reviewing
all your policies, procedures, and plans at least once a year.
But I'll, I'll caveat that with any significant change to your personnel,
your environment, or the way your business operates should then dictate a
review of all the things that support.
And, uh, not only support all of those things, but also support the response
activity to any, any related incidents.
Uh, so as often as it makes sense, but at least once a year.
Okay.
And I'll, I'll add to that too, that there's often two types
of incident response plans.
There's the very technical one with the playbooks and the contact
information, the technical details.
That's for the.
The internal response team consumption.
And then there's kind of a general population incident response plan,
which is more like a guide to, well, how do I report stuff and what do
I expect?
And,
um, you know, some that, that same plan may also include a provision that says you
as an employee or contractor may be called upon as a subject matter expert to help.
Respond to an incident.
And
so putting all that, all that stuff out there as far as expectations
and guidance in a, in a, a shorter,
you know, kind of condensed manual,
similar disaster recovery, you know, there, there's like your evacuation plan
and then there's the tech, the, the, the true disaster recovery plan
that has a lot more detail on it.
I like the idea of, I, I think one of the most crucial elements, if not the very
first element that goes into an IR or DR plan, is the, the contact list, right?
Who do you call for?
What, who's responsible for what?
Um, what is Mike Sailor's cell phone number?
Um, you know, to, to call.
Because he's our guy to bring in, in the case of scenario, and again, you,
you, you have to update that information 'cause that stuff changes all the time.
Right.
Um, and
And, and don't.
Don't just Google Mike and his cell phone number and put it in your contact list.
Actually, you, you've gotta call these people and say
hello and
and you know, I'm, I'm, we need to, we need to establish a, a, a relationship or
a rapport so that you, you are, uh, you will answer the phone when I call you,
uh, and, and
know that it's important.
Yeah.
'cause I don't answer, I don't answer unknown, uh, phone numbers.
So, um, yeah.
Same.
Um, yeah, so we've got our contact list.
Uh, we've got our vendor list, right?
We've got our, um, all of tech, the technologies that are involved.
Um, and we've got an escalation list, right?
A list of what's go, who's going to be called when, and then also.
Who's going to be called when those people don't answer the phone?
Um, right, because I, I know that comes up in a, in a, um, like in a
tabletop, well, it comes up all the time.
Right.
Uh, Fred, who's the one that's responsible for A, B, C, uh, he's on vacation, right?
He, he's in Aruba.
Uh, good for Fred.
And he's taken an actual vacation and he is unplugged the cell phone.
And, uh, you know, and he's not taking our calls, so who's gonna take
Fred's call when Fred's not there?
That should be the case for every responsibility in the,
you know, in the company, right?
Uh, correct, and, and you should have a chart.
And, and if you remember from a previous episode, we call that a racy diagram.
That's right.
Yeah.
Uh, and spell that out again.
RACI,
responsible, accountable, consulted, and informed.
And so for everybody on your response team, you would, you would
indicate, and sometimes that changes based on what the playbook is.
Uh, but who's, who's, who are your primary responsible, uh, accountable
people for all the different types of incidents that you include, uh, in, in
your, in your, in your response plan.
Persona is the first person I call, uh, when I need to do something.
I don't know how to do, because I have this feeling that he
knows, he, he's watched a YouTube video about how to do it.
What does that seem, does that seem reasonable persona?
97% accurate, I would say.
he, he watches a lot of YouTube videos.
Um, all right.
So we have our, we have our, our list, our contact list, we have
the actual procedures, the actual runbooks that are, you know, the
different things that we're gonna do.
Uh, is there anything else that needs to go into response plan?
Yep.
So.
So at the, at the end of your response plan, you, you should
have as much reference material as you think is, uh, necessary.
So, you know, there's your, your instant response team contact list, but down at
the bottom, kind of to your point of, of third parties, but more than just
name and phone number, you may need an account number or a policy number
or, um, something specific, a pin.
Uh, you know, if there's, you know, multifactor, um, and then.
Something at the end.
Uh, towards the end, we have, I, I typically suggest appendices.
And so one of the escalation points of an incident is
whether or not it was a breach.
And the difference between incident and
breach can be significant
for a lot of different reasons.
What, you can get sued over a breach, right?
A breach might require that you, you
have, uh, reporting, reporting obligations to the state or.
What have you.
So then, so there's a, there's usually an appendix that helps you walk through
kind of a decision tree to determine if a, if an incident was a breach,
well then we've got all of this, you know, maybe, especially if you're a
publicly traded company, what are your reporting requirements, uh, by state,
by statute, and then some things that you want to pre, uh, pre-negotiate.
Is with, and this is with like management and legal or hr, how do
we communicate different types of incidents internally and externally?
And so having those predefined templates for emails or phone calls
already in your plan, so you're not on
the phone for an hour negotiating with internal audit or legal about,
all right, how are we gonna say this?
You've, you've got all that stuff outta the way.
So Mike.
So we have everything documented.
I think one thing we didn't cover is where does this document live?
Because right if, because if it's like on your normal internal systems
and you get hit with a ransomware attack, now your incident response
plans are also potentially gone.
If you get hit by a hurricane or a flood and you have it in
physical paper form in the site location, those are probably gone.
So.
How do people store these and make Sure.
it's still accessible?
I've seen a lot of variations of this.
I've seen the All right, who's, whose turn is it to take the metal
box home in the trunk of their car?
Uh, I've seen people store it with their tapes at Iron Mountain.
I've seen people, uh, uh, pay for a service where it's like a cloud-based
disaster recovery thing, where different stakeholders have the ability
to log in and update their stuff, and that's where the plan lives.
Uh, and then, uh, I've also seen some pretty creative, uh, approaches to this
with like $0 retainers with a, a law firm.
And so pre-negotiate, get all the paperwork outta the way.
And I would, I would suggest this with an instant response firm.
And, and even, uh, uh, you know, if, if, if your staff isn't capable of, of
quickly fixing or building or re-imaging stuff, then go find a, a firm that, that
can provide you those resources and, and get all the paperwork done today.
And, but to my point, uh, uh, or back to my point about the law firm.
So $0 retainer establishes and it gets all the deconfliction out of the way.
Uh, but send, give them your, your Dr and incident response plan.
And because you're gonna call them anyway,
uh, make sure that you've got their phone numbers, but you're, it's great.
Great point.
I've seen in a lot of cases where, you know, we're trying to, there's an
incident, we're trying to coordinate response and their networks, their
internet's down, their email's down and, and, you know, how do, how do we even
coordinate among their response team?
And so having a, having a relationship with someone that can.
That can provide you that, that communications medium, but also, uh, be
a, a good place to keep your, your plan.
Yeah, I, I, my personal preference is I like having an electronic version
because it's easier to maintain, but I also like having that paper version and
the way I like having the way I like.
Creating a paper version is in a loose leaf type of a notebook, so that allows
me, when I update a couple of pages, I can just rip out at those pages and
replace those pages so that I'm not printing an entire tree of documentation
every time I go to update the runbook.
Um, and I do like that idea of having it, having it stored somewhere else
other than the company, but close by.
Right.
If we're talking about actual paper.
It needs, you know, you talked about a law firm, you talked about an instant
response team somewhere that stuff is stored, that's accessible to us as a
company, but, uh, but not too accessible because it's in the data center that,
uh, that we're trying to recover.
Or at least a copy.
Right.
Store it somewhere
A copy.
Yeah.
Um, of course the more copies you have, the more trouble you
have maintaining those copies.
Right.
But the, the, um, the, uh, and I think the, the, the physical paper
issue is less of an issue during a cybersecurity event as it, than it is
in a, in a disaster where the, you know, the building blew up or was on fire.
But, I cannot overstate the value of, um, of a paper document, right?
In a, in an event that potentially takes out your, you know,
everything that you have, right?
I mean, I mean, I'm, you know, I'm a, I'm a huge fan of the
cloud putting stuff in the cloud.
Uh, what if you got no internet, right?
Cloud's, cloud's great, but you can't see the clouds anymore.
Yep.
So off switching topics, so we have the cybersecurity incident
response plan, which for company documents, who all the people are,
how they respond, and all the rest.
I.
This is a goldmine for malicious actors, right?
So if they got their hands on this right, they know your entire playbook.
It's like if you got the military plans for like the nuclear weapons and
like how things will respond, right?
So how, like how should people go about protecting these from these bad actors?
So it should be considered or classified as a, a confidential or sensitive
document, so password protected, you know, make sure it's stored
appropriately with restricted access.
Uh, but you're right.
In fact, uh.
We did a tabletop exercise on ransomware for a, an engineering company.
Uh, and then shortly after the tabletop, they actually had a ransomware attack.
Uh, come to find out the threat actors had been in that environment for six months
or actually privy to the tabletop exercise and had access to their instant
response plan and their insurance
policies and all these other things, which then help them better
strategize and facilitate the attack.
And.
Uh, which, and they got paid, you know, they, they made several million
dollars off of that deal because they were, they were informed, uh, and
they knew what the capabilities were.
They knew that they were gonna be, um, ineffective at responding
to a ransomware attack, um,
Yeah.
sure that you, you fix all the problems identified in a tabletop exercise,
and this organization did not.
Well, I, I think that's a great question.
P and I think it goes back to the same thing that we advise for
backup systems segregation, right?
Making sure that it's just not on the same systems with the same usernames
and passwords protected by active directory and an admin and an active
directory admin password, right?
It's gotta be more than that.
And, and that's, and I think that's where SaaS providers can be very helpful.
Right.
Uh, I like this idea, you know, um, that you talked about Mike, of having
a, you know, basically services that will, that they probably have, I.
Templates and things that you can use for an incident response
plan and help build it out.
It makes making that easier.
And then also it's, it's stored in a different environment than yours.
Uh, of course you gotta vet all their security because persona, you are 100%
right, that that would be a gold mine.
Just like backup systems are a gold mine.
You get, you get in charge of the backup system and you have, you know,
why, why hack all the servers when I can just restore the data that I want?
Right?
Um, any final thoughts, Mike?
Any final things we need to say about creating an an incident response plan?
Yes, the design of that plan will drive its effectiveness.
And so, uh, from an audit perspective, um, well, even more fundamentally
controls perspective, an incident response plan or program would be considered
a control, uh, that helps drive the effectiveness of your organization.
I.
There's two parts of a control.
There's the design of the control, and then there's the operational
effectiveness of a control.
And so we can put this plan together.
We can have all these whiteboarding sessions and phone
calls about who's doing what.
And we put it all in this document.
We feel great about it, but it doesn't mean a thing if you don't walk through
it to see how effective that design is.
And that's, you have to do table, you have to do an exercise to test
the effectiveness of your plan.
'cause like Mike Tyson said.
Yeah, everybody has a plan until I hit 'em.
And so your response plan is, that's all it is, is a plan until, until you get hit.
And if you don't, if you haven't, if you haven't walked through
it, you're not gonna know how well you, uh, respond to that.
That hit.
Yeah, I really thought you were gonna rhyme earlier.
You know, you something.
I forgot what you said.
It's, uh, you don't got that thing or something.
I thought you were gonna rhyme there, but, you know, uh, but I, yeah, I,
I, I thought exactly about that.
That Mike, that Mike Tyson comment.
You know, everybody, everybody got play until they get hit in the face.
Absolutely.
All right, well thanks again, Mike for uh, walking us through
and thanks again for some great questions this time.
Persona,
I, I think I'm starting to think more like a bad actor, which is kind of.
Fun.
that's what you gotta do, right?
Gotta think like a bad actor.
Absolutely.
All right, and thanks to our listeners, we do this for you.
Uh, reach out to us, say hi.
Go to backup wrap up.com and put in a comment.
I love getting comments from people.
Um, and, uh, you know, rate us go.
You know, if you love us, rate us.
If you hate us, don't.
Anyway.
Uh, that is a wrap.
The backup wrap up is written, recorded and produced by me w Curtis Preston.
If you need backup or Dr.
Consulting content generation or expert witness work,
check out backup central.com.
You can also find links from my O'Reilly Books on the same website.
Remember, this is an independent podcast and any opinions that you
hear are those of the speaker.
And not necessarily an employer.
Thanks for listening.