Home page logo
/

pauldotcom logo PaulDotCom mailing list archives

Re: counter to claim made on Tenable podcast about upgrading
From: Jack Daniel <jackadaniel () gmail com>
Date: Sun, 27 Jan 2013 18:55:46 -0500

I may have opinions on this...

I think we have to make a differentiation between "version upgrades"
which are only feature enhancements, and upgrades to fix bugs and.or
vulns (although we often get them bundled and have an "all or nothing"
choice).

If a patch/upgrade/whatever fixes a known hole, but might introduce an
unknown hole, I have no problem recommending rapid patching. Security
patches which break things aren't as common as they once were, and
some of what gets labeled "the patch broke it" is more accurately "is
was broken but functional before the patch".

I think staying a rev back for non-security updates is often
reasonable, no one wants to be the first one to apply an Exchange
service pack in production.  But the updates often include security
fixes- for example iOS 6 screwed up all kinds of things, but also
included 100 (+/-, depending on how you count) security fixes.  Damned
if you do, damned if you don't (or the admin's version: blamed if you
do, blamed of you don't).

I think your ability to fail gracefully and revert quickly is critical
to allowing rapid patching and upgrades.  If you can unwind updates
quickly and without (much) drama, you can afford to update more
aggressively.

FWIW, the last time I managed a network it was pretty small, just a
couple hundred devices- I targeted a 72-hour max time to patch on Win
desktops/laptops, and set a target 7-day patch goal for servers,
network gear, and other "non-user" systems (but wasn't stupid about
it, some systems slid up to ~30 days).  I was able to do that in an
NT4/W2k/XP environment *after* I had patch management and backup
systems sorted out and tested.

A final thought on vulnerability fixes- applying the patch or upgrade
isn't the only option.  If the issue is otherwise mitigated (or at
least well-instrumented), then that should buy you time to review and
assess the impact of the update on your environment.

A final thought on non-vuln updates: I used to love getting feature
requests, sometimes pretty adamant requests, for features in products
I supported when the "requested features" had been shipped months (or
in some cases years) prior.  Again, I have no issue with folks who
don't want to be first to upgrade production systems, but make an
informed decision on the trade-offs between versions.

Jack


On Sun, Jan 27, 2013 at 4:46 PM, Josh More <jmore () starmind org> wrote:
Since we're speaking generally, in smaller businesses, I advocate rapid
patching with minimal testing on the belief that the attackers understand
the old bugs better than the organizations understand how to protect against
their exploitation. If you stay current, both the attack and defense side
are equally lost and even if attackers learn faster than defenders do, the
periodic learning level resets are valuable.

Sure, it can cause problems, but the problems they cause are directly
attributable to the patch / new version and can be tested then. The problems
resulting from exploitation take a lot longer to trace and figure out.  If
updating a particular application causes repeated problems, that's in
indication that the organization should look towards replacing it.

In large organizations with dedicated and competent defenders focused on the
application space, the analysis ends up differently, of course.

-Josh More




On Sun, Jan 27, 2013 at 2:58 PM, Frank McClain <frank.mc.42 () gmail com>
wrote:

Well, we've all seen times when a new release creates vulnerabilities that
did not previously exist; in some of these cases, the new ones were worse
than the old ones (never mind issues of performance, stability, etc).
Rushing to adopt a new version without thoroughly testing first can create
problems.

Patches, I tend to view as less of an issue for adoption, especially if
they're for security reasons.  If a vulnerability has been discovered, and
the vendor is actually going to patch it, then it's probably important to at
least seriously look at it in light of your environment.  You do have to
make sure that it's not going to break some other functionality, while still
ensuring that you're covered from the vulnerability standpoint.  If you're
in a regulated industry, your options may be limited when external auditors
discover vulnerabilities that they say you should have patched.

On the other hand, if you feel it's important not to immediately push out
new versions or patches, I wouldn't stay too far behind.  Reason is, you
risk the vendor no longer supporting prior versions.  I've seen some cases
where it seemed that the vendor dropped an older version rather quickly,
because the newer one had more bells and whistles.  Obviously, one revision
behind probably isn't too far out of line.

Regards,

Frank

----- Original Message -----
From: "Robin Wood" <robin () digininja org>
To: "PaulDotCom Mailing List" <pauldotcom () mail pauldotcom com>
Sent: Sunday, January 27, 2013 10:46:50 AM
Subject: [Pauldotcom] counter to claim made on Tenable podcast about
upgrading








Hi
I'm listening to the latest Tenable podcast and Paul was talking about
making sure you upgrade to the latest version of apps just in case someone
has an exploit for an old version which has either been deliberately, or
accidentally, fixed in the latest version.

I'd counter that with older versions of apps have been around longer so
have had more time to probed by the good guys and so vulnerabilities found
and then announced. The latest apps haven't yet been probed so may have new
issues which have been introduced in the new version.

The idea suggested of being one version behind, as mentioned, may
therefore be best from this point of view as the app has had time to be
looked over but isn't too far out of date.

I'd agree that you should stay up-to-date but don't think this argument is
the best to use.

Robin

_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com
_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com



_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com



-- 
______________________________________
Jack Daniel, Reluctant CISSP
http://twitter.com/jack_daniel
http://www.linkedin.com/in/jackadaniel
http://blog.uncommonsensesecurity.com
_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault