Unlocking the Potential: The Crucial Role of Reputation in a SASE Architecture

The Secure Web Gateway (SWG) plays a crucial role in the SASE/SSE solution, which aims to secure internet-bound connections. Its primary objective is to safeguard users from online threats and enforce acceptable access policies within an organization. The SWG achieves this by intercepting user traffic and employing various security engines, including access policy enforcement. Only traffic that meets organizational access policies and is considered clean is allowed to pass through.

With 95% of internet traffic now encrypted, achieving comprehensive security in SASE/SSE solutions necessitates the ability to decrypt this traffic. While most of the traffic can be decrypted using MITM (Man-In-The-Middle) TLS decryption, concerns around user privacy have emerged, particularly when users visit websites that handle personally identifiable information (PII) or banking sites. Furthermore, certain application software vendors have begun adopting certificate pinning techniques to prevent MITM TLS decryption altogether.

These developments raise questions about the security that can be applied at the SASE level while still providing value to enterprises. This is where reputation security engines are gaining momentum.

This article highlights the value of SWG for internet-bound connections by describing security engines that can be universally applied, with or without TLS decryption. It also explores security engines that operate on decrypted TLS traffic, enabling comprehensive security measures.

Generic features common to all components of SASE

As SASE Security’s access control is centered around identity, authentication and authorization are fundamental functions required across all SASE components. The articles on Identity-aware SASE and Identity broker provide insights into different authentication methods and interfaces with multiple authentication services..

In addition, the proxies-in-SASE article delves into the techniques used to capture traffic flowing from users to the Internet, users to SaaS services, and users to enterprise applications. However, this article focuses primarily on the security engines of the SWG component. Note that this article also does not delve into other common features shared by all SASE components, such as centralized configuration management and observability capabilities.

Security Engines and Generic Policy evaluation

In the SASE framework, all security engines operate based on administered policies, which provide the rules and actions to govern the behavior of the system. Each security engine can consist of multiple policy tables, and each table can contain multiple policies.

A policy is comprised of an action and a set of rules. ‘Action’ determines how the system should handle the traffic session.

Rules within a policy define the conditions that must be satisfied for the policy to be considered a match. Rules consist of matching attributes and their corresponding values. If the traffic session aligns with the specified attribute values, the rule is considered a match.

Various matching attributes can be used within rules to enforce security policies effectively. Examples of these attributes include schedule (date/time range), source IP, destination IP, Protocol/Destination Port, Source Port, user claims attributes such as user email address, user group, user role, issuer, and others as specified in the JWT claims registry. Additionally, attributes such as domain name, URL, request headers and values, HTTP method, device posture, UEBA score, location of the user, domain category, domain reputation score, URL category, URL reputation score, IP security category, IP reputation score, and file reputation score can also be utilized. It’s important to note that all security engines may not support all matching attributes in their policies.

SASE evaluates traffic sessions by passing them through multiple security engines. Each security engine independently decides whether to allow the traffic session based on its configured policies. If all security engines permit the traffic session to continue, SASE allows the traffic to pass through.

The order in which SASE executes the security engines is typically predefined. However, certain SASE implementations may offer the flexibility to select the order in which the security engines are executed. This allows administrators to prioritize specific security engines or tailor the processing sequence based on their requirements.

Inline Threat Intelligence Gathering

The SWG (Secure Web Gateway) component plays a crucial role in gathering inline threat intelligence. It relies on data feeds from reputable providers to acquire valuable information about different aspects, including:

• Reputation of IP addresses, domains, URLs, files, and SaaS services: The SWG leverages threat/data intelligence feeds to assess the reputation of these entities. This information helps in identifying potentially malicious or suspicious sources, allowing the system to make informed decisions.
• Categorization of domains, URLs, and SaaS services: By utilizing the intelligence feeds, the SWG can determine the categories to which domains, URLs, and SaaS services belong. This categorization aids in policy enforcement and enables organizations to define granular security controls based on specific categories.
• Malware classification of content: The SWG employs the gathered threat intelligence to classify potential malware based on content analysis. By examining the characteristics of the content, the system can identify and block or quarantine malicious files or websites, preventing them from causing harm.
• Data classification of content: The SWG also utilizes data classification intelligence feeds to classify the content of web traffic. This classification helps identify sensitive or confidential information that may be transmitted or accessed, enabling organizations to enforce data protection policies effectively.

As all internet-bound and SaaS traffic passes through the SWG, it has the ability to collect various attributes of the traffic. By leveraging threat/data intelligence feeds, the SWG can enrich these attributes with valuable threat information. This information not only facilitates policy enforcement across different security engines but also provides visibility into the threats present in the traffic flowing through the SWG. This enhanced visibility enables organizations to detect and mitigate potential security risks in real-time, ensuring a robust security posture.

Security Engines before SSL inspection

These security engines process traffic sessions before they are TLS/SSL decrypted. These security engines act on all the Internet bound HTTP traffic. These security engines stop the traffic session if they identify any potential risk.

• IP Reputation-based Threat Protection Security Engine: The administrators of the SWG are empowered with the capability to create policies based on specific IP categories, IP reputation scores, and other generic attributes, enabling them to establish tailored security measures. This engine offers robust protection to users who access websites known for hosting malware and phishing content. Leveraging comprehensive threat intelligence collected on destination IP addresses, the engine efficiently identifies and mitigates potential risks, safeguarding users from malicious activities. By assessing the reputation of each IP address, the security engine makes well-informed decisions on the appropriate actions to be taken in alignment with the matching policy, ensuring a proactive and dynamic security posture.
• Domain Reputation-based Threat Protection Security Engine: The administrators of SWG possess the capability to create policies based on domain categories, domain reputation scores, and other generic attributes, allowing them to define desired security measures effectively. This engine provides comprehensive protection to users accessing websites flagged for hosting malware and phishing content. Leveraging domain threat intelligence gathered from various sources, including HTTP CONNECT host header, TLS SNI for TLS-based HTTP traffic, and host header of clear HTTP traffic, the engine evaluates policies to accurately identify and mitigate potential risks. By incorporating domain reputation data, the security engine ensures proactive defense measures, strengthening overall security posture and safeguarding users from potential threats.

The reputation-based security engines prioritize both accuracy and adaptability. These security engines offer comprehensive policy-level flexibility to empower SWG administrators with the ability to create exceptions. These exceptions are crucial for various reasons, such as addressing false positives generated by threat intelligence feeds and accommodating the deliberate need to allow traffic for local threat hunters to conduct further inspections.

When it comes to the domain reputation security engine, an important question arises regarding which domain name to utilize for gathering intelligence and enforcing reputation policies. This question arises because the domain name is present in multiple layers of the traffic. In the case of traffic flowing through forward proxy method of the SWG, the SWG can extract the domain name from the host header of the HTTP CONNECT request and from the TLS Server Name Indication (SNI) field. Although both the host header and TLS SNI values typically align, there are instances where they can differ. As a result, SWGs inherently perform two passes through this security engine by default. The first pass occurs when the SWG receives the HTTP CONNECT request, while the second pass occurs when the SWG receives the TLS traffic. This approach ensures that the SWG can accurately evaluate the domain reputation and enforce the corresponding policies.

However, SWGs are designed to be intelligent and efficient. If the domain names extracted from the HTTP CONNECT request and the TLS SNI field are identical, the SWG recognizes this redundancy and avoids the need for a second run of the reputation engine. This optimization helps streamline the security evaluation process and reduces unnecessary computational overhead, enabling the SWG to maintain high-performance levels while ensuring comprehensive domain reputation-based threat protection.

Access Control Engine

In addition to reputation-based threat protection, SWGs offer robust access control capabilities, allowing administrators to provide differentiated access to users when accessing various Internet sites. This powerful security engine enables administrators to create policies based on domain categories, which are provided by reputable threat intelligence providers.

By leveraging domain categories, SWG administrators can simplify their management experience by classifying a vast number of Internet sites into a few overarching categories. This classification system enhances efficiency and ease of policy creation, ensuring that administrators can effectively define access control measures without the need for granular configuration for each individual site.

Moreover, the access control engine also provides the flexibility to specify individual domain names within the policies. This allows administrators to have fine-grained control over access to specific sites, accommodating situations where specific sites require unique access permissions or restrictions.

The flexibility of the access control engine proves particularly useful in scenarios where false positives occur in the domain categorization process. In such cases, administrators can create exceptions within the policies to override the categorization and ensure accurate access control for affected sites. This ability to handle exceptions empowers administrators to maintain a balance between stringent security measures and providing necessary access for legitimate sites that might be misclassified.

SASE TLS/SSL Inspection Engine

The SWG TLS/SSL inspection engine plays a crucial role in enabling advanced access controls and threat protection that require access to the content of TLS/SSL sessions. However, TLS inspection necessitates decrypting these sessions, which requires access to the private keys. As a Man-In-The-Middle (MITM) entity, the SWG does not have direct access to the private keys. To overcome this limitation, TLS inspection engines typically employ a technique where they mimic the server certificate using the Enterprise trusted Certificate Authority (CA).

The typical flow of steps followed by the TLS inspection engine for each new TLS session from the client is as follows:

• Establish a TLS connection to the destination service (Internet site).
• Retrieve the certificate presented by the destination service.
• Mimic the content of the certificate, including its lifetime, to create a mimic certificate.
• Sign the mimic certificate using the Enterprise trusted CA.
• Present this mimic certificate during the TLS handshake with the client.

For this process to work seamlessly without causing security pop-ups in browsers, it is essential that the Enterprise CA certificate chain is securely onboarded in employees’ machines as a trusted CA, typically through their system management software.

To minimize computational overhead associated with key generation and signing of mimic certificates, the TLS inspection engine caches the mimic certificates and corresponding private keys, reusing them until their lifetime expires.

While TLS inspection is highly desirable for advanced threat protection and access control, enterprises may have specific cases where decryption is not allowed. These cases include privacy concerns, especially when accessing banking, financial, or healthcare sites, as well as scenarios where certificate pinning is employed. Additionally, enterprises may choose not to enable TLS inspection for content that is already checked for threats before TLS encryption occurs at the client-side, such as through browser or Office 365 extensions.

To provide flexibility in deciding whether to perform TLS decryption or not, the SWG TLS/SSL inspection engine empowers administrators to create policies. These policies can include domain category classifications, allowing administrators to bypass TLS decryption for specific categories such as financial and healthcare sites, as well as any other sites for which the enterprise is uncomfortable with decryption.

By offering policy-based control and categorization, the SWG TLS/SSL inspection engine enables enterprises to strike a balance between maintaining privacy and security while ensuring robust threat protection and advanced access controls.

SWG PKI infrastructure

SASE services are inherently multi-tenant, supporting multiple enterprises. Within this context, some enterprises may have their own Public Key Infrastructure (PKI) infrastructure, while others may not have any PKI infrastructure in place. It is important to note that the enterprise CA certificate (used to sign the mimic certificates) should have a relatively short lifetime, typically a few days, to ensure robust security. Regular reissuance of the CA certificate is necessary to maintain a secure environment.

To ensure the security of the private key of the CA certificate within the SWG context, Certificate Signing Request (CSR) based certificate generation is preferred. Many SWGs provide their own PKI infrastructure to issue intermediate CA certificates (SWG CA Certificates) to their SWG data plane instances. In cases where an enterprise does not have its own PKI infrastructure, the SWG’s PKI infrastructure automatically creates the parent CA and root CA certificates on behalf of individual Enterprise.

In situations where an enterprise does have its own PKI infrastructure, the SWG’s PKI infrastructure establishes communication with the enterprise’s PKI infrastructure to obtain the parent CA certificate signed. Once the parent CA certificate is obtained, it is used to sign the SWG CA certificates, ensuring the authenticity and integrity of the certificates used for signing mimic certificates.

The PKI infrastructure is considered a critical component of the SWG as it plays a vital role in securing the private keys used for signing the mimic certificates. By effectively managing the PKI infrastructure, including the regular reissuance of CA certificates, and adhering to established security practices, SWGs can ensure the integrity and trustworthiness of the certificates used within the multi-tenant SASE service environment.

Security Engines after SSL inspection

After TLS/SSL decryption, the SWG utilizes a set of security engines to process the traffic sessions and identify any potential risks. These security engines play a crucial role in ensuring comprehensive threat protection

URL Reputation-based Threat Protection Security Engine

SWG administrators are equipped with the capability to create policies based on URL categories, URL reputation scores, and other relevant attributes, enabling them to effectively define security measures. While the domain reputation-based threat protection engine provides protection at the domain level, there are instances where it becomes necessary to perform reputation-based threat protection at the URL level. This is particularly important for websites that have sub-sections or different URLs representing specific sections of the site. While the overall domain reputation might be good, certain individual sections within the site could be compromised or pose a risk. Therefore, the URL-based reputation security engine is essential for comprehensive protection, preventing users from accessing malware-hosted or phishing websites. By considering the reputation of specific URLs, this engine enhances the accuracy of threat detection and enables proactive blocking of potentially harmful content.

As mentioned earlier in the “SWG Pre Decryption Security Engines” section, reputation scores derived from threat intelligence feeds can sometimes result in false positives. Additionally, there are cases where administrators may want to allow a traffic session to proceed for a more in-depth inspection by threat hunters. Furthermore, if comprehensive protection has already been applied at the client level, duplicating the threat protection at the gateway level may be unnecessary. To address these scenarios, the post-decryption reputation threat protection engines are also policy-driven, enabling administrators to create exception policies.

Advanced Access Control Engine

In addition to reputation-based threat protection, SWGs provide robust advanced access control capabilities, enabling administrators to enforce differentiated access to users when accessing various Internet sites. This advanced access control engine shares similarities with the previously described “Access Control Engine” in the “SWG Pre Decryption Security Engines” section. However, as it operates after TLS decryption, it offers even more sophisticated access control options based on URLs, HTTP methods, and HTTP request headers.

The advanced access control engine leverages URL categories, which provide a more accurate and granular classification of websites compared to domain categories. By utilizing URL categories, administrators can effectively define policies to regulate access based on specific URLs, allowing for fine-grained access control.

Similar to the Access Control Engine, the advanced access control engine also provides the flexibility to create exceptions, addressing scenarios where false positives occur in URL categorization. These exceptions enable administrators to override default access control policies for specific sites or content that might be misclassified or require special access permissions.

Security Engines with content inspection

Up until now, the security engines described have been focused on stopping traffic sessions when threats are detected, or access is denied. These engines operate based on initial HTTP information and request headers, allowing for the suspension of traffic until the traffic is inspected.

However, there are additional security engines that require deeper inspection of the content within HTTP sessions. These engines need access to the content in both requests and responses to effectively detect threats. Unlike the previous engines, these content inspection engines do not stop the entire traffic flow but instead halt the specific traffic the moment a threat is detected.

Some of these security engines not only require access to the entire content, but they may also need to perform further processing on the content before utilizing threat intelligence feeds to identify potential threats. For example, if a file is compressed, it needs to be uncompressed for analysis. Additionally, certain threat intelligence providers expect the extraction of text streams from different file types such as Word documents, PowerPoint presentations, OpenOffice files, Excel spreadsheets, PDFs, and more. Since these extractions and threat detections can be computationally intensive, they may introduce latency to the HTTP transactions.

To address this, many of these security engines offer two options: inline capture with threat detection and inline enforcement, or inline capture with offline threat detection. In the inline detection mode, the traffic is captured, and threat detection occurs within the HTTP session, allowing for immediate enforcement actions. In the offline detection mode, the traffic is still captured, but the text stream extraction and threat detection with threat intelligence feeds are performed outside of the HTTP session. In this mode, offending traffic is not immediately stopped, but visibility into potential threats is maintained. These two modes provide flexibility for enterprises to balance inline threat protection and user experience, allowing them to choose the approach that best suits their needs.

File Reputation-based Threat Protection Security Engine

The SWG incorporates a File Reputation-based Threat Protection Security Engine that plays a vital role in assessing the reputation of files transferred over HTTP. This engine leverages the SWG’s threat intelligence gathering functionality, which continuously analyzes the content passing through the gateway. As the traffic flows, the threat intelligence engine calculates the hash of the content, both as it is being transferred and at the end of the file, in order to determine the file’s reputation score. If necessary, the SWG performs decompression on the content before calculating the hash. Administrators are empowered with the flexibility to create policies that consider the file reputation score and dictate whether to allow or deny the traffic session based on this assessment. This security engine performs the policy evaluation and stops further transfer of the traffic once the threat is detected.

Anti Malware Security Engine

The Anti-Malware Security Engine integrated into SWGs incorporates advanced threat intelligence and anti-malware functions to effectively detect and prevent viruses and malware from infiltrating the traffic stream and reaching user devices. This engine also plays a crucial role in preventing users from unknowingly spreading malware by actively monitoring traffic in both directions. As mentioned earlier, these security engines employ various techniques to analyze the content within local files. If necessary, the engine will uncompress files and extract the text stream, which is then subjected to thorough examination using threat intelligence anti-malware functions. The text stream is particularly important for signature-based analysis, enabling the detection of known malware strains.

SWG solutions offer flexibility to administrators, allowing them to create policies that dictate the appropriate actions to be taken upon detecting different types of malware and considering the confidence level provided by the threat intelligence provider. This ensures that responses to malware are tailored to the specific threat and risk level. Furthermore, SWGs provide the capability to create exceptions within the policies to address performance concerns, false positives, and to facilitate deeper threat inspections by threat hunters. This flexibility empowers administrators to fine-tune the security measures and strike the right balance between protection and operational efficiency.

Intrusion Detection & Prevention (IDP) Security Engine

The IDP security engine is an integral part of SWGs, designed to identify potential exploits within traffic streams. Exploiting system vulnerabilities is a common method attackers employ to gain unauthorized access, introduce rootkits, and distribute malware. These vulnerabilities can take the form of buffer/stack overflows, inadequate input validation, or misconfigurations in systems and applications. The IDPS within SWGs can detect exploit attacks targeting client machines and identify compromised clients attempting to exploit third-party services on the Internet, preventing enterprise assets from becoming launching pads for further attacks.

The IDP engine within SWGs delivers accurate detection with fewer false positives for several reasons:

• Access to Clear Data: The IDP engine can access traffic data that has been cleared of encryption, enabling it to effectively analyze and detect potential attacks.
• Access to Reassembled and Re-sequenced Data: The engine can access data streams that have been reconstructed and reordered, ensuring comprehensive analysis and detection of any malicious activities.
• Access to HTTP Protocol Extracted and Decoded Data: By having extracted and decoded data from proxy part of SWGs, the IDP engine gains deeper visibility into the content, allowing for more effective detection of attack patterns.

The IDP engine employs various types of signatures to detect attacks, including protocol anomaly signatures, traffic anomaly signatures, and content-based signatures. Threat intelligence providers offer extensive signature databases, but loading every signature can significantly impact system performance. To address this concern, SWGs provide signature tuning capabilities based on factors such as signature applicability. For example, signatures that are not relevant to HTTP-based traffic or those that inspect non-decrypted content within HTTP can be avoided. Tuning can also consider factors like risk impact, confidence levels of signatures provided by threat intelligence providers.

SWG solutions also offer policy-based traffic selection, enabling administrators to determine which traffic should undergo IDP processing. This flexibility allows for the avoidance of redundant IDP scans on traffic that has already been scanned for attacks at the client endpoint level.

Data Loss Prevention Security Engine

The inclusion of Data Loss Prevention (DLP) Security Engine within SWGs has become increasingly prevalent. This powerful engine is designed to prevent users from inadvertently transmitting or receiving confidential financial, accounting, or business-sensitive information without proper authorization. By leveraging policy-based controls and user attributes, the DLP Security Engine monitors and mitigates the risk of accidental or intentional data leaks.

To effectively perform its role, the DLP Security Engine requires access to the complete content of data transmissions. It extracts text streams, allowing it to analyze and classify the data based on its sensitivity. Data classification intelligence providers utilize the text stream to generate classification results, which encompass various attributes such as compliance labels (e.g., Personally Identifiable Information or PII), generic confidential document data (e.g., financial information), and custom-defined sensitive data.

To facilitate precise control over sensitive data, SWGs offer administrators the ability to create policies that incorporate different classification attributes and values. These policies, combined with generic matching attributes, enable administrators to define granular access controls and specify how different types of sensitive data should be handled.

Custom Security Engines (Bring Your Own Security Engine)

While SASE/SWG providers offer comprehensive security coverage, the ever-evolving threat landscape, particularly zero-day attacks, may require additional enhancements. Enterprise security teams are often proactive in their threat hunting efforts, identifying new attack patterns. They may also receive new threat patterns from other enterprise security teams through threat intelligence sharing. In both cases, these teams may want SWGs to protect their assets against these emerging threat patterns and attacks.

Although SWGs typically have well-configured IDP engines and other security engines, there are situations where the configuration systems may lack the flexibility to create rules for detecting complex threat patterns. Relying solely on SWG providers to add new software logic for these protections can be time-consuming. Additionally, the threat patterns observed by enterprises may be specific to their environment and not applicable for generic usage. In such cases, SWG vendors may be hesitant to release new software in a timely manner to address these custom requirements. Therefore, there is a need for flexibility to integrate new custom programmatic security engines developed by enterprise security departments or Managed Security Service Providers (MSSPs).

SWG solutions are expected to provide open interfaces for incorporating new security engines. Some SWGs offer the capability to add Lua scripts and WebAssembly (WASM) modules. With these capabilities, organizations can develop new security engines such as Lua scripts or WASM modules and integrate them into the SWG infrastructure. SWGs ensure that these custom engines do not interfere with other security engines and that they consume compute resources within the configured limits set by the SWG administrators.

By allowing the integration of custom programmatic security engines, SWGs empower enterprises to enhance their security posture, promptly respond to emerging threats, and protect their assets effectively. This flexibility enables organizations to leverage their in-house security expertise or collaborate with MSSPs to develop tailored security engines that address their unique security requirements.

Summary

In summary, this article has provided an overview of the security engines for secure Internet access. It is important to note that the inclusion of all security engines may vary across different SASE/SWG solutions, and new security engines may be added as new types of internet threats emerge.

SASE/SWG solutions leverage security engines such as IP Reputation-based Threat Protection, Domain Reputation-based Threat Protection, Access Control, TLS/SSL Inspection, File Reputation-based Threat Protection, Anti-Malware, Intrusion Detection & Prevention, Data Loss Prevention, and others. These security engines enhance overall security measures and provide protection against various threats when accessing the internet.

As the threat landscape continues to evolve, organizations should regularly assess their security needs and ensure that their chosen SASE solution incorporates the necessary security engines to mitigate emerging risks effectively.

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