New features
New Check: Admin Impersonation in Okta
Okta offers the ability for admins to impersonate any user in their account (and benefit from the permissions of that user in the environment).
While this can be useful for admins to do their job, if an attacker manages to take over an Okta admin account, they can essentially access any resource in the company. Recently this technique is believed to be used in relation to the Lapsu$ breach.
In response to this, we have created a new check that alerts you when an admin impersonates a user in Okta, so you can investigate and make sure that this capability was used legitimately.
Choose the data you want to see in User Authentication Factors table
Across the board, we are making it increasingly easier to read, use and download the tables all across the Oort interface. This week, we are giving you the capability to choose which columns you want to see in the Authentication factors table of the User360 page, and save your preferences.
To customize the table, click on the “Columns” button in the table header, toggle the column options in the popup menu. Note that the options marked with Lock icon can not be toggled off.
To save the table settings, click on the “Save as default” button at the bottom of the menu. The settings will be saved on the device that is currently used.
Recently added factors tagged in User Authentication Factors table
When performing an investigation on a user suspected to be a victim of malicious activity, it is recommended to check and review any recent changes in MFA factors, as attackers might be setting up the account to access it easily later.
We are making this easier and more obvious by tagging any authentication factor added in the last 7 days, and showing the tag on the User360 page.
Azure applications with expired or soon-to-be-expired certificates are tagged and highlighted
Whenever you perform an investigation, any piece of context can be helpful. That’s why we now tag Azure applications with expired or soon-to-be-expired certificates, and show that tag in the applications page of a User360.
The “App expiration warning window” is configurable in the “Upcoming App Key Expiration” check settings (the default value is 90 days).
Failing check actions now available from the check page users list
This usability improvement aims to reduce the time it takes to investigate and take remediation steps a little more.
The actions menu (that was already available in other places in the interface) is now available directly in the users table of any check page.
From here you can:
- Send a notifications
- >> To the users themselves by: email, direct message service (Slack, MSTeams)
- >> To a specific direct message channel (Slack, MSTeams)
- Exclude the user from the check
- Redirect to the user details page and view the corresponding activity logs
- Mark the funding as Interesting or False Positive. As a reminder, Oort uses that feedback information to always improve the accuracy of the checks.
Filter by External Session ID on Risky Parallel Sessions
Previously it was tricky to visualize events related to a parallel sessions check on the activity view. We were only able to filter by some events, but not by sessions, making it a very manual job.
When investigating a parallel sessions check, the session IDs are now much easier to see and read.
Additionally you now can click on the session IDs and be redirected to the activity view adequately filtered. Alternatively you can click on “View activity from all sessions” which will concatenate all activity sessions with ORs, generating a query like ‘“session1” OR “session2”
The user activity stream page now contains activities impacting the user
Showing activities performed by an admin on the user helps understand the security posture of the user. For example, if an admin impersonates a user, it is critical to know that when performing an investigation on that user.
The user’s activity tab now shows activities performed by an admin on the user in addition to the activities performed by the user.
Past activities performed on users as targets will not be backported into the activities view. The stream will include such activities from now on.
The context and of a check failure is now stored in the audit record
When investigating the timeline of a user, it is common to see a failed check event. If you click on that event, you will now see the details of why this check failed in the first place, without having to navigate somewhere else. This makes investigations faster, and improves total time to remediation.
Build factors list based on OIE Authenticator enrollment methods
Okta’s new identity engine added “Authenticators” and “Authenticators to users” enrollments as security methods. MFA events now reference those methods by id and not by user factor id as it was in the classic Okta engine.
We now support this new model, to provide accurate Okta MFA factors list and usage counts.
For this to work, make sure that in your Okta integration advanced settings the “Authenticators” and “Authenticators to User” data types are selected for data collection.
Better display of explainability details
Previously we displayed all explainability details as a JSON, making it hard to scan when there were nested objects inside the details.
Now we parse the explainability details. If they are strings or numbers, we render them as a list. Only when there are nested objects we proceed to show them as JSON
Bug fixes
On top of all those exciting new capabilities, we have been squashing some bugs:
- Truncating Failed Notification Slack messages
- Programmatic Slack messages have a limit of 3,000 characters for a text field. This caused an error which prevented the message from being delivered.
- In cases where the failing check context exceeds this limit we now truncate the context information in the Slack message.
- Adding Workday checks compatibility
- We did not show HRIS checks that are compatible with the native Workday integration. Now we do!
- Handling of whitespaces in IP CIDR uploaded files
- When the uploaded IP CIDR file had trailing empty lines after the JSON data we failed to parse the file. We now parse these files correctly.
- Provider card for Auth0 was missing on user details page
- ETL was checking the Auth0 user type that is now removed from the API. Auth0 provider card is not listed on User Details page
- Duo phone methods status
- Duo response contains an activated field that is false when Duo Mobile is not enabled. We split Duo phone method status detection based on that field, and mark only Duo Mobile factor based it
- Duo SMS usage count
- We fixed Duo SMS usage count
- Display array in JSON Renderer properly
- Previously we were showing arrays as object representation (like 0: value, 1: value, etc). Now we parse them properly as arrays
Deprecated features
We removed obsolete dashboards from our UI. While those dashboards were providing value when they were created, their functionality was replicated and enhanced via new checks and better reporting in the users and checks section.
A new dashboard section is in the works though, so stay tuned!