vrijdag 24 februari 2017

While your cloud gently weeps ...

Relevant links

https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
https://medium.com/@octal/cloudbleed-how-to-deal-with-it-150e907fd165#.twfri3rzm

As usual when bugs are disclosed that are - for lack of a better word - esoteric but high impact, the information security echo chamber starts buzzing and gets polarized. You're for or against Tavis Ormandy, you're ok with Cloudflare's approach or you aren't, etc. etc.

It does not really matter. Here are a few observations. If you are lazy, just skip to point 5 ... it is the one that matters for you :


  1. Just like Heartbleed, this vulnerability was not the result of a targeted research effort. Tavis was working on internal tooling and got data back that seemed malformed. While he was looking into what was wrong this vulnerability is what he discovered. At least one party that discovered Heartbleed was developing tooling to fuzz OpenSSL extensions and initially thought their tooling was the reason for the results they got. Only through a diligent QA effort did they find that Heartbleed was the reason. Sometimes bugs reveal themselves in interesting ways. They have to be dealt with all the same.
  2. There is no right way to deal with bugs like this as a service provider. Cloudflare did the best they could, as did Google Project Zero. As security professionals, these are teaching moments. We should be grateful for the transparency on all sides and take away what we can. One day it will be us out there, and we better deal with it at least as well as these fine folks.
  3. The response time from Cloudflare on fixing the code that was responsible for this is impressive. Take it as a metric for your software security program. It is unlikely that you will be able to match it, but it is a very relevant metric nonetheless.
  4. The dedication that Tavis showed in purging as much of the cached data as possible is commendable. It goes above and beyond what is generally expected from a researcher. The amount of money he saved Cloudflare and a lot of organizations using their service by writing custom code to scrub data can not be estimated. The fools are blind to this part of the effort.
  5. Your rage is misplaced. What I learned from this is that NONE of the Cloudflare customers impacted have considered a third party service that is critical to their business important enough to QA from a security perspective. Thousands and thousands of organizations that take your money every month have squarely placed a critical component of why you pay them outside their threat model. That is disconcerting. I think I've been repeating the same mantra to companies for at least a decade : "You outsource process and function, but never responsibility." If you include third party services in your product, no matter what they are, you need to go beyond having the supplier fill in a 400 question SIG questionnaire. You have to actually freaking test that component as if it is a pacemaker that your mother will get implanted. THIRD PARTY COMPONENTS REMAIN YOUR RESPONSIBILITY!
For all that is holy, take a chill pill, appreciate the work Tavis, Google Project Zero, and the fine folks at Cloudflare are doing, and - maybe - try to take their work ethic and adopt it into your due diligence effort. Your procurement team is gonna negotiate that 10% discount, but they won't have to deal with the aftermath of a security incident. That'll be you.

Geen opmerkingen:

Een reactie plaatsen