The security arsenal of the typical organisation is a collection of point tools that address individual issues. The network firewall will not be connected to the web application firewall; the distributed denial-of-service (DDoS) defences will not talk to the antivirus software.

This approach is a barrier to policy-driven security, which allows the organisation to define acceptable levels of risk, permissable network behaviour and security service level agreements (SLAs) for applications that are pushed out to individual defences.

If these point solutions are not integrated, then implementing or updating a security policy requires each one to be updated individually. This increases the workload of implementing security policies, and increases the chance that a policy will be implemented incorrectly or not at all.

The ideal situation is a service-oriented security architecture, in which individual components can be controlled using standards-based application programming interfaces (APIs). This allows a central repository for security policies –often a governance, risk and compliance (GRC) application –to be integrated with the individual security technologies, which in turn means that policies can implemented and updated automatically.

It is a good idea to bear this ideal in mind when choosing security technologies. In the long run, a security tool with medium functionality but that easily integrates with other systems might be of more use than a tool with all the possible features and functions but which operates as a silo in the security architecture and must therefore be managed individually.

However, no organisation is in a position to throw out its existing security infrastructure and replace it with all-new, service-oriented alternatives. Besides, deploying an integrated architecture all in one go would be a project of such enormous complexity, even with standards-based APIs, that it would run a high risk of budgetary overrun or even failure.

A more realistic approach is to define programmes of work, focused on one of the pillars of the security architecture, such as user access, the network perimeter or applications.

Each programme should begin with a risk analysis to identify which particular threats the organisation is most susceptible to, and which of its information assets require the most protection. This risk assessment should be use to identify the areas of most pressing need of improved protection. These areas should be addressed first – all the while bearing the long-term goal of an integrated security architecture in mind.

Avoiding complexity

Picking off manageable programmes of work and using risk analysis to identify the areas of greatest need allows an organisation to progress towards an integrated security architecture in a sustainable fashion.

However, it is important to make sure that the process of dividing the task of building such an architecture into manageable chunks does not give rise to undue complexity.

To deploy a point solution for each individual security requirement, even if those solutions can be integrated via APIs, would be to maximise the deployment costs, the management complexity of the ensuing architecture and the risk that network latency will degrade the performance of the IT infrastructure.

This is the argument for using integrated security platform solutions. These allow organisations to add functionality to protect particular applications from particular threats gradually, as part of an ongoing move to an integrated security architecture, but without the risk of undue complexity and network latency.