Let's take a look at the Security Principles for the
Certified in Cybersecurity domain.
This one is entitled Risk Management.
When we take a look at all of the areas of security principles,
we set out a foundation of understanding the
concepts and oversight or governance,
but now we have to do risk management so we're able to
determine what controls we should have.
We will finish this off, of course, looking at the code of ethics.
Let's take a look at some definitions.
Risk is defined as the probability of an event and its consequence.
Now for business, risk is an essential part of doing business.
I start a new product, I do some research,
I open a new office, there is a risk associated with that,
but I'm looking for the reward or the gain I'll get by
having that new product or that new office.
So risk for business is very much both positive,
but also negative because when I do take that risk,
I could lose the investment I made as well.
From an IT perspective, we often look at risk for more of the negative side,
the things that can go wrong.
So we see here how the ISO standard 27005 has defined information
security risk as the potential that a given threat will exploit
vulnerabilities of an asset or group of assets,
and thereby, cause harm to the organization,
so we see more of a negative view of risk,
but it's important for us to remember that we shouldn't always see
risk as negative because the people we're talking to may see it as
very much a part of daily business.
Risk management can be divided into four sections.
The first, to frame the center is to understand the business,
understand the competition, the laws, the culture,
and all of the things about our business,
including things like financial depth.
Before I start looking at risk,
I need to understand the business and what business we're in,
but then when I have that understanding,
I can assess the risk and the results of the assessment are fed back to
management in that frame area so that management can say,
do they agree with the assessment?
Maybe that's a bit of an iterative process we might have to reassess.
Then we take the results of that assessment and do risk
response or sometimes called risk treatment.
What are we going to do about the risk?
Should we just accept it or should we cease that activity
altogether or should we try to reduce the risk?
These are some of the options we'll look at when we look
at risk response and risk treatment.
But risk is always changing.
The business changes, there is new threats,
equipment gets older, people change,
so we need to continuously monitor for what is our current
level of risk and that should go back to response and say
maybe we need to adjust a control.
It should maybe go up to assessment and say,
hey, maybe we need to reassess this risk,
but certainly it should feed back into that center management so
management knows what our current risk is.
We are going to spend a bit more time on risk than it's really we
could say here worth from an exam perspective,
but it's really important because this is a key concept we need to
understand, and so I hope you'll bear with me a little bit on this as we
take a look at what risk management really is.
It starts with risk identification, that is to determine what
are the things we're trying to protect?
The assets.
What are the threats to those assets?
Do those assets have any vulnerabilities?
And of course,
know what controls we currently have in place to try to protect those assets.
We need to understand how some type of risk event
could impact or harm that asset.
Could it harm us financially or reputationally, for example.
The NIST Special Publication 800‑30r1 shows how these fit together.
We have, as you can see in the bottom left corner,
inputs from the risk framing step where we look at the risk management strategy,
the approach, and any of the then risk factors that should be considered as well.
We have a threat.
The threat source could be a hacker, could be an employee,
could be, for example, a natural event,
and that threat source initiates a threat event.
The storm, the malicious code, the deleting the wrong file,
those are all threat events initiated by the threat source.
We have to look at what is the likelihood of that happening?
Untrained staff, for example, are much more likely to
make a mistake than well‑trained staff.
But then we see how that threat event will attempt to exploit a weakness,
a vulnerability, a gap in the protection for that asset,
and this is where we have to understand a threat is not limited to
one vulnerability nor is a vulnerability only subject to one
threat, so there is a many‑to‑many relationship here between
threat events and vulnerabilities.
We also have to look at a few other predisposing conditions such as morale,
the financial depth of the company, can they even handle some type of a loss?
We have to look at whether or not our controls are effective.
But in the end, if that threat was able to exploit a vulnerability,
we're going to have some level of consequence or impact, and that is
going to be some type of impact on the business itself,
or we could say organizational risk.
Risk identification means we need to identify the threat source,
maybe a hacker, then the threat event, the malware,
the vulnerability, an unpatched system, the asset itself,
the business process,
and when we see this string of different things coming together,
then we have a way to measure our level of risk.
We identify risk by knowing what we're trying to protect,
the assets, knowing the threats and vulnerabilities of those assets,
but then we get into the hard part of this.
How do we determine likelihood or the probability of something happening,
and how do we determine impact or consequence if it does happen?
Not all events will have the same impact.
When we assess the risk, we then come out with priorities,
which risks are more important and should be dealt with immediately.
Hopefully,
we come out with some recommendations of how we could respond
or deal with that risk we've identified.
An important part of this is determined who owns the risk,
who's going to be responsible for fixing this problem?
We generate a risk assessment report for management to
see what our identified risk is,
and we may even have a risk register that has all of our risk in one place
so that people can see what our current risk profile is.
The key points review.
Risk management consists of several activities.
These can be happening concurrently or consecutively.
We need to understand the business first,
establishing the frame or establishing the context
in which the business operates, and then by doing risk assessment,
we can identify and prioritize risk.
When we measure risk to an IT system,
the true measure of that risk is how much it would impact the organization,
the business that relies on that IT system.