Chat now with support
Chat with Support

Security Guardian Current - User Guide

Introducing Quest Security Guardian Using the Dashboard Security Guardian Inteligence Tier Zero Objects Shields Up Protection Privileged Objects Assessments Findings Security Settings Appendix - Security Guardian Indicator Details Appendix - Data Collection Details

Pre-Defined Entra ID Discoveries

Quest Security Guardian comes with the following pre-defined Discoveries for Entra ID vulnerabilities.

NOTE: "System" displays in the Created By field of the Discoveries list when a Discovery type is pre-defined.

Discovery Type Description
Entra ID Credential Access Techniques deployed by adversaries on systems and networks to steal usernames and credentials for re-use.
Entra ID Discovery Techniques used by adversaries to obtain information about systems and networks that they are looking to exploit or use for their tactical advantage.
Entra ID Initial Access Techniques used by adversaries to obtain a foothold within a network, such as targeted spear-phishing, exploiting vulnerabilities or configuration weaknesses in public-facing systems.
Entra ID Persistence Techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access.
Entra ID Privilege Escalation Techniques used by adversaries to gain higher-level privileges on a system, such as local administrator or root.

Entra ID Vulnerabilities that Require a Premium License

The following Entra ID vulnerabilities require a Premium License. If the organization has a free license, Assessment results for these Discoveries will return as Inconclusive.

  • Entra ID guest user accounts that are inactive

  • Entra ID Privileged accounts that are not secured by multi-factor authentication (MFA)

Discovery for Entra ID Credential Access Vulnerabilities

The following table describes the vulnerabilities identified in the pre-defined Entra Discovery for Credential Access.

NOTE: Credential Access techniques are deployed by adversaries on systems and networks to steal usernames and credentials for re-use.

Vulnerability Template Vulnerability Risk What to find
Entra ID tenant on-premises Password hash synchronization

Name:

Password hash synchronization with on-premises Active Directory is not enabled

Default scope:

N/A

 

NOTE: If no Active Directory collection is available, an Inconclusive message is returned.

 

Microsoft Entra Connect synchronizes a hash of the user's passwords from on-premises Active Directory to Entra ID. Password hash sync enables users to sign in to a service by using the same password that is used to sign in to the on-premises Active Directory instance. Password hash sync allows Identity Protection to detect compromised credentials by comparing password hashes with passwords known to be compromised.

Remediation:

In Microsoft Entra Connect, the Password Hash Synchronization setting can be enabled on the User Sign-in page.

 Entra ID tenants in scope that have on-premises Active Directory Password hash synchronization disabled

Entra ID user account multi-factor authentication status

 

 

Name:

Entra ID Privileged accounts that are not secured by multi-factor authentication (MFA)

 

Default scope:

All Privileged users

Accounts that are assigned administrative rights are targeted by attackers. Requiring multi-factor authentication (MFA) on those accounts is an easy way to reduce the risk of those accounts being compromised.

Remediation:

Administrator accounts identified may be a member of a Privileged or non-Privileged administrator role. Investigate each administrator to determine why they are not using multi-factor authentication (MFA). If a large number of administrators are not using MFA, MFA may need to be enforced using Security Defaults or Conditional Access policies.

 Entra ID user accounts in scope that have multi-factor authentication not registered
Entra ID tenant administrator SSPR status

Name:

Administrators are not enabled for self service password recovery

Default scope:

Entra ID tenant(s)

 

By default, administrator accounts are enabled for self-service password reset (SSPR), and a strong default two-gate password reset policy is enforced.

Remediation:

SSPR for administrator accounts can be re-enabled using the Update-MgPolicyAuthorizationPolicy PowerShell cmdlet. The -AllowedToUseSspr:$true|$false parameter enables SSPR for administrators. Policy changes to enable or disable SSPR for administrator accounts can take up to 60 minutes to take effect.

 Entra ID tenants in scope that have an administrator service password reset (SSPR) disabled
Entra ID Conditional Access policy “Exchange ActiveSync clients” and “Other clients” access control

Name:

Entra ID Conditional Access policies do not block legacy authentication for all users

Default scope:

All users

 

Applications using legacy methods to authenticate with Microsoft Entra ID and access organization data are not considered secure. Protocols such as POP3, IMAP4, and SMTP have been replaced by modern authentication, which uses Multifactor Authentication (MFA).

Remediation:

Organizations with Microsoft Entra ID P1 or P2 licenses should use Conditional Access policies to block legacy authentication. Organizations with Microsoft Entra ID Free tier should enable Microsoft Entra Security Defaults to block legacy authentication.

 

NOTE: Microsoft recommends excluding the following accounts from Conditional Access policies:

  • Emergency access or break-glass accounts (to prevent tenant-wide account lockout),

  • Service accounts and service principals (non-interactive accounts normally used by back-end services which cannot programmatically complete MFA).

 

 Entra ID user accounts in scope that do not have the client apps “Exchange ActiveSync clients” and “Other clients” access control set to block in an assigned Conditional Access policy
Entra ID Conditional Access policy sign-in risk Name:

Entra ID Conditional Access polices do not protect all users from risky sign-ins

Default scope:

All users

A risky sign-in represents the probability that an authentication request is not authorized by the identity owner. Based on the risk level high, medium and low, a policy can be configured to block access or force multifactor authentication. Microsoft recommends that multifactor authentication is forced on Medium or above risky sign-ins. Remediation:

Requires a Microsoft Entra ID P2 license.

Enable a Conditional Access policy for the tenant that has “Users” set to include “All users” and exclude emergency access or break-glass accounts.

  • In “Target resources”, “Cloud apps” set to include "All cloud apps”.

  • In “Access controls” “Grant”, set “Grant access” to “Require multi-factor authentication”.

  • In "Session", set "Sign-in frequency” to “Every time”.

  • In Conditions, select “Sign-in risk”, set “Configure” to Yes.

  • Under “Select the sign-in risk level this policy will apply to”, select “High” and “Medium” options.

NOTE: Microsoft recommends excluding the following accounts from Conditional Access policies:

  • Emergency access or break-glass accounts (to prevent tenant-wide account lockout).

  • Service accounts and service principals (non-interactive accounts normally used by back-end services which cannot programmatically complete MFA).

 Entra ID user accounts in scope that do not have sign-in risk levels set to high, medium in an assigned Conditional Access policy
Entra ID Conditional Access user risk policy

Name:

Entra ID Conditional Access polices do not protect all users from high user risk

Default scope:

All users

User risk indicates the likelihood a user's identity has been compromised and is calculated based on the user risk detections that are associated with a user's identity. Based on a risk-level of high, medium, low a policy can be configured to block access or require a secure password change using multifactor authentication. Microsoft's recommendation is to require a secure password change for users with high risk.

Remediation:

Requires a Microsoft Entra ID P2 license.

Enable a Conditional Access policy for the tenant that has “Users” set to include “All users” and exclude emergency access or break-glass accounts.

In “Target resources”, “Cloud apps” set to include “All cloud apps”.

In “Access controls” “Grant”, set “Grant access” to “Require multifactor authentication” and “Require password change”.

In "Session", set "Sign-in frequency” to “Every time”.

In Conditions, select “User risk”, set “Configure” to Yes.

Under “Configure user risk levels needed for policy to be enforced”, select the “High” option.

NOTE: Microsoft recommends excluding the following accounts from Conditional Access policies:

  • Emergency access or break-glass accounts (to prevent tenant-wide account lockout),

  • Service accounts and service principals (non-interactive accounts normally used by back-end services which cannot programmatically complete MFA).

 Entra ID user accounts in scope that do not have user risk levels set to high in an assigned Conditional Access policy

Entra ID Conditional Access policy mfa status

NOTE: For vulnerabilities that use this template, a premium license is required.

Name:

Entra ID Conditional Access policies do not protect all privileged users with multi-factor authentication (MFA)

Default scope:

Privileged users

 

Administrators have increased access to the environment. Due to the power accounts with privileged roles have, they should be treated with special care. One common method to improve the protection of privileged accounts is to require a stronger form of account verification for sign-in, like requiring multifactor authentication.

Remediation:

Improve protection by requiring multi-factor authentication (MFA) for the listed directory roles. The conditional access policy is not required if a conditional access policy that requires MFA has been created for all users.

Enable a Conditional Access policy for the tenant that has “Users or workload identities” set to include the directory roles:

  • Global Administrator

  • Application Administrator

  • Authentication Administrator

  • Billing Administrator

  • Cloud Application Administrator

  • Conditional Access Administrator

  • Exchange Administrator

  • Helpdesk Administrator

  • Password Administrator

  • Privileged Authentication Administrator

  • Privileged Role Administrator

  • Security Administrator

  • SharePoint Administrator

  • User Administrator

“Target resources” set to "All cloud apps",

“Access controls” set to “Grant access, Require multi-factor authentication”

Organizations with Security Defaults enabled will enforce MFA for privileged roles without requiring a Conditional Access policy.

 

 Entra ID user accounts in scope that do not have require multi-factor authentication enabled in an assigned Conditional Access policy
Entra ID Conditional Access token protection

Name:

Entra ID Conditional Access policies do not require token protection for sign-in sessions for users

Default scope:

All users

 

Token protection attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device. When a token is stolen, by hijacking or replay, it can be used to impersonate the victim until the token expires or is revoked. Token theft is considered a relatively rare event but can inflict significant damage.

Token protection creates a cryptographically secure tie between the token and the device (client secret) it is issued to. Without the client secret, the bound token is useless.

When a user registers a Windows 10 or newer device in Microsoft Entra ID, their primary identity is bound to the device.

Remediation:

Requires a Microsoft Entra ID P2 license.

Token protection is only supported with some Windows devices and a limited set of applications. Review the requirements and known limitations to confirm if token protection is appropriate for users in the organization. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection The setting to require token protection is located in “Session”, “Require token protection for sign-in sessions”.

 Entra ID user accounts in scope that do not have token protection for sign-in sessions enabled in an assigned Conditional Access policy

Discovery for Entra ID Discovery Vulnerabilities

The following table describes the vulnerabilities identified in the pre-defined Entra Discovery for Discovery.

NOTE: Discovery techniques are used by adversaries to avoid detection. Evasion techniques include hiding malicious code within trusted processes and folders, encrypting or obfuscating adversary code, or disabling security software.

Vulnerability Template Vulnerability Risk What to find
User password last changed

Name:

Entra ID privileged role members whose passwords have not changed recently

Default Scope:

All Users

 

While it is not necessary to require mandatory periodic password resets, organizations should be aware of the password age of users that are members of Microsoft Entra built-in privileged roles.

Remediation:

Ensure that privileged role members have update their password to satisfy the organization’s password policy.

Users that are members of privileged roles that have not updated their password within last 90 days

NOTE: The number of days is editable.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating