Assess Identity Security

View Account Risks on SSPM

1. Log in to Strata Cloud Manager.
2. Select ManageConfigurationSaaS SecurityPosture SecurityIdentity.
3. View the information for Human/Non-Human Accounts.

   The dashboard displays information about human and non-human accounts for an instance of one of the supported application types:

   • GitHub Enterprise
   • Office 365
   • Salesforce

   If no instance of a supported application type is connected to SSPM, the dashboard prompts you to onboard one. If more than one instance or a supported application type is connected to SSPM, you can select a different instance from the SaaS Accounts list.

   From the selected app instance, the dashboard displays a summary of account risks for the app. The risk types displayed in the dashboard will vary depending on the app type (Salesforce or Office 365). Risks can include ACCOUNTS DORMANT FOR OVER a specified number of days, CREDENTIALS NOT ROTATED IN a specified number of days, OVER-PRIVILEDGED accounts, and GUEST 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 app 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.

   
4. 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 app instance. Depending on the type of app, 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 weren’t 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. For GitHub Enterprise accounts, SSPM determines how long an account has been dormant based on last time the user performed certain Git repository activities. These activities include creating or deleting a repository, cloning a repository, pushing changes to a remote repository, or fetching changes from a remote repository.
   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 app isn’t 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 weren’t created through your identity provider. Local accounts are a security risk because the identity provider isn’t managing access for them. Because they have bypassed the identity provider, it's difficult to enforce security policy rules for them. The Identity Security component identifies these risky local accounts by comparing account information from the app 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 isn’t displaying this information, you can Add Provider and follow the steps to onboard Okta or Microsoft 365. For GitHub Enterprises, if a user has selected the Keep my email addresses private option, the Identity Security component of SSPM will be unable to determine whether the account is local. In the table, the Local column for the account will display False. 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	Depending on the application, this information might apply to human or non-human accounts. The number of accounts that have excessive permissions, which are probably not required for the human user or non-human service to complete their tasks. Overpriviledged accounts are ordinary user accounts that have administrator permissions. For Salesforce, the overprivileged accounts are human accounts that have Modify All Data permissions. For GitHub Enterprise, the overpriviledged accounts are non-human accounts that have admin:write permissions to organization or repository. You can click the number of overprivileged accounts that are missing in the identity provider to filter the table of Human Accounts or Non-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.
   GUEST ACCOUNTS	This information applies to Office 365 instances only. Guest accounts in Office 365 enable you to collaborate with people who are outside of your organization. Although guest accounts are designed to give outside users access to your resources for legitimate purposes, they can represent a risk if their access isn’t properly restricted. For example, an external collaboration setting in Azure Active Directory might grant guest users the same access as members. Another Azure Active Directory setting might allow anyone in the organization to invite guest users, including guests and non-administrators.
   TOKEN EXPIRES IN a specified number of days.	For GitHub Enterprises, the number of non-human accounts whose access token will expire in the specified number of days. To identify the tokens that represent the greatest risk, select the option Never from this list. Tokens that never expire represent the greatest threat, because, if a bad actor acquires the token, they could use it indefinitely. This number of expiring tokens includes only fine-grained personal access tokens. It does not include GitHub's personal access tokens (classic). GitHub recommends that you use fine-grained personal access tokens instead of personal access tokens (classic).
5. Navigate to the Human Accounts tab, which displays details about the human accounts in the app instance.

   Human accounts are accounts that are associated with an individual who accesses the account through a web 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.
6. Navigate to the Non-Human Accounts tab, which displays details about the non-human accounts in your app instance.

   Non-human accounts are typically services that authenticate to your app 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.
7. 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.