A Proactive Approach to IT Security Management

{LANG_NAVORIGIN} Security Management
Steve Purser 02/28/2005

3.Key ideas for a new approach

Much as modern organisations as a whole are under pressure to produce results faster and at lower cost, the IT security manager is under pressure to achieve similar results in order to keep up with the business processes. As there is a limit to what can be achieved in terms of restructuring of processes and efficiency gains, it is inevitable that the organisation as a whole will be forced to accept solutions, which represent a compromise between risk and opportunity. There is nothing new in this statement as such. What is new is the speed at which such decisions need to be made and the degree of compromise, which will be necessary as a result of external economic pressures.

The following ideas are key to developing an approach, which will be able to deliver under such conditions:

• The IT security framework must enable the IT security department to react quickly to business requirements.
• Compromise is inevitable. A mechanism is required to ensure that such compromises are made by the right people and based on the right information.
• The management model must be flexible enough to cope with short-term requirements, whilst still ensuring that long-term goals are met.
• Any attempt to re-design the IT security processes and associated framework must be agreed up front with the ‘stakeholders’.

4.Defining a strategy

The IT security strategy is the roadmap for the forseeable future. The word ‘forseeable’ is important here as a strategy, which takes too long to implement, will itself have to be modified to take account of changes in the marketplace and the evolution of technology.

The overall aim of the strategy should be to enable the unit to concentrate progressively more on long-term ‘structural’ initiatives and less on point solutions. The IT security strategy document should provide a clear definition of the proposed target situation and identify the major steps necessary to get there. The strategy is therefore providing a blueprint for resolving the big issues. Examples of initiatives that may appear in a strategy document include:

• Evolution of the mission statement, roles and responsibilities.
• Revision of policy.
• Implementation of IT security Standards.
• User awareness campaigns.
• Implementation or modification of an approach to risk analysis.
• Implementation or revision of a security architecture.

This effectively defines a path of maturity (see figure 1). Organisations at lower levels of process maturity are expected to spend a lot of time on short-term requirements. As time goes on, such organisations should be able to cover an increasing fraction of these requirements via the revised processes and infrastructure implemented in line with the strategy. Highly mature organisations will be able to concentrate almost exclusively on long-term initiatives, as current needs will be catered for by existing processes and infrastructure.

5.Implementing effective processes

Careful design of the core processes should facilitate economies of scale by:

• Reducing the need for costly, specific solutions.
• Increasing standardisation and reducing complexity.
• Making more efficient use of compensating controls throughout the security architecture.

Points to look out for when designing new processes include:

Appropriateness
Processes should obviously be appropriate in the sense that they satisfy the underlying control objective. They should also be appropriate in the sense that they provide a cost-effective solution given the alternatives.

In this context, it is worth noting that some problems are more easily solved by procedural or contractual solutions than by technical ones. An example might be the problem of high-availability, where it might be easier to manage customer satisfaction and company liability by a combination of Service Level Agreements (SLA) and contracts, rather than to deploy an expensive high-availability architecture.

Scalability
It is extremely difficult to predict the volumes of data that processes will be expected to handle in the future. The access control process provides a good example of this, where granular access rights were not unreasonable on centralised mainframe architectures in the past. However, granularity is now a major issue in distributed object environments, where it may be required to manage such access rights for millions of objects. Similarly, complex workflows may result in unacceptable bottlenecks.

Scalability in this case could be improved by:

• Requiring less granularity, but increasing management control.
• Using access profiles that span multiple platforms.
• Simplifying the approval workflow.

Similarly, log analysis can be made scalable by prioritising logs based on risk and restricting analysis to those associated with the biggest risk.

Architectural considerations
Due to the way in which IT architectures have developed, there is still a tendency to design solutions to be platform specific. However, a lot of the complexity associated with today’s IT architectures is closely linked with the level of distribution of data and processing. In fact, interfaces between systems are a good place to look for security vulnerabilities as it is at these points where different security mechanisms need to inter-operate.

Another advantage of taking an end-to-end view is the ability to see the risk in a larger context and therefore to use compensating controls within the architecture.














Your IP address will be sent with this e-mail

From e-mail to e-mail