All
right, let's take a look at Module 22, extremely important topic.
We've touched on this in bits and pieces
throughout the course, and that's risk management.
Risk management can be incredibly involved.
Lots of data collection, lots of
calculations, lots of forecasting, lots of math, lots of statistical data.
It can be a very, very in depth, comprehensive project.
When we perform risk management like
anything else, we're going to scope it appropriately.
We're going to identify from the onset,
from the start, exactly what we're analyzing.
You can never get rid of risk 100 %.
You'll never remove all risk.
If you are in business, you're at some risk, you suffer some potential for loss.
We do our best to minimize that to acceptable levels.
And again, senior management drives the whole thing.
They're going to be the final say on what's acceptable and what's not.
We're going to document that.
And this can be really, really involved.
Lots of math, lots of statistical analysis, lots of risk management
frameworks, which we'll talk about a few of those in the module.
I am usually not the guy who does the risk management or the risk analysis.
I'm usually the guy that tests the security of the controls.
So again, this is an area of focus.
Best left to those who understand the formulas, the calculations.
We're going to touch on that a bit.
I'm going to take you through an example
of calculating annualized loss expectancies, selecting counter measures,
determining the cost benefit or the value of the control of the organization.
We're going to go off slide here for a bit and just do some chalk talk whiteboard
work just to show you how the actual math and equations might look.
Risk management defined is the project of
reducing and maintaining risk at acceptable level.
Maintaining, really important.
This is an ongoing project.
It's never complete.
It's always being assessed since the environment is always changing.
As change occurs in the environment, you
should readdress your risk analysis or risk management.
Same thing with business continuity planning and disaster recovery planning.
We talked about that in the previous module.
Maintaining risk at an acceptable level,
which again, who determines what's acceptable and what's not acceptable.
Everybody all together now, senior management.
Like everything else, senior management,
ultimately responsible, senior management ultimately signs off on senior management
should drive this as a top down approach, again, versus a bottom up approach.
Senior management will delegate the
responsibility of risk management to a risk analysis team.
They will have a cross section or
representation from various business and functional units.
They'll collaborate on what risks exist, what threats exist.
They'll walk through a variety of scenarios.
They'll determine which are the highest
priority, and they'll address and spend the security dollars accordingly.
By means of a well-defined and actively employed security program.
It involves identifying, assessing, and responding to risks
by implementing controls to help the organization manage potential effects.
We're supposed to set out and identify all
risk, every possible threat, every possible scenario.
That's a tall order.
Typically, we're going to scope the
project to a specific range of threats in a specific area of the organization.
Again, like anything else, if you don't
scope the project, it keeps growing and growing and growing.
You have what's called scope creep, and it's never done.
It just keeps adding to the time frames involved.
You should definitely set a deadline scoping to ensure that the project is
completed in a reasonable time frame, then you go to maintenance mode.
Assessing.
Once we've identified the risk, we need to
determine the potential that will be compromised, the resultant impact, and the
likelihood, and then respond to it, minimizing by implementing controls.
I'm going to go, like I said, through a scenario where we'll use servers and
asset, we'll talk about an intrusion being a threat, we'll talk about the number of
times per year, we'll talk about possible countermeasures, and then we'll work
through some of the cost benefit analysis in a really simplistic way.
That formula you'll actually see in other security discussions.
It's pretty standard.
We'll use the Analyze Loss Expectancies, Analyze Registration
Recurrence, and look at the value of the countermeasure to the organization.
Risk Management has a prominent place throughout the system security lifecycle.
Again, it's an ongoing project.
Risk management benefits focus on
potential risk impact areas, addresses risks according to risk level, improves
the risk handling process, allows security officers to act effectively in adverse
situations, enables effective use of risk handling, etc.
Those responsibilities and risk management, we
just mentioned senior management drives the whole process, the chief information
officer, system and information owners, business and functional managers, IT
security program managers, and computer security officers,
IT security practitioners, and security awareness trainers.
Remember, whatever we implement needs to
be communicated to the users and the employees of the organization.
Security awareness trainers or any type of training program should be implemented to
educate users on the existence of the policies and how to follow the policies,
carry out their job roles in a secure way in adherence to the corporate policy.
Key risk indicators.
Before I go too much further, I want to go and start off with just some basic
calculations so we can visualize how this might look, mathematically.
Now, we're going to do very simple equations.
You will not be required to do a lot of math on the exam, I can assure you.
It gets way more involved in this, believe me.
But this is a basic scenario and shows a
little bit about how we would look at potential risk
countermeasures and how that would reduce our potential risk in dollars and cents.
The standard equation is asset value
times exposure factor equals single loss expectancy.
So for example, we have a server
that has an asset value of $100,000,
and that asset value would be impacted
by an exposure factor in a specific situation.
So imagine we've identified the asset,
we've put a value on it, which lots goes into that.
The cost of the system to replace price tag on the hardware, the software, the
amount of money the competition would pay for the information on the server, the
cost for R&D, the liability of compromise, etc.
Lots of different factors go into the calculation of the asset value.
Just for ease of illustration and math,
we're just going to use 100,000 as a nice round number.
We're going to multiply that by an
exposure factor, which is a percentage of loss that would be incurred in this
particular threat scenario, whatever there is that we're analyzing.
Imagine we're talking about a data breach.
Data breach occurs, on average, we expect to lose about 50 %...
Backwards, 50 % of our asset value for each data breach.
Let's say that is about $50,000 in fines, penalties, lost data, downtime, etc.
That will be multiplied by our asset value to create a single loss expectancy.
Single loss expectancy, in this case, would be $50,000.
There's your single loss expectancy.
Every time we get a data breach, it costs us roughly $50,000.
Then you have another equation that
calculates in an annual metric what this is going to cost us per year.
The equation for that is single loss expectancy times annualized rate of
occurrence equals annualized loss expectancy or annual loss expectancy.
In that same scenario where our SLE is
$50,000, let's say that currently we get breached about once a month.
It's probably not a good number.
We should lower that.
Our ARO is actually 12.
Twelve times per calendar year equals about $600,000.
Now, hopefully that's not our current standard risk.
That's a bad situation.
We've got to do something about that quickly.
The ARO can actually be calculated as a decimal value as well.
For example, once every 10 years would be
a 0.1, once every 100 years would be a 0.01, you get the idea.
You can also see AROs represented in percentages.
There's a 5 % chance that this will occur each year.
That determines how often or how frequently the threat is realized.
Again, a threat is again a potential of
violation and the exploit and the breach are the actual occurrence of a threat.
We've got an annualized loss expectancy currently of $600,000.
That is not good.
We need to figure out what we can do to
drop that ARO or drop that SLE or that exposure factor.
Typically, when you're performing calculations like this, the variable is
the annualized rate of occurrence, so we'll just use that to begin with.
But it could be the exposure factor for the ARO.
Let's imagine that we decide we're going to implement a firewall.
That firewall is going to cost us about $100,000 a year to implement.
Let's say that it drops our ARO to one.
That's a notable increase in security or notable reduction in exposure.
Now we calculate...
Let's go blue here.
Our ALE after implementing the safeguard.
Now it's $50,000 times 1 equals $50,000.
That sounds like a good idea.
But you also need to calculate or account for the cost of the countermeasure.
So, if the counter measure costs us $100,000 per year and we're staffing,
administration, so forth, we need to figure out what the difference between the
two ALEs is and then deduct the cost of the countermeasure.
In our difference between the ALEs, we're saving about $550,000.
That seems like a good idea.
But then you deduct the cost of the countermeasure
and that gives you the value of the safeguard of the organization.
I'm running out of room here.
Let's do that in blue.
That's a value of $450,000 through organization.
That countermeasure that cost us $100,000
actually is worth $450,000 to us in not lost revenue.
It's not really a gain, it's an absence of loss.
That's a good business decision.
If this is a positive number, that's a good business decision.
You look for the countermeasures that give you the best bang for your buck.
And if it's a negative value, you might choose to accept the risk.
That's a basic risk calculation for me.
It gets way more involved in that.
Believe me, that's about the extent of my math skills as far as risk analysis.
Again, I'm never really involved in that process, but I understand the basics and I
definitely understand a measure that performs the countermeasures.
All right, so the entities involved in risk management, we've discussed that.
Key risk indicators.
Key risk indicator is an important component of effective risk management
process as it shows the riskiness of an activity.
Lots of things can be key risk indicators.
Number of discovered vulnerabilities in a
given week, the higher that number, the higher the risk.
You also have what are called key
performance indicators which indicate how well you're doing.
So a KRI is a risk metric showing the risk appetite, probability for an organization.
It assists in identifying the adverse of effect of an event, notifying on threshold
levels of risk, backward looking view on risk events.
Some examples, key risk indicators, define
the risk for an objective, identify the possibility of adverse effect, send early
warning to identify a potential adverse event.
So again, anything can be a key risk
indicator if it's an indicator of exposure, vulnerabilities and so forth.
And then a key performance indicator is, again, how well you're doing.
So, one example might be a key risk indicator is the number of open
vulnerabilities during a vulnerability assessment.
Let's say you're doing that weekly.
A key performance indicator would be how quickly you're resolving those
vulnerabilities, applying patches, updating system configurations, etc.
, versus, say, last week.
So, if you're doing better, you got more closed tickets and respond to open tickets
this week, your performance indicators are doing well.
If it's lower than last week, for example,
statistically, you may be doing less often, or even poorly.
So the risk indicator, direct indicator of inherent risk or current risk,
performance indicator, how well we're doing, potentially resolve that.
And again, performance indicators can
indicate anything that indicates performance.
It can be throughput of web applications, bandwidth utilization, anything.
But a lot of times it's used in the same discussion as key risk indicator.
Types of risks, risks from internal sources.
Internal risks from inside the security
perimeter occur during normal business operations, accidental, technical, or
physical asset failures, or deliberate human actions.
We've already had the discussion of the
discredited employee, the careless employee, the negligent employee.
We talked about insider threats.
Again, it can be purposeful or non purposeful, non malicious.
But remember, humans are prone to errors.
They're always the weak link in the security chain.
They make mistakes all the time, but we're wonderfully imperfect.
A risk from external sources.
Arise from outside the organization that goes back to our natural disasters,
manmade threats, unexpected issues, fire outbreaks, and so forth.
Intellectual property theft, that's huge.
Organizations encounter risks from various sources, malicious entities, and the
environment competitors, illegitimate copiers, and third parties.
Lots of IP theft, lots of industrial espionage, industrial sabotage.
Companies are out to steal other companies' secrets.
It doesn't necessarily have to be the Coca Cola recipe, but it could also be
processes, the way they do business procedures, etc.
Anything that's useful to the competitor could be stolen as intellectual property.
A lot of times that's copyright
violations, things like that, source code for software, etc.
A risk from legacy systems.
We talked a bit about legacy systems in our OT and SCADA discussion.
Legacy systems are
outdated, unsupported operating systems, vulnerabilities are discovered.
They're no longer supported by the vendor, so no patches come out.
Legacy system with unpatched data and
outdated security measures, allows attackers to gain access to the middleware
application's databases running on to compromise server platform.
Old XP systems, still used all over the place for kiosk machines.
Last time I checked, I believe the Red box
machines were using XP and other heavily locked down.
But when you're using these legacy
operating systems, when vulnerabil ities come out, they remain unpatched.
There's definitely issues with that.
The cost of updating an operating system will generally not, it depends on the
situation, might not outweigh the cost of the exposure.
Remember, when you weigh the pros and the cons, the cost of the benefit, if it costs
you more to address the risk, you might choose to accept that we're going to talk
about risk treatment and responses to risk here in just a few minutes.
Multi-party risks.
Any situation where you are sharing the risk amongst multiple parties.
Damage several organizations simultaneously, usually caused by third
party providers used by organizations for particular services.
Then software compliance risks may arise
out of illegitimate copying of software, misuse of license, failure to comprehend
newly granted changed policy terms of services.
Software needs to be licensed.
You need to pay for the copies you're using, etc.