View SaaS apps & employee activity
In this section:
Overview
Use the reports in the Push admin console to understand which accounts and SaaS applications employees are using at work, and to identify security risks such as:
Leaked passwords
Weak passwords
Reused passwords
Shared account credentials
Lack of MFA
Suspicious mail rules
Unused or risky third-party integrations
Not using a password manager
You can use ChatOps to work directly with employees to fix issues as they arise. See: Configure ChatOps.
In order to gain a full inventory of your cloud identities and apps, you must perform both an API integration and the installation of the Push browser extension on employee browsers in your environment. They each play a role in providing full visibility:
The API integration provides visibility into SaaS applications that your employees access via social login, such as Sign In with Google and Sign In with Microsoft, as well as third-party OAuth integrations they consent to. The integration also finds any security risks associated with these platforms, such as a lack of MFA and suspicious mail rules in employee inboxes.
The Push browser extension provides visibility into accounts that your employees create and access with a username and password, including unmanaged and non-SSO accounts, as well as vulnerabilities associated with these accounts. It also identifies social logins.
View SaaS usage details
The Employees and Apps pages in the Push admin console provide an overview of SaaS apps in use in your organization from two different perspectives: at the level of the employee, and at the level of the app.
Prerequisites: In order to see complete data on SaaS usage, you must complete an API integration with your work platform (Microsoft 365 or Google Workspace) and enroll employee browsers using the Push browser extension.
Employees page: Available in the left sidebar at Employees, this page shows a per-employee view into which SaaS a person uses. It includes the following details:
Employee name, email address, and (if available via the API integration or Gravatar) photo.
A count and list of the SaaS apps used by that employee.
Employee browsers used with the Push extension.
Recommended security improvements for their account, such as enabling MFA, improving a weak password, or changing a reused password to something unique.
Ability to filter by employee name, apps, browser, OS, browser extension status, ChatOps status, and findings.
Ability to export the list to csv.
Click on an employee record to view the full list of SaaS apps and any recommended security improvements.
Securing findings can include:
Weak password
Reused password
Leaked password
Shared account credentials
Lack of MFA protection
Mail rules associated with the account that forward email to external recipients
Not using a password manager
The employee record view also shows you which browsers they use, the browser version, the Push extension version, and when the extension last checked in.
Apps page: Available in the left sidebar at Apps, this page shows you an inventory of all SaaS apps in your environment discovered by Push. It includes the following details:
A table or tile view of all the SaaS apps discovered in your environment.
Security findings for each app, such as no MFA, shared account credentials, etc.
An entry for each app showing how many accounts use it, and whether it was discovered via the browser extension through username and password logins, or via API integration.
Ability to filter by app name, which employees use it, login types, and security findings.
Icons to represent if an app has been classified according to its sensitivity level and approval status.
Ability to set an owner for each app from the list of licensed employees.
Ability to add free-text notes about an app.
Click on an app entry to view the security findings for that app, and which employees have an account for that app.
Use the Sensitivity level field to classify apps that feature High, Medium, or Low sensitivity data or permissions. Use the Approval status field to classify apps that are approved or unapproved for use in your environment. Note that classifying an app does not trigger any actions in the Push platform; these categories are meant to support your record-keeping and risk assessment activities.
Use the Owner field to set a single owner for an app, selected from the list of licensed employees. The Owner field allows you to document who is responsible for an individual app, such as the primary administrator or team leader, to make communication about app management easier. Note that adding an owner does not trigger any actions in the Push platform.
Related help article
View activity for other observed apps
Beta feature
This feature is currently in private beta. If you would like to try this feature, please contact us.
From the Apps page, you can also view other apps that the Push browser extension has observed but doesn’t recognize as work apps. If the extension has discovered additional apps accessed by employees using your specified work domain(s), you’ll see them linked from the top of the page. Select the link to open a modal with more details.
An app will appear on the Other apps list if Push does not recognize it as a commonly used work app. You can see the list of apps that Push recognizes as popular work apps on our Supported SaaS page.
Note that for apps on the Other apps list, you will be able to see the login method (OIDC login or password login) and when the app was last seen. You will not be able to see the identities, accounts, or account security findings until the app is added as a work app.
From the Other apps list, you can mark apps as work apps you wish to manage on the main Apps page by selecting Mark as work app. Push will review your request and add the app as quickly as possible.
If you want to ignore an app, you can select Hide app.
You can still view hidden apps and their associated activity by adjusting the filter.
View account security
Find security issues with employee accounts, such as leaked, weak and reused passwords or shared credentials, and identify whether accounts are protected by multi-factor authentication (MFA) on the Accounts page, available in the left sidebar.
Prerequisites: In order to see MFA usage data, you must complete an API integration with your work platform (Microsoft 365 or Google Workspace). In order to see password security data, you must enroll employee browsers using the Push browser extension.
On this page, you can view the following details:
Whether an account is using social login or a password.
Whether a password has been leaked.
Whether a password is reused.
Whether a password is easily guessable.
Whether a password contains words found in a custom restricted word list.
Whether employees are sharing account credentials.
Whether an employee appears to be using a password manager, or is manually typing their passwords.
The login method for a given account (password, OIDC, or SAML).
When an account for a specific SaaS app and employee was last used.
Whether the employee has registered for MFA on their primary work account (Google or Microsoft) as well as certain popular SaaS apps, and what authentication methods they use for MFA.
Ability to filter by login method, identity provider, last seen, password manager usage, findings, used by, app sensitivity level and approval status, and apps.
Understanding MFA data in Push
The Accounts page reflects whether an employee has registered for MFA. With most platforms, users who register for MFA start getting prompted for MFA. However, with some platforms, such as Microsoft 365, users can register for MFA but an administrator still needs to enforce it before the user will be prompted. Refer to our blog post for some ideas on enforcing MFA with M365.
View third-party integrations
Review which third-party OAuth integrations users in your environment have consented to using the Third-party integrations page in the left sidebar at Use cases > Third-party integrations.
Prerequisites: In order to see third-party integrations, you must complete an API integration with your work platform (Microsoft 365 or Google Workspace). The Push browser extension also observes social logins (e.g. "Log in with Microsoft" or "Log in with Google").
Insight into the third-party integrations in your environment is important for addressing risks like consent phishing, and identifying undesired privileged access granted to potentially malicious third parties.
On this page, you can view the following details:
A list of all the third-party integrations discovered in your organization.
Which platform an integration is linked to (Microsoft 365 or Google Workspace).
Details about each integration's risk characteristics.
How many users have consented to an integration and whether an admin has consented to an integration.
What permissions an integration has been granted.
Whether the app is verified by Google, Microsoft, or the Push team, or has not been verified.
When an integration was last used. Note that data for integration usage is collected at the time you complete an API integration. We don’t backfill usage data.
The risk characteristics that Push provides are:
User Delegated High-Risk Assets: Whether user-delegated permissions exist for high-risk assets such as email, calendar, and contacts.
Exposes Some Data For All Users: Whether the app exposes some data for all users.
Long Tail: Whether the app has a “long tail,” meaning it has permissions beyond a simple social login and is used by fewer than 3 users.
Social Login Only: Whether an app is used solely for social login.
Click on an integration to view more details:
What permissions the application has, and for how many users. Click on a permission to view the exact scope that a user has delegated.
Which specific users have consented to the integration.
Its reply URLs.
Its app ID.
Delete third-party integrations
If you identify a third-party integration that is unused, unwanted, or otherwise problematic, you can remove it using the Push platform.
There are two ways to remove a third-party integration:
From the Push admin console
From a ChatOps channel message
For guidance on how to triage a problematic integration, refer to this Push blog post.
Deleting integrations from the admin console
To remove an integration from the admin console, go to Explore > Third-party integrations and then identify the integrations you wish to remove. Then use the Bulk actions > Delete integrations option to remove the selected integrations. You can also remove individual integrations by clicking on the three dots at the end of each row and selecting Delete integration.
You’ll have the option to delete the integrations for all applicable users in the Google Workspace or Microsoft 365 instance integrated with Push, or only those users who are assigned a license on the Push platform.
Deleting integrations from a ChatOps message
You can delete integrations directly from a ChatOps message if you enable the ChatOps topic for SaaS notifications so that your security team can receive messages in your specified team channel.
Find suspicious mail rules
Attackers often use malicious mail forwarding rules to retain access to sensitive email once they have successfully phished an employee. Use Push to review externally forwarding mail rules and verify whether a rule has been created by the employee or a malicious third party.
Prerequisites: In order to find suspicious mail rules, you must complete an API integration with your work platform (Microsoft 365 or Google Workspace).
As soon as you complete an API integration with your work platform, Push scans employee inboxes for mail rules that forward to external domains and lists the results on the Suspicious mail rules page, available under Explore in the left sidebar of the Push admin console.
The left panel of the screen shows discovered mail forwarding rules, including whether they’ve been triaged yet and whether the rules are still in use. Click on a rule to see more details about it:
The name of the rule.
The external email address it forwards to.
Which platform it appears on (Google or Microsoft).
The rule owner.
When the rule was first seen by Push.
What the rule is configured to do.
A timeline of activity associated with the rule.
From the right panel, you can accept the rule and close the alert in Push, or mark it as suspicious. Push will automatically disable mail rules you mark as suspicious if they were created in Microsoft 365. Google Workspace does not support disabling mail rules.
You can use the ChatOps workflow for suspicious mail rules to automate outreach to employees to ask if they created a rule. ChatOps also allows your security team to receive messages if an employee marks a mail rule as suspicious so they can respond right away. See the ChatOps topic for suspicious mail rules for more information.
Curious about whether you should just disable external email forwarding for your organization? Check out our blog post for Push’s point of view.