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.