Thwart Security Risks with Comprehensive IDPS in Unified SASE

Within the realm of Secure Access Service Edge (SASE), the integration of Intrusion Detection and Prevention Systems (IDPS) is almost universal. Its role extends beyond merely thwarting known exploits, it serves as a vigilant sentinel for IOC (Indicators of Compromise, affording a comprehensive layer of protection. I would even argue that the IDPS is being used for Indicators of Compromise and Indicators of Attack more in the recent past by organizations.

The power of IDPS lies in its ability to furnish rich insights into network traffic; it not only extracts connection metadata such as 5-tuples of the connection but also delves into the nuanced details of various protocol fields. This depth of extraction yields invaluable information about the characteristics of data traversing the network, enhancing contextual awareness.

IDPS uses multiple methods to fortify network security. It proficiently detects and obstructs known exploits and malware through signature-based detection methods. Furthermore, it stands guard against anomalous data by employing rules that can identify irregular packet or stream patterns. These rules extend their purview to encompass abnormal protocol attribute sizes and unanticipated protocol value behavior.

While features and security effectiveness of IDPS within the SASE framework may exhibit slight variations among service providers, the core capabilities remain largely similar, owing to the utilization of signature databases typically sourced from third-party threat intelligence vendors. Additionally, IDPS technologies have matured and developed similar capabilities even in the face of multiple evasion techniques employed by attackers. In my assessment, the primary differentiation among providers lies in the realm of observability and the facilities they offer for threat hunting, with a focus on minimizing false positives and false negatives.

The intent of this article is not to delve into the IDPS feature differentiation among SASE services. Rather, it seeks to explore the precise points within the packet path where IDPS functions are executed by SASE services and whether these insertion points effectively detect attack patterns within the original traffic.

There is a perspective held by some that incorporating Intrusion Detection and Prevention System (IDPS) functionality at the proxy level within Secure Access Service Edge (SASE) services is sufficient. Their rationale stems from the fact that many organizations already employ OnPrem IDPS for intrusion detection on generic traffic. The primary challenge with OnPrem IDPS lies in its inability to inspect traffic that is TLS-encrypted. Given that SASE proxies conduct Man-in-the-Middle (MITM) TLS inspection, they gain access to unencrypted traffic. Therefore, the belief is that having the IDPS insertion point at the proxies is adequate.

Moreover, some argue that a significant number of systems are adequately patched against network-level (L3/L4) and TLS-level attacks. In response, attackers have shifted their focus towards employing more sophisticated tactics at the application (L7) and data levels. Consequently, there is a prevailing notion that not extending IDPS functionality beyond the proxy level within the network is justifiable. However, this argument does not hold in all cases. Consider IoT devices that continue to operate on older, infrequently updated operating systems. These devices may remain vulnerable to a broader range of attacks, necessitating a comprehensive security approach.

Many also acknowledge that SASE services are expected to incorporate IDPS at both the proxy and L3 levels to ensure the thorough inspection of all network traffic. To achieve comprehensive attack detection, IDPS functionality should be applied not only at the proxy level, as discussed earlier, but also at the WAN interfaces level, where traffic enters and exits interfaces designated for traffic to and from the Internet. While this approach represents an improvement over deploying IDPS solely at the proxy level, it does introduce a challenge. In cases where traffic flows through the proxies, IDPS may not have visibility into the original traffic in both directions of the sessions. Proxies typically terminate connections and establish new ones. As they rely on the local TCP/IP stack, they reassemble original packets, re-sequence TCP data, recreate IP/TCP options, and regenerate TLS handshake messages. Consequently, IDPS at the WAN interface level may lack visibility into the original traffic originating from the internal network, potentially causing it to overlook attack patterns that were part of the original traffic.

It’s worth noting that attackers may not always be external; there could be internal attackers as well. Additionally, attacks may originate from internal systems due to previous malware infections. Therefore, it is crucial to ensure that the IDPS consistently observes the original traffic in both directions for effective threat detection and prevention.

Seek SASE Services with Multiple IDPS Insertion Points

We advocate for SASE services to offer the flexibility of inserting IDPS at multiple points, all concurrently active. Organizations should have the freedom to choose whether to deploy IDPS at each L3 interface and at the proxy level. This approach empowers IDPS to inspect the original traffic from both client and server endpoints of the sessions, even when the traffic is TLS-encrypted and going through the proxies.

Furthermore, organizations should actively search for SASE services that avoid generating duplicate alerts and logs resulting from multiple insertion points. For instance, traffic that doesn’t pass through any proxies but traverses multiple L3 interfaces (received on one interface and sent through another) may be seen by two IDPS instances, potentially leading to duplicate alerts and logs. It is advisable for organizations to ensure that such redundancy in logs is minimized, preventing the inundation of administrative personnel who are already grappling with a high volume of logs generated by security functions. Ideally, SASE services should exhibit intelligence on a per-traffic session basis and intelligently avoid duplicate IDPS function execution if no traffic modifications occur within the SASE service.

Additionally, organizations should seek solutions that enable the correlation of logs generated by multiple security functions, including various IDPS instances, for a given traffic session. This correlation aids in enhancing observability and streamlines the work of threat hunters by simplifying the mapping of security events.

Recognizing the computationally intensive nature of IDPS, organizations should also strive to conserve resources wherever possible. For instance, if organizations already employ Host IDS (HIDS) or On-Prem IDPS, they may wish to retain control over the deactivation of IDPS on specific instances for certain types of traffic. SASE services that offer policy-based IDPS steering can empower organizations to dictate which traffic should undergo inspection by different IDPS instances within the SASE framework.

In summary, the effectiveness of IDPS within the SASE paradigm extends beyond its features; it hinges on the flexibility that SASE provides regarding IDPS insertion points and the degree of control it affords organizations to align with their specific requirements.

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