Checks Tab
Last updated
Last updated
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:
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.
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.
Name
The name of the failed check
Result
Failed check status. Always listed as Failure
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
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:
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.
The fields available in the Resolved Checks table are:
Name
The name of the resolved check
Result
Resolved check status
Expired
Mitigated
Excluded - includes email of Identity Intelligence User who excluded and comment, if present
Total Handling Time
The number of days elapsed between the first date a check/observation failed and the date it was resolved
Resolved Date (UTC)
The date and time that a check/observation was no longer failing for a given user
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).
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.
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.
Resolved check explainability
Exclude a user - Removes the user from the list of check failures and stops them from being evaluated against a given check for a specified time frame. You can also leave a comment explaining why this user has been excluded from this check for that amount of time. 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. User is not evaluated against this check for the specific context that caused the given observation for 30 days. If Identity Intelligence notes that user has the same exact behavior again tomorrow, the user will not fail the check again, unless an observation is logged for that check with new context (new IP address, device, etc). Read more about this on the Triaging Alerts and Remediation Actions docs
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 Suspicious - 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. User is not evaluated against this check for the specific context that caused the given observation for 30 days. If Identity Intelligence notes that user has the same exact behavior again tomorrow, the user will not fail the check again, unless an observation is logged for that check with new context (new IP address, device, etc).
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.
State based checks and event based checks have different 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 documentation. More information about the Observations UI and functionality specifically within the User 360 Checks tab can be found below throughout this article.
For event based checks, within the explainability panel you can get more information from the given user's 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 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 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.
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 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 for each unique observation:
These actions can be found in the Actions button to the right of the User360 Tab names for a given user. The documentation has more information about the different actions available, the permissions needed, compatible sources and how to use them.
