Clouds are everywhere these days. They are often cheaper, more powerful, compatible with single sign-on (SSO) and often accessible via a Web browser. There are four main types of clouds: on-premises, or clouds hosted by the customer; off-premises, or clouds hosted by a vendor; dedicated, which are clouds used only for a particular tenant; and shared, a cloud where resources are spread among many tenants.
These categories are more descriptive than public and private clouds. There are also virtual machine-based clouds where several separate computing environments can be used, versus bare-metal, where each compute node is a separate physical machine.
Threats to the Cloud
The first and most dangerous threat in any IT system is the insider threat. It’s especially hard to defend against because users, and particularly administrators, have usually been granted some degree of trust. Technological countermeasures can usually be circumvented if the user has the right level of access. This is why it is critical for organizations to have an efficient offboarding process so that disgruntled released employees do not have access to the systems.
Side-channel threats occur when an attacker has the ability to obtain information from another tenant’s node by measuring some side effect of the system’s use. These have been popularized in the research community but, to IBM X-Force’s knowledge, have not been seen in the real world.
Perhaps the most dangerous real-world threat is the loss of authority over the cloud control interface. We aren’t talking about the provisioning portal but rather the administrative interface of your enterprise’s cloud. Think of it as a control console for your cloud nodes.
In the right situation, this can lead to a complete loss of integrity, confidentiality and availability. Note that the attack here is against the interface’s Web server, or a cross-site scripting (XSS) or cross-site request forging (CSRF) attack against the administrator’s Web browser.
Make sure the interface’s Web server is up to date and that the interface does not have any XSS or CSRF vulnerabilities. These are just good security practices in general and are not unique to the cloud. If you use SSO, be sure your security assertion markup language (SAML) implementation follows the recommended specification.
Additionally, use two-factor authentication. Note that this is good practice for restricting access to any sensitive servers and data.
Additional Risks to Cloud Environments
There is a somewhat rare attack called virtual host confusion. It is often seen with content delivery networks and shared platform-as-a-service (PaaS) clouds. This attack can allow for server impersonation under the right circumstances. Once again, the X-Force team is not aware of this being exploited in the wild. For more information, read the paper “Network-based Origin Confusion Attacks against HTTPS Virtual Hosting.”
This attack is from the same group that identified Logjam, FREAK, SLOTH and others. To prevent this attack, never use certificates for more than one domain. Avoid using wildcard certificates and carefully configure TLS caching and ticketing parameters to be different for every Web server. Finally, make sure your domain fallback page is an error page.
Shared data and computations on shared (typically off-premises) clouds can be exposed in the right circumstances. This particularly applies to MapReduce operations. To prevent this leakage, consider dedicated clouds, where there is a lesser chance of malicious actors having a presence.
Never make the mistake of assuming that on-premises or dedicated clouds need not be secured according to industry best practices. These clouds are often considered a more valuable target by attackers.
Finally, there is shadow IT, or the inability of IT to monitor the activities of the user. This happens when the user’s client is connected to a cloud with an encrypted connection. In that case, the user can interact with the cloud and perhaps perform unauthorized actions. To combat this, consider federating. Monitor your logs to see which applications are in use and use a proxy to intercept cloud traffic. You can also use an analytics engine and create relevant rules at your endpoint device.
In general, what can be done to improve cloud security? Always follow the best security practices whether you are a tenant or a provider, such as tracking new vulnerabilities and attacks against components of your cloud. If you are a cloud provider, do background research on entities that wish to join your environment.
If you are a tenant, always understand your cloud model and compensate for any weaknesses inherent in that type. Be sure to support TLS 1.2 access. This ensures stronger cryptography and is the latest secure protocol for connections to Web servers.
Both providers and tenants should institute regular vulnerability scanning as frequently as is feasible. They should also lock IP addresses so only authorized networks are able to access your cloud or site. If this is not possible as a provider, then be sure to employ strong authentication and access controls.
As a provider, make logs relevant to your tenants available. This complements the tenant’s own logging.
As a tenant, make sure all software is up to date. PaaS providers need to do the same with their environments. In one of the most important measures, tenants must encrypt data. This is critical for data protection, but be sure to implement cryptography correctly. There are solutions available to minimize the ciphertext deduplication problem.