Leslie Fife - The Official (ISC)2 CCSP CBK Reference

Cloud computing is not always the correct solution. Which is the correct solution is a business decision guided by a cost-benefit analysis. Cloud computing benefits include reduced capital costs as the individual customers no longer have to buy the hardware and system software that the CSP provides. The lowered capital expenses are offset by higher operating costs, as the customers must pay for the services used.

In many countries, capital expenses and operational expenses are treated very differently for tax purposes. For example, capital expenses may be written off or depreciated over a number of years. To write off the entire business of expenses of new infrastructure, purchased and installed on-premise could take many years. Operational expenses, such as the cost of cloud computing, can usually be written off as a business expense in the year the expense is incurred.

The business must understand the cost and tax implications of moving to the cloud or investing in on-premise infrastructure to make the choice most beneficial to the business. A move to the cloud may be as much (or more) for financial reasons than technical ones. This move should be considered only if the benefits justify the cost or if the benefits lower the costs.

Functional security requirements can make the move to cloud computing or the governance of cloud computing safer for a customer's information and processes. However, there remains some challenges with cloud computing, including portability, interoperability, and vendor lock-in.

These challenges can be lessened through the use of a vendor management process to ensure standard capabilities, clearly identifying the responsibilities or each party and the development of SLAs as appropriate. For complex or expensive systems, the RFP process can be utilized to clearly state customer requirements. The security requirements should be part of the requirements specified in the RFP and can be part of the process of choosing a vendor. A vendor that cannot meet the customer's security needs can be eliminated early on.

One-time movement is when a customer moves to a cloud platform, with no intention of moving it again. This is not common. In a modern environment, movement to and from the cloud as well as between cloud services and CSPs is much more common. These movements are not simply a forklift operation where you pick up some on-premises solution and data and drop it into a cloud account. Each CSP uses different tools and templates. So, a move from one CSP to another requires mapping to the other with the associated data cleanup. Moving from your own infrastructure to a CSP has the same challenge.

Frequent movement between CSPs and between a CSP and your own infrastructure is significantly more difficult, and data can be lost or modified in the process, violating availability and integrity rules. Portability means that the movement between environments is possible. Portable movement will move services and data seamlessly and may be automated.

The movement of data between software products is not a new issue. It can be complicated in the cloud by the need to continue paying for the old service while porting to the new one. This puts time pressure on the porting.

With customers using a variety of cloud services, often from different vendors, interoperability is an important consideration. In addition, some situations may require a private cloud sharing data with an on-premises solution. The ability to share data between tools and cloud environments and between clouds and corporate infrastructure is important. One issue is that the security tools and control sets differ between CSPs. A gap in security may result. Careful planning is essential, and the services of a cloud broker may also be warranted.

One way to improve the situation is through application programming interfaces (APIs). If properly designed, the API can bridge the security gap between services and allow the sharing of data and processes across multiple platforms. For example, if a SaaS tool is used to build a data inventory and supports the corporate data/system classification scheme, an API could be built to securely share that information with the governance, risk management, and compliance (GRC) or system inventory tool. This creates a single source for data, sharing it with relevant systems, and removes the potential of multiple data classification in different systems.

Solving the interoperability and portability challenges will go a long way toward ending vendor lock-in. This occurs when a customer is tied to a specific CSP and moving would incur significant costs including financial, technical, and legal. Vendor lock-in remains a significant concern with cloud computing. Continued advances in virtualization, improvements in portability and interoperability, and a careful design within a reference architecture have decreased this issue.

An additional concern is the use of CSP-specific services. If these are used to build capabilities, moving to a new CSP also impacts this additional capability. This is similar to using nonstandard features of a compiler in the development process. It locks you into that development environment.

One example is the use of AWS CloudTrail. CloudTrail allows auditing of your AWS account in support of governance, risk management, and compliance. If the decision is made to move away from AWS, the GRC functionality will have to be rebuilt with new services, either with the new CSP or with another vendor.

With additional improvements and careful architecture, vendor lock-in should become an issue in the past. Until then, the security challenges of cloud computing in general, and portability and interoperability in particular, remain.

In a cloud environment, security responsibilities are shared between the service provider and the customer. In the SaaS model, the customer has the least responsibility, and in the IaaS model, the customer has the most responsibility. In a PaaS, the responsibility is shared more equally.

The Shared Responsibility Model for cloud services is commonly presented by the major vendors, which are all similar. There is an architecture stack. Some items in the stack are the responsibility of the CSP, and some are the responsibility of the customer. In between, there is an area of varied responsibility. At times, this middle area is the responsibility of the CSP and sometimes of the customer and sometimes both. It is important for the customer to know their responsibilities, especially in this middle region.

A typical architecture stack looks like this:

Data

APIs

Applications/solutions

Middleware

Operating systems

Virtualization (VMs, virtual local area networks)

Hypervisors

Compute and memory

Data storage

Networks

Physical facilities/data centers

It is generally understood that the CSP is responsible for the last five items on the list in all delivery models. However, where the line between customer and CSP exists varies beyond that.

The exact split and layer names vary by vendor, but the general principle remains the same. Both the CSP and the customer have some individual security responsibilities, and along the line where these meet, each may have some security responsibilities. The line for each delivery model is explained in the following sections.

From a security standpoint, you have limited security options with a SaaS solution. Most of the security options are provided by the SaaS provider. The SaaS provider is responsible for the security of the infrastructure, operating system, application, networking, and storage of the information on their service.