patch management policy/practice - a summary of responses till 12:45 am (EST)
From: Doug Fox (dfox168@hotmail.com)
Date: 03/12/03
- Next message: Tim Border: "SrvsvcDefaultShareInfo"
- Previous message: Doug Fox: "Re: dumpel"
- In reply to: Doug Fox: "patch management policy/practice"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Doug Fox" <dfox168@hotmail.com> Date: Wed, 12 Mar 2003 12:42:22 -0500
It may be OT questions, but they are relevant! I will compile a list of all
responses.
Q1: 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.)
Q1R1: 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.
Q1R2: The SANS emails indicate that their "big firms" have a quarterly patch
schedule unless the patch is of such critical nature that they cannot wait.
They test in a test environment before rolling out.
I'm a little firm. I'm a "canary". I patch using hfnetchkPro as my patch
management tool every Friday if a patch comes out. Why? I'm a wacko person
that takes the responsibility of breaking things around here. I have no
test server. I am my test server.
So ... I patch... I make sure that I archive the patches.... I figure out
what broke and fix it.
Thus far this year there has only been 6 [it's sort of like those horror
movies....it's too quiet you know]
Q1R3: I have scheduled service windows on the servers that are quarterly. I
don't always use them, more often I install patches and reboot only twice a
year.
Q1R4: Balance of :
1. Severity of the patched issue - a combo of simplicity of the exploit and
extent of exploit's impact
2. Exposure of machine to the risk (assessed per machine)
3. Role of the machine - that is, pain if the exploit is used as compared
with necessity that it be up for max 9s I tend to have a low pain threshold
:-)
Q1R5: When appropriate. Depends on need.
Q2: If you do not feel comfortable applying the patches for whatever
reasons, but security insists. How would you handle the situation?
Q2R1: 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.
Q2R2: I *am* security. :)
Look, if you're not comfortable but some authority insists you do something,
you really have three choices. Protest to a higher authority, acceed to
their request or quit.
And every patch is unique. So there's no rule that "All patches will be
applied seven days, four hours and nineteen minutes from the moment they are
released." Any admin that has a rule for when patches are applied isn't
paying enough attention.
For example, W2K SP3. It's applied to all workstations, and once we tested
it we rolled it out within a week. It's applied to most servers, but while
some were applied within a week or two, others were applied during other
upgrades and patch cycles or other maintenance. The external web servers
still do not run SP3.
Tools:
Get on a NT platform....
St Bernards Update Expert
Shavliks hfnetchk pro
or be brave and 2K/XP with Auto updates
A conversation between two posters:
Poster 1:
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 re-architecting 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 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.
Poster 2:
I tend to disagree. Installing patches is certainly a headache. But as the
other poster mentioned, there have been 6 patches released this year. If
your company and home were running Linux on their workstations, it would be
at least 6 if not more... and the problem gets worse if you allow your
corporate users to run RedHat 8.0 and 7.3 and 7.2 and SuSE and Debian etc.
etc.
There are a variety of ways to get updates easily, from visiting
www.windowsupdate.com once a week to SUS update services and other similar
Microsoft update services built into Windows XP etc., free HFNETCHK to
confirm that updates are installed, etc. We've had success rolling out
patches also via the login script and the AT command as well. It seems to
me that the larger problem is that too many people don't even bother to lift
a finger to pursue getting free updates, installing free antivirus, the
basic things you know you need to spend a few minutes doing to keep secure.
[And also too many companies and government entities etc. that don't have a
clear policy mandating when and how patches are installed.] Installing
www.grisoft.com antivirus or any of the free firewalls out there is a snap,
but still so many people don't do it. IMHO, no matter how easy you make
this stuff, people won't do it.
Poster 3
>The real issue regarding patches and service packs and Microsoft is that it
>is barely manageable.
Patching and updating have never been manageable on any OS, and likely never
will truly be.
>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.
Maybe, but not as much as people seem to whine about. There have really
only been a few critical updates, and Microsoft's severity rating of
critical may not mean it's critical for your organization or that particular
server. Each system has it's own risks of exposure, so ciritcal to one may
mean "immediate" where to another it means "kinda important".
> 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.
It definitely is architecture, and unfortunately there isn't any real way to
fix it until the next release of Windows. Not Windows Server 2003, but the
*next* release in three to five years. The development of that platform is
starting now, and you can bet Microsoft is working heavily toward
redesigning the core architecture to reduce the headaches of patching and
patch management.
Until then, we buy asprin in the jumbo size bottles... :)
"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.)
>
> If you do not feel comfortable applying the patches for whatever reasons,
> but security insists. How would you handle the situation?
>
> Any comments/suggestions/info are greatly appreciated.
>
> Thanks,
>
>
- Next message: Tim Border: "SrvsvcDefaultShareInfo"
- Previous message: Doug Fox: "Re: dumpel"
- In reply to: Doug Fox: "patch management policy/practice"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
