Classifying issues

The output of the initial series of interviews is as follows:

◗ The minutes of each meeting, which are distributed to the people interviewed and agreed;

◗ An internal document summarizing all issues identified, including the name of the person or people that identified the issue and a descrip-tion of the problem.

At this stage, none of these documents are for general circulation. This is because some of the identified issues are contentious, and different stake-holders have different points of view on what the issue is and how it should be solved. An example of such an issue is the problem of the high standards

being set by the audit department and the business need for rapid time to market. Knowing that the resolution of these issues is likely to be a difficult process involving some degree of compromise, we choose to solve this issue by discussion groups and not by circulating analytical documents.

Now that we are aware of the known issues, the next task is to prioritize these in order to decide which issues can be solved quickly and which require a more strategic approach. This prioritization will take account of several factors, including:

◗ The risk associated with the issue;

◗ The estimated timeframe within which a solution can be implemented;

◗ The extent to which there is likely to be agreement among stakehold-ers on the issue itself and how to resolve it.

The results of the prioritization exercise are shown in Table 4.1 and include the issues raised in Section 1.9.

At this point it is extremely important to stress that the prioritization presented in Table 4.1 involves professional judgment, and there is no right or wrong solution. Any similar exercise is therefore open to discussion, and indeed such discussion can be very helpful in understanding how different stakeholders perceive risk and the degree to which they are prepared to accept identified risk. In other words, while we strive to impose a struc-tured approach to resolving issues and to use good engineering practice, we also recognize that this is not an exact science. Ensuring that stakeholders feel comfortable with the approach and obtaining their buy in where actions are concerned is as important as carrying out a correct logical analysis of the issues. The examples discussed in the following paragraphs will help the reader understand the factors leading to this prioritization in the case of The Secure Bank.

Starting with the high-priority issues, points I1 and I2 are almost self explanatory. Issue I1 is judged as high priority because the visible support of executive management is a necessary condition for success. Support at this level will also help to assure that information security as a whole is correctly prioritized with respect to other concerns, such as the need to reduce costs.

Issue I2 is also of paramount importance, as the approach we wish to intro-duce puts a lot more emphasis on risk analysis and somewhat less emphasis on policy. Both of these issues can be dealt with in the short term, and nei-ther point is likely to be contentious (although we will need to work closely with the risk-management team where the second point is concerned).

Issues I3 and I5 are classed as high priority, as they are contributing to the current negative image of the IT security department. Finally, issue I4 is also classed as high priority, as it is a source of friction between two stakeholders.

Of the high-priority issues, only issue I3, insufficient dialogue between the security department and users, poses a planning problem because this cannot be resolved in the short term. By comparison, issues I16 and I17 are classed as low priority mainly because both require significant investment before any real benefits can be achieved. Where issue I3 is concerned,

4.4 The consolidation period 93

Table 4.1 Prioritization of Known Issues for The Secure Bank

Id Issue Priority

I1 Support from Executive Management

Currently, the support for the information-security process by the executive management team is quite passive. Support needs to be more active and highly visible.

High

I2 Absence of Risk Analysis

The current approach to IT security is almost entirely policy driven and little risk analysis is carried out.

High

I3 Insufficient Dialogue Between the Security Department and Users There is little dialogue between the security department and other departments. The main point of contact is a yearly presentation, which is largely out of date.

High

I4 High Standards Imposed by the Audit Department

The standards currently imposed by the audit department are inconsistent with the restrictions being imposed upon project teams.

High

I5 Lack of Involvement of Production Support Staff

System administrators and production support staff feel that they have little influence on the security of the machines they administer. Several interesting ideas for improving security at a reasonable cost have not been followed up on.

High

I6 No Defined Approach to Privacy Issues

Nobody is taking ownership of data privacy, and, consequently, there are no policy statements or guidelines in this area.

High

I7 Theoretical Approach

The current approach to information security is generally thought to be too theoretical. A more hands-on approach is required.

Medium

I8 Poorly Defined Responsibilities

Responsibilities are poorly defined and do not match what happens in reality. In addition, the current set of responsibilities in incoherent across the enterprise.

Medium

I9 Risk Management Not Aligned with IT Security

There is no collaboration between the risk management group and the IT security group.

Medium

I10 Administration Procedures Do Not Scale

Existing procedures for security administration are based on those originally defined for the mainframe. These procedures do not scale well and are often ignored. There is little automation in place.

Medium

I11 No Coherent Approach to Information Security

There has been no attempt to create a coherent framework for information security, which covers physical security and personnel issues in addition to IT security.

Medium

I12 Insufficient Security of Mobile Devices

There is currently no consistent approach to securing mobile computing devices, such as handheld and portable computers.

Medium

I13 Operational Responsibilities with the Audit Department

For historical reasons, the audit department has retained certain operational responsibilities from the past, notably the administration of access rights on mainframe platforms.

Medium

I14 No Integration with Software Development and Acquisition

There has been no attempt to align information-security concepts with software development and purchasing activities. Consequently, projects tend to bypass the IT security department.

Medium

however, we can expect to achieve benefits in the short term even though the issue can only be resolved via a strategic approach.