Many enterprise IT departments list cloud security as a major concern in adoption; however, security is just one boundary to mainstream implementations. IT teams must take into account cloud security and compliance and other risks when examining a cloud service provider.
In this chapter excerpt from Cloud Computing: Assessing the Risks, authors Jared Carstensen, Bernard Golden and J.P. Morgenthal discuss what cloud consumers need to consider in terms of security, compliance and risk, how these considerations affect cloud infrastructure and applications, as well as where the compliance responsibility -- or trust boundary -- lies.
Relationship between security, compliance and risk
To understand the interaction between security, compliance and risk, please refer to Figure 1. The figure represents how the three areas together form a whole. Significantly, both security and compliance indicate a boundary within those areas, with both the Cloud provider and Cloud user retaining responsibility for a portion of that area.
When it comes to risk, however, no such boundary exists. This lack of a boundary represents the fact that all service agreements shift primary responsibility for risk to the user. Should a Cloud application fail in availability, cause a financial loss to the Cloud user, or even fail to comply with important compliance requirements, the Cloud provider limits its responsibility significantly, typically to a refund of fees.
This asymmetric risk arrangement may seem unfair -- after all, the Cloud provider's decisions and operations may cause a failure in compliance, which results in a financial penalty (i.e. a risk outcome borne by the Cloud user). So why should the financial responsibility be applied to the Cloud user instead of the Cloud provider which caused the compliance failure?
Despite this perception of unfairness, this careful assignment of risk responsibility to the Cloud user is universal throughout the Cloud Computing world. Individual Cloud providers may have slight differences among what they will provide in compensation for service failures; for example, one provider may offer a credit for service unavailability on a one-to-one basis (i.e. if the service is down for one hour, the Cloud user will receive one hour's credit to the monthly service cost), while another will refund a week's service costs for an outage of one hour. Despite these differences, though, every provider limits its financial exposure to service unavailability.
It's important to understand that this risk limitation is not unique to Cloud Computing. Outsource providers (e.g. firms that take over operating a company's IT data centre) also limit their financial responsibility in the event of an outage. Therefore, it is important not to regard this risk limitation as a complete restriction on using a Cloud provider, unless, that is, a company regards any risk limitation by a service provider as unacceptable. In that case, the company should continue to operate its own computing environment and forego use of an external Cloud provider.
The important point from this discussion is that when Cloud Computing security is raised as an issue, other issues are often being addressed. It's important to distinguish what type of issue is of concern, as that will change the method of evaluating the issue, the demarcation of the trust boundary and the appropriate actions to be taken by the Cloud user.
To help distinguish which issue is being evaluated and how to identify the trust boundary appropriate for the issue, Figure 1 can be used as an aid.
Understanding the trust boundary
As noted, in the areas of compliance and security, the Cloud user and Cloud provider both hold some of the responsibility. The interface between where one party's responsibility ends and the other begins may be referred to as the trust boundary.
While the existence of a trust boundary intuitively makes sense, two questions arise:
- How can a Cloud user know where the trust boundary lies? After all, the service of a SaaS provider is quite different from that of an IaaS provider. So how can one know where the boundary lies?
- Once the boundary is defined, what can the Cloud user do to verify that the Cloud provider is adhering to its responsibility? In other words, what are the appropriate actions to take to ensure the Cloud provider lives up to its commitments?
One might ask, what does the trust boundary represent? In its basic form, the trust boundary represents a demarcation line: on one side of the line, the Cloud provider possesses responsibility for security measures; on the other, the Cloud user possesses responsibility.
For example, in an IaaS environment, it is clear that the Cloud provider has responsibility for physical security of the computing facility. It is also clear that the Cloud user is responsible for the application code.
On the Cloud provider's side, it is in control of what security practices are followed; the Cloud user can only audit what information about those practices the Cloud provider offers and evaluate whether the practices are sufficient for the user's needs. On the user's side of the trust boundary, the Cloud user can determine what the correct security practices are and can take active steps to implement those practices.
In short, on the Cloud provider's side of the trust boundary, the user is a passive assessor of what the Cloud provider implements in terms of security practices. On the Cloud user's side of the trust boundary, the user is an active implementer of security practices.
This excerpt and the original document it is taken from are both subject to ITG copyright and may not be reproduced in any format, without prior written consent from the publisher.