Re: Testing MS Security Patches?

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.
.

Relevant Pages