View Salesforce Account Risks

1. To navigate to the Identity Security dashboard, select Posture Security Identity.
2. View the information for Human/Non-Human Accounts.

   The dashboard displays information about human and non-human accounts for a Salesforce application instance. If no Salesforce instance is connected to SSPM, the dashboard prompts you to onboard a Salesforce instance. If more than one Salesforce instance is connected to SSPM, you can select a different instance from the SaaS Accounts list.

   From the selected Salesforce instance, the dashboard displays summary information for ACCOUNTS DORMANT FOR OVER a specified number of days, CREDENTIALS NOT ROTATED IN a specified number of days, and OVER-PRIVILEDGED accounts. If at least one instance of the Microsoft Azure or Okta identity provider was onboarded to SSPM, the Identity Security dashboard also displays the ACCOUNTS MISSING IN IDP by comparing account information from the Salesforce instance with information from the identity provider. If more than one identity provider instance is connected to SSPM, you can select a different one from the Identity Providers list. You can also Add Provider to onboard a different Microsoft Azure or Okta instance.

3. Inspect the information displayed in the upper section of the dashboard for a high-level summary of the account risks that the Identity Security component detected in your Salesforce instance. The top section of the dashboard displays the following information.

   Displayed Information	Description
   ACCOUNTS DORMANT FOR OVER a specified number of days.	The number of human accounts that have not been accessed for the specified period. These might be accounts that were not deleted after the account owner left the organization, and were forgotten. Or a user might have set up a new account without deleting, or continuing to access, the older one. Dormant accounts represent a signification security risk because bad actors can use them to gain access. Accounts that have remained dormant for a significant period can represent the greatest risk, because they might predate enforced requirements for MFA and for password length and complexity. You can display the number of accounts that have been dormant over 30, 60, or 180 days, and can click the number of dormant accounts to filter the table of Human Accounts in the lower section of the page. The table provides more information about each dormant account. It shows when the account was created, when the account was last accessed, and when the account password was last updated.
   CREDENTIALS NOT ROTATED IN a specified number of days.	The number of non-human accounts that have not had their credentials rotated for the period specified. This summary is the number of accounts with non-rotated credentials for non-human accounts only. However, from the table of Human Accounts, you can view when an account's credentials were last rotated. Non-human account credentials include service account passwords, as well as credentials for accessing APIs, such as API keys and OAuth tokens. Failure to rotate these non-human account credentials can represent a significant risk to your organization. Service account passwords that are not rotated are more vulnerable to brute-force attacks, especially if the password predates enforced requirements for password length, complexity, and reuse. API keys that are not rotated increase the window of opportunity for bad actors to exploit leaked or compromised keys. Similarly, if the client secret of an OAuth application is not rotated, a compromised refresh token will enable to a bad actor to continue to obtain valid access tokens. You can display the number of non-human accounts with credentials that have not been rotated in 30, 60, or 180 days. You can click the number of accounts to filter the table of Non-Human Accounts in the lower section of the page. The table provides more information about each account, such as when the account was created, and when the account credentials were last updated.
   ACCOUNTS MISSING IN IDP	The number of human accounts that are local accounts, which are accounts that were not created through your identity provider. Local accounts are a security risk because the identity provider is not managing access for them. Because they have bypassed the identity provider, it is difficult to enforce security policies for them. The Identity Security component identifies these risky local accounts by comparing account information from the Salesforce instance with account information from the identity provider. For this reason, the dashboard will display the local account information only if the Identity Security component is integrated with an instance of either the Microsoft Azure or the Okta identity provider. If the dashboard is not displaying this information, you can Add Provider and follow the steps to onboard Okta or Microsoft 365. The identity provider that the Identity Security component uses for this comparison is the identity provider that is currently selected in the Identity Providers list. If more than one identity provider instance is connected to SSPM, you can select a different identity provider from the list. When you add a new identity provider or switch to a different identity provider, it can take approximately 15 minutes for the Identity Component to determine the local accounts based on the new identity provider's account information. You can click the number of accounts that are missing in the identity provider to filter the table of Human Accounts in the lower section of the page. From the table you can gain additional insights about the local accounts, such as the email address that is associated with the account.
   OVER-PRIVILEDGED ACCOUNTS	The number of human accounts that have excessive permissions, which are probably not required for the user to do their job. Overpriviledged accounts are ordinary user accounts that have administrator permissions. For Salesforce, the overprivileged accounts are accounts that have Modify All Data permissions. You can click the number of overprivileged accounts that are missing in the identity provider to filter the table of Human Accounts in the lower section of the page. From the table you can gain additional insights about the local accounts, such as the email address that is associated with the account.

4. Navigate to the Human Accounts tab, which displays details about the human accounts in the Salesforce instance.

   Human accounts are accounts that are associated with an individual who accesses the account through a user interface with ID and password credentials. The displayed information includes the email address of the account owner, when the account was last accessed, and when the account credentials were last rotated. If the Identity Security component is integrated with your identity provider, the table will also show whether the account is a local account that was created through the identity provider. In the table, you can also Add Filter to filter the table by the various account attributes.
5. Navigate to the Non-Human Accounts tab, which displays details about the non-human accounts in your Salesforce instance.

   Non-human accounts are typically services that authenticate to your Salesforce instance through an API by using an OAuth token or an API key. The displayed information includes the email address of the human user who created the non-human account, when the account was created, and when the account credentials were last rotated. In the table, you can also Add Filter to filter the table by the various account attributes.

   When viewing either the Human Accounts or the Non-Human Accounts tab, you can click the download icon to export a CSV file with a list of the non-human or human accounts. The list will contain all users unless you applied a filter to the table.
6. Take action to resolve issues with the non-human or human accounts.

   If SSPM is linked to an issue tracking system, you can create a ticket to resolve account issues. To do this, select one or more accounts on either the Human Accounts or Non-Human Accounts tab, and File Ticket. To view the tickets that were created, navigate to the table's Tickets tab.