Re: Microsoft's Early Xmas Present.

[Valdis.Kletnieks () vt edu]

On Thu, 03 Jan 2002 08:59:03 PST, H C <keydet89 () yahoo com>  said:

> management and administrative nightmare, but I am also
> quite sick of hearing the excuse that organizations
> aren't subscribing to the Security Bulletins b/c there
> are just too many to deal with.  It doesn't take much
> more than a few seconds to see if the issue affects
> you at all...if you use Eudora, then an OutLook
> vulnerability won't be an issue, will it?

windowsupdate.microsoft.com got hit with CodeRed because the original
Microsoft advisory stated that the vulnerability only affected certain
configurations (if you were using the Index Server).  The
windowsupdate server didn't use that feature, so the patch wasn't
installed.  Too bad that the vulnerability was more widespread than
the advisory originally stated.

More than a few people didn't install IIS patches because the vulnerability
list said "Windows .. Server", but their 'Windows Professional' system was
also vulnerable because when they upgraded, IIS was installed because they
had the old Personal Web Server software installed.

I may be mis-remembering the details, but I believe there was at least
one "Outlook" vulnerability that was actually an IE issue, and *did*
also affect those Eudora users who had configured a "use IE to display
text/html" option.

And in some cases, it *can* be "more than a few seconds to see". I've
seen more than a few times when a vulnerability against a Linux
program has come out, and some major detective work was required to
figure out if RedHat had already incorporated the change.  If the
vulnerability was created in frobozz-1.4.3, and fixed in
frobozz-1.4.5, and RedHat is shipping a frobozz-1.4.2 that
incorporates various upstream patches from 1.4.3 through 1.4.6, are
you vulnerable or not?

Once you have a handle on what systems are *REALLY* affected, then you
get to figure out how to deploy the patch.  If you're a large site that
has several hundred mission-critical servers, or have several thousand
desktops to upgrade, this can be a long, involved, and scary business.

And if a *second* critical patch comes out during the 2 weeks it takes
to download, integrate, test, and deploy the patch on your 300 critical
servers, you *really* have a problem.  Do you go back to square one, and
integrate/test the combo of patches (thus leaving some systems unpatched
for the FIRST hole for another week or so), or do you delay deployment of
the second patch for another week?

How does your answer change if you worry about the patch itself being
bad (which has happend), or a *third* critical patch coming out (which
has happened)?

When your machine room is over a quarter of an acre in size, everything
is a lot more complicated (and yes, our machine room is 0.29 acres ;)

-- 
                                Valdis Kletnieks
                                Operating Systems Analyst
                                Virginia Tech

Attachment: _bin
Description: