So you've chosen the firewall model that is best suited to your business and network needs (see How to choose a firewall 2005 ), and your vendor of choice has just dropped off several shiny new toys – sorry, network security devices – at your office. So how do you deploy and look after them, and make sure they're providing the level of protection you expect, without having to put in a nightshift to keep up with the extra work?

Let's make life easy for now and assume you just have one firewall, in your head office (or a redundant pair) as we'll look at the complexities of multiple firewalls in a minute. This is your main protection from the outside world, so it's important that it's tamper-proof. First off, lock down everything you can to stop your firewalls giving out useful information to anyone who tries to access them (see How to stop firewalls advertising their secrets to find out how even NOT replying to a probe can help an attacker figure out how to break in).

You need to set your firewall up to only allow access to a specified set of people, and there should be no shared login IDs. It's important to be able to account for any changes made, and that includes who made them. Access should only be allowed from specific hosts on a secure network too, although that can have implications for remote support, and it should go without saying (but unfortunately in many cases doesn't) that you should use a secure method of connecting to your firewall rather than the likes of telnet, which displays config details, including passwords, to anyone who can manage to get an analyser to pick up the traffic.

Managing logs and alerts
Firewalls generate logs – lots of them. And although you're hoping that if you've set your firewall up properly, it does actually keep the bad guys out, it's also vital that you're reading its logs and looking at the alarms generated on a timely basis.

You'll be swamped if you just let all alarms appear on a management station. Especially if you also have other security mechanisms, such as Intrusion Prevention devices, in your network, you may need to look at some form of correlation software (see How to Correlate firewall alarms ).

You'll need to decide which alarms are most important, and remember to take account not just of alerts for someone trying to get into a part of the network they're not allowed to, but also activity on your firewall itself. Failed (and successful) login attempts, configuration changes and housekeeping information such as memory and disk usage are potentially more important to be aware of than the fact someone's tried to ping a server.

Do you want the firewall management system to audibly alarm for a high-priority alert? What happens out-of-hours if your network operations centre or help desk isn't manned round the clock? Many systems will phone, text or page you if you want, but be sure you don't set that up for every alarm generated, or your life is likely to be very unpleasant indeed.

Logs are typically sent off to a server with lots of disk space. You'll need to decide how long you need to keep these for – this may be governed by legal requirements or business policy, and remember that if you do discover you've been attacked, you may need to produce records a long time after the fact if your company decides to prosecute. Regular archiving – in an easy-to-recover format – is likely to become another housekeeping task.

Managing upgrades and configs
There are a variety of ways in which changes can be made to your firewall's config: if you only have one or two, then you'll probably deal with them individually, either using the command line, or, more likely, a GUI front end that makes it easier to relate actual configs to policy decisions about which network can talk to which.

This often entails a bit of upfront work, telling your management system about classes of hosts, networks or resources, but once done, it's a cleaner way of setting out the rules, and is less likely to generate typos. It also makes it much easier to have a consistent picture over your whole network: if you have lots of firewalls, the last thing you want is for them all to be set up slightly differently. It makes troubleshooting a nightmare, and can open up security gaps: one mis-configured filter on a branch device is enough to put your whole infrastructure at risk.

If you have multiple remote sites, each with their own firewall, ad-hoc changes aren't going to be sustainable. Upgrades, patches and config changes will need to be managed by a central system that can handle batch jobs, working round your firewalls in turn overnight and recording what's been done. If your company has lots of teleworkers, the problem is compounded – it's likely that each user will have a personal firewall (either software or hardware) and you need to manage them in terms of alarms and logs as well as changes. Not an easy task if they're DHCP-addressed devices, getting addresses dynamically from the local ISP. There are systems designed to cope with just this situation, but they may be proprietary to the firewall manufacturer.

Firewalls aren't the sort of thing you can just install and forget about. It's important to be aware of what they're doing, but you need to manage the information they're giving you, if you don’t want to wear yourself out looking after them.