Securing servers

Editor's Note: This is the first of our new Server Sleuth columns. Each week, the Sleuths will help you crack your tough server-management questions - which you can send them at sleuths@nwfusion.com. See the Server Sleuths bio page for more on our crack detectives.

Q. Securing our servers is our IT organization's biggest concern. With new regulations concerning the protection of data and new viruses popping up almost daily, what can I do to ensure that our servers are up-to-date with the latest patches and service packs? 

Also, can you address the speed vs. security question? Meaning, once I get a patch, to ensure it does not bring down the network, I have to check it to make sure there are no conflicts. If there are, I have to manually make changes to the patch, which drastically increases the amount of time it takes to deploy the individual patch; sometimes by as much as a month. Is there anything I can do to speed up the process to ensure my network is as safe as possible?

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Editor's Note: This is the first of our new Server Sleuth columns. Each week, the Sleuths will help you crack your tough server-management questions - which you can send them at sleuths@nwfusion.com. See the Server Sleuths bio page for more on our crack detectives.

Q. Securing our servers is our IT organization's biggest concern. With new regulations concerning the protection of data and new viruses popping up almost daily, what can I do to ensure that our servers are up-to-date with the latest patches and service packs? 

Also, can you address the speed vs. security question? Meaning, once I get a patch, to ensure it does not bring down the network, I have to check it to make sure there are no conflicts. If there are, I have to manually make changes to the patch, which drastically increases the amount of time it takes to deploy the individual patch; sometimes by as much as a month. Is there anything I can do to speed up the process to ensure my network is as safe as possible?

I've worked with teams who told me that before they solved it, patch management was a "can't see the forest for the trees" problem.  They spent time and energy tackling each patch or update as a single event, working on a single layer of the configuration, like a single tree.  The problem is that sometimes their solutions affected other aspects of their networking "forest." One tree leans a bit, and others can fall.  Without accounting for the entire environment, patch management can result in instability as patches and updates impact other elements and create disruptions.

The whole software stack must work together, and continue to do so even after reprovisioning or changes.  So patching one aspect of one layer at a time is slow and risky, and frankly not working in the real world. I believe that automation is key to risk avoidance as well as speed.

The fundamental idea is that you need to manage patches holistically.  In other words, you need to look at the full configuration, the entire stack - operating system, applications, content, settings, etc.- to do patch management effectively (getting the right patch to the right system), efficiently (quickly), and risk-free (no disruptions because of unforeseen conflicts when patches and updates are applied across the whole environment).

A comprehensive configuration database - one that has all of the configuration information, across the entire software stack - can provide visibility. This enables a thorough analysis of the potential impact of any change in advance of the change.  By identifying problems before they occur, you can focus your time just on the patches and areas that need adjustment up front.  You'll avoid the domino-effect of problems across your environment that disrupt service and take enormous IT time and resources to solve. 

The potential impact of any change is not just technical, of course. Also vital is looking at the impact of any changes on your business logic. A policy-based patch management solution can help manage risk in this way.  For example, if you know that any customer-facing systems must remain stable, then you can establish policies to analyze changes and introduce them in the corporate intranet before the extranet.