- In this lesson 24.4,
we're gonna take a look
at doing a business impact analysis.
Which is always gonna be part
of our risk management program.
Now, the purpose of a BIA,
or a Business Impact Analysis,
is to characterize system components,
supported business processes,
and interdependencies.
In terms of how important
they are to the organization.
Now, the outcome of a BIA
is gonna be a prioritized matrix of services,
systems, and infrastructure
used to inform management decisions.
In terms of resource prioritization
and investment strategy.
And to guide the development
of our incident response, disaster recovery,
and business continuity plans.
Now, the goal of doing a BIA is to determine
the criticality and impact of our systems.
And if they weren't available
what our recovery requirements are?
And, when we look at the aggregative systems
what our recovery priority is?
So the first thing we wanna do,
is we wanna identify our critical processes.
And then the associated impact of a disruption.
Now our recovery requirements is an evaluation
of all of the resources needed
to resume business processes
and the related interdependencies.
Now, those dependencies may include
technology, infrastructure, facilities,
personnel, even third parties.
And then our recovery priority is establishing
the prioritization and sequencing
of recovery and resumption activities.
So those are our goals to determine
criticality and impact,
recovery requirements, and recovery priority.
Now here's one of the most basic metrics
that we're gonna use.
It's called a Maximum Tolerable Downtime.
The Maximum Tolerable Downtime, MTD,
sometimes you'll hear it is MTO,
Maximum Tolerable Outage,
represents the amount of time
that a system owner is willing to accept
for a service or process outage or disruption.
And includes all impact considerations.
So I wanna stress this is not an IT decision.
This is not a security decision.
This is a business unit decision.
This will be made by the management
of that business unit.
Which basically says,
what's the amount of time, that we can go
by having a service or a process
either out or disrupted right before
it causes an unacceptable impact.
Now, the MTD may also include
the amount of time that a business
can support alternate processing modes.
So for example, in a bank, you know,
at the teller stations,
if they couldn't connect back
to the the core system,
well they may be able to work
in offline mode for an hour.
So that would be taken into consideration.
But we get past that timeframe,
now they can't operate at all.
That would be unacceptable.
And we also have what's known as an SDO.
An SDO is a Service Delivery Objective.
Now, that's the acceptable level of operations
in alternate processing mode.
So if we had this outage,
is there something we can accept
that's not quite full resumption,
but enough to keep us going.
So operations might be less than normal,
but sufficient to sustain
business functions until full recovery.
So MTD and STO.
And here are some of our MTD,
Maximum Tolerable Downtime Impact Considerations.
Our dependencies, our fluctuations, financial,
regulatory, reputational, and contractual.
So Dependencies, Is there an impact
on other functions, processes, or services?
Fluctuations, based on date and time.
Is there a difference between a system or process
not being available on a Monday than a Friday?
A morning than an evening?
Financial, what is the monetary loss?
Regulatory, Will this disruption or downtime
cause any compliance issues?
Reputational, Will this outage or downtime,
you know, result in a loss
of customer trust and or business?
And then, do we have any contractual obligations
and not being available?
Would there that be a contractual violation?
So then we start looking at, okay,
if there was a downtime,
there was this problem, an outage.
How do we restore our systems?
How do we get back?
And how quickly do we need to get back?
And so we've got four BIA recovery metrics.
RTO, Recovery Time Objective.
RPO, Recovery Point Objective.
MTTR, Mean Time To Repair.
And MTBF, Mean Time Between Failures.
Now the Recovery Time Objective
is the amount of time allocated
for system recovery before
negatively impacting other systems.
So it's how much time do we have to recover?
But very often, there's a number of components.
Number of systems, that we have to recover
for a particular process.
And so the sum of all the RTOs
should be less than the MTD.
RPO is all about data.
It's the Recovery Point Objective.
It's the acceptable data loss.
And this translates to the point in time
prior to a disruption,
that data can be recovered.
And honestly, this is a place
where I find the largest disconnect
between expectations and reality.
So I might be doing a BIA,
and say to a business unit,
okay, if there was a disruption
how much data could you recreate?
How many transactions?
And they might say,
oh, probably from the last half hour
of transactions we could recreate.
And then I say to IT,
how often are you backing up
or replicating their data?
And maybe they say, oh, every 12 hours.
Well, we could potentially have a data loss
of eleven and a half hours
that no one's really acknowledging.
And so once we establish that RPO, right,
we either have to change expectations.
Or make additional investments.
Or change how we do things.
And then these next two recovery metrics
actually will come from a manufacturer generally.
MTTR, Mean Time to Repair,
which is the average time
it takes to repair a failed component or device.
And then MTBF, is the Mean Time Between Failures.
Which is just a measure of reliability
with usage generally stated in hours.
So let's take a look
at the full business impact analysis process.
The first thing we're gonna do is,
we're gonna prioritize
our services and processes.
And really what we're saying is,
if there was a major disruption,
what are our essential services and processes?
And essential is a tough word to use here,
because everybody likes to think
their job is essential.
But let's think about
a financial institution, right.
If there was a major outage, what is essential
for a financial institution to do?
Well, to be able to let their customers
get their money out, is probably
one of the most essential things, right.
Are we gonna be worried about making new loans?
Probably not.
Are we gonna be worried about,
you know, marketing.
Probably not, right.
We have to look at what
those essential services are in a disruption.
So we're gonna prioritize
those services and processes.
And then for each service and process,
we're gonna identify the impact of a disruption.
We're gonna establish the MTD,
The Maximum Tolerable Downtime.
We'll establish the SDO,
the Service Delivery Objective.
We'll determine their required RPO, right.
The Recovery Point Objective.
That's all about data.
We'll identify all of the infrastructure.
Or all of the components.
We're gonna determine the required RTO,
that's our Recovery Time Objective.
Then we'll compare the required
and the actual RTO and RPO.
Then we will analyze the gaps
between the actual RTO and RPO.
And then lastly, we'll report up to management.
So let me just give you an illustration
of the outcome of a BIA.
This is actually from NIST,
Special Publication 800-34r1.
You can see we've got the business processes
of process an invoice, prepare a report,
create a budget, respond to inquiries.
We have what the potential impact is.
Operations more than 1,000 staff affected.
Or reputation affected,
or customer service affected.
Then we have
the Maximum Tolerable Downtime, right.
The MTD, that's a business unit decision.
Then we have, what are all the system components?
And it's very likely that you'll have
multiple system components.
It looks like the application server,
well, is responsible for both
processing the invoice and creating a budget.
So you can see that there's
multiple dependencies here.
So we're gonna identify
those system components, that's right here.
So we started with our Business Process,
our Potential Impact.
Our Maximum Tolerable Downtime.
And then we'll get to our
Recovery Time Objective.
Then what we don't have
in this particular illustration,
is our RPO, our Recovery Point Objective.
You've seen this slide before.
This is just a refresher.
This is just a reminder about cost balancing.
That we always, you know,
need to think about cost.
And we want to balance the the cost to recover
and the cost of disruption.
Taking into account
the length of disruption as well.
And that my friends,
brings us to a 3-second challenge.
Five challenge questions, three seconds each.
This is the maximum time a process or service
can be unavailable, without causing
significant damage to the business.
One, two, three.
That's MTD, Maximum Tolerable Downtime.
Again, sometimes you'll see it
as Maximum Tolerable Outage.
It means the same thing.
Number two, the amount of time allocated
for system recovery.
That's gonna be inclusive
of all of the dependencies.
One, two, three.
That's your RTO, your Recovery Time Objective.
Number three, the acceptable data loss
expressed in time.
One, two, three.
And that's our RPO, Recovery Point Objective.
Number four, the intersection
of the cost of the disruption,
and the cost to recover.
One, two, three.
That's our Cost Balance Point.
And lastly, number five,
a measure of reliability.
And that's generally stated in hours.
One, two, three.
That's gonna be an MTBF
or Mean Time Between Failures.
So let's do a security in action
about a business impact analysis.
Anytown's Bank's mission-critical priority
is to be able to serve their customers
24 hours a day, seven days a week,
365 days a year.
So to facilitate this,
they have an online
and a mobile banking platform.
They have determined
that their online banking application
can operate in offline customer transaction mode
for 60 minutes with minimal customer impact.
So that would be offline mode,
after there's a disruption.
After that, service
is no longer available to customers.
Now they can manually recreate
the last 30 minutes of transactions
relatively easily.
Generally within 10 minutes.
So here's what I wanna know from you.
What is the MTD, the RPO,
and the RTO for this scenario?
So they wanna be online, right, 24x7x365?
They've determined
that their online banking application,
that's really our focus here.
Can operate in offline transaction mode
for 60 minutes with minimal customer impact.
But after that service is no longer available.
They can no longer service their customers.
After the 60 minutes.
And they tell us they could manually recreate
the last 30 minutes of transactions
relatively easily.
Within 10 minutes or so,
but probably not past that.
So, what's the MTD, the RPO, and the RTO.
Go ahead and put me on pause,
and come up with this BIA metrics.
Well, the Maximum Tolerable Downtime
really is 60 minutes.
That's the most we can be down.
So we go down,
and at that point the offline mode kicks in.
So we could still service our customers.
But at the end of that 60 minutes,
we're down, we're done.
We can no longer service customers at all.
So our Maximum Tolerable Downtime
is going to be 60 minutes.
Our Recovery Point Objective, or RPO,
is going to be 30 minutes.
Why?
Because they tell us that they could recover
the last 30 minutes of transactions.
But after that, absolutely not.
So the Recovery Point Objective,
that's looking back,
how much data could they recover?
They're saying we could only recover
the last 30 minutes worth of data.
Now, the Recovery Time Objective, the RTO,
needs to be less than 60.
And that 60 minutes combined
for all applicable components
and interdependencies.
And then another question to ask would be,
is there an acceptable SDO
or Service Delivery Option?
Is there something that's acceptable
between being like dead in the water
and full recovery?
Is there something in between
that would be acceptable?
And that would be the SDO.
The Service Delivery Option.
Knowing these metrics for your exam
and in real life,
is for sure security in action.
There's your word cloud,
make sure that you know all of these terms.
And when you're ready,
head on over to our quiz.
I'll see you there.