Why processes fail to deliver

7.2.1 Productivity issues

One of the most important areas in which processes fail to achieve the desired results is productivity. Common causes for reduced productivity include:

◗ Inappropriate control objectives;

◗ Unrealistic service targets;

◗ Inefficient control mechanisms;

Requirements for stable processes

Productivity:

Process design must result in a high level of productivity.

Adaptability:

To be capable of adapting to a

changing environment, process design must take into account the need for flexibility and scalability.

User acceptance:

Process design must meet the requirements of the end users and should be in line with company culture.

Figure 7.1 Key requirements for stable processes.

◗ Poorly designed workflow.

Inappropriate control objectives affect productivity in a negative way by diverting resources away from activities that would result in more effective risk mitigation. A control objective is obviously not appropriate if it does not significantly reduce risk or satisfy a regulatory or legal requirement. A set of control objectives can also be inappropriate if it does not provide a reasona-bly optimal response to mitigating global risk. For this reason, it is essential that the control framework as a whole implement a coherent set of security controls. In other words, it is of little use implementing extremely ambitious controls in one area if these controls can be undermined using weaknesses in other areas.

Where the information-security process delivers a service to others, it is essential that realistic levels of service be agreed with the customer. A par-ticularly good illustration of this is provided by procedures for authorization and access control. Staff expectations that exceed the capacity of the team to deliver this service results in a backlog of requests. Under such conditions, staff may directly contact administrators in an attempt to resolve the situa-tion, which in turn results in administrators spending time on the telephone and causes further service degradation.

Control mechanisms that are not regularly reviewed can quickly become inefficient or obsolete. For instance, requiring a physical signature on paper as authorization to perform some action is no more secure than using a sim-ple mail message if the signature is never checked. Mail messages, on the other hand, are likely to produce a quicker response. If checking signatures proves to be unrealistic from an operational perspective, it may be better to get the risk signed off and implement an electronic solution, which should at least improve response times. This could subsequently be improved by implementing a secure transmission method, such as secure mail, using digital signatures. Of course, neither signed mail messages nor signed docu-ments add any value if the authorizing party does not verify what is being signed.

Poorly designed workflow and inappropriate assignment of responsibili-ties are a frequent source of problems where the information-security process is concerned. A common mistake is to assign the responsibility for approving requests for security-related changes to members of the senior management team, without allowing for this to be delegated. In most organizations, senior managers perform very few routine operational tasks, and they are not particularly good at processing these requests in a timely manner. This often leads to bottlenecks in the process and can result in criti-cal delays when several approvals are required before a request can be processed.

7.2.2 Adaptability issues

The ability to adapt to change is a second area where many processes experi-ence problems. Issues in this area include:

7.2 Why processes fail to deliver 157

◗ Process design that reflects specific and not generic requirements;

◗ Insufficient use of roles;

◗ Insufficient emphasis on compensating controls;

◗ Likely future requirements not built into the design.

Although many control procedures respond to a generic requirement, they often arise in a well-defined context. A typical example would be the requirement for a procedure to control emergency change accounts arising out of an audit of a particular business application. Emergency change accounts are often created by companies to allow developers to carry out changes at unusual hours and should obviously be subject to tight controls.

If the resulting procedure is designed to take advantage of features particu-lar to the OS to achieve its goals, it will be difficult to deploy on other sys-tems. Similarly, where procedures are designed to be system specific, they are unlikely to benefit from compensating controls deployed elsewhere in the security architecture.

Procedures that directly reference the organizational structure of the enterprise are less flexible with respect to organizational changes than pro-cedures that use the concept of roles. This is an important limitation for larger organizations where management changes are frequent. In many cases, such changes involve merging or splitting departments, with the con-sequence that the procedures may refer to positions that no longer exist.

Designing procedures and control measures for individual systems with-out taking into account architectural considerations greatly reduces the possibility of using compensating controls. As the name suggests, a com-pensating control is a control that can be used to compensate for a weak-ness elsewhere. As an example, consider an application that has a known vulnerability that cannot be corrected without extensive redesign. If this application is used only by a small number of users, it may be possible to reduce the risk by placing the server on a protected network segment and strictly limiting visibility of the machine to this user community.

Processes that are designed without any consideration for future requirements are unlikely to provide a strong foundation for growth.

Despite this fact, many of the procedures used in modern, distributed envi-ronments have been simply carried over from those used in the mainframe era. Procedures for analysis of logging and audit trail data constitute a typi-cal example of this problem, and many organizations still support policies requiring regular analysis of data on all platforms. For most large organiza-tions, such an indiscriminate approach is infeasible due to the sheer volume of data.

7.2.3 Acceptance issues

Successful processes are aligned with the needs of the end user and are designed to fit in with the company culture. Processes that do not take into account the requirements of the participating parties are likely to face

opposition and may eventually be rejected. Common process-design issues related to user acceptance include the following:

◗ Complexity;

◗ Dependency on specific skill sets;

◗ Psychological issues.

The issue of complexity is discussed within several different contexts in this book, but the point to be made is always the same: reducing complexity should result in better understanding, and only by understanding a problem can we hope to fix it. It is therefore particularly important that staff mem-bers develop a good understanding of the information-security process and the role that they play in this process. Without this level of understanding, they may not be able to recognize unusual events or to react to them appro-priately if detected.

In general, process design should aim to simplify as much as possible and to avoid the requirement for specific skill sets. Unfortunately, simplification has its limits, and certain procedures will require staff with specific skill sets.

Hence, end users can be helped to select access rights matching their job function by defining roles with meaningful, business-related names, but tasks such as firewall administration remain the domain of experts. In the latter example, merely understanding the syntax and semantics of the con-trol data itself requires a good working knowledge of how communications protocols work. Untrained staff may be able to set up simple rules and report the more obvious problems, but understanding what constitutes normal behavior and managing threats requires expertise.

This last issue is interesting in the sense that capable network engineers tend to prefer project-oriented work to repetitive administration tasks.

Indeed, the more repetitive the task, the more difficult it is to motivate skilled staff to perform the required actions correctly (rather than just going through the motions). This problem was also referred to in Chapter 1 using log analysis as the example.