• No results found

GAP ANALYSIS—UNMITIGATED RISK

In document Information Security Governance (Page 96-99)

Current State

9.3 GAP ANALYSIS—UNMITIGATED RISK

The next step will be a complete analysis for each element, attribute, and character-istic to determine the gap between the current state and the desired state. At this juncture, as each element is evaluated in terms of the difference between the current and desired states, consideration must be given to what it will require to “fill” the gap if one exists. That is, will it simply take more or will it require different processes, technologies, controls, and so on.

Assuming the desired state defines the state of security that manages risk to ac-ceptable levels, then, the “gap” between the current state and desired state is the un-mitigated risk that implementing the strategy is designed to address.

For an example, let us consider some samples of each approach and how a gap analysis might be conducted.

9.3.1 SABSA

Let us examine the following SABSA security attributes taken from the User At-tributes in the table in Appendix A that might have been used (along with others) to determine both current and desired state.

For the desired state attribute, “Protected—the user’s information and access privileges should be protected against abuse by other users or by intruders,” the cur-rent state attribute might be, “User’s information is protected by user ID and pass-words with no requirement for change and no automated approach to ensure good password construction.” The gap is fairly obvious and remediation is as well, al-though it may not necessarily be easy to convince the enterprise that the more re-strictive controls are necessary.

For the desired state attribute, “Reliable—the services provided to the user should be delivered at a reliable level of quality,” the current state attribute might be, “System performance is inconsistent and customers report seeing other people’s accounts on occasion. Customer data is frequently corrupted and unreadable.” The gap here is also apparent and is a technical problem that governance has not ad-dressed. It may be that operational standards are inadequate or not enforced.

For the desired state, “Responsive—the users obtain a response within a satisfac-tory period of time that meets their expectations,” the current state might be, “Users often complain that security is slow to respond to their issues and cause delays in necessary system changes and project implementation.” The gap is obvious, al-though the causes are not. It may be a lack of security staff and resources, or it may be that review processes are cumbersome and inefficient.

9.3.2 CMM

As an example for CMM, let us examine some of the 15 statements used for defin-ing current and desired states.

The first statement for defining the desired state for CMM Level 4, Managed and Measurable, is “1. The assessment of risk is a standard procedure, and exceptions to following the procedure would be noticed by security management.” An example of a current state familiar to many security practitioners might be, “Assessment of risk is ad-hoc and there is no formal process requiring notification of management.

Scope and frequency of assessments are not mandated and the activity is discour-aged by IT management as time consuming and costly.”

In this example, several deficiencies are clear and filling the gap will require several things be addressed. The first is the attitude of IT management. Depending on the organization, its structure, culture, and position of the security manager,

ad-dressing this issue will require various activities and may or may not be achievable.

For the objective to be realized will require either gaining IT cooperation by educa-tion or pursuasion, or else senior management support mandating the requirement as a matter of policy.

Policies and standards may need to be created or modified and approved as nec-essary for the regular performance of risk assessments and their scope as well as analysis and reporting requirements.

The next CMM element to consider is, “2. Information security risk management is a defined management function with senior-level responsibility.” The current state in many organizations is likely to be, “Information security is a part of IT re-porting to the CIO. The position is a low-level manager with responsibilities for technical security of desktop computers and the data center.”

The position as a manager in the IT department is structurally deficient and prone to conflicts of interest. Information security is a regulatory function with a fo-cus on safety; IT is fofo-cused on performance. The regulator cannot report to the reg-ulated and the pressure for increased performance and reduced costs for IT is often at the expense of security in these situations. In heavily regulated sectors such as fi-nancial institutions, there are specific prohibitions against this reporting structure in many jurisdictions recognizing the inherent problem with the practice. To close this gap will require senior management to recognize the issue and address it by elevat-ing security management to a senior position reportelevat-ing to the COO, CEO, or, per-haps, to the audit committee of the board. The scope, authority and resources of se-curity management must be equivalent to any other major operational unit to meet this objective and achieve effective security governance.

When the desired state is, “3. Senior management and information security man-agement have determined the levels of risk that the organization will tolerate and have standard measures for risk/return ratios,” the current state might be, “Levels of acceptable risk have not been defined and risk management is a reactive process with mitigation considered after an event is determined to be excessively damaging to the organization. Cost/benefit analysis is not performed for security activities and no metrics are utilized to determine performance levels.”

To address these deficiencies, several elments must be addressed. A process must be developed to ensure that management determines some parameters for ac-ceptable risk in order for security management to know what level to manage risk to—how much is enough, too little, or too much. The fact that risk is not in effect being managed but is determined by the extent to which the organization suffers damage can be considered a lack of due care and is utterly fundamental to the re-sponsibilities of senior management and boards. The failure to perform analysis and implement performance metrics means that there is no rational basis to prioritize al-location of limited resources and virtually no information on which to base security management decisions.

As shown in the foregoing examples, gap analysis, when completed, can paint a reasonably complete picture of existing deficiencies and provide the basis for deter-mining the activities required to close the gaps.

Information Security Governance. By Krag Brotby 87 Copyright © 2009 John Wiley & Sons, Inc.

Chapter 10

In document Information Security Governance (Page 96-99)