250-589 Symantec Web Protection—Edge SWG R2 Technical Specialist Practice Questions

In an explicit deployment, the client's browser is aware of the proxy. For an HTTPS request, the browser sends an HTTP CONNECT method to the proxy containing the full hostname of the destination server. This allows the proxy to make caching, routing, and policy decisions based on the hostname before the SSL session is even established. In a transparent deployment, the proxy initially only sees a destination IP address, which can make it more difficult to apply domain-based policies and can be less efficient for caching until after decryption occurs.

The dns lookup command, executed from the enabled command-line interface (CLI) of the Edge SWG, is the direct method to test the appliance's own DNS resolution capabilities. It queries the DNS servers configured on the appliance, which is essential for troubleshooting issues where the proxy itself cannot resolve destination hosts.

The core architectural difference is domain membership. In IWA direct mode, the Edge SWG appliance itself must be joined to the Active Directory domain, allowing it to communicate directly with domain controllers. In IWA BCAAA mode, the Edge SWG is not domain-joined. Instead, it offloads authentication and user group lookups to the BCAAA service, which runs on a separate, domain-joined Windows server. This mode is often used when security policies prohibit network appliances from joining the AD domain.

While the local categorization database is a primary defense, it relies on periodic updates. For new or uncategorized URLs, the WebPulse dynamic real-time rating service is essential. When the Edge SWG encounters a URL not in its local database, it can query the WebPulse cloud service. WebPulse uses a global sensor network and advanced analytics to provide an up-to-the-minute category and risk score for the URL, allowing the Edge SWG to block new gambling sites even before the local database is updated.

The diagram clearly shows the step-by-step evaluation. The SSL Access Layer decided to 'Intercept' the traffic. The Web Authentication Layer then matched a rule for the 'Sales' group, triggering authentication. Finally, the Web Access Layer matched the request against the 'Technology' category and the action was 'Allow'. This demonstrates a successful, authenticated, and allowed transaction for a sales user accessing a technology site.

Mutual TLS (mTLS) requires both the client and server to present valid certificates. SSL interception breaks this process because the Edge SWG presents its own emulated certificate to the client. The correct solution is to bypass interception for this specific traffic. Using the Server Certificate Common Name in the SSL Interception Layer is a precise and secure way to create this bypass, ensuring only the intended application traffic is excluded from inspection. Installing the client's private key on the proxy is a significant security risk, and disabling protocol detection is too broad and may have unintended consequences.

For IWA to function transparently, the client browser must recognize the proxy as part of the Local Intranet zone. This setting allows the browser to automatically send the user's Kerberos ticket with the request. If the proxy's hostname or IP is not in this zone, the browser will treat it as an external site and will not send the authentication ticket, resulting in a credential prompt. While time sync issues and incorrect SPNs can cause IWA failures, the lack of a Kerberos ticket in the initial request points directly to a client-side zone configuration problem.

To implement this policy, an administrator needs a Web Access Layer to define the traffic handling rule. The destination must be configured to match the 'Newly Registered Domains' category, which is provided by Symantec's categorization services. The action would then be set to trigger High Risk Isolation. A 'Threat Risk Level' object is for risk scores, not domain age, and an 'SSL Access Layer' is for controlling the initial SSL handshake, not for applying isolation based on content category.

Management Center is designed for centralized administration. The most efficient and scalable method is to organize appliances into logical groups (e.g., by region). A job can then be created to distribute the policy file specifically to the 'European' device group. This ensures targeted deployment without affecting other regions and provides a clear audit trail. Distributing to all devices is incorrect, and manual configuration defeats the purpose of centralized management.

This statement is false. In an ICAP integration, the Edge SWG acts as the ICAP client. It intercepts the traffic and, based on policy, forwards the content (e.g., a file download) to the Content Analysis appliance (the ICAP server). The Content Analysis appliance is the component that performs the actual malware scanning, sandboxing, and analysis, and then sends a response back to the Edge SWG indicating whether the content is clean or malicious.