Cloud Security Recommendations

DZone 's Guide to

Cloud Security Recommendations

· Cloud Zone ·
Free Resource
Only seven months after their first security guide, the Cloud Security Alliance (CSA) released a second document: The Security Guidance for Critical Areas of Focus in Cloud Computing Version 2.1.  "Over those seven months our knowledge, and cloud computing technologies, have evolved at an astounding rate," said the CSA editors.  The continuing advancement of cloud computing brings both new opportunities and new security challenges, they say.  The CSA has condensed its original 15 domains of discussion down to 13.  Although new risks keep appearing as the cloud moves ahead, new cloud security solutions are also regularly appearing.  Each domain provides many practical recommendations for a more secure cloud strategy.

Cloud Architecture

Domain 1: Cloud Computing Architectural Framework

This Domain is intended to provide the foundation for the understanding of cloud architectures and the inherent risks in the cloud.  Cloud services exhibit five essential characteristics:
  • On-demand self-service
  • Broad network access
  • Resource pooling
  • Rapid elasticity
  • Measured service
With derivative variations, cloud service deployment models consist of Infrastructure, Platform, and Software as a Service.  IaaS is the foundation of all cloud services, with PaaS building upon IaaS, and SaaS in turn building upon PaaS. In this way, just as capabilities are inherited, so are information security issues and risk.  Clouds can be Public, Private, Hybrid, or Community specific.  Trade-offs between the three cloud deployment models include:

  • SaaS provides the most integrated functionality built directly into the offering, but it has the least consumer extensibility.  However, it has a relatively high level of integrated security for which the provider is responsible.
  • PaaS is intended to enable developers to build their own applications on top of the platform. As a result it tends to be more extensible than SaaS, at the expense of customer- ready features. This tradeoff extends to security features and capabilities, where the built- in capabilities are less complete, but there is more flexibility to layer on additional security.
  • IaaS has enormous extensibility, but tends to have less integrated security capabilities because the operating systems, applications, and content are managed and secured by the cloud consumer.

The key takeaway is that as you move down the stack to the deeper levels like IaaS, more of the security burden is placed on the consumer.  The security responsibilities of both the provider and the consumer greatly differ between cloud service models. Amazon’s EC2 IaaS, for example, includes vendor responsibility for security up to the hypervisor, meaning they can only address security controls such as physical security, environmental security, and virtualization security. The consumer is responsible for security controls that relate to the IT system (instance) including the operating system, applications, and data.  For a SaaS offering like SalesForce.com, the entire ‘stack’ is already provided.  The provider is responsible for the physical and environmental security controls along with the security controls on the infrastructure, applications, and data. Understanding the impact of these differences between service models is essential to managing the risk of cloud computing within an organization.

Governance  Domains

Domain 2: Governance and Enterprise Risk Management

Governance recommendations
  • Invest a portion of the savings obtained by Cloud Computing into increased analysis of the provider's security capabilities.
  • Cloud Computing service customers and providers should develop comprehensive information security governance, regardless of the service or deployment model.
  • Collaborative governance structures and processes between customers and providers are necessary, both as part of the design and development of service delivery, and as service risk assessment and risk management protocols, and then incorporated into service agreements.
  • Security departments should be engaged in the process of establishing Service Level Agreements and contractual obligations to ensure that security requirements are contractually enforceable.
  • Prior to moving into the cloud, an organization should establish metrics and standards for measuring performance and effectiveness of information security management.
Enterprise Risk recommendations
  • Analysis of vulnerabilities and their potential impact on assets should be conducted.  Organizations should also analyze of the probability of risk scenarios, management-approved risk acceptance level, and risk treatment plans.
  • In SaaS, the majority of information will have to be provided by the service provider.  Organizations should structure analytical information gathering processes into contractual obligations of the SaaS service.
  • In PaaS, build in the information gathering and include the ability to deploy and gather information from controls as well as creating contractual provisions to test the effectiveness of those controls.
  • With an IaaS service provider, build information transparency into contract language for information required by risk analysis.
  • Customers should view cloud services and security as supply chain (service provider relationships and dependencies) 

Domain 3: Legal and Electronic Discovery

  • Customers and cloud providers should understand each other’s roles and responsibilities related to electronic discovery, including such activities as litigation hold, discovery searches, who provides expert testimony, etc.
  • Plan for possible termination of the relationship in the contract negotiations, and for an orderly return or secure disposal of assets.
  • Knowing where the cloud service provider will host the data should be a prerequisite to implementing the required measures to ensure compliance with local laws that restrict the cross-border flow of data.
  • Specific security issues must be addressed in the provisions of the service agreement.
  • The cloud services agreement must allow the client or a third party to monitor the service provider’s performance and test for vulnerabilities in the system.
  • The provider and the client should have a unified process for responding to subpoenas, service of process, and other legal requests.

Domain 4: Compliance and Audit

  • Involve Legal and Contracts Teams
  • Require the Right to Audit Clause
  • Analyze Compliance Scope
  • Analyze Impact of Regulations on Data Security
  • Review Relevant Partners and Services Providers
  • Analyze Impact of Regulations on Provider Infrastructure
  • Prepare Evidence of How Each Requirement Is Being Met

Domain 5: Information Lifecycle Management

  • Make sure there is specific identification of all controls used during the data lifecycle.
  • Know where your data is.
  • Understand the compartmentalization techniques employed by a provider to isolate its customers from one another.
  • The data owner determines who should access the data, what their rights and privileges are, and under what conditions these access rights are provided.
  • Understand how encryption is managed on multi-tenant storage.
  • Perform regular backup and recovery tests to ensure that controls are effective.

Domain 6: Portability and Interoperability

  • Understand how VMIs can be captured and ported to new cloud providers, who may use different virtualization technologies.
  • Eliminate or document any provider-specific extensions to the VM environment.
  • When possible, use platform components with a standard syntax such as open APIs and open standards.
  • Understand the impacts on performance and availability of the application when migrating to a new platform.
  • Perform regular data extractions and backups to a format that is usable without the SaaS provider.
  • Understand that any custom tools being implemented will have to be redeveloped upon migration, or the new vendor must provide those tools.

Operational Domains

Domain 7: Traditional Security, Business Continuity, and Disaster Recovery

  • Understand that the centralization of data means there is a risk of insider abuse from within the cloud provider.
  • Cloud providers should think about adopting the most stringent requirements of any customer as a security baseline.
  • Customers should look at the cloud provider's disaster recovery and business continuity plans.
  • Customers should identify physical interdependencies in provider infrastructure.
  • Customers should ask for documentation of the provider’s internal and external security controls, and adherence to any industry standards.

Domain 8: Data Center Operations

  • It's important to obtain a commitment or permission to conduct customer or external third-party audits.
  • All cloud architectures should be able to demonstrate comprehensive compartmentalization of systems, networks, management, provisioning, and personnel.
  • Cloud customers should understand their cloud providers’ patch management policies and procedures. This understanding should be reflected in contract language.

Domain 9: Incident Response, Notification, and Remediation

  • Customers should clearly define and communicate to cloud providers what they consider incidents (such as data breaches) and what they consider mere events (such as suspicious intrusion detection alerts) before service deployment.
  • Customers must understand the prearranged communication paths to the provider’s incident response team.
  • Find a cloud provider with the ability to deliver snapshots of the customer’s entire virtual environment, including firewalls, network (switches), systems, applications, and data.

Domain 10: Application Security

Software Development Lifecycle (SDLC) security should address these three main areas of differentiation with cloud-based development:
  1. Updated threat and trust models
  2. Application assessment tools updated for cloud environments
  3. SDLC processes and quality checkpoints to account for application security changes.
  • IaaS, PaaS, and SaaS have different trust boundaries for the software development lifecycle, which must be accounted for during the development, testing, and production deployment of applications.
  • Securing inter-host communications must be the rule.
  • Keep track of files used for application logging and debugging, as the locations of these files may be remote or unknown and the information could be sensitive.
  • Customers should obtain contractual permission to perform remote vulnerability assessments.

Domain 11: Encryption and Key Management

  • Use encryption to separate data holding from data usage.
  • Assure regulated and/or sensitive customer data is encrypted in transit over the cloud provider’s internal network and encrypted at rest.

Domain 12: Identity and Access Management

  • Customers should avoid proprietary solutions such as creating custom connectors unique to cloud providers, since these solutions make management more complex
  • Enterprises should consider authenticating users via their Identity Provider (IdP) and establishing trust with the SaaS vendor by federation.
  • Enterprises should consider using user-centric authentication such as Google, Yahoo, OpenID, Live ID, etc., to enable use of a single set of credentials that can be used on multiple sites.
  • Enterprises should verify that the provider supports at least one of the prominent standards (SAML and WS-Federation).

Domain 13: Virtualization

  • Identify which types of virtualization your cloud provider uses, if any.
  • Virtualized operating systems should be augmented by third party security technology to provide layered security controls and reduce dependency on a single platform provider.
  • Understand which security controls are in place internal and external to the VM.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}