How Secure is that Cloud Vendor? 7 Basics
All cloud computing vendors will tell you how wonderfully secure their services are. As you evaluate those claims, here are 7 key factors to consider.
Wed, January 26, 2011
CIO — Cloud computing security is an incredibly broad (and deep) topic, so I can only scratch the surface in a short article. Even so, let's try to get the basics under control.
The first order of business is making sure we're talking about the same thing. Some cloud vendors try to blur the lines between security, reliability, and disaster recovery/business continuity. While all these are important attributes, it just confuses the conversation. So let's stick with the standard definitions in this overview.
1. Let's Get Physical
In on-premises systems, Job 1 of security is to make sure that unauthorized people don't get physical access to the machines. If someone can connect foreign hardware, reconfigure the system, or control the system boot cycle, an awful lot of security is out the window. In a cloud-based service, you don't have to worry about this on the server side — that's the vendor's job. While there have been occasional breaches of cloud services over the years, established cloud vendors have pretty tight operations groups — and most of them treat their internal security procedures as highly guarded trade secrets. Which means you won't be able to get much info to evaluate them. With a reputable vendor, it's safe to ignore this issue.
2. Identity Crisis
The next item that must be handled is identity across clouds. The first things to look for are in the area of authentication and authorization: password strength, IP range blacklists/whitelists, login hours, two level authentication...all the stuff you're used to with on-premises systems. Most cloud vendors should have this covered, at least through add-on features or modules.
And of course, there's the too-often-neglected issue of privilege revocation. While this is more a process issue than a systems one, look for features that prompt the administrator (or automatically warn of users who likely need revocation) to make for a tighter ship.
The other side of the coin is making the authorization process less annoying to users: SSO connectors and delegation infrastructure are needed for any practical multi-cloud applications. User account or ID anonymization/obfuscation are particularly important if your applications need to span suppliers or channels in the supply chain.
Encryption is an obvious requirement for cloud applications, and https is the baseline for all user logins and integration connections. Many cloud applications, however, are not built to have the data encrypted within the cloud. Indeed, in some cases it's not even possible to have the cloud data stored in encrypted form. As this poses risks for customer privacy, corporate snooping, and even Fourth Amendment protections, ask your cloud vendors about internal encryption and push for it in their roadmap presentations.
As I wrote in an earlier column, information loss protection (aka data leakage prevention) is a critical issue for business applications. Every year, 80 million consumer identities in the U.S. become compromised due to accidental losses and deliberate attacks. Even if you like WikiLeaks, losing control of business information is something to worry about.
In cloud systems, there are two major risk areas for leaks. The first category is a breach within the cloud vendors — something you have little control over (other than vetting vendors). But you can at least demand as part of your cloud vendor SLA that they notify you of any breach that affects your data.
The second category of breach you do have control over: loss at the end-point. This requires add-on software or hardware for each server, PC, and mobile device that presents or processes data from your cloud application. The goal is to make sure that only authorized data transfers occur, and they must be regulated down to the device and file/object level. Further, use of file encryption and auto-erase (upon loss of control of the device) are required, particularly if your organization has a large field force. While general purpose ILP/DLP products are a good start, there are now some startups offering solutions tailored to the specific needs of cloud-based software.