Re: patch management policy/practice

From: Activated (activated@attbi.com)
Date: 03/12/03 

From: "Activated" <activated@attbi.com>
Date: Tue, 11 Mar 2003 15:02:56 -0800

I can't resist saying a little about this large question.

The real issue regarding patches and service packs and Microsoft is that it
is barely manageable. The frequency of updates that are said to be
"critical", and the complexity of applying the updates have led most larger
companies with a very large headache. Microsoft is not to blame for hackers
and the ante that is raised by them, but it IS responsible for the
architecture for applying changes, and the relative weakness the software
has shown over time to have in regard to the "holes" discovered. Since the
software is mission critical, and really, since Microsoft is a major game in
regard to infrastructure, we customers are wholly dependent on, and need
Microsoft to "fix" the mess. It may not be easy to fix, it may require a
massive rearchitecting of the products, but at present, and in reality, the
cycle of hole-hack-discovery-fix-patch creation/posting-updating is the
single most taxing byproduct of buying and using Microsoft products.
Microsoft makes it worse also by allowing marketing to make make name
changes too often, and to bring even more confusion to the product trees
which are dynamically in flux in regard to patches and updates.

To be fair, all products are undergoing this kind of flux, but Microsoft
with its breadth of product, and the problems noted regarding dates, and
packages and application of them, brings a very difficult situation to
corporations, and even worse for the casual home users, and small home
offices. Really, the SoHo are on their own by and large. A cottage
industry has sprouted around them, but most often they are running with old
software, non-patched, and open to all levels of risk and destruction.

If you want an answer to how often? It is not dictated by the size of your
company, it is dictated by your willingness, ability, and internal resources
to keep up with the updates. It is dicated, today, by your ability to take
critical servers offline regularly, and to accept that most of your clients
are going to go unpatched for long periods, and with risk. Most often,
unless you have a ton of extra money for an IT org to have enough techs to
chase the clients down, you will wait for new product releases, and hope
Microsoft will include patches to the date of purchase that cover the
"holes" discovered prior to the new product release itself. Then you will
immediately begin to degrade in regard to clients and patches.

"Karl Levinson [x y] mvp" <levinson_k@excite.com> wrote in message
news:OxXlzfB6CHA.2052@TK2MSFTNGP11.phx.gbl...
>
> "Doug Fox" <dfox168@hotmail.com> wrote in message
> news:OoPMXOB6CHA.1808@TK2MSFTNGP12.phx.gbl...
> > It may be OT questions, but they are relevant! I will compile a list of
> all
> > responses.
> >
> > How soon do you apply patches to your "critical" servers? Within a week?
> > two weeks? a month? or upcoming mainteance window, which could be 3
months
> > down the road? (assuming testing has been done.)
>
> Depends on a lot of different things and varies from computer to computer
or
> from company to company. It's up to you and your need for security and
the
> risk of the exploit being used on that machine. For example, installing
> non-critical patches might be delayed for internal machines where maximum
> uptime and reliability is essential. It's also sometimes good in some
cases
> to wait and see if other people report problems with a patch, though with
> some very public critical patches, you may not want to wait.
>
> Remember that the goal of security is generally not to make your server
> impenetrable, but to try to save money and maximize availability of
> resources where ever it is sensible to do so. It could be that certain
> safeguards are more "costly" than the threats they are trying to reduce,
in
> which case you might choose to accept the risk of that threat instead of
> trying to reduce it.
>
> > If you do not feel comfortable applying the patches for whatever
reasons,
> > but security insists. How would you handle the situation?
>
> I suppose do testing or document and provide the reasons for your concerns
> to your security group and management. That patch is probably going to
get
> on your system sooner or later, when the next service pack or
comprehensive
> rollup whatever is released.
>
>

Relevant Pages

  • Re: How to Maintain an IIS Server?
    ... >>> I looked at the Microsoft Security Website. ... >> before a firewall and antivirus have been installed]. ... >> new patches that are missing, ...
    (microsoft.public.inetserver.iis.security)
  • Re: How to Maintain an IIS Server?
    ... > [for MS MBSA Baseline Security Analyzer] ... Get a firewall or two as well, ... >>> new patches that are missing, ... >>> software installed on your computer, especially Microsoft Windows, ...
    (microsoft.public.inetserver.iis.security)
  • Re: Ithis microsoft security site?
    ... patches or any type of updates attached to email. ... http://microsoft.com/technet/security is authoritative for all security ... >> Microsoft Corporation Network Technical Services ... Install now to protect your computer ...
    (microsoft.public.security)
  • Re: A 6% fix from Microsoft Security Bulletin MS03-040 - 828750
    ... What I meant by "post" was to the Microsoft security pages. ... > exploiters - as was the case with the RPC hole. ... > are known and the risk of exploit becomes high or manifest. ...
    (microsoft.public.security)
  • Re: A 6% fix from Microsoft Security Bulletin MS03-040 - 828750
    ... What I meant by "post" was to the Microsoft security pages. ... > exploiters - as was the case with the RPC hole. ... > are known and the risk of exploit becomes high or manifest. ...
    (microsoft.public.security.virus)