Finding online data exposures is like shooting fish in a barrel—assuming that you’re using an M65 cannon with a nuclear payload. New and horrific breaches emerge every week. In the last couple of weeks alone, we’ve seen several, each violating privacy and security in different ways.
Some expose internal information that could be useful to hackers. For example, data integration and big data management company Attunity left internal files from TD Bank and Ford Motor Co exposed to the public via a misconfigured database hosted on Amazon Web Services, including details about internal technology architecture.
Others surface details that tell attackers about peoples’ personal lives and potentially expose their entire homes to attack. Chinese manufacturer Orvibo was found to have left a database with two billion log events online, including usernames, unsalted passwords, account reset codes, and even the precise geographic coordinates of devices for thousands of users.
Then, there are the embarrassing ones. Online Buddies, which makes the LGBQT dating app Jack’d, just shouldered a $240,000 fine after reports emerged in February that it had left images of almost 2,000 users exposed in an insecure AWS S3 bucket. Many of the photos were nudes and included the user’s locations, putting them at potential risk. Senior executives learned of the incident a year prior and did nothing.
Why does this keep happening? There are two main causes. The first is a misunderstanding of who’s responsible for cloud security.
Cloud service providers are clear that both they and the customer share responsibility for cloud security. Here’s Amazon’s shared responsibility model. Here’s Microsoft’s.
Despite this, companies treat cloud infrastructure as an outsourcing mechanism for security. CyberArk recently asked 1000 people across the globe, ranging from C-suite executives through to developers, what they took to the cloud and what their security expectations were. Of those surveyed, almost half ran business-critical applications in the cloud or stored customer data there that was subject to regulatory oversight.
Security was a big reason for migrating to the cloud, with 36% saying that they did it to offload security risk. Many of them took the term ‘offloading’ literally, with 75% relying on the cloud provider’s built-in security, despite 50% recognizing that it wasn’t sufficient.
Misfires and explosions
Perhaps this lack of concern prompts the second reason for massive data exposures in the cloud: misconfiguration. When these public-facing exposures happen, it’s usually because someone has left a cloud-hosted database accessible to the public, and it’s normally one of two brands: Elasticsearch or MongoDB.
It has always been possible to limit remote MongoDB access, but the company only switched that on by default in version 2.6, released in April 2014. That was only in certain distributions. Then, MongoDB made this configuration the standard across the board in version 3.6.
Elastic, which makes Elasticsearch, has long disabled remote access by default in the free version of its software. It only takes a simple alteration in a configuration file to turn it on, though. They might rely on a separate firewall in front of it for security—if they used anything at all. Apparently many don’t.
In the past, if you wanted built-in security for remotely accessible Elasticsearch instances, you’d have to pay for the premium version. Recently, the company changed things up by making core security features free in the product. It now includes native authentication and role-based access control, along with TLS for encrypted communications. This may be due in part to Amazon’s launch of its own open Elasticsearch distribution, which includes security features out of the box.
So now there really is no excuse for exposing large sensitive datasets to the public—not even complaining that security isn’t free. However, there are still many older and misconfigured instances out there. What are the odds that they keep on making the headlines for months or years to come?
If you want to get ahead of the pack and ensure that your own cloud security is airtight, get some training. SecTor’s Cloud Security Hands-On session will take attendees from zero to sixty in two fact-filled days this October, teaching them the fundamentals of cloud security and preparing them for the Cloud Security Alliance CCSK version 4 exam. It happens on October 7-8, just before the main conference, and you can register here.
There are 0 comments