SaaS Security
Configure Settings on Data Security
Table of Contents
Configure Settings on Data Security
Define internal domains, add trusted users and domains, configure acceptable levels
of asset exposure, and set the time zone and language for SaaS Security.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
Or any of the following licenses that include the Data Security license:
|
Before you start scanning, define any collaborators and the asset exposure level to
trigger incident reports. Then, configure global settings for Data Security to
use when scanning your sanctioned SaaS applications.
- Define Your Internal Domains
- Collaborators
- Exposure Level
- Define Users and Domains
- Enable Data Masking
- Configure Email Alias and Logo
Define Your Internal Domains
Add internal domains to Data Security to determine
if an asset is being shared externally with an untrusted user.
One of the first things you need to do is
to define your internal domains. Data Security uses the list
of internal domains you define to determine if the Collaborators on
an asset are internal to your company, or if the asset shared with
external users. Data Security determines this by matching the
domain name in a collaborator’s email address against the list of
internal domains defined. Depending on your policy rules, Data Security identifies an asset as an incident if shared with external users.
A trusted collaborator overrides untrusted domains.
Similarly, an untrusted collaborator overrides a trusted domain. For example,
you might determine that there is no business reason to trust a file
modification from fax_service@mycompany.com.
Because
Data Security uses the internal domains list to determine the Exposure
Level of an asset during the scan process, you must define
your internal domains list before you begin scanning your
cloud apps. Additionally, you can build in flexibility when you
define your internal domains:
- Wildcard matching—Use of wildcard (*.<domain>) is supported.
- Subdomains—You don't need to explicitly list subdomains; instead, use a wildcard (*.<domain>).
When
you modify the internal domains list, consider that you might need
to update the exposure, depending on the discovery state for a given
asset:
Asset | Rescan required to update exposure? |
|---|---|
Existing, discovered assets | Yes. Rescan to enable Data Security to recalculate exposure. |
Future, undiscovered assets | No. Data Security automatically recalculates
the exposure. |
The Internal Domains list applies to all
cloud apps on Data Security so you must be an administrator
with a Super User role or an Admin role with access to All Apps
to modify this setting.
- To add your internal domains, select .
- Enter a comma-separated list of your Internal Domains.The internal domain you add here is displayed in the All Domains section only where there is an asset associated with the domain.
- To define any of the domains listed under the All Domains section as Trusted or Not Trusted, use the Actions menu against that domain.
- Save your changes.
Collaborators
Specify internal and external collaborators, and trusted
and untrusted users to configure the incident settings on Data Security.
Although different SaaS applications have different terminology
for sharing and collaboration, within Data Security, a collaborator
is any person who can access, view, preview, download, comment,
or edit a managed asset. To provide granular control over what types
of sharing pose a risk within your organization, Data Security
classifies Collaborators differently:
Because Collaborators apply to all cloud apps on Data Security, you must be an administrator with a Super Admin role or an
Admin with access to all apps to modify this setting.
- Internal vs. External Users—Data Security uses the domain name in the email address associated with the user’s cloud app account to determine whether the user is internal to your organization or not. You must Define Your Internal Domains before you begin scanning your application data so Data Security can properly identify assets shared with users who are external to your organization.
- Trusted vs. Untrusted Users—Using Data Security, you can configure a policy rule to create an incident if an external user has access to an asset. In some cases, sharing with external users—even though they are not part of your organization—does not pose a threat. For example, they might be partners or other trusted third-parties who you can mark as Trusted. Or, if you have entire domains that belong to trusted partners or user groups, you can mark those domains as Trusted so those users with email addresses from that domain are trusted users.When you asses incidents, you can update the domain trust settings in and mark the domain as either trusted or untrusted.
Alternatively, when you view asset details you can explicitly designate an external collaborator as Trusted to exclude from incident discovery or Untrusted to ensure both new and modified assets shared create incidents. Changing trust settings for a user or a domain changes the underlying global policy Data Security uses when scanning assets. Trust settings enable more granular policy control while still allowing you to distinguish between internal and external sharing.
Exposure Level
Data Security scans assets for exposure levels to
identify how and with whom the asset is shared.
Data Security uses an exposure level status to describe how your shared assets display in an
application and determines file exposure by analyzing all users who have access to the
file. Although every SaaS application has its own settings for controlling how and with
whom users may share assets, Data Security provides a mechanism for setting and
enforcing acceptable exposure levels consistently across all your managed apps.
On Data Security, each policy—both the default rules as well as any custom rules you
define—enable you to set a level of exposure identifying an asset as being at risk
(except for Sensitive Documents rules, which match documents with predefined
characteristics).
The exposure level is just one match criteria available in a policy and, therefore, determining
the minimum level of exposure posing a threat depends on the other match criteria, and
what threat the policy protects against.
For example, the WildFire policy scans all your assets for files containing malware. In this
case, a file containing malware poses a threat no matter the exposure level. However, if
you add a Sensitive Credential policy rule to protect an engineering GitHub repository
used for sharing code throughout the company, any external sharing poses a risk, so you
should configure the rule to match on Public and External exposures.
Data Security scans assets for the following exposure levels:
Unknown exposure level is used exclusively to search for assets, not policies, and only applies
to AWS S3 buckets.
Exposure Level | Description |
|---|---|
Public | An asset is Public if it contains either
of the following:
|
External | The owner invited one or more users outside
of your organization to collaborate on the asset. |
Company | The owner created a company-wide URL giving anyone
in the company direct access to the asset. |
Internal | Includes assets the owner has not shared.
Also includes assets the owner has shared, but only with users within
the company. These users have an email address in the enterprise
domain name. |
Shared via Custom URL | The owner created a custom link, vanity
URL, or password-protected link for direct access to the asset and then
shared this asset (directly or indirectly) using the link. This option is for Box assets only and hidden if you're not using Data Security to secure Box
applications. |
Define Trusted and Untrusted Users and Domains
Define users and domains as trusted or untrusted on Data Security to provide more granular control and monitoring of
who accesses assets.
One of the first things you did when setting
up Data Security was Define
Your Internal Domains to determine if the user is internal
to your organization. If an external user has an email address that
does not belong to an internal domain, you can use Data Security to define users and domains as trusted or untrusted to protect
your assets and have better granular control over who has access.
After you define external users and domains, Data Security reports
any assets shared inadvertently or maliciously.
Because the Trusted and Untrusted Users and Domains list applies to all cloud apps on Data Security, you must be an administrator with a Super Admin role or Admin with
access to all apps to modify this setting.
- Select . Define your users and domains as per your need.
- Save your setting.
Enable Data Masking
Configure data masking on Data Security to control
the exposure of data displayed in an incident snippet.
Data Security uses data masking to mask the data in the snippets. Data masking
enables you to control how Data Security stores and displays sensitive data,
such as credit card numbers or Social Security numbers, to the administrator and
other nonprivileged users who can view the snippet of content matched as an
incident.
By default, Data Security displays the last four digits of the value in cleartext
(partial masking). For example, Data Security displays a
snippet of credit card number as XXXX-XXXX-XXXX-1234.
You can specify that Data Security display values in cleartext (no masking) or
fully mask the data to hide all the values.
Because
the Data Masking setting applies to all cloud apps on Data Security, you must be an administrator with a Super Admin role or Admin
role with access to all apps to modify this setting.
- To specify the storage and reporting of sensitive data by Data Security, select .For financial and PII policy rules, Data Security displays a snippet of 100 bytes of content before and after the violation.
- Do not mask—Displays all the values in cleartext.
- Partial Mask —Displays only the last four digits in cleartext.
- Full mask—Does not display any values.
- Save the changes.Save your changes.
Configure the Email Alias and Logo for Sending Notifications
Customize the email alias and logo on Data Security
for policy violation notifications.
Data Security is configured with an SMTP service enabling you to send email
notifications when a policy violation occurs. When you email a user, the default
display name is Data Security and the sender email address is
no_reply@paloaltonetworks.com. Although asset owners can
reply to this default sender email address, no_reply
discourages them. Best practice is to change this default and others to personalize
your communications. Use the logo feature to legitimize the email sender so asset
owners don't mistake your email as spam.
Because
General Settings applies to all the cloud apps on Data Security, you must be an administrator with a Super Admin role or an
Admin role with access to all apps to modify this setting.
- To configure email alias, select .
- Sender Name—Name of the sender of the email message. Best practice is to use a name with imperative, such as Security Administrator or Compliance Auditor.
- Reply-to-Email—Address to use for communications. Best practice is to use a distribution list or an alias with a group of administrators or compliance auditors. Optionally, you can choose an alias that automatically triggers a helpdesk ticket upon reply.
- Upload an Email Logo: . Browse to select the image, then Save.
