SaaS Security
Create SaaS Policy Rule Recommendations
Table of Contents
Expand All
|
Collapse All
SaaS Security Docs
Create SaaS Policy Rule Recommendations
Learn how to create SaaS policy rule recommendations on SaaS Security Inline.
Where Can I Use This? | What Do I Need? |
---|---|
|
Or any of the following licenses that include the SaaS Security Inline license:
|
You can create a SaaS policy rule
recommendation from scratch, or, alternatively, apply a predefined policy rule recommendation
or copy an existing recommendation. Before you create any recommendations, consider
a few collaboration and authoring guidelines.
SaaS policy rule recommendations enable you to recommend Security policy rules to
your Palo Alto Networks
NGFW administrator or Prisma Access administrator. SaaS Security Inline pushes SaaS policy rule recommendations to your NGFW or Prisma Access. Your NGFW administrator or
Prisma Access administrator will see your policy rule recommendations in the
NGFW web interface or Prisma Access web interface, then can
accept and commit the SaaS Security policy rule. After your NGFW administrator or Prisma Access administrator commits the
policy rule, the policy rule becomes active. You can update your SaaS rule
recommendations at any time.
Alternatively, SaaS Security administrators can create Internet Access rules instead of policy
rule recommendations to simplify policy rule creation for SaaS app security using
snippets and folder configurations. This allows you to
enforce consistent SaaS app security regardless of the enforcement point, eliminate
policy implementation delay, and reduce the risk of misconfigurations. This
streamlined workflow enables you to fully utilize the SaaS Security Inline
capabilities, achieve a stronger security posture for your SaaS environment all
while reducing the managerial overhead of implementing new security policy rules for
your SaaS apps.
Before you begin:
Ask your NGFW administrator to verify that SSL decryption is enabled
on the NGFW. SSL decryption is required for PAN-OS to detect specific
user activities, such as upload or download activities, in the network traffic. SSL
decryption is also required for PAN-OS to identify individual application tenants in
the network traffic.
(NGFW Only) Ask your NGFW administrator to verify that all
NGFW have log forwarding enabled as instructed in
the ACE deployment. The SaaS Security web interface cannot display SaaS application visibility data and might not be
able to enforce policy rule recommendations without logs for all
NGFW.
- Log in to Strata Cloud ManagerSelect ManageConfigurationSaaS SecurityDiscovered AppsPolicy Recommendations.Add Policy.Select the application granularity for your policy recommendation.You can define policy recommendations that are effective at the Application Level or at the application Tenant Level. Application-level policies, if committed on the NGFW, will affect all instances of the application identified in the policy recommendation. Tenant-level policies, if committed on the NGFW, will affect only the application tenants identified in the policy recommendation. Before you select the application granularity for your policy recommendation, consider some common scenarios for defining application-level and tenant-level policy recommendations.The option to create tenant-level policy recommendations appears only in SaaS Security Inline for NGFW, or on tenants that have a Next Generation Cloud Access Security Broker (CASB-X) license.Tenant-level policy recommendations have the following requirements for NGFW and Prisma Access. Although you can submit policy recommendations without meeting these requirements, NGFW and Prisma Access administrators can view and import the recommendations only if these requirements are met:
- NGFW: Tenant-level policy recommendations require a NGFW running PAN-OS 10.2.5 (or a later 10.2 release) or PAN-OS 11.1.0 or later.
- Prisma Access: Tenant-level policy recommendations require Prisma Access running a 10.2.8 / PA 5.0 or later data plane.
Specify a Rule Name and Description. For example, Block Unsanctioned, File Sharing Apps from HR.Specify the network traffic to detect and the action to take.If you are defining a policy at the application level, complete the following steps:- Specify the applications that you want to control.You can only create recommendations for enforcement on your NGFW for SaaS apps that have an App-ID. You can determine if a given SaaS app in the Application Dictionary has an App-ID based on its How is this app detected? attribute.Use the filters (such as the Category and Risk filters) to help you locate the SaaS applications so that you capture all the application SaaS Applications. For example, if your intent is to only include high risk SaaS applications, filter by risk.For a rule to take action on a SaaS application, the user activities you choose must be supported by all the SaaS applications you select. User activities are unique to each SaaS application. For example, if a SaaS application does not provide a means for a user to upload a file, your rule cannot include that user activity. The SaaS Security Inline web interface returns an error when you select a user activity that the SaaS application does not support. Use the Capabilities matrix to help you determine which user activities the SaaS applications support.
- Select the User Activity you want the NGFW to detect.
- Specify a Response to instruct the NGFW or Prisma Access administrator take action on
the network traffic that matches the policy rule.Although your NGFW or Prisma Access has other actions, SaaS policy rule recommendations support Block only. Block denies the traffic that matches the rule from entering your network.
If you are defining a policy at the tenant level, complete the following steps:- Select the application that you want to control at the tenant level.
If the application that you want to control does not appear in the selection list, then SaaS Security Inline does not support tenant-level detection for that application. Cancel this policy rule recommendation, and start again to Add Policy. This time, select the option to define the policy recommendation at the Application Level.Currently, tenant-level detection is available for the following applications. Some applications use different constructs, such as workspaces, that are similar or analogous to tenants. For the purpose of tenant-level control, SaaS Security Inline treats these constructs as tenants. The traffic that SaaS Security Inline can monitor to detect application tenants also differs from application to application.For some applications, tenant-level support requires you to enable additional header logging on the NGFW. When additional header logging is enabled, the NGFW logs more information about the applications to Strata Logging Service. This additional information enables SaaS Security Inline to detect the individual application tenants for these applications. Because SaaS Security Inline is the only consumer of this information, and because you might not require tenant-level policies for these applications, the additional header logging is disabled by default. The applications for which additional header logging is required are identified in the following table's Additional Header Logging Required column.To enable the additional HTTP header logging on the NGFW, complete the following steps. To enable additional HTTP header logging, the NGFW must be running PAN-OS 11.2.3 or later.
- Select DEVICESetupACE.
- Under SaaS Inline Settings, Enable Additional HTTP Header Logging.
Within 24 hours after the additional logs are available in Strata Logging Service, SaaS Security Inline will be able to detect the individual tenants for the applications.Application Category Detected Tenant Type Supported Traffic Additional HTTP Header Logging Required Aha! (Aha.io) Development Tenant Browser No Amazon Bedrock Artificial Intelligence Account ID Browser Yes Amazon Polly Artificial Intelligence Account ID Browser Yes Amazon Q Artificial Intelligence Account ID Browser Yes Amazon SageMaker Artificial Intelligence Account ID Browser Yes Amazon Sagemaker Ground Truth Artificial Intelligence Account ID Browser Yes Amazon Titan Artificial Intelligence Account ID Browser Yes Amazon Transcribe Artificial Intelligence Account ID Browser Yes Azure AI Services Artificial Intelligence Account ID Browser Yes Atlassian Confluence Collaboration & Productivity Tenant Browser No Azure OpenAI Artificial Intelligence Endpoint Name Browser No Bitbucket Development Workspace Browser, Mac and Windows CLI (For Https Config) No Box Content Management Tenant Browser No However, basic HTTP header logging must be enabled on the NGFW for the referrer component. For more information, see the note following this table.ChatGPT Artificial Intelligence Workspace ID Browser Yes Claude Artificial Intelligence Organization ID Browser No Dropbox Content Management Team ID Browser Yes Egnyte Content Management Tenant Browser, Mac Native and Windows Native No Frontify Content Management Tenant Browser No Github Development Organization Browser, Mac and Windows CLI (For Https Config) No Microsoft OneDrive for Business Collaboration & Productivity Tenant Browser No Microsoft OneNote Collaboration & Productivity Tenant Browser Yes Microsoft Outlook Office Tenant Browser Yes Microsoft Sharepoint Collaboration & Productivity Tenant Browser, Mac Native and Windows Native No Microsoft Teams Collaboration & Productivity Tenant ID Browser, Mac Native and Windows Native Yes MS Powerapps Development Tenant Browser Yes Okta Security Tenant Browser No Salesforce Sales Cloud Sales Tenant Browser No Sharefile IT Infrastructure Tenant Browser No Slack Collaboration & Productivity Workspace Browser, Mac Native and Windows Native No Webex App Collaboration & Productivity Tenant Browser No Windows Azure General Business Tenant Browser Yes Workday HCM HR Tenant Browser No Workplace From Meta Collaboration & Productivity Tenant Browser No Zendesk Customer Service Tenant Browser No However, basic HTTP header logging must be enabled on the NGFW for the referrer component. For more information, see the note following this table.Zoom Collaboration & Productivity Tenant Browser No To enable SaaS Security Inline to detect Box and Zendesk tenants, HTTP header logging must be enabled on the NGFW for the referrer component. HTTP header logging of referring web pages provides added visibility into the web traffic on your network, which SaaS Security Inline uses to detect the individual tenants.Tenant detection for Microsoft OneDrive for Business does not include personal tenants. To block personal use of Microsoft OneDrive, create an application-level policy to block the Microsoft OneDrive Personal application. - Specify an Action to be applied to the NGFW for the network traffic that matches the policy
rule. Although your NGFW or Prisma Access has other actions, SaaS policy rule recommendations support Block and Allow only. The Block action is supported for all applications that support tenant-level detection. A subset of these applications also support the Allow action. Support for the Allow action is provided only for a subset of applications, including Box, GitHub, Microsoft SharePoint, and Slack.The Block action denies the traffic that matches the rule. The Allow action, if supported for the selected application, is used to permit exceptions to a Block action. For example, you might create a policy recommendation to Allow access to Box on certain tenants, and then create a separate policy recommendation to Block access for all other tenants. Because allowing application network traffic is the default, a policy recommendation to explicitly Allow certain traffic is unnecessary unless it is paired with a policy recommendation to Block traffic for other tenants.When you define Allow and Block policy recommendations, the order in which these policies are evaluated on the NGFW is important. On the NGFW, when traffic matches a policy rule, the defined action is triggered and all subsequent policies are disregarded. For this reason, a more specific policy recommendation to Allow traffic for certain applications must be placed before a more general policy to Block traffic for all other tenants.If you are defining a policy recommendation that uses the Allow action for a Box tenant, the NGFW must already allow traffic for the App-ID boxnet-base. If the App-ID boxnet-base is blocked on the NGFW, then the Allow action will not be effective.
- Select the User Activity that you want the NGFW to detect. You can select one or more activities, such as file Create, Delete, and Share activities.
- Select at least one Tenant that you want to
control. You can select up to 30 tenants.When the Allow action is supported for an application, you can specify that the policy recommendation applies to Any tenant. The Any specification acts as a wildcard to match all current and future tenants. On the NGFW, when an imported policy specifies Any tenant, the policy will apply to all tenants unless an earlier policy in the NGFW's evaluation order specifies a different action for a tenant. In this way, you can define one policy recommendation to Allow the actions for selected tenants and another to Block the actions for Any other tenants.To filter the list of tenants, select a Tenant Type.
Specify User & Groups.By specifying users or groups, the policy recommendation will apply only to those users and groups. Creating policy rule recommendations based on user group membership rather than individual users simplifies administration because you don’t need to update the recommendation whenever group membership changes.The user and group information that is displayed depends on whether the Cloud Identity Engine is available on your tenant.- If the Cloud Identity Engine is not available on your tenant, then SaaS Security Inline discovers users by using Strata Logging Service logs. To discover groups, SaaS Security Inline uses Azure Active Directory (AD), provided you have performed an Azure Active Directory Integration.
- If the Cloud Identity Engine is available on your tenant, and directory
sync is configured in Cloud Identity Engine for Azure AD, SaaS Security Inline obtains user and group information from Azure
AD through the Cloud Identity Engine. If directory sync is configured
for multiple Azure AD instances, SaaS Security Inline obtains user
and group information from all of the Azure AD instances.SaaS Security Inline also obtains the dynamic user groups that the Cloud Identity Engine has defined. A dynamic user group uses tags as filtering criteria for group membership. As soon as a user matches the filtering criteria, that user becomes a member of the dynamic user group. Defining dynamic user groups in Cloud Identity Engine enables you to create a policy that adapts to changes in user behavior, location, and other conditions where context plays a key role in determining access.Even when the Cloud Identity Engine is available on your tenant, you still have the option to view the user information discovered from Strata Logging Service logs and groups from the earlier method of Azure Active Directory Integration. In this case, you can toggle between showing Discovered Users & Groups from Strata Logging Service logs or showing CIE Users & Groups. Be aware that the users and groups listed in these different views can vary for the following reasons:
- The users in the CIE Users & Groups view will show only the users from one or more Azure AD instances that are synced in Cloud Identity Engine. Because the users displayed in the Discovered Users & Groups view are discovered by examining Strata Logging Servicelogs, the Discovered Users & Groups can show users who do not have accounts in the Azure AD instances.
- Because the users displayed in the Discovered Users & Groups view are discovered by examining Strata Logging Service logs, only users who generated network traffic are listed in the Discovered Users & Groups view. The CIE Users & Groups view shows all users from the Azure AD instances that are synced in Cloud Identity Engine, regardless of whether the users generated network traffic.
- The CIE Users & Groups view displays dynamic user groups. This information is available only through Cloud Identity Engine and so these groups are not shown in the Discovered Users & Groups view.
- The groups displayed in the Discovered Users & Groups view are obtained from only a single instance of Azure AD, provided you have performed an Azure Active Directory Integration. The groups displayed in the CIE Users & Groups are obtained from all the Azure AD instances that are synced to Cloud Identity Engine.
An advantage of using Cloud Identity Engine is that it provides more information in the Users & Groups table, such as a user's role, department, and region. You can filter the Users & Groups table based on this information to more easily locate the users and groups based on their attributes. For example, by using the Type filter, you could filter the table to show only Users, Active Directory Groups, and CIE Dynamic User Groups.
Select whether you want to create the policy recommendation from the Discovered Users & Groups view or from CIE Users & Groups view. If these options do not appear, then the Cloud Identity Engine is not available on your tenant or does not have directory sync configured for Azure AD. In this case, you can select only discovered users and groups.When SaaS Security Inline submits a policy recommendation to the NGFW, it must specify the user and group information in the same format that the NGFW uses to identify users and groups in policies, such as a common-name, distinguished name, or SAM Account Name. If SaaS Security Inline sends the user or group information in the wrong format, the recommendation can be imported on the NGFW, but will not have the desired effect.If the policy is identifying users and groups from Cloud Identity Engine, the user's Primary Name and Group Name formats are included in the recommendation that is sent to the NGFW, and must match the formats specified on the NGFW. SaaS Security Inline determines which format to use from the Cloud Identity Engine settings on the Settings page. Complete the following steps to ensure that SaaS Security Inline sends the information in the correct format.- Select SettingsDirectory & External Services.
- Under the Cloud Identity Engine section, make sure that the Directory
Attribute for the user's Primary Username and the Group Name match the
user and group attributes
specified on the NGFW. On the NGFW, you
can locate the relevant settings by completing the following steps:
- Select DeviceUser IdentificationCloud Identity Engine.
- Open the Cloud Identity Engine instance.
- View the User Attributes tab to identify the Primary Username format.
- View the Group Attributes tab to identify the Group Name format.
If the policy is identifying users from Strata Logging Service logs, SaaS Security Inline discovers the group information from your Azure Active Directory integration. If no groups display, verify that you performed this integration. SaaS Security Inline determines the format to use for group names from the Directory Services settings on the Settings page. Complete the following steps to ensure that SaaS Security Inline sends the group information in the correct format.- Select SettingsDirectory & External Services.
- Under the Directory Services section, click the name of the Azure Active Directory.
- Make sure that the Group Name attribute matches the group attribute specified on
the NGFW. On the NGFW, you can locate the
relevant setting by completing the following steps:
- Selecting DeviceUser IdentificationGroup Mapping Settings.
- Open the Azure Active Directory instance.
- View the Group Attributes tab to identify the Group Name format.
(Optional) Specify Device Posture to enforce what devices can and cannot access specific SaaS apps, including device ownership and device compliance.Your device posture selection automatically creates a Host Information Profile (HIP) object for mobile devices after the policy recommendation is imported as a policy.- Mobile Device Managed Status—Choose Managed when the device is company-owned, whether a dedicated device or shared with Unmanaged when the device is employee-owned, or Any for both.
- Mobile Device Compliant Status—Choose Complaint when the device adheres to your organization’s security compliance requirements, Non‑Compliant when it does not, or Any for both.
(Optional) Specify a Data Profile.Save the new rule.Enable the recommendation when you’re ready to submit the recommendation for enforcement.If you create separate tenant-level Allow and Block policy recommendations to achieve particular results, remember that your desired results will depend on the order in which the policies are evaluated on the NGFW. Make sure that the NGFW administrator places a more specific Allow policy before a general Block Any policy. If a general Block Any policy is evaluated first, the NGFW will ignore the more specific Allow policy.