Re: Patching and Firmware versions general question
- From: "Sean" <sean@xxxxxxxxxx>
- Date: Thu, 15 Mar 2007 09:54:50 -0000
Wolf.
In response, my mantra has always been.
"If it doesn't add value to the business, don't do it"
However you can only apply this rule once you have successfully identified
the risk to the business (often via Microsoft's advisories as you stated).
Let's take the Slammer Worm as a point of interest, if a network
administrator had 'assessed the risk' and then negated the ability for UDP
packets to be routed to any SQL based server from unknown hosts on the WAN
(or LAN in case anybody plugged a personal computer into the network) this
would have allowed breathing space to manage the risk and plan the patching
in the knowledge that it would not impact on any other systems or end users.
Good process management is key, it's the foundation for a stable and
manageable businesswide solution that is also supportable with minimum
resource.
Here's the crux, good end to end process management can't be taught, and all
too often people are placed in positions of power that have little or no
experience in this field, they have their own agenda, and they want it NOW
(generally reacting to an arbitrary service or function requested by a new
or existing customer). This then imposes a drain on IT resource not allowing
staff to identify risk and manage it as part of there day to day role.
I am lucky enough to work for a company that has a 'buffer' between the
decision makers and the implementers, people who will rationalise the impact
and clarify the value attributed to the business so we can plan change.
I don't live in a rose tinted world thinking this is prevalent everywhere, I
know this doesn't happen, but it should, and everywhere I work I try to
introduce these levels of control because they do work, and the business is
made measurably more profitable by them.
This is easily measured by judging downtime per user based on the impact of
the associated risk, this easily equates to a money value and by managing
the risk you can show the business you have saved them $$$$$$'s or in my
case ££££££'s a year in downtime, this offsets the cost of running your
department and can give you good leverage for a better budget, or more
resource in your department (or not, you could just ask for a big fat bonus
instead for being so good).
;)
Sean
"Thee Chicago Wolf" <.@.> wrote in message
news:s2mgv2p9sigfftm6ggjqqtqh4lod2s12v6@xxxxxxxxxx
I don't agree, in a well managed environment you wouldn't introduce an
element that would alter the balance of your systems. If you have good
change management procedures and plan changes well in advance you can keep
all of your systems at a common level and only patch if the patch is to
fix
an issue you are experiencing or to bring systems in line with the
prerequisites of a new element you are introducing under a managed
process.
Reactive management never works in my experience because the knock-on
issues
it can cause are often worse than the problems you were trying to fix in
the
first place (if indeed you were trying to fix a problem) creating a
greater
drain on resource.
Here's a brilliant response to this school of thought: Count on your
fingers and toes how many institutions and individuals were scrambling
and crying when they just realized in late February that they had to
apply the Time Zone fix to their staff, prod boxes, and other
machines? I know you and everyone in your location don't have enough
hands and toes to count that high. Considering that Microsoft
pro-actively released the OS fix for the issue in November (KB928388),
there's no reason anyone should have been caught by surprise. Sure, a
whopping SIX countries couldn't figure out when to institute their new
DST until 2007 but that was not Microsoft's fault. I don't even count
Exchange in this since it was an ex post facto problem. The rest of us
were fine on March 11th. The same thing can be said about the Slammer
or Beagle worms. I knew far in advance and was protected based on
Microsoft recommendations. Everyone else was getting blasted. Active
or reactive, I usually listen to Microsoft.
Individuals like myself utilize proactive Administration. That
translates to fix it BEFORE it becomes a problem. Just because right
now, THIS SECOND, it is not a problem, doesn't mean it won't be some
time down the road when no one is looking much less remembers that one
patch or update that was released a month / year ago that could have
been installed to fix the problem or vulnerability in advance of its
manifestation.
Reactive Administration is the scrambling lot who are rushing to fix
their servers when something breaks. I don't understand how these
folks can get paid 6 and 7 digit salaries: they are WAY overpaid. I've
been at this 17+ years and know what does and doesn't work, at least
for my environment. There are many schools of thought in IT and
experience, I believe, is the product of the best of them all. Like
the Boy Scout motto: Be Prepared.
Maintenance should be like a car: regular and for the sake of
prevention. Things break down less that way. Just my 2 Yen.
- Thee Chicago Wolf
.
- References:
- Prev by Date: Re: FIXMBR and F6
- Next by Date: Re: How many processor cores will Windows Server 2003 Standard x64 use
- Previous by thread: Re: Patching and Firmware versions general question
- Next by thread: How to Turn up logging for Application and System logs
- Index(es):
Relevant Pages
|
