Understanding Check failures
Last updated
Last updated
Overview
The Checks page provides high level information about all checks across all users in your environment, along with several filters, to quickly understand the state of your environment and assess potential areas in need of attention. The Checks page shows the full list of checks that are compatible with the identity data sources that are connected in your tenant. The checks in the table are ordered by compliance, from lowest to highest compliance, starting with the checks that have the most users failing. Checks that are in full compliance can be found towards the bottom of the list.
The Checks page is different than the , which only shows information about a given user's check failures, and from the page, which only shows information about a specific check failure.
To dive into a specific check failure and review the full list of failing users, click on any part of the row of the check you are interested in exploring.
This section covers:
State based checks vs Event based checks
Behind the scenes, Identity Intelligence also categorizes checks as either state based or event based to retain and display a user's check history.
State based checks are those which are calculated on static entitlement information such as - Is the user active? Does the user have MFA configured? Does the user have unused applications? Is the user sharing an authenticator with another user? etc. Based on the response, a state based check will fail and will remain failing until the response changes.
Event based checks are those which rely on event data where a user, or someone pretending to be a user, engages in a particular activity that triggers the check failure. Examples of event based checks are - Weak MFA was used to successfully sign in, IP Threat Detected, Personal VPN usage, Impossible Travel, etc.
If a user has multiple unique events that trigger an event based check failure, event based checks will display the 'Observations' on a given User's Check tab, to keep a record of the individual events that caused the failure, rather than consolidating all the information into one check failure. For example, a particular user fails the New Country for Tenant check yesterday because of a login in from Croatia, and tomorrow because of a login from Uruguay. Each event would be recorded as an individual failing observation for this particular user.
The section below details the fields that appear in the table, as well as the definition of each field:
Check Compliance
Check
The name of a given check The severity of the check
The scope of who is being evaluated against the check (end user or Identity Provider) The names of any relevant frameworks or topics related to the check Any custom tags applied to a check, if present
# Failing
The total number of users currently failing a given check The percentage change (increase or decrease) in number of users failing a given check over the last 7 days and 30 days
# Excluded
The total number of users excluded from a given check
Report Channels
Enabled
If a check is enabled, this check will be evaluated again the users in your protected population. A blue toggle to the right indicates a check is enabled If a check is disabled, users will not be evaluated against this check. A grey toggle to the left indicates a check is disabled By default, all checks are enabled. To disable a check, toggle the switch either from this column in the Checks table or from the specific Check page
This section describes the high level actions you can perform on the Checks page. Click through the tabs below to learn more about how to utilize each feature.
Filters
The Checks page is filterable by a number of attributes, enabling you to slice and dice all Checks based on certain parameters that are important to you. You can see all the available basic filters on the left hand side of the Checks page.
To enable a filter, click the check box for the attribute you would like to filter by. The applied filters will be added to the search bar. Distinct filters are separated by an AND operator. Within a given filter, selecting more than one value will separate the values with an OR operator (ie: Moderate OR Low).
To remove a filter, you can either deselect the attribute from the filters list on left hand side of the Checks page, or click the X on the right hand side of the filter box that is in the search bar.
After you have selected your filters, the filters are retained as you navigate between different areas within the platform.
: posture vs threat, state based vs event based, and near time vs scheduled
The full list of available checks can be found . Read more about the information presented and actions available on the Check Results page .
When looking at the available checks in the platform, you may notice that some checks are marked as Identity Posture Insight checks, while others are marked as Identity Threat Insight checks. Posture based checks highlight ways to improve your organization's identity security hygiene, while Threat based checks draw attention to potentially risky behavior that your end users, or someone pretending to be your end users, may be engaging in. It is important to as this ensures decreases the potential risk of every threat that comes in.
Event based checks will continue to fail for a given user for 7 days, until no new observations are noted. After 7 days, if no new observations have been noted for that check for the given user, the check failure will expire and mitigate itself so the user will no longer appear in the list of failing checks. The check failure will move to the table of the given user's Checks tab in the User 360. However, if a new observation is noted for that check for the given user within the 7 day window, the user will continue to fail the check. The list of observations and the associated explainability can also be seen in the User 360 Checks tab.
You may notice that certain checks have an additional field in the Check Details section called Check Assessment which distinguishes the checks that are "Near Time Compatible". If log streaming is enabled for the compatible sources, the data collection and analysis for that check will occur multiple times throughout the day. Checks that are not Near Time Compatible are "Scheduled" and will follow the standard 24 hour data collection process that runs at the for your tenant.
You can read more about Near Time compatible checks in the section of the Reviewing Check Results documentation.
The percent compliance of a given check, where 100% represents full compliance (0 users failing). Calculated by # of users failing a given check compared to # of users in Protected Population Note: If check compliance is 0% and Users column in the Checks table is N/A, this indicates the check is evaluated against data sources, not end users, and has at least 1 item failing
If a Notification Target has not been configured for a given check, an Add button is displayed in this column. Select the Add button to open a modal to choose from existing notification targets, or, if no notification targets are configured in your environment, it will say "No notification targets found". Click the Add Notification Target button to go to and configure one If one Notification Target has been configured for a given check, you will see the name of the configured notification target and an icon for the target type (Slack icon, email icon, etc) If multiple Notification Targets have been configured on the same given check, this column will say 'Multiple Channels' To modify or add Notification Targets to a given check that already has one or more targets configured, click on the Pencil icon next to the target name to make changes
Run Checks Now If you have made changes to the configuration settings of checks, clicking this button will re-run the state based checks so that you can see which users are failing based on the updated check configuration criteria.
If you have made changes to the configuration settings of checks, clicking this button will not show you updated results based on your new settings. To see any new users who are failing the check based on your configuration setting changes, you need to go to the page and trigger a data collection for the desired data source. Note: Manually collecting new data will not remove previously failing users that no longer fail under the updated settings from the list of failing users
