As we're adopting cloud computing, we're more aware of the security concerns it raises than we were of issues created by other large-scale technologies we adopted in the past. This is a wonderful thing! But security nirvana has yet not been achieved. While there's still plenty of room for cloud providers to improve, many aspects of cloud security must be the responsibility of the consumer.

In particular, I see five security-related issues with cloud computing that are critical to the success and security of a cloud-based project—and that are not always getting the full consideration they deserve.

1 Internal clouds are not inherently secure.

In the past year, many organizations have foregone using public clouds, choosing instead to build private clouds behind their firewalls. This may be the best solution for risk-averse groups.

These teams, though, need to understand that just because they've built a cloud inside their firewall doesn't mean that their solution is safe. It still takes just one bad apple to spoil the barrel—a single department, user or application that is not behaving as it should.

An organization that is risk-averse enough to avoid the public cloud should be building a secure cloud—possibly the company should be building its dream cloud, which contains all the security controls that it thinks are missing from a public environment. Since the company physically owns the private cloud, incident response can be very swift. Detection capabilities need to be cloud-specific (for example, sensors need to monitor inside the cloud, not just at its perimeter) and operational capabilities such as patch management must be sharp. A vulnerable service that's in a cloud might have greater exposure and risk than the same service in a standard server farm thanks to the shared nature of cloud resources.

Several vendors are now able to sell spare resources from a private cloud to other organizations. Imagine: A risk-averse company builds an internal cloud, firewalled from the public Internet. They've taken basic precautions, but haven't really built security into their playbook. The following year, the organization's budget shrinks, and management hears it can cover costs by renting part of the company's cloud when it's not in use. Maybe they understand the risk involved, but decide to mitigate it at a contractual level.

This is not a farfetched scenario, and if I were looking for malicious entertainment, buying a few hours' time in an organization's internal cloud could provide interesting results.

2 Companies lack security visibility and risk awareness.

The paucity of security visibility that most providers offer their customers is itself getting plenty of visibility. Obviously, when using a public cloud service, companies must balance the competing factors of control, visibility and cost. This can be a significant issue—reduced visibility results in diminished situational awareness and a questionable understanding of risk.
When planning a move to the cloud, an organization needs to recognize this lack of visibility and determine how to best leverage what insight they can get their hands on. Really, this means designing mitigating controls.

At the infrastructure and platform levels, this is straightforward: Log more information in your applications and set systems up to generate alerts when signs of compromise or malicious use are spotted (for example, when files are modified, records are changed more frequently than usual, or resource usage is abnormally high). For software as a service (SaaS), though, these precautions will require more thought.

SaaS providers are beginning to distinguish themselves via security features. Organizations vetting SaaS providers should consider how they will handle risk awareness—does the provider offer usage data that is granular enough to recognize changes in usage? (Monthly billing doesn't really cut it, unless the risk scenario is a malefactor who only attacks on the 29th of the month.)

If a malicious user attempts to access data stored in the cloud, how will the company learn of this? If sensitive data is modified or destroyed, is there a way for you to be notified quickly? Frequently, providers will offer a wider variety of information via an API than they do in their dashboard. While this does require that you get code written that can leverage the API, modern APIs are usually easy to work with, and the information you gain as a result will be valuable to risk-sensitive organizations.

It would be great to have a standardized API for gathering security information from a provider, but as far as I know, no one is developing one right now.

3 Sensitive information needs safer storage.

Safely storing sensitive information is one of the toughest problems in cloud computing. The solution is to encrypt data, but the critical questions are where to encrypt, and how.

The first requirement of successful encryption in the cloud, which some providers do not yet understand (or at least don't practice), is: Do not store the encryption key with the encrypted data. Doing so more or less negates any value gained from encrypting the data.

However, the solution is fairly simple, and there's no excuse for not implementing it.

In current shared environments, nobody is yet offering a virtual-machine solution that guarantees the integrity of the guest environment. This means that a malicious program could be monitoring the guest's encryption-decryption logic, capturing both plain-text data and the encryption key.

If the application receives plain-text data and encrypts it in the cloud, there's no easy fix for this right now, other than running on bare metal—installing applications directly on the hard drive, not in the OS.

Some businesses, though, don't encrypt in the cloud, but encode it before it reaches the cloud service. This works in cases such as a company using a customer resource management system only from its offices, or a business where all users either are at headquarters or VPN into headquarters before connecting to the cloud service.

Several companies make appliances (virtual or physical) that proxy data leaving an office on the way to a cloud service and encrypt or tokenize it before sending it to the cloud. This allows them to use a cloud service without worrying about data loss—as long as they only intend to access the cloud service from behind that appliance.

4 Apps aren't secure.

Application security has been getting attention for years. In my mind, its importance increases when an application is deployed to a cloud environment, as the application is more exposed.

One of the biggest mistakes an organization can make is to take an existing application and simply deploy it to a cloud without first considering what new attack vectors this move opens up.

When possible, an application should be re-architected for cloud deployment—this allows parts of the application to scale independently, and to be more distributed and resilient. It's really an opportunity to make an application more secure than ever. Forcing a development team to not use the corporate firewall as a crutch will result in a solid application.

Application security can be a complicated topic, but here are my crib notes: Never trust user input, and always encode output back to the user. Getting those two things right will remove about 80 percent of application security issues.

After input and output are taken care of, next up is proper authentication and authorization. These should be checked on every page or service request, not just at initial login. Ideally, any administrative functions are run through a separate application, so if a malicious user does compromise an account, the most he can get is a single user's data, not admin access.

The last big thing to consider is data encryption: For performance reasons, most organizations don't want to encrypt all data, so the trick is to find the balance of encrypting enough sensitive information so that if you get compromised, data cannot be pieced together to provide useful identification.

5 Authentication and authorization must be more robust.

Of all the problems covered in this article, cloud authentication and authorization has the greatest number of commercial solutions available. This does not mean the issue is easily solved, however. Every organization has its own way to manage authentication and authorization.

First, it must determine if its current authentication system could also work in a secure and reliable way for users in a cloud environment. If the answer is yes, the follow-up question is whether that is also the best way to authenticate cloud services.

Also worth considering: Does every cloud service the organization uses need to be authenticated by the same system?

There is a lot of policy that a company must define to settle the cloud authentication and authorization issue.

Policy aside, any authentication system must be very flexible—whether it integrates with an enterprise's active directory or is standalone, security administrators must be able to easily add support for new services, which may have different authentication schemes and group memberships.

It is crucial that the authentication system fits into the company's aforementioned visibility plan. There's no reason not to know very quickly of a series of failed authentication attempts.

Discussing how to respond to those failures will be left for another day.