Unfortunately, no code that is millions of lines long is perfect, and security holes will always exist. One of the best ways to protect yourself is to make sure your system has the most recent patch levels installed.

Unfortunately, no code that is millions of lines long is perfect, and security holes will always exist. One of the best ways to protect yourself is to make sure your system has the most recent patch levels installed. Rarely does a virus or worm attack a brand new vulnerability; rather, they attack known vulnerabilities for which patches exist. Typically, people who discover vulnerabilities will report them to Microsoft, and a patch is created and released along with the announcement of the vulnerability.

Administering the Patching Process

When you are administering a production environment with business-critical functions, it’s extremely important that you use a controlled process to manage your patching. Here are some ideas to get you started on a patching procedure.

Implement Change Control

First and foremost, you should implement a change control process for your system. A change control process has
• Defined owners for the system, patch, and any applications
• Communication to all parties involved in the patch
• A waiting period, so that the interested and affected parties can raise objections or questions; it’s often a good idea to get approval from each of the owners before applying a patch
• An audit trail and back-out plan
• A scheduled time for installation and a defined outage window

Be Consistent

When applying patches, make sure the same patch level is applied to each server-unless you have a good reason not to do this. Consistent installation is especially true for domain controllers, since out-of-sync patches could mess with replication or authentication between DCs.

Read the Documentation Always

Completely read the documentation for a patch before you install it, so you can understand thoroughly what’s involved. That way, you can determine whether applying the patch is going to disable some needed functionality or cause issues with a certain piece of hardware or software on your system. Reading the documentation will also educate you on which patches are necessary and which ones are not critical.

Test It Out

It is a good idea to have a test lab in your organization that tests any new patches before they’re installed systemwide. When you are completely satisfied that the patch performs appropriately and have appropriate sign-off from everyone involved, target noncritical systems first for patching. If you are not comfortable patching, don’t do it, especially if the patch is a feature enhancement rather than a security patch.

Be Able to Uninstall the Patch

If you can, install patches so that you can uninstall them if you need to later on. That way, you can back out of a patch if it causes problems on your system. You can usually find switches that allow for this. Also, keep a backup of the system state data on hand, plus a full backup of the system, just in case.

Make Sure the Patch Is Relevant

Always make sure that you can or should apply a patch to a system. Applying a WS03 Post SP1 patch before applying SP1 probably isn’t a great idea. Also, keep in mind that you may not need to apply client patches, such as Internet Explorer patches, to a server, since Internet Explorer won’t be used on the server. In addition, applying a whole service pack is usually better than applying lots of individual patches within the service pack.

Spec-India is Custom Application Development Company that Offers Cost Effective Software Development, Mobile Software Application Development, Custom Software Development, ASP.Net Development, Legacy System Migration, Onsite Software Development and Application Support and Maintenance. Visit http://www.spec-india.com/ to learn more.