mailing list archives
Re: Getting Off the Patch
From: Valdis.Kletnieks () vt edu
Date: Tue, 18 Jan 2011 14:45:38 -0500
On Tue, 18 Jan 2011 18:39:24 GMT, "Thor (Hammer of God)" said:
On Mon, 17 Jan 2011 22:29:13 GMT, "Cal Leeming [Simplicity Media Ltd]" said:
Most people wouldn't rely solely on patch day to protect their
You're in for a surprise.
Are you taking the position that the level of "being surprised" at the number
of people who only patch dictates that they stop patching and try to
successfully implement other controls so they don't have to patch?
No, I'm taking the position that "most people" are in fact solely relying on
patching because they are clueless and they wouldn't even be patching at
all if auto-update wasn't turned on. (And Cal caught on what I meant in his
reply - that there's two very disjoint communities).
And that changes the calculus of "best practices" - what's "best" at a shop
that has thousands of managed nodes and a staff of dozens of experienced
sysadmins is different from a shop that has dozens of machines and one
semi-clued guy with a McSE. (We'll leave home machines out of the
equation for now - it's safe to assume that *those* machines the operating
system has to take steps to protect itself, including auto-patching, because the
user won't do it).
Yes, it's almost mandatory for large shops in billion-a-year revenues to have
separate devel, testing, pre-prod, and prod systems, and extensive controls and
testing procedures. They usually can afford a few extra servers and one or two
more live bodies to do the work. But in a smaller shop, the added cost of 4x
the servers and added pressure on a single sysadmin's time can be a real
show-stopper. Hiring a second guy will mean *literally* doubling the total IT
budget - and if you're a small business with only 15 or 25 employees *total*,
this can be a showstopper issue. In those shops, you'll *never* get a 'best
practice' deployed, no matter how 'best' it is, unless it's at least both
cost-neutral and time-neutral. Even at large shops, trying to deploy a better
practice can be difficult - if the current security is seen as "good enough",
trying to sell something that's only a 10% or 15% incremental benefit can be
difficult unless you can make the business case for it.
And that's something I've noticed is lacking from much of the discussion - the
business case for deploying something. Sure, something might well be more
secure, but unless the added security is worth more than the added cost, time,
and effort, it's actually a bad idea to deploy.
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/