| Where Can I Use This? | What Do I Need? |
|---|
|
|
- SaaS Security Posture Management license
Or any of the following licenses that include the Data Security license:
|
SaaS Security Posture Management includes an
Identity component for identifying threats to your identity posture. You can
navigate to the Identity page in SSPM to examine these threats. The Identity page
provides an overview of identity-related threats across SaaS apps used in your
organization. From here, you have a unified view of human and non-human identities
in your organization and the threats related to those identities. By giving you
visibility into these threats, the Identity page enables to you to address areas of
concern and close security gaps.
To display information on the Identity page, SSPM
first runs identity scans of the SaaS apps. SSPM supports identity scans only for
certain SaaS apps. You can identify the supported SaaS apps from the Add Application
page (). On the Add Application page, the onboarding tiles for the supported
SaaS apps have an Identity label.
From the information that SSPM collects from the
identity scan, SSPM then applies a series of detectors to identify common identity
threats such as overpriviledged accounts, dormant accounts, and accounts with
unrotated credentials.
Additional detectors are available if you integrate
your identity provider with the Identity component. You can integrate either the
Okta or Microsoft Azure identity provider with the Identity component. To integrate
the Okta identity provider, complete the onboarding instructions for
Okta. To integrate the Microsoft Azure identity provider, complete the
onboarding instructions for
Microsoft 365. With access to
your identity provider, SSPM can apply a detector for multi-factor authentication
(MFA) threats to identify users with no MFA or weak MFA. By comparing account
information from the SaaS app instance with information from the identity provider,
SSPM can also apply a detector for identifying local accounts, which are accounts
that weren’t created through your identity provider.
To navigate to the Identity page, select .
View Identity Threats for SaaS Apps
Navigate to the Identity page in SSPM to view threats by individual SaaS app
accounts.
The Identity page provides an overview of identity-related threats across SaaS apps
used in your organization. Details about the threats are listed in tables on the
following tabs:
- The Identity Threats tab, which provides details for
each individual threat that SSPM detected. Each entry in this tab's table is
a separate threat detected for a single SaaS application account.
- The Unique Identities tab. On this tab, SSPM attempts to resolve a
user's various identities across SaaS apps into a single unified identity.
The best results are realized if you have onboarded an instance of either
the Microsoft Azure or the Okta identity provider. In this case, SSPM can
determine the various SaaS apps that you're accessing through single sign-on
(SSO). If you have not onboarded an identity provider, then SSPM uses email
login addresses to determine unique identities across SaaS apps. If multiple
SaaS app accounts are using the same email address for login, SSPM
consolidates those accounts into a unique identity.
To navigate to the Identity page, select .
SSPM supports identity scans for certain SaaS apps. If one or more of those
SaaS apps were scanned, SSPM displays identity threats for those SaaS app
instances. You can view a list of the SaaS app instances in the
Application Instance filter list. To view a list
of the SaaS apps that SSPM supports for identity scans, and to onboard
instances of those apps, Add Provider.
In the upper section of the Identity page, examine the overview of the identity
threats that SSPM detected across all instances of the supported SaaS apps.
This overview divides the threats into the threats detected for non-human
identities (such as services that authenticate to an API by using a token or
an API key) and human identities (accounts tied to individual people). For
the non-human and human identities, the threats are further categorized by
the types of threats (as indicated by the threats discovered by the
different threat detectors).
A donut chart represents all the detected identity threats, with slices of
the chart representing threats for non-human and human identities relative
to the whole. Additional slices of the donut chart show the percentage of
different threat types detected relative to the whole. You can hover over
the slices in the donut chart to display more details.
In the lower section of the Identity page, view the information shown in the
Identity Threats table, which lists the individual threats that SSPM
detected.
The table lists each threat that was detected for SaaS accounts. The table
shows information about the account where the threat was detected. The
account information shows the type of account (human or non-human) and the
application. The Detector column shows the type of threat, as indicated by
the detector name. Each entry in the table is a single threat, even if
multiple threats were detected for the account. To view all the threats for
a particular account, use the Search by Account Name
filter in the upper-left corner of the Identity page.
To investigate a threat in more detail, click the
View
More link for the threat.
If the Account Name in the table appears as a hyperlink, click the link
to open an access graph, which shows the different SaaS apps that the
identity can access. The access graph shows information, such as the
SaaS apps that the user accesses through the identity provider versus
direct login to local accounts. The access graph also shows SaaS apps
that are accessed through non-human accounts that the unique identity
created.
In the lower section of the Identity page, view the information shown in the
Unique Identities table.
The table lists each unique identity that SSPM was able to discern from your
identity provider or other sources. The Detector column shows the types of
threats that SSPM detected for the unique identity across SaaS apps that the
identity can access.
When viewing either the Identity Threats or
the Unique Identities tab, you can click the download icon to export
a CSV file that contains the table information.
Optionally, filter the information on the Identity page to show only the
information that you're interested in.
For example, you can filter the information by identity type (human or
non-human), detector, or application instance. You can apply these filters
using the Add Filter control, or by clicking on the
relevant slices in the donut chart. To return to the full unfiltered view,
Reset the filters.
Investigate the accounts further and take action to resolve threats.
For example, you might investigate dormant accounts to determine if you can
delete them, or you might investigate guest accounts to ensure that their
access to your resources is properly restricted. If SSPM is linked to an
issue tracking system, you can create a ticket to resolve account threats.
To do this, select one or more accounts names in the table and
File Ticket.
Identity Threat Detectors
The Identity Security component has a variety of detectors for discovering specific
types of identity threats, such as dormant accounts or accounts with unrotated
credentials.
The Identity Security component has a variety of detectors for discovering specific types
of identity threats, as described in the following table. SSPM displays the detected
threats on the Identity page.
| Detector | Description |
|---|
|
Dormant
|
Detects accounts that have not been accessed for a specified period.
Because the account owner isn’t logging in, they will be less likely
to notice if the account is compromised. They will also not have
received password expiration notifications or prompts to change
their password. As a result, the account might have an old password
that predates newer requirements for password length and
complexity.
By default, the threshold SSPM uses for detecting dormant accounts is
30 days. In the upper section of the Identity page, you can click on
the current threshold value to reset it.
For GitHub Enterprise accounts, SSPM
determines how long an account has been dormant based on the 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 Expiring
|
Detects accounts whose credentials will expire within a set number of
days. By default, the threshold SSPM uses for detecting expiring
credentials is 30 days. In the upper section of the Identity page,
you can click on the current threshold value to reset it.
|
|
Credentials Not Rotated
|
Detects accounts that have not had their credentials rotated within a
set number of days. Account credentials include user ID and password
combinations, as well as credentials for accessing APIs, such as API
keys and OAuth tokens. Failure to rotate these account credentials
can represent a significant risk to your organization.
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 a
bad actor to continue to obtain valid access tokens.
By default, the threshold SSPM uses for detecting non-rotated
credentials is 30 days. In the upper section of the Identity page,
you can click on the current threshold value to reset it.
|
|
Guest
|
A guest account is an account designed to provide
external users, such as a partner or contractor, limited or
temporary access to the SaaS application. Guest accounts 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. |
|
Local Account
|
Local accounts 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 component identifies these risky local accounts by
comparing account information from the SaaS app instance with
account information from the identity provider. For this reason, the
Identity component displays local account information only if you
have onboarded an instance of either the Microsoft Azure or the Okta
identity provider. If the Identity component isn’t displaying this
local account information, you can Add
Provider and follow the steps to onboard Okta or Microsoft 365. In the upper section of the Identity page, the Identity
Provider field shows the identity provider that the
Identity component uses to detect local accounts. If more than one
identity provider was onboarded, you can select a different one from
this list. Selecting a different identity provider does not
immediately refresh the information displayed on the Identity pages.
The displayed information will be refreshed after the next identity
scan completes.
|
|
MFA Misconfiguration
|
Multi-factor authentication (MFA) misconfigurations are users with
no MFA or with weak MFA.
If MFA enforcement policies are not configured for the identify
provider, a user can access SaaS apps through the identity provider
by using only one factor. If those credentials are compromised,
there is no additional layer of security to prevent unauthorized
access to their account. These users should enroll in a strong
second factor for MFA.
Weak MFA refers to users who are enrolled in one or more additional
factors for MFA, but whose factors are not resistant to phishing,
social engineering, or interception attacks. The weak MFA factors
include factors such as email verification and short message service
(SMS) verification.
Weak second factors offer less protection than stronger factors, such
as biometric login or a hardware key. If MFA enforcement policy
rules on the identity provider are not configured to prevent
sign-ins using only weak factors, then the account can be more
easily compromised. These users should enroll in a strong second
factor for MFA.
|
|
Overprivileged
|
Overprivileged accounts are accounts that have elevated,
administrator-level access to the SaaS app. For some administrators,
this level of access might be legitimate. However, for other
accounts, the elevated privileges are not needed for the human or
non-human entity to complete their tasks. To follow the principle of
least privilege, you should investigate accounts with elevated
permissions to verify that they have only the permissions necessary
to complete their work.
|
