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

Grazed from CSOOnline.  Author: Mark O’Neill.

How does security apply to Cloud Computing? In this article, we address this question by listing the five top security challenges for Cloud Computing, and examine some of the solutions to ensure secure Cloud Computing.

Organizations and enterprises are increasingly considering Cloud Computing to save money and to increase efficiency. However, while the benefits of Cloud Computing are clear, most organizations continue to be concerned about the associated security implications. Due to the shared nature of the Cloud where one organization’s applications may be sharing the same metal and databases as another firm, Chief Security Officers (CSOs) must recognize they do not have full control of these resources and consequently must question the inherent security of the Cloud. However, it is important to note that Cloud Computing is not fundamentally insecure; it just needs to be managed and accessed in a secure way…

All Cloud Models Are Not the Same

Although the term Cloud Computing is widely used, it is important to note that all Cloud Models are not the same. As such, it is critical that organizations don’t apply a broad brush one-size fits all approach to security across all models. Cloud Models can be segmented into Software as a Service (Saas), Platform as a service (PaaS) and Integration as a Service (IaaS). When an organization is considering Cloud security it should consider both the differences and similarities between these three segments of Cloud Models:

SaaS: this particular model is focused on managing access to applications. For example, policy controls may dictate that a sales person can only download particular information from sales CRM applications. For example, they are only permitted to download certain leads, within certain geographies or during local office working hours. In effect, the security officer needs to focus on establishing controls regarding users’ access to applications.

PaaS: the primary focus of this model is on protecting data. This is especially important in the case of storage as a service. An important element to consider within PaaS is the ability to plan against the possibility of an outage from a Cloud provider. The security operation needs to consider providing for the ability to load balance across providers to ensure fail over of services in the event of an outage. Another key consideration should be the ability to encrypt the data whilst stored on a third-party platform and to be aware of the regulatory issues that may apply to data availability in different geographies.

IaaS: within this model the focus is on managing virtual machines. The CSOs priority is to overlay a governance framework to enable the organization to put controls in place regarding how virtual machines are created and spun down thus avoiding uncontrolled access and potential costly wastage.

The following check-list of Cloud Security Challenges provides a guide for Chief Security Officers who are considering using any or all of the Cloud models. Note, some of these issues can be seen as supplementing some of the good work done by the Cloud Security Alliance, in particular their paper from March 2010 Top Threats to Cloud Computing [PDF link].

For CSOs focused on PaaS

Challenge #1: Protect private information before sending it to the Cloud

There are already many existing laws and policies in place which disallow the sending of private data onto third-party systems. A Cloud Service Provider is another example of a third-party system, and organizations must apply the same rules in this case. It’s already clear that organizations are concerned at the prospect of private data going to the Cloud. The Cloud Service Providers themselves recommend that if private data is sent onto their systems, it must be encrypted, removed, or redacted. The question then arises "How can the private data be automatically encrypted, removed, or redacted before sending it up to the Cloud Service Provider". It is known that encryption, in particular, is a CPU-intensive process which threatens to add significant latency to the process.

Any solution implemented should broker the connection to the Cloud Service and automatically encrypt any information an organization doesn’t want to share via a third party. For example, this could include private or sensitive employee or customer data such as home addresses or social security numbers, or patient data in a medical context. CSOs should look to provide for on-the-fly data protection by detecting private or sensitive data within the message being sent up to the Cloud Service Provider, and encrypting it such that only the originating organization can decrypt it later. Depending on the policy, the private data could also be removed or redacted from the originating data, but then re-inserted when the data is requested back from the Cloud Service Provider.

For CSOs Focused on SaaS

Challenge #2: Don’t replicate your organization in the Cloud

Large organizations using Cloud services face a dilemma. If they potentially have thousands of employees using Cloud services, must they create thousands of mirrored users on the Cloud platform? The ability to circumvent this requirement by providing single sign-on between on-premises systems and Cloud negates this requirement.

Users with multiple passwords are also a potential security threat and a drain on IT Help Desk resources. The risks and costs associated with multiple passwords are particularly relevant for any large organization making its first foray into Cloud Computing and leveraging applications or SaaS. For example, if an organization has 10,000 employees, it is very costly to have the IT department assign new passwords to access Cloud Services for each individual user. For example, when the user forgets their password for the SaaS service, and resets it, they now have an extra password to take care of.

By leveraging single sign-on capabilities an organization can enable a user to access both the user’s desktops and any Cloud Services via a single password. In addition to preventing security issues, there are significant costs savings to this approach. For example, single sign-on users are less likely to lose passwords reducing the assistance required by IT helpdesks. Single sign-on is also helpful for the provisioning and de-provisioning of passwords. [Editor’s note: Also read Role management software—how to make it work for you.] If a new user joins or leaves the organization there is only a single password to activate or deactivate vs. having multiple passwords to deal with. In a nutshell, the danger of not having a single sign-on for the Cloud is increased exposure to security risks and the potential for increased IT Help Desk costs, as well the danger of dangling accounts after users leave the organizations, which are open to rogue usage.

For CSOs focused on PaaS

Challenge #3: Keep an Audit Trail

Usage of Cloud Services is on a paid-for basis, which means that the finance department will want to keep a record of how the service is being used. The Cloud Service Providers themselves provide this information, but in the case of a dispute it is important to have an independent audit trail. Audit trails provide valuable information about how an organization’s employees are interacting with specific Cloud services, legitimately or otherwise!

The end-user organization could consider a Cloud Service Broker (CSB) solution as a means to create an independent audit trail of its cloud service consumption. Once armed with his/her own records of cloud service activity the CSO can confidently address any concerns over billing or to verify employee activity. A CSB should provide reporting tools to allow organizations to actively monitor how services are being used. There are multiple reasons why an organisation may want a record of Cloud activity, which leads us to discuss the issue of Governance.

For CSOs focused on IaaS

Challenge #4: Governance: Protect yourself from rogue cloud usage and redundant Cloud providers

The classic use case for Governance in Cloud Computing is when an organization wants to prevent rogue employees from mis-using a service. For example, the organization may want to ensure that a user working in sales can only access specific leads and does not have access to other restricted areas. Another example is that an organization may wish to control how many virtual machines can be spun up by employees, and, indeed, that those same machines are spun down later when they are no longer needed. So-called "rogue" Cloud usage must also be detected, so that an employee setting up their own accounts for using a Cloud service is detected and brought under an appropriate governance umbrella.

Whilst Cloud Service providers offer varying degrees of cloud service monitoring, an organization should consider implementing its own Cloud service governance framework. The need for this independent control is of particular benefit when an organization is using multiple SaaS providers, i.e. HR services, ERP and CRM systems. However, in such a scenario the CSO and Chief Technology Officer (CTO) also need to be aware that different Cloud Providers have different methods of accessing information. They also have different security models on top of that.

Some use REST, some use SOAP and so on. For security, some use certificates, some use API keys, which we’ll examine in the next section. Some simply use basic HTTP authentication. The problem that needs to be solved is that these cloud service providers all present themselves very differently. So, in order to use multiple Cloud Providers, organizations have to overcome the fact they are all different at a technical level.

Again, that points to the solution provided by a Cloud Broker, which brokers the different connections and essentially smoothes over the differences between them. This means organizations can use various services together. In situations where there is something relatively commoditized like storage as a service, they can be used interchangeably. This solves the issue of what to do if a Cloud Provider becomes unreliable or goes down and means the organization can spread the usage across different providers. In fact, organizations should not have to get into the technical weeds of being able to understand or mitigate between different interfaces. They should be able to move up a level where they are using the Cloud for the benefits of saving money.

For CSOs focused on SaaS, PaaS and IaaS

Challenge #5: Protect your API Keys

Many Cloud services are accessed using simple REST Web Services interfaces. These are commonly called "APIs", since they are similar in concept to the more heavyweight C++ or Java APIs used by programmers, though they are much easier to leverage from a Web page or from a mobile phone, hence their increasing ubiquity. "API Keys" are used to access these services. These are similar in some ways to passwords. They allow organizations to access the Cloud Provider. For example, if an organization is using a SaaS offering, it will often be provided with an API Keys. The protection of these keys is very important.

Consider the example of Google Apps. If an organization wishes to enable single sign-on to their Google Apps (so that their users can access their email without having to log in a second time) then this access is via API Keys. If these keys were to be stolen, then an attacker would have access to the email of every person in that organization.

The casual use and sharing of API keys is an accident waiting to happen. Protection of API Keys can be performed by encrypting them when they are stored on the file system, or by storing them within a Hardware Security Module (HSM).

Conclusion: Homemade or Off-the-shelf?

When implementing a security framework to address these challenges, the CSO is faced with a buy vs. build option. They could engage developers to put together open source components to build Cloud Service Broker-like functionality from scratch. This approach creates the runtime components of a broker, such as routing to a particular Cloud Service Provider. However, other components of the solution, such as reporting and an audit trail, may not be present. An off-the-shelf Cloud Service Broker product will provide these extra features as standard and should also provide support for all the relevant WS-Security standards at a minimum.

As the Cloud Security Alliance notes in its Security Guidance White Paper. "Cloud Computing isn’t necessarily more or less secure than your current environment. As with any new technology, it creates new risks and new opportunities. In some cases moving to the cloud provides an opportunity to re-architect older applications and infrastructure to meet or exceed modern security requirements. At other times the risk of moving sensitive data and applications to an emerging infrastructure might exceed your tolerance." I hope this article provides sufficient data points to guide readers on their journey.