Skip to content

Taegis™ IDR Overview🔗

Overview🔗

Taegis™ IDR is a software add-on module that helps improve your security posture by continuously monitoring for identity risks and misconfigurations while providing dark web intelligence on compromised credentials. With IDR, you will receive a list of prioritized findings and an Identity Risk Posture Score and rating based on your current exposures within minutes of setup.

What is an Identity?🔗

Identity is defined as a collection of unique identifiers that allow a computer to identify an entity, such as a person, organization, software program, or another computer.

For IDR, identities include active:

  • Human Identities — Represent an employee, guest, vendor, etc.
  • Machine Identities/Non-Human Identities (NHI) — Represent entities such as applications, service principals, service accounts, machines and any other identities that are used to authenticate and authorize access to resources or perform transactions between systems.

How is IDR Licensed?🔗

IDR is licensed based on the number of active human and non-human identities collected from the identity provider. The same account that appears in multiple systems is only counted once.

What are Findings?🔗

A finding is the output of a posture check performed by the IDR module. Findings have an associated risk level that should be used to prioritize which to address first. Find an overview of the top findings with the highest risk on the Identity Risk Posture Overview page, a full table of findings on the Identity Findings page, and findings related to a specific identity on Identity Details pages.

Get to IDR🔗

Select Identity from the Taegis Menu and choose Overview to view your Identity Risk Posture Overview. If IDR is not enabled for your tenant, you will see Taegis™ IDR under Taegis Solutions in the Taegis Menu.

Configure IDR🔗

Once IDR has been enabled for your tenant, select Identity from the Taegis Menu to begin configuring the Entra ID integration. Follow the steps within the interface to complete the integration and begin using IDR. See our IDR Integration Guide for integration set up instructions.

Resources🔗

Use the following resources to find valuable IDR information:

FAQs🔗

What Identity Providers are supported?

Microsoft Entra ID is currently supported.

Can I add more than one Microsoft Entra ID Tenant?

Yes, you can now add multiple Entra ID tenants from the Identity Settings page.

What Microsoft Entra ID license do I need?

The solution requires Entra ID P1 or P2, which are available in standalone products, add-ons, or included with other Microsoft licenses such as Microsoft 365 E3, E5, Microsoft Business Premium, and Microsoft 365 Frontline Worker F1, F3, F5. Microsoft Entra ID Free provides access to the Microsoft APIs and impairs some of the data that can be ingested and posture checks that can run.

How long does it take for IDR to update after upgrading from Entra ID free to P1 or P2 license?

IDR relies on the Microsoft APIs to collect account information. Microsoft also restricts access to certain APIs based on licensing, so information such as whether a user is an Admin or has MFA registered may not show up right away after a license upgrade. We have seen delays up to a week before Microsoft provides the updated user information after a customer upgrades their license. You can verify this by viewing the activity report outlined in Authentication Methods Activity - Microsoft Entra ID | Microsoft Learn. If the information contained within the user report is not updated, IDR will also be out of date until Microsoft refreshes the information.

Why are my users showing not protected by MFA?

There are a few potential causes:

  • You do not have the required Microsoft Entra ID license (e.g., P1 or P2).
  • You recently upgraded your license and Microsoft has not made the data available yet (see previous question).
  • You are using a third-party MFA provider such as Okta or Duo with a legacy configuration. In this scenario, the MFA status will not report back properly as Microsoft Entra ID does not store the MFA information at the user level for external MFA providers. However, we can infer that an external provider is being used if you use the new Microsoft External Authentication Methods configuration within your Entra ID tenant configuration. Additional setup details are available for Duo and Okta.
How often do posture checks run?

IDR includes a suite of assessments each responsible for running different checks. These are performed at different intervals as outlined below:

Type of Assessment Frequency
Entra ID Posture Checks Every 2 hours
Dormant Resource Checks Every 2 hours
Credential Compromise Daily
How often is data collected from Entra ID?

Upon setup, we collect the full catalog of data from Microsoft Entra ID. After that, we check for updates based on the type of data as outlined below:

Data Type Frequency
User Details Every 10 minutes
Service Principals/Apps Details Every 10 minutes
Groups Every 10 minutes
Devices Every 10 minutes
User MFA Configuration Every 15 minutes
User Activity (Last Sign On) Every 6 hours
Domain Data Every 24 hours
How often do you check for leaked credentials?

We check for leaked credentials every 24 hours.

How are account compromise findings generated?

To ensure that these are actionable, we perform a number of processing steps to correlate and validate the data that we are collecting and analyzing.

  1. Verify that an active identity exists within the configured Identity Providers.
  2. Determine when the plaintext password or hash was first leaked based on the available historical data (~six years). This is important because newly published combolists often contain old data from previous breaches.
  3. If it is a plaintext password value, we then compare this to the Microsoft Entra ID global password complexity requirements to weed out invalid values.
  4. Finally, we compare the first_leaked_date of the password to the last_password_change_time for the identity. If the leak first occurred after the last_password_change_time, we generate a finding.

Note

Account compromise findings are generated for active identities only. However, you can still see the raw data on the Credential Compromise page.

How are account compromise finding risk levels determined?

If we have determined that a finding should be generated, we then check the associated account to see whether it has MFA enabled and at what strength. Below are the associated risk levels based on the type of user, type of leak, and MFA configuration.

Account Type Password Type No MFA MFA Enabled Phishing Resistant MFA Enabled
Admin Account plaintext Critical High Medium
Admin Account hash High Medium Low
Non-admin Account plaintext High Medium Low
Non-admin Account hash Medium Low Low
Do you collect and store hashes or passwords?

No, we do not store any of the plaintext passwords or hash values. We also do not have the ability to capture these from the Identity Providers. When scanning for and collecting data, we apply a custom hash to the observed values and then categorize the record as either a plaintext or hashed password. This allows us to determine the uniqueness of the passwords as well as calculate metrics without having to retain the underlying password values.

How many domains are monitored for leaked credentials?

You can choose up to 20 primary domains to be monitored.

What data is used in the leaked credential monitoring?

The data set we use goes back six years and includes data from various Dark Web marketplaces (e.g., Russian Marketplace, Genesis market), TOR sites, public and hidden Telegram channels, and stealer log files.

How often is the Identity Risk Score updated?

The Identity Risk Score is updated daily based on changes from the previous day. The score will either increase or decrease based on whether new findings were observed or previous ones were resolved or dismissed.

How can I see the list of checks that are being performed?

You can view the list of checks within the Posture Check Preferences tab on the Identity Settings page.

Can I customize the checks that are running against my environment?

Yes, you can enable and disable the posture checks within the Posture Check Preferences tab on the Identity Settings page.

Is IDR a service?

No, IDR is a software add-on module that is monitored by the customer.

I have the Taegis MDR service, does the SecOps team triage my findings?

No, IDR findings are not active threats. It is the customer's responsibility to monitor and manage findings.

I have the Taegis MDR service, how does this help the Security Operations team?

The module collects and stores important data and context from Microsoft Entra ID about your environment. This additional context helps accelerate the investigation and response processes across both identity and non-identity alerts where the user has been correlated. Alerts with applicable identity information are correlated and enriched with user information collected with the IDR module and will be evident by the fingerprint icon next to the associated identities.

Identity Enrichment for Alerts

What determines whether an identity is flagged as Admin?

The isAdmin flag in Entra ID (Azure AD) is set to true for users assigned to roles recognized as administrative or privileged within Entra ID. These roles generally have significant control over directory resources, users, or security settings. The following is an exhaustive list of the Entra ID roles that set the isAdmin flag to true:

  • Global Administrator — Full access to all administrative features in Entra ID
  • Privileged Role Administrator — Manages role assignments in Entra ID, including assigning other administrators
  • User Administrator — Manages user accounts, groups, and some user attributes
  • Security Administrator — Has full access to all security features and settings
  • Compliance Administrator — Manages compliance-related features such as eDiscovery and auditing
  • Application Administrator — Manages application registrations and settings in Entra ID
  • Authentication Administrator — Can view, set, and reset authentication methods and controls, including password resets
  • Exchange Administrator — Manages settings for Microsoft Exchange Online
  • SharePoint Administrator — Manages settings for SharePoint Online
  • Teams Administrator — Manages settings for Microsoft Teams
  • Intune Administrator — Manages device management settings and configurations in Microsoft Intune
  • Billing Administrator — Manages subscriptions, billing, and support tickets
  • Helpdesk Administrator — Limited to password resets and basic troubleshooting
  • Service Support Administrator — Manages service support-related settings
  • Directory Readers (if combined with other privileged roles) — Can read directory information; usually combined with another role to elevate privileges
  • Global Reader (if combined with another admin role) — Read-only access across Entra ID and Microsoft services; may set isAdmin to true when combined with another admin role
  • Reports Reader (if combined with another admin role) — Access to reports and logs, often combined with other administrative responsibilities
  • Conditional Access Administrator — Manages conditional access policies
  • Identity Governance Administrator — Manages settings related to identity governance, access reviews, and entitlement management
  • Special Cases:
    • Custom Roles with Administrative Privileges — If a custom role has been defined with administrative permissions comparable to any of the above roles, it may also set the isAdmin flag to true.

Role Assignment Combinations

Sometimes, the combination of a less-privileged role with a more-privileged one can result in the isAdmin flag being true. For example, having both Global Reader and User Administrator roles assigned can trigger this flag.

This list covers the standard roles in Entra ID that impact the isAdmin flag; however, if Microsoft updates these roles or adds new ones, the behavior of the isAdmin flag could change accordingly.

What determines whether an identity is flagged as Stale?

If the last_logon_time is greater than 90 days, we mark a user as stale.