All right, let's take a look at
Module 21, which deals with business continuity and disaster recovery.
It's incredibly important.
It's often overlooked.
It's often under driven.
It's often out of date.
It's often inaccurate in what looks good
on paper and what actually can take place in restoration procedure.
Incredibly important.
It needs to be properly planned, properly
updated, properly practiced or trained on in a continuous basis to ensure that the
business can continue to function in the absence of availability of critical
resources or outages or whatever the case may be.
This is a very important subject.
I cannot understate that.
The problem with a lot of business
continuity and disaster recovery plans is that they're extremely outdated.
Business disasters and catastrophes don't happen very often, so you can get a false
sense of security that if it did happen, we'd be able to restore.
When you've developed your continuity plan, your disaster recovery plan, it's
been sitting on a shelf gathering dust for four or five years.
Once this is developed, first off, a
company without a business continuity plan, disaster recovery plan is
hugely vulnerable to potentially going out of business forever.
A lot of companies operate in really thin margins, and you'll see statistics like 90
% of the companies on the planet, if they had to close their door for seven
days or longer, would shut their doors entirely.
Now, we've seen a lot of resilience,
especially in the recent years with the pandemic.
I think we've seen a lot of unexpected resilience.
We've also seen a lot of unfortunate closures.
But some of this stuff we can really plan for, some of this does come a left field.
Nobody really expected a pandemic of this magnitude.
But things like regional disasters and
floods and hurricanes and so forth happen on a pretty regular basis, and we
can pretty adequately prepare for those situations.
First off, business continuity planning,
or BCP, is often seen with the /DRP, which is Disaster Recovery Procedures.
BCP/DRP, they're the same conversation. They're different, though.
Business continuity planning is ensuring that the business entity is
able to continue functioning in a disruption.
We have disruptions, we have catastrophes, we have disasters.
Disaster recovery planning
ensures that the assets or the resources that the business entity relies upon
are restored and usable again in a disaster, catastrophe, or a disruption.
Let's go ahead and define disruption, disaster, and catastrophe pretty quickly.
A disruption is a minor hitch.
Hard drive fails in a server, that's a disruption.
Does that mean we have to pull up stakes and move to an alternate site?
Not at all.
That means we're going to put another hard drive in or let the Raid Subsystem
compensate for it, but a disruption doesn't affect the entire facility.
A disaster renders the facility unusable for a day or longer,
and a catastrophe destroys the facility, meaning that when you resume operations at
an alternate site, when you resume back to the primary site, it's no longer there.
You have to plan for new construction or relocation to a new location.
You want to consider local regional disasters.
We're going to talk a little bit about subscription sites.
I'm going to throw some things in here
that we don't necessarily see directly referenced in the slides
that I like to talk about when I talk about business continuity planning.
Bc describes the process and procedures
followed by the organization to ensure continuity, ability to perform critical
business functions during and after disaster.
An ISO standard defines it as the
capability to organization to continue delivery of services and products
at acceptable predefined levels following a disaster.
Who determines acceptable?
Everybody all together now, senior management.
It's business centric strategy,
emphasizes more on maintaining business operations than IT infrastructure.
So, the DRP is mostly the infrastructure.
Okay, the first thing you do is an
organizational analysis, which we're going to have a slide that illustrates that.
But you'll do a risk analysis of the organization.
We'll call that a business impact analysis.
But the first thing you have to do is figure out how do we do what we do here?
It sounds like an obvious question,
but you'll be amazed how quickly you're going to get to it.
I don't know.
So how does this system work?
I don't know.
Bob actually implemented that, and he's been retired for four years, and it's a
Unix box and nobody ever pays attention to it because it just keeps running.
I don't think we've ever rebooted that thing.
You're going to get to a I don't know or
unfamiliarity with how something works, how are you going to be able to
reconstruct something if you don't know how it works.
This is a great opportunity to fully document how everything works,
how it can be restored, and also allows for a possibility of updating
legacy systems that may not be restorable in the event of a disaster and disruption.
The first thing you're going to look at is what do we do here?
There're different models for doing that.
ZAP and frameworks and models, which define the who, what, where, why, when,
and how do we do things here at X, Y, Z company.
The first thing you look at is what do we do here?
Oh, we improve quality of life through
innovative polymers and plastics development and so forth.
No, no, no, no, no, no. What do we do here?
Oh, we make money.
You look at how the organization generates revenue, which is what keeps it going.
That makes it possible for them to fulfill their mission statements and business
objectives and philanthropic operations and so forth.
But if you're not generating revenue, you're dying.
That is the lifeblood of any organization.
How do we make money?
What are the critical processes for making money?
How do we keep that going?
You will prioritize those processes based
on how they contribute to generating revenue.
When you say it like that, it sounds very
materialistic and so forth, but it's a fact.
That's what drives corporate functionality, revenue.
How do we make money?
How do we continue to make money?
How can we
adopt alternate methods, resume operation sites to continue to generate revenue?
You're going to prioritize your critical time sensitive processes.
You're going to identify your departmental relationships and interdependencies.
You're going to map the whole thing out in
a business organizational analysis and a business impact analysis.
All right, so BCP is
about keeping the company up and running in the event of a disaster.
The business entity disaster recovery refers to the organization's ability to
restore business data and applications after a disaster.
So, this is the assets that the business entity relies upon.
Our DR activities include the recovery of systems and people responsible for
rebuilding data centers, servers, or other infrastructures damaged by a disaster.
Remember, disaster just makes this facility or site unusable
for a day or longer, usually means recovering somewhere else.
It's a data centric strategy
where emphasis is on quickly restoring the organization's infrastructure and data.
The objectives, reduced downtime faced by an organization during and after disaster.
Like everything else, proper planning ensures this happens in a timely fashion.
But like everything else, proper planning is never enough.
What looks good on paper doesn't necessarily map to reality.
So, you got to practice this.
You've got drills, you got full interruption test, you have parallel test
to ensure you're able to actually do this in a live scenario.
Reduce the losses accrued during an after disaster.
Recover data that is damaged due to a hardware failure.
There's more than that.
Business continuity management then
ensures your organization's operations are not affected by disruptive incidents,
responsible for business recovery, crisis management, incident management, which
we've already talked about, emergency management, and contingency management.
The goals, ensure organizational
resilience to disruptive incidents and disasters, equip an organization to
respond effectively to threats from natural manmade disasters.
We're talking a lot of risk analysis here, right?
Including technological disasters and
protect the business interests of the organization.
Remember, we've got natural and we've got manmade and we've got politically
motivated, a bunch of subcategories of threat sources.
Our implications of business continuity
management, update the overall BCP based on employee training, exercises, and
reviews, manage recovery of applications, and the continuation of business
activities in the event of a business disruption.
A couple of things off the slide here.
A business continuity coordinator is going
to be delegated by or designated by senior management.
They're going to be in charge of putting the whole thing together.
They're going to recruit representatives from all the business units and functions.
They're all going to come together and they're going to get an idea of what could
happen, how bad would it be, interdependencies and so forth.
You have representation from all the various departments,
which you've got managers, you have technical types to get a realistic view of
the threats that you face, and then you do a risk analysis.
It's like any other risk analysis.
You look at things like natural disasters,
outages and so forth, and you look at how you're going to respond to it.
Restoration orders, prioritization.
A lot of this stuff is based on performance metrics,
maximum tolerable downtimes, recovery time objectives, and recovery point objectives,
which I'll sprinkle those in here in the appropriate slides.
The business impact analysis is nothing
more than a risk assessment to the organization itself.
Systematic process determining and
evaluating the potential effects of an interruption,
disaster, disruption or catastrophe, to critical business operations as a
result of a disaster, an accident, or emergency.
Ascertains recovery time and recovery requirements.
Recovery time is recovery time objective.
There's also a recovery point objective.
Then you've got what are called maximum tolerable down times.
MIT, where did that come from?
Maximum tolerable down times are maximum tolerable outages
that are defined as the absolute longest you can be without something.
When you establish these metrics, then your RTO is directly related to that.
Pretty straightforward.
How long can we be without this resource at the most?
Four hours. Fantastic.
We now have a recovery time objective.
We need to resume within that four hours.
That is measurable performance, especially in your interruption test.
RPO is a recovery point objective, which
states we need to be able to restore business data up to a certain point.
For example, let's say you have a disaster
on Friday and your RPO is no more than a day behind in backups, you have to restore
your data sets to at least Thursday or Wednesday evening.
It's the point at which you recover to.
There may be some loss of data there, but
RPOs are defined and also approved as acceptable by management.
The underlying assumption in a BIA is that while each component
of the organization depends on the continuous function of every other
component, there are critical interdependencies.
Some components are more crucial than others.
Guess what they get?
Asset values like any other asset.
They get prioritized based on criticality,
they get assigned a higher value, they are addressed first.
Hence, these critical components should receive a larger funding and
the recovery should be prioritized in the wake of a disaster.
All right, so just like everything else,
we spend more money towards what causes us potentially the most pain.
The business impact analysis happens in multiple phases.
We got a five phase scenario here as
illustrated in a Certified Cybersecurity technician.
You may see some different models depending on other sources where you read
it, but they all follow a pretty common set of phases.
Phase 1, the initiation of the BIA.
Initiated upon the approval of senior
management, senior management should always drive these projects.
That's defined as a top-down approach
which helps to ensure the success of the project.
The initiation phase can be divided into two steps.
Step 1, describing the objectives and the scope of the BIA.
Scope, really important.
Without scoping a project, you never have any certainty as to how much you're going
to accomplish, and you always have this thing called scope creep.
So, you need to find exactly what you are
targeting and what you're going to accomplish, then you know exactly when the
BIA is complete, and you don't have branch offices and things like that creeping in.
Scope creep is when you keep adding things to the
project that weren't laid out ahead of time.
That means your timelines go on and on and on.
Also, project milestones and timelines, really important.
Without due dates and deadlines, nothing gets done.
Without an expiration date or a drop-dead date, things just go on and on and on.
You keep wrapping things in.
Step two, forming a business impact assessment project team.
Then you go into phase two.
In phase two, the BIA project team adopts different information gathering methods
such as interviews and questionnaire surveys.
You're going to start interviewing and
collecting information regarding, Hey, what threats might we face?
This is standard risk analysis, which risk
analysis we'll be talking about in the next module.
Risk analysis gathers information in quantitative and qualitative metrics.
Quantitative gives you hard and fast numbers, dollars and cents.
Typically, you look at number of dollars lost, that thing.
In qualitative, it's based on importance and, say, severity.
On a scale of 1 to 10, Bob, how bad do you think that would be?
I think it'd be a 6.
A lot of times you'll average those values.
There's lots of different ways to collect qualitative information.
Interviews, questionnaires, focus groups, storyboarding, Delphi method, etc.
The collected information is reviewed,
documented, and summarized in tables, schedules, and diagrams.
Phase 3 deals with the analysis of the information.
Information collected is evaluated and reviewed manually or screened by computer
systems to provide a prioritized list of business process or functions.
Again, prioritized means the heaviest emphasis on a scale of 1 to 10 ratings,
the higher rated qualitative metrics, also the most danger of dollar loss from
quantitative definitely pushes something up the scale.
You prioritize what is going to cost you the most harm, cost you the most money.
Phase 4, documentation and findings.
Findings are documented and the BIA report is prepared.
Then phase 5, the final report is submitted to senior
management for approval or decision making.
Senior management relies on the report for
developing strategies for DRP and for meeting a BCP.
Now, senior management checks off on things.
It makes it sound like they're actually crafting the disaster recovery.
But management, it's not their job to
craft the continuity planning or the business or the DRP.
They're going to let those better, sooner
qualified put that together, but they're going to oversee, they're going to drive
the process, and they're also going to prove the final results
on the recommendations of those who they've delegated to do the work.
But you always check in with senior
management, even if they're not developing the program, they're driving the program.
A recovery time objective, I went ahead of
the curve here a little bit of the slides on this.
Recovery time objective,
maximum tolerable length of the time a computer system network or
application can remain dysfunctional after a failure disaster.
It defines the extent to which an interruption affects normal
business operations and the amount of revenue loss due to such an interruption,
it's expressed in minutes, sometimes hours.
But an example, an RTO of 45 minutes
implies that IT operations must be restarted within 45 minutes.
That's all stuff you can measure.
Without measurable performance, you have
no idea whether or not everything that you're putting together is realistic.
You get this down on paper and then you practice, practice, practice.
If you don't hit your time objectives, you revise, you practice again.
A recovery point objective, again, is the
maximum time frame which for the organization loses data after a major
outage, provides a foundation for designing a DR and BC solutions.
Every organization must calculate how long
it can operate without the required data before suffering a failure.
So, you get up to a certain point, there will be a certain degree of loss.
You don't have backups that are up to the minute.
Sometimes you do have their disk-to-disk backups.