Cloud Needs Operational Gates–Especially for Security

In January of 2017, the very popular MongoDB suffered what seems to be becoming a fairly predictable tactic for attackers: taking data hostage. Subsequent investigation into the compromise noted that for the most part, attackers had exploited … nothing. The issue wasn’t with the software, but the configuration. The default configuration, mostly running on AWS, that left the databases wide open to anyone with an Internet connection.

This included the now infamous CloudPets dramain which voice messages (presumed to be private) between children and their parents were publicly accessible to anyone savvy enough to either grab the database (a non-secured instance of MongoDB) or understand the app architecture and its use of Amazon S3. Cloud Pets used S3 to store profile pictures and voice records and apparently waved off any kind of security, leaving them accessible to anyone with the proper reference.

Now, lest you think think I’m picking on CloudPets, let me note that the RedLock CSI team recently discovered that “82% of databases in public cloud computing environments such as Amazon Relational Database Service and Amazon RedShift are not encrypted.”

[dramatic pause]

Furthermore, “31% of those databases were accepting inbound connection requests from the internet.”

Let me further note that there were more than 27,000 MongoDB servers compromisedin the first weeks of January 2017. Way more than CloudPets was bit by their own poor security practices regarding this incident. As a blog from MongoDB noted when the first attacks were publicized, “These attacks are preventable with the extensive security protections built into MongoDB. You need to use these features correctly, and our security documentation will help you do so. [emphasis mine]”

MongoDB was not insecure, it simply wasn’t secured at all. The problem really isn’t with the product, it’s the poor practices of those rushing to get IoT and mobile apps into the hands of consumers via cloud. 

Cloud as a Catalyst for Insecure Practices

In the datacenter – on-premises – there are gates, both physical (firewalls and the like) and operational (processes and approvals), that must be passed before software is unleashed on the world and used to serve up data. Cloud, by design, has fewer physical gates and – as it unfortunately often appears – fewer operational gates for apps to pass before it is offered up to the world at large. The reduction of operational gates is really where the concept of “rogue IT” or “shadow IT” has gone. Line of business stakeholders, frustrated with long lead times and project timelines spanning years instead of months, originally began to take to the cloud to “get around” IT. Except what that meant was they were also going around the operational gates put in place to ensure the security and performance of those applications.

That’s not a problem with cloud, it’s a problem with those adopting cloud. Because it isn’t just the “takes too long to provision physical hardware” line we’ve been fed for ten years; it’s the “takes too long to get through IT approval processes” that really chaps the derriere of business stakeholders who just want to get to market now, before the competition.

Respondents to a 2017 Arxan/IBM sponsored survey on Mobile and IoT Security back that up. Respondents cited pressure on app dev teams as being responsible for poor security of IoT and mobile apps, with 69% pointing the finger at rushing mobile app development as the source of vulnerable code, and 75% saying the same for IoT apps.

That same pressure extends to setting up and securing the databases and cloudy storage that makes things useful in the first place. The entire premise of Cloud Pets is built not off the toy, but on the toy’s ability to send and receive data via the Internet. That means its success resides in one of those IoT apps being rushed through development and deployment in the cloud to hit that Christmas Day release date.

Developers aren’t the only folks responsible for securing the applications they’re tasked with delivering. Whomever is responsible for provisioning cloudy services supporting that app – whether database or file sharing or app services in general – must shoulder some of the responsibility for securing it. And so should the business stakeholders driving unrealistic deadlines and encouraging bare minimum operational gates for final delivery.

Yes, IT has to embrace digital transformation and streamline the operational gates that lead to successful – and safe - product delivery to consumers. But business and developers cannot continue to simply avoid those operational gates in the cloud and leave not only consumers but corporate stakeholders at risk with shoddy security practices that rely on “default” configurations. This isn’t as much about products as it is processes; it’s about ensuring that policies are deployed and configurations correct before exposing apps – and their users – to preventable compromise.

If you’re going to avoid an embarrassing incident, you have to start by putting some basic security stakes in the sky by defining (and enforcing) at least some basic operational gates that must be passed before going to market.

Organizations need those operational gates more than ever, because the pace of migration to public cloud for apps supporting both productivity and profits is accelerating. And along with that increased pace of migration comes an increase in the opportunities for attackers to exploit them.