Message-ID: <15533237421C6E4296CC33A2090B224A11C03B@UTDEVS02.campus.ad.utdallas.edu>
From: pauls at utdallas.edu (Schmehl, Paul L)
Subject: When should you patch?  Was: No Subject (re: openssh exploit code?)

> -----Original Message-----
> From: Montana Tenor [mailto:montanatenor@...oo.com] 
> Sent: Tuesday, October 21, 2003 3:05 PM
> To: Schmehl, Paul L
> Cc: mitch_hurrison@...lip.com; full-disclosure@...ts.netsys.com
> Subject: RE: [Full-Disclosure] No Subject (re: openssh exploit code?)
> 
> I agree with Mitch.  Lets say you get an advisory that
> a severe thunderstorm may be coming your way.  Do you
> wait until the wind and rain are blowing inside your
> house to close the windows and doors.  Do you allow
> the kids to keep playing outside?

That depends entirely on the nature of the notification.  If the
thunderstorm is 60 miles west of me and traveling at 20 miles per hour,
I've got three hours to prepare.  And during that time it could change
course and miss me entirely.  Those are all details that I need to know
to make the right decisions.

If I make my kids come inside and stop playing every time there's a
warning, they will soon learn that I "lie" (because the storm doesn't
come every time) and begin to ignore me.  And that can be fatal for
them.  Lest you think I'm trivializing, this is a huge issue with
management.  If you want them to pull the plug when something really
serious is about to happen, you'd better not be telling them to pull the
plug every time a warning is sounded.  There are various levels of
seriousness, and you'd better learn how to deal with them appropriately
or you won't be employed for long.

>  You do the prudent
> thing.  Instead of trying to brute-force Mitch into
> this, think about why doing the right thing to protect
> the long term interests of your business is the RIGHT
> thing to do.
>
I'm not trying to brute-force Mitch into anything.  I'm trying to get
him (and you and others) to see that there is more than one facet to
this gem.  Mitch complains about his worth not being recognized (at
least I think that's what he's saying.  Hopefully he'll respond to my
request for more information.)  Well admins feel the same way.  They
read in the lists that if they don't patch right now they are
incompetent and should be fired immediately.  That they should take
every vulnerability as a life and death issue and patch now, the
business needs be damned.  But admins don't life in that fantasy world.
They live in the real world, where *many* things have to be weighed and
considered carefully before taking any major action that disrupts the
business.  (And I'm not an admin, so this is not my personal gripe, OK
Ron? ) :-)
 
> The problem is solved by a refusing to allow a
> superior, most likely one ignorant to security
> concerns, to make the ultimate decision about security
> issues.  Come on, thats why he/she hired you in the
> first place.

In most cases, that is untrue.  Admins are hired to *run* things
smoothly, *not* to shut them down.  (See later in this message when I
address this issue specifically.)  *Managers* make decisions, for better
or for worse.  An idealistic admin may take down a critical server
*once* to patch it for a critical update, but there won't be a second
time, trust me.  (In case you're wondering, I'm making these statements
from 30 years experience in managing companies, not based on my present
position.)
> 
> Doing the prudent thing is almost always the best
> approach.  If you see a CERT advisory, I would say its
> prudent to patch.  Even if the language is vague and
> you see no proof.  
> 
And I would agree.  We're not arguing about the *end* result.  We're
arguing about the *timing* and what factors enter in to that decision.

> Do you have to be lifted up into the tornado before
> seeking shelter? If, in the corporate world, your
> downtime to patch means lost income, then perhaps you
> need to allow for such loses in your business
> model/plan.  Its part of doing business, and thats not
> my opinion, its fact.  Either you put the money in(via
> lost revenue in downtime) now, or you lose more money
> later when you get sucked into the tornado.

OK.  Time to follow up on my previous statement about admins being hired
to *run* things, not to shut them down.  If you tell me there's a
tornado coming and I react immediately by shutting down all my systems
and sending everyone home *and* the tornado misses me by 5 miles, I'm
going to be fired for incompetence.  *Especially* if the systems that I
shut down were critical to the operations of the business.

For example, you shut down the systems of a hospital because you think
you need to patch right now for a serious vulnerability.  It just so
happens that a surgeon was *in* the OR at that time doing virtual
surgery, using the Internet, on a patient in another country.  (This has
been done, so it's not a speculative case.)  You didn't bother to ask
whether shutting down the systems would affect anyone so you know
nothing about this critical surgery.  The OR has to scramble to enable
backup systems to complete the surgery and the patient's life is at
serious risk during the downtime.

Do you think you'll have a job tomorrow because you were "prudent"?  I
think not.  You were incompetent.  Because you didn't consider *all* the
ramifications of your actions.  Admins have a lot more paramters to
consider besides the seriousness of a vulnerability before deciding
*how* and *when* to take systems down to patch.  In some cases you may
have to simply disable a service until you can get time to patch the
service.  In some cases you can't even do that so you have to find other
means to protect the box.

>  I am
> sorry, but when a customer calls me today because I
> have taken his box offline to apply a patch, I explain
> to the customer that doing so is the prudent thing to
> do, and the atmosphere turns from a bitching customer
> to one that respects the fact that I am so proactive
> in securing their machine and thier interests.

If I was your customer, I would no longer be.  I want you to protect me,
not take my business offline without notice.

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/ 

Powered by blists - more mailing lists