cloud Featured

5 Recurring Cloud Security Observations

This blog post will discuss the top security vulnerabilities commonly associated with cloud computing and touch on areas we observe frequently on penetration tests. By understanding these risks, you can take steps to protect yourself and your data while using cloud-based services.

Steve Spence

• 11 min read
The Cloud, love it, loath it; however, there's no getting away from it!

Cloud computing has revolutionised our lives and work, from streaming our favourite shows to sharing photos with friends and colleagues. But what exactly is the cloud, and how did it come about?

The cloud refers to a remote server network that stores, manages, and processes data over the Internet instead of on a local server or personal computer. This concept has been around since the 1960s, but it wasn't until the late 1990s and early 2000s that cloud computing became more widely available and accessible to the general public.

With the many benefits of cloud computing, such as increased flexibility, scalability, and cost-effectiveness, it's no surprise that more and more businesses and individuals are adopting cloud-based solutions. However, as with any technology, the cloud has potential risks and vulnerabilities.

This blog post will discuss the top 5 cyber security vulnerabilities commonly associated with cloud computing. By understanding these risks, you can take steps to protect yourself and your data while using cloud-based services.

Ok, so before we do dive in, maybe the “Top 5 Cloud Cyber Security Vulnerabilities” isn’t exactly accurate; I would propose a more accurate title would be “5 Common/Reoccurring Cloud Cyber Security Vulnerabilities”, as for the most part, from our vast experience here at Lares, providing and conducting cyber security engagements in all different forms, e.g. Red Team, Insider Threat, Purple Team, Penetration Testing, Compliance etc., more often than not, these issues, regardless of engagement type, appear to be the most prevalent common and reoccurring issues that lead to exploitation or facilitate an initial foothold. So, without further ado, let's dive in!

The five most common/reoccurring Cloud Cyber Security Vulnerabilities findings (in no particular order) we come across within clients’ environments are as follows:

  • Cloud Misconfigurations (e.g., IAM, S3)
  • Unauthorized Access
  • Insecure APIs/Services/Interfaces
  • Lack of Visibility
  • Insecure third-party resources

Pssst… I’ll also discuss a more general finding/issue towards the end of the blog post that touches every facet of cyber security, including the cloud and the impact it can have.

While some of these findings carry change control, patch and risk management requirements, others often do not have a simple fix; however, several of the root causes associated with the common/reoccurring cloud security vulnerabilities can be remedied with businesses embracing a ‘best practices’ approach both in policy and technical controls. It is key to remember that ‘best practices’, simply put, means ‘things that have worked out well for the masses’ and, as such, should work well for you too; spoiler alert, your business still needs to carry out its business risk analysis to fully understand the proposed best practice adoption and what it means for you and your user base. Blindly accepting/implementing any change can land you back in a compromising position with even less understanding or awareness than before.

Cloud Misconfigurations (e.g., IAM, S3)

This is probably the most common vulnerability an organization will face and a leading cause of why Cloud data breaches, in particular, occur. Misconfigurations can come in all forms and are too many to cover within this post; however, I’ll touch on a few of the stand-out items below. Interestingly, these all-too-common misconfigurations, and their associated vulnerabilities, are often caused by a lack of knowledge of good practices, rushing to stand an environment or service up, a lack of peer review from relevant teams such as DevOps, Security Architecture or a combination of these things.

Identity Access Management (IAM)

IAM misconfigurations are common within cloud systems; all too often, they happen when, e.g., a user or service has been created and given access to resources they should not be able to access or interact with.

IAM is another form of ‘Role Based Access Control’ (RBAC) system[1a] [1a] [1a]. In IAM, roles take on three primary forms:

  • Users
  • Roles
  • Groups

IAM might sound daunting; however, securing/configuring it correctly doesn’t have to be complicated or elaborate. Here are some easy-to-follow tips to minimize this type of threat:

IAM ‘Root’ user – DON’T USE IT FOR DAILY TASKS! Instead:

  • Create a separate IAM user for administration and technical work.
  • Disable and delete any credential pairs the root user may have had.

Enforce MFA, EVERYWHERE!

  • IAM users in any account should always enable Multi-Factor Authentication (MFA).

Restrict User/Service/Resource Access

  • Enforcing the principle of least privilege is the most effective way of achieving this!
  • This should be done for all of your cloud resources and users; Avoid granting complete access to a user/service/resource if they/it only needs read access or access to a subpart of the resource.

IAM User ‘House Keeping’

  • Frequently review access and privileges. Access requirements can and will change over time.
  • Delete inactive accounts and/or suspend user accounts where that user is non-operational for prolonged periods.

Key Rotation

  • Regularly change SSH and PGP keys
  • Change KMS keys as/when needed
  • 2FA/MFA, changing keys or tokens can help can mitigate stolen keys and eliminate an attack surface‌

Public Data Storage (Buckets and Public Objects)

Public Data Storage misconfigurations can have highly damaging consequences and, again, just like IAM misconfigurations, are another common vulnerability an organization will face. In recent years there has been another leading cause of why Cloud data breaches, in particular, occur.

For instance, you might need a ‘bucket’ for website storage or hosting static content. This inevitably means you’ll probably need to make some of, if not all of the bucket or its contents public.

Here are some easy-to-follow tips to minimize this type of threat:

Bucket Data Storage

  • Set to ‘Private’ by default. Not all cloud providers do this by default; however, it is detailed in each of the main cloud providers documentation on how to do so.
  • Key point to note, as of December 2022, AWS, as do Azure offer ‘private by default’ creation of their S3 buckets.

Bucket Permissions

  • Permissions (such as GET, PUT, DELETE, LIST for HTTP methods) should be restricted to certain users

Logging/Versioning

Note: Irrespective of the cloud provider, you should thoroughly and carefully consider it before choosing the most appropriate solution. Furthermore, be aware of what is being added to any bucket you create and/or manage, as depending on the settings configured, an added item may remain public until you change it, potentially exposing sensitive data.

Unauthorized Access

In short, unauthorized access occurs when a user/threat actor obtains access to some or all of a business’s cloud resources. Unlike a traditional ‘on-premises’ infrastructure, cloud-based deployments are outside the original concept of the ‘network perimeter’ and directly accessible from the public Internet. Whilst in this digital age, the 24/7 accessibility of cloud-based infrastructure is not only an asset but a necessity to employees and customers alike, it also makes it easier for a threat actor to gain unauthorized access to an organization’s cloud-based resources. This is mainly part of misconfigured or lax security controls and compromised credentials, as these can enable a threat actor to gain direct access, potentially without an organization’s knowledge.

Here are some easy-to-follow tips to minimize this type of threat:

  • Enforce MFA, EVERYWHERE across your business/organization! This should be mandatory for any user with cloud access and/or data within cloud environments.

Enforce a suitably robust password policy with added complexity

  • The jury is still out on whether it should be a password, a passphrase or even passwordless e.g., certificate-based authorization, Zero Trust policy-driven access etc.; however, what it should be, is easy for a user to understand their obligations and deal with though that doesn’t mean allowing users to set an easily guessable password just because 2FA/MFA is in place. Always make sure safe password practices and hygiene are being followed.

End-user awareness/education

  • Whether it is employees or customers, either start or continue to build on social engineering awareness around these types of attack vectors such as phishing, vishing etc. Threat actors regularly employ these tactics to gain access credentials for accounts and/or services.
  • Improve email filtering to make it increasingly harder for threat actors to target your end users, along with honing detection and filtering of phishing emails.

Insecure APIs

The TL;DR is there is no escaping it; APIs are everywhere; they are the backbone of modern software developments and environments, particularly the cloud; whether it’s cloud provider APIs for their customers or APIs stood up by your organization, there’s just not getting away from them! They are used in almost anything a user can access, from microservices to applications to websites.

APIs often have undocumented vulnerabilities, ranging across various misconfigurations. Securing APIs is critical to protect against unauthorized use and unwanted traffic and provide overall cyber threat mitigation.

Threat actors can and will attempt to exploit APIs in a variety of ways; however, the most commonly noted are:

  • Broken Authentication / Broken Authorisation
  • Security Misconfigurations e.g., unpatched flaws, common endpoints, or unprotected files and directories
  • Code Injection e.g., Command injection, SQL Injection etc.

Here are some easy-to-follow tips to minimize this type of threat:

  • API documentation. An API should be clearly, concisely and well-documented. This documentation and the API code base should be regularly reviewed by both automated and manual means. As this will help add in identifying any security issues.
  • Web Application Firewall. Implementing a web application firewall (WAF) to filter requests by IP address or HTTP header info, and to detect code injection attacks; WAFs also let you set response quotas per user or other metrics.
  • Implement an API gateway.
  • This acts as a reverse proxy, sitting between the API collection of backend services and the client, preventing unnecessary exposure of the APIs directly.
  • Implement rate limiting, e.g., limiting the number of API calls the client (API consumer) can make in a second. This can also aid in preventing ‘resource exhaustion’ and ‘DDoS’ attacks.
  • Implement DDoS protection.
  • Arguably this could be a ‘common cloud vulnerability in its own right; however, so could many other things. That said, you’ll want to consider the following for your cloud environment or when choosing your cloud provider:
  • Most cloud providers that protect against DDoS attacks, e.g., AWS Shield, come with easy integration and no additional cost. Check that your chosen provider offers this service.
  • If not by default, ensure DDoS protection on your cloud service/environment (if applicable) is always turned on.

Lack of Visibility

As with most things in life and the cloud, as we grow, we sometimes lose sight of things, or in this case, lack visibility and understanding of our cloud environment. Our cloud services and the scale of the resulting infrastructure grow. Losing sight or lacking visibility in your cloud environment is a significant concern, which can impact and/or delay actions on a threat being detected and may also result in a data breach!

Most cloud providers offer various services, tooling, detection and alerting capabilities; however, the organization and people responsible for administering any environment must still take a proactive approach.

Here are some easy-to-follow tips to minimize this type of threat:

  • Monitor for and detect threats with real-time alerting (where possible).
  • Ensure visibility and understanding of your cloud infrastructure. For example, AWS in Feb 2023 announced a new capability to ‘visualize your VPC resources’ Infrastructure monitoring employs a set of solutions and practices to ensure availability, performance, and security in your technology stack. This stack includes virtualized environments, hardware, networks, storage resources, devices, applications, and operating systems.
  • Implement tools such as Cloud-native application protection, as this can minimize risk and shorten the response time in security alerts, incidents or breaches.

Insecure third-party resources/components

Risks exist everywhere, and the cloud, the resources and the components you use are no different! How you manage them ultimately dictates how prepared you are to respond; this is the same for third-party resources and components risks. No matter how secure your code is, whether an API, SaaS, PaaS, dependencies or third-party components, threat actors can exploit them if they are not themselves secure.

A threat actor can identify the supply chain, third-party resource or component and start from here. They only need to compromise the weak link, to carry out their attack against your company's cloud environment.

An example of such an attack recently was the Node.js/NPM supply chain attack in Dec 2021. Where packages are hosted on Node Package Manager (NPM), the package manager for the Node.js JavaScript platform, either being compromised directly to deliver malware or being created to impersonate popular, legitimate packages.

Key areas a threat actor will commonly focus on are:‌

  • Vulnerable 3rd party open-source packages/libraries
  • Vulnerable versions of application components
  • Use of known vulnerable container images

Ultimately, you can prevent bugs and vulnerabilities in your code; however, you can’t prevent the same in code or products that you or your team haven’t created. Therefore, robust and well-thought-out controls should be implemented to help you make informed decisions about what to use and the risk it might pose.

Here are some easy-to-follow tips to minimize this type of threat:

  • Conduct a business risk analysis on what you use, particularly third-party resources. Look for the products that are officially supported. Also, consider those with compliance certifications that openly speak about their security efforts, have a bug bounty program, and treat their users responsibly by reporting security issues and delivering fixes quickly.
  • Track the third parties you are using. This may seem like common sense; however, it is harder and more time-consuming than it sounds, though this should not be used as a justification to ignore or not follow through. The more you know, the better prepared you are to respond.
  • Ideally, create an in-house repository/library for the things you use. This will allow you to test new versions/updates released or pushed before your services, applications and cloud environment actively use them.
  • Carry out a third-party review, whether periodically, bi-annually or quarterly; the main thing is that you start now if not already doing so! Should a product, service, component, or library be identified that is no longer needed, remove them, revoke any access requirements/permissions and document this.

So, there we have it: the five cloud security vulnerabilities. Now time for the bonus one….

Bonus consideration affecting Cloud environments: The ‘Insider Threat’

Ok, the ‘Insider threat’, let’s face it, it’s always been a ‘thing’; however, the prominence of this attack vector and type is now proving to be a major security headache and issue for organizations around the globe.

A malicious insider, for example, a disgruntled employee or contractor, already has authorized access to an organization’s network and some or all (depending on their privileges) of its sensitive resources. Attempts, by a threat actor, in this case, a malicious insider, to gain elevated levels of access, depending on their skill, reveal the presence or actions of most attackers to their target, making it hard for an unprepared organization to detect a malicious insider.

Now translating this attack vector to the cloud, detecting a malicious insider is often even more difficult. With cloud deployments, companies enter into a shared responsibility model [1b] [2b] [3b] with their respective Cloud provider and, as such, lack control over their underlying infrastructure. This often makes many traditional security solutions less effective. Couple the concern above, along with the fact that cloud-based infrastructure is often directly accessible from the public Internet, in some form or other, and often suffers from security misconfigurations, making it even more challenging to detect a malicious insider.

My colleague Andy Gill has put together a great post on the ‘Insider Threat’ attack type and the Top 5 findings Lares has encountered/documented while conducting an ‘Insider Threat’ engagement. The post can be found here.

Summary

In summary, we walked through the "top 5" or "5 most common and reoccurring cloud security vulnerabilities" (if you prefer), along with key considerations and starting points to help prevent these issues or vulnerabilities from existing within your cloud environment.

Key takeaways:

  • Hardened defences at the core of cloud architectures have shifted hacking to endpoint user identity as low-hanging fruit.
  • Principle of Least Privilege. Discrete user and application-based isolation are ultimately required to achieve a robust ‘zero-trust layer beyond simple authentication.
  • Assess and understand—advanced tools only part of the story, such as cloud infrastructure entitlement management (CIEM). Operational policies and structured risk models are also vital.
  • Trust is more than giving keys and codes. It’s earned. User objects must be given risk scores that dynamically adjust as the business requires and evolves.

Many resources are available from each cloud provider to assist with helping to configure a more secure cloud environment. As a starting point, look at what your cloud provider offers and how that can be leveraged (if not already so), then look for additional resources such as Cloud-native application protection (CNAPP), along with open-source security-oriented tooling such as ‘Prowler’, ‘Scout Suite’ etc., which are a multi-cloud (generally) security-auditing tool, which enables security posture assessment of cloud environments.

Here at Lares, we can offer a comprehensive Cloud Assessment tailored to your needs; due to our vast experience and expertise, we regularly carry out Red Team, Insider Threat, Purple Team, Penetration Testing, Compliance orientated assessments and much more against our clients’ environments.

1 - AWS References

2 -  Azure References

3 - Google Cloud References

4 - Tooling Examples

‌