Stanford CIS

Policies & Practices Encouraging Patch Installation

By Stanford Center for Internet and Society on

1438

Lauren Gelman, Stanford CIS, Moderator
Vincent Weafer, Symantec
Stephanie Fohn, Consultant

Vincent:  Patching can be very expensive, and it's not always the most cost-effective way to solve the problem.  Segmenting the network can help lower the urgency of patching and thus lower cost, but isn't a foolproof solution by any means.  Transparency is important - simplify the patching process, and users will be more willing & able to cooperate.

Stephanie:  Patching is very risky.  What happens when you install a patch?  Will it bring down your production system?

[GF:  While attending USENIX San Diego in '00, I had just started as UNIX Systems Manager at a department at UC Santa Cruz.  I remember being startled that huge companies were buying at least two of everything primarily because they needed to perform their own testing of things like software patches.  Of course, I had my own test systems on which I'd deploy patches before rolling them out to the UNIX labs and centralized servers, because not doing so with Solaris is suicidal.  But I wasn't buying two of everything.  There was a time or two I wished that I had.]

Stephanie:  Patch management solutions exist which make software patching more automated on a large scale.  But this solution exists because of a problem that need not exist - vendors can and should take responsibility for making patching easier and more reliable.  [paraphrased]

Stephanie:  Real world example:  Particular large retailer with a very open policy with regard to individual workstations.  This makes patching unpredictable for them - it's impossible to assure that all machines will take all patches equally well.  So, this entity patches only twice per year.  [!!!]  Another real-world example:  A large bank uses very tightly defined configurations, including host auditing.  As a result, patches can be deployed automatically, reliably, and on short notice.  [Obviously, flexibility suffers in the latter case.-GF]

[GF: At my 'day job', I encourage my users to install whatever software for which we have a legitimate license (if needed).  We have no standardization whatsoever.  As a result, my users are very happy because each person gets what she/he needs & wants, but I run ragged every time a patch on any platform (Windows, MacOS, Linux) is released.  It's worth it to the company in this particular situation, but this is an extreme case.]

Vincent:  Liability for failing to keep up on security patches rests with all involved parties - vendors, maintenance crews (IT folks), and users.

Vincent:  The utility and practicality of automatic updates depends a lot on how quick and easy it is for the user.  Someone who must wait 20-30 minutes or more for a security update to download over a dial-up connection will be much less likely to appreciate automatic updates than someone with DSL or other broadband connection.

[GF:  More anecdotal personal experience:  My grandmother keeps up on her Windows Update patches now that she has DSL.]

An audience member, Vincent and Stephanie talked about how vendors are starting to give themselves greater permissions specifically with regard to automatic remote software updates by way of EULAs, partially because nobody reads EULAs.
[GF: Read those EULAs!  Do you really need software that comes with unacceptable terms & conditions?]

Published in: Blog