Create SaaS Policy Rule Recommendations

1. Log in to Strata Cloud Manager
2. Select ManageConfigurationSaaS SecurityDiscovered AppsPolicy Recommendations.
3. Add Policy.
4. 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.
5. Specify a Rule Name and Description. For example, Block Unsanctioned, File Sharing Apps from HR.
6. 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:

   1. 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.
   2. Select the User Activity you want the NGFW to detect.
   3. 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:

   1. 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.

      1. Select DEVICESetupACE.
      2. 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.
   2. 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.
   3. 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.
   4. 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.
7. 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.

   1. Select SettingsDirectory & External Services.
   2. 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:
      1. Select DeviceUser IdentificationCloud Identity Engine.
      2. Open the Cloud Identity Engine instance.
      3. View the User Attributes tab to identify the Primary Username format.
      4. 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.

   1. Select SettingsDirectory & External Services.
   2. Under the Directory Services section, click the name of the Azure Active Directory.
   3. 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:
      1. Selecting DeviceUser IdentificationGroup Mapping Settings.
      2. Open the Azure Active Directory instance.
      3. View the Group Attributes tab to identify the Group Name format.
8. (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.
9. (Optional) Specify a Data Profile.
10. Save the new rule.
11. 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.