> > I don't mean to jump down your throat here; the tone is definitely harsher > than I would like, but I want it to be very clear why I have such strong > feelings about upgrading security-critical dependencies. >
I don't take it personally. I do a little coding (hello startup) but I'm actually the guy who: - Had to develop our Policies and Procedures (P&P) in conjunction with our Compliance consultant - Has to work with our lawyers to negotiate Information Security and Business Associate agreements with customers - Has to provide implementation details in request to our customers' security groups (I spent all day working through a 160 item self-assessment so it was top-of-mind for me) When there's a vulnerability, you can fast track an upgrade because there's a non-theoretical risk to doing nothing. The problem is an "optional" version bump. It's all CYA. If I don't follow my P&P, the federal government, state government, and customers all have (extra) grounds to sue my company (cofounder so literally *mine*). If the consequence of waiting are a transient Twisted bug or a delayed feature depending on a feature in a blocked version, it's an easy choice. Clayton Daley On Thu, Jul 7, 2016 at 6:00 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > > On Jul 7, 2016, at 2:06 PM, Clayton Daley <clayton.da...@gmail.com> wrote: > > I don't object to this specific change (we're on shiny new code), but want > to offer some food-for-thought: > > 1) Is newer really better in cryptography? Heartbleed affected 1.0.1, but > not 1.0.0 and there are a bunch of vulnerabilities that only affect the > newer libraries (https://www.openssl.org/news/vulnerabilities.html). It > even makes sense that the older libraries have been more-thoroughly > tested... so new code may just mean new vulnerabilities. > > > I can understand the point here - that upgrades are not zero-risk - but > this is a very dangerous line of reasoning. (I think "in cryptography" you > really mean the general english word "cryptography" and not like "PyCA™ > Cryptography™".) It's dangerous because, as application developers, you > and I aren't really _qualified_ to evaluate whether newer versions of > security-critical libraries are more or less secure; the best we can do is > always, always, always upgrade. The solution to heartbleed was to upgrade > to a newer version of 1.0.1, not to roll back to 0.9.8. > > More importantly, heartbleed itself is not a general category of defect, > in the sense that heartbleed itself shone a bright light directly on > OpenSSL and exposed the real problem, which was massive underinvestment in > critical security infrastructure. The issue isn't that upgrading is > dangerous, it's that letting critical infrastructure decay is dangerous. > > One way that you can *promote* the decay of critical infrastructure is to > defer upgrading out of vague fears about the upgrade going poorly rather > than specific technical issues. > > I should take the opportunity to point out that if you're a professional > network software developer, you should really be giving a couple of bucks > to the OpenSSL foundation: <https://www.openssl.org/support/donations.html>. > The most direct way to fight the decay of critical infrastructure is to > fund it with cash money. (And, for that matter, < > https://twistedmatrix.com/trac/#DonatetoTwisted>...) > > 2) How does this impact regulated industries. In healthcare (my current > industry), changing a library (especially cryptography) could mean: > > - An internal review to select a new version of the library > - An internal change management process > - Technical testing (perhaps a 3rd party audit) > - A notification to clients of the change > - Secondary reviews/testing at clients > > The intensity of this process depends on the risk level of the system and > this could be a long and complicated process for some organizations. Seems > like a more deliberate deprecation policy would make it easier to plan > ahead. > > > The problem with a lot of the regulatory standards that require this sort > of laborious change-control is that during the entire period where all this > redundant analysis and re-analysis of the change is happening, customers > are still vulnerable (and in a health care context, this may mean even that > lives remain at risk!). > > My (entirely secondhand) understanding is that recognition is dawning in > many compliance fields (HIPPA, PCI-DSS, SOX) that there is a mismatch > between the realities of software development (delay in making changes == > risk) and industrial change control (every change == risk), and auditors > and regulators are beginning to take this into account. This means that > the ability to make changes *quickly* to ensure safe operation is slowly > gaining ground over the ability to delay changes until sufficient > evaluation has taken place. > > This recognition is dawning because many of these reviews are, in fact, > nonsense. For example: "an internal review to select a new version of the > library" - does every healthcare project have a qualified cryptographer and > penetration tester to each independently spend the 6 months of careful code > audits required to actually evaluate the relative security of new versions > of OpenSSL, or does this internal review consist mainly of unqualified > people pontificating about hypothetical risks, divorced from the technical > realities of the upgrade in question? > > My own experience has taught me that fear of changes like this is mostly > developers being afraid of audit or compliance, rather than audit or > compliance actually requiring it. If you tell your auditor "we absolutely > have to upgrade OpenSSL every week if an update is available", they'll > usually figure out a way to do it. > > I don't mean to jump down your throat here; the tone is definitely harsher > than I would like, but I want it to be very clear why I have such strong > feelings about upgrading security-critical dependencies. > > Additionally, the Netscape SPKI APIs are disappearing from OpenSSL itself > eventually, so this specific issue isn't just about upgrading - it's about > preventing it from being difficult to upgrade in the future. If we wait > until the APIs are actually gone, rather than just deprecated, this may > create friction around a critical security update. > > -glyph > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > >
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python