Cloudop security

Editor's Notes

• #7: IaaS includes the entire infrastructure resource stack from the facilities to the hardware platforms that reside in them. Further, IaaS incorporates the capability to abstract resources (or not) as well as deliver physical and logical connectivity to those resources. Ultimately, IaaS provides a set of API’s which allows for management and other forms of interaction with the infrastructure by the consumer of the service. PaaS sits atop IaaS and adds an additional layer of integration with application development frameworks, middleware capabilities and functions such as database, messaging, and queuing that allows developers to build applications which are coupled to the platform and whose programming languages and tools are supported by the stack. SaaS in turn is built upon the underlying IaaS and PaaS stacks and provides a self- contained operating environment used to deliver the entire user experience including the content, how it is presented,
• #9: Private Clouds are provided by an organization or their designated service provider and offer a single-tenant (dedicated) operating environment with all the benefits and functionality of elasticity and the accountability/utility model of Cloud. The physical infrastructure may be owned by and/or physically located in the organization’s datacenters (on-premise) or that of a designated service provider (off- premise) with an extension of management and security control planes controlled by the organization or designated service provider respectively. Public Clouds are provided by a designated service provider and may offer either a single-tenant (dedicated) or multi-tenant (shared) operating environment with all the benefits and functionality of elasticity and the accountability/utility model of Cloud. The physical infrastructure is generally owned by and managed by the designated service provider and located within the provider’s datacenters (off-premise.) Managed Clouds are provided by a designated service provider and may offer either a single-tenant (dedicated) or multi-tenant (shared) operating environment with all the benefits and functionality of elasticity and the accountability/utility model of Cloud. The physical infrastructure is owned by and/or physically located in the organization’s datacenters with an extension of management and security control planes controlled by the designated service provider. Hybrid Clouds are a combination of public and private cloud offerings that allow for transitive information exchange and possibly application compatibility and portability across disparate Cloud service offerings and providers utilizing standard or proprietary methodologies regardless of ownership or location. This model provides for an extension of management and security control planes
• #15: Security concerns have been the top factor cited as delaying cloud adoption for the past several years. In part this is due to a lack of standards around testing, reporting, SLAs and other standard business agreements that have already been worked out in more mature markets (like hosting). Another major factor is that the terms used with cloud-computing can have very different meanings based on context and so discussing cloud security can be tricky without laying down some ground work as far as definitions and context.
• #28: Public deployments have the advantage of leveraging the service provider’s experience, security budget, process & procedure at a minimal cost to the consumer, however, if a provider doesn’t offer a security feature that is critical to your deployment you’re pretty much out of luck. Annonimizing effect: Being a small fish in a large ocean makes targeted attacks against your infrastructure very difficult to orchestrate. This is amplified by the transitory nature of IP addressing in most IaaS provider offerings. PaaS & SaaS offerings take this further by providing such massively scaled systems that the cost of producing a successful attack can outweigh the potential benefits. Collateral Damage: Attacks against the overall cloud provider or against specific systems sharing the same physical infrastructure as yours can lead to collateral damage from attacks not directly targeted at your organization. The “VM Next Door” (same processor, same network segment, etc…) may be a bad actor of the target of one. Cloud providers are high value targets that present a large attack surface on public networks. This coupled with other items in this list such as the global scope of vulnerabilities can have a huge impact when doing a risk assessment for public cloud deployments. Large Security Investments: Public cloud providers have dedicated security teams, battle tested policies and procedures and more advanced security tools than most organizations can afford. This plays into the major economic motivators for public cloud adoption which is leveraging the expertise and budget of the cloud provider. Data & AAA security: Keeping secure data on a multi-tenant, non-isolated system requires additional planning and resources than keeping it in a private data store. You need to work how & when to encrypt data as well as how to manage access to that data. Managing AAA (Authentication, authorization & accounting) functions can be more challenging in a public cloud deployment. The lack of multi-user role based access controls in most IaaS & PaaS offerings makes managing access to underlying system controls challenging. However, the SOA oriented nature of public cloud services generally means you get a standardized method of accessing, collecting and acting upon AAA data. Pre-certification: Public cloud providers continue to amass different security certifications as well as guidelines, policies and procedures that can help their clients reach particular certification levels (ie: Amazon’s SAS-70 datacenter certifications). Public cloud providers will probably also become major players in helping shape new certification requirements going forward (ie: The development of new cloud based PCI compliance requirements have been announced) Regulatory Compliance & Certifications: While “pre-certification” is in the advantages column, it is a double edged sword with public cloud providers. If a cloud provider does not have a particular certification you require, or does not provide a report or feature you require to attain a certification or compliance, the likelihood of being able to influence their feature sets is minimal. Multi-site system & data redundancy: The automated sharding and distribution of data and workloads to multiple sites is major benefit of public cloud deployments. The cost and ease with which this is accomplished within public clouds is a major factor favoring their adoption. Multi-jurisdiction data store: The flip side to automated data replication to multiple geographic sites is that your data will most likely end up in multiple legal jurisdictions either in whole or in part. You may not even know which jurisdictions your data is in at any time. This can pose serious problems achieving certain regulatory requirements (Ie: EU Data Protection Directive, US Safe Harbour program). Additionally, you may not know when legal actions (ie: foreign data supoenas) have been issued against your data. Having data in multiple jurisdictions also has implications for legal data ownership & recovery issues. Fault tolerance & excess capacity: The automated systems and APIs used by IaaS, Paas & SaaS providers has allowed for the creation of incredibly fault tolerant systems, from autoscalling instances in EC2 to the total cloaking of the hardware & network layers in AppEngine and SalesForce.com. In terms of excess capacity public cloud providers allow you to scale to continue providing service in the face of DoS attacks, they also provide amazing resiliency and RESTORATION OF SERVICES following an attack or other security incident. Know vulnerabilities are global: This related back to the “Collateral Damage” item in that once a vulnerability in your public cloud provider’s infrastructure is discovered, it will generally affect all accounts. We have already seen this with several SaaS providers such as Google Apps.
• #29: Externalization of attack surface: By placing the public side of your application in a public cloud, you can deflect attacks from your corporate environment to the cloud provider who may be bettr suited to dealing with them or mitigating them. Data Transfer & Access Considerations: Though has to be given to how data is transferred into out of the public cloud. What are the security requirements? If you have access controls inplace internally, how do you extend those AAA functions to the public cloud? Private cloud scaling limits: Hybrid scenarios offer the promise of allowing private clouds to “spill-over” excess compute requirements into a public cloud as required. In reality these types of hybrid systems are very difficult to implement today, however temporarily moving certain workloads between private clouds and public clouds for special events can provide enormous ROI. Increase architectural complexity: Marshalling and managing separate AAA systems, data transfers and application communications between private infrastructure and public clouds can be tricky and requires lots of planning. Multi-site system & data redundancy: Hybrid solutions also promise to allow corporations to quickly implement disaster recovery and business continuity plans. The costs associated with having a hot or warm standby secondary site are more complicated than in a pure public cloud deployment yet quite more cost effective than with a private cloud deployment. Credential Management: Managing access to the public cloud APIs as well as managing inbound traffic from application components hosted in a public cloud can be daunting. Can you validate that inbound messages to your private cloud actually originate from your own systems in the public cloud? Isolation & segregation: Hybrid cloud deployments allow corporations to maintain control over the isolation and segregation of their most sensitive data while still providing many of the benefits inherit in a public cloud. Regulatory compliance: This can be trickiest in the hybrid model as requirements may span both your corporate systems and those of your cloud provider partners. More on regulatory compliance below.
• #30: Redundancy & Availability: by partnering with organizations that share similar requirements, goals & data organizations can build clouds that provide many of the redundancy aspects offered by public clouds yet make sure that the overall security posture and feature set meets their needs. Complexity: More organizations = more complexity. Negotiations on requirements can be a major stumbling block. Shared risk & security costs: by pooling security resources among several organizations, community clouds are able to offer security features and services that a single organization might not be able to afford. Federation requirements: Mapping role based access controls to users and interconnecting disparate corporate directory service and AAA systems can be extremely time consuming but can add a level of flexibility for security arrangements between partners that are unavailable in other cloud models. Compliance requirements: Members of a community cloud deployment can ensure that “their cloud” meets their particular regulatory and certification requirements. Ie: HIPPA, SoX, PCI-DSS, etc.. Increased privilege user attacks: Depending on the cloud and application architecture, many more people may have direct access to your organizations data in a community cloud model. This leads to the increased possibility of privileged user attacks. Easy targeting: Community clouds can be a treasure trove for malicious actors looking for specific information. You cannot hide behind the annonimity of public clouds to avoid targeted attacks against your organization or data “types”.
• #31: Increased control of encryption: IaaS is the only cloud model that allows you to fully dictate when and how data gets encrypted before being committed to persistent storage. Account hijacking: Hijacking of cloud account credentials can place the “keys to the kingdom” in an attackers hand. Given the low levels of security generally required for exercising cloud account privileges this can be a major issue. Also changing cloud account credentials in an IaaS model can be more difficult than with other models. Minimized privileged user attacks: Due to the increased low level controls compared to other cloud service models, IaaS provides the least vulnerability to privileged user attacks. Ability to use familiar AAA mechanisms: Since IaaS clouds are providing familiar VMs, you can leverage your existing knowledge of how to secure and manage them. API security risks: Think about a private enterprise datacenter and all the layers of security you would need to transverse to shutdown a system from a remote location (2 factor VPN authentication, bastion host login, corporate directory credential authorization, ssh authentication, sudo restrictions, etc…). NOW, think about what it takes to remotely shutdown a system on EC2 or in Azure remotely. A simple API call from any internet enabled device. More standardized deployments: IaaS provider best practices and methodologies force, guide and cajole system engineers to rely on automated deployment systems. This leads to a much more standardized deployment and change management process. Lack of role based authorization: Many IaaS providers still do not provide mechanisms for restricting which systems different operations staff can access or control via API in a granular manner. Rapid cross vendor redeployment: Again due to the fact that IaaS clouds are providing well know OS VMs moving functionality between cloud providers is relatively easy (barring data transfer costs) Dependence on security of the virtualization platform: IaaS vendors rely on the security features of the hypervisor or virtualization software to provide security controls. Vulnerabilities in these cloud building blocks can impact all cloud provider customers. Full operational control at the VM level: Your organization maintains full control over your systems from the VM level upwards. Full responsibility for operations: Even though you have no control over the physical infrastructure or the network, your IT team is still responsible for the security and operations of your production systems. If a PaaS or SaaS provider has an outage you can’t be held responsible, if a IaaS provider has an outage, it was up to you to plan for that eventuality.