Create SaaS Policy Rule Recommendations

Create SaaS Policy Rule Recommendations

1. Log in to Strata Cloud Manager
2. Select ManageConfigurationSaaS SecurityDiscovered AppsPolicy Recommendations.
3. Add Policy.
4. Select the app granularity for your policy recommendation.

   You can define policy recommendations that are effective at the Application Level or at the app Tenant Level. App-level policy rules, if committed on the NGFW, will affect all instances of the app identified in the policy recommendation. Tenant-level policy rules, if committed on the NGFW, will affect only the app tenants identified in the policy recommendation. Before you select the app granularity for your policy recommendation, consider some common scenarios for defining app-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 dataplane .
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're defining a policy at the app level, complete the following steps:

   

   1. Specify the apps 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 apps so that you capture all the app SaaS Applications. For example, if your intent is to only include high risk SaaS apps, filter by risk.
      For a rule to take action on a SaaS app, the user activities you choose must be supported by all the SaaS apps you select. User activities are unique to each SaaS app. For example, if a SaaS app does not provide a means for a user to upload a file, your rule can’t include that user activity. The SaaS Security Inline web interface returns an error when you select a user activity that the SaaS app does not support. Use the Capabilities matrix to help you determine which user activities the SaaS apps 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're defining a policy at the tenant level, complete the following steps:

   

   1. Select the app that you want to control at the tenant level.
      If the app that you want to control does not appear in the selection list, then SaaS Security Inline does not support tenant-level detection for that app. 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 apps. Some apps 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 app tenants also differs from app to app.
      For some apps, tenant-level support requires you to enable the following SaaS Inline settings on the NGFW.

      • Additional HTTP Header Logging. When additional header logging is enabled, the NGFW logs more information about the apps to Strata Logging Service. This additional information enables SaaS Security Inline to detect the individual app tenants for these apps.
      • Session Tracking. When session tracking is enabled, the NGFW logs additional user and tenant information to Strata Logging Service. This capability enables you to allow some app traffic for a tenant, while blocking traffic from specific user accounts on that tenant. For example, for a trusted vendor, you might allow traffic only for your organization's accounts for a particular app, while blocking traffic for the vendor's accounts or personal accounts for the app.
      Because SaaS Security Inline is the only consumer of the additional header logging and session tracking information, and because you might not require tenant-level policy rules for these apps, these settings are disabled by default. The apps for which additional header logging or session tracking is required are identified in the following table's Additional Requirements column.
      To enable additional HTTP header logging or session tracking 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. To enable session tracking, the NGFW must be running PAN-OS 11.2.5 or later.

      1. Select DEVICESetupACE.
      2. Under SaaS Inline Settings, enable the Enable Additional HTTP Header Logging as Enable Session Tracking settings based on the app requirements outlined in the following table.

      

      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 apps.
      Application	Category	Detected Tenant Type	Supported Traffic	Additional Requirements
      Aha! (Aha.io)	Development	Tenant	Browser	None
      Amazon Bedrock	Artificial Intelligence	Account ID	Browser	Additional HTTP Header Logging
      Amazon Polly	Artificial Intelligence	Account ID	Browser	Additional HTTP Header Logging
      Amazon Q	Artificial Intelligence	Account ID	Browser	Additional HTTP Header Logging
      Amazon SageMaker	Artificial Intelligence	Account ID	Browser	Additional HTTP Header Logging
      Amazon Sagemaker Ground Truth	Artificial Intelligence	Account ID	Browser	Additional HTTP Header Logging
      Amazon Titan	Artificial Intelligence	Account ID	Browser	Additional HTTP Header Logging
      Amazon Transcribe	Artificial Intelligence	Account ID	Browser	Additional HTTP Header Logging
      Azure AI Services	Artificial Intelligence	Account ID	Browser	Additional HTTP Header Logging
      Atlassian Confluence	Collaboration & Productivity	Tenant	Browser	None
      Azure OpenAI	Artificial Intelligence	Endpoint Name	Browser	None
      Bitbucket	Development	Workspace	Browser, Mac, and Windows CLI (For Https Config)	None
      Box	Content Management	Tenant	Browser	Basic HTTP header logging must be enabled on the firewall for the referrer component. For more information, see the note following this table.
      ChatGPT	Artificial Intelligence	Workspace ID	Browser	Additional HTTP Header Logging
      Claude	Artificial Intelligence	Organization ID	Browser	None
      Dropbox	Content Management	Team ID	Browser	Additional HTTP Header Logging
      Egnyte	Content Management	Tenant	Browser, Mac Native, and Windows Native	None
      Frontify	Content Management	Tenant	Browser	None
      Github	Development	Organization	Browser, Mac, and Windows CLI (For Https Config)	None
      Gmail Beta: Gmail support is available only for early access.	Office Programs	Tenant	Browser	Session Tracking
      Google Drive	File Sharing	Tenant	Browser	Session Tracking
      Google Keep	Internet Utility	Tenant	Browser	Session Tracking
      Google Sites	Content Management	Tenant	Browser	Session Tracking
      Microsoft OneDrive for Business	Collaboration & Productivity	Tenant	Browser	None
      Microsoft OneNote	Collaboration & Productivity	Tenant	Browser	Additional HTTP Header Logging
      Microsoft Outlook	Office	Tenant	Browser	Additional HTTP Header Logging
      Microsoft Sharepoint	Collaboration & Productivity	Tenant	Browser, Mac Native and Windows Native	None
      Microsoft Teams	Collaboration & Productivity	Tenant ID	Browser, Mac Native, and Windows Native	Additional HTTP Header Logging
      MS Powerapps	Development	Tenant	Browser	Additional HTTP Header Logging
      Okta	Security	Tenant	Browser	None
      Salesforce Sales Cloud	Sales	Tenant	Browser	None
      Sharefile	IT Infrastructure	Tenant	Browser	None
      Slack	Collaboration & Productivity	Workspace	Browser, Mac Native, and Windows Native	None
      Webex App	Collaboration & Productivity	Tenant	Browser	None
      Windows Azure	General Business	Tenant	Browser	Additional HTTP Header Logging
      Workday HCM	HR	Tenant	Browser	None
      Workplace From Meta	Collaboration & Productivity	Tenant	Browser	None
      Zendesk	Customer Service	Tenant	Browser	You must enable Basic HTTP header logging on the NGFW for the referrer component. For more information, see the note following this table.
      Zoom	Collaboration & Productivity	Tenant	Browser	None

      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 app-level policy to block the Microsoft OneDrive Personal app.
   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 apps that support tenant-level detection. A subset of these apps also support the Allow action. Support for the Allow action is provided only for a subset of apps, 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 app, 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 app network traffic is the default, a policy recommendation to explicitly Allow certain traffic is unnecessary unless it's paired with a policy recommendation to Block traffic for other tenants.

      When you define Allow and Block policy recommendations, the order in which these policy rules are evaluated on the NGFW is important. On the NGFW, when traffic matches a policy rule, the defined action is triggered and all subsequent policy rules are disregarded. For this reason, a more specific policy recommendation to Allow traffic for certain apps must be placed before a more general policy to Block traffic for all other tenants.

      If you're 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 app, 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. (Optional) Specify User Accounts

   The User Accounts field is shown only if the selected app can leverage the firewall's session-tracking feature. The apps that can leverage the session-tracking feature are shown in the table above. You can then use this field to Select user accounts that you want to be affected by the policy. For example, for the selected app, you can block personal accounts while allowing traffic for corporate accounts. By default, the User Accounts setting is Any, in which case all user accounts are affected by the policy.

   To use this feature, you must enable session tracking on the firewall.
8. 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 Service logs, the Discovered Users & Groups can show users who don’t 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 the CIE Users & Groups view. If these options don’t appear, then the Cloud Identity Engine isn’t 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 policy rules, 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 won’t 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.
9. (Optional) Specify Device Posture to enforce what devices can and can’t 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.
10. (Optional) Specify a Data Profile.

    If you have an active Enterprise Data Loss Prevention (E-DLP) license, you can add predefined or custom data profiles to prevent exfiltration of sensitive data. Data profiles specify how you want to enforce the sensitive data that you’re filtering.
11. Save the new rule.
12. 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 policy rules 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.