Can Identity Intelligence analyze behavior and fail checks more frequently?
PreviousAccessing and Securing your Cisco Identity Intelligence TenantNextImporting Known IP Address Lists
Last updated
Last updated
While the short answer to this question is "yes", there are several important things to consider and requirements that must be met for Identity Intelligence to change the frequency of its data collection and analysis.
First, it is important to understand how Identity Intelligence works out of the box.
Generally speaking, by default, your Identity Intelligence tenant pulls data regularly throughout the day from all of the identity sources connected to your tenant via their respective APIs. We refer to this as Data Collection. In many cases, Identity Intelligence only pulls the delta of data - anything new or anything that has changed - compared to the previous data collection.
This data collection process happens in the background, approximately every hour or so.
Although data is being collected frequently throughout the day, Identity Intelligence does not do anything immediately with that data - new check failures are not recorded, user activity logs are not updated, check failure notifications are not sent, User Trust Levels and Identity Posture Score are not recalculated, just to name a few examples.
That is because the data collection alone is not sufficient to trigger those different events to happen. To support all these events (and more) Identity Intelligence must run a full analysis of the data that was collected throughout the day to examine the individual data points, analyze data points across identity sources, compare the new data points to historical data points (ie: data from previous days), evaluate the data and events against each check's logic, etc. It is important to note that after the Data Analysis is complete for a given identity source, user check failures will still not be updated.
As you can imagine, this is quite a complex, time consuming and resource intensive process, which is why the Data Analysis runs once every 24 hours for each identity source. There is no set timing for when each identity source's data analysis runs, they are distributed throughout the day at random.
Step 3: Data Updates and Notifications
User data and check failures are updated once a day on a scheduled 24-hour cycle for ALL connected identity sources. It is during this step that the platform is updated with new records and you will start seeing updates and the new information populated in the platform. If notification targets are enabled on checks, then alerts for new check failures will be sent at this time as well. The timing of the notification task can be modified to fit your organization’s preferences.
You can customize the time that check notification occurs to fit your organization's preferences. To do so, navigate to the Tenant Settings menu item and select the option. For example, some customers prefer that notifications be sent before the start of their work day so that they can start their day by reviewing all the new check failures.
Be sure to build in some buffer time to ensure that all checks can be updated before the team is online as this process can take some time, especially for larger tenants. If the process is still running when your team starts accessing the platform, the platform may still be updating, so the results can change from one minute to the next, which can create confusion.
Identity Intelligence has a small number of checks today that are considered "near time" compatible, which means that the platform will detect and alert on failures for these checks much closer to the time that the actual event happened. Rather than wait for the 24-hour analysis cycle, "near time" checks will typically notify about a failure within approximately an hour of the user event occurring.
For the compatible checks to process events in near time, event streaming must be enabled for the compatible source(s). Event Streaming is managed per identity provider. Below are links to documentation about how to configure event streaming documentation for each source:
It is important to note that certain checks may be near time compatible with one identity source, but not another. Compatibility is determined based on the format of the data received from the identity source and any associated limitations that allow or prohibit us from making the check near time compatible.
Identity Intelligence can change a tenant's setting so that user activity logs and check failures are updated more often throughout the day instead of the default 24 hour cycle. We refer to this updated setting as Threat Discovery Mode (TDM): High
While this may sound great at first, there are a few very important things to consider before switching your tenant to TDM: High .
As we described above, for Identity Intelligence to support all the events and data displayed in the UI, it must run a full analysis of the data it has collected throughout the day. With TDM: High, Identity Intelligence must run the full analysis on an hourly basis in order to update all the data displayed in the platform.
We often find that after enabling this setting, many customers come back to us and ask us to turn it off. This is because even with the best intentions, for most teams TDM: High is too frequent. Before the team has had a chance to finish reviewing, investigating, triaging and remediating the detections from 10 AM, the analysis runs again at 11 AM and now, there are a whole batch of new failures to investigate. This can be very overwhelming and stressful for teams to manage, and even counterproductive to their success with Identity Intelligence.
That is why we highly recommend that you consider how your team is set up (size, level of experience/expertise, etc), how they would manage and work with this frequency of check failures, how they would balance this alongside their other responsibilities, as well as ensure that the team has a very well tested and established process in place for investigating and triaging detections, before making the change, so that your team can make the most of TDM: High .
Below are some example questions you should ask yourself/the team to determine if TDM: High makes sense for the team at their current stage of adoption and operationalization:
Who will be responsible for reviewing, investigating and triaging check failures?
Who will be responsible for reviewing all the detections that come in during the team's "offline" or "non-business" hours?
What is the current volume of check failures seen on a daily basis across all checks? Across the checks of most importance?
Would the team be able to get the number of failing users down to 0 in one day on only the checks that are most important to your organization?
What notification system is in place to ensure that the team can proactively review any detections as soon as they are reported?
How does your team currently manage the detections that Identity Intelligence reports daily?
What processes do the team follow today to operationalize the information provided by Identity Intelligence?
Does your team have sufficient resourcing to review new user failures every hour?
What other tools or responsibilities does the team have that they will need to balance alongside the work created by Identity Intelligence? How does this fit in with the increased workload associated with TDM: High ?
If the team cannot successfully operationalize the data received at this level of frequency, what is the intended value or benefit your team gains by receiving the data at this rate?
If your organization cannot properly operationalize and manage the frequency, and volume, of detections that would occur by being in TDM: High , then the value your team will get from updating this setting is incredibly limited. Even worse, if the team is not ready, changing to TDM: High is more likely to hurt your team's adoption and usage of Identity Intelligence than it is to help.
If this is the case, it is best to hold off on making the change and continue working with the 24 hour schedule, until the team is able to really benefit from having data updated more frequently throughout their day.
As we discussed, because of the increased frequency of data collection and the general risk associated with enabling TDM: High , there are a few requirements that must be met before TDM: High can be enabled on a tenant.
The more identity sources that are connected to your Identity Intelligence tenant, the better the platform works. It is critical to connect your primary Identity Provider (IdP) to your tenant get a holistic view of your users and to identify users who may not exist in Duo. If you connect additional sources, your view on a user gets even wider. When you connect your Human Resource Information System (HRIS) data, you get additional context about a user that is also valuable.
Identity Intelligence leverages the additional user context, data and activity from these sources to reduce the number of false positives reported. This is important when utilizing TDM: High because the detection analysis is happening very frequently, so low-fidelity results can create a lot of additional, time consuming and low value work for your team compared to high-fidelity results that are worth the investigation. If Duo is the only integration connected to your Identity Intelligence tenant, the detection results are much more likely to be noisy, so you will get less value not just from Identity Intelligence overall, but also less value from TDM: High.
Setting up and configuring Notification Targets is an important step to general operationalization of Identity Intelligence, and is an even more critical component to get meaningful value from TDM: High. With TDM: High, checks will start failing on an hourly basis. If your tenant does not have a notification target connected and configured on checks, then the team will not be able to receive proactive alerts about new users failing throughout the day and they will need to sign in to the platform repeatedly to see what has changed from the previous hour. Additionally, without an alerting mechanism, there will be a delay between when a detection was reported, when the team logs into the UI to see that a detection was reported and the team starting an investigation.
These delays diminish the value of TDM: High because even though the data analysis is running frequently throughout the day, the team isn't able to easily investigate the issues at the same pace since they won't know about the detection as soon as Identity Intelligence reports it.
There are certain data points that Identity Intelligence only receives via Streaming that are needed to determine check failures
Streaming ensures that data can be sent to Identity Intelligence without overloading the identity source's APIs or causing rate limiting/throttling issues that could impact other tools in your environment
If Streaming is not currently enabled, there is no near-time alerting for checks that are already near-time compatible without TDM: High . We recommend that you enable streaming and use the small number of near time compatible checks to simulate the experience and gauge the volume and frequency associated withTDM: High . This will help you better understand if the team is prepared to properly operationalize the check results of a few checks, before enabling TDM: High across ALL checks.
If you have read all the documentation above, your tenant meets the requirements listed, and you would like to have TDM: High enabled on your tenant, contact your Duo representative team or Support. They will reach out to the Identity Intelligence team directly who will verify the requirements are met and enable the TDM: High setting.
There is currently not a way to manually enable or disable this setting within your own tenant. If you would like to disable the setting, you will need to follow the same process to request that it be turned off.
All that being said, there are certain instances where the check analysis and notifications update outside of the 24 hour cycle. This happens with
We highly recommend using a (ex: Slack, Teams, Webex) or using to send the alerts to a SIEM, rather than using an email notification target. Notifications sent to messaging systems include more details about the user failure and triage options, making it easier to manage and interact with the alerts than email, while SIEMs are great options for teams managing a large volume of notifications, consolidating logs and alerts across multiple tools, or working with a Security Operations (SOC) team.
If you would like to enable TDM: High you must first enable Streaming on all connected identity sources that support streaming (currently , , ). This is for a few reasons:
Note: does incur an additional cost for Microsoft. You will need to speak with your Microsoft rep to learn about pricing. Streaming for Entra is required to support TDM: High because it is very common for Identity Intelligence to experience rate limiting on Microsoft's GraphQL API as it is shared across multiple Microsoft services. Because their API is shared across multiple services, if Microsoft starts to rate limit the API, it can also cause unpredictable and unexpected results in other Microsoft services (ex: Sharepoint)