The admin role in Okta comes with great power (and responsibility), so it is best to monitor whenever a user is getting admin privileges, and make sure that this was done for legitimate reasons.
We have therefore added a new check that monitors the “user.account.privilege.grant” event in Okta and shows all the users that were assigned admin privileges.
If you are using Okta Log Streaming you will get near real-time notifications when we observe the “user.account.privilege.grant” event.
When performing an investigation and looking into the reasons behind a failed check event, there was no easy way to see all failing events at once, which was limiting the context you could get.
We added a bunch of different ways to achieve this (for checks that support explainability).
In order to be redirected to a filtered activity view that will include all failing events you can:
When performing an investigation, a short time to resolution is critical, so we’re making sure that you can perform investigations as fast as possible.
When trying to understand why a check was failing, you had to navigate back and forth between User Details Activity and Check tabs, causing context changes and a waste of time.
Now it’s possible to do this straight from the activity view, without needing to go back to Checks.
When clicking on a failing check or associated event in the activity tab, the side drawer will include all the information available for that failure (the same information we are showing in User Details/Checks), as well as all the available actions.
As a security analyst I would like to know which Okta events were executed in the impersonated session to help investigate and make sure that this capability was used legitimately.
The check context shows the Okta events that were executed in the same Okta session as the impersonated event.
In this demo the impersonated session was used to register a new MFA factor.
Our User360 page’s purpose is to provide you an exhaustive view of a user’s actions, to provide all the context and data needed for an investigation in a single pane of glass. Therefore we keep adding new data points, and this week the Azure AD admin events are now part of this User360 view.
Each check is part of one (or several) topics, in order to help you organize your work and look at related checks all at once.
Since we’ve been introducing new checks related to admin access, we have also added a new topic. You can use it to filter checks in the main checks page.
In order to make it easier to manage files downloaded from the Oort interface, we have reworked the file names.
They now use the following format: --.csv
For example: oort-users-20220921-090000.csv – list of users for Oort tenant, downloaded Sep 21, 2022 at 9am of local time.
Last week we introduced the ability to toggle columns for the MFA factors table, so that you can align the data you see to your needs.
This week we have made that functionality slightly more intuitive to use:
Customized table settings are automatically saved when toggling columns on/off. If you’d like to get back to the default view, just click on “Restore default” at the bottom.
If you are an Azure Active Directory user with a P2 license, you are most likely familiar with the Risky users functionality, where Microsoft looks at a variety of signals to identify potentially risky sign-ins.
We are now collecting risky users data, and will soon start using it to enrich user information, display more data, and improve our Identity Threat Detection algorithms. Stay tuned!
You can enable the collection of risky users data in the Azure AD integration advanced settings:
It is worth repeating: Weak factors like SMS or calling are actively being exploited by attackers to hijack identities and get into your environment.
As a reminder, SMS as an MFA factor is weak for a variety of reasons, the most obvious ones being:
We highly recommend you switch every single user in your environment to stronger forms of MFAs, and we are making it easy thanks to our “Weak MFA” check.
Today we are making it even more obvious by highlighting weak MFA factors in the Authentication factors table of our user360 page.