Preparation inside of our networks is a
key for determining or for incident response.
We need to understand that the key concept of
preparation is preparing for the worst case scenario.
We often see this in different aspects of policies and procedures.
But the technical and non technical steps we take
could save us a lot of time, effort and energy as well as cost for future problems.
Preparation is truly key in our security industry.
An incident response plan or IRP serves as a central document
for managing the entire incident response process within our organization.
Its policies outline the requirements for the plan and assigns roles,
responsibilities and typically remains concise,
establishing an internal governance necessary for building
the incident response capabilities within our organization.
An incident response plan should be broad enough to
where it impacts the entire organization as a whole,
identifying key roles without identifying people.
We want our IRP to say the director of Blank or this technical department.
Does this or you get the picture? We won't want to identify that.
John Smith,
the director of engineering is going to do this that
sets us up for failure ne broad enough in scope.
Yet singular and notion to where we can quickly identify the person or persons
responsible within the incident response plan to
accommodate for what we're trying to achieve.
It's important that the process to develop
during the incident response plan is communicated properly
and need to be vital and executing effectiveness.
And the incident replies needs to have a variety of
team members and stakeholders involved to ensure that it's adequately.
We're providing the specific needs of the
industry or of the enterprise environment.
This makes it more manageable,
it has more effective communication processes and it's best to
have internal and external stakeholders involved throughout the entirety.
Effective internal communication is critical and
often facilitated through a command center.
This serves as a hub for decision makers and
stakeholders and provides updates and feedbacks to response activities.
If you're in the middle of a disaster recovery plan and your
workers don't know where to communicate
or to facilitate communication transparently,
that could lead to some real problems.
During a hurricane.
One time, I was out in the middle of the field, fixing telecommunication
equipment only to find out that there was no command
and control infrastructure in place that I was aware of.
I contacted my manager but obviously his cell phone didn't work.
I had to call all the way to Georgia only to find
out the Georgia had no idea what I was talking about.
All they knew was that half our systems were offline
and they had no idea what was going on.
Having an effective communication and command and
control outline for internal communications is paramount,
making sure that we have an
incident response plan focused with precise communication.
We also have to have alternate communication needs
because of that problem that we face.
During that during that telecommunications issue,
we were all assigned satellite telephone with known command and
control lines that we can communicate up the line.
If one of the one of the tracks of communication were no longer available,
we need to have external communication both during the
incident response and after the incident response and this
needs to be managed by trained professionals to avoid
misleading information and ensure compliance with regulatory bodies.
Again, while I was with the telecommunications industry,
we had a problem where telecommunications and 911
services weren't operating properly that needed to be properly
communicated via external communication up the line so
that the FCC was aware of our issues.
We had a fiber line cut one time between Phoenix and
Flagstaff where served all the communication needs for Northern Arizona.
The FBI need to be involved as well
as some other agencies to investigate the problem.
However, as a member of the telecommunications industry,
we were responsible for actually fixing the issue.
Those external communications need to go through the right offices at
the right time to report properly for compliance and regulatory needs.
Training is often overlooked and is the groundwork for
effective response regardless of where it's coming from.
You need to understand
that it's not enough just to have an incident
response plan in a bookshelf somewhere collecting dust.
I can't tell you how many organizations I've been with where I go
in through the in boarding process and I'm looking around and they're like,
oh, read all these documentations about our different policies,
but there's no incident response plan on file.
When you finally ask for one,
it's pulled out of some shelf out in the middle
of nowhere and no one even knows what you're talking about
hasn't been updated in over a decade.
This is quite often a problem,
especially with large enterprise environments that don't have
a lot of incidents occurring throughout the years.
In many cases, non
technical staff make up the majority of
an organization and invariably these users will
be the ones who are exposed to the signs of potential security incidents.
We need them to be aware of our security incidents and
how to evaluate or how to report those incidents up.
It's not
unforeseen for a user to click on a phishing link and as
soon as they click on it to realize they made a mistake,
it happens all the time.
We need to be aware of those issues and train them properly so that they can report
up the chain and effectively communicate that they actually
screwed up and we need to fix it.
It's far better for an employee to report it right away than for us to get it
after the fact three or four days later
because our systems weren't picking it up properly.
An incident response plan must be tested and it must
be test at least annually throughout your entire organization.
This is critical for developing proficiency and dusting off the
book to make sure that everything is up to date,
that the organization hasn't changed since the
incident response plan was put into motion.
We need to provide exercise to evaluate the plan,
the procedures and the personnel readiness and these exercises should
include document reviews to make sure they're set up properly.
We should be able to do tabletop exercises where
the team gets together and they simulate responses.
The hypothetical situations
we can do walkthroughs where participants familiarize themselves with response
steps and roles without involving the actual equipment or data.
And finally,
we can do full scale exercises where we
literally shut down machines to see what happens.
When I, again, when I was in telecommunications,
we would often shut off power to a facilitating
site to see if the generator would kick in.
And we were required to do this for some sites at least every 30 days.
If the generator failed to kick on our battery backup system should,
if they didn't kick on the site would just go dead.
But you get my point.
We sometimes need to do a full scale exercise to ensure that everything
is working properly in the way that we identified it or managed it.
Disaster recovery plan or A DP is a
structured approach aimed at swiftly restoring it systems,
data and infrastructure host a disruptive
event to minimize downtime and maintain business
. We're gonna talk about a business continuity plan in a second,
but you need to understand that a disaster recovery
plan is not the same as business continuity plan.
Well, yes, a disaster recovery plan can be utilized in a business continuity plan.
A disaster recovery plan is of its own making.
This identifies the different recovery strategies that we can utilize how we can
utilize different resources and acquisition of parts and even labor if needed.
Once we've identified a disaster recovery plan, it goes through a risk assessment,
identifying the different risks that we expect to see within our own environment.
When I was in Phoenix Arizona, we weren't worried about hurricanes or tornadoes.
It wasn't something that our disaster recovery plan really planned for.
Yes, there was a side note in there that basically said we would follow
the overall arching plan that the organization had set forth.
But I can't tell you the last time we actually looked at that plan
because we haven't had a tornado or a hurricane ever in Phoenix Arizona.
One thing that we did have was a heat disaster recovery plan.
We identified very strategically.
If the temperatures inside of our internal server room reached
a certain temperature and the systems did not work properly.
The exact details of what we were supposed to do in that event
and we went through the entire process on a day to day basis,
especially during the summer to make sure we were aware of those plans.
I remember every May before the summer started to
get really hot that we would make sure that our
ac repair guy was on the line and realized that
our sl a was one hour for specific sites.
We need a business impact analysis.
What is the impact of this critical function going down? If I have an inter
server room going down, the impact could be very high.
We need to understand the business impact and
identify which prioritization takes precedence in real disaster.
If you have a hurricane hitting Florida,
there's going to be certain points that are more important and
have a higher priority because of business impact than others.
It's just a matter of doing business.
We need to have recovery point objectives. What if this happens?
How often should we or how soon should we recover from this issue?
If I have a hurricane in Florida, we expect the server room to go down.
How long should it stay down before we go over and, and fix the issue?
That's a recovery point objective.
We need to have data backups and recovery in place.
When I say data backups, what I'm talking about is how often do we back up our systems.
Sometimes those backups are nightly, sometimes they're weekly,
sometimes they're monthly.
It really depends on what data we're storing and
how important that data is to the system overall.
And how do we recover from that data?
We've gone over this and security plus many, many times.
So I'm really not going to go that into depth with it
just to understand that data backup and recovery is a real thing.
When it comes to disaster recovery,
we need to have response procedures and reduce allocation or resource allocation.
If something occurs within our systems.
If I have a hurricane that's expected to hit the Florida line,
I need to have resources on standby to fly into Florida.
If flooding takes place. How are those resources coming to play?
How am I going to get those resources if the roads are closed down?
What happens if air flight isn't available?
The overall
resource allocation needs to not just be assets but people,
they need to be identified ahead of time.
If Florida is gonna get hit by a major hurricane,
it's not behooves us as an organization to say, hey,
let's pull from Alabama and Georgia,
maybe even New York or Phoenix to facilitate having more resources on
the ground to bring those systems back online sooner rather than later.
If something were to occur. And finally training,
we need to understand that people need to be trained.
Nothing's worse than having a bunch of professionals.
That have no idea what they're doing.
Even though in a normal day to day occurrence,
they would have no problem operating at peak performance.
Training is vital to make sure that people know what they're doing,
who they're communicating with and what their expected actions
in a disaster recovery.
Are we expecting people in the Florida area to come into the office? Next day,
I was an organization where if we had a disaster,
an environmental disaster take place.
We were required within two hours to call into an 800 line to
let the company know that we were available and that we were safe
once they identified that they may hit us up and say, are you able to come to work?
That was part of our training and our response plan.
I was further responsible for very disaster recovery aspects.
In which case, if something occurred,
I was expected to go fix the issue and be
able to stand by myself without direct communication within the
department and fix any various issues that I may identify.
This is part of our disaster recovery plan and you need
to be trained properly to be able to take those actions.
What are you allowed to do? What aren't you allowed to do?
And what are your expectations?
A business continuity plan refers to an
organization's ability to continue its essential job functions
and operations during and after any disruptive incident or crisis.
This isn't just a disaster. We're not talking about hurricanes or tornadoes.
This can mean a terrorist attack.
It could mean the servers drop off air because of a patching problem.
It could mean any number of things,
but a business continuity plan is very broad at
its scale but details very specific incidents that are occurring
within that.
We could see notions of technology failures,
cyber attacks or even disasters because disaster
recovery is part of business continuity.
While a disaster recovery plan is specific to disasters,
a business continuity plan is more designed around an overarching structure.
We can use a lot of the same resources
that have been allocated for AD RP within a business
continuity with the expectation that both are going to occur simultaneously.
And this happens quite a bit.
However,
the main goal of AB CP is
to minimize downtime and protect the organization's reputation
and thereby its finances. We need to maintain
caps consumer confidence and ultimately assure the organization's
survival if it's faced with an adversity action.