Week 43, 2022
Last updated
Last updated
Duo has a functionality for admins to create Bypass codes that can be send to the user, to re-establish access in case of major issues.
Of course this powerful function is not to be used lightly, and need to be monitored closely, as it could be abused.
This is why we have added a check that will detect and notify you when a successful sign in is done using a Duo Bypass Code.
Users should be assigned access to applications through groups and roles, and direct user assignment should be monitored as it could be used by an attacker to access additional assets while evading usual scrutiny. This check will trigger alerts whenever an individual account is directly given access to an application. Applications listed in the ignore list will not trigger an alert.
The list of directly assigned applications is displayed for each user that failed the check.
Each check is assigned some “topics” that you can filter on, in order to address specific use cases with more focus.
We have added an “application” topic for all application-related checks.
While all our checks are calibrated out of the box to perform well in a variety of situation, it can be useful to tweak some parameters to better fit your specific policies. That’s why we are always adding ways for you to customize how our checks perform. This week, the Account probing threshold can be configured to define the number of failed attempts that should trigger the alert.
It is important that you always get as much relevant information as possible about the reasons behind a check failing, so you can perform an efficient investigation. This week we are adding the last successful sign in time and list of failed sign in events that occurred after the last successful sign. You can see this information in the explainability drawer for the “Inactive Account Probing” check.
It is important that you can easily identify when a weak auth method is used by an user, for example when this method is a single phone number used by multiple accounts. This week we are adding a new tag (Weak MFA Configured) which is going to highlight an event in the user activity table, so you can easily spot such behaviors.
We want to display the user's external session id without needing to look inside the raw data. This week, we are adding this data to the user activity queues, allowing admins to filter user activity with just a few clicks that will automatically create the corresponding filter chip that admins can use to search for the session user activity or even reverse lookup search.
We now show which were the actual targets on the check explainability
We now show more targets on the Activity Table, such Policy Entity, Policy Rule, group and others
Searching for checks “Protected Population” groups by the group name prefix is now case insensitive.
When the Workday RaaS report had re-hires that appeared in more than one record in the report we had a bug causing us to sometimes show inaccurate data for those users. This is fixed so we always show the details of users with the latest Hire Date.
When configuring an user’s email as a Slack notification target we accepted deleted users. We no longer allow setting the email of a deleted user as a Slack notification target.
The “User in IDP” check but not in HRIS did not consider users that never logged in to the IdP. The check now considers all IdP users including users that haven’t logged in to the IdP yet.
In order to complement the new check, and get more information about Bypass code usage, it is now displayed as an MFA factor, with usage count in each user360 page.
