CHAPTER 4: SECURITY THREATS ASSOCIATED WITH CLOUD COMPUTING

The previous chapter illustrated some of the potential benefits and pitfalls associated with the security of Cloud computing.

This chapter highlights some of the threat actors that may be in a position to attack a Cloud-based service. Some of the threat actors discussed in this chapter are taken from the NIST list of important actors for public Clouds available from:

www.nist.gov/itl/cloud/actors.cfm.

Alternative threat actor lists are available from the likes of CESG/NCSC via the now withdrawn HMG Information Assurance Standard 1 (NCSC currently points towards NIST SP800-30³⁹ as an example threat taxonomy), and as part of the Information Security Forum (ISF) IRAM v2 risk assessment methodology.⁴⁰

The threat actors discussed in this chapter, and illustrated in Figure 3, should be considered during the risk analysis phase prior to any move to a Cloud-based service.

Figure 3: Cloud threats

Cloud provider staff

Whenever a service is outsourced, the client is reliant upon their service provider to abide by the provisions of their contractual arrangements. This situation is little different when dealing with Cloud providers. Consumers are still reliant upon the Cloud provider to abide by their security commitments. These commitments should include appropriate employment checks, activity monitoring, segregation of duties and internal disciplinary procedures. Cloud providers should also be willing to provide details of the internal approvals processes; these are privileged access controls and monitoring processes that have been implemented to control the access of staff to customer data and services. Certain providers have also devised solutions to allow their customers to exercise a degree of control over support access to their services, including Lockbox in the Microsoft Cloud environment⁴¹ and the ServiceNow SNC Access Control plug-in.⁴²

Cloud consumers are well-advised to examine their provider’s published staff security commitments prior to trusting their data to the provider.

Contractual commitments aside, there is still a risk that a member of service provider staff could act maliciously or accidentally to compromise the security of their clients' data. Whilst there are controls, such as on-premises encryption or tokenisation, that clients can implement to protect their data from a compromise of confidentiality (and from some integrity attacks), there is little that they can do to protect against risks to availability. Should a privileged member of staff at a service provider turn rogue there are few technical controls available to prevent them accessing or destroying data or disabling services.

However, this is also little different to the situation with internally hosted systems: Cloud employees of consuming organisations or traditional outsourcers can also turn rogue. There is one factor that may increase the likelihood of Cloud service provider staff turning rogue; threat sources such as organised crime or intelligence agencies may be more likely to target Cloud provider staff. These members of staff may present such threat sources with access to more data or services than would be the case when targeting internal staff or employees at more traditional service providers.

Image/application providers

One of the major productivity benefits of deploying services into the Cloud is the number of preconfigured machine images (e.g. Amazon Machine Images (AMIs)), Docker⁴³ containers and applications that are available for almost immediate use. Many AMIs are now available from Amazon themselves and many more from other EC2 users; these AMIs come with pre-built capabilities for web serving, database hosting, security scanning and many other options.

Security researchers, such as Sensepost, have already demonstrated that it is possible to upload AMIs containing instructions of which the AMI consumers were unaware⁴⁴. Fortunately, the Sensepost example simply used GNU Wget to obtain a file from Sensepost to allow the researchers to track download and usage of their uploaded AMI. It is likely that other backdoored AMIs will be, and perhaps already are, more harmful in nature.

As well as the threat of purposefully malicious backdoored AMIs, there is also the threat of AMIs that were not appropriately sanitised prior to being published. Work by Bugiel et al.⁴⁵ has shown that a large proportion of AMIs contain the SSH (Secure Shell) user authentication key of the AMI Publisher. This is dangerous for Cloud consumers as such authentication keys give the AMI Publisher access to the virtual machines of the Cloud consumer. I would surmise that it is most likely that not all of these backdoors were left in by accident. Amazon does provide guidance⁴⁶ on the steps that should be taken to remove credentials prior to uploading AWS AMIs to the Marketplace; however, this guidance is only pertinent to those not intentionally looking to cause mischief. Whilst I have used the term AMI, the same concerns are relevant to the sharing of pre-built server images whatever the IaaS provider. Similarly, the use of Docker containers for implementation on IaaS or pre-built applications for deployment onto PaaS platforms may also suffer from similar issues relating to backdooring.

However, trust in the supply chain is not a new issue. Organisations must always place trust in the servers, storage, network equipment and the software that they choose to deploy. Organisations will typically perform a certain amount of due diligence and testing before purchasing IT assets and then deploying them. This approach should also be adopted before deploying pre-packaged machine images, applications, blueprints or other templates in Cloud-based environments.

Equipment manufacturers

As explained earlier in this book, the security research community has an increasing interest in exploring the security issues associated with the physical hardware underlying all Clouds (and indeed all IT), from the CPU to the BMC via DRAM (Rowhammer) attacks. In conjunction with increased concerns about nation state threat sources seeking to compromise the supply chain (including through the use of physical implants or the deliberate inclusion of physical design flaws), equipment manufacturers should also be viewed as potential threat actors. Cloud consumers must also consider that threat and risk level attribution by national security services to specific vendors may be affected by the contemporary nature of global trade relations between those issuing the guidance and those producing the hardware.

Competitors

There is nearly always a driver to keep certain information assets away from your competitors. These assets could be your latest findings from research and development, your client list or something more prosaic such as your staff directory. When services are hosted internally then organisations can be confident that they understand the barriers preventing access by their competitors.

These barriers become a little less formidable when services are outsourced. IT hardware may still be dedicated to individual clients; however, to drive cost-efficiencies, the service desk and support staff may well be shared across the client-base of the provider. Similarly, multiple client IT systems may be managed by a common management network and operations centre. Even with a traditional outsourcing arrangement, organisations may find themselves sharing aspects of their service with their competitors.

When moving to a Cloud model, the barriers become even less formidable. An organisation and its competitors could now be operating their services on the same physical servers, having their data stored on the same physical SANs and using the same applications or run-times as their competitors. Competitors may, therefore, see Cloud services as a more likely source of competitive information than more traditional deployment models.

Organisations should however bear in mind that the more traditional industrial espionage methods, such as financial inducements and blackmail, targeted at individuals are likely to be just as successful with obtaining information stored on-premise as they are with information stored within the Cloud. As an interesting side note, some businesses refuse to adopt Amazon Web Services as they see the wider Amazon business itself as being a competitor either now or in the near future; I have personal experience with several retail and insurance businesses that have displayed such beliefs.

Crackers/hackers

Crackers have already proven themselves to be a genuine threat to Cloud services – consider the compromise of the Sony PlayStation Network (PSN)⁴⁷ as a prime example. In April of 2011 Sony decided to close the PSN whilst they investigated, and recovered from, an attack which compromised the user account information of millions of PSN users. In May of 2011, Sony estimated that this breach of security was going to cost the business around $170m. More recently, Uber (the taxi firm) were compromised in 2016⁴⁸ after hackers obtained sensitive credentials relating to their Cloud-hosted services from the GitHub account of one of their developers. The hackers got away with the names and driver's license information of 600,000 Uber drivers, together with the names, email addresses and phone numbers of 57 million Uber users.

Hackers may pose a more direct threat to services deployed on Cloud systems than those deployed on-premises. Side-channel attacks may allow an attacker to identify the physical hardware hosting their target's virtual images; at this point, the attacker can attempt to bring up their own virtual machine on the same physical hardware. A hacker would still require a mechanism like Rowhammer or a Spectre-style CPU-level attack to break the virtualisation barrier(s); however, work by Ristenpart et al.⁴⁹ has shown that the side-channel analysis reconnaissance is not merely a theoretical problem. So, whilst hackers and crackers are a threat to systems wherever they are hosted, more attack vectors exist with respect to services hosted on a Cloud service.

Insiders

Insiders, such as company employees (shown in the consumer element in Figure 3), have long been considered by security professionals to be one of the major threat sources to organisations. Insiders tend to be trusted (to some extent) and so granted access to applications and data. Insiders are, therefore, in a position where they could deliberately, or accidentally, release, modify or destroy valuable data. This aspect of insider access to data is independent of IT delivery model and so equally applicable to Cloud services.

Cloud does, however, present a new mechanism by which insiders could knowingly, or unwittingly, compromise the data or services of the organisation to which they belong. Cloud services are extremely straightforward to sign up to and use; all that is typically needed is a credit card and an Internet connection. It is a trivial exercise for an insider to deploy a Cloud service, inadvertently opening up new mechanisms for business data to be exfiltrated or for attackers to infiltrate back-end systems. From the perspective of compliance with the GDPR, it is extremely difficult for an organisation to maintain a complete information asset register, and then apply the necessary controls to those information assets, if they are not aware of the locations where their employees are storing and/or processing personal data.

However, this is not a new pattern of behaviour; similar behaviours were displayed during the rise of the client/server model and during the early days of wireless networking. Proactive and technology-aware members of staff would implement their own systems or wi-fi networks as they found that they could get the IT services they wanted without having to suffer the delays often associated with central IT teams – a phenomenon commonly known as ‘Shadow IT’. Cloud computing displays many similar characteristics to these previous disruptive technologies; Cloud services can be quick and easy to deploy, promising more efficient delivery of the services required by business users. Unresponsive or overly risk-averse IT departments can, therefore, exacerbate the threat posed by insiders establishing their own shadow IT services.

Governments

Cloud computing is a global phenomenon: Cloud services are offered from data centres across the world. Many governments have the legal authority to seize data from data centres hosted within their territories. Some governments have even enacted legislation granting them access to data hosted outside their jurisdiction if the organisation hosting the data concerned has a subsidiary based within their jurisdiction⁵⁰. Such legislation is usually justified as being required for counter-terrorism purposes or for fighting the distribution of child pornography. Some nations do not attempt to justify their access rights and simply take advantage of their position in order to maintain order within their populations. Often, the service providers are under legal obligations not to inform the data owners of any such data seizure.

One example of a major data seizure is that of the US government's seizure of payment data from SWIFT, the organisation which facilitates the transfer of funds between banks. It was reported that the US government compelled SWIFT to provide details of archived inter-bank transfers conducted through SWIFT for the previous 4 years. The output from the Belgian Commission for the Protection of Privacy (CPP) investigation of the events can be obtained from:

www.dataprotectionauthority.be/sites/privacycommission/files/documents/swift_decision_en_09_12_2008.pdf.

It is clear that the ability of sovereign states to seize data is not limited to data hosted by Cloud service providers. However, it is equally apparent that governments do represent a threat to the privacy of business data, the threat is simply exacerbated by the Cloud model where data could be located in more jurisdictions than would be typical with other deployment options.

In addition to governments making use of the extraterritorial powers that they have granted themselves, there are also extralegal mechanisms that they may adopt to gain access to Cloud-hosted data. Cloud service providers and Cloud management brokers are tempting targets for nation state and nation state aligned hacking groups. For example, the CloudHopper/APT10⁵¹ incident resulted in the compromise of at least nine managed services providers, with the APT10⁵² group widely believed to be a Chinese government grouping. Cloud service providers and those offering Cloud-management services must design their services in the knowledge that they will be attacked by highly capable threat actors.

Transport agents

Some organisations have a requirement to transfer large amounts of data for storage and/or processing at their Cloud provider. The usual mechanism for transferring data between the consumer and the Cloud is over the Internet. This is clearly impractical for large datasets. Cloud providers like AWS have recognised this limitation and, consequently, offer services that enable consumers to save their data onto a hard drive and mail or courier this hard drive to the provider. AWS customers looking to transfer huge quantities of data can even make use of a dedicated ‘snowmobile’⁵³ consisting of a truck pulling a 45 ft long container with sufficient storage for up to 100PB of data. However, whilst not all CSPs will offer snowmobiles, the ability to transport data via hard drive import/export is increasingly common.

Consumers taking advantage of this service require a means of getting their hard drives to the Cloud providers, and transport agents fulfil this function.

Transport agents, therefore, represent a viable threat to the security of the Cloud consumer's data. They are in possession of storage hardware containing large amounts of consumer data which may or may not be protected by encryption, and so must be subject to appropriate security controls, e.g. due diligence, vetting and monitoring.

Identity providers

The use of identity federation techniques is a common recommendation of Cloud security papers, speakers and this author. Identity federation enables organisations to manage their Cloud users' identities on-premises or using Cloud-based Identity Providers (IdPs), and can provide seamless access to applications whether they are hosted on the Cloud or on-premises. If organisations do not want to manage their own identities, they can rely upon public, third-party identity providers (such as Facebook, LinkedIn, Google and Microsoft) via their support for OAuth2 or similar standards. Whilst it would be a brave business that relied upon such providers to secure access to their internal systems, a case can certainly be made to use such providers for consumer-facing Internet services requiring little by way of identity validation or verification. Such a case could be built around improving the end user experience through providing them with greater control over their personal information through enabling them to use identity providers of their own choice.

If an organisation makes the choice to use an external identity provider to secure a Cloud-based application, then they must recognise that a compromised (or malicious) identity provider represents a serious threat to their service.

Note: it is not only human actors that have identities, systems and services also require identities and these identities can also be compromised.

Attribute providers

Similar arguments to those just expressed with regard to Identity Providers can be made with regard to Attribute Providers, i.e. providers of specific attributes associated with an identity. For example, a user may be authenticated to an application using Facebook Connect, but the application may then require further details associated with that identity to make fine-grained access control decisions. Such details (attributes) can be stored within, and made available by, a different service provider. This can allow an organisation to split authentication and authorisation data whilst also minimising the effect of a single compromise on the privacy of their end users.

Note: End users could choose to store a minimum set of data with their identity providers and with each attribute provider to minimise the impact of a compromise of any single provider.

Of course, a compromised (or malicious) attribute provider then represents a threat to the security of the relying application.

Cloud brokers

Some organisations may want to deliver their IT using multiple Cloud service providers to benefit from additional resilience, variable pricing or to meet perceived regulatory compliance requirements around business continuity and exit planning. However, they may not want to have to worry about the quirks of each service that they use. The role of the Cloud broker⁵⁴ is to sit between the client and their Cloud services. Brokers can present a single interface for their clients to use to build and operate their services whilst handling the complexities of actually running these services on a variety of Clouds in the background. Cloud brokers can also simply act as Cloud-based systems integrators for those clients looking to outsource Cloud management, even if they only use a single provider.

Cloud brokers are, therefore, in a trusted position and represent a potential threat to organisations making use of their services.

This chapter introduced a number of different entities that could represent a threat to an organisation's Cloud-based services. Knowledge of potential threats enables organisations to build barriers that are effective against the methods likely to be employed by each relevant threat. Organisations can use the threat descriptions within this chapter to check that the security controls that they have implemented cater for the threats that they have identified as being within scope.

³⁹ https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf.

⁴⁰ The Common Threat List (only available to ISF members) www.securityforum.org/news/isf-updates-risk-assessment-tools/.

⁴¹ Lockbox is a long-standing feature of Office 365. Similar functionality is now available in Azure https://azure.microsoft.com/en-gb/blog/approve-audit-support-access-requests-to-vms-using-customer-lockbox-for-azure/.

⁴² https://docs.servicenow.com/bundle/london-platform-administration/page/administer/security/concept/c_SNCAccessControl.html.

⁴³ www.docker.com/.

⁴⁴ www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-sensepost-clobbering_the_cloud.pdf.

⁴⁵ www.trust.informatik.tu-darmstadt.de/fileadmin/user_upload/Group_TRUST/PubsPDF/BNPSS11.pdf.

⁴⁶ https://docs.aws.amazon.com/marketplace/latest/userguide/product-and-ami-policies.html.

⁴⁷ www.bbc.co.uk/news/technology-13206004.

⁴⁸ www.wired.com/story/uber-paid-off-hackers-to-hide-a-57-million-user-data-breach/.

⁴⁹ www.cs.tau.ac.il/~tromer/papers/cloudsec.pdf.

⁵⁰ For example, the United States of America has both the Patriot Act and the CLOUD Act: https://en.wikipedia.org/wiki/CLOUD_Act.

⁵¹ www.ncsc.gov.uk/news/apt10-continuing-target-uk-organisations.

⁵² www.fireeye.com/current-threats/apt-groups.html#apt10.

⁵³ https://aws.amazon.com/snowmobile/.

⁵⁴ Sometimes known as Cloud service brokers or Cloud management brokers.