Week 47, 2022
Last updated
Last updated
Our aim is to help teams detect and respond to identity threats as quickly as possible. To do so, we know that it's crucial to have the right context in the right places. We’ve expanded our context to explain why a check might fail, what that means to you, and what you can do about it. Login to Admin Console in Okta. Unexpected activity in your Okta Admin Console is bad news and it’s not always obvious to know if that access was legitimate. To make this decision easier, we now exposed context on the IP address and country the account was accessed from.
New Email Forward Rules. A simple email forward rule is no big deal, right? While that’s generally true, it's also a common way for employees that are leaving the business to extract data. It’s worth checking to confirm that the rule is legitimate as it could save you a headache in the long run. As you can see below, we’re pulling out the right context you need to investigate further. Specifically, Oort surfaces the target email address to which the employee is forwarding their work emails as well as when it was created and the IP address of the offender.
Weak MFA used to successfully sign in. Having a second factor is important to prevent account takeovers – it means that attackers cannot simply reuse a breached email and password combination. Unfortunately, not all second factors are equal and MFA with SMS or voice calls are susceptible to attacks. Oort detects when weak (SMS or voice call based) methods are in use, so you can ensure that individuals with important privileges are not providing unnecessary opportunities to attackers. The necessary context is provided, including the platform logged in to and the action that was taken.
User Activity Anomaly. While we all strive to ensure this doesn’t happen, attackers sometimes get access to an account. In order to evade defenses they might try to perform certain administrative actions. When Oort sees these unusual actions being taken, a “User Activity Anomaly” check will fail. This will help to aid defense if attackers do gain access. In this week’s update, we now surface more detailed information about the nature of the unusual administrative activity.
One of the most popular workflows for taking action on Oort’s insights is via our Slack integration, which enables users to send notifications to specific users or channels in Slack. We’ve implemented some simple, but effective, features that will save you time.
First, we now include a default message, “Open Discussion”, for sending notifications for channels. Second, sometimes users will try to send a notification to a channel where they do not have access. Oort will clearly show this error message so you can either choose another channel or request access.
Have you got a high number of inactive users, but don’t know where to start? You’re not alone! Having lots of inactive users (both internal and external) is extremely common and we want to make it easier for you to go and resolve these.
To do so, we have introduced a new field for the “Account created date”. Users can use this knowledge of the account age to focus on removing the oldest inactive accounts first. We’ve provided ways for you to select, show and download this information to make it as easy as possible. Simply go to Toggle Table Columns and select “Created Date”.
Additional IP context menu, which was introduced in last week’s release notes, is now available on the User Overview page and Activity page
Improved the privacy and security of our Weekly Digest Email by reducing the recipients list to only include one email address
Tuned our popular Risky Parallel Sessions check to further reduce false positives
Okta session length. Logging into Okta multiple times a day can be annoying – why not just log in once and keep it open? Well attackers can “hijack” these sessions (you can read more about here). Long sessions can also enable terminated users to continue to have access to their inbox after termination or even for regular users to evade enforcement when you roll out new MFA policies until the next time they need to reauthenticate (maybe never). To reduce the risk of this happening, Oort identifies this issue if you do not have a maximum session lifetime or if it seems unusually high. We’ve included some helpful links within the platform to help you understand the best practices around this issue, so check it out!
