Let's begin talking about the risk assessment methodology by delving into the individual steps and we'll explain and explore what goes on in each of them. We've already laid out the foundation. We've looked at a high level as to what the steps are. We're now going to go in and start with step one, preparing for the risk assessment. We look to establish a context for the risk assessment in this step. The idea of establishing a context is to understand what the risk assessment is really going to frame or explain and help us to understand. Are we looking at risk that may deal with a web solution? Are we looking at risk that may be occurring from outside the organization? Are we examining risk from inside the organization? What are the variables? What are the parameters that we have to be aware of? And what is the general environment that the risk assessment will take place within? When we think about the preparation steps involved with step one, we have to identify what the purpose of the assessment is. Identify the scope of the assessment. What are we trying to accomplish? What is the focal area that we are going to accomplish it around? What system or systems, in other words, what area or areas are we going to focus on? That's the scope. What areas are in scope? What areas are out of scope? If we're looking to assess the internal network in the operating environment, we're not going to look at anything from outside. In scope will be LAN out of site or outside of scope will be anything that is remote to the LAN. And then we would want to define them. Identify the assumptions and constraints associated with the assessment. We're going to be able to do this or that. We are not going to worry about those other things. Identify the sources of information to be used as inputs to the assessment. We're going to get information from these systems over here. We're going to talk to these people over here. And we're going to look at this documentation over here. Everything else, we're going to ignore. And identify the risk model and the analytical approaches. We may have one or more risk models we want to use. We may have one or more analytic approaches we may want to use. We're going to have to identify what those frameworks are in order to be able to then prepare ourselves to move to the next level. Step two, next step, conducting the assessment. Now we've done our prep work. Got all our tools together. Laid out all of the assumptions, things we're going to take care of, know where we're going to focus, know what our metrics for success are and how we're going to achieve them. Now we're going to go execute. We're actually going to go do it. So step two is all about conducting the assessment. What's the objective? Produce a list of information, security risks that ultimately can be prioritized, that we can look at and say, "Of the five risks on the page, what is the most important one? What's the most likely one we have to address? What's the second most important, second most likely?" And so on. And so we'll move them around like jigsaw pieces in a puzzle till we figure out the right order and the right assessment. So we'll prioritize those risk levels and use that to then inform or drive our risk response decisions. If we are going to say that risk to the e-mail system is the highest priority risk, then we have to make sure all of our efforts and all of the resources we use are going to be targeted at the e-mail system. We don't want to waste a lot of time on file and print if everything's going to be focused on e-mail. It's going to distract us from our ultimate goal of securing the e-mail system and minimizing risk. So we have to make sure we know where to focus. To accomplish this objective, we have to analyze a variety of things. Threats and vulnerabilities, impacts and likelihood, and the uncertainty associated with the risk assessment process itself. What if we're assessing the wrong thing? That's something we've got to consider. It's a risk. What if we're looking at the wrong systems? That's something we got to consider. What if we're looking at the right systems, assessing the right things, but we just don't see what's there? That's also a risk. We've got to understand and identify the fact that we may be doing all the right things and still coming up with the wrong answers, in other words, right? And that is also a risk that we would have to take on and identify when we conduct the risk, or conduct the assessment rather, and identify the risks. So what are the risk assessment steps? What do we actually do? Here. Identify threat sources, identify threat events, identify vulnerabilities. A lot of identify, right? Got to be able to label and identify and see and know certain things. Threat sources, we've defined what those are. Threat events, we defined those as well. Vulnerabilities, we've defined those also. Got to know the language. If you don't know the language, you don't have a clue what these steps mean. You're not going to be able to understand what we're doing. Determine the likelihood of threats. We've identified and defined likelihood as well. Determine the adverse impacts. We've identified and defined that. Determine information security risks. We've got to identify a bunch of stuff then we've got to make some determinations. So we've got to say, "This is what we got in these files over here. Now based on that, what does that actually mean? And that's what we're doing in the risk assessment area is we're conducting the assessment in step two. Now remember, overall, step two is a large step. We're going to have a whole bunch of sub steps that get us through all of the individual activities here. We're going to start breaking those down right now. So 2a, within the concept of conducting the assessment, identify threat sources. As in, we're going to go down this list and make sure we understand each one of them. Step 2a, identify threat sources. Identify potential threats to information resources. Where are those threats coming from? Why are we worrying about them? What is the potential that this threat source over here is going to be problematic? That's what we're looking at, but in order to determine that, we first have to identify and know that that is a potential threat source. Identifying threat sources. How do we do that? Determine sources for obtaining threat information. How do we know that a threat is a threat? Well, somebody may have identified it as such over here in this online database. Let's go look that up and figure out whether it applies to us. Maybe something like the common vulnerability exposure database. CVE, that'd be a good place to look, right? So there may be other things like that. Determine what threat taxonomy may be used. Taxonomy is all about language and description. How do we know a threat's a threat? Well, somebody labels it a threat and we don't and maybe because of a language, maybe because of a reference issue. Probably have to speak the right language and use the language of threat identification. So we have to go out and make sure we're doing that. There may be industry or silo-specific threat taxonomies that we should be aware of. For instance, if we're dealing with cyber threats, threats in the cyber space. There may be very specific language about those things. Worms, viruses, trojans, malware, root kits, those are things we may or may not know about. Hopefully, you have a sense of some of those. If you don't, look them up. You need to know what they are. So if we know what those are, great. If we don't, we've got to go figure it out. But if we're not dealing with threats in cyber space, in cyber security, but rather a point of reference for threats is in a SCADA, an ICS an Industrial Control System, that has physical capabilities that we are monitoring. We are going to then look at those systems and deal with threats there. Some of those things may still apply. We could get malware that's inserted into the system to take it over. Still very appropriate. But in addition to all that, we may have other specific threats unique to SCADA and ICS. And as a result of that, we may have to know what the threat taxonomy is in that particular area. It's very important, in other words, for us to be able to speak the contextual language of the environment that we are assessing the risk within. And there may be unique vagaries, unique specificities associated with that environment that we have to be aware of. Again, it's our job, our responsibility to figure that out as part of this step. Provide input or determine what threat information will be used in the overall assessment. Kind of the general theme we've been talking about here. Call all that inventory, all that information, all that intelligence, bring it to bear to create the contextual filter for sieving through and understanding how to shake through the strainer all the risks that ultimately will stick. And the ones that stick are the ones we have to be aware of.
