We continue now with section 40, Information Risk Management and the Action Plan. It is often the case that a specific technology may be so common and ubiquitous that it is actually referenced in policy. Take for example the Transport Layer Security or any other very common thing such as IP technology.

In many cases, the organizations will have multiple unrelated architectures, and this is more the norm than the exception. We have this occurring across database, server, identity management, and other places in our infrastructure. They function fine on their own, but unfortunately integration, communication, and even collaboration causes them not to combine very well. And like different people working on different parts of a car without working together, we have a lot of disconnects, and unfortunately a lot of incompatibilities that have to be coped with.

This leaves us in a situation where nothing will fit together smoothly or at all. And, like a car, they don't work when assembled. And this is the primary reason why we need to examine and ultimately it's suggested, recommended, that we select an architectural framework to help us overcome these incompatibilities.

Now when building an information risk management program, the security manager needs to develop processes and procedures, roles, responsibilities, and templates for business records. These can be a lengthy and laborious undertaking, and it lacks assurance for success.

Indeed, when building a program from scratch, it is often suggested that security managers refer to the multitude of high quality risk management frameworks, including the following. The ISO 27001 ISMS, the ISO 27005, security techniques, information security risk management, or an alternative approach, the ISO 3110 risk management, risk assessment techniques.

NIST of course has its own. NIST special publication 800-39 for example, managing information security risk. ISACA's COBIT 5. The RIMS Risk Maturity Model, and a facilitated risk management process known as FRAP. Each of these describes management components and interactions at a very high level. And the components include roles, policies, standard operating procedures, and so on.

Each also facilitates short term deliverables such as risk mitigation options coming from conversations with subject matter experts, ensuring policies are followed, and so on. Now other goals the framework helps ensure would be that the program adds value, that it is cost efficient, that management understands the security drivers and their benefits, that there is security knowledge growing within the organization, and that it is captured.

The program fosters cooperation and good will amongst the workforce. That stakeholders understand their roles and the roles of others as they work in the program, and that ultimately continuity of the business is addressed. Frameworks are two types of approaches that risk managers can choose from when considering any of those existing.

First they can select a single framework that has the best alignment with the organization's practice. This is usually a well advised approach. Secondly, the security manager can select elements from one or more frameworks to build the organizational risk management program. However, as noted in the other chapter, there are several things that influence this. And the tendency to build by piecemealing several different frameworks runs the same risk of incompatibilities or overlaps and gaps.

Now the frameworks we're going to talk about are typically breaking down into five areas. Technical, operational, managerial, administrative, and educational or informational. Across these, their aspects will fall into several different component categories, such as program scope, information risk objectives, the policy, risk appetite and tolerance, roles and responsibilities, risk management life cycle processes, risk management documentation, and of course, periodic management review.

Now managers in regulated industries need to understand legal and regulatory requirements so that they might select a framework and build a program that has all the required activities and characteristics that may be subject to that industry's regulations.

Secondly, if an enterprise risk management program is in place within the organization, that security manager should consult with the enterprise risk management team in order to understand how the frameworks will support each other if multiple are selected, or how the current framework that is in operation is functioning.

When we examine in more detail technical components, we find that these refer primarily to systems and networks. We have to establish that each of these elements taken as a discrete element in the combination of systems, they each have an owner and very likely a custodian which may be a separate role entirely.

The owner is responsible for costs and behaviors. The custodian role is generally responsible for day to day management and administration. Now each business unit that requires a system is often considered to be its owner. Certainly they also have the custodial function. But in any case, all systems must have an identifiable owner, a responsible party as indicated by management. The purpose of this is of course not just operational, but to establish accountability for the system network and its components.

One of the aspects of this is how the system will integrate into the environment to be efficient and effective. The organization's risk management program needs to fit neatly and relatively easily into the organization's existing policies. The risk management program should therefore compliment existing structures instead of building separate structures.

The principal at work here is one of utilizing existing structures and minimizing impact to the organization. A new or improved risk management program will already be disruptive on an organization in need of such a program, but there is no point in making the component tree of the program disruptive as well. The organizational components therefore need to be management and administrative activities that are conducted on a routine basis, sometimes daily, sometimes weekly, sometimes less often, sometimes more often.

The execution may require different departments to perform them. The security manager in his role or her role must therefore exercise oversight over these functions to insure their proper performance and their timely accomplishment. Some examples of these include credential administration, security event monitoring, system patching procedures, change control, collection of security metrics and reporting, maintenance of control technologies, security incident handling, and retirement and sanitization of hardware.

In all cases, we need to identify the owner and ensure that the documents are not only being performed but they're kept up to date on each component. We then have to explore the management components. When designing and establishing a risk management program the security manager needs to understand the business context on which the risk management program will exist. This includes the scope of the program as well as the entire business environment in which the program will operate, including the organization's policies, processes, practices, and not to be overlooked, the culture.

The context is not simply the whole of the organization. Although in some cases it may be. Instead the security manager together with executive management needs to define the boundaries within which the risk management program will operate. Now these definitions may include the following. Business units, lines of business, locations, regions, or other forms of delineations. 

articipants and stakeholders in the information risk program must also be identified. The roles and responsibilities for participants and for stakeholders must be defined and made very clear. And then we have to define of course the risk appetite and the tolerance. And the management components that support this will be the timeliness on which these functions are performed, which may mean reviews every few months or quarters, or annually.

Some examples will be the development of standards, the review of policies, the executing of oversight of any initiatives. Management must shape the goals of the security program and to ensure that they line with the business objectives at all. These by their nature will define what must be managed to ensure success or measurement of that success or in a gap. And then we must ensure that senior management is being provided with the proper oversight information and feedback.

As separate and distinct from the managerial components, we will have administrative components which see the things at a slightly lower level. The information security department itself of course must be managed, populated by subject matter experts, technicians and others.

In this configuration, they will need of course resources, personnel, financial management, and occasional changes and refreshing of all of these. Efforts as always must be prioritized to focus on risks that have the greatest potential for occurring frequently, or having great impact when they do. The security manager may be pressured or feel pressured to take shortcuts from time to time when any of these resources may be lacking or difficult to acquire or frankly impossible.

In doing so in their role, they must escalate these issues to senior management for proper resolution. Now ensuring that business units are themselves aware of the temporary security resource shortages, also informs the stakeholders of the conditions and they inform them of additional responsibilities that have to be shifted to them or away from them in order to compensate for the temporary condition.

Critical to all of these will be the educational and formational components. Now the type of materials and the target audience of the training that may be necessary throughout this risk management program will change from time to time. We have content such as risk awareness, and that may take place at new employee orientation and their initial training that occurs.

General policy and procedure training is a program that may be monitored and provided by human resources, and then role specific training may take place at the business level. All different kinds of techniques will be used such as interactive, role playing, scenarios, and others.

Collaboration with HR and the other units to decide what needs to be covered will be a reflection of the security management program and of the prioritization that will exist in various business units. It will always be necessary to capture and communicate metrics like quiz scores, various times between training. So that a steering committee function if one exists will be kept abreast of how these things are working and that they're being performed and their impact upon operations.

Any security program, like any program within enterprise, must have a roadmap so that we know where we're going. What stops their need to be along the way, any kind of detour that might be taken, for good or for ill so that we can know exactly where we are and that we're meeting our requirements on the road and that we're going to our proper destination. We need to recall the outcomes of any successful program as a predecessor.

Now on this roadmap, all outcomes, stopovers, detours, et cetera, must appear on the roadmap to assure its continuing accuracy. Trying to develop a roadmap all in one go may be a very difficult if not impossible task, therefore, developing a roadmap in stages might be a preferred method, allowing us to focus on portions as we travel down this road.

Example stages might include these. Stage one might be highlights of how security went online with the business goals. Stage two might show leveraging, a steering committee to draft policies. Stage three might see various committees and their members conducting internal reviews. And stage four might include the implementation of a change to address gaps revealed in any previous stage.

So the elements of a road map, we should research whether or not a strategy is already in place. If there is, a roadmap should exist as a sign for how we are going to accomplish that strategy. It enables us to turn a conceptual architecture into operational reality. But if we find that there is no strategy, there's also a risk of a lack of work prioritization, or even accomplishment. It may also demonstrate that there's a lack of metrics to show any progress.

So a strategy therefore is essential for following the roadmap and ultimately implementing the security management program successfully. This means we may need to design and deploy controls as one of our very first things and that this will be a large part of development, implementation, and ultimate accomplishment of that strategy.

So developing the information security program road map. What we will do is develop the need to review existing data, applications, systems, facilities, processes, and all the human factors as well. This gives us insight into new projects that can be undertaken, that should be undertaken, but that must be in order to ensure success of this program.

The roadmap should define each step that is necessary to get to a particular goal. And for this of course, we'll need milestones. And these milestones will include key goal indicators, key performance indicators, and critical success factors so that we can measure our progress and report this to management. It is more important to establish a monitoring process than verifying values were correct the first few times they're collected.