How best to handle Microsoft re-release of security patches
From time to time, some security patches need adjustments to correct issues that have been discovered. Microsoft attempts to resolve this by releasing a new version of an existing patch or by releasing a new patch the replaces a previous patch.
To date, I have encountered 4 different ways that a re-release patch can show up in the DSUW.
1. Direct replacement.
What this means is that the re-release patch appears in the DSUW as the same patch number of the original patch. So the scan tool has the new criteria for the patch but the patch package does not. What kind of impact can this have? Your systems will continue to try to install the patch, even if it is the old one installed. In some cases you may see or hear about systems continually applying patches. The best method of managing this is to de-authorize the patch in the package and test the new patch and implement according to the patching guidelines established by your organization. Unfortunately, I can not recall the last time and exact patch that I have seen this, but it wasn’t that log ago.
2. New version of an existing patch and this patch overwrites the original one.
What this means that the scan tool is aware of the new patch, but the patch package is not. There would be no impact on your systems when the scan tool is updated. You would need to authorize this and test the new patch and implement according to the patching guidelines established by your organization. Unfortunately, I can not recall the last time and exact patch that I have seen this, but this too wasn’t that log ago.
3. New patch that requires the old patch to be uninstalled.
What this means is that efforts outside of the DSUW patching process have to be performed to uninstall the original patch, thus allowing patching to occur via the normal patching process. There is no direct impact to the systems when the scan tool is updated. You would need to authorize this and test the new patch and implement according to the patching guidelines established by your organization. Patch MS06-025 would be an example of this.
4. Patch to a patch or a hotfix to an existing patch.
What this means that a fix is needed to correct an existing patch. This will usually require actions outside of the DSUW. There is no direct impact to the systems when the scan tool is updated. You would need to authorize this and test the new patch and implement according to the patching guidelines established by your organization. Patch MS06-015 & MS06-042 (hotfix released prior to the re-release) would be examples of this.
One of the best things that can be done to control the possible impact of these re-release patches is to control how often the scan tool checks in for updates. As some of you may have noticed, the wsusscan.cab is updated between patching cycles. Usually these updates are to correct something within the cab, like a misspelling of words or a clarification of statement made in the patch description. Often these updates go without notice or warning.
The next thing that can be done is to monitor your patch compliance. If compliance numbers go down or there is a second listing of a patch (for the same OS) that wasn’t there before, or you notice that a patch that has been authorized in your patch package, but your compliance number are not going up. Then you may have a re-release patch on your hands.
To date, I have encountered 4 different ways that a re-release patch can show up in the DSUW.
1. Direct replacement.
What this means is that the re-release patch appears in the DSUW as the same patch number of the original patch. So the scan tool has the new criteria for the patch but the patch package does not. What kind of impact can this have? Your systems will continue to try to install the patch, even if it is the old one installed. In some cases you may see or hear about systems continually applying patches. The best method of managing this is to de-authorize the patch in the package and test the new patch and implement according to the patching guidelines established by your organization. Unfortunately, I can not recall the last time and exact patch that I have seen this, but it wasn’t that log ago.
2. New version of an existing patch and this patch overwrites the original one.
What this means that the scan tool is aware of the new patch, but the patch package is not. There would be no impact on your systems when the scan tool is updated. You would need to authorize this and test the new patch and implement according to the patching guidelines established by your organization. Unfortunately, I can not recall the last time and exact patch that I have seen this, but this too wasn’t that log ago.
3. New patch that requires the old patch to be uninstalled.
What this means is that efforts outside of the DSUW patching process have to be performed to uninstall the original patch, thus allowing patching to occur via the normal patching process. There is no direct impact to the systems when the scan tool is updated. You would need to authorize this and test the new patch and implement according to the patching guidelines established by your organization. Patch MS06-025 would be an example of this.
4. Patch to a patch or a hotfix to an existing patch.
What this means that a fix is needed to correct an existing patch. This will usually require actions outside of the DSUW. There is no direct impact to the systems when the scan tool is updated. You would need to authorize this and test the new patch and implement according to the patching guidelines established by your organization. Patch MS06-015 & MS06-042 (hotfix released prior to the re-release) would be examples of this.
One of the best things that can be done to control the possible impact of these re-release patches is to control how often the scan tool checks in for updates. As some of you may have noticed, the wsusscan.cab is updated between patching cycles. Usually these updates are to correct something within the cab, like a misspelling of words or a clarification of statement made in the patch description. Often these updates go without notice or warning.
The next thing that can be done is to monitor your patch compliance. If compliance numbers go down or there is a second listing of a patch (for the same OS) that wasn’t there before, or you notice that a patch that has been authorized in your patch package, but your compliance number are not going up. Then you may have a re-release patch on your hands.
posted by Anonymous at 3:26 PM
0 Comments:
Post a Comment
<< Home