Go back

From GitHub to Account Takeover: Misconfigured Actions Place GCP & AWS Accounts at Risk

GitHub Account Takeover of AWS and GCP Accounts

Contents

In April 2023, Rezonate research team explored prevalent misconfigurations of GitHub integration with cloud native vendors. GitHub OIDC-based trust relations have been found with the critical misconfigurations that leave connected AWS/GCP accounts vulnerable to potential takeover attacks. Although this issue was discovered and reported in the past, we have found that dozens of GitHub Public Repositories, and potentially many private ones, have demonstrated this critical issue, leaving dozens of companies vulnerable. The team notified recognizable affected organizations, but there may be more private repositories and organizations at risk.

In this article, we will introduce the misconfiguration research process,  explain the OIDC implementation process that GitHub uses to authenticate to the cloud, present the misconfigurations that we have identified across various organizations, provide a step-by-step guide for discovering and fixing the problem, and propose how to avoid the issue completely.

Key Points

  • Rezonate research team has explored an attack vector that exposed AWS & GCP accounts to unauthorized access through misconfigured OpenID (OIDC) GitHub Actions role.
  • Based on our scans, these known misconfigurations exist in dozens of the GitHub public repositories that use Github OIDC provider to AWS or GCP.
  • During the last few weeks, the Rezonate team has reached out to a few dozens of vulnerable organizations and personal accounts, providing them with information in order to remediate this misconfiguration.
  • To check whether your GCP or AWS accounts have been affected by this misconfiguration, please refer to the “Remediation Guidelines” section.

Background

Cloud and SaaS technologies have made identity and access controls the connective tissue between operational tools and cloud-native environments.

To ensure business operations flow as seamlessly and as fast as possible, IAM and Devops teams are required to share administrative access and create trust relations between 3rd-party tools and their core cloud environments. The key challenge is to limit privileges and conditions on these cases, and to protect and monitor this highly-privileged administrative access.

One of the most common examples of trust relations can be found in a software CI/CD pipeline, where strong privileges and access to an organization’s Cloud infrastructure are provided. We’ve seen dozens of cases where this access path was exploited due to misconfigurations, lost credentials and access keys, and compromised supply chains such as the CircleCI incident, the NPM incident, and many others.

Figure 1: Attacker scans for misconfigured trust relations in GitHub, and uses them to impersonate a CI/CD app, gaining full access to AWS or GCP accounts.

Due to the highly-sensitive nature of these access paths, CI/CD vendors have added support for the OpenID Connect (OIDC) protocol to supply short-term credentials, which are considered more secure. The trend toward OIDC support is reflected through the announcements of GitHub, GitLab, and CircleCI within the last 2 years.

OIDC is a modern, secure authentication method for creating trust relationships, but when not configured correctly, the method can become the root cause of a hidden, critical access risk.

Even though these misconfigurations were reported in the past, in books, as well as in security blogs, the Rezonate research team has identified many organizations that remain vulnerable. 

GitHub OpenID Provider Integration

The GitHub OIDC deployment guide highlights many advantages to using OIDC over access keys. OIDC allows you to adopt good security practices, such as:

  • No cloud secrets: Eliminating the need to store cloud credentials as long-lived secrets. Instead, workflows will request and use a short-lived access token from the cloud provider through OIDC.
  • Authentication and Authorization management: Having granular control over how workflows can use credentials, using the cloud provider’s authentication and authorization tools to control access to cloud resources.
  • Rotating credentials: With OIDC, the cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires.

The following diagram provides an overview of how GitHub’s OIDC provider integrates with GitHub Actions and the cloud provider:

Figure 2: Overview of GitHub OIDC provider integration

In general, integration involves the following steps:

  • Start by creating an Identity Provider in the target cloud environment.
  • GitHub Actions will generate an OIDC temporary token containing execution context (such as the repository, organization, or branch).
  • GitHub will send a request to the cloud provider, containing the GitHub OIDC token.
  • The cloud provider will validate the token and the context, and exchange it with short-lived credentials that allow access to the cloud environment.

GitHub OIDC Integration with GCP & AWS

Integrating GitHub Actions through OIDC includes setting up trust between the cloud infrastructure and GitHub, which workflows can then use to access roles and service accounts.

Configure Trust

The process of configuring trust between the cloud provider and GitHub is similar between different cloud providers, and includes two main steps:

Let’s examine the setup for GCP and AWS.

Configure Trust with GCP

Based on Google Cloud documentation, the following process creates a Workload Identity Federation, which provides the issuer ID and basic attribute mapping.

Figure 3: Creating a Workload Identity Federation

Optionally, after configuring the attribute mapping according to the Google Cloud documentation, add Attribute Conditions such as a GitHub organization, repository, or branch.

Figure 5: Adding Attribute Conditions

Now that we have the Identity Provider configured, we can bind it to service accounts and allow GitHub to use them as part of its workflow. In the picture below we can see the github-actions-integration service account connected to the Identity Provider recently created. 

Figure 5: Bind service accounts to Identity Provider

Configure Trust with AWS

Similar to GCP, AWS starts with creating a new Identity Provider (OpenID Connect) with the GitHub Provider URL.

Figure 6: Create an Identity Provider in AWS

Next, we can create an IAM Role and reference the recently created Identity Provider, allowing users federated by the Identity Provider to assume roles in the account.

Figure 7: Create an IAM Role

Next, we name the role, add a description, and modify the access conditions of the role. By default the trust policy condition only includes audience filters.

Figure 8: Modify access conditions using filters

As mentioned in the GitHub integration documentation, it’s highly recommended that you limit access to specific repositories by adding filters against the token subject. Note that by default the AWS process does not enforce adding additional conditions. To add conditions, click the “Edit Policy” button, which reveals the following warning:

Figure 9: Missing additional conditions warning in AWS

Configure GitHub Workflow

Now that everything is configured from the cloud infrastructure side, the next step is to use the relevant GitHub actions as part of the workflow.

  • First, add permissions to the workflow, allowing it to read an OIDC token. Add the following permissions to the beginning of the workflow YAML file:
Figure 10: Add permissions to GitHub workflow
  • Next, add the matching action to the authentication process, based on the cloud provider:
    For AWS, use the configure-aws-credentials:
Figure 11: Add matching action to authentication process – AWS
Figure 12: Add matching action to authentication process – GCP

After performing the steps above, the integration process is completed and the workflow can perform operations in the cloud environment.

Potential Misconfiguration

Although the integration between the cloud and GitHub is relatively simple, potential misconfigurations could expose access to unauthorized parties.

GitHub articles refer to Conditional access as part of the integration process, however, the cloud infrastructure is not flagging or alerting when conditional access is not being used.

The lack of notification from the cloud provider during the setup increases the chances that an organization will have misconfigured trust settings. Those misconfigurations may result in roles and service accounts that can be abused by threat actors/attackers, leading to unauthorized access.

As a result of our research, we have discovered two specific types of misconfigurations that can be exploited by attackers to gain unauthorized access to a trusted cloud account.

Misconfiguration – Lack of Subject Condition

This misconfiguration occurs when the user who integrated the role did not add conditional limitations to cloud access. This misconfiguration allows any GitHub organization to access the cloud account.

Misconfiguration – Poorly-Defined Condition Pattern

This misconfiguration occurs when the conditions defined limit the subject, but are not restrictive enough and thus can be bypassed.

For example, the subject condition may include a wildcard to allow all the repositories in the organization to use the same role or service account as part of the GitHub Actions workflow. If the wildcard is mistakenly placed in the organization name (and not in the repository name), the condition allows unauthorized access from any GitHub organization with a name that fits into the pattern.

Identifying Vulnerable Organizations

To Identify vulnerable organizations and understand how prevalent misconfigurations are, we used GitHub search, looking for Actions workflows that use OIDC with AWS or GCP.

Using GitHub Code Search, we executed the following queries:

Figure 13: GitHub Code Query – AWS OIDC Workflows
Figure 14: GitHub Code Query – GCP OIDC Workflows

We split the query into subqueries to avoid reaching GitHub’s result limit, and eventually produced a list of roles and accounts that were potentially vulnerable.

Having the list, the next step was to identify what was misconfigured.

GitHub actions query returned thousands of results, and checking them through GitHub actions would be time-consuming. As a workaround, the team developed a different approach to identify vulnerable organizations using self-hosted runners.

Self-Hosted Runners

Github Self-Hosted Runners is a feature that allows organizations to execute parts of the GitHub Actions workflows in their own environment. The team discovered that by controlling the machine that authenticates against the cloud, we can extract the OIDC token, and perform batch tests on AWS roles and GCP service accounts outside of GitHub.

The batch tests included the following steps:

  • Setup a self-hosted runner:
    Download and install the GitHub self-hosted runner:
Figure 15: Our self-hosted runner
  • Configure the runner to proxy all of the traffic through our local proxy:
    Use the http-proxy parameter within the GitHub action.
Figure 16: The GitHub workflow configured to trigger token generation.
  • Intercept a workflow request and extract the Web Identity Token:
    After everything was ready, we triggered the workflow by performing a commit to the repository. The commit started a GitHub workflow which performed a network request to assume the target role with the Web Identity token. Then, we extracted the token from the request sent by the runner to AWS.
Figure 17: Extract token from runner request – AWS

Decoding the JWT Token reveals our sub, along with other identifiers that are being sent and logged by the cloud provider as part of the authentication process.

Figure 18: Decoding JWT token
  • Copy the token to our multithreaded script, which will check the potentially vulnerable roles.

Using a pre-developed script and leveraging Boto3 and Gcloud, we scanned a list of potentially vulnerable roles while having the JWT at hand.

Results

After reducing duplicate roles and service accounts, we scanned approximately 1500 roles and service accounts across GCP and AWS.

As for the first misconfiguration, lack of subject condition, we determined that dozens of the roles were vulnerable, allowing anyone to use them to access the accounts.

The second misconfiguration, poorly-defined condition, was harder to test and required setting up a dedicated GitHub organization per target. Thus, we performed a random test against 20 organizations, finding one of them to be vulnerable to this attack.

The vulnerable accounts included various organizations, including private companies, non-profit organizations, software development studios, and many personal accounts.

During the last few weeks we have reached out to the relevant organizations and people, sending them information regarding the vulnerable roles and sharing remediation guidance.

Remediation Guidelines

Could My Environment Be Affected? 

Based on our research, this type of misconfiguration is a risk for AWS and GCP users who use GitHub Actions with modern authentication (OIDC).

Identify Potential Misconfigurations: Lack of Subject Conditions

To identify this misconfiguration In AWS, check for roles that have no subject limitations in its trust policy.

Figure 19: Misconfigured Role with no Subject – Example – AWS

To identify this misconfiguration in GCP, check for service accounts connected to the Identity Provider that has access to the Entire Pool.

Figure 20: Misconfigured Role with no Subject – Example – GCP

Identify Potential Misconfigurations: Poorly-Defined Conditions

To identify this misconfiguration in AWS, locate the StringLike conditions for roles that are connected to the Identity Provider, and check for wildcards in the organization name.

Figure 21: Misconfigured Role with Poorly-Defined Condition Pattern – AWS

For example, in this case, we have a role that was originally intended to be used by different repositories within the Rezonate organization. Since the StringLike conditions included a wildcard in the organization name,  every organization that starts with “rezonate” can assume this role. This means that an attacker can create a new GitHub organization with the name “rezonateX” and get access to the role.

This misconfiguration option does not apply to GCP, as GCP does not support wildcards.

Identity Risks in the Rezonate UI

Rezonate customers should look for the security risk “GitHub Actions Role vulnerable to hijacking” in the Rezonate UI and follow the guided remediation steps attached to it.

Use a Script to Perform a Quick Scan

For the general public, we have released a script to our GitHub repository (link here), which performs a quick scan against the AWS account or GCP project and reveals possible vulnerable roles and service accounts.

Loading

Continue Reading

More Articles
8 Okta Security Best Practices to Implement Now

8 Okta Security Best Practices to Implement Now

Cyber attackers are continuously upping their game. They make it their mission to constantly search for user, system, and infrastructure vulnerabilities and gain unauthorized access to sensitive data.  With 61% of all data breaches involving compromised credentials. An IAM breach's consequences can vary from immediate financial losses to irreparable long-term reputational damage. Organizations must take proactive measures with specialized tools like Okta to identify and prevent IAM breaches. Okta is a leading identity and access management provider with excellent features to safeguard your digital identities against cyber attacks. In this article, we will discuss eight security best practices to get the most out of Okta. What is Okta Security? Okta Security is a robust identity management service designed for businesses and developers. It offers two leading solutions: Customer Identity Cloud and Workforce Identity Cloud. The Customer Identity Cloud is designed to secure consumer and Software as a Service (SaaS) applications across various industries, handling authentication, authorization, and secure access. On the other hand, the Workforce Identity Cloud aims to secure employees, contractors, and business partners, covering every part of the identity lifecycle. Regardless of Okta's reputation and capabilities, even they couldn't stop the most recent security breach. This highlights the importance of continuously monitoring your systems and being prepared to take action if something goes wrong. It doesn't matter how trusted a tool is; you should always be vigilant and prioritize security. Why Do You Need an Identity Provider Like Okta Security? Imagine your organization is a fort, holding your most valuable hidden digital treasures. In this context, identity provider Okta emerges as the watchful protector, improving the castle's defenses against IAM threats and safeguarding sensitive data. But the story doesn't end there. As your organization scales, the benefits of having such an identity provider will multiply. Enhanced security - Like the guardian at the castle gates, Okta centralizes access controls, authentication, and user management, ensuring that only those with the right keys gain entry to your digital assets. Increased productivity - If you have users who constantly access your resource, you can use single sign-on to allow them access resources without repeatedly re-entering credentials. Reduced IT workload - Okta can also act as the magician of your castle by automating various identity and access management tasks like user provisioning and freeing up IT resources. Regulatory compliance - Okta helps organizations meet compliance requirements around data security, access controls, and auditing. What Types of IAM Threats Might You Face? IAM attacks constantly change, and attackers keep trying different methods to find weaknesses in users or systems. Here are a few common types of IAM threats and how Okta protects your organization against them: Brute force attacks - Attackers try to guess user passwords through repeated login attempts. Okta prevents brute force attacks by locking accounts after several failed attempts. MFA push notification fatigue - Attackers flood users with MFA push notifications, hoping they accidentally approve one. Okta lets you set policies to limit the number of MFA verification messages sent within a period. Session hijacking - Attackers steal a user's valid browser session cookie and take over their account. Okta's device trust feature helps detect compromised sessions. Phishing - Attackers try to steal credentials via spoofed login pages. Okta's domain-bound certificates and email authentication features help block phishing attempts. 8 Okta Security Best Practices DevOps 1. Use Okta SDKs and Libraries Okta provides various SDKs and libraries for different programming languages and platforms. These pre-built code components and features are highly recommended when integrating Okta into your applications. In addition to smooth integrations, this approach provides several significant advantages: Saves time Ensure secure communication Standardize the IAM implementations Reduces the likelihood of coding errors Tips for selecting the best SDKs: Choose the SDK that matches your application's programming language. Regularly update the SDKs. Look for security vulnerabilities in the libraries. 2. Secure API Tokens API tokens are the keys to your digital fortress, providing access to stored digital assets. Therefore, securing API tokens is crucial to prevent unauthorized access to sensitive information and resources. Tips to secure API tokens: Store API tokens in a secure secret management solution rather than code or config files. When creating tokens, grant only the minimum scopes needed for that application. Set tokens to expire automatically after a shortened 30-90 days. Audit and revoke tokens that are no longer needed. Ensure tokens are transmitted only over secure channels like SSL/TLS. CISOs (Chief Information Security Officer) 3. Integrate with ITDR Solutions Identity Threat Detection and Response (ITDR) is a security solution category designed to detect, investigate, and respond to potential security threats that target an organization's identities, credentials, and cloud entitlements. It entails detecting unusual activities, identifying compromised credentials, integrating with identity and access management (IAM) policy enforcement, and more. It's important to note that integrating Okta with ITDR is a continuous process. While it helps to enhance an organization's security posture, it does require regular updates and reviews to ensure it evolves with the changing threat landscape and effectively mitigates identity threats. Here are a few tips to follow when integrating Okta with ITDR: Conduct a thorough analysis to understand the gaps in your current ITDR strategy and see if the ITDR vendor has good coverage for Okta related threats and behavioral analysis. Ensure you understand your organization's compliance requirements and see how Okta's features can help meet those requirements. Before full-scale implementation, conduct pilot testing to understand any potential issues and fix them. Conduct simulation exercises to help users understand how to respond to alerts and notifications generated through the Okta-ITDR integration. Set up real-time monitoring of identity threats leveraging Okta's analytics and reporting features. Ensure the ITDR solution integrates, streamlines, and prioritizes Okta's threat insights according to your business's threat models. Leverage Okta's API capabilities to integrate it with other systems in the organization's IT ecosystem. Implement Single Sign-On (SSO) functionalities to streamline access management and enhance security. 4. Develop an IAM Strategy When organizations scale, they face issues managing user identities and access across multiple systems. But, if you have a well-defined IAM strategy, you can easily tackle such situations. A typical IAM strategy consists of objectives, identity inventory, IAM solution selection, access control policies, and more. With Rezonate's IAM intuitive and collaborative IAM solution, you can gain real-time visibility over accounts, assets, and identity levels. It automatically uncovers and removes risky permissions. Rezonate integrates with Okta, so you'll be up and running within 15 minutes with just one-click, fast deployment.  Tips to follow when developing an IAM strategy: Clearly define the objectives and goals. Create workflows for user onboarding, offboarding, and role changes. Take stock of all user identities within your organization. Choose a robust IAM solution. Use RBAC to assign and manage permissions based on user roles. SecOps 5. Automate Account Lifecycles Automating account lifecycles involves creating processes to manage user accounts from creation to deactivation or removal automatically. This simplifies tasks related to onboarding, offboarding, and role changes. For example, when a new employee joins a company, automation will create an account, assign role-specific permissions, and provide access to the necessary resources. This ensures employees can access the tools and resources they need from day one. Tips to automate account lifecycles: Set up policies to provision and de-provision accounts immediately when employees join and leave. Set alerts to detect if users gain additional application access or privileged roles over time to curb privilege creep. Ensure automation is integrated with identity management, HR, and other relevant tools. 6. Regularly Audit Access and Privileges Regular access and privilege audits help organizations ensure users have appropriate access levels to perform assigned tasks. In addition, they help to identify security gaps, reduce the risk of unauthorized access, and ensure compliance with policies and regulatory requirements. Tips to follow when performing audits: Establish a routine audit schedule. Maintain precise records of user accounts, their roles, and their permissions. Identify and pay special attention to high-privileged accounts like administrators. Revoke access and privileges that are no longer needed. Implement RBAC. IAM Engineers 7. Leverage Multi-Factor Authentication (MFA) Multi-factor authentication (MFA) is a security measure that requires two or more verification methods to grant access to a system. MFA combines something you know (password) with something you have (mobile device) or something you are (fingerprint or face recognition). For example, consider a scenario where an employee's password gets somehow leaked. If you enabled MFA, the hacker couldn't access the account because they didn't have the second authentication factor. Here are a few tips to follow when enabling MFA: Enable MFA for all users. Select robust authentication methods such as one-time passwords (OTP), biometrics, or hardware tokens. Consider adaptive authentication, which assesses risk factors and adjusts the level of MFA required. Ensure there are backup authentication methods in case users lose their primary MFA device. 8. Configure Strong Password Policies Password policies are rules and requirements defined to strengthen the passwords users create. These policies typically include password complexity, length, and expiration time guidelines. Even without specialized tools, a strong password protects against brute-force attacks. Here are a few tips to consider when defining a password policy: Require passwords to include a combination of uppercase and lowercase letters, numbers, and special characters. Require a minimum length for passwords. Enforces regular password changes every 90 days. Prevent using common passwords like 'abcd1234'. Set rules to lock user accounts temporarily after a certain number of failed login attempts. How to Protect Your Okta Environment from Threats Okta is one of the leading identity providers around the globe. However, as organizations move their resources towards the cloud, we can see a significant increase in threats to cloud identities and access management. This highlights the importance of using specialized tools like Rezonate to detect and mitigate risks before they become critical. Rezonate is a modern identity and access management tool that integrates with Okta to help detect risks and threats across your Okta infrastructure. Moreover, it brings continuous risk monitoring, least privilege, real-time threat detection, and automated remediation to supercharge your IAM solution. Book a free demo of Rezonate today and witness firsthand how it can revolutionize your organization's access security.
Read More
7 Tips to Make Sense of the Gartner IAM Magic Quadrant

7 Tips to Make Sense of the Gartner IAM Magic Quadrant

The world of Identity and Access Management (IAM) is not just about selecting a vendor – it's about selecting the right vendor. In a rapidly evolving sector, making informed decisions is critical for your business to stay secure and efficient. With its long-standing reputation in tech research, Gartner has led the way in offering crucial insights into this domain. A telling projection is that by 2026, 90% of organizations will primarily rely on identity threat detection tools – a jump from less than 20% today. This shift underscores the criticality of understanding the IAM vendor landscape and making informed choices. What is the Gartner IAM Magic Quadrant and What Does it Mean? The Gartner IAM (Identity and Access Management) Magic Quadrant is a research methodology that presents a graphical representation of a market's direction, maturity, and participants. It offers an analysis of technology providers in the IAM domain, focusing on their ability to deliver and the completeness of their vision. The IAM Magic Quadrant evaluates the strengths and weaknesses of the most significant providers in the marketplace. It offers custom category weighting, showcasing the evolution of the vendor space over time. Furthermore, it incorporates user reviews to provide a comprehensive understanding of each vendor, ensuring a cap of twenty vendors to maintain the quality and significance of its insights. Getting included in the Magic Quadrant means getting exclusive approval from Gartner, which proves to your customers that you are an exceptional vendor.  The Four Quadrants: 1. Challengers Challenger providers have a good capability to execute but may not have a fully realized vision. They are solid and stable, often having a large market presence, but may lack innovative features or forward-looking strategies. 2. Leaders Leader vendors excel in both their ability to execute and the completeness of their vision. They are often the dominant players, demonstrating a clear understanding of market needs and exhibiting robust performance through a comprehensive range of products. Rezonate integrates with a Magic Quadrant Leader, Okta, to help detect risks and threats across your Okta infrastructure through least privilege best practices and auto-remediation. No matter how big a vendor’s reputation is, it’s always essential to consider solutions like Rezonate that continuously monitor your systems and offer real-time threat protection. 3. Niche Players Niche players focus on a specific segment or have a limited innovation capability beyond their niche. They may excel in their specialized domain but not offer a broad suite of solutions or expansive growth strategies. Source 4. Visionaries Visionaries are companies that showcase a strong ability to envision future market trends and plan accordingly, even if they might currently lack execution capability. They are innovative and forward-thinking, often introducing new features and capabilities ahead of the market. What are the Goals of the Magic Quadrant? The Gartner IAM Magic Quadrant is designed to help you navigate the often intricate landscape of IAM vendors. Its primary goals and benefits include: Informed Decision Making The Magic Quadrant serves as a guide for businesses to choose the right vendor, ensuring they evade the costly repercussions of a suboptimal decision. With a comprehensive analysis of each vendor's strengths and weaknesses, businesses can make choices that align with their specific needs and objectives. Optimized Expenditure The Magic Quadrant is pivotal in financial planning as it benchmarks vendor pricing against the market. This means businesses can show if they are getting value for money or if they can achieve the same or better outcomes at a more competitive price point. Minimized Complexity and Risk One of the unsung advantages of the Magic Quadrant is its analysis of contract terms and conditions. By doing so, Gartner helps shield businesses from unforeseen costs and potential pitfalls, ensuring a smoother engagement with vendors and a more predictable budgetary landscape. In effect, the Magic Quadrant is a strategic compass, guiding businesses toward vendors that meet their immediate needs and align with their long-term goals while ensuring cost-effectiveness and reduced risks. 7 Tips to Make Sense of the Gartner IAM Magic Quadrant Navigating the Gartner IAM Magic Quadrant can initially seem daunting, given its comprehensive analysis of vendors. However, understanding its methodology and nuances can help both IAM vendors aiming for a spot in the Quadrant and businesses seeking the best solution. Here's a breakdown of seven critical sections of the report: 1. Market Definition/Description Understanding the IAM market as defined by Gartner is crucial: “Gartner defines access management (AM) as tools that establish, enforce and manage journey-time access controls to cloud, modern standards-based web and legacy web applications.” For example, Gartner-approved capabilities provided by AM tools could include: API access control User authentication (e.g. least privilege and zero trust principles) Advanced lifecycle management capabilities Journey-time orchestration in the context of access management Internal access administration (e.g. user onboarding and provisioning) Reporting for compliance purposes Gartner's market definition ensures businesses are comparing vendors catering to the same market segment. When you align your vendor evaluations with Gartner's definition, you're better poised to select a solution that truly fits your needs. On the other hand, vendors should streamline their offerings to fit within this defined market. By doing so, they enhance their visibility and relevance in the Quadrant. Caption: This graph shows where the top vendors lie in the four quadrants. Source 2. Inclusion Criteria The inclusion criteria are akin to the gatekeepers of the Magic Quadrant. They stipulate the fundamental requirements a vendor must meet to be considered. For businesses like yours, this gives you confidence that every vendor in the Quadrant has already met a baseline of quality and capability. Vendors aiming for a spot should meticulously tailor their pitches and presentations to highlight how they meet or surpass these criteria. 3. Exclusion Criteria While the inclusion criteria set the stage, the exclusion criteria provide a reality check. Knowing who didn't make the cut – and why – can offer you clarity on Gartner's stringent standards. In contrast, vendors should steer clear of pitfalls that lead to exclusion. Avoiding exclusionary factors is paramount, whether this means ensuring a significant market presence or ramping up core IAM capabilities. 4. Evaluation Criteria Part 1 | Ability to Execute A vendor's operational prowess comes to the forefront with their ability to execute, encompassing everything from product quality to overall business health. For businesses, the Magic Quadrant offers a peek into a vendor's operational strengths and potential longevity in the market. Vendors can bolster their position by relentlessly improving product quality, fortifying their financial health, and refining their customer service approach. Table 1: Ability to Execute Evaluation Criteria Evaluation CriteriaWeightingProduct or ServiceHighOverall ViabilityMediumSales Execution/PricingHighMarket Responsiveness/RecordHighMarketing ExecutionMediumCustomer ExperienceHighOperationsLowAs of August 2022 Source: Gartner (November 2022) 5. Evaluation Criteria Part 2 | Completeness of Vision A vendor's foresight is illuminated through their completeness of vision. Businesses can glean insights into whether a vendor is merely keeping pace or truly pioneering the future of IAM using the Magic Quadrant. This criterion serves as a testament to a vendor's innovation and adaptability. Vendors can impress Gartner by immersing themselves in continuous market research, aligning their strategies with emerging trends, and remaining receptive to user feedback. Table 2: Completeness of Vision Evaluation Criteria Evaluation CriteriaWeightingMarket UnderstandingHighMarketing StrategyMediumSales StrategyLowOffering (Product) StrategyHighBusiness ModelMediumVertical/Industry StrategyLowInnovationHighGeographic StrategyHighAs of August 2022 Source: Gartner (November 2022) 6. Market Overview The IAM market is in constant flux, marked by innovations, challenges, and shifts highlighted in the Magic Quadrant report. The market overview section gives businesses a panoramic view of IAM industry activity, helping you align with prevailing best practices and be attuned to upcoming changes. Vendors can carve out a competitive edge by staying in sync with market movements and preemptively addressing emerging needs in their product offerings. 7. User Reviews In an age of information overload, authentic user reviews stand out. They offer businesses a raw, unfiltered view of a vendor's offerings, echoing the voice of real-world users. Gartner's rigorous process ensures these reviews are comprehensive and trustworthy. Vendors can enhance their Quadrant positioning by nurturing customer relationships, promptly addressing concerns, and cultivating an ecosystem where satisfied users are advocates. Navigate the IAM Landscape With a Gartner-approved Vendor The Gartner IAM Magic Quadrant provides you with a clear compass to navigate the IAM vendor space. By breaking down the market, evaluating vendors meticulously, and incorporating valuable user reviews, it offers companies like yours a robust tool to make strategic decisions in the realm of Identity and Access Management. But there’s more to the IAM industry than the Magic Quadrant report. Recognized as a Cool Vendor in the 2023 Gartner Cool Vendors Report in Identity-First Security, Rezonate is making waves with our forward-thinking approach. Our commitment to identity-centric security tackles the pressing challenges of compromised identities and rising breach costs. Explore Rezonate’s platform or request a demo to see firsthand how identity-first security can redefine your protection strategy.
Read More
Roy Akerman - 20 Minute Podcast on Identity Security

Podcast: A New Approach To Cybersecurity – An Identity-Centric Security One

In this riveting new episode of 20 Minute Leaders, Rezonate's CEO, Roy Akerman, the visionary mind behind Rezonate, a groundbreaking cybersecurity firm aimed at securing identities and protecting businesses. With 85% of today's attacks stemming from compromised identities, machines, or users, the need for a cybersecurity revolution is louder than ever. Roy enlighteningly delves into how Rezonate was born out of this urgent demand, Rezonate's innovative approach that disrupts traditional systems, and the future of cybersecurity. Don't miss out on this deep dive into the world of tech security, where old paradigms are challenged and revolutionary solutions are birthed. To listen to the full episode: https://youtu.be/F0xvRBrvS_M Spotify: https://open.spotify.com/episode/6dzJlrSrmVshYOGh4j6Jli?si=IG7SZiKNQOSBb4SXKlAEwA For more information, contact us or request a free demo. Like this article? Follow us on LinkedIn.
Read More
See Rezonate in Action

Eliminate Attacker’s Opportunity To Breach Your Cloud today

Organizations worldwide use Rezonate to protect their most precious assets. Contact us now, and join them.