The adoption of public cloud computing makes user data less secure. And it’s not for the reasons most in IT realize.

In the first part of this series, I explain why; solutions follow in part 2.

Most users experience the cloud as online software and operating environments (e.g., Google’s App Engine, Chrome OS, Documents); and as online backup, storage, and file sharing systems (e.g., Dropbox, iCloud).

Adopting such services makes sense. Its providers have deeper resources, better technical talent, and more capabilities for predicting and reacting to adverse events. This lowers the probability of data loss and outages, be they because of accidental or malicious causes. Using cloud-based services reduces the in-house processing power requirements and also meets the varying data access needs that users have today. This reduces the costs of maintaining hardware, software, and support staff.

Most Companies Have Adopted the Public Cloud

Recognizing these advantages, some 91 percent of organizations worldwide have already adopted public cloud computing solutions and around 80 percent of enterprise workloads are expected to shift to cloud platforms by year’s end.

But cloud computing solutions also bring new technical challenges that can expose the enterprise to cyber-attacks. Many of these are well known in cyber security circles and have proven fixes. This includes mechanisms for auditing security vulnerabilities both at the provider end and on client machines, for assuring the availability and integrity of hosted services through encryption, and for granting and revoking access.

Outside of these, however, there are several vulnerabilities that arise from using cloud-services. These are user and usage driven issues that are ignored by most in IT who prefer to write-it off with the “people will always be a problem” adage rather than tackle them. In consequence, most of these threats are seldom researched, but they make the data hosted on the cloud even more susceptible to being hacked.

For one, using cloud-based file sharing routinizes the receipt of hyperlinks in emails. Keep in mind, hundreds of providers make-up this market space. Most organizations use at least five different cloud services and most users subscribe to an ecosystem of their own liking. These translate to numerous cloud-service generated hyperlinks that users frequently send and receive via emails and apps on different devices.

But once users get accustomed to complying with such emails, it routinizes opening hyperlinks, making them much more likely to click on malicious hyperlinks in spear phishing that mimic them.

Convenience is not Always Secure

Making things worse is the design of cloud-sharing services. In their bid to make it convenient, services such as Google Drive, Google Photos, and Dropbox, send out pre-crafted email notices of shared files.

The email notice usually contains only a few pieces of variable information: the name of the sender, the hyperlink, and some information about the file being shared through the link. The rest of the space is occupied by branding information (such as the name of the cloud provider and their logo). Thus, users have just a few pieces of information for judging the authenticity of what’s being shared.

But in many cloud services, while the email appears to come from the sender and has their name, it doesn’t come from their in-box. Instead, it comes from a different in-box, one that changes with the provider. For instance, Google Drive notifications come from a “” inbox, Dropbox comes from a ”,” while Google Photos comes from a “,” where the alpha-numeric characters (randomly chosen for this example) change each time. No user can remember these in-boxes, so there is no way for users to know if these emails are indeed authentic. Furthermore, cyber security awareness training caution users about opening emails from strange and unknown in-boxes. Thus, every time users open a cloud-shared hyperlink, they have violated safety principles they were taught-–which erodes their belief in the validity of the other aspects of their security training, opening them up to even more online attacks.

Hyperlinks Shared Through Cloud Services

A similar issue plagues the hyperlinks shared through cloud-services. Most contain special symbols and characters, and there is no simple way for users to assess their veracity. Given how these are generated and shared, users cannot plug the hyperlink into a search engine or into a browser without deploying them. Nor can users forward privately shared links to a sandboxed device or to another person with expertise. All users can do is rely on the information in the email, which requires deploying the hyperlink.

Outside of the sent-mail and hyperlinks, the only other varying indicator in a cloud-sharing email is the extension of the shared document (such as whether it is a .DOCX or a .MOV file), which is usually accompanied by an icon showing the type of file attached (e.g., a PDF icon). These were never designed to serve as yardstick for gauging the veracity of shared files.

As my research on user cognition shows, people form several false assumptions about online risk. For instance, many people believe that PDF documents are secure because they cannot edit them, which, of course, has nothing to do with the security of the file-type. These mistaken assumptions, what I call Cyber Risk Beliefs, are not only trigged by icons and files extensions, but they also dictate how users react to them. So, seeing a PDF extension or icon–which can easily be spoofed–and believing it is secure, further increases the likelihood that users will open cloud sharing hyperlinks that may actually be spear phishing.

Finally, the display of all these pieces of information is further circumscribed on smartphone and tablets. Depending on the app and device, brand logos and other graphical information are sometimes not displayed, sender information is auto-populated from the device’s contact book, and the UI action buttons, as in “Open” Download” and “View” are made prominent. These are deliberately designed to move the user along to a decision–which almost always is to comply with the request rather than to pause or exercise conscious care.

Such design issues plague many communication apps accessed on mobile devices–something I highlighted in my 2019 Verizon DBIR write-up. But they are even more problematic in cloud-based file sharing because unlike email, which by default receivers expect to be personalized (as in have a subject line, some salutation, and always, a message), the established norms for cloud-sharing of files are exactly the opposite: users seldom expect personalization, almost never include a message, and don’t even know how to inject a subject-line. This not only makes it easier to create spoofed cloud sharing emails but users have a particularly hard time discerning them on mobile devices.

Wrapping Up Cloud Security

All these issues are usage driven and stem from the success of the cloud. This means they are unlikely to go away and the widespread adoption of the cloud–a market Gartner expects will exceed $220 billion by 2020–will only increase their scale.  Given the volume of data that is increasingly stored on the cloud, the availability of so many user level vulnerabilities are fodder for social engineers looking for easy ways to hack the data.

And this is already afoot: Dropbox, Google Drive, and Adobe accounts are now among the most common lures used in spear phishing emails. In 2019, one in four breaches in organizations involved cloud-based assets, and a whopping 77% of these breaches happened because of a phishing email or web application service, that is, the attacks spoofed cloud-service emails and contained hyperlinks that led users to watering holes.

Keep in mind that these vulnerabilities exist in almost all cloud services, which means breaches because of them can occur in any of them. But, because of how users form beliefs about online risk, a breach in one would likely undermine their trust in all cloud platforms. So, resolving these issues is necessary not just for better protecting data but also for ensuring the continued adoption of the cloud.

How we do this, I discuss in the part 2.

*A version of this post appeared here: