'Patchwork' security is right for you
The secret? Install security patches as they're released.
Okay, maybe that's not such a secret. After all, that's why vendors write patches. But for a variety of reasons, many organizations ignore security fixes until intruders take highly publicized advantage of the holes the patches are meant to correct.
SOME ORGANIZATIONS NEGLECT patching their software, simply because they never hear that a patch has been released. How can you avoid this pitfall? The best way I know to stay on top of security holes is to become a regular visitor to SecurityFocus.com. Check daily for new security advisories. Sign up for the appropriate Bugtraq mailing list.
And if you don't have time to monitor the information yourself, assign it to someone else on your staff.
Some organizations steer clear of patches for a different reason. Every time you change code on a production machine, you risk corrupting something new that the patch's authors missed when correcting the flaw. It's a troublesome problem, because, as Clarence Carter sang more than 30 years ago, we depend on patches. Only you can decide which threat is more dangerous--leaving a known hole open, or risking the stability of a server.
TO MINIMIZE THE RISK inherent in applying new patches, I suggest a phased deployment. First patch a test server--ideally one that runs a selection of typical applications on your network, or better yet, one that mirrors a critical production server. Then let it run for a day or more.
If nothing bad happens, roll out the patch to a machine that serves a small group of users--ideally, a group not working on mission-critical applications, and one that understands and accepts the need for guinea pigs.
Finally, if all is well, you can deploy the patch to the rest of the network.
Sometimes, all isn't well. I should hardly have to say it, but you'd be surprised at the foolish things people do in the interest of saving time. So be sure you have a complete backup of your system to recover from, in case a patch is faulty!
ONE OTHER ACTION to undertake with a clear view: changing platforms. Yes, some vendors are more noted than others for writing software whose security resembles Swiss cheese, and some have better reputations. Even so, it's not realistic to use that fact as an excuse to change platforms and as part of an attempt to avoid having to deal with patches.
The hard fact is, for better or worse, a given platform usually hosts a raft of critical applications that won't run on a more secure operating system. Usually, the utility of the applications outweighs the need for airtight security. The time to decide whether features or security take precedence is before developing or purchasing new software.
Given all that, isn't the end conclusion obvious? Take a patchwork approach to your security needs to help keep your company's network safe.
How do you make sure your patches are up to date? TalkBack to me.