In a purely Public Cloud model, infrastructure security is provided by the CSP (Cloud Service Provider). To be successful, the CSP must have robust security and be transparent regarding security processes, procedures and capabilities, as a single security breach has the potential to destroy the CSP's reputation.

Note:
This document is part of a collection of documents that comprise the Reference Architecture for Private Cloud document set. The Reference Architecture for Private Cloud documentation is a community collaboration project. Please feel free to edit this document to improve its quality. If you would like to be recognized for your work on improving this article, please include your name and any contact information you wish to share at the bottom of this page.

However, your organization cannot ignore security, even when the CSP appears to control the entire stack. You must ensure that a number of factors are considered:

People Considerations

• You should assign an individual or team to assess CSPs and perform a comparative analysis.
• You should assign an individual or team to negotiate contracts and service level agreements (SLAs).
• You should assign an individual or team to continuously monitor the security status of the CSP before and after adopting the CSP's services.

Process Considerations

• Properly assess the CSP. Check that the vendor holds industry certifications such as SAS 70 Type II and ISO/IEC 27001:2005. Put in place processes to evaluate new considerations and certifications and to stay abreast of developments in the cloud computing arena.
• Verify that you have contracts that include clearly defined SLAs to ensure security levels are met and maintained. SLAs should have absolute requirements such as all data being encrypted when sent over the Internet and when on the disk. They should also have measurable requirements such as four 9s (99.99%)availability, since availability is part of the CIA definition of security. There should be clauses in the contract defining the penalties for failing to deliver on the security stipulations in the SLAs. Security failures could have serious repercussions for the organization, potentially releasing confidential intellectual property. Penalties should for SLA violations should reflect the costs of this damage. The CSP must also meet all levels of compliance and data security that need to be met by the organization and be consistent with, or superior, with current intranet security policies, capabilities and controls. The geographic location of data should be defined in the contract as this could have compliance implications as discussed later.
• You should investigate what practices are put in place to prevent security breaches between the CSPs tenants. Most security concerns relate to exposure to the Internet, however most CSPs run a multi-tenant infrastructure and you should receive assurances that there can be no data leakage between these systems. This assurances must be backed up with detailed technical information on what controls are in place to prevent cross-tenant data leakage.
• You should investigate whether the CSP uses third party vendors and, if so, what practices it has in place to ensure that the third party meets the SLAs and other standards and compliance measures. Also, investigate what practices the CSP has in place in the event of a failure of the third party systems and confirm that your contract with the CSP clearly state which entities are responsible for indemnifying your firm in the event of a costly security event.
• Ensure that your organization meets and maintains all of the cloud vendor's best practices. Failure to do so could adversely affect security and invalidate contracts. Require that the CSP provide explicit information regarding what security and availability controls are available to you, as well as their best practices recommendations on how to implement the avialable controls.

Technology Considerations

• Encrypt all traffic over the Internet and if possible, when data is on disk at the CSP.
• You should apply your own data encryption where possible rather than relying on the cloud vendor's encryption. Some systems such as Amazon EBS (Elastic Block Storage) do not offer encryption, while others, such as Microsoft Windows Azure do, however, with either system it is advisable to use your own encryption for sensitive data. Your ability to control on disk encryption will vary, and may require that you use technologies that provide Rights Management Services on file based data.
• Ensure you have a monitoring and logging process in place, which, among other checks, validates the security levels of the cloud vendor, informs you as to who attempted to access a file, and who actually opened and read a file.

There are Public Cloud offerings for software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS), all of which can be instantiated in a Public Cloud. With PaaS the organization must take responsibility for securing their applications and for IaaS the organization must secure the software platforms (operating systems) and development platforms, as well as applications that run in the operating system and development platform contexts.

REFERENCES:
SaaS, PaaS, and IaaS: A security checklist for cloud models

ACKNOWLEDGEMENTS LIST:
If you edit this page and would like acknowledgement of your participation in the v1 version of this document set, please include your name below:
[Enter your name here and include any contact information you would like to share]

Return to Previous Page

Return to Cloud Computing Security Architecture

Return to Reference Architecture for Private Cloud