Week 38, 2022

New features

New check: Admin role assigned to user in Okta

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.

Improvements

View all activity from explainability

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:

• On a check page, click on the “view logs” option of a failing user row

• On a user page, click on the “view logs” option of a failing check rowevents

• On a User Details/Checks page, click on the new “View in activity” button on the explainability sidedrawer

• On a User Details/Activity page, click on the new “View all events” button on the explainability sidedrawer

View explainability details on audit log records

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.

Adding context to Okta Admin Impersonation check

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.

Azure AD audit log events stream are now part of user activities

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.

New “Administrator access” check topic for admin-access related checks

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.

Download filenames improvement

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.

UX improvement for table columns toggling

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.

Azure Risky Users Collection

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:

Highlight weak user factors in authentication factors table

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:

• They are not encrypted, so fairly easy to intercept

• They are very vulnerable to phishing and social engineering attacks

• Companies who send those SMS are themselves vulnerable to large scale attacks (like Twilio)

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.

Bug fixes

• Downloading relevant data in check details Previously we weren’t downloading all relevant users data when clicking “Download” in check details. Now in the downloaded file users can find all the data from the users failing check table.

• We did not remove the user’s manager information from the IdP tile after the information was deleted in the IdP. We now delete the user’s manager information from the IdP tile when the information is deleted in the IdP

• We showed the HRIS tile for only some of the users that were in the HRIS file. This is fixed.