Every week, security analysts put out new lists of vulnerabilities, and operating system and application vendors deliver appropriate patches and fixes. But how should IT departments go about deploying these patches? It doesn't really matter whether it's Unix or Windows; a lot of work needs to be done before patches are installed and businesses systems stop being vulnerable.
Security is often seen as a cost, not a benefit, but that's not the best way to understand what managing security means to a business. Peter Key, of Cap Gemini Ernst & Young, describes it as similar to paying insurance premiums. Businesses need to undertake a risk analysis, looking at their IT systems, understanding the value flowing through them, and examining the cost to the business if an exploit shuts them down. This process should lead to a plan showing just what needs to be managed, and how.
Some systems will need to be patched as soon as a security fix is released, while others can be left until an appropriate point in their maintenance cycle. It is even possible that some systems won't need to be patched, if the associated risks are low enough.
Most businesses focus on securing their perimeters, using firewalls and virus scanners to make sure their networks and computers remain secure. As email is now one of the main sources of malicious software intrusions, tools such as Sophos' Enterprise Manager are an important feature of any security architecture, allowing you to deploy the latest updates centrally. However, no firewall is perfect, and not all attacks come from outside your business - so it is essential to make sure that internal systems are as secure as possible.
Part of the problem is that there are so many patches. A business running several different desktop and server operating systems, along with a substantial number of applications, may find itself having to deal with dozens of different patches and updates a week - more if a significant security vulnerability has been discovered. In some cases, a single vulnerability may affect many different systems, as happened recently when a problem with the SNMP network management protocol was discovered.
Before you deploy a patch, it needs to be tested fully. While most patches are tested before they are distributed, there could still be effects on your applications. There are issues here for all sizes of businesses - small and medium enterprises tend not to have the resources to manage testing and deploying security patches, while larger businesses often have too many machines to manage effectively. Full testing means implementing duplicate installations of critical systems, along with appropriate test cases to run before a patch gets a clean bill of health. It is a process that can take a considerable amount of time, increasing the risk of vulnerabilities being exploited: hackers often target recently announced insecurities because they know testing and deploying fixes takes time.
Bill Pepper, of Computer Sciences Corporation, points out another significant problem for UK and European businesses trying to stay on top of security vulnerabilities: time zones. Patch notifications put out during US working hours will all be waiting in system managers' inboxes first thing in the morning. It is essential to build a process for managing patches, and prioritising which should be tested and deployed first.
One option is to use a vulnerability scanning tool to keep track of what needs patching. These can be simple, such as Microsoft's free Baseline Security Analyser, which scans Windows PCs and servers for known issues, and checks they have had the latest fixes and patches installed. This was developed for Microsoft by a third party, Shavlik Technologies, which produces more complex enterprise-level tools like HFNetChk Pro, to scan and update operating systems and applications on large networks of computers (there's also a free "Lite" version that works for up to 50 PCs). Security specialists such as ISS and VIGILANTe also provide vulnerability scanning tools that report on known attacks and what needs to be done to prevent them.
Ironically, the number of security issues with Microsoft offerings means more tools have been developed to deal with the problem. While Windows managers can take advantage of Microsoft's Windows update tools, things aren't as easy for Linux system administrators. Package management tools built into most distributions help you update servers, but it is not particularly easy to monitor many different mailing lists (or to justify spending all day logged into Slashdot) to find out just what updates are needed.
One option, for Red Hat users, is a subscription to the Red Hat Network. Starting at $96 per server per year, this buys you update notifications that can trigger automatic updates. System administrators can use proxy tools to manage the patches for their servers, as well as managing groups of servers. Other tools allow you to schedule updates to avoid affecting business operations, or to build a workflow to make sure patches are tested before being deployed.
You can use security patches with management tools like IBM's Tivoli, or Computer Associates Unicenter TNG, but this approach requires investment and development. It is a process that will also require locked-down desktop PCs, so you have full control of configurations and can ensure that unintended interactions are kept to a minimum.
Managing security patches is an important part of a business's security policies and procedures. It is also one of the hardest. As patches are system specific, there is no real cross platform standard for describing or deploying them. Until patch management becomes part of standard systems management, keeping systems secure will remain complex, time consuming - and essential.
