In today's lesson, I'll discuss risk framework. So by the end of this lesson, you'll be able to understand what risk frameworks are and how they are used, discuss how you need tools to support you throughout the process of managing risk frameworks and understand how to get buy-in from everyone who is involved in the entire risk management framework. So what is a Risk Management Framework? Well, risk management framework is a workflow and processes based approach to managing both Operational Risk and Organizational Risk. So we have two different kinds of risk. We have the operational risk that deals with operating services or systems or functions within the organization and then we also have the organizational risk which is the overall architecture of the organization. So if a risk is identified to either, we may have a problem either operating a service or operating system and then on the organizational side, we could have our entire business in trouble if we don't look at risk as a whole. So those two are the real big things that we're going to be looking at here to manage in risk management framework. Risk management framework also integrate security and risk management activities throughout the entire system lifecycle. This could also be a service life cycle as well. We'll talk a little bit more about how security is involved through this entire process. But this lesson is really geared toward risk management process, okay? Risk management framework is also a key step in providing an effective information security program. So without risk management framework, we're doing risk management ad hoc. We are not doing it on a set basis, we don't have processes that we follow. Risk management needs to be an integral part of your overall strategy in any organization or any business that you have. And how you identify that risk and how you deal with it is part of that process as well. A good framework to start out with is the NIST 800-37 publication. So that guide is Entitled Guide for Applying the Risk Management Framework to Federal Information Systems. Now, if you remember back to when we started talking about some documentation, NIST provides a whole lot of documentation for Federal Information Systems. However, it's a good practice to follow for any organization because the concepts and principles can be used throughout the entire organization or any industry. So NIST 800-37 provides a framework for ongoing and near real-time risk management for system lifecycles. So if we're looking at the very start of a system or the very start of a service, even the concept of it, we go from the very thought that there might be a service or a system all the way to the destruction of the data or the removal of that service. The document also provides leadership insights to making cost-effective, risk-based decisions. Whenever we're analyzing risk, we need to take the kind of feelings out of it. We need to make risk-based decisions and have a framework surrounding those. So an effective, not subjective, but objective-based risk decision on anything that we're doing within our organization or for our systems and services. The documentation really goes into the steps of how we set up a risk management framework. So let's talk about each of these. The Steps are Categorize, Select, Implement, Assess, Authorize and Monitor. The first step is Categorize. It talks about what is a system and how is it used. How important is it? So let's take, for example, a teleconferencing service. How is it going to be used and how it's important for the overall strategy of the organization. We need to look at who's responsible for that step and we would say the Information System Owner is responsible for that step because they are the one that's going to be able to tell you everything that is going on with that system all the time. How this step is used is it really identifies the criticality of the system. So let's talk about a couple of examples here. A credit card payment server. I would say that's a high-risk area that if data were to be or we were able to identify risk within that server then we may have a problem with operations or organization risk as well. Credit card terminals. How important is it to have credit card terminals up and running at a certain time? Well, it's not as important as a payment server where you may only have one payment server but many terminals. So depending on how we're using the service here, how we're using the system, basically we can categorize them much easier based on how many we can deal with being down at a time. Or what about a server with photos on it as well? As a server with photos or other media stored on it, as important as if it's the business's job to store photos, yes, it's important. But if it's just your personal pictures, there's other ways to mitigate that risk. Step 2 is going to be our Select step. In summary, we're selecting what kind of security controls can be placed on the system based on the criticality. This dives into NIST 800-53 controls that really outline the high, medium and low criticalites or the security controls that we can put on systems. The Information Security Office is really the ones that are responsible for this step because based on what category that we have chosen, they're going to say, this is important to us. It's used based on the criticality of the systems in different controls that should be selected. You may not have all high security controls on everything. An example of this would be determining whether or not to put Multifactor authentication on financial systems versus identifying antivirus requirements for employee workstations. So the two have very different requirements and based on the criticality of those services, then we're going to select what kind of controls that we put in place on those systems. Step number 3 is the Implementation. We're going to actually implement the controls that we've selected in Step 2 The Information System Owner is going to be responsible for that because it is not the Information Security Office's job to do that. How it is used, it's going to be very simple, we just do the work on the system. Examples of this are going to be deploying security controls such as multifactor authentication and antivirus on specific systems. Step 4 is our Assessment phase. In Step 4, it's the development of processes used to ensure information systems security controls are in place. We're going to look at the entirety of the system and say, based on what I have found, what I understand about the system, can I assess that each one of these controls is actually working? Either your Auditing or your Information Security Office is going to be the one that's going to be responsible for the work of assessment. Third-party companies are also good in this area as an independent non-partisan party to look at the overall controls and making sure they are working. Examples of this are, does the multifactor authentication work correctly or does the antivirus actually protect against the threats out there? Or what about other risks that we haven't identified yet? Do we need to go back and assess the overall system for other risks that we haven't identified? In Step 5, we Authorize. If risks have been identified in the assessment phase, how are we going to mitigate or control that risk? We also have the option here of just accepting the risk. This is also going to be done by our Auditing or Information Security Office. And if we've identified any risk or if some of the security controls are not effective, the risk must be either accepted or mitigated. Accepted, there might be other compensating controls that protect us from that risk but yet it still needs to be identified as a risk and do we have the actual authority. Are we authorized to make that determination whether or not we want to mitigate or whether or not we want to accept that risk. Some of the examples are certain antivirus cannot be placed on point of sale terminals. We've actually had this happen in our payment card industry environment at the university where some of the enterprise antivirus that we had was not effective on the point of sale terminals, so we had to buy other antivirus to complete that risk assessment. We don't want to mitigate it or accept it, we wanted to control that risk. In Step 6 is Monitor. We need to continually monitor the information system and security controls to determine if they're effective or not. The responsible party could be many different people. It could be the auditing department, it could be the Information Security Office, it could be the system owner. But we're going to document changes to the environment and conduct analysis of the security controls to make sure that they're in place and they're working and that they're actually effective. One way that we can do this very easily is going to be logging or system monitoring. In the cases with payment card industry data, PCI or HPE data, we have very specific programs that we can use to monitor the systems or the services to make sure that they're working properly and the controls are effective. So in a Complete Picture, a complete framework must work for your environment. There are going to be many different tools out there that you can use to assess the risk but one size doesn't fit all. NIST 800-37 is going to be a good starting point for you but you may have a small organization where there may be just two people auditing the system or even one person auditing the system and another one is a System Owner or we may have a very large organization where one person does just one small part of each task or each step. But we need to have buy-in from all parties in order for the risk management framework to work. We have to have buy-in from the Information System Owners, the Information Security Office and especially Senior Management. If your Senior Management doesn't have a buy-in into this entire process, your entire risk management framework is a risk in general because people aren't on board and we might miss some steps.
