Right in the middle of IT

The management of data security policies is such that many professionals are prone to the odd headache!

Coping with the rules, properties and policies affecting hundreds of devices – firewalls, intrusion prevention systems and anti-virus servers – is hard enough. That’s before you’ve even tried to manage them, or attempted to change their state.

The policies themselves are becoming ever more complex and demanding. However, they’re still in need of instant usability and flexibility such that any changes to them must be made quickly, easily and accurately.

One way forward is to centralise the management of these architectures and policies, and yet managing this ‘centralised security management’ (CSM) in itself requires a special focus if you are to ensure that all devices work coherently in providing the security that justified their cost.

Adopting the CSM-style approach affords you a 10,000 square feet ‘dashboard’ view of the overall security landscape that enables you to more easily configure, validate and prioritise the system from a security perspective alone. The administration of software updates – and any authentication and integration with third party devices – will also work more effectively if managed from a central point.

Configuration and validation

One of the first areas to benefit is the configuration of security devices. Misconfiguration is a common problem, particularly when managing security across multiple domains. It is much easier to manage configuration if you can do it across the board, rather than having to continually reconfigure individual entities. At the heart of this is the concept of object reuse. If a policy has already been defined, it is easy to reapply it.

CSM is also invaluable when it comes to validating the configuration. How do you know that what is being displayed is actually deployed and activated? You need to know that what you are seeing is what the device is providing. End users are always looking for ways in which they can verify this. There may also be a requirement to ‘back manage’ a piece of configuration. If you were to update a configuration, can it be changed back?

The ability to restore a configuration by roll-back is hugely important when you are managing a complex configuration of firewalls or other security devices.

You can, of course, configure each device independently. Using CSM, though, means that you have access to all of those devices. This includes mirror clusters of firewalls across duplicate – and, it must be said, within different – geographical areas.

Assuming that you’ve managed to configure your data security devices, the next concern is monitoring them. You may have the devices set up to your satisfaction, but you need to know if those same devices are operational (and what the traffic flow is). You need to be able to access logs and check on the health of devices, their memory state and CPU use. Furthermore, all of that needs to be carried out in real time.

Managing the firewall is critical to your system’s security. You need to know the traffic flow through the firewall at a specific time for a number of reasons: troubleshooting, capacity planning, analysis and security incident investigation. Ultimately, the firewall’s audit granularity and report capability is key to accomplishing this.

Criteria must be flexible

In terms of event alerts, the security and IT teams will need to know where they are coming from. For example, are they emanating from one device or a series of devices? It’s clearly much more of a security threat if you have the same attacker targeting 15 different devices, perhaps an automated attack, rather than perpetrating one isolated attack. The CSM system needs to be able to understand and correlate what is happening, and the criteria must be flexible.

There should also be some kind of prioritisation built into the system. Where do the system’s priorities lie – in a port scan or disk use? In other words, does a security alert hold priority over a system alert (such as 100% use)? These sorts of rules have to be built in such that the system is then able to make judgement calls on prioritisation.

The same can also be said of the priority given to software patches or updates. Which is the more important? Software updates or security ‘fixes’? Normally, you’d say patches were more critical and so would have a higher priority. How, though, do you identify what updates are available?

The CSM must be able to do that, identifying the type of firewall, which version is running and whether any updates are available.

The critical element of CSM is the management server. If you are going to operate a centralised system, you need to manage the risk of what a user can do to CSM data, funnelled through that management server. Thus, access to the management server must be rigorously controlled (for example, by using a Public Key Infrastructure and digital certificates)

Assuming an update service is available, it is essential to know how to access it, and how it might be pushed out to security devices. An update candidate should be downloaded locally to the CSM ready for distribution to the firewalls in a central fashion. The system will need to know if the update applies, and whether or not it can be validated.

In applying the update, it is likely that this will be in the form of an automated application but will be initiated manually by the administrator. The interface to the update should be centrally managed.

The risk can be higher

When it comes to upgrading devices, it could take anything up to an hour to complete each one manually, thus the upgrading of all devices could take days to achieve.

Centralised management is far better, but entails a greater risk. The disadvantage is that the risk impact of doing everything together is higher because multiple devices are updated simultaneously. If something goes wrong, the effect is magnified. Therefore, all software updates must be digitally signed by the software vendor for integrity. That software verification must tell the system that the update has been signed by the correct vendor, that the validation isn’t corrupt and that the update is the current version.

Once the upgrade process has been successfully completed, it is important that the firewall or other device is given a date and time stamp to say that the upgrade has been completed. This is very important for version control (ie the end user knows which version of a given software program is running at any given time).

If the installation of an update fails, the system should have an ‘automatic rollback’ procedure in which any device in the process of being upgraded reverts to its previous working state. One of the problems with a CMS is that all information – such as configuration, logs, alerts and software upgrades – is held in a central databank. Of itself this can be a risky business, because all of your security information on all of your devices is held in one place. All of your eggs, as they say, are in a lone basket. Therefore, as part of your own administration and security environment the CSM itself must always be backed-up.

Permissions and authorisation for access is also an issue which users of centralised management systems must bear in mind. For example, which users have access to which firewalls, and what access control do they have for those firewalls? Do they have read or write access, or both? Can they create, notify and/or delete? The type of permission a given user enjoys is vital to the secure running of the system. Security and IT managers be aware!

A little more time

Time is another important criterion in safeguarding access to devices. For example, your security may define login restrictions on a time basis. Typically, shifts for monitoring are for three per day, each of eight hours. Your system could have user IDs for login tied to specific times during a shift, and only when on that shift. This means that the user ID may only be deployed during pre-defined and approved time ‘windows’.

The critical element of CSM is the management server. If you are going to operate a centralised system, you need to manage the risk of what a user can do to CSM data, funnelled through that management server. Thus, access to the management server must be rigorously controlled (for example, by using a Public Key Infrastructure and digital certificates). Oh yes... It is also necessary to maintain a listing of who changed what and when. That’s very important!

Integration with third party solutions

There is one final area regarding the use of a CSM that demands attention: integration with third party solutions. It is important that any centralised system allows effective integration with third party solutions, in particular third party monitoring solutions such as HP Openview, Webtrends and IBM's Netview (generally speaking by using an SNMP agent).

There is no doubt that CSM allows you to take control of your data security. Without it, you could find that 70% of firewalls may be configured incorrectly. If you want to change key lengths or rotation for access control, it will help in this regard too.

If you’re trying to accomplish configuration for a Virtual Private Network, either on a star or meshed topology, CSM will undoubtedly make your management a far easier process.