Figure 2: Top domains in a Shodan search for CVE-2014-0160 on January 22, 2017

That’s disconcerting because there is a tendency to “fire and forget” in the public cloud, and concerns over understanding the shared responsibility model of public cloud have been previously voiced. This remains my favorite quote, from AWS head of global security programs Bill Murray, in an interview with the Register in 2015:

“Customers are responsible for protecting everything from the guest operating system they run on AWS up through the applications they are running,” he told El Reg. “We are responsible for the host OS and the VM and everything down to the concrete of the data centre floor.”

“We are asked this question a lot: ‘What keeps you up at night?’ What keeps us up at night in AWS security is the customer not configuring their applications correctly to keep themselves secure,” Murray said.

That leads us right back to today and the disconcerting data from Shodan. Now, the data doesn’t disclose whether it’s Amazon’s web servers or its customers web servers that are vulnerable, and it’s not clear how the domain names were rolled-up. After all, most customers’ domain names are merely CNAMEs for a host within Amazon’s domains, so it’s likely that at least some—if not a majority—of vulnerable web servers belong to customers.

But that’s largely irrelevant, because at least some of those 180,000 vulnerable web servers are in a public cloud, and the responsibility for addressing the risk falls squarely on the shoulders of the customer.

There are legitimate reasons why some customers may have not addressed this vulnerability with the appropriate patch. Factors such as compatibility with the rest of the application stack and the investment of time required to test and certify a new stack can outweigh the risk. That’s why risk management exists, after all—to weigh all the factors involved and determine whether the risk is worth the effort to address.

Still, there are other, less costly means of mitigating risks like Heartbleed in the public cloud. Injecting a non-vulnerable application proxy in front of the web server, for example, would effectively mitigate the threat with little effort. Also, a web application firewall—if it’s in use (and if it isn’t, we have more to talk about than just Heartbleed)—can often provide the protocol-level security necessary to mitigate threats like Heartbleed without requiring extensive changes to the web server.

Both of these alternative solutions require, of course, some effort on the part of the customer. That’s because the security of web servers and applications in the public cloud lies solely on the shoulders of the customer. While public cloud providers may (and do) offer app services that can perform these tasks, and numerous vendors provide similar offerings through cloud marketplaces, it still behooves the customer to seek them out and deploy them.

Web applications are the gatekeepers of data; data that is highly sought after by malevolent forces whose economy is just as digital as business today. And web applications depend on web servers, and the protocols that secure and deliver them. If they’re vulnerable, apps are vulnerable. And if apps are vulnerable, so is their precious data. Ensuring that vulnerabilities are mitigated in a timely fashion is not just good security practice; it’s good business practice in a digital economy. And that means patching both apps and the servers upon which they are deployed, especially in the public cloud.

Because if Shodan can find web servers vulnerable to Heartbleed, so can the bad guys.