So we want to discuss the risk management process. Now this process consists of a set of structured activities that enabled an organization to systematically manage risks. Like any other business process, risk management processes vary somewhat from one organization to the next but they generally consist of a set of activities which are common. These would include, establishment of scope and boundaries, information asset identification and valuation, the performance of the actual process steps in which we identify threats, vulnerabilities, exposures, analyze various levels and orders of magnitude of risk and its impact and determine if risk meets acceptance criteria.

Then we have to determine risk treatment or response. And this is part of our strategy as to how we will handle, address, and bring risk in line with the organization's risk tolerance and appetite. We will of course need to develop part of our strategy around the acceptance of residual risk which will inevitably occur. And as always, we must figure out how we're going to communicate about, and how we're going to monitor the risks we find.

So here we have a graphic that illustrates the risk management as a continuous process. It needs to have a set formalized repeating process for performing all of our assessments and at all levels. And this will, of course, as we've discussed in the past, include both logical and physical processes.

We recommend to asset owners, the various best practice techniques to continuously monitor risks. We have to avoid applying general profiles across regions. As we've discussed, regions can vary widely and wildly in what they require legally and the various natures of culture and the business in them.

We will have to test periodically all controls in each instance to make sure that the controls are in fact performing as expected, as desired, and producing the right kind of results. So, we first defined the risk appetite. 

Second, we'll identify and assess risk. Then we will develop a risk management plan once we understand what risks we have. We implement that risk management plan. And as part of that plan, we will Institute proactive continuous monitoring which will serve for all of those that we have mitigated and for the residual risk that will remain.

So let us define the risk management framework. As we've discussed before defining a framework, we need to understand the background of the organization and its risk efforts in the past. We need to look at existing risk management activities, if there are any, and acceptable risk criteria, if there are any.

From there, we will develop a process for risk management activities appropriate to the organization, its culture, its region, and other important factors. Now each one of these will have similar requirements. We will have to draft a policy demonstrating senior management's commitment to these goals.

We'll have to do planning and resource commitments and documentation. There has to be an implementation program to ensure that whatever strategy we comprise, it will be implemented properly to ensure greater chances of success.

As with any project, there needs to be management review to ensure that progress is being maintained or that if roadblocks and log jams occur, that they're taken care of in a timely and appropriate manner. Risk management processes that need to be applied at both strategic and a tactical levels and that we produce the proper risk management documentation for lessons learned capturing.

On the right side of this particular slide, we see a number of the frameworks we've mentioned in the past. Each one of these may be appropriate to a particular operational environment. Many of them will apply to many different ones.

In our particular role as a security manager in our enterprise, we must look at these and whatever other ones fall under our examination and pick the most appropriate to our operational context. While designing an information risk management program, the security manager must understand the many key aspects of the organization's internal environment.

If an information security manager fails to take these considerations into account, the program may be less effective or fail altogether. The key aspects that we have to include will be; key business drivers, any sort of organizational strength or weakness or opportunities or threats as characterized by the examination model we know as SWOT, S W O T.

We must know who our internal stakeholders are. As discussed, we need to understand what our organizational structure and just as important, the culture. We've talked a great deal about inclusive assets. And the goals that we need to set for the organization, which will influence the goals we set for our security strategy.

Just as important as the internal environment, we may need to examine the external environment for the influences that we'll have over our enterprise and consequently, our information security management program. It is critical that the security manager and executive management understand the external environment.

While the external environment can not be in scope in a risk management program that functions internally to the enterprise, many aspects of the external environment must well be understood if the organization and its risk management program are to be successful. The conditions that we might examine and include in our deliberations will include things like market conditions, economic conditions, the industry, the various competitive financial and political environmental factors, local laws and regulations of course wherever we happen to be, the social and cultural conditions, external stakeholders, other external factors and external threat actors, and geopolitical factors.

Knowing these will help keep the organization in a better position to understand the external influences on the organization which in turn will influence various aspects of our risk management program including the considerations to include when making risk decisions and overall risk tolerance.

The combined understanding of the internal factors and the external environment will help us define the context which we'll refer to this aggregate of the environmental factors and activities that occur that we have to take into account as we build our program. As we determine what our context is, we need to define other factors such as how much of organization activities need to be in scope and what the full scope of risk activities need to be.

We will of course need to determine what roles and responsibilities of risk management participants needs to be and how risk averse or risk aggressive the organization is establishing both risk appetite and risk tolerance.

For these will need to establish what the criteria will be including what the impact, which is type and order of magnitude, what the probability of their occurrence will be, and the general rules that establish acceptable risk that management will use. This will determine what criteria will end up and which ones are likely to change throughout the course of our risk management program.

A fundamental part of any information security management program we'll be performing a gap analysis. Now this will typically be measuring the difference between where we are today, our current state, and where we desire to be, which may be based on a regulation or simply our desire to get to be more secure.

Now the security manager, as they design the organization information risk management program, needs to have a vision for the desired end state as determined by those factors. And they're often going to be based on one or more information risk frameworks. But when it comes to developing actual plans for the implementation of the components of the program, the security manager needs to understand the current state even if there is no formal program at all. And to do this, we need to perform that gap analysis.

Now this is defined as an examination of a process or a system whatever happens to be in scope and the differences between it, where we are, and where we need to be. This helps us better understand the current state in all of its detail and how it is different from the desired state, which would highlight various forms of gaps, flaws, and lacks.

In further detail the gap analysis will reveal the characteristics of the current state, how it can remain, what should be discarded, what should be replaced, and what should be added to it. And so we will need to establish what those differences are, what to control objectives should be, and how they result in acceptable risk. And from this, we'll establish a security baseline.

Now these objectives we should expect to change during the process performing our security risk management program. And this will require periodic review of re-performance of the gap analysis, if you will, to ensure our accuracy and our correct understanding of where we are anywhere along the roadmap.

One of the things we must consider in the formation and performance of a risk management program will always concern cost and benefit analysis. These can be performed in different enterprises by different means and by different criteria.

In our particular organization, we need to determine what ways are being used currently by the operational elements and see if those can be adapted to the way that we do it or want to do it in our information security management program. This will bring about a consistency of method, performance, and interpretation, as well as communication of a clear message of the results that we obtain.

Now common measurements of potential losses might be: Employee productivity impacts, lost hours due to an outage of some sort. Revenue losses, which may be direct or indirect. And direct cost loss events such as the loss of a facility or a system.

Now the events that effect security baselines include things like these. We first must establish a minimum security level across the organization as a baseline for us as our point of departure. There may be a need for baselines at higher classifications and these of course should be higher as well, reflecting the higher impact or loss potential of the assets that fall into that category.

Baselines will periodically need to be reexamined to ensure that if change is needed, we identify it, the type and magnitude of it, and that we do so in a timely manner, and what that does and what causes it in the way of potential threat changes. Any other event that might produce a change in the baseline could include new laws or regulations, changing threat environments, the degradation or the growing obsolescence of controls that we've implemented, and any system changes to take place within our enterprise.

Now as we've discussed, all of our decisions producing the strategy, the roadmap, and our implementation plan, have to integrate with the environment. And the integration of these will include the integration with IT processes. Integration is always a bi-directional thing. The environment, what we intend to integrate with it, and the effect that each can have on the other to either enable it to be more successful or less. Now information provided by the security to other departments is part of that integration: Information that we have to give them an information we need from them.

Information from other departments provided to security is every bit as critical as the information security we'll give to those other departments because each will impact the other and whatever changes might be produced. Ideally security should be determined and as we say, baked into each project from the very beginning of its development life cycle.

Now traditional system development life cycle stages are of course initiation, development or acquisition, implementation, operation and maintenance, and then end of life or disposition and risk must be included in the consideration of each of these five phases. And even after things have been operationalized, change, configuration, and release management for systems is part of what changes the risk layout.

We have to pay special interest to change management because of the influence that it has over systems operation and our risk management program and profile. We have to be sure that each change that is under consideration include security implications as part of the analysis. Thus each change should include a risk analysis on what the change is, what it seeks to accomplish, and what could go right or wrong so that we can prepare accordingly.

We have to determine where the changes are initiated, the funding of course, and how they will be deployed and whether or not that deployment cycle involves multiple locations or possibly even multiple regions. We will have to of course, periodically review controls to identify these changes over time that may be necessary.

As control's age and become obsolescent, they will need to be considered for change themselves. One thing that recurs quite often is misconfigurations and these can lead to breaches. And these are often caused by a lack of clear standards and procedures, short-handed staff who take shortcuts or are poorly trained, and then time constraints that apply pressure on existing staff.

Our release management rolls out new capabilities or updates existing ones and release management is a process that must be controlled with equal care like the others. It must include proper testing before deployment to ensure that it is indeed mature and properly ready for release and the population who will receive the change and any operational changes accompanying it are properly informed and prepared.