Our website uses cookies

Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing Infosecurity Magazine, you agree to our use of cookies.

Okay, I understand Learn more

Somebody Else's Security: Rethinking Cloud FUD

Almost every single day—I talk to people who are planning to move their organization's data to the cloud. As a vertical-agnostic concept, it's hard to find an industry that isn't thinking about cloud migration.

Cisco predicts that, by 2021, 94% of global data center traffic will be processed in the cloud.

This is dramatically different from just a few years ago. Back then, if you asked an enterprise organization if they had plans to move to the cloud, it was like flipping a coin. At the time, enterprises were worried that the cloud inherently lacked security—because of the old bromide that the cloud is "somebody else's computer."

The major cloud providers listened, upping their security and compliance game while continuing to demonstrate the business agility cloud solutions could offer. Now, enterprises, on the whole, can't seem to get enough cloud.

For many, their security has suffered. Their fears were staring back at them in the mirror.

There's a hole in my AWS bucket
Consider just one archetype of a cloud security disaster: An IT administrator looks around his office and data center, sees all of his on-prem security solutions—database security, intrusion prevention system, anti-malware software, firewalls, physical security measures, etc.—and from there assumes that (or, at least, acts like) his cloud environment is just as secure. Consequently, he fails to build in additional security layers into the cloud environment—probably while utterly botching his security configurations.

Sounds silly, right? But the problem is endemic. In Amazon Web Services alone, an estimated seven percent of AWS S3 buckets are configured to allow unrestricted access. The list of enterprise IT organizations who had their private data publicly exposed in 2017 because of misconfigured AWS S3 buckets (whether because they did it themselves or because one of their third-party vendors put their data at risk) is long.

The list includes consulting firms like Accenture, military contractors like Booz Allen Hamilton and TigerSwan, telcos like Verizon and Orange, financial institutions like Capital One, retailers like Walmart, entertainment companies like WWE, Viacom, and the Australian Broadcast Corporation.

M&M Security in the Cloud
Let's say, miraculously, no ill comes out of the failings of our IT administrator from the earlier example. He may have even accidentally done something right.

But now one of our lead developers looks around, sees the same things that the IT administrator did, and comes to the same conclusions as the IT administrator did about being in a "secure environment." Because every keystroke he can save represents precious time, our lead developer uses his recycled, easily guessable password (assuming he bothers to change the default).

From there, he proceeds to upload production data (which, in a truly secure development lifecycle), he shouldn't have access to in the first place) to the cloud. Then—completely forgetting that his code includes sensitive API keys—the developer posts said code to his GitHub repository.

Now comes an outside hacker, running a dictionary attack to get into our lead developer's GitHub repository. When the dictionary attack succeeds in a matter of seconds, the hacker gains access to our lead developer's user credentials, uses them to breach the company's AWS buckets, and holds the company's data for ransom.

This is like locking the door but leaving the key under the mat—and having no alarm system, guard dog, or other "inner" security once the outer security of the door is breached.

Somebody Else's Problem
So, sure, the cloud is indeed somebody else's computer—in the same way that an apartment is "somebody else's property." You may be renting the resources, and your "landlord" may be liable for particularized maintenance items—but you're still on the hook for losses and damages if you share your keys, leave the windows open, or leave the door unlocked.

The cloud is secure—or, at least, it can be - but a lot of cloud implementations aren't secure because enterprises have turned the security fears of the "somebody else's computer" philosophy into a self-fulfilling prophecy.

Specifically, the perception of the cloud has evolved from that of "somebody else's computer" to one of "somebody else's problem." The breaches described above were all user-caused. All the cloud vendors can do is offer decent UX and training, and then cross their fingers.

It's up to enterprises—large and small—to (1) audit their cloud service providers, (2) have a trained cloud-configuration expert in-house to make sure that their cloud environments are secure, and (3) install visibility and incident-response tools to make sure that their clouds stay that way.

In other words, if you're in or going to the cloud, don't pass the security buck. It may be somebody else's computer, but it's your data.

What’s Hot on Infosecurity Magazine?