CHAPTER 8: SECURITY AND THE CLOUD
This chapter begins with a brief overview of the existing guidance available to those with an interest in Cloud security. I then propose mechanisms for delivering those security services within the SRM – see Figure 7 – that are common to all three traditional Cloud service models, and where the delivery of those services is not overly impacted by the choice of service model.
Finally, this chapter also discusses the relative merits of the different Cloud deployment models from a security point of view.
Existing guidance
Cloud computing has been growing in popularity and acceptability over the last decade or so; more than enough time for a number of different organisations to produce guidance in the area of Cloud security. The most established guidance document is arguably that produced by the Cloud Security Alliance (CSA)82; this group was originally formed in 2009 by a small number of individual volunteers but it now comprises hundreds of corporate members and tens of thousands of individual members. The CSA document, “Security Guidance for Critical Areas of Focus in Cloud Computing” is in its fourth iteration at the time of writing, and now presents a relatively mature set of guidance across 14 different domains from architecture through to incident response. The CSA guidance is a must-read document, not least because it also represents a major element of the syllabus for the Certificate of Cloud Security Knowledge (CCSK), the vendor-neutral Cloud security certification offered by the CSA. The guidance within the CSA document has evolved over the years and is now more practical and deliverable than that offered by previous iterations. In addition to the security guidance document and the CCSK, the CSA also hosts around forty other initiatives relating to Cloud security, with the most prominent including:
•Cloud Controls Matrix (CCM);
•Consensus Assessments Initiative Questionnaire (CAIQ);
•Top Threats; and
•CSA Security, Trust and Assurance Registry (STAR).
Of all of the CSA initiatives, I would particularly recommend readers to investigate the CCM, CAIQ and STAR. The CCM has practically become a de facto standard for organisations building secure Cloud services, whilst the CAIQ is the most common approach used to ascertain compliance with the CCM. The CAIQ is also widely used because it includes a mapping of the CCM onto other well-known information security standards, such as COBIT, ISO 27001 and PCI DSS – this mapping across the standards is useful even outside of the Cloud context.
The CSA STAR83 initiative is one of the more valuable repositories of Cloud security information on the Internet. Its registry allows Cloud providers the opportunity to describe how they deliver the security elements of their offers using the format of completed CAIQs. There are three different levels of assurance available, from simple self-assertion (Level 1) through to continuous independent assurance (Level 3). STAR Level 2 introduces the use of independent third-party auditors to certify compliance with the CCM. This can be achieved through either STAR Attestation, which blends SOC 2 requirements from the AICPA Trust Service Principles (AT 101) and the CCM, or STAR Certification, which blends the requirements of the ISO/IEC 27001:2013 with those of the CCM. Most of the major Cloud providers across all service models now have an entry on the registry, which can be found here:
https://cloudsecurityalliance.org/star/registry.
CSA STAR entries often represent the most comprehensive view of Cloud provider security capabilities available to those charged with conducting the due diligence activities associated with Cloud adoption – they are only rivalled by SOC2 Type II reports. Organisations are strongly recommended to review the STAR entries prior to procuring or building upon a Cloud service.
The CCSK certification is now in its fourth iteration; it tests candidates' knowledge of the latest version of the CSA security guidance document together with knowledge of “Benefits, risks and recommendations for information security”, a risk assessment document 84 produced by the European Network and Information Security Agency (ENISA) and the CCM. This risk assessment document is only one of a number of interesting publications that ENISA have produced. Another ENISA document containing some worthwhile guidance is the “Security and Resilience in Governmental Clouds”85 document which includes a Strength, Weakness, Opportunity, Threat (SWOT) analysis with regard to the different deployment models, in a government context. The main landing page for ENISA's work on Cloud can be found at:
www.enisa.europa.eu/topics/cloud-and-big-data/cloud-security.
I have made extensive use of the work of NIST within this book, primarily their definitions of the Cloud service and delivery models. NIST also have a proud history of producing security guidelines, particularly in the area of operating system security. As you may expect then, given their work with Cloud computing and security, NIST have produced their own special publication on the security of Cloud computing: Special Publication 800-144, entitled “Guidelines on Security and Privacy in Public Cloud Computing”86 provides a good overview of the security issues associated with the use of public Cloud computing services.
Governments have been eager adopters of Cloud services, with the UK government adopting a strategic principle of Cloud First back in 2013. Unsurprisingly, governments have stringent security requirements, particularly with respect to classified data; for this reason, government guidance is a good source of inspiration for those organisations looking to implement secure Cloud services. The UK National Cyber Security Centre (NCSC) has published a widely adopted set of 14 Cloud Security Principles87 and associated implementation principles. The principles are wide-ranging and cover both largely Cloud-specific issues, such as ‘separation between users’ (i.e. multi-tenancy considerations), and more traditional security elements, such as ‘identity and authentication’ in the context of Cloud usage. The US government has also been a keen adopter of Cloud services, and the US approach towards adoption of Cloud has been guided by the FedRAMP approvals process. There is a comprehensive collection of Cloud security guidance available for those organisations seeking to comply with FedRAMP available from the FedRAMP website.88 As with the NCSC Cloud security principles, the FedRAMP guidance is widely applicable outside of the government arena.
The final vendor-neutral organisation that I will mention here, in the context of generic advice, is the Open Group. One of the first Open Group outputs in the area of Cloud security was the “Security Principles for Cloud and SOA” whitepaper produced by the Cloud computing workgroup89. This whitepaper presents a series of security principles, in the format recommended by TOGAF 9, designed to guide the secure development of service-oriented architectures implemented in the Cloud. The security principles it describes are also often relevant to other forms of Cloud deployments. A more recent output is the Cloud Computing Ecosystem Model90which provides guidance to architects developing enterprise architectures that include the use of Cloud services.
That concludes my brief round-up of some of the existing guidance (and wider initiatives) with regard to the security of Cloud computing. The next few pages provide some more detailed guidance on how a number of security services common to all service models may be implemented.
Common security services
In general, the security services defined within the SRM will be delivered differently per service model. However, a number of the security services are technology-agnostic and so independent of Cloud service model. This section provides guidance on how these more procedural and/or organisational services may be provided.
Hosting
In the SRM, the hosting service grouping is composed of the following services:
•Physical Security
•Environmental Security
•Storage
•Communications
Regardless of service model, these hosting services will always be delivered by the Cloud service provider (CSP).
Consumers should ensure that the physical security mechanisms employed by the CSP are sufficient to meet their requirements. This should not just be limited to the external perimeter security; consumers should ensure that the CSP data centres also include adequate internal security mechanisms, including internal access controls, internal security monitoring (CCTV, passive infra-red intruder detection systems, logging of access to sensitive security zones, et cetera) and suitable procedures governing visitor access. Consumers are unlikely to be able to conduct their own physical audits to confirm that these controls are in place and they will usually be reliant upon independently assessed assurance mechanisms, e.g. SOC2 Type II reports, ISO 27001 certification or CSA STAR entries. In addition to the external and internal physical security of the building, consumers should also content themselves that the CSP data centres are located in areas that are secure from multiple perspectives. Issues that should be considered include:
•Environmental threats – earthquakes, volcanic eruptions, flooding, severe weather;
•Civil unrest – are the data centres located in stable political locations?
•Government intrusion – are the data centres located in countries where government access represents an acceptable threat?
•Transport – flight paths.
•Resource availability – is there a sufficient pool of skilled resource available?
Some CSPs do not help themselves by keeping information regarding the location and physical security mechanisms of their sites out of the public domain. Consumers should be wary of CSPs that are unwilling to share such information, particularly if such information is still not available under non-disclosure agreements.
As with the physical security aspects, consumers should (where possible) ensure that they are content with the environmental controls implemented by the CSP. In the context of the SRM, environmental controls refer to those controls used to maintain a suitable environment for the IT equipment in terms of cooling, resilient and redundant power supplies and humidity controls. Those organisations with specific carbon reduction, or other 'green' targets, may also be interested in the efficiency ratings of the CSP data centres. Again, this information is not always available from the CSPs. However, a number of CSPs make the efficiency of their data centres a key point of pride and a selling point, e.g. Salesforce.com91 and Google Cloud92.
Another key element of the hosting service grouping offered by CSPs, of all description, relates to storage; it concerns whether IaaS, PaaS, SaaS or FaaS consumers are likely to need to store data within the CSP Cloud, and, consequently, within the CSP data centres. Whilst consumers may be able to secure their data via on-premises encryption or tokenisation (depending on the Cloud service), in other cases consumers will be reliant upon the storage security provided by the CSP. Where possible, consumers should content themselves with the mechanisms used by the CSP to secure their data when stored within the CSP Cloud. This should include examination of:
•The access controls to the underlying storage systems;
•The mechanisms separating data belonging to different consumers;
•The support mechanisms for the storage (this should include ascertaining whether customer data can be taken off-site should storage failure require investigation by the storage vendor); and
•The capabilities provided to consumers to remove their data from the CSP and how such 'deleted' data is managed by the CSP.
The final hosting service within the SRM is communications. Consumers should ensure that the CSP data centres have multiple communications links to ensure that their service remains available in the event of a network failure. As with the other hosting elements described in this section, such information is not always going to be available from the CSPs. In the event that such information is not available from their CSP, consumers must balance the risk of the service (or services) not meeting their requirements against the expected benefits of the Cloud service. Such a lack of information should not lead to automatic disqualification of potential CSPs, unless the consumer has specific critical requirements that demand absolute certainty of the mechanisms used to deliver those requirements.
Compliance
Compliance is still perceived to be one of the major barriers to the adoption of Cloud services within enterprises, particularly in more risk-averse and/or more heavily regulated sectors. However, Cloud services are now widely adopted within government and are increasingly being adopted by financial services organisations; this shows that perceived compliance issues can be overcome, at least within the risk appetites of the organisations concerned. In the UK, many of the retail banking giants are increasingly adopting Cloud services, for example HSBC Bank is now working on the principle of Cloud First,93 whilst Lloyds Bank is adopting a more hybrid approach via IBM, AWS and Google. Whilst some of this adoption may be driven by increasing comfort with the Cloud model, it is also likely that the established banks are starting to feel the pressure of competing with more agile challenger banks that are typically more Cloud native in their approach. OakNorth, for example, is a poster child for Cloud in the financial services sector and has built its core banking systems on AWS.94
Chapter 5 discussed some of the compliance issues associated with Cloud computing, particularly with regard to data privacy and issues relating to compliance with PCI DSS requirements. Compliance is not a trivial subject to address, particularly for global enterprises. For example, the following link lists the data protection legislation of over 50 countries:
www.informationshield.com/intprivacylaws.html.
It is my view that compliance as a whole cannot be outsourced, which is why I have suggested that compliance remains the primary delivery responsibility of the client regardless of service model within Figures 8, 9, 10 and 11. I do not dispute that consumers may outsource the delivery of their IT services to providers offering compliant services, or that certain activities relating to the assurance of Cloud services may also be outsourced. However, should the consumer or provider suffer a breach of compliance the consumer would still suffer the consequences such as loss of reputation and potential fines. The organisation always retains accountability for their own compliance and so, in my reference model, they also retain responsibility for ensuring that their services are delivered in a secure manner.
Whilst a growing number of CSPs can legitimately claim to offer services that are compliant with standards such as PCI DSS (subject to very specific scopes), the consumer will still suffer the consequences should the systems that they build on such services become non-compliant. Such a situation could easily arise due to a misunderstanding of the scope of the compliance achieved by their CSP. Cloud consumers cannot insulate themselves entirely from the impacts of being found in breach of their compliance requirements.
Within the SRM, the compliance service grouping consists of five services:
1.Audit
2.Test
3.Regime
4.Identify
5.Translate
So, how does this work in practice? Of these services, by far the most important, and hardest to deliver, is the regime service. This is the service that is responsible for defining the compliance regime and so sets the boundaries for the activities that are acceptable. In order to set the compliance regime, two different conceptual services are suggested: the identify and translate services. These two services perform two different, but equally critical, tasks in terms of defining the compliance regime. The identify service is responsible for identification of all of the different compliance requirements; such requirements can be sourced from national legislation, industry regulation, organisational policies and other sources. I would recommend that the set of source requirements be validated by a qualified legal advisor to provide assurance that the set is defensibly comprehensive. Once a set of requirements has been identified, it is then necessary to place these requirements into context. For example, principle (e) of the GDPR requires that personal data be:
kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes subject to implementation of the appropriate technical and organisational measures required by the GDPR in order to safeguard the rights and freedoms of individuals (‘storage limitation’)[.]95
What does this text mean in the context of your application? How do we get from legalese to a testable requirement? The purpose of the translate service is to turn the typically generic language used in legislation and regulation into something relevant to the task at hand.
Now, you may be thinking that this all sounds like the production of mountains of paperwork that would severely impact upon the agility, flexibility and time to market that a move to Cloud is supposed to provide. At this point, I should highlight that I do not think it would be necessary for the compliance service as a whole to be delivered by every single Cloud project. ICT delivery projects rarely occur within an organisational vacuum, and most organisations should already be aware of their compliance requirements; in this situation, the translate service becomes critical for individual project and/or service delivery. That is to say that the key task is to translate the existing, known compliance requirements into testable requirements tailored for the Cloud-based service currently under consideration.
Figure 12: Compliance process
This process of generating a set of testable requirements is shown in Figure 12. Once you have a set of requirements, you can then test whether or not the Cloud services under consideration can meet those requirements. It is vital that the consumer pays close attention to the service levels promised by the provider alongside the liabilities and penalties for failure to meet these targets. There is little incentive (other than reputation management) for Cloud providers to meet strict service levels if their standard terms and conditions limit their liabilities for failing to meet the advertised service levels. Consumers should be wary of the advertised service levels and be comfortable with the possibility of the service levels not always being met. If you are comfortable with the likely actual service levels (and many reputable providers offer the capability to monitor their service level history), then you can go ahead and design your service with the comfort that your compliance requirements can be met – so long as you do your own job adequately.
Aside from the use of the SRM, there are some more straight-forward, practical steps that enterprises can take to adhere to strict data protection rules. The simplest mechanism for ensuring that your data does not leave the legal regime of your choice is using a local Cloud supplier, i.e. one hosted within your own country, often referred to as ‘sovereign’ Cloud providers. For example, there are a number of Cloud suppliers96 within the UK that only operate data centres within the UK; such suppliers are not going to place your data at risk of being transferred overseas (although there is no guarantee that IP packets between your on-premises systems and the Cloud provider will not be routed overseas). An alternative route would be for the consumer to build their own private Cloud and host this Cloud within the location of their choice. Of course, this latter option requires more initial investment and would not be suitable for those looking to take advantage of the full range of services available from public Cloud providers. The major Cloud providers are now offering some options that work as a compromise between on-premises and on-Cloud models; these include ‘Cloud in a box’ preconfigured hardware for deployment on-premises, such as Azure Stack or AWS Outposts, which organisations adopting a hybrid Cloud model may find worthy of consideration.
Security governance
The security governance service grouping is one of the largest within the SRM catering for:
•Risk management;
•Privacy; and
•Personnel security.
The security governance grouping also includes a service called ownership. Ownership relates to the need for those organisations deploying in the Cloud to ensure that the ownership of specific responsibilities and accountabilities has been assigned. I have seen numerous Cloud strategies fail due to a lack of appropriate ownership. Symptoms of such a lack of ownership may include:
•Rampant Shadow IT due to a lack of governance and control;
•An abundance of Cloud environments across a variety of authorised Cloud providers due to the lack of a standard approach to deployment;
•A lack of accountability for the success or failure of Cloud projects;
•A lack of clear principles, policies, standards or other ways of working;
•The proliferation and duplication of tooling and management structures.
Enterprises adopting Cloud must define their ownership structures as early in the Cloud adoption process as they can. These ownership structures can be delegated and distributed; there does not need to be a single centralised owner. However, there does need to be a single centralised view of that ownership structure. Some possible ownership roles include:
•Cloud risk;
•Cloud architecture; and
•Cloud operations.
Once allocated, it is the responsibility of the role owners to ensure that the wider enterprise (or their allocated business units) is able to maintain a level of control and accountability around success and failure.
There is also one more service included within the security governance grouping and that is coordinate. Whilst the primary responsibility for delivery of the security services described within the SRM may change depending upon the chosen service model, the coordinate service must always sit with the consumer. The purpose of the coordinate service is to ensure that all of the other security services relevant to the application work together as a cohesive unit regardless of who bears primary responsibility for delivery. I strongly recommend that consuming organisations assign responsibility for coordination of security across on-premises and on-Cloud services to a named individual or team, perhaps the Cloud risk owner listed earlier. This will help to ensure that a close interest is maintained in the cohesiveness and effectiveness of the overall security architecture (Cloud and on-premises).
The security management service is an interesting one in the context of Cloud, digital transformation and DevSecOps. If your enterprise is adopting multi-model IT, perhaps the Gartner bimodal approach or Wardley's PST model, then your approach to security must be cognisant of the need to support these different modes of working. For example, for Mode 1 services, typically those that are more stable, a traditional security management structure may be appropriate (see Figure 13 below).
Figure 13: Mode 1 – Traditional approach
In this situation, the central information security team may retain responsibility for policy and standard setting, monitoring compliance with those policies and standards, and for the delivery of security operations. This is very much the traditional security approach to the security function: providing projects and programmes with the security requirements that they must deliver – the ‘thou shalt’ approach. This approach does not scale to the agile, multiple releases per day way of working featured in Mode 2. A new approach is required.
Figure 14: Mode 2 – Distributed approach
Figure 14 represents a more appropriate way of working in these more dynamic environments. In this model, much of the responsibility for and control of security is delegated to the business units and project teams, though they may still work to a set of common security principles and tooling. This delegation may take the form of ‘security champions’ embedded within individual delivery teams. Depending upon the scale and nature of your approach and project, such champions could be embedded at the level of ‘tribes’, ‘squads’ (if using the Spotify model) or individual scrum teams. The aim of this approach is to provide the development teams with access to the security input that they need at the time and level that they need it. The security champions themselves do not always need to be full-time security professionals, they simply need to be aware of the security requirements for their area and have strong links to the centralised security capability (and wider security community or guild) should they need further advice and guidance. When this expertise is embedded in the individual teams, they are able to progress to delivery much more rapidly than is common in the more traditional model – in contrast to the ‘thou shalt’ approach, this approach is closer to ‘we will’. Larger enterprises will likely find themselves needing both approaches to provide the right security approach and oversight to the various modes of operation: a single approach to security is unlikely to be appropriate.
Cloud deployment models
The next few chapters of this book consider each of the Cloud service models in turn and describe mechanisms for delivering the security services described within the SRM. However, these chapters do not consider the different Cloud deployment models. To fill this rather obvious gap, I am going to use the remainder of this chapter to talk about the security characteristics of the different deployment models.
Public Cloud
Public Cloud is the deployment model most commonly associated with Cloud computing. The security implications are very much encapsulated by its name – public. Public Cloud services are open to all: competing enterprises, individual users, malicious users and any other interested party. The Public Cloud model is shown in Figure 15.
Figure 15: The public Cloud model
The different customers of the CSP are separated only by the mechanisms that have been implemented by the CSP; an insecure Cloud service could effectively bridge across their customer base. So, in the public Cloud model, there are shared networks, hypervisors, access control services, storage and (depending on service model) shared platforms and applications.
A naïve consumer may have neglected to secure their communications to their 'trusted' Cloud provider; it is vital that consumers realise that they are often connecting to their CSP over the untrusted Internet and secure such connections appropriately. This book provides guidance on how to secure FaaS, SaaS, PaaS and IaaS, so I will not go into the details of how to secure connectivity here; the point of this section is to highlight the differences between the different deployment models.
Major public Cloud providers are often global in nature with data centres spread across the world to provide resilience and redundancy and to deliver acceptable performance levels to local users. Such CSPs will often claim to be able to limit the transfer of data between these data centres so as to enable their clients to meet compliance requirements relating to data location. However, there is often no cast-iron guarantee (e.g. acknowledgement of liability) should such CSPs accidentally allow data to leak from one data centre to another. There is also often a lack of clarity regarding the support model for the physical infrastructure providing the public Cloud service. Some of the well-known Cloud providers have a ‘follow the sun model’; this means that support staff are located outside of the geographical region of the data centre itself. This leads to a lack of confidence amongst some potential consumers regarding their ability to limit data presence to specific locations and it helps to explain much of the concern that surveys often report with regard to compliance issues in the Cloud.
Of course, the public Cloud model does have some security benefits to provide to their consumers. Firstly, the CSP has likely heavily invested in security already, particularly at the PaaS and SaaS levels. This is an investment in property, technology, personnel and process that consumers can take advantage of and do not need to resource themselves. A second advantage of the public Cloud model is the wide visibility of security incidents that these CSPs may have across their client base. There have been a number of anecdotal incidents whereby CSPs have noticed something amiss with their clients' activities, e.g. sudden increases in network traffic indicating where client services have been hacked and used to distribute illegal content. Such wide-ranging situational awareness can be a positive feature for many clients, particularly if the client does not have the staff or the contacts to be able to identify security threats currently active 'in the wild'. Security monitoring services like Azure Sentinel and AWS GuardDuty obtain threat intelligence from across their entire Cloud infrastructures; consequently, potential malicious activity has a higher visibility with these than most enterprises operating on-premises.
Meanwhile services such as GCP Backstory97 and AWS Detective98 provide enterprises with searchable archives of past security log entries that provide valuable insight when investigating the root cause and/or history of security incidents.
In summary, consumers considering the public Cloud model must be wary of compliance issues and be confident in the compensating mechanisms that they have adopted to protect themselves from other tenants accessing the service.
Private Cloud
The private Cloud model is the diametrical opposite of the public Cloud model. A private Cloud is dedicated to the use of a single consumer. However, there is no requirement for the private Cloud to be hosted and operated by the consumer. A private Cloud can be outsourced to a traditional service provider; the service provider may then operate the Cloud service from the premises of their client or from their own data centres. Figure 16 outlines the private Cloud model.
Figure 16: The private Cloud model
Figure 16 shows the two potential access mechanisms for a private Cloud, either over the consumer's own WAN or, in the case of a hosted Cloud, perhaps over the Internet. The red line within the diagram represents the barriers preventing the threat actors from accessing the private Cloud. Unlike in the public Cloud model, there is no multi-tenancy across different consumers. There may, however, be multi-tenancy implemented across different organisational units within the consumer. Indeed, this is where consumers may derive their cost-savings from adoption of the Cloud model; different organisational units or services can now purchase compute or network resource from the private Cloud rather than having to invest in a multitude of discrete technology stacks.
From a security perspective, there is little doubt that the private Cloud model offers consumers the most control. The consumer can dictate their own requirements and engage in detailed dialogue and negotiation with prospective CSPs. This is in direct contrast to the public Cloud model, where it is often difficult (or impossible) for consumers to negotiate any deviation from a provider's standard terms and conditions or service levels. The flexibility offered by the private Cloud model, therefore, enables consumers to implement the exact security solutions that they require, subject to the traditional constraints around cost! Consumers can also dictate the location of the infrastructure and so manage their own compliance risks.
The private Cloud model is not without issues however. If the private Cloud is only for one consumer, with a set of particular security requirements, then the consumer will need to invest in the property, technology, personnel and processes needed to meet those requirements. If the consumer is planning on operating their own private Cloud (rather than outsourcing its operation), then they must also accept the need to provide the necessary security resources.
The other main issue with private Clouds, from a security perspective, relates to availability. Whereas public Cloud services can present the illusion of infinite compute and storage resources, this is an illusion that a private Cloud cannot sustain. An organisation building a private Cloud must still provision enough IT equipment to be able to cater for the maximum usage spikes; this will likely leave the organisation with the traditional issue of over-capacity whereby resources sit idle awaiting the next spike.
Hybrid Cloud
The hybrid Cloud model applies to any combination of the other three deployment models. For example, a service delivered using both private and public Cloud resources would be described as a hybrid Cloud. Figure 17 outlines the different combinations of the other Cloud deployment models that can form a hybrid Cloud.
Figure 17: The hybrid Cloud options
It can be seen from Figure 17 that there is at least one configuration for a hybrid Cloud that does not involve public Cloud services. This configuration would entail the use of private Clouds in combination with community Clouds. I point this out as it is easy to forget that the hybrid approach does not necessitate the use of a public Cloud. It should also be noted that the term ‘hybrid Cloud’ is increasingly being used to refer to situations in which a consumer deploys a service across a variety of different Cloud providers. However, I will continue to use the more traditional NIST definition in this book.
Figure 18 uses a representation very similar to that which I used for the private Cloud model within Figure 16.
Figure 18: The hybrid Cloud model
The major difference from Figure 16 is that I have removed the barrier between the Cloud resources and the threat actors. This brings me to the crux of the major problem I see with the hybrid Cloud model. It is the worst of all worlds from a security perspective, especially when considering the combination of private and public Cloud models. Not only do consumers need to invest in all of the security resources associated with operating a private (or community) Cloud, but they must also implement the controls needed to operate in the public Cloud. This issue is not necessarily as problematic now as it was in the past – there are a growing number of Cloud workload protection tools (e.g. Guardicore) that enable organisations to use common security tooling across on-premises and on-Cloud environments.
So what reasons are there for an organisation to adopt the Hybrid Cloud model? There are two primary reasons organisations adopt the hybrid model:
1.They may have a desire to keep their most sensitive data on-premises but also want to make use of Cloud services for their less sensitive or commodity services; or
2.They may have some legacy services that are nontrivial to migrate to the public Cloud, e.g. mainframes.
A third driver relates to the over-capacity issue I touched upon when talking about the private Cloud model. Rather than purchasing capacity that may only be used very rarely, an organisation may choose to maintain a presence on a public Cloud service and 'burst' to the public Cloud for additional capacity when their private Cloud becomes over-stretched. In this approach, an organisation's sensitive data remains within their private Cloud with only the occasional foray into the public Cloud. Of course, from a compliance perspective, an occasional breach remains a breach. This may be one reason why such Cloud-bursting is less common in practice than was envisaged in the early days of Cloud.
A final driver for the adoption of a hybrid approach may occur when a consuming organisation wishes to adopt a 'best of breed' approach; in this case, they may choose to use public SaaS services tied together with some private IaaS services (e.g. storage or shared identity repository).
From a security perspective, placing data into the public Cloud immediately raises all of the issues associated with operating in the public Cloud: multi-tenancy, data remanence (how does the public Cloud provider manage data that has been deleted by the consumer?) and the potential leaking of data across geographic boundaries. It is vital that those organisations adopting the hybrid model in order to keep their sensitive data on-premises maintain strong barriers between their private Cloud and the outside world.
In terms of the security benefits that the hybrid model offers over and above the public Cloud model, these are perhaps limited to the ability to retain sensitive data within the more enclosed deployment model (e.g. private) whilst still taking advantage of the capabilities of public Cloud services for other services. This does come at the cost of increased complexity, including the likelihood of the duplication of security tooling across the public and private Clouds.
Community Cloud
A community Cloud sits somewhere between the public and private Cloud models. A community Cloud caters for a closed community of organisations, typically bound by a common security and compliance regime. An excellent use case for a community Cloud could include government Clouds or more niche areas such as Cloud services aimed at law enforcement, health or education. Figure 19 illustrates the community Cloud model.
Figure 19: The community Cloud model
As with the private Cloud model, there are a series of barriers preventing access to the Cloud services to those outside of the authorised community. The Cloud services could be hosted within a commercial CSP data centre, or within a data centre belonging to a member of the community or, perhaps, within a shared data centre established by the community. The network links between the members of the community and the relevant data centres could be provided by a private network or through use of the Internet.
Community Clouds have the obvious advantage over their public Cloud equivalents that the community gets to define their own shared security requirements and to dictate the location of the data centres. Another advantage of the community Cloud model over the public model is that it caters for a closed community and so Joe Public (or Joe Hacker) will find it more difficult to compromise the service.
As the community model sits between the public and private models it, by definition, sits somewhere between those models in terms of availability of capacity. Public Clouds present the illusion of infinite resource and private Clouds lead to either over or under-provisioning; community Clouds can help their users to cater for usage spikes through allocation of the resources not currently allocated to other members of the community. This is obviously based on the assumption that not all members of the community experience the same spike in usage at the same time (which is not as unlikely as it may sound if talking about community Clouds for the emergency services).
One downside of the community Cloud approach is the need for the members of the community to establish trust with each other, and also to agree to a common governance structure and approach with respect to their community Cloud. Internal politics can be hard; politics within occasionally competing communities can be harder. A community Cloud requires either a central or distributed governance body to define their requirements and to negotiate the terms and conditions and service levels expected of the CSP. This governance body must then procure the service and, once it is in operation, manage it right through to decommissioning, if this is necessary.
Overview of Cloud deployment models
Table 3 summarises the discussion about the merits of the different Cloud deployment models from a security perspective.
Table 3: Deployment Models
In general, the amount of security control over a Cloud deployment available to the consumer decreases in the order shown below:
1.Private Cloud
2.Community Cloud
3.Hybrid Cloud
4.Public Cloud
As a principle, I would tend to argue that hybrid Clouds should be viewed as being as secure as the most public aspect of the Cloud services concerned, e.g. a hybrid Cloud of a private and public Cloud should be viewed as being as secure as the public Cloud concerned, although this does depend upon the strength of the barriers between the two.
82 https://cloudsecurityalliance.org/. In the interests of transparency, I should note that I chair the UK Chapter of the Cloud Security Alliance at the time of writing.
83 https://cloudsecurityalliance.org/research/initiatives/star-registry/.
84 www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment/at_download/fullReport.
85 www.enisa.europa.eu/act/rm/emerging-and-future-risk/deliverables/security-and-resilience-in-governmental-clouds.
86 https://csrc.nist.gov/publications/detail/sp/800-144/final.
87 www.ncsc.gov.uk/collection/cloud-security?curPage=/collection/cloud-security/implementing-the-cloud-security-principles.
88 www.fedramp.gov/documents/.
89 https://publications.opengroup.org/review/product/list/id/89/category/66/.
90 www.opengroup.org/cloud/cloud_ecosystem_rm/index.htm.
91 www.salesforce.com/company/sustainability/.
92 https://cloud.google.com/sustainability/?hl=sr.
93 www.computerweekly.com/news/450418305/HSBC-adopts-cloud-first-strategy-to-solving-big-data-business-problems.
94 www.finextra.com/newsarticle/28952/oaknorth-moves-core-banking-backbone-to-amazon-web-services-cloud.
95 https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/.
96 For example, UK Cloud: https://ukcloud.com/.
97 https://cloud.google.com/blog/topics/inside-google-cloud/the-security-moonshot-joins-google-cloud.