We're going to continue now with our CISM review seminar, and we have come to section 34 in this discussion. At this point, we're going to begin exploring the CISM domain two, Information Risk Management. In the sections of this domain, we're going to cover the benefits and outcomes from an information security risk management perspective, risk assessment and risk management frameworks, developing a risk management strategy, the risk management life cycle process, integrating risk management into an organization's practices and culture, the components of a risk management, asset value, vulnerabilities, threats and probability and impact of occurrence, risk treatment options including mitigation, acceptance, transfer, avoidance. The risk register itself. The device used for capturing and tracking or dealing with risks, and the monitoring and reporting of risk.

So let's take a look at introduction to managing and assessing risk. Risk management is the striking of balance. And that is a key word in this entire program, as well as in the CISM itself. Striking this balance means taking advantages of opportunities and minimizing loss on balance with business priorities. What we're attempting to do is ensure that risk doesn't impact processes negatively, or trying to minimize the negative impact that can occur when the risk does appear.

Management of risk should be done based on a centralized form and implemented policy, possibly enforced by a risk management group or certainly by the privacy, security and compliance areas. It can be decentralized for less of an upfront commitment. However, this can result in diffusion and increased confusion in the program long-term.

Now to sum up and state it very simply, the three phases of risk assessment include identification, which is finding our vulnerabilities and exposures. And we take an inventory of the threats that can exploit them. We do analysis, which is to perform both a risk assessment and a business impact analysis on identified risks. And to explain the difference, a risk analysis is a process whereby we identify weaknesses, flaws, vulnerabilities, and the threats that can exploit them so that what we're focused on is security. Whereas a business impact analysis or BIA is used to focus on the impact of threats when they materialize on the business, and what the actual business impact will be from such an encounter. So as such, they're not replacements, they're not the same, they're compliments to each other. But they are two distinctly and differently focused processes.

We also have evaluation. This is a way of determining whether or not the risks fall within the risk appetite and tolerance. Now our risk responses, our treatments are going to fall into four categories. We can't accept, which is usually at the end of the process. We can mitigate, which is actively offsetting the risks that we find and there possible outcomes. We can avoid them where possible, this usually comes hopefully at the beginning of the process. And then we can transfer, which is another way of saying we outsource or buy insurance. And we'll get into more detail on that as we progress through this domain.

We've mentioned culture in the past and culture can positively or negatively influence how we perceive and manage our risk. It may be that across the spectrum from completely risk averse to completely risk aggressive. We will find that we have varying degrees throughout our organization, across these levels. And they can influence how we're going to manage our risk program. The industry also can determine how important risk management is.

In certain industries risk management is an afterthought, in other industries risk management is a forethought taking on a great deal of importance. Now, for example, building airplanes may cost lives such that if we do a bad job, more deaths result, whereas if we do a good job, fewer do. Building garden hoses probably won't have the same impact. Nonetheless, risk management in its form that's contextually specific will be an important part of both.

Now successful risk management program is going to depend on the maturity level of the perception of risk present in the corporation. We're going to have to weigh a number of different factors and find balance between what they present? The impact of result and our needs to offset them. For example, if we look at HIPAA, HIPAA mandates encryption of some data even if we don't see the value of the data and the benefit of providing the encryption.

One of the rules we have in security, is simpler is usually better. And we try never to use absolute terms such as always or never. So we always have to look at the context to judge whether or not simple really is the right choice or complex. But in general, it is considered that complexity is the enemy of good security. So what we want to look at is simplistic where possible, less capable processes to more complex and more capable ones. But not assume that simple is better or worse, or that complex is better or worse until we apply them in the proper context.

Complexity tends to build in technological fragility and complexity can make problem resolution in the event of a problem more difficult. Now the ultimate goal of this program is to evolve to a truly continuous improvement posture, and away from the historically less effective repetitive remediation.

So we look at the circle of life. This is a life cycle approach that introduces technology, the management of change, and from time to time modifying and even retiring them being replaced by something that shows improvement. As such we have to manage change. We have to guard against losing knowledge of asset status as change occurs. When in fact, what we should be doing is capturing and increasing our knowledge, as well as our storehouse of experience.

Security managers should promote change management, not change for its own sake, not a lack of fear of change, but prudent change, well considered change, appropriate change, again on balance with the business objectives. The areas that find that they are often missed when change occurs, blueprints first facility updates. Sometimes those are not updated when they should be leaving us in the lurch. If something happens at an area that doesn't seem to be documented in the blueprints.

Networks constantly change. So we need to be sure that we keep our network understanding our network documentation current. The business continuity plan, what should change as business conditions, organizational changes occur. We might have to worry about remote access configurations. Again, making sure that we stay in step with changes. We have physical security, and physical security can and must keep up with changes in personnel, facilities and others.

Any change that occurs may produce changes that are necessary in contract language or service level agreements with our providers. Changes in our business needs we'll do the same. And we must maintain a storehouse of knowledge of internal and external facility management personnel to ensure that the physical security remains in step with the information and asset security.

As this graphic illustrates, risk management is a continuous process that should be integrated with our other processes at some level. When thinking about where risk management occurs the obvious answer is everywhere, but that answer is too general and as such unhelpful.

We have been discussing risk management and risk management does need to pervade our activities. And yet there are specific places where certain of it actions must take place for it to be truly effective. For example, as part of the formation of a concept or a design, as part of the functional level deconstruction of a system, or application, or a facility, as part of the detailed level configuration of any aspect or component of any of those, as part of the evaluation of any flow of any process. And as part of all pre and post implementation activities.

As with any risk management function, the goals are to ensure that process gaps are found and closed, that vulnerabilities are discovered and patched and that any threats that are credible have been effectively addressed. Whether from early on or as any recent arrival.

As the graphic shows these are iterative activities and as such should be performed through all phases from concept to operations and ultimately to retirement. Ensuring that risk management is a well-defined process will lead to its integration with other business and technological processes.

Taking the natural next step to ensure targeting the appropriate locations, so to speak. And circumstances showing the optimal potential as sources of actionable intelligence will increase the quality and integrity of the products and actions derived from it. The ultimate goal is to involve the critical activity into full integration throughout.

As vital as any traditional business process in order to achieve true continuous process improvement in risk management and move beyond the still common repetitive remediation approach. Here in more detail we show specific activities as they fit into each step in the overall system life cycle process flow.

In the earliest phase, risk known to exist and general aspects are outlined and qualified. That is determined to be both real and relevant to the context. With each subsequent phase of project development the risk characteristics are progressively elaborated adding more definition and clarity that leads to more effective mitigation approaches.

Once in operation the system must be regularly assessed to maintain visibility and performance, as well as timely adjustment when required. When it reaches end of life, the well-established risk management program will assure that the disposal process is effective in removing any residual sensitive information, proprietary design features, and all other intellectual property that if compromised could result in an adverse business impact or even negative legal consequences. Properly implemented and diligently performed this process assures organization and its systems environment are protected from end to end.

So let's elaborate a little bit more on what we talk about when we say the risk and the IT circle of life. As we've been saying, risk management plays a crucial role in all phases of the system life cycle, of which the classic system development life cycle is a sub-process. Now the SLC or SDLC has five phases.

Each project, each system, each development entity will go through these five phases as it reaches maturity and then ultimately is retired out of service. All begin with an initiation, in which we define the purpose and scope of system and its various functions. At this point the risk will impact stated requirements at a general level.

Next will come development or acquisition, where the system itself is designed or purchased and built. Risks identified earlier are addressed or noted and more detail is added to them, a case of progressive elaboration.

Following this, there will be implementation where the system is constructed, configured, enabled, tested, and then verified as ready for use. Here further progressive elaboration is performed such that the risks are now fleshed out to a point where we can understand them in detail, and they're addressed prior to converting the system into operation.

Then of course we have operations and maintenance or O and M. The system is operated and is updated as needed throughout its life. Risks of course, as I stated earlier must be periodically assessed and reassessed to ensure that all risks already addressed stay that way, and any new risks that arise can be effectively dealt with.

At the end of every system comes to the question of disposal. Now the system itself can be moved, it can be archived, or it can be destroyed depending upon which solution is required. At this point risk management still continues where the risk of residual data must be minimized through assured destruction or retirement mechanisms.

So here we have the different kinds of mitigating approaches that we use for risk. These four stages reflect the general approach in the NIST risk management framework. The first thing we do is we prepare that means that we set the stage, get all the mechanisms in place, identify our information sources and the context in which this will be performed. This means that we decide on what our strategy will be to address the risks we will find. Undoubtedly, we will find some.

Then we actually conduct the risk assessment in the second step. Here we're going to use qualitative and quantitative methods so that we can understand first the operational context in which the risks arise. We can qualify them, so that we can establish their reality and their relevance. And then we use quantitative methods to start putting times and dollars to things. Which ultimately we need for cost benefit analysis and for presenting business cases for the specific choices we're going to make.

Third we do risk treatment. Based on our findings from the previous steps, we will make choices between the various risk treatment options. Some will be proactive and some will be reactive. In reality all risk management and mitigation programs will apply both types of methods.

We will communicate the results of course to top level management, seeking their guidance and decisions about how they want best to treat these things in a cost effective and operationally effective manner. They include the classic methods, avoidance, mitigation, transference, and acceptance. Bearing in mind that acceptance as explained earlier does not mean doing nothing.

Then we move into the maintenance phase where we maintain the assessment. And this is where the continuous improvement rather than repetitive remediation becomes our standard of performance.