When you're assessing risk, you need to understand the threats.
Some threats may be created by the environment around you.
We need to understand what type of tornado, hurricane,
earthquake, or severe weather threats
may affect our organization.
There are also man-made threats that
are important to understand, whether these threats are
coming from inside the organization,
or they're threats that are coming
from outside the organization.
Usually, these threats on the inside are from our employees,
and external threats may be organizations
that are outside or not part of our direct organization.
It's common to perform a quantitative analysis
of the threats that you may be faced with.
Part of these calculations might include an annualized rate
of occurrence.
This is the likelihood that a particular threat
will affect you.
This ARO is one that you can calculate
based on how often in a single year might
you be hit by a hurricane.
This might be a very different calculation
if your organization is in Montana versus an organization
that may be located in Florida.
Another calculation that's important
is the SLE, or the Single Loss Expectancy.
So if this single event occurs, if a hurricane comes through,
if a laptop gets stolen, there's a particular cost associated
with that and you can determine what this SLE might be
by looking at the risk itself.
So if a laptop is stolen, the asset value
for replacing that particular asset is $1,000.
That is the cost of our single loss expectancy.
Now that we know what a single event may cost,
we need to understand how many events
might happen in an entire year.
This would be the ALE, or the Annual Loss Expectancy.
So you would multiply the annualized rate of occurrence
by the single loss expectancy to calculate the annual loss
expectancy.
If we know that a laptop being stolen is going to cost $1,000
and we can estimate that there will be seven laptops stolen
in a year, we can multiply $1000 times 7
to come up with our annual loss expectancy, or $7,000.
When providing these calculations,
we also have to think about the overall business impact.
Being able to replace hardware has a quantitative cost
associated with it, but there's a qualitative impact
because there will be people not working because they don't have
a laptop or there may be services that we can't provide
to our customers because we don't have a laptop for someone
to provide those.
One way to evaluate risk during a project
is to create a risk register.
We know that every project has a project plan,
but at each step along the way there
will be some type of risk associated with that step.
Once we have identified each of those risks,
we can now create some possible solutions that
might help us avoid that risk.
And now that we've identified and documented
the risk and the solutions we can
monitor to see what type of risk we
may find during the process of this project.
We might also need to evaluate risk for something
as common as your supply chain.
This is the process that's used to get a product or a service
from the very beginning supplier to the final product.
A supply chain is usually not just an internal organization,
but there are also third parties you have to work with.
There's usually a set of coordination
that must occur between all of these different groups.
By examining the supply chain, you
can then identify areas where the supply chain might
be improved and look at the IT systems
to see if there may be optimizations
that could be put in place.
Once you've provided this evaluation,
you can then document what the business processes
changes might be to be able to make the supply
chain that much more efficient.
For risks such as losing a laptop,
there's an obvious cost associated with that, but what
about the other types of processes in your organization
where you're not able to put a quantitative analysis
on those steps?
Instead we'll want to use a qualitative risk
analysis to be able to determine where the risk may be.
One way to perform a qualitative risk assessment
is to identify different risk factors
and then identify categories of risks associated with those.
There may be an impact in annualized rate of occurrence,
there may be cost of controls and an overall risk value.
You may want to give those different values between 1
and 10, or you could use a traffic light grid
where you're looking at a red, yellow, or green
to determine how risky these might be.
If you're performing a risk assessment,
then you'll need to create a business impact analysis.
We need to know what the critical business
functions are for your organization
and document those.
Once we know what those are, we'll
know what the impact of losing them might be.
Will we lose revenue, will there be some type of legal impact,
or will we lose customers because we're not
able to provide that particular service?
It's also important to know how long this particular business
function will be impacted.
We may need to get additional people or resources
or we may need to get emergency equipment brought in
to be able to provide this business function.
This analysis might also allow you
to determine if making an investment in disaster recovery
may be an advantage to the organization.
Once you've added up all of these numbers associated
with the risk, you'd be able to determine
if it's a good financial move to have a disaster recovery plan
or if you should be able to make other arrangements instead.
Many of the systems that we use in our organizations
contain sensitive data.
They may have financial information or health care
information or some other type of private information
from our customers.
We want to be sure all of that data is safe,
so it's common to perform penetration
tests, vulnerability scans, and other tests
against those systems.
One challenge with performing these tests
is you're never quite sure how a system may
react to a penetration test or vulnerability scan.
I can tell you from personal experience
that a simple vulnerability scan could impact a system
and make it unavailable for other people to use.
It's very common to get formal authorization before performing
these tests then.
This allows you to remove any legal liability
for the people that are performing the tests
and this also determines how you're
going to be doing the testing.
If you want to perform a relatively noninvasive test
you may do some vulnerability scanning,
but if you're performing an active penetration test
there may be systems made unavailable.
The penetration test itself may install back doors,
it may create denial of service attacks,
or transfer sensitive data off of those systems.
There are many different ways to respond to business risk.
One way is to simply avoid the risk completely.
If you're participating in an activity that contains risk,
you simply stop participating in that activity
and you therefore do not have any more of that risk.
That's not an option for most of us.
Instead, we need to continue performing those functions,
but we need some way to mitigate the risk.
One way to transfer the risk from us to another person
might be to purchase insurance.
Now instead of accepting all of the risk ourselves,
we've mitigated that with some type of third party insurance.
This may be a situation where you simply accept the risk.
You know there's no insurance that you can purchase,
there's no way to mitigate this risk,
it's part of doing business and we're
going to accept any risk that comes with that.
Almost all of our computing systems
have some type of risk mitigation built in.
For example, if you put a firewall
between the users of an application
and those application servers, then you're
decreasing the risk level that somebody
may be able to take advantage of a vulnerability
on those systems.
One of the most common ways to minimize risk
in an organization is to institute
some type of formal change management process.
This means that we need to follow this formal change
management process if there's any type of change.
This might be upgrading an operating system
or changing the software that's on a system.
It might be adding or removing a server
or changing a firewall rule.
In organizations that have a formal change management
process, this is a normal part of business.
This happens very frequently and usually you're
meeting with the change management team every week.
In organizations that have not created a formal change
management process, the environment
can be a bit more chaotic.
Without any formal change management process,
there's no way to know when a change might be made
and what impact that change might
have for the organization.
A formal change management procedure
will have very clear policies and rules.
You'll know exactly when the change management is going
to occur, the duration of that occurrence, what
the installation processes might be for those changes,
and you'll know what the fallback procedures might
be if the change is not able to be implemented successfully.
For organizations that don't have formal change management
process, it might be very difficult to implement one.
When it's so easy to simply log on to a system
and make a change, no one wants to create a formal process that
slows that down, but the addition of change
management will not only provide more up time and availability,
it will decrease the risk for your entire organization.