🤖Manage Apps
Overview
View detailed context on your employee identities using the data tables in the Tibo dashboard. On the Employee, App, and Alert pages, you can get information about:
Apps your employees are accessing, including when and how they access.
Security alert for each employee and app.
You can also manage apps and integrations from these pages, such as:
Setting in-browser app banner messages to guide employees
Removing OAuth integrations you no longer need or do not trust
Classifying app sensitivity level and approval status
Assigning owners to apps
Finally, you can review and modify data from these pages, including resolving shared account findings and removing observed login methods and specific SaaS accounts.
Dashboard
The Dashboard page in the Tibo provides a snapshot of your apps and security alerts, as well as important trends across your organization.
Learn more about the dashboard in Dashboard.
View App Details
The Employees and Apps pages in the Tibo dashboard provide an overview of AI apps in use in your organization from two different perspectives: at the level of the employee, and at the level of the app. On both pages, you can see security alerts.
Employees page: Available in the left sidebar at Employees, this page shows a per-employee view into which apps a person uses and where they have security alerts with their accounts. It includes the following details:
Employee name, email address, and (if available via the API integration or Gravatar) photo.
A list of apps they use.
Employee browsers enrolled in Tibo.
Ability to filter by employee name, apps, browsers, OS, browser extension status, and security alerts.
Click on an employee record to see all their apps and security alerts.
Securing alert can include:
Leaked password
Weak password
Reused password
Shared account credentials
Unused third-party OAuth apps
MFA not registered
Suspicious mail rules
The employee record view also shows you:
A breakdown of their login methods (password, OIDC, SAML, Okta SWA).
Whether they're using a password manager in their recent logins.
A list of the accounts that are most vulnerable.
Which browsers they have enrolled in Push, including the browser version and the Push extension version.
When the Push extension last checked in for that employee.
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 leaked or reused passwords, no MFA, shared account credentials, etc.
An entry for each app showing how many accounts use it, and how those accounts logged in.
Ability to filter by app name, which employees use it, login methods, identity provider, last used, app approval and sensitivity level, owner, 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, as well as what login methods are being used to access the app.
View activity for other observed apps
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 company-owned domains, 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 and when the app was last seen. Click on the app to see which employee was using it.
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.
Use the app banners feature to communicate your security policies directly to employees when they visit the login or signup page for an app.
You can use app banners to:
Encourage employees to use a preferred app over an alternative.
Remind employees not to enter sensitive information or company data into ChatGPT or other AI tools.
Ask employees not to use an app until it can be reviewed by the security team.
Ask employees to log in with SSO instead of creating a standalone password account.
Or anything else you want!
From the Apps page, select an app you want to publish a banner for. On the app slideout panel, click Configure next to App banner, and enter your custom text. You can preview it in your browser, or go ahead and publish it.
App banners can be configured in three Modes:
Inform: End-users will see a banner message at the top of the page.
Acknowledge: End-users will see a large banner covering the center of the page that requires them to acknowledge the message in order to continue.
Reason: End-users will see a large banner covering the center of the page that requires them to submit a reason for using the app in order to continue.
For more examples of how to use app banners, refer to this help article.
Manage app sensitivity, approval state, and owner
You can also use Push to classify your apps' sensitivity level, whether they're approved for use, and who owns them.
From the Apps page, select an app and use the provided fields on the app slideout panel.
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
Guide to reviewing and classifying SaaS apps
Use the Accounts page to get a complete understanding of all the accounts that exist in your environment, including employees who may have multiple accounts on the same app, and how they are accessing an app (password, OIDC, SAML, Okta SWA).
You can also 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).
Prerequisites: In order to see complete MFA data, you must complete an API integration with your work platform (Microsoft 365, Google Workspace or Okta). 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 a password has been leaked, reused, or is weak (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, SAML or Okta SWA).
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 used, password manager usage, findings, used by, app sensitivity level and approval status, and apps.
When observing a SAML login, Push can recognize the following providers:
Okta
Google Workspace
Microsoft 365
JumpCloud
Duo Security
Ping Identity
Removing account data
If you need to do any cleanup of your account inventory (or to help with employee offboarding), you can select accounts you wish to forget. Forgetting an account will remove that data from Push, but does not impact the employee record itself.
Go to the Actions column on the Accounts page and select Forget account, or use the checkboxes and Bulk actions to remove account data.
Resolving shared account findings
If you know that employees are no longer sharing credentials for a specific account, you can manually resolve the shared account finding. Push does not have a way to detect when a shared account is no longer being shared.
To resolve a shared account, open the account details pane and click Resolve in the Employees using account section. Note: If Push sees the account get shared again, a new finding will appear.
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.
Related help articles
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. 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 OAuth integrations discovered in your organization.
Which platform an integration is linked to.
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.
Related blog posts
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.
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.
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.
Related help articles
Curious about whether you should just disable external email forwarding for your organization? Check out our blog post for Push’s point of view.
Last updated