How to develop a good Windows Patch Update management mechanism?

BKJIA: whenever a new patch is released on Windows, you may want to use it as soon as possible. However, the patches used for updates cannot be automatically provided to users, because no matter whether these patches are used to add new features, correct errors, or fill security vulnerabilities, there is a kind of reality that cannot be avoided, that is, the patch will destroy the application.

For the IT department, a more meaningful approach is to use the Windows Server Update Service to deploy, test, and control updates. The above measures are undoubtedly more responsible and effective than directly allowing users to download and automatically install these patches while facing potential damage risks.

Of course, our ultimate goal is to keep control of the process while letting patches be automatically updated.

Pre-warning

Microsoft's update time is fixed, that is, we often say "patch Tuesday" is the second Tuesday of every month), which means that you can arrange a test plan for it in advance. We can get a notification in advance by subscribing to Security announcements. Such notifications are generally released three working days before the release of updates, and contains the details of the update-the day when the notification is released is often called "threatening Thursday ".

At this time, attackers will also learn the details of the vulnerabilities that have been fixed. Therefore, it is time-consuming for them to immediately start trying to break through the patch protection. Microsoft will occasionally release various important patches outside Tuesday, which often requires immediate attention from the IT department.

If readers and friends are engaged in industries that require strict regulatory rules, or your company is always dealing with a lot of administrative issues, then an appropriate patch update strategy is absolutely necessary.

Protection weaknesses

Microsoft's IT department must ensure that 98% of desktop systems are under the protection of the latest patches. However, this is a requirement for the IT department, not for the product team. Therefore, the company must identify the impact on internal applications before launching the patch.

Updates are not widely used. Therefore, you need to review which systems need to be updated based on specific vulnerabilities.

Not all patches must be installed immediately. New production functions are often included in the function set and service toolkit, rather than the patch, but the patch may improve the execution performance.

In any case, the installation of patches must be evaluated. In addition, if you have to accept a batch of updates every month and restart the system, you must weigh which updates are not urgent, it can be deployed after a longer period of testing, that is, it can be carried out together with the next batch of updates), and which of the following can greatly promote production, so it should be installed as soon as possible.

Anti-Virus Software Updates do not need to be tested and approved, because enterprise-level anti-virus software systems are updated three times a day by default.

Specialized enterprise-level anti-virus software systems automatically process updates. If you are managing the Forefront terminal protection system through the System Center Configuration Manager, version 2012 of this manager provides the following features: this enables automatic approval of updates only when a specific definition language is selected.

Race time

In a few cases, Microsoft believes that some patches play a major role and need to be launched as soon as possible because they can solve serious problems. However, even if no review time is reserved for it, you still need to evaluate it in advance.

Microsoft's security bulletins and third-party services will occasionally release updates to users for such patches, and you may find that third-party vendors have great reference value for such key patch suggestions ).

Despite the importance of deploying emergency patches, developing a set of assessment strategies should undoubtedly give priority to them. You may want to immediately update the emergency patch, but you must first understand whether this will disrupt our regular business applications. The best advice is to keep the software audited in real time so that we can clearly see which systems will be affected.

Test, test, or test

There are several ways to test the patch. You can use a testing system with scripts to cover systems and applications or adopt more informal methods such as releasing a patch collection to users. If the department to be tested happens to be the IT department, make sure that they make sure that the production application and scripts work well in the process of performing common tasks together.

Large enterprises may want to deploy the service separately to avoid increasing the network load. If this update does cause damage, the deployment can also reduce the pressure on the Technical Support Team.

We need to track the updates that have been successfully installed. Even small enterprises need a change management system to record patch content and updates.

Like Microsoft applications, we will also need to develop a set of patch update policies for third-party applications and network devices. Third-party tools such as App Titude of App-DNA and AOK of ChangeBase can help us track the status of multiple products at the same time and provide a detailed guide, tell everyone which applications will be affected by Microsoft updates.

The tools mentioned above cannot relieve the monthly update burden, but with their help, we do not have to try to solve the problem from the beginning at least once.

Original article: http://www.theregister.co.uk/2011/05/30/windows_patch_management/