Skip to content ↓ | Skip to navigation ↓

Helping to define and examine the top perceived cloud security threats of the day, the ‘Egregious Eleven’ is the most recent iteration in an evolving set of summary reports published by the Cloud Security Alliance (CSA). It follows on from the ‘Treacherous Twelve,’ which they defined for us in 2016, and the ‘Notorious Nine,’ which they presented in 2013.

The ‘Egregious Eleven’ list marks an interesting shift of emphasis in that most threats can be viewed as more truly and intrinsically native to the shared, on-demand nature of cloud computing itself in comparison, that is, to some of the more traditional infrastructure and information security threats ‘also applicable to cloud’ discussed in previous versions.

Another notable and rather positive difference is that some of the items highlighted in prior reports primarily relating to Cloud Service Providers (CSPs) now rate low enough in the survey responses to be omitted from the list altogether. Instead, more attention is paid to threats higher up the technology stack including areas of configuration within the customer’s control.

Whilst some of the threats will hardly come across as ‘breaking news’ to security professionals, the guide is produced with the admirable intention of simply being a call to action for enhancing security awareness and improvement. It also succinctly provides us with a well-researched, structured and articulated summary of possible hazards with which to raise questions and discussion.

Both consumers and providers of cloud services alike can, therefore, benefit from risk assessing and hopefully escaping some, or ideally all, of the egregious eleven:

1. Data Breaches

Just as many aspects of cloud computing continue to advance and evolve with characteristic pace, it appears there are some constants when it comes to security which show no sign of abating anytime soon. In order of perceived severity, data breaches was first on the ‘Treacherous Twelve’ list and remain resolutely first of the ‘Egregious Eleven.’ Data breaches were also cited as the top concern regarding the adoption of public cloud services by 64% of cyber professionals who responded to the recently published (ISC)² Cloud Security Report for 2019.

‘Operation Cloud Hopper’ was the name bestowed upon the sustained cyber espionage campaign carried out against eight of the world’s largest technology service providers. In literal terms, these attacks affected more traditional managed service providers (MSPs) than cloud services (as per the commonly accepted ISO/IEC 17788 or NIST SP 800-145 clarifications of what actually defines a cloud service.)

The implications, particularly for the multi-tenancy architecture of public cloud, are both obvious and highly concerning none the less. A sustained and long-term intrusion of a large CSP could have a devastating effect not only on the personal, system, financial and intellectual data property of the CSP itself but also that of its customers and then quite possibly their own customers and so on. Just how far such a potential downward spiral of compromise could go and what the long-term consequences may be could make even the large-scale compromises and data breaches we have known so far pale into comparison.

People, processes and technology, including efficiently implemented and well-managed encryption techniques, all play a crucial part in avoiding data breaches in any environment. Likewise, lapses in any of those areas may well contribute to or even be the cause of a data breach. One of the key data protection ‘takeaways’ for cloud is acknowledging that despite any shared security control responsibilities across the various service models of Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) and the perhaps misplaced notions that accompany them of risk transferal, the ultimate responsibility for adequately protecting the customers data will remain more often than not with the customer themselves.

2. Misconfiguration and Inadequate Change Control

Whilst elements of this area were previously alluded to under the ‘System and Application Vulnerabilities’ item of the ‘Treacherous Twelve,’ the list now specifically calls ‘Misconfiguration and Inadequate Change Control’ out as the second top threat. The dynamic nature of cloud with its often-ephemeral resources and the ease to which systems, storage or entire environments can be rapidly provisioned or configured with minimal authorization is to many, including developers, one if its more appealing aspects.

The guide, therefore, notes how traditional security controls and change management approaches may not necessarily be as, or at all, effective in the cloud. From ‘the world is welcome’ S3 storage buckets to Elasticsearch databases exposing millions of user records, there are far too many examples of cloud misconfigurations leading to breaches through a likely lack of any robust change authorisation or oversight.

Change management processes are clearly still required in the cloud, but they need to be re-evaluated and likely repurposed. Security control challenges likewise need to be creatively rather than retrospectively considered. Secure deployment and operations automation, for example, can actually offer the possibility of less human error, provided there are suitable mechanisms for assuring repeatable templates, continual code review and alerting or correction of any modifications or deviations from approved baselines. Immutable instances or workloads often built with containers may take this thinking further, only permitting changes from an underlying image so that no manual login to make direct changes to the running instance itself is necessary or even feasible. Even when using immutable instances or infrastructure, however, security tools and processes should still be actively scanning and monitoring for signs of untoward configuration changes.

3. Lack of Cloud Security Architecture and Strategy

Another of the newer cloud-specific additions to the report involves urging better consideration for the differences of thinking required when securing cloud solutions. The rapid pace in which organisations are hybrid joining or migrating away from their in-house infrastructure and virtualisation environments with neither appropriate diligence or appropriately updated skillsets will inevitably lead to some poor strategic and architectural decisions. The CSA offers a wealth of free and vendor-agonistic information to help get started with a security strategy. One of the best documents to begin with is their ‘Security Guidance for Critical Areas of Focus in Cloud Computing.’

4. Insufficient Identity, Credential, Access and Key Management

IAM or identity and access management has always been a multi-faceted and complex function to get right in any large or disparate environment. In the abstracted world of cloud, verifying trust in the identity of the party requesting access to the cloud service, and assigning the correct entitlements when granting that access, is everything when it comes to securing the data, workloads and resources within it. Public cloud complicates this further with its essential ‘broad network access’ from anywhere characteristic and the frequent need to trust multiple entities managing access in different ways to different resources. This is where federation comes in along with the need to preserve the integrity of the identity provider and its authoritative sources whilst establishing the right levels of trust with the relying party. Making all this seamless to the end-user yet secure in its implementation of standards such as SAML, OAuth & OpenID can be a complex task to configure and maintain.

But even if you get all of that just right, there is still, of course, the cloud users’ selection and protection of their own identity passwords to the authoritative source to consider. The password, as we know too well, is an approach to authentication which hasn’t proved to be terribly intuitive to human nature, and so the humans, in turn, haven’t proved to be terribly great at selecting or protecting them. This is why two factors of authentication are always better than one, and a third is better still. For privileged users with administrative or other high levels of system entitlements, MFA is always a must.

5. Account Hijacking

Whether through the tried and tested attacker methods of phishing, cross-site scripting or a multitude of newer vulnerabilities and vectors, hijacked cloud accounts make for a great attack target. Defense in depth has to be applied therefore at all levels to minimize the opportunities for attackers to masquerade as legitimate users or services. Once they do, it can be very hard to detect and correct. Particularly when accounts can then be used to perpetuate other attacks or malicious acts that appear to have come from the compromised source itself. Subscription or other highly privileged accounts are particularly valuable. If access to the management plane (the virtual area which effectively controls your cloud environment) can be hijacked, then you really do have some big trouble.

Although largely theoretical and less discussed than it used to be, the concept of hyperjacking (very simplistically, that is taking control of or replacing the underlying hypervisor itself with a rogue instance) potentially takes the whole idea of hijacking to a very different ‘game over’ level.

6. Insider Threat

The threat of ‘malicious insiders’ predates not only cloud but networked computing itself and has long been a focus of security risk assessments for critical environments. The reach and levels of access a well-placed ‘inside’ threat actor may have in a multi-tenanted CSP environment, and the fact that they are completely unknown to the customers themselves once again accentuates the risk for some of cloud over wholly ‘in-house’ controlled systems and staff.

It is, therefore. imperative that customers for whom this is a real concern conduct the proper diligence with their CSP before entrusting them with any critical data, processes or workloads. They need to understand what controls may be in place around aspects such as encryption key management and robust segregation of duties, for example. Any such policies and processes will also need to be supported contractually to have any real authority. For certain highly regulated sectors or organisations, such a removed, contractual approach may simply not be sufficient. They may instead choose to forego some of the convenience, scale and cost benefits of public deployment models and instead build their own private clouds.

‘Insider threats’ may equally arise from within the customers own appointed personnel or contracted resource, of course. Putting the thought of intentionally malicious saboteurs or spies aside for a moment, most insider originating breaches simply occur through negligence or poor user training and awareness. Any security strategy therefore needs to make sure users are appropriately trained and hold access only to the data and privileges genuinely required for performing their roles.

To summarize, this half of my blog and perhaps restore some balance and perspective; whilst considering threats is a necessary security activity, it is also right to state that the cloud in all its guises can offer some significant security as well as business benefits over many traditional on-premise methods of delivering IT services. Like it or not, cloud is also the inevitable future of most digital and IT services. In the next part of this blog, we’ll take a better look at some of those benefits as well as delve into the next and final five of that egregious eleven.


About the Authorangus macrae: Angus Macrae is a CISSP (Certified Information Systems Security Professional) in good standing, a CCP (NCSC Certified Professional for the IT Security Officer role at Senior Practitioner level) and PCIP (PCI SSC Payment Card Industry Professional.) He is currently the IT security lead for King’s Service Centre supporting the services of King’s College London, one of the worlds’ top 20 universities

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.