Bitsight’s Response to “Cloudbleed” and a Framework for Addressing Third Party Vulnerabilities

As we discussed in a previous blog post, Cloudflare suffered a serious bug that caused private information from any Cloudflare customer and their users to be publicly leaked onto websites that had corrupted web content. Any person with knowledge of those websites was able to scrape the sensitive information left there.

This blog discusses the steps Bitsight took to understand how our product and services may have been affected, assess how our own business’ third-parties were affected, and show what we did to mitigate those possible risks. Because one of Bitsight’s APIs uses Cloudflare (as we will discuss below), we want to ensure that we are fully transparent with customers about their potential impacts and the steps we took to address this bug.

Bitsight Products

After determining which Cloudflare products were potentially susceptible to this data loss, we determined that only our Security Ratings API was affected, as it was the only product using Cloudflare’s reverse proxy. We also confirmed with Cloudflare that none of our information in transit was lost or publicized. Our next step was to consider the risk exposed by the possibility of API credentials being leaked. In the case of programmatic APIs, such as the Security Ratings API, credentials are sent in every request to the service, which do not have the same time-bound characteristics as cookies. In the case of an application using username and password, depending on the risk profile the website is comfortable with, they can either (a) invalidate cookie sessions and require users to reauthenticate, (b) also require users to reset their passwords. API credentials have the same chance of exposure as session information, but there’s no way to invalidate API credentials without resetting them.

The loss of data in this situation was not guaranteed. Because Cloudflare services a high number of requests in combination with the obscurity of the URLs that were leaking data, there was a low probability that one particular user or vendor was affected by this issue. Due to the low probability of a token being exposed, we reached out to our customers on Friday to inform them that we would reset their API credentials on March 1. We suggested that they do this on their own ahead of this date to provide a seamless transition and avoid disruptions within any products that had integrated with our API. If they did not reset their token between Friday, February 24, and March 1, they would be revoked and reset automatically. We engaged with each customer directly to ensure this was a seamless process.

Bitsight Third Parties

Like many other companies, Bitsight uses third party payment providers, banks, healthcare providers, and other vendors. We use our product as part of our process to continuously monitor the third party risk of these companies. As described in our previous blog post, we used the Security Ratings platform to identify which vendors were using the affected Cloudflare product. This information is provided in even more detail using the filtering capabilities within the Bitsight Discover product. We used this functionality to focus in on specific products that might have been affected. Likewise, if Bitsight was in a customer’s portfolio, they would have noticed that Bitsight used Cloudflare due to the aforementioned Security Ratings API using Cloudflare’s reverse proxy.

The next step was to assess the possible impact on those vendors. This was easy if the vendors were proactive in alerting their customers about whether they were affected. The first pass through the reduced list of vendors showed that a third of them had either contacted us or had posted easily identifiable articles that allowed us to quickly assess our risk. For the remaining vendors, we had to manually identify what resources were behind the services we used and verify that these were the affected resources our product had identified. This can be revealed through monitoring which resources are accessed when using the specific application or service. Sometimes this is harder to do, for example with mobile applications when those resources are more often abstracted to the user. At that point the next step would be to contact the vendor to confirm if they are impacted and take any necessary precautions.

Through the remaining process we were able to further reduce the number of affected vendors in half, allowing us to focus our efforts on the impacted vendors rather than reaching out to all of our third parties. We took an approach appropriate for each impacted vendor to minimize future exposure. Some services were used by a small team of internal employees, others by our operations team, and another group of vendors were used by all employees. We were also able to determine that no third party services that rely upon Cloudflare’s reverse proxy are used within our products.