RE: Installing patch KB837001 via Windows Update

["Rod Trent" <[EMAIL PROTECTED]>]

We're completely off-topic now.  Best to get back to patch management
discussions. 

Suffice to say that all OS's need to be patched.  No matter what OS you
choose to use, patching still needs to be part of your overall security
strategy.  When you have diverse environments (i.e., multiple OS's
deployed), patching complexity increases and more resources are required to
manage security in the environment.

-----Original Message-----
From: George Capehart [mailto:[EMAIL PROTECTED] 
Sent: Saturday, April 17, 2004 1:41 PM
To: Patch Management Mailing List
Subject: Re: Installing patch KB837001 via Windows Update

On Thursday 15 April 2004 10:59 pm, Susan Bradley, CPA aka Ebitz - SBS Rocks
[MVP] wrote:
> Okay it's the end of the day and I gotta rant.  We keep talking about 
> how Microsoft should regression test these patches and yet look what 
> we are asking them to do.
>

<snip>

>
> Yes, I want them to build better patches, but I'd rather they'd build 
> patches in a way that I can get back to where I was before the patch 
> went on as well.

<rant>
OK.  *My* turn to rant.  There are other OSs in which this is not a problem.
Matter of fact, MS operating systems are the only ones I've used that have
this problem, and I've used most of the Unices, DOS (both PC and mainframe),
MVS, VMS, MPE, RSTS, CP/M, etc., etc. 

> The reality is they cannot patch for all the "junk"
> that I have on my box.

That's not the problem.  The problem is that they have thrown everything and
the kitchen sink in the OS and it's nigh on impossible to tell where the OS
stops and the applications begin any more.  This was done on purpose.  It is
just the opposite strategy of the Unix world in which the idea is to build
many single-purpose tools that can be used in concert to perform complex
tasks.  (I am not intending to start yet another MS vs. *nix food fight.  I
am merely describing differences in design philosophy and some of the
implications of those differences).  
In the *nix world, there is a clear distinction between the kernel which
manages system resources and all of the userland applications and subsystems
that use those resources.  The kernel and all of the userland applications
and subsystems have their own lifecycles, can be managed independently, and
can be patched (*and rolled back*) independently.  There is lots of "junk"
on most production machines.  
It is the phenomenal complexity and multiple levels of interfaces, levels of
indirection and opaqueness that makes patching *dows such a challenge.
Frankly, I'm amazed that they're able to do as well as they do.

>  And that's the reality of Patch Managment.  I have to take the risk.  
> I have to make the decision.  In my office I'm taking the chance that 
> my ports are pretty nice and tight and nothing [while exploit code is 
> out] is in worm mode and I'm coming in to the office tomorrow when 
> everyone else is making a nice three day weekend out of it and 
> patching my LAN and cleaning my office.  [Do I know how to party or 
> what?]
>
> The point is no vendor can patch test for the environments we have.

In almost all non-MS environments, that's not necessary.  There is a clear
distinction between the OS, OS utilites and applications.  The APIs are well
known and dependencies among the subsystems are known.  
The OS vendor doesn't have to test everything and the kitchen sink.  
That is not to say that there are not dependencies among subystems and
applications.  The difference is that the interfaces and their behavior is
well known.  There are no silent "enhancements" or "bug fixes" that change
their structure or behavior.  And it is possible for the administrators to
decide how they want to partition their system, where to put the utilties,
applications and data.  Configuration data are well documented and not
buried in a "registry."  If, after an update, it is necessary to have an
application reread some initializing information, it is not necessary to
reboot the operating system.  It is sufficient to restart the application.
And the operating system can be reconfigured on the fly.  Most of the
problems with patching MS systems are caused by the design of the "operating
system," and I use that term loosely.  I can think of no reason beyond
avarice that would justify having a browser be a part of an operating
system.
</rant>

Cheers,

George Capehart
--
George W. Capehart

Key fingerprint:  3145 104D 9579 26DA DBC7  CDD0 9AE1 8C9C DD70 34EA

"Does getiud(2) halt the spawning of child processes?"
  -- Unknown from a very old fortune cookie file



---
To unsubscribe send a blank email to
[EMAIL PROTECTED]



---
To unsubscribe send a blank email to [EMAIL PROTECTED]