Part Three: Controlling Threats and Risk

Start course
Overview
Difficulty
Beginner
Duration
50m
Students
39
Ratings
5/5
starstarstarstarstar
Description

This course explores risk analysis and prepares you for the CISM examination, which will cover the significant aspects of risk. We'll cover different risk levels and types of risk and how they can potentially affect an organization. We also look at the risk assessment cycle and the stages required when analyzing risk. You'll also learn about the various risk analysis methods available. Then we'll move on to how risk analysis can be used when planning and deploying risk controls and countermeasures.

If you have any feedback relating to this course, please contact us at support@cloudacademy.com.

Learning Objectives

  • Identify risk levels and potential impact of given risks upon the assets
  • Learn about the risk assessment cycle
  • Learn about different risk analysis methods including qualitative, semiquantitative, quantitative, OCTAVE, and FAIR
  • How to use risk analysis to control threats and risk
  • Define a strategy for deploying risk countermeasures

Intended Audience

This course is intended for those looking to take the CISM (Certified Information Security Manager) exam or anyone who wants to improve their understanding of information security.

Prerequisites

Any experience relating to information security would be advantageous, but not essential. All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.

Transcript

We've arrived at section six. We're having discussed risk analysis methods. We're going to discuss how to apply that knowledge and the results gained through the analysis for controlling threats and risks.

In the previous section we discussed asset, vulnerabilities, threats, and time. These factors of course must be described in relationships so that we can understand the interaction of them giving rise to risk and producing a situation in which the threat can impact the asset and cause us to lose its value or its function.

Here we see a graphic describing a threat agent exploiting a vulnerability through some method in creating an exposure to loss or some other form of compromise. Next to that, we see a bubble highlighting potential damage which represents the universe of damage that can be caused but not necessarily the damage that will be caused unless a particular threat materializes. The intersection between the threat and the potential damage is where we have the realization of an asset actual loss scenario that can materialize.

Following the arrow, we see that it is to this section that we apply a control. In following the arrow horizontally, we find that should the threat materialize and begin to do its damage, a countermeasure can be employed to augment the prevention of further damage. Again, this highlights the proactive or preventive nature of what we call controls and the defensive or reactive nature of what we call a countermeasure.

Now let's look in various aspects of vulnerabilities and what might give rise to them and make them difficult to cope with. Without question, nothing exists that is truly and vulnerable. For us the question is what we can identify in the way of vulnerabilities that might exist within one of our assets and how serious such exploitation of it would be.

As I mentioned before, predisposing conditions may not themselves be vulnerabilities but they can certainly give rise to vulnerabilities that can then be exploited by a variety of threat agents. They may have a retarding or an accelerating effect on those agents as well.

One of the aspects of vulnerabilities that must be considered as well is that the contribution of a given vulnerability or a security control to the ability of an exploit to actually occur. And the example on the slide you see weak password protection for a system that can only be accessed from within a high security room.

What this example seeks to highlight is this, yes it may indeed be a weak password. However, that weak password can only be used from within a high security space. This is implying that other layers of security, as in defense and depth would dictate, would deal with the authorization of persons to enter the high security space and the denial of unauthorized persons from doing so such that the weak password is not worrisome in and of itself.

We have of course, automated tools such as vulnerability scanners that can scan for known vulnerabilities in our systems. And upon finding them, make recommendations for effective mitigation. When it comes to certain kinds of vulnerabilities these may be relatively easy to detect or as process or performance types of vulnerabilities which may have multiple aspects where one factor impinges upon another. And these may in fact be more difficult or even impossible to detect easily.

So, we see different categories of vulnerabilities. These are those that affect the network. Those that are of a physical nature. Those that have a direct impact from being built into applications or being accessible from the internet. Some result from poor design or used utility programs.

One area that has gained a great deal of importance in the last decade, is risks that come to us through our supply chains. And below is the first list you'll see of several examples that have been discovered over time where these categories have been born out. What they serve to do is give us clear indication of the aspects of our systems that need to be investigated sometimes deeply for the presence of any vulnerabilities.

To do so effectively means that we have a sense of the sort of thing that we look for. Something irregular, something unexplained or something unknown. And we have a sense of how it may interact with other things to produce exploits or damaging results. We see the combination of risk, likelihood and impact.

The first bullet we see is that risk equals threats, time multiplied by vulnerabilities, multiplied by consequences. To define this correctly this equation defines a relationship between these elements, threats, vulnerabilities and their consequences of being exploited to the notion of risk as opposed to being a strictly mathematical calculation. It is an accurate representation of this relationship.

In the context of the CISM, it has also been to recognize that risk though oftentimes seen as negative may in fact represent an opportunity of a positive nature. This of course is a direct result of evaluation of the context in which the risk presents itself and the CISM would be expected to make a well-considered informed judgment on that.

We have already discussed at some length probability in that it measures how likely it is that a given threat or its agent might occur. This needs to be calculated to a level of confidence but not necessarily to absolute certainty. Below this, we see the factors that may modify our interpretation of probability, such as volatility, velocity, proximity, and the other terms you see there.

My advice to you is in looking at this slide, regard these items as fair game to be asked of you on the exam as a definitional type of question. Now on this slide, what we see is the recommendation that groups of risks should be put together in terms of similarities or shared characteristics of those group elements. This is sound advice from the standpoint that a solution that addresses one kind of risk may likely have a positive impact on the second risk that shares many of the same characteristics as the first.

This is simply a reflection that this is a multi-dimensional problem and that there are potential solutions that are equally multi-dimensional. Without question, there are assets of greater importance and lesser importance.

It is equally true that there are risks of greater seriousness and risks of lesser seriousness. It is, therefore, necessary to prioritize based on the importance of the given asset as to whether it will be treated as more important or less important with the same consideration being given to risks of greater or lesser damage in like fashion.

It is necessary for me to call out the fact that we are attempting to do here is not to eliminate all risk or defend against all threats or to mitigate all vulnerabilities. These terms represent absolutes that are not achievable by realistic methods or for that matter are affordable. We're concerned with risk management and having well-formed decisions to do so made effectively. And in doing so, looking beyond what may be the most obvious solution to find better answers to the questions that will be raised in the course of this analysis.

Taking a page out of the book of project managers we identify the risks that we should commit them to a risk register for tracking purposes. This risk register makes a record of the risks that we have identified and gives us a tool through which we can manage each risk and each set of actions we take in response to having identified that risk.

Along with the risk, comes the ability to associate any vulnerability, any exposure and every asset associated with that risk. It also allows us to associate owner, risk owner and any other stakeholder that may be involved or have an interest in this particular risk asset relationship.

Now, as seen earlier, we typically have four options when it comes to coping with risk, except, mitigate, avoid, or transfer. The one option that can never be exercised is simply ignoring a risk. If a risk is real and relevant meaning that it is both credible and reasonably probable to occur, that ignoring the risk would be considered negligent. Therefore ignoring the risk is not an option that is open to us.

It must be understood that avoiding a risk is not the same as ignoring it. As we defined earlier, avoiding a risk recognizes that taking a certain action could give rise to a risk and thus if we can avoid taking that action, we do so, so that risk does not materialize.

It must be recognized and accepted that in the course of doing risk analysis and mitigation a certain legal accountability may be created such that failure to do so by ignoring a risk may give rise to potential adverse consequences and financial impact.

So let's take a look at some rules for managing our risk. One of the first things of course is that management must do is to set the level of acceptable risk and define our organization's risk tolerance. Recognizing that risks that we must mitigate by some means are both real and relevant and may in fact have a regulatory basis. We must define these terms to guide our decision-making as needs to be done.

As shown earlier, if a risk level is unacceptable then some form of mitigation must follow. If a risk level is found to be acceptable some form of acceptance may be possible but the requirement might not end with simple acceptance.

It may very well happen that risk mitigation may not be practical even for real and relevant risks. That being the case, some form of alternative method may have to be employed. It may be that risk avoidance is not possible. It may be that risk transference is a practical option. This may result in outsourcing or the purchasing of insurance both of which reflect responsible reaction to the presence of a real and relevant risk that may not be mitigated by other means.

One thing that must be established is risk ownership and accountability. It is a common blanket statement to say that management owns all the risks of an enterprise. This blanket statement however, identifies more of a fiduciary responsibility and a legal accountability than actual operational ownership consequently and risk ownership must be identified within the organization who will be responsible for the actual mitigating and routine management of the risks situation thus identifying the risk owner will escalate periodic reports and alerts as needed to senior management for appropriate action so that senior management can fulfill properly its legal accountability for managing risk in the enterprise.

In every risk analysis scenario, there will be defined the terms, acceptable risk, total risk and residual risk. We have discussed total risk and acceptable risk but we have not yet touched on residual risk. Let's do that now.

The risk that we have prior to many mitigating activity taking place is referred to as total risk or inherent risk. This is all of the risk elements that occur within the scope of our assessment project and it includes all elements present.

Once we have completed our mitigating activities and whatever combination they occur, what remains is considered residual risk. There will always be residual risk and residual risk is what we will largely manage following the completion of our risk analysis activity.

Now the residual risk that remains must of course be equal to or lower than our acceptable risk and within our risk tolerance. The management of the residual risk should take place through a program of continuous monitoring so that should the conditions change at any time, we'll be able to properly mount a response to whatever risk conditions shouldn't result.

The impact of course is the very thing that we are trying to identify as potential. And through the course of our mitigating activities either reduce or prevent from occurring. This represents a negative outcome of some kind to performance, to integrity or to simple loss. It has always expressed in some form of financial representation even qualitatively.

These sorts of impacts in the form of losses, compromises, corruption, denial of service or some other form will invariably have a financial impact upon the enterprise where they occur. The value of the impact therefore, represents a target value that must be considered whenever we start serious review or decision-making regarding what mitigating efforts, technologies or physical devices may be involved and the cost effective mitigation of that impact.

About the Author
Avatar
Ross Leo
Instructor
Students
2892
Courses
44
Learning Paths
6

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.

 

Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.