We now continue with section 18, Culture. It frequently has to be recognized about any enterprise, of any age, is that over time it develops a culture. This culture and its attributes and behaviors must be taken into account whenever we undertake to place any sort of program that involves change, quote, to the way that we do things, unquote.

Every company has a culture of one kind or another whether or not we notice it. Culture is composed of various attributes such as organizational behavior, influence, various attitudes among the workforce, what is considered normal, teamworking, existence or the lack of turf wars, and various other internal politics, and geographic disposition.

What we are hoping to achieve through the Office of the CISM is to create a security aware culture. That is, a culture in which people do their jobs in a way that protects assets, as well as seeking to perform high quality accomplishment. Such a culture would involve everyone from top to bottom.

The evidence that we seek and the behaviors that we hope to instill include having security representatives participate in internal projects, users knowing how to identify and report incidents, having internal communications lines set up so that security management is available to all members, and so that people have a clear sense of what their role is and the overall enterprise security culture.

So let's examine what it means to perform culture creation. In step one, a group experience is something in common. Step two, the group response to the experience in various ways, yet similar ways. Step three, the response becomes the quote, expected behavior, unquote. Step four, this now expected behavior becomes an unwritten rule. And step five, this now unwritten rule becomes the norm.

So we see the process in the graphic on the slide progressing from experience, to response, to behavior, to rule, to acceptance of the norm. As I mentioned, culture must be taken into account when trying to build a program of greater security awareness among the enterprises workforce. And it is very important that we take this into account because culture can defeat the efforts along this line more readily than any failure of technology.

Culture creation is a common occurrence within any group of persons who live and work within a reasonably homogenous and stable environment. Over time, this process moves the group from disorganized and non-standard responses to a more homogenous response through various types of organic evolution, which means it is not under any direct control or supervision.

This organic evolution produces the way we've always done it mentality, which then becomes the unwritten rule. Eventually, new conditions arise that show these norms to be increasingly inadequate and ineffective to cope. What has been good enough no longer is.

Thus building a cultural norm, such as one of more security conscious workforce can prove to be difficult to establish, and replacement of the old. Nonetheless, the CISM is a primary source and motivator of just such a change, instituting the new norm through quote evolutionary not revolutionary means unquote.

Now we're going to move on to section 19, in which we're going to continue our discussion of metrics. Now, as we discussed before, determining which metrics are going to be collected and employed to inform our decisions, and our programmatic actions are very important steps to take. We're going to discuss now in a little more detail some ways that we can go about this problem and decide on metrics, and how to apply them.

First, we take the basic problem. Two data points that are to be compared to each other. We establish first a reference point as a baseline, which should serve as a reference point of known quality or quantity. Then, as with all metrics, we take a measurement to some other point, and then compare it to the reference point to determine any variation.

Fundamental to how this process works of course is the establishment of criteria, so that we have a consistent way of defining and measuring the particular attribute of the system, or component, or process that we wish to measure. One system of doing this is called SMART, which is an acronym that stands for specific, measurable, attainable, relevant, and timely.

These five characteristics are crucial to any meaningful and valuable set of metrics that we're going to use. And describe the very things we need the most. Another approach would be to determine accuracy, cost-effectiveness, repeatability, predictability, and actionability. As a combination of these two methods it would seem therefore to be the best approach.

Now as we described before, one thing we must do regardless of what metrics we're talking about, we must ensure that what is being measured is actually relevant. Metrics that we might use have to be of value in the story that they're going to tell. And the intelligence that they're going to provide should be actionable.

As such, these metrics must provide the basis for making well-informed, sound, important decisions. Generally speaking, metrics fall into three essential categories. Strategic, tactical, and operational. Essentially to their collection and their contribution to the given recipient of the metric would be to make sure that they align with the level and type of audience who will be receiving this information, and upon whose decisions this will depend.

For example, senior management will care more about strategic metrics like risks impacting business goals. Whereas the IT security manager may care more about tactical metrics, like the number of password resets. Now we move into section 20. And here we're going to make the discussion of current state versus desired state, and explore the gap between and how we close it.

So let's start with an overview. The first thing we have to establish is where we are today as our current state. The second thing we want to do is define as clearly as possible, what our desired end state is to be. This of course can be defined as the necessity to achieve compliance with some regulation, some state of operation, or a combination of the two.

Our next task is to describe the pathway to get from our current state to the desired state by performing a gap analysis in as much detail as the situation requires. This is of course going to provide us with actionable intelligence to be able to describe the roadmap and then follow it successfully. You may find that describing the desired state or end state will be easier to do then to do so with the current state.

As the chosen ideal, the end state has no encumbrances such as ongoing work, changes in the working environment, to cloud the vision of the person establishing this roadmap. Comparatively, precisely establishing the current state can be somewhat tricky due to the fact that there's very obstructions will be present and active.

So let us begin with the current state. It is vital that we use the same approach to determine the current state, as it is for creating the desired state. If for example, you decide to employ the use of COBIT for the desired state, COBIT should also be used to define the current state. This reflects the necessity to ensure consistency of description, and measurement.

One of the tasks that should of course be conducted is a risk assessment on the current state. Part of this should be to include an inventory and an effectiveness measurement of controls present in the current state, so that the differential between the current state and the desired state can be clearly understood.

Risk assessment methods of course include COBIT 5, the NIST Guide, Special Publication 800 dash 30, the ISO 27005 risk assessment method, the Factor Analysis method known as FAIR, and the recently discussed OCTAVE Method. Part of this process should be to conduct a business impact analysis that will assist in developing a strategy for evaluating controls and risk exposures, as well as to provide input on information classification.

Now, we look at the desired state. With the desired state, we're going to compare that to the initial state and describe a pathway to go from one to the other, and accomplish the goals to arrive at this desired state. This will have quantitative, as well as qualitative aspects to it.

The quantitative of course looks at the various numbers, money, time, and other similar quantitative factors. And looking at these values, they may require some level of precision that is not achievable easily with security, like it might be in other areas.

The qualitative associates definitions and attributes with the outcomes desired. Qualitative aspects will require comparable precision, but will involve qualities, and conditions, and criteria more than purely numbers. The qualitative will specify a scenario in which all the quantitative ones will need to be achieved.

As with risk assessment, establishing this pathway will be a hybrid of both quantitative and qualitative factors. In looking at the initial state and the desired end state, we define the distance between the two in terms of time, and other factors as a gap. This gap will have to be looked at very closely to determine what elements exist, are absent, or are differently configured, that are required to close the gap and achieve successful compliance with the desired end state.

The gap analysis as an exercise should be performed on each goal, each risk, and each potential impact of not achieving these successfully. This gap analysis should be a repetitive exercise on at least an annual basis, so that you always ensure you know where you are versus where you should be.

One approach would be to start by working backwards. This of course means beginning with the end in mind, and working your way back until you have found where you are, and then set out to describe the pathway to close that gap.