When I ask a customer or a partner if they are ready to move to the cloud, I see a wrinkled brow. When I say security, either a look of fear crosses their face or their eyes glaze over. I am almost always speaking to a very technical audience. Confusion, fear and frustration aside, cloud is happening now — to such an extent that the federal government has issued a Federal Cloud Computing Strategy and said that cloud computing is a “profound economic and technical shift ... .”
What complicates the cloud security issue is that different cloud architectures raise different questions which lead to different answers. A silver bullet for cloud security does not exist. One must take into consideration whether you are dealing with a private, hybrid or public cloud. In a traditional data center, the goal is to keep the bad guys out. In a cloud, you do not have a traditional perimeter to defend (i.e., a moat around your data center). Therefore defending your territory is much more difficult. In the cloud, your exposures multiply and risks are increased. In a data center, you own the servers (and virtual machines if you choose to virtualize). In a cloud, you usually lease the servers and virtual machines. In most cases, you only control the virtual machines. This causes great anxiety when determining how and when to move the cloud. Your control over the environment in the cloud is greatly reduced, which leads to risk and exposure.
Three Main Architectures
So how do you resolve this loss of control, while still feeling good about migrating services and applications to a secure cloud?
When facing a decision of migrating software or services to the cloud, the first order of business is to seek out best practices and experts. One of the best resources for cloud computing best practices is guidance provided by experts engaged by the federal government at The National Institute of Standards and Technologies (NIST).
NIST has published numerous reports on cloud computing and cloud security. Many of the leading reports can be found at NIST’s website (nist.gov). In addition, with a quick search query and a phone call, you will likely be able to interview numerous consulting agencies as to how they can best serve your needs by
securing your data, software, services and applications in your cloud of choice.
NIST defines six different types of cloud architectures. However, these different architectures are variations on a theme of private, hybrid or public cloud. The variations include whether the servers, hypervisors, operating systems, virtual machines or cloud are on-premises, off-site or a multi-tenant/shared community. In each circumstance, cloud security will be handled differently.
For many considering a migration to the cloud, private clouds are a welcome relief because the loss of control is mitigated to the greatest degree. Private clouds generally are defined by NIST and Wikipedia as cloud infrastructure operated and dedicated to a single tenant. The servers and the virtual machines are not shared with any other organization. This makes private clouds typically the most secure and usually the first step for an enterprise to the cloud. In some cases, you may even own the servers; the virtual machines and the cloud may even be located inside your data center. If this is the case, then the security architecture is similar to a traditional data center in terms of “defending the perimeter.” However, depending upon how much control you cede to the cloud provider (or managed service provider) for a private cloud, instead of taking direct responsibility for cloud security, you may end up auditing or reviewing your cloud provider’s security practices to ensure your software, services, applications and data are secure.
According to NIST, a hybrid cloud is defined as two or more independent facilities bound together, such as an on-premises data center bound to private or public cloud infrastructure. In a hybrid cloud, you face a dual approach to security. As previously mentioned, you can protect your data center infrastructure in the traditional approach — “secure the perimeter.” But you cannot treat your bound private cloud or public cloud infrastructure with the same security approach. You must define the type of cloud infrastructure you have architected. What is it that you are protecting? Are you protecting just the virtual machines as described earlier? Or is there more, such as the hypervisor or the OS? Who is responsible for the firewalls? What about the application stacks? Who is going to be responsible for updates on the app stacks? Do you monitor your own app code? Will you have to manually track all of these activities? Is it automated? You do not need to know all of these answers, but someone has to be able to answer them.
Using a public cloud raises different security questions than does using a private or hybrid cloud. If you are reselling Google Apps, IBM’s Lotus Live, Microsoft’s Office365, HP or Oracle (or any other large company’s software or cloud services), then you probably are thinking you don’t have to worry about security since that is their problem. You take it for granted that they have it covered. To some extent, this may be perfectly reasonable, especially when dealing with household. However, many of the questions in the previous section on private cloud can and should also be posed to your public cloud provider.
At some point, just letting the large software or cloud provider handle cloud security will not be enough if you are dealing with any reasonably sized customer or complex cloud applications that knit together different software products. Selling cloud services is rarely one dimensional and usually multiple vendors are involved. Expect that your customer will demand you answer their cloud and security questions in specific detail. This happens the moment you let them know the cost of such cloud services. Complex cloud security questions arise with even small customers, not always because of their size, but also because of the size of their customer base.
Cloud security cannot to be ignored or taken for granted. Depending upon your cloud of choice, your answers to cloud security will be slightly different. But by following some of the best practices suggested by NIST and by taking a proactive approach to security in the cloud, you will be ready for this profound economic and technical shift to cloud computing securely.
Questions to Ask Cloud Providers About Security
Gaining efficiency and reducing costs are clear benefits driving the movement of IT infrastructure into the cloud, while security is the main worry that prevents it. But asking the right questions can help you to not only reduce your risks, but enable you to control them more effectively than you can with an on-premises IT infrastructure. The business continuity and disaster recovery benefits of geographic distribution may be obvious. Perhaps less obvious is that a provider may be able to use its economy of scale to hire specialized expertise, as well as solve particular problems common to many customers within a particular niche or vertical market. By asking the right questions, you can find a provider with contract terms and SLAs that establish the foundation for a sound and trusted business relationship.
Your first questions should be directed to the customer: What is the nature of the data and services they plan to move to the cloud, and what would be the impact to the business if a breach exposed them to the public, to other customers sharing the same infrastructure or to the provider? The answers to these questions will help you to ask the right questions of the service provider regarding its architecture, deployment models and controls. It is important to keep in mind that your clients’ customers and suppliers are still going to hold them responsible for what happens to information they provide — whether it’s managed in-house or by a third party.
Controls & Governance
The next questions are for the provider, particularly about how it can provide assurance that the client’s requirements are met on an ongoing basis.
What visibility will you have into the effectiveness of the security controls of the solution? What logs and reports will you (and your auditors) be able to access? What certifications are held by the provider, and are there any audit reports which you can review? Do you have any audit rights?
What SLAs are provided and are they negotiable? What remedies are offered in the event that SLAs are not met?
Insight into the overall security stance of the provider, and its compatibility with your client’s, may be gained by asking open-ended questions about the provider’s security controls — namely, what are they? An answer in vague generalities is less acceptable than specifics, which make reference to particular security standards and frameworks, and a few such references is less acceptable than an ability to offer details about what is actually in place to meet them. A provider with an SSAE 16 audit of their data center is better than one without. Better still is a provider who can provide you with the appropriate type of Service Organization Control (SOC) report for the service being provided (SOC 1 for financial auditors, SOC 2 IT auditors, SOC 3 for more general audiences) and (for SOC 2/3) covering the relevant Trust Services Principles for the type of data and service involved.
What certifications has its staff earned? Does the provider employ dedicated security staff with industry certifications, as well as engineers with vendor-specific certifications? Does the provider also employ business process people with ITIL or ISO 20000 knowledge? How does the provider do change management?
The data your client stores in the cloud may be sensitive proprietary information, or it may include personally identifiable information subject to breach laws or other regulatory requirements. You need to ask questions about how that data is protected. How is it secured in transit, both en route to and from the provider, as well as when it moves within a virtual environment? How is it secured at rest? Is encryption used, and how are keys managed? Are there solutions available where you control the keys, so that the data is not visible to the provider? What controls protect your data from unauthorized modification or destruction? How are security profiles associated with the data maintained when the data moves from one environment to another? How is data destruction ensured when the data is removed or upon termination of the contract? Do you retain ownership and control over the data so that you can remove it in a usable, portable form for use with another provider?
Identity & Access Management
Your client’s data in the cloud environment will need to be used in some way, directly or indirectly, by individual users. How will the provider authenticate those users and monitor their activity? Ideally, you want to reduce the complexity of user management, perhaps by using a form of federated identity based on SAML (such as Active Directory Federation Services) or OpenID, which can also help with visibility. What mechanisms are available to control access for authorized users to cloud resources, at what level of granularity and with what audit trails?
In the last several years, reports of major breaches at prominent companies have made it more and more evident that preventive controls are never sufficient. It is no longer a question of whether your organization will suffer a breach, but when and how quickly you will notice and respond. The importance of detective and corrective controls, as well as having a strong incident response capability, cannot be underestimated. You’ll want such capabilities from the cloud service provider, and some open-ended questions will help set the stage. What are your incident response capabilities? Have you had any breaches, and, if so, what did you do? Both of these are great initial questions. It’s important to ask about change management (again) and configuration management — how does the provider recognize when unauthorized changes occur? A provider that is unwilling to talk about such details is probably unsuitable as a trusted partner managing your most critical data.