Summary
Last week we introduced the first of our “Actions.” This week, we’ve released additional capabilities by enabling MFA resets from within Oort.
Over the past week, we’ve also introduced new options for customizing idle timeout periods in Oort and further checks related to our Salesforce integration.
Thanks for reading!
📱 Reset MFA
IT help desk teams spend a lot of their day helping employees that have lost their phones to reset their MFA factors. Resetting a user’s MFA should not be trivial, however. Attackers often reset their targets’ MFA so they can register their own. It is, therefore, critical for IT help desk teams to verify that the user is who they claim to be.
Oort’s User 360 profiles already provide a single pane of glass for IT help desk teams to understand who the user is. Armed with this information, help desk analysts can ask questions to confirm their identity, such as:
- Where did they last login from?
- What factor did they last use?
- Which of the following applications have you used in the last day?
With this release, you can reset all MFA factors for Okta and Duo from within the User 360 profile itself. Simply go to “Actions” and select “Reset MFA”. To further assist involving the IT help desk, Oort has a dedicated RBAC role for the IT help desk, enabling them to take action without changing settings in Oort.
✏️ Okta Long Sessions - Filter by Session ID
Last week we released the new Okta Long Running Sessions check. This check will identify sessions that exceed the recommended session length of 7 days. Long sessions without re-authentication pose a security threat by increasing the chance and impact of session hijacking.
In this release, we have added new context to the check activity panel to provide added detail, including the session ID, session authentications in the last 30 days, and the number of events in the session.
For further context, you can pivot on the session ID chip, which will take you to the user activity tab. As you can see below, this shows all activity for the session in question.
⌛ Customize Idle Timeout Period
Given the risk of session hijacking with long sessions, we have made Oort sessions idle timeout 15 minutes by default. According to OWASP, “common idle timeout ranges are 2-5 minutes for high-value applications and 15-30 minutes for low-risk applications.” NIST is slightly more generous, with a recommended timeout of 30 minutes.
While this advice is helpful, we understand that each organization has its unique risk threshold, and, given how often teams use Oort, they’d like to define their session timeout period.
At the same time, we understand that Oort is a tool used frequently. You can now define how long the session timeout period is. Within Tenant Settings, you will now see a tab for Idle Timeout where you can change timeout settings from the default.
🗺️ Access to Salesforce from New Country
In January, we first announced our Salesforce integration. You can read more about why we built this integration in our blog, Protecting Salesforce Accounts from Takeovers and Ungoverned Access.
We’ve been busy making sure we provide the best possible insights from this integration. Now that we collect geoinformation as part of this integration, Salesforce is included in the New Country for Tenant check. With this check, Oort alerts on successful logins from a new country for the tenant to help identify compromised Salesforce accounts.
Bug Fixes and Minor Improvements
- Okta API tokens. Oort now collects Okta API tokens using Okta's official API, and you will see this option in the Okta integration set-up modal.
Direct message templates. If you have custom check settings for Okta Long Running Sessions, this will display in the direct message templates.
Events with multiple checks. If multiple checks are associated with an event, all of these checks will be shown in the activity panel.