Securing Cloud Services - A pragmatic guide: Second edition

reading

Part 1: Securing Cloud services – setting the scene

INTRODUCTION

Part 1 provides the foundation for the rest of this book as it introduces the concepts embodied within Cloud computing, describes the associated security threats and lists a few of the existing industry initiatives dedicated to improving the security of Cloud services.

Part 2 introduces a number of security architecture concepts and a conceptual Security Reference Model. This model is then applied to the different Cloud service models – Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) and Function as a Service (FaaS) – to show how the conceptual security services within the reference model can be delivered for each Cloud service model.

If you are already familiar with Cloud computing models, terminologies and associated risks then you could go straight to Part 2, although you may find the contents of Part 1 a useful refresher.

Throughout this book, I have italicised the names of the security services defined within the Security Reference Model (SRM). This is to distinguish between the name of a service such as identity management and the wider topic of identity management.

CHAPTER 1: INTRODUCTION TO CLOUD COMPUTING

Cloud computing

One of the more evocative labels for an IT delivery model – certainly more so than the utility computing label to which Cloud owes much of its heritage. However, like its rain-carrying namesake, Cloud computing can be difficult to describe, with many observers having their own perspective on what is, and what is not, Cloud. Many people use Cloud services without realising that they are doing so – iTunes, Facebook and Twitter are all examples of Cloud services. However, these are consumer Cloud services, aimed at individual users, and the security of such consumer services is not discussed within this book.

The purpose of this book is to help those organisations looking to implement Cloud services aimed at the enterprise – the likes of Salesforce, Amazon Web Services, Microsoft® Azure and the Google Cloud Platform – to do so in a risk-managed manner.

Figure 1: Cloud computing model

Figure 1 shows a high level representation of the Cloud computing model. On the left, we have a Cloud computing provider – essentially a set of servers offering some form of shared IT service. On the right, we have a set of organisations with users and client devices capable of accessing that shared service. In the middle we have the Internet (or some other delivery network) that acts as the transport mechanism enabling the access devices to connect to the shared service. You can also see some individual users sitting on the Internet that are just as capable of accessing those shared services as the larger organisations. The shared service on offer could be anything from the original Amazon Web Services model of access to compute and/or storage resources through to the Salesforce, Concur or SuccessFactors model of access to specific software applications.

Regardless of the service on offer, there are a number of key characteristics that the service must display in order to be truly 'Cloud', these are:

•Multi-tenant – the service should (at some level of the technology stack) be shared amongst its users rather than dedicated to the use of a single consumer. In the case of services like Amazon Web Services, multi-tenancy traditionally exists at the level of the physical hardware and the hypervisor,¹ which can host virtualised images serving many consumers.² In the case of services such as Salesforce, the multi-tenancy sits at the application level – many different consumers access the same instance of the applications on offer. Consumers are, therefore, separated only by the barriers implemented by the provider within their applications. This is a prime differentiator of Cloud services from a more traditional data centre outsourcing model, where resources would more typically be dedicated to individual clients.

•Ubiquitous network access – the service should be available to all over a common network. For public Cloud services, the common network is usually the Internet. For other types of Cloud services, the network could be a more private network such as a government or academic network.

•Elastic – the service should be able to respond quickly to spikes in demand, with the Cloud consumer able to add the additional resources needed to maintain service levels during a spike in demand and, then, to rapidly release resources again once the spike has passed. Cloud providers should look to reduce the amount of manual effort required to support this elasticity.

•Pay per Use – consumers should be charged for the amount of resources that they actually consume; in the case of infrastructure services this could be by charging per CPU per hour or charging per GB of data stored or transferred. For Cloud providers offering SaaS this could be a case of charging per user per month rather than charging on the traditional basis of a perpetual license.

•On-demand self-service – consumers should be able to provision the services they need themselves, without needing to talk to the Cloud provider. In many popular Cloud services, customers can obtain the services they need with only a network connection and a credit card.

That is my view of Cloud, a view heavily influenced by the now de facto definition of Cloud computing produced by the American National Institute of Standards and Technology (NIST). The NIST definition of Cloud computing is discussed in much more detail in chapter 2. There are a number of services that seek to use the Cloud label, but which do not display all of the characteristics described above. A number of service providers continue to jump on to the Cloud bandwagon, and many services that would normally just be viewed as a shared service or a virtualised data centre have been relabelled as Cloud services. This relabelling is so common that it earned its own title – ‘Cloud-washing’.

This book is not dogmatic about whether or not a Cloud service displays all of the expected characteristics described above; the guidance it provides is also generally applicable to wider classes of shared services.

¹ Hypervisors are responsible for allocation of physical hardware resources such as compute, storage and communications to virtualised operating system guests hosted on that hardware.

² Although bare-metal services dedicated to the usage of a single customer can also be used at additional cost.

CHAPTER 2: OVERVIEW OF EXISTING CLOUD TAXONOMIES AND MODELS

Chapter 1 provided an informal introduction to the main concepts underlying the Cloud computing model. This chapter provides a more formal set of definitions and a common terminology to enable a joint understanding of what is meant by terms such as IaaS, community Clouds and deployment models.

There are a number of different definitions of Cloud computing, with probably the most widely accepted being the definition of Cloud computing produced by NIST.³ The NIST definition describes Cloud computing as being:

[A] model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.

The five essential characteristics, as defined by NIST, are:

1.On-demand self-service

2.Broad network access

3.Resource pooling

4.Rapid elasticity

5.Measured service

The three service models defined by NIST are the familiar terms of IaaS, PaaS and SaaS. These service models are described in more detail shortly.

The four deployment models within the NIST definition comprise the commonly used terms of public and private Clouds together with the less commonly used models of community and hybrid Clouds (though hybrid Cloud is becoming increasingly popular in the enterprise space). Each deployment model is described more fully a little later on in this chapter.

There are some interesting things to note about the NIST model of Cloud computing, one of which is that it focuses on the three main traditional delivery models of IaaS, PaaS and SaaS. New models have emerged since the publication of the NIST definition, notably FaaS and the different, but often related, model known as serverless computing. As both the FaaS and ‘serverless’ models are likely to become increasingly popular over the next few years, particularly with respect to the implementation of microservices architectures, we will consider the security of such models in this book.

Whilst this book is relevant to Business Process as a Service (BPaaS), and, indeed, to many of the other *aaS terms that have been coined since the publication of the NIST definition, it is structured so as to consider IaaS, PaaS, SaaS and FaaS in turn. Those deploying other *aaS models should take the relevant guidance and adapt it to their purposes.

Service models

Infrastructure as a Service (IaaS)

In their definition, NIST describe Cloud IaaS as the model where:

The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g. host firewalls).

The most popular IaaS services are those offered by the ‘Big 3’ comprising Amazon Web Services (AWS), Microsoft Azure and the Google Cloud Platform (GCP); however, some of the major systems integration companies, such as IBM and HPE, also offer IaaS specifically targeted at enterprise users. You can also find smaller local Cloud service providers (CSPs) offering ‘sovereign’ Cloud services, i.e. Cloud services hosted and supported from a single host country, which target those organisations with specific regulatory or national security requirements necessitating that data and services remain in-country.

An example of a more focussed IaaS is that of companies offering Disaster Recovery as a Service (DRaaS) whereby organisations can store machine images and data in a Cloud-based service ready for use in a disaster scenario rather than building a secondary data centre. Another example of an IaaS is that of desktop as a service which enables end users to access their company 'desktop' over the Internet, with the desktop infrastructure itself being hosted within a Cloud provider and shared with other clients.

The primary selling point of IaaS is that the Cloud provider has already invested in providing the infrastructure and so end user organisations only have to concern themselves with the operational expenditure of using the service rather than the capital expenditure of building their own services. Consumers, therefore, pay for the capacity that they actually use rather than having to pay for servers sitting idling in their data centres. Furthermore, IaaS enables the speedier deployment of new resources, with new server images being available to consumers in a matter of minutes rather than months, as may be the case for those organisations needing to manage complex procurement and deployment processes. Those resources can then be released again should demand recede, at which point the organisation bears no further costs – a marked contrast to the traditional model. IaaS also promises to release headcount currently assigned to physical server management to tasks that offer more perceived value to the business.

Many enterprises are adopting IaaS for mission-critical production services across a wide variety of sectors. ‘Cloud First’ is the dominant IT strategy for both the FTSE350 and the UK government. It is now extremely rare to find an organisation that is looking to build new physical data centres; few organisations see building and operating data centres as a core business activity.

There are a number of reasons why some organisations may still be resisting a move to IaaS, with security being one of those factors.

Other factors include:

•It is potentially more expensive to run a 24/7 service, with relatively constant levels of demand, on the Cloud. Clouds tend to be cheaper for short-term or bursty applications – consistent loads can be cheaper to host on-premises, particularly where organisations are not willing to re-architect services to take advantage of the elastic nature of the Cloud.

•Certain legacy technologies, such as mainframes, cannot easily be migrated to the Cloud. Mainframe workloads are now being moved to the Cloud, but this is certainly not as straightforward as moving a virtual machine from VMware ESX to AWS EC2 or Azure. Furthermore, mainframe applications may require substantial data transfers to and from the Cloud provider and this may create greater costs.

•Discomfort with the ‘follow the sun’ support model of the underlying Cloud platform. Whilst the Cloud provider's physical infrastructure is, obviously, supported in the host geography, the higher levels, such as the hypervisor layer, may be supported from outside the host region. This situation can cause difficulties for those organisations subject to blanket compliance requirements demanding data, services and support be hosted within a specific geography.

Platform as a Service (PaaS)

NIST describe Cloud PaaS as the model where:

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

The most well-known examples of PaaS include Microsoft Azure, Google AppEngine, AWS Elastic Beanstalk, Heroku and the Force.com platform. In addition to those platforms that allow the Cloud consumer to simply run their code, the PaaS term is also commonly used to describe other services that sit in-between the IaaS and SaaS definitions. Examples of such PaaS services include the Azure data analytics offers and the Service Now platform where customers are able to develop and extend upon the provided service.

PaaS offerings build on the advantages of the IaaS model by taking away the overhead of server administration from consuming organisations. Developers get direct access to the development environment and can increase or decrease their compute resources as and when they need; project delivery is no longer dependent on server installation lead times.

As we shall see later in the book, PaaS is perhaps the hardest of the three delivery models to secure as the responsibilities for delivery of security services is distributed across the provider and consumer much more widely than in the other two service models.

Cloud interoperability and portability is the subject of many industry initiatives, including work by the Open Group,⁴the International Organization for Standardization⁵ (ISO/IEC 19941:2017) and the Object Management Group⁶; however, both issues remain problematic with no standard being widely adopted by the major Cloud providers. Whilst it constitutes an issue for all Cloud models, the potential risk of lock-in is more pronounced with PaaS than with either IaaS or SaaS. PaaS providers may support specific frameworks, APIs, identity management services and databases that may not be compatible with those offered by other providers or traditional on-premises products. In practice, this makes it very expensive to move from one PaaS provider to another as the developed application must be recoded (ported) to utilise the APIs, frameworks and other features offered by the platform of any alternative provider.

The PaaS model tends to be very attractive to those organisations needing quick delivery of Internet-facing services and those organisations (such as start-ups) that do not have the resources to host or manage their own servers at the operating system level. The PaaS model is also increasingly popular with the enterprise market, particularly in the area of big data analytics and machine learning.

Software as a Service (SaaS)

NIST describe Cloud SaaS as the model where:

The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Salesforce.com, a company that offered Cloud services before the term ‘Cloud’ itself was coined, is without doubt a pioneer in the area of SaaS. Other examples of well-known SaaS applications include Office365, SuccessFactors.com, Google Docs and Concur.

With SaaS, organisations will typically access a specific software application (such as a customer relationship management application) via a web browser. This means organisations only need to consider the business usage of that application and the provision of devices capable of accessing the Internet – concerns around servers, operating systems and application development are no longer relevant. This model can be very attractive to business executives, particularly if the relationship between business and IT representatives has been strained by past perceptions of poor or unresponsive IT delivery.

The SaaS model is probably the most commercially successful of the three delivery models, perhaps in part due to the previous industry flirtation with the Application Service Provider (ASP) model. Enterprises appear to be more comfortable making use of specific services hosted in the Cloud than they are with the idea of making more general purpose usage of Cloud-based services. SaaS can appear to offer genuine business enabling services whereas PaaS and IaaS may appear to the business as simply different ways of doing IT.

There are a number of specific, security-focussed SaaS offerings, including email security, web content filtering, identity as a service, vulnerability assessment and anti-malware to name a few. These ‘security as a service’ offerings are often pitched as providing security expertise for those organisations that cannot provide such expensive expertise internally.

Function as a Service (FaaS)

As noted earlier, NIST do not currently publish a definition for FaaS or the related term ‘serverless’. There are a number of different definitions relating to both terms, but no widely accepted standard; that being the case, I feel little guilt in putting forward my own definitions in this book!

Let us define serverless as:

The capability provided to the consumer is to deploy functionality onto the Cloud by accessing utility services via the APIs offered by the provider. The consumer does not manage, control or have visibility of the underlying Cloud infrastructure, including its network, servers, operating systems or storage, but has control over the deployed applications.

The key point here is that the consumer has no visibility of the underlying infrastructure as services are accessed purely by application programming interface (API). In other words, whilst physical servers are providing the services within the realm of the Cloud provider, these services appear ‘serverless’ to the consumer who only ever interacts via API. The canonical example of a serverless technology is AWS S3 (Simple Storage Service); in this case, consumers simply call the S3 API to PUT or DELETE data objects but have no visibility of the underlying infrastructure.

FaaS is a form of serverless technology and an evolution of the PaaS model. The most popular FaaS services are AWS Lambda, Azure Functions and Google Cloud Functions.

We will define FaaS as:

The capability provided to the consumer to deploy event-triggered, time-limited functions on the Cloud without requiring an overall process to be running at all times. The consumer does not manage, control or have visibility of the underlying Cloud infrastructure including its network, servers, operating systems or storage, but has control over the deployed applications. Scaling is the responsibility of the Cloud provider.

In general, FaaS services charge per number of executions, execution time and related factors, i.e. if a particular function is never triggered then there will be no charge (other than for associated storage of code or data). Functions can be triggered by a variety of events including provider-specific events (e.g. changes to the contents of an AWS S3 bucket), the receipt of an HTTP request or the identification of an event in a data stream. FaaS functions are time-limited; for example, an AWS Lambda function has an execution limit of 15 minutes whilst an Azure Function has a default execution time limit of 5 minutes (configurable to a maximum of 10 minutes) under the Consumption hosting plan option. If a function is not completed within those time limits, it may be terminated by the Cloud run-time.

FaaS services are commonly used to assist in the automation of IT operations, e.g. as part of DevOps initiatives (or, in the context of this book, DevSecOps initiatives), due to their ability to automatically respond to defined events. Another common use case for FaaS is the cleansing of data, e.g. to prevent regulated data from being transferred outside of an assured environment.

FaaS is also becoming one of the primary technologies used to implement microservices architecture, i.e. applications that are decomposed into modular components. Enterprises have the option of containerisation of microservices components or using FaaS, and some of those that have not invested in the likes of Kubernetes and Docker to provide containerisation are now deciding to avoid that complexity and move to FaaS.

The ephemeral and distributed nature of the FaaS model presents a number of novel challenges from the perspective of security that we will explore later in this book (see chapter 12).

Deployment models

Public Cloud

The public Cloud model is the archetypal Cloud model; the services are open to all-comers, individuals, enterprises, governments, your collaboration partners and your competition. The key point is that there are no real security barriers governing who can register to access the shared service. The low barrier to entry (typically a need for a credit card and an Internet connection) is one of the major selling points of the public Cloud model.

NIST define a public Cloud as one where:

The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.

Examples of public Clouds include Amazon Web Services, Microsoft Azure, the Google Cloud Platform, Salesforce.com, Office365 and most other well-known Cloud services.

Private Cloud

The term 'Private Cloud' is one of the more contentious concepts within the area of Cloud computing. Some commentators such as Werner Vogels of Amazon⁷ have argued that private Clouds do not exist, with the implication that those organisations which believe themselves to have a private Cloud in fact only have a virtualised data centre. I must admit that the distinction between a virtualised data centre and a private Cloud can be hard to define; however, I do see merit in the idea of a private Cloud. In the public Cloud the economies of scale are realised through the sharing of resources, such as CPU cycles and storage across different organisations. However, in the private Cloud model the economies of scale come from the sharing of resources across different cost centres within the consuming organisation.

Of course, in the private Cloud model there are much lower savings on capital expenditure compared to the public Cloud as the consuming organisation must still invest in the IT and physical hosting infrastructure. However, a private Cloud is still likely to be cheaper to operate than a more traditional infrastructure due to the lower footprint of a shared, multi-tenant (between cost centres) virtualised IT estate. A perception that private Clouds are more secure than their public equivalents is one of the main drivers for organisations to build their own Cloud. The other major driver for organisations adopting private Cloud approaches is a risk-averse interpretation of regulatory requirements. These ideas will be explored later in chapter 6, which discusses some examples of regulatory requirements relevant to Cloud usage.

NIST define a private Cloud as being where:

The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third-party, or some combination of them, and it may exist on or off premises.

The major public Cloud providers do now allow their customers to procure dedicated instances and dedicated hardware (i.e. compute resources that are not shared with other tenants); this allows them to offer private Cloud services albeit at greater cost than their multi-tenant offers.

Community Cloud

Community Clouds form the middle ground between public and private Clouds and could be viewed as equivalent to a gated community. Community Clouds are only open to members of the community with rigorous registration procedures to be completed prior to access being granted. Once granted access to the community, there would typically be a set of minimum security controls that member organisations must implement in order to protect the overall community. Community Clouds are more cost-effective than private Clouds as the cost of building and operating the services are shared across all of the organisational tenants.

NIST define community Clouds as being those where:

The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third-party, or some combination of them, and it may exist on or off premises.

Secure government Clouds, open only to departments and their executive agencies, are good examples of community Clouds. Other such community Clouds exist in specific private sector industries, notably defence.

Hybrid Cloud

NIST define the Hybrid Cloud model as representing the model where:

The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).

The initial driver for implementing a hybrid Cloud model was the belief that this would ensure the effective management of spikes in demand that would exhaust the resources available to a more private deployment model. For example, organisations hosting a private Cloud could draw upon the CPU resources of a public Cloud should demand become too great for the private Cloud to service. However, the demand for such ‘Cloud-bursting’ has not proved to be as great as expected.

The hybrid model is now much more popular with those enterprises that are unable to move all of their IT services to the public Cloud, either as a consequence of other choices or of their interpretation of strict compliance requirements. In both scenarios, it