The business impact analysis is the thing that begins our
process of setting up the BCDR strategy.
This is going to be based upon the business's tolerance of loss of
their most critical assets. If you're like me and you've asked business
partners in the past, what's most important?
Sometimes the first answer that comes back from them is, everything. In
a jovial kind of way I have then followed up with,
well, what is the thing that you would lose your job for first? And then there's
the response of, oh, the most important thing. Just as if you were underwater
for 10 minutes, but you only had 5 minutes of breathing, that helps you to see
that there should be some definition for a critical asset that says based upon a
predetermined amount of time, I know that I can tolerate the failure of a
business resource or a business process. That's what the business is going to
return to you.
Another feature of the business impact analysis is this thing
called an RTO. ISO 27031 states that there is a recovery time
objective per resource service or activity.
It's the amount of time the organization has as a
goal to recover a disrupted product.
So, think of the MTPD as being a timer and think of
the RTO as being a stopwatch.
The RPO is related to the recovery of data to a point that
meets organizational validity and integrity.
So the RPO is related to how far back into the past an
organization must go in order to have a reliable replica or a
copy of reliable data to continue the business.
This could be information that is inside of a backup, so
it's not measured in storage amount, it's measured in time.
Here are some things to think about as you're
questioning what the BCDR strategy looks like.
What is the recovery point objective as defined by the business?
What is the amount of data that they can tolerate losing? In a
financial institution, it may be measured in seconds of time or
minutes of time. In some other organization that does not have the
need to have the last known good transaction so tightly bound, it
could be measured in hours or in days.
What is the RTO? Here again, we're focusing on the recovery time of a system.
Think of the RTO as being a virtual machine that is restored.
Think of the RPO, recovery point objective, as being the data
that is restored from some type of backup.
What are the kinds of disasters that you should include in your threat analysis?
Remember how we talked about this idea of a qualitative or a
quantitative analysis? Both should be employed here.
So now, let's consider what the cloud‑based BCDR options could look like.
Again,
it's not exhaustive, but it's at least three general ways of thinking
about containing the resiliency in your organization in the cloud.
Cloud‑based BCDR options are three in number, again,
generally speaking. You have on‑premise operations and then you're
using the cloud as BCDR. You are a complete cloud consumer, so your
primary provider of BCDR would be the cloud, you've left the
datacenter. Or, you are a cloud consumer with an alternate cloud
provider as your BCDR option.
So, let's take a look at what does that appear as. On‑premise, Cloud as BCDR
means that your primary mode of operation is the datacenter. In your BIA what
you've done is your business impact analysis has shown that based off of a
threat of actually losing this datacenter,
the recovery point objective and the recovery time
objective are actually going to be things that we measure
out to some type of cloud service.
So, we're backing up those critical things to the cloud.
If in fact there is a disaster that takes place with that datacenter,
then we would go to our alternate location and we
would do our recovery from the cloud.
How about you are primarily consuming from a cloud service provider?
Well,
in this case we're actually using the native
replication capabilities of the cloud.
You'll recall an availability zone represents one or more datacenters.
If you onboard workloads from a particular availability zone,
then there is replication, obviously, that is
occurring within that availability zone.
But, between availability zones within a region,
you could also have replicas, depending on the type
of workloads that you are using.
If one of those availability zones should go offline,
you could without any hesitation be consuming and retrieving
services from another availability zone.
In fact, if you set up some type of load balancer across availability zones,
you would not even have to know that you lost a particular availability zone.
If I am a cloud consumer and then I'm using an alternate
location as my BCDR, then what I'm going to have to do is
make sure that the interoperability, the format,
the semantics between the formats of data and also of systems has
some kind of congruency between those two providers. Because if I
lose my primary, I should be able to automatically be consuming
services from my alternate provider.
Primary activities that are associated with BCDR would include recovery,
which means that the team that gets activated is actually focused on the
alternate location and they're trying to bring up systems from the most
critical to the least critical. And restoration,
which means that you have a team that's actually doing work at the
primary location to bring that primary location back online.
Recovery activities begin in prevention.
We're trying to protect from threats such as environmental hardware failures,
operational errors or malicious attacks. Detection says that I'm detecting
incidents at the earliest opportunity to minimize the impact to the
services. Response is the imperative part of the first action that says that
the recovery team may need to communicate on a regular basis with the
executive emergency management team to give them an analysis of how bad
things are. And then, moving into the recovery activities, where you follow
the appropriate strategy and you prioritize the most critical services get
reinstated first, and an ongoing improvement of all of these capabilities.
Working in parallel to recovery would be restoration. Here, in the
restoration activities, we're thinking about what the original location looks
like. If it was a disaster, it may mean that number one,
it was uninhabitable for people.
So getting a certification of restoration to a new normal may
actually be something that the focus says it's not the original
location, we're actually operating in a new space,
sort of like what happened in downtown New York City after 9/11 for many
companies. Why is it that we go in reverse order and return the critical systems
last and the least critical systems first? Number one,
because we don't want to impose some kind of conflict with the site
that is in operation at the recovery location.
And number two, even though it's been certified,
we don't fully trust that previously uninhabitable environment.
It's also in concert with the recovery.
So these are parallel activities.
It may seem counterintuitive, why would we do this?
One of the things is that we no longer have BCDR capabilities, do we?
So, we want to ensure that we get up that original location as quickly as
possible so that we can still have BCDR capabilities.
Next, join me over in the process of creating,
implementing, and then testing the BCDR.