Zero Trust Based Cloud Applications and Its Data Access Control Solution is Now GA

[pneelakrishn]

What: SaaS Security Inline Adaptive and Attribute-based Access Control Policies 

 

Description

Administrators can now create user identity-based and cloud dynamic user group based policies (Role, Department, Region, Manager, AD Group) from SaaS Inline to be enforced in various control points. The User Section on SaaS Inline policies will not only include discovered users but also all users in the organization, enabled by the CIE integration. Admins can now distinguish between named and guest users. This solution, launched on April 29, 2024, is designed to empower our customers to fully utilize the platformization strategy from Palo Alto Networks.

Why:

In today's dynamic digital landscape, the transition to cloud-based services presents both opportunities and security challenges. Palo Alto Networks' Zero Trust-based cloud application and data access control solution offer a vital response to these challenges through SaaS Security Inline Adaptive and Attribute-based Access Control Policies. This solution empowers administrators to create finely tuned access policies based on user identities and dynamic user groups, leveraging attributes such as role, department, and AD group memberships. By tailoring access permissions to specific user profiles and contextual factors, organizations can ensure robust data protection while maintaining operational efficiency. Seamless integration with the Cloud Identity Engine facilitates a smooth transition to a cloud-centric identity management approach, ensuring security infrastructures remain agile and adaptable to evolving threats and business requirements. Furthermore, user attribute-based policies and detailed user attribute pages provide administrators with comprehensive visibility into user identities and group memberships, enabling informed access control decisions. In essence, Palo Alto Networks' solution equips organizations to confidently embrace cloud technologies, knowing that their data assets are safeguarded and compliance standards are met in today's ever-evolving digital landscape.

Key Benefits:

• Seamless Transition to Cloud Identity Engine at Customer’s own pace
• Dynamic Risk/Custom group-based adaptive SaaS Inline policies 
• User attribute-based SaaS Inline policies 
• User detail page with attributes and all the groups (AD and CDUG) the user belongs to. 

How it Works:

SaaS policy rule recommendations enable you to recommend Security policy rules to your Palo Alto Networks firewall administrator or Prisma Access administrator. SaaS Security Inline pushes SaaS policy rule recommendations to your firewall or Prisma Access. Your firewall administrator or Prisma Access administrator will see your policy rule recommendations in the firewall web interface or Prisma Access web interface, then can accept and commit the SaaS Security policy rule. After your firewall administrator or Prisma Access administrator commits the policy rule, the policy rule becomes active. You can update your SaaS rule recommendations at any time.

Before you begin: Ask your firewall administrator to verify that SSL decryption is enabled on the firewall. 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 firewall administrator to verify that all firewalls 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 firewalls.

Here are the clear steps for guidance:

Step 1: Navigate to SaaS Security Inline.

Step 2: To navigate to the Policy Recommendations view, select Discovered AppsPolicy Recommendations.

Step 3: Add Policy.

Step 4: Select the application granularity for your policy recommendation.

Step 5: Specify a Rule Name and Description. For example, Block Unsanctioned, File Sharing Apps from HR.

Step 6: Specify the network traffic to detect and the action to take.

Step 6a: Specify the applications that you want to control.

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.

Step 6b: Select the User Activity you want the firewall to detect.

Step 6c: Specify a Response to instruct the firewall or Prisma Access administrator take action on the network traffic that matches the policy rule.

Step 7: Specify User & Groups.

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.

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

Step 9: (Optional to include DLP) Specify a Data Profile.

Step 10: ​​Save the new rule. Enable the recommendation when you’re ready to submit the recommendation for enforcement.

Once the policy recommendation is enabled it’ll be automatically synced to controls points. And network admin can now import the policy enforcing access controls! 

Stay Secure, Stay Empowered!

Best Regards,

Priyanka Neelakrishnan  |  Product Line Manager, Cloud Security