Go back

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.


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 CriteriaWeighting
    Product or ServiceHigh
    Overall ViabilityMedium
    Sales Execution/PricingHigh
    Market Responsiveness/RecordHigh
    Marketing ExecutionMedium
    Customer ExperienceHigh
    As 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 CriteriaWeighting
    Market UnderstandingHigh
    Marketing StrategyMedium
    Sales StrategyLow
    Offering (Product) StrategyHigh
    Business ModelMedium
    Vertical/Industry StrategyLow
    Geographic StrategyHigh
    As 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.


    Continue Reading

    More Articles
    Defending Azure Active Directory (Entra ID): Unveiling Threats through Hunting Techniques

    Defending Azure Active Directory (Entra ID): Unveiling Threats through Hunting Techniques

    Azure Active Directory (Entra ID) stands as one of the most popular and widely-used cloud-based identity and access management services provided by Microsoft. It serves as a comprehensive solution for managing user identities and controlling access to a diverse range of resources, both within the Microsoft Azure ecosystem and across other platforms. Azure AD offers crucial features like single sign-on (SSO), multi-factor authentication (MFA), role-based access control (RBAC), and directory services.  Understanding  Azure AD logs is essential for maintaining a robust security posture in a cloud-centric environment. These logs provide a comprehensive record of user activities, authentication attempts, and access permissions. By analyzing Azure AD logs, organizations can detect and respond to suspicious or unauthorized activities promptly, identify security threats, track user behavior, and ensure compliance with regulatory requirements. Understanding these logs is pivotal in proactively mitigating security risks, protecting sensitive data, and safeguarding the integrity of Azure-based services, making it a fundamental aspect of any effective cybersecurity strategy in the cloud. Reading this blog will provide you with: Understanding of the logs that can be extracted from your Azure AD, and how. Knowledge about how to analyze these logs, and get the right information out of them. Learning about more than 10 Threat scenarios and corresponding hunting queries that you can run in your own environment to identify threats. Access to a tool Rezonate wrote to extract logs from AzureAD to any preferred analysis platform of your choice. Azure Active Directory Log Sources Azure Active Directory (Azure AD) offers two log sources that capture different types of events and activities within the Azure AD environment. These logs provide valuable insights for monitoring, security, and compliance purposes: Sign-in Logs: capture information about user sign-ins, including successful and failed attempts, sign-in locations, device details, and authentication methods used. Directory Audit Logs: capture information about various administrative activities, such as changes to user accounts, group memberships, application access, role assignments, and permission modifications. Data retention settings for the different licensing levels can be found here. Azure AD Sign-in Logs Azure AD sign-in logs are records that capture information about user sign-in activities within the Azure Active Directory (Azure AD) environment. These logs provide insights into the authentication and access activities of users as they interact with Azure AD-integrated applications and services. Sign-in logs are a crucial component of monitoring and maintaining the security of an organization's identity and access management infrastructure. The full structure of the sign-in logs can be found on Microsoft’s official reference page. Every data-point  in the log record could be useful in certain use cases, but we highlighted some of them  that you should focus on for most investigations and hunting scenarios: IdUnique identifier for the event.CreatedDateTimeEvent time.ActivityDisplayNameThe name of the activity, used as the type of the event. The full list can be found in Microsoft’s documentation.AppId The identifier of the Azure AD application that the entity logged in to.AppDisplayNameThe name of the Azure AD application that the entity logged in toUserPrincipalNameThe user name that was used to sign in.DeviceDetailThe device information from where the sign-in occurred. This property includes the client’s operating system and browser details.IpAddressThe IP address that was used for the authentication. UserAgentThe user agent that was used for the authentication.StatusIndicates the result of the sign-in. The full list of errors can be found in Microsoft’s documentation.IsInteractiveIndicates if the sign-in was interactive or not.CorrelationIdA unique identifier that is used to correlate other logs that are related to a specific sign-in event.  Sign-in logs are separated into four groups: Interactive sign-in: Interactive sign-ins occur when a user logs in using a web browser, a mobile app, or another client application, and the user directly interacts with the authentication prompts.  Non-interactive sign-ins: These logs typically involve automated processes, such as service accounts, background tasks, or system-to-system interactions, where user intervention is not necessary for authentication to occur. Service principal sign-ins:  A service principal is a security identity used by applications, services, or automation tasks to access Azure resources and perform specific actions. Service principal sign-ins occur when these identities are used to authenticate and access resources or services. Managed identity sign-ins: A managed identity is a feature in Azure that provides an identity for resources like virtual machines, Azure services, and applications. This identity can be used to authenticate with various Azure services without requiring explicit credential management. Managed identity sign-ins occur when resources or applications use their managed identity to authenticate and access other Azure services, APIs, or resources. Azure AD Directory Audit Logs Azure AD directory audit logs are records that capture details about administrative activities and changes within an Azure Active Directory (Azure AD) environment. These logs provide insights into actions taken by administrators or privileged users that impact user identities, groups, roles, and directory settings. Directory audit logs are essential for maintaining security, compliance, and accountability within an organization's identity and access management infrastructure. These logs help track changes, monitor user activities, and investigate potential security incidents. The structure of the audit logs can be found on Microsoft’s official reference page. Each data point in this log could be useful but we highlighted some of them that you should focus on for most investigations and hunting scenarios: IdUnique identifier for the event.ActivityDateTimeEvent time.ActivityDisplayNameThe name of the activity is used as the type of the event. The full list can be found in Microsoft’s documentation.InitiatedBy Provides information about the entity that performed the action that triggered the event.TargetResourcesThe resources that were involved in the event.ResultIndicates the result of the eventResultReasonLogs the reason for a failure if the event was not successful.CorrelationIdA unique identifier that is used to correlate the event to a specific sign-in event.  Exporting Azure AD Logs Exporting  Azure AD  logs requires one of the following roles: Reports Reader Security Reader Security Administrator Global Reader Global Administrator There are two primary approaches to accessing Azure AD logs. 1. Azure AD Console: In the monitoring section, you will find both “Sign-in Logs” and “Audit logs”. Login to Azure Portal From the Azure Services, select Azure Active Directory From the left pane, navigate to the “Monitoring” section Each sign-in event, of an interactive user, is displayed as a single event and can be expanded to view more detailed information: The tree remaining sign-in log groups are displayed differently. Instead of showing each sign-in attempt in a single event, the sign-in events are grouped by the target application that the user signed into: 2. Exporting The Logs To CSV\JSON While accessing the Azure AD logs from the Azure portal is easy, it is recommended to export the logs out of  Azure AD  so you will be able to cross reference Azure AD activity with other data sources and perform advanced queries and analyze it in scale. To export logs from Azure AD, we recommend using an Azure AD application and Microsoft Graph API. Follow the instructions below to create a new application for logs export in your tenant: Sign in to the Azure portal using your administrator account. From the Azure services, choose Azure Active Directory. From the left pane, choose App Registrations Click on “New Registration”. Name it as you wish. In “Supported account types” select  “Accounts in this organizational directory only (Default Directory only - Single tenant)”. Click Register. In the newly created application page, from the left pane, choose API Permissions. Click on Add permission. Click on Microsoft Graph - Application Permissions. Type “AuditLog” in the search box. Click on “AuditLog.Read.All”, and then “Add permissions”. Grant admin consent for the default directory - In other words, allow the application to use the assigned privileges. From the left pane, choose “Certificates and Secrets” Click on “New client secret” Choose your desired expiration date. Use the new secret to authenticate to Azure AD and query your logs. Let the Hunt Begin In this section, we will guide you through some of the top-relevant threat scenarios to look out for, explain them, mark the Relevant Azure AD Event Sources, align to the specific MITRE ATT&CK technique, and include our own queries in Postgres query syntax. Scenario 1 - Brute Force on an Azure AD User A brute force attack on an Azure AD user involves an attacker repeatedly trying different passwords to guess correctly and eventually gaining unauthorized access. To hunt for any occurrence of this scenario, you can search for an actor that performed more than X failed login attempts on at least Y target user, failing or ending up with a successful login. In cases of failure, the activity may result in a user's lockage. (Read more about Microsoft’s Smart Lockout protection mechanism) Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Get users who failed to login from the same IP address at least 5 times SELECT "userPrincipalName", "ipAddress" , "appDisplayName", "userAgent", count(id) as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity siaaae WHERE "errorCode" = 50126 -- Error code for invalid credentials AND "createdDateTime" > now() - interval 'X hours' GROUP BY "userPrincipalName", "ipAddress", "appDisplayName", "userAgent" having count(id) >= 5 ORDER BY "eventCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Attention: The user-agent field in authentication logs indicates the client application employed for the authentication process. To bypass modern authentication requirements like Multi-Factor Authentication (MFA), threat actors might exploit legacy authentication protocols such as SMTP. In cases where a legacy protocol is utilized for authentication, the user agent in the logs will be identified as 'BAV2ROPC'. In case you encounter a brute force attempt with the user agent set to 'BAV2ROPC', it is crucial to consider it as malicious unless proven otherwise. Scenario 2 - Password Spray on an Azure AD Account A password spray attack on an Azure AD account involves an attacker repeatedly submitting different usernames with the same password (a small set of passwords) to eventually manage to log in and gain unauthorized access. To hunt for any occurrence of this scenario, you can search for an actor that performed more than 1 failed login attempt on at least Y unique target user, from the same IP address. Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Get users who failed to login from the same IP address to at least 5 unique users SELECT "ipAddress", "appDisplayName", "userAgent", count(distinct "userPrincipalName") as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity siaaae WHERE "errorCode" = 50126 -- Error code for invalid credentials AND "createdDateTime" > now() - interval '1000 hours' GROUP BY "ipAddress", "appDisplayName", "userAgent" having count(id) >= 5 ORDER BY "eventCount" desc -- For Each result, check if the source IP address managed to login to the target user AFTER the "lastEvent" time MITRE Technique Credential Access | Brute Force | ATT&CK T1110 Scenario 3 - Multiple User Lockouts In certain instances of brute force attacks, the malicious actor may lock out the targeted users during their unauthorized access attempts. To identify such scenarios, we can employ a detection method that involves searching for multiple user lockouts originating from a single IP address. Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Search for login attempts to disabled users SELECT "ipAddress", count(distinct "userPrincipalName") AS "userCount", "appDisplayName", "userAgent", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 50053 -- Error code for user locked out AND "createdDateTime" > now() - interval 'X hours' GROUP BY "ipAddress", "appDisplayName", "userAgent" having count(distinct "userPrincipalName") >= 5 ORDER BY "userCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 4 - Multiple Authentication Failures During MFA Challenge An attacker that managed to compromise a credential set of an AzureAD user that is protected by MFA, upon authentication, will generate a specific sign-in log with the error code 500121 which correlates with the following message: “The user didn't complete the MFA prompt. They may have decided not to authenticate, timed out while doing other work, or have an issue with their authentication setup.” We can highlight suspicious IP addresses that generated multiple events with the mentioned error code.  Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Search for failed authentication attempts during MFA challenges SELECT "userPrincipalName", "ipAddress", "appDisplayName", "userAgent", count(id) as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity siaaae WHERE "errorCode" in 500121 -- Error code for no MFA response AND "createdDateTime" > now() - interval '2000 hours' GROUP BY "userPrincipalName", "ipAddress", "appDisplayName", "userAgent" having count(id) > 1 ORDER BY "eventCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 5 - Authentication Attempt to a Disabled User  In some cases, Azure AD user accounts might have been disabled due to security concerns, or maybe even as part of employee off-boarding. Monitoring login attempts to disabled users can help you detect unauthorized activities. Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Search for login attempts to disabled users SELECT "ipAddress", count(distinct "userPrincipalName") AS "userCount", "appDisplayName", "userAgent", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 50057 -- Error code for user disabled --AND "createdDateTime" > now() - interval 'X hours' - optional filter GROUP BY "ipAddress", "appDisplayName", "userAgent" ORDER BY "userCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 6 - Suspicious User Consent to Application When an attacker gains access to an Azure AD Tenant, they can create a new multi-tenant application equipped with specific API permissions such as Mail.Read, Mail.Send, Mailboxsettings.ReadWrite, Files.ReadWrite.All and User.ReadBasic.All, of which do not require administrative consent. Next, the attacker invites external users (potential victims) to use this application. Upon the first login by a new user to the attacker's application, a "Consent" prompt appears. If the user grants consent to the application, it enables the application to perform actions on behalf of the user, potentially leading to unauthorized access and misuse of the user's data and resources. We can utilize non-administrative consents to detect privileged applications that have access to user data. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Search for non-administrative application consent select id,dn,"newValue" from (select id, jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'displayName' as "dn", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' as "newValue" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName"='Consent to application') as subsearch where dn='ConsentContext.IsAdminConsent' and "newValue"='"False"' MITRE Technique Initial Access | User Consent | ATT&CK T1204  Scenario 7 - Persistence Via Service Principal Credentials An attacker could establish a persistence mechanism by adding new credentials to an already existing Azure AD application if one of the following applies to them: Application Administrator  Global Administrator (GA)  microsoft.directory/applications/credentials/update Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Search new application credentials events SELECT "id","user","ip", "activityDateTime", "activityDisplayName", "property", count("oldVals") AS "oldValsCount", count("newVals") AS "newValsCount" FROM ( SELECT "id","user","ip", "activityDateTime", "activityDisplayName", "property", jsonb_array_elements("oldVal"::jsonb) AS "oldVals",jsonb_array_elements("newVal"::jsonb) AS "newVals" FROM ( SELECT "id", "initiatedBy"->'user'->>'ipAddress' AS "ip", "initiatedBy"->'user'->>'userPrincipalName' AS "user", "activityDateTime", "activityDisplayName", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'displayName' AS "property", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'oldValue' AS "oldVal", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' AS "newVal" FROM directory_audit_activity_azure_ad_entity WHERE "activityDisplayName" = 'Update application – Certificates AND secrets management ' ) AS subquery WHERE "oldVal"!='[]' and "oldVal" is not null) AS query GROUP BY "id","user","ip", "activityDateTime", "activityDisplayName", "property" HAVING count("newVals")> count("oldVals") MITRE Technique Persistence | Additional Credentials | ATT&CK T1098 Scenario 8 - Admin Privileges Assignments Not Via PIM Azure AD PIM (Azure Active Directory Privileged Identity Management) is a Microsoft Azure service that helps organizations manage, control, and monitor access to privileged roles and resources in their Azure environment. It allows administrators to grant just-in-time privileged access, enforce approval workflows, and provide auditing and reporting for enhanced security and compliance.It is important to monitor Azure AD admin privileges assignments, not through PIM, since this behavior should not be common, and might suggest that an admin account is compromised. Relevant Azure AD Event Source  Azure AD Directory Audit Logs Query -- Search AAD administrative privileges assignment not via PIM select "ipAddress", "initiatedUser",category,"operationType", "targetResourceType", coalesce("targetUser","targetApp") as "targetDisplayName", ass3."value" as "newRoleName" from (select "id","ipAddress","userPrincipalName" as "initiatedUser",category,"operationType","TR"->'type' as "targetResourceType", nullif("TR"->'userPrincipalName', 'null') as "targetUser", nullif("TR"->'displayName', 'null') as "targetApp" from directory_audit_activity_azure_ad_entity daaaae , jsonb_array_elements("targetResources") as "TR" where category='RoleManagement' and "operationType" ='Assign' and "targetResources"::text like '%dmin%' and ("initiatedBy"->'app'->>'displayName' != 'MS-PIM' or "initiatedBy"->'user' is not null)) bq, (select * from (select "id",jsonb_array_elements("sub")->>'newValue' as "value", jsonb_array_elements("sub")->>'displayName' as "valueName" from (select "id",jsonb_array_elements("targetResources")->'modifiedProperties' as "sub" from directory_audit_activity_azure_ad_entity where category='RoleManagement' and "operationType" ='Assign') base1) base2 where "valueName" = 'Role.DisplayName') as base3 where bq."id" = ass3."id" and "targetResourceType"!='"Role"' MITRE Technique Privilege Escalation | Privilege Assignment via Valid Account | ATT&CK T1078 Scenario 9 - Account Hijacking Social engineering for initial access is on the rise. These techniques are simple in most cases and do not require much technical knowledge. Attacks such as phishing, MFA relay, or even buying credentials online may help attackers compromise user accounts.Usually, when an adversary compromises a user, gaining persistent access to that account is important. To do so, the adversary might change the user’s password and enroll a new MFA device. In some cases maybe even delete the original user’s factors.The following query identifies user accounts that performed a series of actions from an IP address that is not being used often by the organization, and during a short period of time - which might suggest that these accounts are compromised. The actions that this query searches for are: Self-password reset MFA enrollment MFA deletion  Relevant Azure AD Event Source  Azure AD Directory Audit Logs Azure AD Sign-In Logs Query -- Search multiple security information changes from a rare location in a short timeframe select * from(with org_ips as (SELECT count("timebucket"), "ipAddress","countryOrRegion" FROM ( SELECT DATE_TRUNC('day', "createdDateTime") AS TimeBucket, COUNT(distinct "userPrincipalName") AS "userCount", "ipAddress","countryOrRegion" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 0 AND "createdDateTime" > now() -interval '1 week' GROUP BY TimeBucket, "ipAddress", "countryOrRegion" HAVING COUNT(distinct "userPrincipalName") > 1 ) subquery GROUP BY "ipAddress","countryOrRegion" HAVING count("timebucket") > 1) select count(distinct "activityDisplayName") as distinct_event_count, min("activityDateTime") as first_event, max("activityDateTime") as last_event, daaaae."ipAddress", "userPrincipalName",array_agg(distinct "activityDisplayName") as events, "result", age(max("activityDateTime"),min("activityDateTime")) as duration, extract(EPOCH FROM max("activityDateTime")) - extract(epoch from min("activityDateTime")) as duration_epoch from directory_audit_activity_azure_ad_entity daaaae , org_ips where "activityDisplayName" in ('Reset password (self-service)', 'Self-service password reset flow activity progress', 'User deleted security info', 'User registered security info', 'User started security info registration') and daaaae."ipAddress" not in (select distinct org_ips."ipAddress" from org_ips) and "result"='success' group by "userPrincipalName",daaaae."ipAddress", "result") base where distinct_event_count = 5 and duration_epoch <= 604800 MITRE Technique Initial Access | Social Engineering and Phishing | ATT&CK T1566 Scenario 10 - Abusing Third-Party Users (Supply Chain Attack) Many Azure AD tenants are trusted by third-party accounts - IT providers, security tools, or maybe trusted partners. Third-party accounts should perform directory changes only if the activity is authorized by the tenant administrator. Use the following query to detect changes performed by guest accounts in your organization. Unauthorized activities may suggest that the third-party account is compromised  Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Guest directory changes select daaaae."activityDateTime", daaaae."ipAddress", daaaae."userPrincipalName", daaaae."activityDisplayName", daaaae."result", jsonb_array_elements(daaaae."targetResources")->>'userPrincipalName' as "external_user_name", siaaae."homeTenantId", siaaae."resourceTenantId" from directory_audit_activity_azure_ad_entity daaaae, sign_in_activity_azure_ad_entity siaaae where "result" ='success' and daaaae."correlationId" = siaaae."correlationId" and siaaae."homeTenantId" is not null and siaaae."homeTenantId"!=siaaae."resourceTenantId" MITRE Technique Execution | Trust Relationships | ATT&CK T1566 Scenario 11 - Abusing Single Password Authentication Single-factor authentication is a security risk that is best avoided by enforcing MFA, but it is not always possible to do so. Adversaries will often try to abuse users that are not protected by MFA. Use the following query to monitor single-factor authentication from non-organizational IP addresses. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Guest invites with org_ips as (SELECT count("timebucket"), "ipAddress","countryOrRegion" FROM ( SELECT DATE_TRUNC('day', "createdDateTime") AS TimeBucket, COUNT(distinct "userPrincipalName") AS "userCount", "ipAddress","countryOrRegion" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 0 AND "createdDateTime" > now() -interval '1 week' GROUP BY TimeBucket, "ipAddress", "countryOrRegion" HAVING COUNT(distinct "userPrincipalName") > 1 ) subquery GROUP BY "ipAddress","countryOrRegion" HAVING count("timebucket") > 1) select "createdDateTime", "ipAddress", "autonomousSystemNumber", "countryOrRegion", "userPrincipalName" , "appDisplayName", "conditionalAccessStatus" from sign_in_activity_azure_ad_entity siaaae where "authenticationRequirement" ='singleFactorAuthentication' and "errorCode" = 0 and "isInteractive" = true and "ipAddress" not in (select distinct "ipAddress" from org_ips) and "countryOrRegion" not in (select distinct "countryOrRegion" from org_ips) MITRE Technique Initial Access | Valid Cloud Account | ATT&CK T1078.004 Scenario 12 - Azure AD Sync Abuse Azure AD Connect is a Microsoft tool that enables synchronization and integration between on-premises Active Directory (AD) and Azure Active Directory (Azure AD). It allows organizations to extend their on-premises identity infrastructure to the cloud, providing users with a seamless single sign-on experience across both environments.  AAD Connect synchronizes user accounts between on-premises domain controllers and AAD tenants, utilizing a privileged user account authorized to update to the AAD directory. A compromised domain controller could allow an attacker to move laterally to Azure AD by extracting the login credentials of an AAD Connect user.  Relevant Azure AD Event Source  Azure AD Directory Sign-In Logs Query -- Search AAD Connect user abuse select "createdDateTime", "ipAddress", "countryOrRegion", "userPrincipalName", "appId","appDisplayName", "errorCode" from sign_in_activity_azure_ad_entity siaaae where "userPrincipalName" ilike 'Sync_%' and "appDisplayName" not in ('Microsoft Azure Active Directory Connect','') MITRE Technique Initial Access | Valid Cloud Account | ATT&CK T1078.004 3 Additional Queries For Azure AD Access Governance On top of the scenarios mentioned above, there are additional relevant queries that can be used to hunt for threats in an Azure AD tenant. Their results are harder to rely on since they require having a deeper context of the regular activities in the organization to differentiate the legitimate operations from those that may be part of an actual threat. For example, a user was assigned an administrative role. It could be malicious or legitimate, and requires triage for a verdict:  Who performed the action? Is this the first time this actor assigns privileges?  Are there any client characteristics that do not make sense coming from that actor? Query 1 - New Application Creation Malicious applications can serve adversaries to get their first foothold in an Azure AD tenant. Review the installed applications that were installed by administrators. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Search for new AAD applications select "activityDateTime", "ipAddress", "userPrincipalName", "activityDisplayName", "result", jsonb_array_elements("targetResources")->>'displayName' as "appName" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName" ='Add application' MITRE Technique https://attack.mitre.org/techniques/T1204/ Query 2 - A Guest Was Invited to the Organization Guest users can be invited to an Azure AD tenant - This means that users from different Azure AD tenants can access your tenant. It’s important to review these invites to make sure that only authorized third-party users will be invited. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Guest invites select "activityDateTime", "ipAddress", "userPrincipalName", "activityDisplayName", "result", jsonb_array_elements("targetResources")->>'userPrincipalName' as "external_user_name" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName" ='Invite external user' MITRE Technique https://attack.mitre.org/techniques/T1199/ Query 3 - New Authentication Policy Exclusion Azure AD Conditional Access Policy is a powerful feature that controls access to the organization based on specific criteria. If a user or a group of users are excluded from a conditional policy, they might put the organization at risk. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Policy Exclusions select "activityDateTime", "userPrincipalName", category, "activityDisplayName", "operationType",jsonb_array_elements("targetResources")->>'displayName' as "policyName", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' as "newConditions", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'oldValue' as "oldConditions" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName"='Update conditional access policy' MITRE Technique https://attack.mitre.org/techniques/T1556/ Rezonate Tool For Exporting Azure AD Logs As promised, we have included 2 tools that can be used to accelerate the application creation and the log extraction process. They are both available in our GitHub repository.
    Read More
    Rezonate Compliance SOC2

    How Rezonate Maintains Audit-Ready State Using Rezonate

    We all understand the importance of maintaining strong security protocols and controls. That’s why Rezonate decided to invest in the SOC 2 Type 2 compliance early on, and after only one month since our out of stealth announcement, we successfully achieved attestation. What exactly is SOC 2 Type 2 certification, and why is it important to you? SOC 2, or System and Organization Controls (SOC) 2 type 2 is a widely recognized set of standards that ensure a company’s controls have been independently examined and tested.  The “Type 2” designation refers to the fact that the audit covers a period of time, meaning that a company has not only implemented proper controls, but also demonstrated their continuous effective operation over a period of time.  Which is the key point I want to highlight here: a point-in-time validation vs. continuous readiness. Rezonate protects Rezonate Following any compliance requirements can be quite challenging. For starters, you need to fully understand the specific framework by analyzing and interpreting the right categories and controls. Then, using different assessment tools and manual efforts, you compile a list of all requirements, identifying what has been completed and what needs to be done, ensuring that the process is properly documented, logged, and monitored. So, how can you take steps to remove manual time-consuming actions, excel at all delicate tasks, ensure an error-prone process and achieve zero exception compliance? At Rezonate, we, the Security & DevOps team, use the Rezonate Cloud Identity Protection Platform (CIPP) on a daily basis for several use cases. As part of our ongoing protection of - our own human and compute resources’ IdP-IaaS identities and every access attempt to and from our cloud-native stack -  we ensure continuous compliance readiness across key identity-first trust principles defined by the SOC 2 audit: Security - Enforce the protection of data and systems, against unauthorized access, enforce MFA, and strengthen access controls. Strict inbound and outbound rules. Availability - Maintain availability SLAs at all times. Building inherently fault-tolerant systems which do not crumble under high load. Invest in network monitoring systems and DR plans in place. Confidentiality - Restrict and monitor access to organization’s confidential data and adhere to the principle of least privilege. We do that with the goal of continuously improving our controls and processes, ensuring that we are always meeting the highest standards in the industry. In a real-world and active environment, drifts may happen, however the process we’ve built around it course-correct itself. Protect identities, access, systems, and data We operate in a faced paced environment and therefore our infrastructure changes fast. Yet, we still allow our team the flexibility required to build fast - without compromising security. Using the Rezonate platform, our customers understand the identity security posture with complete visibility of their identities, policies, and access requests to meet all IAM aspects required for the security, availability, and confidentiality principles. Centralized identity inventory - Up to date inventory of all identities: employees, 3rd party vendors, machine resources, roles, groups, applications, and all required context across your multi-IdP / multi-cloud infrastructure. Access events - Discover and understand every access performed on or from a monitored identity, since its creation time to its last active session and activity performed. Privileges analysis - Evaluate entitlements provided to actual usage and true need for access and business operation. Behavior baseline & drift - Analyze every access request to critical data and application and realize possible risk across our IdPs and cloud infra. Risky exposures - Detect and better understand critical exposures, new access requests, and policy distribution to our engineering and overall staff. While we evaluate each request and relevant context to uncover potential hidden interdependencies, risk and implications. Threat detection - Detect any malicious impersonating, access rights, and excessive privileges, while evaluating possible impact, and taking action before damage occurred. Remediate - Proactively enforce a real-world least privileged access where Rezonate’s DevOps can ‘flex’ policy for unnecessary and risky privileges and ‘relax’ entitlements and access privileges for confirmed benign ones for increased productivity and agility. We have built this mechanism, all while abiding compliance mandates, to comply and stay audit-ready despite complex architectures to protect our most trusted asset - our customers’ data. Be able to provide required proof for observation period instantaneously without the manual effort involved.  If you want to speak with our team on how we are leveraging the Rezonate platform to protect Rezonate and by doing that, maintain SOC 2 Type 2 audit readiness for everything related to your identity and access, sign up for a demo or simply let us know info@rezonate.io.  Thank you to our partners, EY and Scytale, for their partnership on this and future milestones. 
    Read More
    What is ITDR (Identity Threat Detection & Response) and Things to Look Out For

    What is ITDR (Identity Threat Detection & Response) and Things to Look Out For

    In the brick-and-mortar world, our physical presence assumes our identity. But the virtual world disrupts this age-old presumption. From pseudonyms to shadow identities and avatars to digital twins, we have many ways to represent our identity online.  However, 80% of cyberattacks today leverage identity-based attacks, and the cloud-based landscape only makes verification more difficult and hackers more excited. That’s why ITDR has emerged as an indispensable approach to counter cybersecurity threats. In this article, we will understand the concept of ITDR and delve into the security challenges addressed by it. We will also reveal seven key features and capabilities every ITDR platform should have. What is ITDR? Identity Threat Detection and Response (ITDR) is one of the approaches to cybersecurity risk mitigation. Before understanding the goal of ITDR, it's essential to recognize the difference between these key terms: Credentials prove who you are. Privileges define what you can do. Access is the ability or permission to interact with resources. Identity providers validate and assert your identity. Cloud resources are the digital assets you might want to access in a cloud environment. ITDR establishes processes to prevent, monitor, detect, and mitigate identity threats related to user and machine identities with access to the cloud infrastructure, IAM infrastructure (such as identity providers like Azure AD and Okta), and third-party SaaS applications. The rise of cloud computing, remote working, digital transformation, and decentralized identities have made credentials and user or system identities a prime target for cybercriminals. Therefore, the process of verifying an identity (authentication), determining what that identity can do (authorization), and the actual identity data itself are all potential attack vectors. For this reason, ITDR is focused on detecting and responding to malicious activities and threats associated with the access journey: authentication, authorization, and the management of actual identities. It uses capabilities like real-time monitoring, analytics, and AI-driven pattern analysis to pinpoint anomalies or suspicious activities and alert security teams to trigger fast incident response.  Source How is ITDR Different From EDR and XDR? ITDR, EDR (Endpoint Detection and Response), and XDR (Extended Detection and Response) are all security frameworks or solutions designed to detect and respond to threats. However, their goals and scopes of protection differ. Here's a breakdown of their differences: ITDR Focuses on the security of identities and their associated access.  The access journey (including authentication, authorization, and actual identity management) forms the basis of ITDR's threat detection. Ensures only legitimate users can access resources and quickly detects and responds when identities are misused or compromised. EDR Focuses on endpoints, including desktops, mobile devices, and other connected hardware.  Continuously monitors, detects, investigates, and remediates threats on endpoint devices. Provides tools for analysis and incident response.  XDR Takes a more comprehensive approach by looking beyond just endpoints. Combines data from endpoints, networks, servers, cloud resources, emails, and other environments. Provides a comprehensive view of your threat detection program.  Detects more sophisticated attacks by correlating data from various sources and extending the security perimeter.  Challenges of EDR and XDR Both EDR and XDR are based on the principle of securing tangible assets of your organization's network, such as workstations, servers, routers, and gateways. However, routine maintenance, upgrades, and network expansions make maintaining a consistent security posture and threat detection program challenging. Moreover, technological advancements add newer endpoints to the network, expanding the attack surface.  Why ITDR Provides a Solution The ITDR approach to cybersecurity is unique in response to the changing threat detection landscape. It focuses on identity, which is not a tangible asset of the network – it is an intangible concept.  There’s been a huge increase in sophisticated identity-based attacks, such as privilege escalation, lateral movement techniques, or data exfiltration by malicious insiders and external threat actors that compromise the super admins who manage the IAM infrastructure. Given this surge, ITDR ensures that identity-related threats are rapidly detected and neutralized, safeguarding your critical assets and data. Unlike EDR and XDR, ITDR is the only solution that provides comprehensive and real-time visibility over identities and their behavior across clouds, SaaS, and IdPs from end to end. ITDR enables you to be proactive and narrow down your window of exposure by finding human and machine root causes for your risky and compromised identities before attackers take advantage of them.  What Security Challenges Does ITDR Address? Hackers are two things: intelligent and, well, pretty greedy. They’ll try to compromise identities in as many ways as possible, meaning ITDR platforms must monitor: Keys (e.g., cryptographic keys, tokens, or API keys) to protect services or data.  Credentials (e.g., username-password combinations) to thwart unauthorized access attempts. Programmatic attacks that use automation to compromise identities on a large scale.  Console attacks directed at management interfaces that give hackers high-level administrative privileges.  Admins and super admins who have the keys to the kingdom – once they’re compromised, hackers have everything they need.  The full scope of ITDR also covers the following areas: User Activity ITDR detects and responds to suspicious access attempts to critical systems by monitoring user activity. Sometimes, insiders and external threat actors carry out these unauthorized access attempts. Therefore, observing their behavior and alerting security teams about repeated suspicious behavior is also under the purview of ITDR. Identity Credentials Credentials are the secret information used to identify a user or a device, such as passwords and private keys. ITDR gathers intelligence related to using credentials to detect possible credential theft attempts. Source Access Permissions ITDR also detects and responds to privilege escalation attempts by monitoring identity permissions. This process also ties back to compliance requirements for granting the least possible privileges for identity and access management. 7 Features to Look Out for in an ITDR Platform An ITDR platform acts as an umbrella security cover over EDR and XDR. It performs real-time identity centric threat analysis, actively profiling and monitoring the identities and monitoring their usage, enabling continuous visibility of potential threat situations. ITDR supports a risk-based alerting mechanism and auto-remediation to manage all the stages of a threat lifecycle.  To augment the capabilities of an ITDR platform, here are the seven must-have features that can elevate its effectiveness to become an integral part of any organization's arsenal to counter cybersecurity attacks. 1. Compatibility with Multiple Clouds, SaaS, and IdPs An ITDR platform connects to cloud services, SaaS applications, and IAM infrastructure (like IdPs) to collect data on identities and access privileges. It analyzes authentication and authorization events to produce actionable insights on identity-related threats.  Therefore, it is vital to ensure that the ITDR platform you choose is compatible with native IAM services provided by Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), or other cloud providers. It should also integrate with the specific identity management solutions used by the organization, such as Okta or Azure Active Directory. 2. Room for Scalability and Elasticity Cloud environments are known for their scalability and elasticity. The ITDR platform must be equally capable of scaling with the cloud infrastructure to handle increasing workloads and user accounts without performance degradation. One important aspect of scalability is multi-cloud and hybrid-cloud deployment. If your organization uses multiple cloud providers or a hybrid cloud approach, an ITDR platform must also be able to monitor identities across different cloud providers. 3. Source of Identity Monitoring Typically, an ITDR platform relies on several sources to monitor and analyze identity-related activities. These sources primarily include logs and event data generated by various IT systems, including network devices, application servers, and authentication systems. To make the platform more effective, it must support additional sources that are indirectly accessed or fetched externally. ITDR platforms need to integrate with threat intelligence sources that have lists of leaked credentials and users, as well as third-party vendors that provide enrichment capabilities to the ITDR engine.  The dark web is yet another external source of data. ITDR platforms can leverage this data to monitor for stolen credentials to perceive early warnings of potential risks. 4. Integration with External Threat Intelligence Services and Vulnerability Feeds ITDR platforms rely on third-party vulnerability feeds from credible sources for comprehensive coverage of the threat landscape. Advanced ITDR platforms also offer features associating identity risk factors with the MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) framework for advanced protection. 5. Cloud Native Security Support Modern cloud applications have foregone the traditional monolithic, long-running process architecture, favoring cloud-native deployment to achieve super scalability. This approach relies on short-lived, ephemeral processes for performing specific tasks, such as handling API requests or accessing a particular database table. Tracing identities within a cloud-native environment requires additional integrations. As an advanced feature, ITDR platforms can support cloud-native deployments, such as the ability to monitor identities associated with API calls, serverless function execution, and container orchestration tasks. 6. AI (Artificial Intelligence) and ML (Machine Learning) Capabilities AI and ML significantly enhance an ITDR platform's capabilities. They provide more advanced and proactive methods for identifying and mitigating identity-related security threats. Some key areas where these technologies play a pivotal role include behavior baselining, user and entity profiling, threat profiling, and alert categorization. Overall, AI and ML can help ITDR platforms learn and adapt over time based on feedback and new data, improving their accuracy in identifying threats. 7. Data Privacy and Compliance Of course, the ITDR platform you choose must be verified for adherence to data privacy regulations and industry compliance standards applicable to your organization, such as GDPR, HIPAA, or PCI DSS. Further, the platform must support reporting and auditing capabilities to demonstrate compliance. Synergizing IAM and ITDR: A Resilient Future for Cybersecurity ITDR is a relatively new method of countering cybersecurity risks. It takes a radically different approach by safeguarding the identities, which are the virtual assets of a cloud environment. Since IAM is responsible for generating and provisioning these identities, it is all the more logical to combine it with ITDR. Rezonate offers the perfect synergy between ITDR and IAM to help security engineers and DevOps teams maintain the perfect sanity of their IAM configuration. With a few minutes of setup and an intuitive dashboard, Rezonate can connect to the most popular cloud providers and capture identity weak spots quickly. See Rezonate in action today.
    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.