Implementing Security
First Published: SC Magazine

I get to work with a lot of the world’s largest and most complex organizations on an almost daily basis. You would think that these organizations, with their highly skilled and sizable security departments, would be able to handle almost any security problem thrown their way. While they certainly have mature and established security policies, and are aware of many of the pitfalls, their problems tend to manifest themselves in the way their security advice is implemented.

With a large and highly departmentalized structure, many organizations find themselves suffering from poorly implemented security solutions. The security logic may have originally been sound, but somewhere between the approval phase and the technical rollout, focus was lost.

One recent security assessment springs to mind. The client’s security strategy included the installation of firewalls at each important network segment and remote site - several hundred firewalls were required in all. The rollout had been under way for many months; the project manager had everything under control; and the project was on target to be completed on time. My security assessment team had been tasked with testing the secure hardening of several hundred critical servers and verifying the integrity of their perimeter defences (i.e. firewalls and intrusion detection systems).

Through standard port scanning procedures, we noticed that many ‘strange’ ports were indicated as being open or filtered. The assessment team received permission to review the appropriate firewall rule bases.

Reviewing a complex firewall rule base is not a lot of fun for most security professionals. However, after sampling a few of the firewall rule bases alarm bells rang in the consultants’ heads. Not only were the rules overly complex and repetitive, many were completely contradictory and effectively turned the firewalls into expensive routers.

The problem lay with the technical team doing the physical rollout. To keep business interruptions to a minimum, a decision was made early on to ascertain the types of network traffic currently on the network segment about to receive the firewall, and install an appropriate rule set.

Unfortunately, to do this they chose to sample network traffic over 72 hours and use this information to build the rule set. It was a pity that the rollout team was not aware of some of the more common Trojan horse port numbers - they could have raised the alarm with their security team after finding some odd ports.

So, not only were their newly installed firewalls functioning as expensive routers, but holes had been made that specifically allowed communication with probable Trojan horse software. The advice to the client was to halt their firewall rollout immediately; to develop a set of policies and procedures for specifying firewall rules; and to immediately investigate all the hosts with the ‘strange’ ports.

Another typical problem encountered is the backing up of critical hosts within secure environments.

While many security departments ensure that the perimeter defences for critical hosts - particularly internet facing - are in place and functioning correctly, recoverability does not feature quite so high on the list of security objectives. Thus the ‘server team’ or similarly tasked department must develop its own processes for ensuring a safe and robust backup infrastructure.

The most common approach is to develop a secondary backup network by dual homing the critical servers. Unfortunately, a common implementation failure results in the bypassing of any firewall or segregation between the servers - not often marked on the security department’s version of the network diagrams.

So, with the compromise of a single host, an attacker can potentially reach all other systems also connected to the backup network, eluding the backup networks IDS. I have yet to see an organization that has installed network IDS on their backup networks. This is a common failing in many managed server farms at hosting facilities run by third-party ISPs.

The point of these examples is to show that, even with the best laid plans, security departments must be able to understand how their solution will be implemented within a live environment and to ensure that a mechanism for verifying the solution is available. It is vital to consider the personnel or departments that will be deploying and managing the security solution, and to take a collaborative approach. 
    Copyright 2001-2007 © Gunter Ollmann