Re: Testing MS Security Patches?
- From: "Roger Abell [MVP]" <mvpNoSpam@xxxxxxx>
- Date: Mon, 30 Jan 2006 08:14:37 -0700
On the contrary, MS has issued very much info on the topic
http://search.microsoft.com/results.aspx?mkt=en-US&setlang=en-US&q=patch+management
We were just trying to give the essentials.
"y2kbug_s97" <y2kbugs97@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:236F2A1A-DD4B-4152-A2E6-C9CF9EA48508@xxxxxxxxxxxxxxxx
> Thank you all for posting your comments. I can tell from your comments
> that
> Microsoft probably does not publish general guidlines for testing patches
> but
> your comments will help me mold a solid plan in our specific environment.
>
> Thanks again...
>
> "Alun Jones" wrote:
>
>> In article <178C0A5D-51D0-46C6-8243-C3193B0C4871@xxxxxxxxxxxxx>,
>> "=?Utf-8?B?eTJrYnVnX3M5Nw==?=" <y2kbugs97@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> wrote:
>> >Does anyone know of specific tests that should be performed before
>> >implementing MS security updates on production systems.
>>
>> There are no general recommendations to suggest here, because your goal
>> should
>> be to test those applications on which your business depends. If your
>> business uses the same applications that everyone else uses, then it's
>> entirely likely that they've already been tested by Microsoft. If your
>> business uses different applications from others, then those are the
>> applications you need to test.
>>
>> >I am a member of a large organization and we are trying to enhance our
>> >testing procedures before implementing MS security patches through out
>> >our
>> >production environments.
>>
>> There's nothing specific about these being security patches - they are
>> changes
>> you are making to the system, and you need to ensure that they don't
>> impact
>> the rest of the business' operations in a way that will cause more damage
>> than
>> the problem that they are aimed at fixing.
>>
>> >Is there a document that shows what specific things should be
>> >considered?
>>
>> You need to analyse your LOB (line-of-business) applications, and that's
>> really something that you need to establish for yourself. Establish a
>> set of
>> functions that are required for most of your operations, and a means to
>> test
>> that they happen correctly.
>>
>> Then use that sequence on every change you make, and add to it any
>> operations
>> that appear to be related to the parts of the system that have changed.
>>
>> >I'm looking for a guideline that displays how to validate that a
>> >security
>> >patch released by MS will not break any applications or the Operating
>> >System.
>>
>> I'd say it's a fairly good bet that Microsoft has already done more
>> testing
>> than you'll be able to in regards to making it not break the OS, so you
>> should
>> concentrate on those applications that are required for your business'
>> continued operations.
>>
>> But, there are a few things you should consider:
>>
>> 1. Download the patch.
>>
>> 2. Test the install on a lab machine / machines that represent the
>> majority of
>> your users.
>>
>> 3. Test the uninstall - when you roll out the patch to users, if it kills
>> their systems, you need to know that the uninstall is going to work.
>>
>> 4. Test the installed patch in your lab against some sample use cases.
>> Engage
>> in a feedback loop with your users to discover the important use cases -
>> remind them that if they experienced significant problems with a previous
>> patch, that was because you didn't test what they need to do against the
>> patch
>> in the lab. If that was because they didn't tell you what they need to
>> do,
>> then they need to be more detailed next time.
>>
>> 5. Determine who your rollout will start with - pick a group of users
>> that
>> will be first-adopters for the next patch. There are different theories
>> on
>> this - you can find people who are advanced users, so they can cope with
>> instructions to resolve issues; you can pick people at random, to make a
>> good
>> statistical selection; you can pick people that you know are trouble to
>> any
>> piece of software they encounter; you can pick people that you like, you
>> can
>> pick people that you hate. Okay, that's a piece of humour, I don't
>> suggest
>> that you do exactly that - but pick a strategy, or a set of strategies.
>> I
>> suggest informing the test group that they are to be used as a test case
>> for a
>> new update that's rolling through, and that you need them to let you know
>> anything that's changed.
>>
>> 6. Review the success of the initial rollout in meetings with
>> stakeholders in
>> those departments, and then roll out to the rest of the company if the
>> result
>> is good - or if the anticipated result of not rolling it out is worse.
>>
>> Alun.
>> ~~~~
>>
>> [Please don't email posters, if a Usenet response is appropriate.]
>> --
>> Texas Imperial Software | Find us at http://www.wftpd.com or email
>> 23921 57th Ave SE | alun@xxxxxxxxxx
>> Washington WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
>> Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.
>>
.
- Follow-Ups:
- Re: Testing MS Security Patches?
- From: y2kbug_s97
- Re: Testing MS Security Patches?
- References:
- Re: Testing MS Security Patches?
- From: Alun Jones
- Re: Testing MS Security Patches?
- From: y2kbug_s97
- Re: Testing MS Security Patches?
- Prev by Date: Re: NTFS Permissions
- Next by Date: Re: Testing MS Security Patches?
- Previous by thread: Re: Testing MS Security Patches?
- Next by thread: Re: Testing MS Security Patches?
- Index(es):
Relevant Pages
|
