Summary
This week, we’re excited to add a new integration for Salesforce. Managing the disconnect between users in Salesforce and other identity platforms can be a real security headache, which I’ll explore in more detail below. We’ll be talking about additional use cases that can benefit from getting data from Salesforce in future weeks, so stay tuned!
This week also brought new filtering options within the Users tab, which will enable you to quickly access the information you need when performing investigations.
Onwards!
💰 Salesforce integration
Salesforce holds some of the most sensitive commercial information in a business: it’s full of customer details, quotes, purchase orders, and other sensitive data.
It’s also common for organizations to give access to external users who may well not be in the IDP. These may be external organizations, or even personal Gmail accounts. If these external users are not in Azure Active Directory or Okta, this can be particularly worrying.
In this release, you can now integrate Salesforce into Oort (this will take a matter of seconds). Using the filters in the Users Tab, you can filter by those users that only exist in Salesforce. When you click into the User 360 profile itself, you will notice a Salesforce Card will show on the left hand panel.
This is for those security teams looking to gain visibility into who (especially external users) has access to Salesforce data that may be outside of your IDP.
🎚️Filter by Microsoft User Risks
Microsoft provides a lot of information about risky events relating to users. It provides data around unlikely travel, risky IP addresses, and other events. These risk attributes can provide powerful indicators of risk, but are often too noisy.
In this release, you can filter users by the severity of the risk attributes assigned to them. In the Users tab, you can filter by “High”, “Medium”, and “Low”. This enables you to filter out the noise of the low risk attributes, and only focus on the higher risks.
Things get even more interesting when you combine that with other filters. For example, by only focusing on those users with successful logins and only focusing on High risks, you can dramatically reduce the noise.
🌐 Admins across different platforms
With Oort pulling in data from so many sources, simply knowing a user is an admin may not be enough. You may well want to know what platform, specifically, that user is an admin for. In this release, we’ve introduced a filter to do just that.
For example, the following will find admin users that are not admin in Okta. This will help you to narrow down your searches and make your investigations quicker.
isAdmin:true AND integrationInstanceDetails.providerAdmin.keyword:OKTA__false
🔍 Search by User Principal Name (UPN)
In Microsoft Active Directory, a User Principal Name (UPN) is a username and domain in an email address format. In a UPN, the username is followed by a separator "at sign" (@) followed by the active directory's internet domain.
You can now search for this specific UPN in the User Tab’s search bar, and it will return the related user. This filter will also work for the Profile Login in Okta.
integrationInstanceDetails.userKey.keyword:
Bug Fixes and Minor Improvements
- Users not in IDP. If a user is not part of an IDP but is disabled, the status of the end user will now reflect the disabled state.
- Compliance Trend. If Oort has insufficient data, it will display “Not available yet” until 15 days of data is collected.
- Slack in multiple tenants. If you already have a Slack workspace in one tenant, you will not be able to add it to another Oort tenant. To make this clear, you will see an error message.
- Slack notifications. A new workflow exists to confirm a user is part of the Slack workspace you are planning to install the Oort bot on.