What is security and risk management in Cissp?

Welcome back to the Cloud Academy's presentation of the CISSP Review Seminar. So in this module, here you see the outline of the topics we're going to cover. Introduction to risk. Qualitative and quantitative risk assessment. We're going to look at identifying of threats and vulnerabilities. And then we're going to walk through the risk assessment analysis process and then look at the subject of risk assignment or acceptance, followed by countermeasure selection. We're going to continue talking about security and audit frameworks and methodologies. Implementation of the program elements. Access controls. Control assessment. Effectiveness assessment methods. Asset valuation. Reporting. Continuous improvement, always a very important component of a security program. And then risk frameworks. So let's get on and continue. 

So let's begin with some definitions. Risk. Risk represents the likelihood that a given threat source will act upon a particular vulnerability, and the resulting negative impact that would occur from this interaction. Also, it refers to the financial exposure to losses, whether singularly or cumulative, through such an adverse event. So the matter of risk has two definitions that we have to address. One is possibility. This refers to the fact that the risk in question is real and capable of happening. But we also have to address a secondary element, which is probability. And that is the measurement that the risk in question is more or less likely to materialize, and when materializing, that some frequency of recurrence is carried with it. 

So here we have the asset vulnerability threat and time. This is a four dimensional space, in which applying risk mitigation practices and countermeasures. So we look at asset value, and whenever we value an asset, we have to include both tangible and intangible aspects. Some of which would be measured by normal business methods. Others which might be arbitrary determinations of value. We also have to look at threats and their impacts, and this includes the type of impact and the order of magnitude of the impact. We move on to vulnerabilities. Weakness and predisposing conditions. Predisposing conditions can be rather difficult to separate from weaknesses, but the best way of thinking of predisposing conditions is they're environmental in nature. They are simply the environment in which an asset exists, but they certainly can give rise to weaknesses or vulnerabilities, and therefore play a significant role in how we look at the asset vulnerability threat combination. We have to include, in our analysis, the elements of time, because time causes changes in value or changes in character, of the given asset. So in this four dimensional space, we come to evaluate the interaction between an asset, vulnerabilities which may exist in the asset or in the environment around the asset, and then the threat. That element which can exploit those conditions. And then examine the effects that changes brought by time can bring to this. 

So the risk management concepts we're going to explore are the threats, the vulnerabilities, likelihoods or probabilities. The impacts that can be caused. The countermeasures that we need to select from in order to counteract one or more of these elements. And then the element that remains, after we've done all that we can do, effectively, and that is residual risk. So here we have the current risk management framework, as is outlined in the common NIST documents, beginning with Special Publication 800-30. This is also characterized in the NIST volume 800-37, 800-39. It brings to bear four primary characteristics. We first have to frame the risk, in which we determine our strategy to address the risks that we find. We conduct the assessment, and, by that, we do our qualitative and quantitative methods to be used. We have to communicate the results, which will result in informed decision-making on the parts of management or the other asset or risk owners, and the choices that they're going to make. Which will result in mitigation, transference, acceptance or other risk strategies, to effectively reduce the risk or the affects that the risk elements can have on the environment. And then, of course, we have to maintain the assessment, which is looking to do continuous improvement, rather than the more common practice of repetitive remediation. And the graphic that you see next to it shows the steps that we take. We prepare for the assessment, and by that we're going to set up the project through which we're gonna conduct this. Then we actually conduct the assessment itself, and in that we will identify threat sources and events. Identify vulnerabilities in the predisposing conditions. We'll make some kind of an assessment to determine likelihood of the adverse events occurring. Then we're going to determine impact, type and magnitude, and from that, we will derive what the overall risk will be for the given scenario we have just completed the analysis on. Then we will communicate the results to management, to facilitate their informed decision-making, and then, down the road, we have to maintain the assessment, which, of course, includes reacting in real-time to events that arise, risks that arise, that may not have existed at the time we conducted this initial assessment. And then seeking to do continuous improvement, rather than the less effective repetitive remediation. 

So here we have a graphic, beginning, as they always do, at the top, where we categorized the system and data, and here's where we establish what sort of a system it is, what it does, the data that it handles, and start to assess a level of criticality. The importance that this system and its data will have to our organization. And in the box you see the FIPS 199 and the Special Publication 800-60, which assist in us categorizing the system and its data. Moving on to step two. We select the controls that will be appropriate to the particular system context we're examining. For that, we can use the FIPS 200 and the SP 800-53, both of which outline control structures that we can use optionally, in the given context, to effectively manage and reduce the risk. We move on to step three, in which we're going to conduct the configuration and the actual implementation of the controls, and for that we can seek the guidance present in the Special Publication 800-70. Step four, we have to assess the control's effectiveness, which is guided by an addendum to the original 800-53, which contains the controls themselves, and we consult 800-53A, which is a guide that helps us assess the actual control's effectiveness, in context. Step five. We move to authorize the system change, or the deployment, if it's a complete system, and for that we turn to the guide Special Publication 800-37. Step six completes this cycle by instituting continuous monitoring techniques for the activities and the events, to manage this implementation in real-time, and for that, we once again turn to Special Publication 800-37, and SP 800-53A, once again, the assessment guide for the controls selected for the 800-53. This is the cycle if we employ the NIST risk management framework methodology. There are, of course, other ones, such as the ISO 27000 series. But the essential steps that you see here, steps one through six, are reflected in this other standard as well, because we begin by scoping out the environment, working through, pragmatically, the steps to analyze the environment, select controls, do the actual implementation, then assess how well we've carried that implementation out. As a side note, it has to be taken into context that no matter how good of a job we do, we won't really know how effective we've been in implementing these things, until we go back and assess the quality of our implementation. Then, management has to approve the system and the results of this, to authorize the system, or the system change, to be operated. And then, as always, all these methodologies conclude with putting in place continuous monitoring. 

So we're going to explore the various security and audit frameworks and methodologies. Now these frameworks and methodologies exist to support this program and its effectiveness. And what we're going to examine will be several different ones. Some will be related to security in particular. Some will be related to audit and the measurement of the effectiveness of the security frameworks. But in general, these frameworks do not conflict with each other, but rather are best thought of as overlays to the system. Think of the various layers that you find in blueprints. One layer will be the structure of the building. How it's laid out, the floor plan, et cetera. Another framework will be the electrical, the wiring. Another one will be the mechanical. How the various things, such as elevators, are gonna be put in place. Another one will be the HVAC, and how that lays out, and so on. Using that as a mental image, you'll get a much better feel for how these frameworks can be overlays, one to another, to give us a complete set of controls, monitoring, measurement, and, in the end, they constitute a complete program that will provide us not only what we need to put in place, but the implementation of what we put in place and the measurement of their effectiveness, concluded with a process for continuously monitoring their effectiveness, so that should the conditions arise where we need to replace a control or modify an existing one to improve the overall effectiveness. We have the basis for proceeding along that line, to continually improve what we put in place and get better results in the future. One that is generally used for management, security, control, is COSO, the Committee of Sponsoring Organizations, which is an outcome from what was known as the Treadway Commission. This one was really meant to address strong internal controls in a financial environment, to ensure integrity of reporting, and ensuring that disclosure objectives would be met. Here we have what our control environment is supposed to be. Tactical controls, procedural controls and so forth. A risk assessment process for looking at these controls, to make sure that the risk assessment reflects all the areas of concern, resulting in proper controls being implemented. The various kinds of processes that will be operated by the various persons within that environment, to ensure that the control activities reflect the important elements highlighted through the risk assessment, and achieve the goals established through the control environment. Then, how this will be reported, escalated, and managed actively. And then the monitoring element, to ensure ongoing effectiveness. 

Here we have the ITL, the IT Infrastructure Library, which we often refer to as service-oriented architecture. This, as you probably know, focuses on delivery of capability rather than focusing on a specific technology or even a brand of a particular device, such as a Dell or an IBM or other. The idea here is that when ITIL is put into place, we focus on what people who will be involved in this are going to do, rather than the customary technologies, Microsoft Office, and other kinds of programs that they're accustomed to using, so that we deal with what they do in tools that will enable that, and, of course, the risk and security and audit requirements that will arise in that capabilities environment. Now ITIL version three has a service lifecycle that breaks down into five phases. We come up with a definition of what the service strategy is to be. From that, of course, we'll derive what the service design is to be that will implement the strategy. Then the migration process of putting it into actual operation, then the actual operation itself, a separate thing from the transition from concept into operation. And then, again, the cycle of continuous service improvement. 

So as you can plainly see, this is a process that is not focused on security, but security is indeed an integral element of each one of these steps. And in accordance with the principles of risk management, we consider the security and audit requirements that includes compliance, of course, from the very beginning phases in service strategy. The COBIT, or Control Objectives for IT and Related Technology, sponsored by the ISACA organization, currently in version five. It includes elements such as Val IT that seek to establish the value contribution that the IT infrastructure in the given organization, and its contribution to that business's effectiveness. This includes the practices of risk IT, where in the ISACA interpretation, it reflects doing many of the things that we've already spoken of. They have an IT Assurance Framework that describes what assurance would look like. And then the business model for information security, which reflects the same kinds of priorities and concerns that the business will have over the system in question, and the security and risk elements involved in that system environment and its operation. So this forms an audit or assurance framework that overlays something like ITIL, which might be on top of something like COSO. So again, we have the blueprint, multiple layers sort of concept being put out here. 

Here we have the classic ISO 27002 as of 2013. Now, the ISO 27001, the ISMS or Information Security Management System, reflects a governance structure of five domains in which this, the Code of Practice, will exist. To implement the goals that are defined and established through the configuration of the ISMS, of the 27001. Here in the darker blue sections, you see the 14 domains of the current 27002. Here, we are doing things like implementing the controls that we might extract from the NIST Special Publication 8500-53 in each area, to ensure that the goals and objectives, the compliance requirements and so forth, are addressed properly, and effective operation of the security measures within it are put into place. So with these various overlays, what we're doing is we're looking at the idea of how we do risk assessment. That idea, risk assessment, is contained in each one of these. Now we have two basic families of ideas about how a risk assessment is to be performed. The first one, the qualitative process, is based primarily on scenarios of impact. In this process, we envision how an asset can be impacted, what kind of a threat, what kind of consequences, and so forth. This typically relies on a team of subject matter experts to get together and have a facilitated group discussion to construct and validate various scenarios that we think are reasonably possible to occur in our environment. From this, we'll make a calculation on what the risk is, how bad it could be, what the type and order of magnitude of impacts might be that result, and eventually come up with recommendations for countermeasures to what we've decided this risk scenario might contain. The other type of risk assessment that we're going to do is the quantitative process. This one, very much different from the qualitative process, is based primarily on the assessment of numeric data such as dollars, probabilities of occurrence, and so on. It tries to be as independent and objective as it can be by assigning numeric values to all the various elements of risks that we identify in the various scenarios that we will develop. This one, contrary to what the qualitative process requires, requires a large amount of data in order to establish the financial and the probabilistic basis on which it performs. Now, with that said, it should be recognized that invariably, the risk assessment process that you ultimately will do will be a hybrid of these two types of analytical approaches. By that, I mean this. With a qualitative process, you may end up with a scenario and a qualitative scale or a largely qualitative scale of high, medium, and low, or something along that line. Where with the quantitative process, you're going to come up with probability measurements, and you'll put them in categories of negligible, and varying degrees of higher levels of seriousness. But to do the actual risk assessment process, it will be a combination of these two kinds of methods, because you must begin with scenario which relates the elements of impact and the effects that they will have on the various operational assets. And you will have to rate them in terms of likelihood of occurrence, and ultimately, the dollar value of the impacts that do occur. So, it will ultimately be the hybrid.

About the Author

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.

What is security and risk management?

What is security risk management in cyber security?

What is security and risk?

What is the relationship between security management and risk management?