As we approach the middle of 2023, we thought it an appropriate time to reflect on the cloud security risks and threats that we have seen so far this year, as observed by the Orca Cloud Security Platform that continuously scans billions of cloud assets on major cloud service provider platforms.
After careful analysis of aggregated scan results from January-May this year, the Orca Research Pod has identified the top five most common, yet severe, cloud security risks that are ubiquitous in many cloud environments. In addition to revealing the risks and presenting the data we found, we also provide background information on each risk, as well as key recommendations on how to avoid these risks from occurring in the first place. We hope that this research will help organizations understand which areas can provide the greatest improvement in cloud security posture so they know where to focus their efforts.
Executive Summary
- The Orca Research Pod found that the five most common as well as severe cloud security risks of 2023 so far are, in order of severity: (1) unpatched exposed web services, (2) sensitive information in Git repositories, (3) unsecure sensitive AWS keys, (4) overprivileged IAM roles, and (5) overprivileged AWS Lambda functions. Each of these risks were found to be widespread in organizations of all sizes, even in those with a high maturity level in terms of cloud security.
- Even though these are not the newest and most talked about issues, they are part of cybersecurity 101 (such as the need to patch vulnerable web services and enforcing policies that adhere to the Principle of Least Privilege (PoLP)), and further highlight what is commonly said in the industry: that we should first focus on the security basics to make the largest improvement in cloud security postures.
- It is also important to acknowledge that many security teams are facing a huge backlog in open security alerts while being understaffed. This is hampering their ability to address risks in a timely manner, which is why prioritization of alerts, coupled with guided and automated remediation, are essential to overcome these challenges.
- The Orca Research Pod compiled this research by analyzing workload, configuration, and identity data captured from billions of real-world production cloud assets on Amazon Web Services (AWS), Microsoft Azure, Google Cloud, Kubernetes, and serverless functions, scanned by the Orca Cloud Security Platform from January 1st – May 1st, 2023.
Orca Cloud Security Research Results
Below we list the five most common and critical cloud security risks of 2023 so far, in order of importance:
Finding #1: Patching is lagging on exposed web services
Orca found that 36% of organizations have an unpatched web service in their cloud environment that is exposed to the Internet and therefore easily accessible by attackers. Unpatched services, with known vulnerabilities and bugs, can be one of the main attack vectors into cloud environments. In fact, the majority of attack paths that the Orca Security research team detects and analyzes begin with an exploitation of a known vulnerability. The stakes are considerably higher if the service is web-facing, that is, accessible from outside the network.
Malicious actors can relatively easily exploit an unpatched vulnerability to cause service downtime, potential remote code execution, or more. In some cases, unauthorized remote access may also be a possibility.
All software has the potential to have vulnerabilities and bugs, including web services. Software vendors are responsible for discovering and fixing them before they are found and exploited by malicious actors. Software consumers are in turn responsible for immediately applying these fixes, released via updates or patches.
Finding #2: Sensitive information commonly stored in Git repository
Orca discovered that 50% of organizations have at least one Git repository containing sensitive data. Sensitive information such as database passwords, API keys, encryption keys, hash salts, and secrets, can mistakenly get pushed into a Git repository. In addition to this being contradictory to security best practices, if they are part of the source code of your application, attackers can potentially extract them and compromise your systems. Any pushed sensitive data must be detected and removed immediately, both from the repository and the history.
Finding #3: Sensitive AWS Keys often stored on file systems
49% of organizations have sensitive AWS keys stored on a file system inside a virtual machine. Think of AWS keys as literal keys to your system. Anyone with your key has access to all your resources and can perform any operations that you can, like launch EC2 instances, delete S3 objects, etc. This is why you must always store your keys in a safe location, and never share them with anyone, especially not external parties.
By default, sensitive AWS keys are stored on the file system. If these keys are obtained by a malicious actor, they can use them to access sensitive resources and perform unauthorized operations. It’s important to note that sensitive AWS keys are one of the main exploits for malicious lateral movement identified by Orca Security in attack paths.
AWS keys provide indefinite access unless they are manually revoked. However, for many use cases, you don’t need long-term access without an expiration date. This is why AWS recommends using temporary credentials (generated using the Security Token Service) instead of AWS keys. In addition to the access key ID and secret access key, temporary credentials also have a security token that specifies the expiration date of the credentials.
Finding #4: Too many admin users per organization
Orca discovered that 33% of organizations grant full administrative privileges for more than 10% of IAM roles in their cloud environment, with 10% of the organizations even granting administrative permissions to more than 40% of their roles. This is way too many.
An IAM role in an AWS account is an identity with specific permissions that dictate what actions the identity can perform and which resources it can access. Unlike IAM users, IAM roles are not bound to a single person and can be assumed by anyone that is authorized to do so.
There are no long-term or indefinite security credentials associated with a role. Instead, short-term credentials are issued whenever a user assumes a role. Roles provide a great way to delegate access to users or applications that don’t usually need access to your resources.
IAM privileges are an example of how sometimes security is less convenient, but is still the correct choice. While it’s much faster, and easier, to grant many privileges to users—rather than restricting permissions and creating the need for more oversight—it’s a case of short-term gain and (potentially) larger damage in the long-term.
As a golden rule, it’s best to not, except in rare circumstances, define an IAM role with full administrative privileges, since anyone who assumes the role will have the ability to perform any action on any resource in the account. This violates the Principle of Least Privilege (PoLP), greatly increases the attack surface, and increases the risk of full account takeover.
Finding #5: Majority don’t use separated roles for Lambda functions
Orca discovered that 70% of organizations have at least two Lambda functions that share the same IAM role. In addition, almost 86% of all Lambda functions are sharing their IAM role.
When it comes to AWS Lambda, AWS recommends creating separate roles for each function, in order to promote the Principle of Least Privilege. “By using one dedicated IAM role per function, you can control permissions more intentionally. Every Lambda function should have a 1:1 relationship with an IAM role. Even if some functions have the same policy initially, always separate the IAM roles to ensure least privilege policies.”
This protects data from unauthorized access, and allows you to adhere to various security and compliance standards.
Key Recommendations
As mentioned, these risks are not new. The fact that they are so widespread, therefore, is preventable. By following the recommendations below, organizations can strengthen their cloud security risk posture and minimize the occurrence of these risks as much as possible:
- Adhere to the Principle of Least Privilege – Ensure that administrator privileges are only given to those who really need them, and that regular users don’t have the power to escalate their own privileges or create new accounts. Regularly review user policies, to ensure that users are not given permissions they don’t strictly need. If users haven’t used permissions in 90 days, they should ideally be revoked.
- Never stop patching – Regardless of how rigorous your security controls are, if you don’t regularly patch your software, you are at serious risk of compromise. This is because cyber criminals like to scan and target networks with known, unpatched vulnerabilities. Whenever possible, systems with known vulnerabilities should be patched. Since it is impossible to patch *all* vulnerabilities, it is important to understand which vulnerabilities enable dangerous attack paths and make sure those are patched first.
Attack path showing how an unpatched service vulnerability inside an Internet facing VM, combined with sensitive keys, can facilitate lateral movement to a high-privileged IAM role in AWS Lambda.
- Utilize checklists and CIS benchmarks – To minimize human error, use checklists when creating and configuring cloud assets, entitlements, and resources. Additionally, we recommend implementing policies that follow the best practices of well-known CIS benchmarks.
- Perform continuous cloud scanning to identify risks – Continuously scan your cloud environments for these and other risks. You can really only do this effectively and keep pace with the speed at which cloud environments change by adopting a cloud security platform that has wide visibility across clouds, accounts, and workloads. Ideally, it will empower you to understand the full context of risks and recognize when seemingly unrelated issues can create dangerous attack paths.
- Leverage prioritization to avoid alert fatigue – Risk prioritization is a foundational requirement for effective cloud security. Security tools typically generate many alerts. When you consider that security teams—often understaffed and overworked, and working under heavy pressure—are generally monitoring several tools simultaneously, that’s a lot to handle. Although it will never be possible to fix all risks, it is important that you focus on the ones that are most critical.
These risks, as well as over 2,000 others, are described in Orca’s Cloud Risk Encyclopedia, a free and public resource featuring cloud security and compliance risks and remediation strategies pulled directly from the Orca Cloud Security Platform.
About the Orca Research Pod
The Orca Research Pod is a group of cloud security researchers with extensive expertise in cloud security, attacker techniques, and effective defensive strategies. Our expert team discovers and analyzes cloud risks and vulnerabilities to strengthen the Orca Cloud Security Platform and promote cloud security best practices. In addition, the Orca research team discovers and helps resolve vulnerabilities in cloud provider platforms. Since the start of 2022, Orca has discovered twelve major vulnerabilities in Azure and AWS, and worked with cloud service providers to resolve them.
Learn More About Identifying and Mitigating Cloud Security Risks
If you want to learn more about these particular risks and how Orca Security can help, register for our upcoming webinar on June 15, How To Fix 5 Critical & Common Cloud Security Risks in 2023. We also provide an online Cloud Risk Encyclopedia that allows you to search cloud risks and find detailed descriptions and remediation instructions.
If you would like to find out how the Orca Cloud Security Platform provides comprehensive visibility into cloud risks based on the context of your environment, you can schedule a demo, or sign up for a Free Risk Assessment.
