Cloudbleed: Three Risk Management Lessons Learned
Recently, a Google researcher discovered a serious flaw with the content delivery network (CDN) provided by CloudFlare. This vulnerability has now become known as Cloudbleed, in a nod to the earlier Heartbleed SSL vulnerability. The Cloudfare CDN allows users of the service to have their content stored at Cloudflare Network Points of Presence (PoPs) rather than a single origin server. This reduces the amount of time it takes to serve websites in disparate geographical locations. The service is popular, with Cloudflare having over five million customers, including Uber, OkCupid, and FitBit.
The Cloudbleed vulnerability involved a situation where sensitive data was inadvertently displayed or “leaked” when visiting a website that used certain Cloudflare functionality. Cloudflare has estimated that the leak was executed 1,242,071 times between September 22nd and February 18th. Search engines such as Bing, Yahoo, Baidu and Google also cached the leaked data. The researcher who discovered the leak found all sorts of sensitive data being leaked, including private messages from major dating sites, full messages from a well-known chat service, online password manager data and hotel bookings, passwords and keys.
The Clouldbleed vulnerability is a reminder that companies that leverage external vendors to receive, process, store, or transfer sensitive data must find ways to reduce the risk created by the relationship to an acceptable level. We have three steps that companies should consider taking to accomplish this.
First, companies should understand how external vendors will interact with their data flows. Companies that leverage Cloudflare services have given it access to sensitive data, including private messages, passwords, and keys. The risks of providing this data to external vendors cannot be understood if the company itself does not understand at a senior organizational level what is being transferred. Ask questions about the proposed procurement of vendor-provided services to understand what interaction the service/vendor has with your data.
Second, companies should make sure that they have permission to transfer user data to third parties, based on its existing terms of use and privacy policy documents that the relevant data subjects have agreed to. Generally speaking, in most cases, the company collecting the data from the data subject will remain responsible for any issues that occur downstream, including loss or breach of the data through a third party vendor relationship.
Third, companies should carefully negotiate their vendor contracts in light of their own risk tolerance. The contract should contemplate the data at issue, including by type and category, such as private messages and passwords, and should to the extent feasible transfer all risk of a breach on the vendor side to the vendor. In many cases, it will be appropriate to require that the vendor carry insurance to satisfy its obligations under the agreement, including data breach remediation should it become an issue.
Companies with any questions regarding this process should not hesitate to contact the Privacy and Security team at Mintz Levin.
Author
