Cloud computing is everywhere. As McKinsey accurately predicted back in 2016, “in the next three years, enterprises will make a fundamental shift from building IT to consuming IT.” Today, most large enterprises use cloud computing in at least one capacity, from DevOps to data storage to web hosting. Consumers – over 2.3 billion – are also using the cloud. With the availability of Google Drive, DropBox, Amazon Web Services, and numerous other cloud applications, individuals can easily share and store files at little to no cost.
The cloud provides particular benefits on the enterprise end; as the National Institute of Standards and Technology articulates,
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.
But like any technology, the cloud obviously has its security risks.
The Risks of Enterprise Cloud
In addition to challenges of encryption, packet filtering, password strength, firewalls, intrusion detection systems, and other elements of IT security, the cloud presents another interesting complication: the opportunity for hackers to break into a single organization’s cloud application (i.e. break into a single server), and then “tunnel” from there into other applications.
This is because of multi-tenancy, or multiple instances of the same application operating in a shared environment. This is a central property of cloud computing. For instance, a cloud might be running a document editor for seven different companies, simultaneously, all on a single server. While this feature is a great selling point for Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS) companies whose products reside in (or quite literally are) the cloud, vulnerability for one cloud user becomes vulnerability for another.
Perhaps unsurprisingly, there are several techniques that can address this security risk. While customer systems may have varying degrees of security, robust security protocols on the provider side can safeguard against multi-tenancy-enabled threats.
In Short: Isolate Your Cloud
Isolation broadly refers to keeping systems separate from one another; separating an electrical grid from a public water system is a perfect example. In the cloud context, then, isolation failures refer to customers being on the same machine without proper segregation between their applications. Resources may be insecurely shared. Two program instances may not be entirely separate.
As a result, hackers could tunnel from customer A’s external system into B’s cloud, and then jump from B’s cloud into C’s cloud, and so on. The breaches themselves could occur through file systems, APIs, social engineering, and more – it doesn’t particularly matter; the point is, isolation failures are an enabler of such attackers.
For server systems with heavy and frequent resource sharing, tunneling from system to system could allow hackers to “cascade” across a network – breaching many companies at once.
- Isolate the network traffic of each customer. While multiple clients may be sending API requests to the same server or socket, they shouldn’t be able to see the network traffic of any other clients – so block clients from seeing the full queue of incoming network data. Not properly restricting the visibility of network traffic on the server is only inviting a hacker to find the least-secured client of a cloud company and then use them to spy on other companies with stronger security. Make sure there are no traffic overlaps, on the sending or receiving ends.
- Isolate cloud resources through containerization – separating the memory and operating system of each application. Separate A’s virtual machine memory from that of B. Make sure a buffer overflow attack against one system (which shouldn’t succeed anyway) won’t tread into a second’s memory; specifically, prevent one VM instance from reading, copying, or writing to the memory of another. Dynamic information-flow tracking, a hardware mechanism to prevent malicious, data-driven attacks, is just one technology helpful in this regard.
- Heavily encrypt all data, both at rest and in-transit. Just because data is stored in a cloud environment doesn’t mean it’s safe. Use robust, industry-grade encryption algorithms like RSA. Store encryption keys separately from the data they’re encrypted with. Be aware that some enterprise file sync and share (EFSS) applications use web connections to transfer data on their own – so ensure these use secure communication protocols like TLS. To this point, make sure client API requests are sent only via secure tunnels; anything unencrypted should be rejected immediately. Query responses, initiated on the provider end, should be encrypted as well.
- Delete old data. While this should already be occurring via resource allocation, it can also prevent the hack of one customer’s environment to read the old data of another that’s still sitting on a server. To supplement standard file deletion, use cryptographic erasure (CE) – otherwise known as crypto-shredding – to destroy the encryption keys themselves. This will prevent an attacker from reading the data, providing the algorithm can’t be brute-forced (which is another reason for strong encryption in the first place). Set up regular schedules to ensure this fact.
- Rigorously penetration-test cloud applications and cloud hardware for isolation failures. Build strong feedback loops to report and quickly patch any vulnerabilities you discover. This isn’t just a convenience, but a necessity for any business providing cloud services to another. Enterprises often have too much to lose just because of weak security practices.
These steps aren’t perfect, and every enterprise cloud provider – SaaS, PaaS, or IaaS – should consider far more than just the cloud security risks posed by multi-tenancy. But following these initial recommendations can further establish a strong cybersecurity posture in the enterprise cloud.
The Certified Ethical Hacker (CEH) v10 program, now includes emerging attack vectors on the cloud, artificial intelligence, and machine learning, as well as, IoT hacking, vulnerability analysis, and static and dynamic malware analysis. Learn more about the course here.
About the Author:
Justin Sherman is double-majoring in Computer Science and Political Science, focusing on cybersecurity, cyber warfare, and cyber governance at Duke University. He conducts technical security research through Duke’s Computer Science Department; he conducts technology policy research through Duke’s Sanford School of Public Policy; and he’s a Cyber Researcher at a Department of Defense-backed, industry-intelligence-academia group at North Carolina State University focused on cyber and national security. Justin holds over a dozen cyber- and security-related certifications, and he’s a regular contributor to many industry blogs, news sites, and policy journals.
Disclaimer: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of EC-Council.