✅Checks Tab
Overview
The Checks tab in the User 360 shows a detailed view of all of a user's current check failures/observations, the reasons a user has failed a particular check, and other information related to the user's check history. Understanding the various checks a user is failing at once, or in close succession, can make it more obvious to identify an active attack or possible compromise on a given user's account. The Checks tab is the last tab of the User 360. You can also see the number of checks a given user is currently failing next to the tab name. In this article, we will go through the data and functionality available on the Checks tab including:
The Checks tab is not visible if a given user is not part of the protected population.
Different Types of Checks
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. 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 and event based checks have different triaging capabilities, but also slightly different interaction experiences within the Checks tab of the User 360 because event based checks store Observations, or a history of check failures for a specific check for a given user.
To learn more about the different types of checks within Identity Intelligence in general, refer to our Understanding Check failures documentation. More information about the Observations UI and functionality specifically within the User 360 Checks tab can be found below throughout this article.
Checks table elements
On the Checks tab, there are 2 different tables - the first table displays the checks that a given user is currently failing. The second table shows the given user's resolved checks, which are checks that the user is no longer failing. If the user does not have any resolved checks you will only see the Failing Checks table. If the user is not currently failing any checks, you will only see the Resolved Checks table.
Below, we will explain the fields that appear in each table, as well as the definition of each field.
Failing Checks
| Element | Definition |
|---|---|
Name | The name of the failed check |
Result | Failed check status. Always listed as |
Times Excluded | The total number of times a given user has been excluded from a particular check |
First Reported (UTC) | The date and time of the first failed observation for a particular check for a given user |
Last Reported (UTC) | The most recent date and time of a failed observation for a particular check for a given user |
User/Manager Notified | The number of times a given user or their manager has been notified about a particular check failure, and an icon representing the method used to notify (Email, Slack, Teams, etc) If a notification target is not set for a particular check, a message prompting you to configure the notification is shown in this column Note: Only some checks support notifying end users or managers. For checks that do not support notifying end users or managers, this column will say 'Not Supported'. If notifications are supported, but have not been sent to end users or mangers, the column will say 'Not Notified' |
Admin Notified | The number of times an admin has been notified about a given using failing a particular check, and an icon representing the method used to notify If a notification target is not set for a particular check, a message prompting you to configure the notification is shown in this column |
Failing Check Observations
If there has been more than one observation for a check failure, the row can be expanded using the arrow to the left of the check name, so that you can see the history of observations.
Up to 5 observations will be displayed by default, but you can click the 'See More' button under the last observation to see additional events if they exist. Observations are displayed in order from newest (top) to oldest (bottom).
The fields available for observations are:
| Element | Definition |
|---|---|
Observed At | The date and time a given observation was recorded |
Source | The identity source associated with a given failing observation |
Feedback provided | The user who provided feedback on a given observation, if applicable. If there has been no feedback, the value is N/A. |
Feedback date | The day and time a user provided feedback on a given observation, if applicable. If there has been no feedback, the value is N/A. |
Resolved Checks
The fields available in the Resolved Checks table are:
| Element | Definition |
|---|---|
Name | The name of the resolved check |
Result | Resolved check status
|
Total Handling Time | The number of days elapsed between the day a check/observation failed and the day it was resolved |
Time to Resolve | |
Resolved Date (UTC) | The date and time that a check/observation was no longer failing for a given user |
Resolved Check Observations
Similarly to failed check observations, if there has been more than one resolved observation for a check failure, the row can be expanded using the arrow to the left of the check name, so that you can see the history of resolved observations.
Up to 5 observations will be displayed by default, but you can click the 'See More' button under the last observation to see additional events if they exist. Observations are displayed in order from newest (top) to oldest (bottom).
Resolved check widgets
Under or next to the two checks tables are also two small widgets with the number of mitigated checks a given user has, the number of checks a given user has been excluded from, and the median count per user for your tenant.
Diving deeper into a check failure
For each failing check, you can click in and view more information about that particular failing check, along with the most important context, such as the actions that contributed to the user failing a given check and high level context about that user. This is called the 'check explainability'.
To review the check explainability, click on any blank space in the row related to the specific check or observation you'd like to dig into. This will open a slide panel from the right side of the page. To access an observation's explainability, you can also click the button on the right side of the observation row, outlined in blue in the screenshot below. To close the slide panel, click the X in the top right corner of the panel, or click anywhere outside of slide panel.
The explainability available will vary from check to check based on what information or context is most relevant for a particular check, and can include information such as such as user title, failing data source, factor type, application accessed, IP address used, etc.
For event based checks, within the explainability panel you can get more information from the given user's Activity tab by either clicking the View in Activity button to navigate to the Activity tab pre-filtered on all events related to that check failure, or clicking on a See in Context button which takes you to the Activity tab pre-filtered on events that occurred in the hour directly before and after the check failure.
Resolved check explainability
Resolved checks also have explainability if the check failure was observed 7 days ago or less. If the check is less than 7 days old, you can access the explainability in the same was as actively failing checks - by clicking in the blank space. If the check failure was observed more than 7 days ago, the slide panel will appear with the recommended actions only. You can still access the check failure explainability of these older observations by clicking the 3-dot button on the right hand side of the row, and selecting View Logs. This will take you to the User's Activity tab, pre-filtered on the check failure. Then, find the desired failing 'Observation Added' event and click the blank space of that row to open the side panel with the check explainability.
How to triage a user's check failure
Once you have looked into a user's failing check(s) to understand more about the user and/or complete an investigation, you can then take action in a few different ways. To learn more about the available actions, how to use the different actions, or any additional permissions needed to use certain remediation actions, read our Remediation Actions documentation To respond to a specific check failure for a specific user, you can use the 3-dot button on the right hand side of each row, you can submit feedback for each unique observation:
Exclude a user - Removes the user from the list of check failures and stops them from being evaluated against a given check for the specified time frame. Check will appear in Resolved Checks table in Checks tab of User 360
Mark as Normal Behavior - Note: Only available for event based checks. Remediates the failed check for that occurrence and moves it to the Resolved table in the User360 Checks tab. If Identity Intelligence notes that user has the same behavior again tomorrow, the user will fail the check again
Identity Intelligence team compiles this data to determine if customers find the detection accurate or not, so logic improvements can be made if needed
Mark as Interesting - Note: Only available for event based checks. Remediates the failed check for that occurrence and moves it to the Resolved section of the User360 Checks tab. If Identity Intelligence notes that user has the same behavior again tomorrow, the user will fail the check again
Identity Intelligence team compiles this data to determine if customers find the detection accurate or not, so logic improvements can be made if needed
There are also additional remediation actions, such as Reset MFA, Log out User, Delete User, Quarantine, etc, that can be taken on a given user's account, depending on the sources associated with a given user and the permissions configured at the data source.
These actions can be found in the Actions button to the right of the User360 Tab names for a given user. The Remediation Actions documentation has more information about the different actions available, the permissions needed, compatible sources and how to use them.
Last updated