Make Security Simple: Streamline Policies in Unified SASE

Balancing Configuration and Control is critical for reducing security risks and management complexity

The Secure Access Service Edge (SASE) service, along with its associated architecture, comprises a powerful amalgamation of multiple security components. These include a stateful inspection firewall, Intrusion Detection and Prevention System (IDPS), DNS security, DoS/DDoS protection, Secure Web Gateway (SWG), Zero Trust Network Architecture (ZTNA), Cloud Access Security Broker (CASB), and many more. These components grant administrators the ability to configure them through policies, offering a robust shield to protect an organization’s assets against threats while adhering to specific access requirements.

The Role of Policy Configuration

Policy configuration plays an indispensable role in enforcing security within the SASE framework. The repercussions of badly configured policies can range from resource threats and data leaks to unintended, overly permissive access. In today’s industry landscape, organizations grapple with two predominant approaches to security policy management:

1. The Single Table Approach: A consolidated policy table containing a myriad of policies that span threat management and various access control scenarios across all SASE components.
2. The Multi-Table Approach: Multiple policy tables, each addressing specific aspects such as threat protection, access control, different applications, and user groups.

Striking a Balance in Policy Management

The expectation from SASE is clear: it should offer easily manageable security policies and simplified troubleshooting procedures. Achieving this necessitates a balanced approach. One effective strategy to mitigate policy complexity based on organizations requirements. Bigger organizations may require compartmentalization with multi-Table approach where policy table granularity is defined based on security functions, application resources, and subject (users/groups). Smaller organizations may prefer compartmentalization with a lesser number of policy tables combining multiple types of access controls or even combining threat protection with access control. This flexible approach minimizes the number of policies requiring simultaneous management, rendering them more manageable.

However, it’s important to exercise caution to avoid excessive compartmentalization, which can introduce its own set of challenges. Administrators may find themselves navigating through multiple policy tables to identify and address issues, potentially causing delays in resolution.

Understanding the Key Requirements

Before delving deeper into the intricacies of policy management, it’s crucial to understand the specific requirements that organizations must address within the SASE framework. Key areas include:

Need for Role-Based Security Configuration Management in SASE Environments

Secure Access Service Edge (SASE) components offer comprehensive security, encompassing threat protection and access control for a wide range of resources across diverse organizations, including their workforce, partners, and guests. Within this security framework, organizations often have distinct categories of administrators responsible for different aspects of security.

For example, an organization may have one group of administrators dedicated to managing threat protection while another group focuses on access controls. Within these broad categories, it’s common for organizations to establish various administrative roles tailored to specific types of threat protection and access control. Let’s delve into some practical examples:

Threat Protection Roles:

• Intrusion Detection and Firewall Configuration: Administrators with the “threat-protection-ngfw-role” are granted access to configure Intrusion Detection and firewall settings within the SASE environment.
• Reputation Controls: Administrators holding the “threat-protection-reputation-role” can manage settings related to IP reputation controls, URL-based reputation controls, domain-based reputation controls, file reputation controls, as well as cloud-service and cloud-organization reputation controls.
• Malware Protection: Administrators with the “threat-protection-malware-protection-role” have the authority to configure settings specifically pertaining to malware protection controls.

Access Control Roles:

• SWG Configuration: Administrators designated as “access-control-Internet-role” are responsible for managing Secure Web Gateway (SWG) configurations.
• SaaS Application-Specific Access Control: Roles like “access-control-saas1app-role” and “access-control-saasNapp-role” focus on configuring access control policies for specific applications (SaaS Service 1 and SaaS Service N), ensuring fine-grained control.
• Enterprise Application Management: Roles such as “access-control-hostedapp1-role” and “access-control-hostedappM-role” are dedicated to handling access control configurations for enterprise-level applications, app1 and appM.

In cases where an organization uses multi-tenant applications, additional roles may be introduced to manage security configurations effectively. For instance, roles can be established to configure policies for the organization’s workforce, per-tenant workforce, and even guests. Consider an application “X” with security configurations managed by different sets of administrators:

• Owner Workforce Security: Administrators with “access-control-hostedappX-role” and “access-control-owner-workforce-role” collaborate to manage access control configurations for application “X” for the owner’s workforce.
• Application Tenant-Specific Workforce for Tenant: Roles like “access-control-hostedAppX-role” and “access-control-owner-tenantA-workforce-role” enable administrators to configure access control settings for tenant A’s workforce.
• Application Tenant specific workforce for Tenant B: For a multi-tenant application “X,” various roles, such as “access-control-hostedAppX-role” and “access-control-owner-tenantB-workforce-role,” facilitate the management of access control configurations for tenant B’s workforce.

Additionally, even non-multi-tenant enterprise applications may require separate administrators for different workforce segments. For instance:

• Engineering Department: Administrators with “access-control-hostedappY-role” and “access-control-eng-role” focus on managing access control configurations for application “Y” within the engineering department.
• Sales & Marketing: Roles like “access-control-hostedappY-role” and “access-control-sales-role” are designated for configuring access control settings for sales and marketing teams.
• IT Department: Administrators with “access-control-hostedappY-role” and “access-control-it-role” have responsibilities for access control configurations pertaining to the IT department.

A significant advantage of role-based security configuration management is its ability to provide granular control tailored to specific responsibilities. Contrast this approach with the challenges that can arise when using a single, all-encompassing policy table:

• Error-Prone: Multiple administrators working with the same policy table and overlapping permissions may inadvertently introduce errors when adding, deleting, or modifying policies.
• Troubleshooting Complexity: Resolving issues within a monolithic policy table can be time-consuming and challenging.
• Policy Overload: Consolidating all policies into a single table, covering various applications and threat protection scenarios, can lead to a cumbersome and unwieldy policy management experience, as well as potential performance challenges during policy evaluation.

In conclusion, adopting role-based security configuration management within SASE environments empowers organizations to efficiently delegate responsibilities, enhance security, and streamline policy management while avoiding the complexities associated with single-table approaches.

Working alongside with Configuration Change Control Management

Organizations are increasingly embracing change control management for all configurations, including SASE configuration, to proactively detect and rectify configuration errors before they are implemented. This practice not only serves as a safeguard but also introduces a secondary layer of scrutiny, allowing a second set of eyes to review and approve configurations before they take effect.

Security policy configurations are applied directly within the traffic flow, making any errors in policies potentially disruptive to services and incurring direct financial consequences.

To cope with the inherent complexity of security policy configuration, it’s common practice to serialize changes. This means that when modifying one type of configuration, no other configuration sessions of the same type are initiated until the previous one is either applied or revoked. However, when using a single policy table that encompasses all threat and access control functions, serializing changes can introduce delays in configuration adjustments performed by other administrators.

In contrast, a multi-table approach can effectively address this scenario, allowing different administrators to concurrently work on distinct tables, thus streamlining the configuration change process.

Not all organizations share the same requirements:

SASE is typically offered as a service, and SASE providers may serve multiple organizations as customers. These organizations can vary significantly in terms of size, regulatory requirements, and the diversity of roles within their structures. Some organizations might host multiple applications, either On-Premises or in the cloud, while others may exclusively rely on services from SaaS providers, and some may incorporate a combination of both.

Furthermore, certain organizations may not have a need for various administrative roles or multiple administrative users. In scenarios where organizations have only a limited number of applications and lack the complexity of multiple administrative roles, they may find value in using fewer policy tables.

SASE is expected to be designed to offer the flexibility required to accommodate these diverse needs, including the option of using consolidated policy tables for multiple relevant security functions and applications.

Avoiding confusing configurations:

Certain SASE solutions, in their pursuit of simplification as discussed before, opt for a single, all-encompassing policy table where policies can be configured with values for various matching attributes. During traffic processing, policy selection is based on matching the values from the incoming traffic and other contextual information against the attribute values specified in the policies.

However, it’s crucial to recognize that during traffic processing, not all attributes of the traffic are readily known. For instance, in the case of stateful inspection firewalls, only a limited set of traffic values can be extracted, such as the 5-tuple information (source IP, destination IP, source port, destination port, and IP protocol). Meanwhile, for proxy-based security components like SWG, ZTNA, and CASB, the extraction of attribute values can vary and may involve distinct stages, notably the Pre-TLS inspection and Post-TLS inspection phases.

Before TLS inspection/decryption, many HTTP attributes remain unknown. It’s only after TLS decryption that additional attributes, such as access URI path, HTTP method, and request headers, become available for evaluation.

As administrators responsible for configuring security policies, it is impractical to expect administrators to keep track of which attributes are valid at various stages of packet processing while defining policies. While some security solutions claim that irrelevant attributes are not considered in policy evaluation, determining which attributes are pertinent and which are not can be challenging when inspecting complex policies.

We firmly believe that amalgamating policy tables across multiple stages into a single table creates complexity and confusion for administrators. Such an approach can be challenging to comprehend and lead to potentially perplexing configurations. To ensure clarity, it is advisable to create policies within a given table that include only relevant attributes for consistent and straightforward evaluations.

Optimizing Deny and Allow Policy Tables:

Certain security solutions adopt a structure where they maintain separate “Deny” and “Allow” policy tables. Within this setup, policies defined in the “Deny” list take precedence and are evaluated first. If no matching policy is found in the “Deny” table, the evaluation proceeds to the “Allow” policy table. However, this division of policies into two distinct tables can pose challenges for administrators.

We firmly advocate for a more streamlined approach, where any given policy table is presented as an ordered list of policies. In this arrangement, each policy explicitly specifies its action—whether it’s “Deny,” “Allow,” or any other desired action. During traffic processing, policy evaluation follows a logical progression from the highest priority policy to the lowest priority policy until a match is found. Once a matching policy is identified, the corresponding action is applied to the traffic. In cases where no matching policy is encountered, a default action, such as “fail open” or “fail close,” is triggered as defined by the organization’s security policy.

This approach simplifies policy management and enhances clarity for administrators by consolidating policies within a single and ordered list irrespective of the policy action values, thereby minimizing complexity and streamlining the policy evaluation process. Not separating policy tables based on action values also enabled SASE solution providers to introduce new action values in future relatively easily.

Creating Flexible and Expressive Policies:

As you’ve gathered, administrators craft policies by defining sets of values for matching attributes. Traditionally, there has been a common understanding of how policy matching operates during traffic evaluations: a policy is considered a match only when all the attribute values specified in the policy align perfectly with the values of the incoming traffic session. These values can either be extracted directly from the traffic or inferred from contextual information, such as the authenticated user context and the device context responsible for initiating the traffic. Essentially, this matching process involves an ‘AND’ operation across all attributes of the policy.

However, as security technologies have evolved, many security devices have introduced a more flexible approach, granting administrators the ability to assign multiple values to attributes. In this evolved paradigm, a match is established if the runtime context information aligns with any of the values specified for the policy attributes. In essence, the matching process now combines an ‘AND’ operation across attributes with an ‘OR’ operation across the values associated with those attributes.

Organizations stand to benefit significantly from this flexibility when creating comprehensive policies. It reduces the overall number of policies required while maintaining readability. However, these multi-value attributes are just one step in the right direction, and further enhancements are often necessary to meet organizations’ unique requirements:

Support for “NOT” Decoration: Administrators require the ability to define policy attribute values with a “NOT” decoration. For instance, it should be possible to specify a ‘source IP’ attribute value as ‘NOT 10.1.5.0/24,” indicating that the policy will match successfully when the traffic session’s source IP does not belong to the 10.1.5.0/24 subnet.

Support for Multiple Instances of an Attribute: Many traditional security devices support only one instance of a given attribute within a policy. To create comprehensive policies, the ability to include multiple instances of the same attribute within a single policy is essential. For example, an administrator may want to allow sessions from any IP address in the 10.0.0.0/8 subnet while simultaneously denying traffic sessions from the 10.1.5.0/24 subnet. This should be achievable within a single policy, perhaps by specifying ‘source IP’ values twice: “source IP == 10.0.0.0/8” and “source IP == NOT 10.1.5.0/24.” This prevents the need to create two separate policies and allows for more intuitive policy management.

Support for Decorations for String Type Values: Attributes that accept string values, such as URI paths, domain names, and many HTTP request headers, benefit from decorations like ‘exact,’ ‘starts_with,’ and ‘ends_with.’ These decorations enhance the creation of expressive policies.

Support for Regular Expression Patterns: In some cases, policies require pattern matching within traffic values. For instance, a policy may dictate that a traffic session is allowed only if a specific pattern is present anywhere in the ‘user agent’ request header value. Support for regular expression patterns is essential in such scenarios.

Support for Dynamic Attributes: While traditional attributes in policies are fixed and predefined, SASE environments sometimes require dynamic attributes. Consider request and response headers or JWT claims, where standards coexist with numerous custom headers and claims. SASE should empower administrators to create policies that accommodate custom headers and claims. For example, SASE should allow the creation of policies with the request header ‘X-custom-header’ as an attribute and the value ‘matchme.’ At traffic time, any HTTP sessions with ‘X-custom-header’ as one of the request headers and ‘matchme’ as the value should match the policy.

Support for Objects: This feature allows the creation of various types of objects with values that can be used as attribute values in policies, rather than specifying immediate values. Objects can be referenced across multiple policies, and any future value changes can be made at the object level, simplifying policy modifications, and ensuring consistency.

These enhancements contribute to the creation of flexible, expressive, and efficient security policies, empowering organizations to tailor their policies to unique security needs and scenarios effectively.

Enhancing Policy Integration with traffic modifications

Certain security functions necessitate modifications to traffic, with the most common use cases involving the addition, deletion, or modification of HTTP request/response headers and their values, query parameters and their values, and even the request/response body. These modifications can vary significantly based on administrators’ configurations. Often, the specific modifications depend on traffic values, such as the destination application/site service, as well as contextual information available during traffic runtime.

Rather than maintaining a separate policy table for traffic modifications, it is often more efficient to include these modification objects within the access policies themselves. This approach streamlines policy management and ensures that modifications are directly aligned with the policies governing traffic behavior.

One prominent scenario where traffic modification is essential is in the context of Cloud Access Security Broker (CASB) solutions, particularly when organizations require multi-tenancy restrictions. These restrictions often involve the addition of specific request headers and values to enforce collaboration-specific policies. Additionally, there are other instances, such as the addition of custom headers for end-to-end troubleshooting and performance analysis, where traffic modifications play a crucial role.

Consequently, organizations expect SASE solutions to support policies that seamlessly integrate with modification objects. During traffic processing, traffic modifications are executed when the matched policy is associated with the appropriate modification objects, providing a unified and efficient approach to traffic management and policy enforcement.

Enhancing Observability:

It is common practice to log every traffic session at the conclusion of the session for the purpose of observability. In cases involving substantial or “elephant” sessions, it is also customary to periodically log access information. These session logs typically contain valuable data, including traffic metadata, actions taken during the session, and details regarding the packets and bytes transferred between the client and server.

One significant advancement offered by SASE is the consolidation of security functions and the adoption of single-pass, run-time-completion architectures, resulting in a unified session log. This contrasts with non-SASE security deployments where each individual security component generates its own session log, often containing information about the policy that was matched and critical attribute values used in the matching process. Importantly, while SASE generates a single log, there is an expectation that it should not compromise on the inclusion of critical information.

When a traffic session is allowed due to multiple policy evaluations across various security functions and policy tables, the resulting log should encompass information about every policy that was matched. Moreover, if a policy matches due to the values of specific traffic or context attributes, the log should provide precise details about the attribute values that led to the policy match.

Given that organizations rely on comprehensive logs for effective observability, SASE solutions are expected to furnish thorough information in the logs, ensuring that administrators have access to the data they need to monitor and analyze network traffic effectively.

SASE Approach to Policy Management:

It’s important to recognize that not all SASE solutions are identical. Organizations should carefully assess whether a particular SASE solution aligns with their specific organizational requirements without sacrificing usability. While organizations may not initially possess all the requirements listed above, it’s only a matter of time before these requirements become increasingly relevant and essential to their operations.

Organizations having all the aforementioned requirements gain the advantage of complete flexibility in tailoring their SASE policies to their specific needs. On the other hand, organizations that do not currently have all these requirements often seek a simpler user experience while keeping an eye on introducing additional functionality as their requirements evolve. This approach allows organizations to strike a balance between their current needs and future growth, ensuring that their SASE solution remains adaptable and responsive to changing circumstances.

Unless SASE solutions provide full flexibility, customization becomes challenging. Therefore, we believe SASE solutions should provide the following core capabilities:

1. Modular Policy Management: SASE solutions encompass multiple security functions, each with its own set of policy configurations. These configurations should include options to enable/disable, set default action in case of no policy match, manage collection of multiple policy tables, define multiple policies within each policy table, establish an ordered list of policies, and set action settings, modification objects, matching attributes, and values for each policy.
2. Policy Chaining: To enable more specific and granular policies, SASE solutions should support policy chaining. This means allowing the arrangement of policies across multiple policy tables in a collection. For example, organizations can have separate policy tables for different applications, with the main table policies using application/domain names as matching criteria to select the appropriate policy tables. This is typically accomplished through the use of policies featuring an action called ‘Jump,’ which redirects policy evaluation to the referenced policy table. The concept of policy chaining gained popularity with Linux IPTables, and many security solutions subsequently incorporated this functionality.

The comprehensiveness of security functions within SASE can be extensive and may include:

• NGFW (Next-Generation Firewall): Providing L3/L4 access control, DDoS protection, IP reputation, domain reputation and, Intrusion Detection and Prevention System (IDPS)
• SWG (Secure Web Gateway): Offering TLS inspection, pre-TLS web access control, post-TLS web access control, URL reputation, file reputation, and malware protection.
• ZTNA (Zero Trust Network Access): Similar to SWG but focused on securing hosted applications.
• CASB (Cloud Access Security Broker): Covering cloud service reputation and cloud service access control.
• DLP (Data Loss Prevention): Implementing access control based on Personally Identifiable Information (PII), standard confidential documents, and enterprise-specific sensitive documents.

The flexibility of policy management for each security function, along with the ability to manage policies within each function via multiple policy tables with policy chaining, is a powerful feature. Geo-distributed organizations with various regulatory requirements can particularly benefit from this flexibility.

However, smaller organizations may prefer some sort of consolidation of policy tables. In such cases, it should be possible to customize the configuration by:

• Consolidating all pre-TLS security function configurations into a single collection of policy tables across multiple SWG/ZTNA components.
• Consolidating all post-TLS security function configurations into another single collection of policy tables across multiple SWG/ZTNA components.
• Retaining CASB, malware, and DLP functions as separate entities as these require complex policy definitions.
• Opting for a single policy table within the policy table collection, thus avoiding policy chaining.

Therefore, organizations should seek SASE services that provide full flexibility while also offering custom controls to consolidate configurations for relevant security functions. This approach ensures that SASE policies are tailored to an organization’s specific needs while maintaining ease of management and scalability as requirements evolve.

Balancing User Experience with Future-Proof Flexibility

Security policy management has historically been a complex endeavor. Many products specialize in policy management for specific security appliances, resulting in a fragmented landscape. SASE addresses this complexity by consolidating multiple security appliances into a unified solution. While this consolidation offers advantages, it also introduces complexities of its own.

Traditional approaches to policy management, such as a single policy table, may seem appealing initially. However, they present numerous challenges and often fall short of meeting the requirements outlined in this article. Conversely, having an excessive number of policy engines can also lead to complexity. Striking the right balance between flexibility and simplicity is paramount.

One significant challenge in the industry is the proliferation of policies. An excessive number of policies not only degrades the user and troubleshooting experience but also carries performance implications. The multi-table approach and policy expressiveness, as described earlier, are essential strategies for reducing the volume of policies within policy tables.

SASE solutions are increasingly addressing these complexities by providing greater sophistication in policy management. It is our belief that SASE solutions will continue to evolve, implementing many of the requirements detailed in this article in the very near future. This evolution will empower organizations to strike the optimal balance between user experience, flexibility, and performance, ensuring that their security policies remain effective and adaptable in a rapidly changing threat landscape.

• CTO Insights blog

  The Aryaka CTO Insights blog series provides thought leadership for network, security, and SASE topics. For Aryaka product specifications refer to Aryaka Datasheets.