In today's complex threat landscape, a single layer of security is no longer sufficient. Attackers leverage multi-stage, evasive techniques to bypass traditional defenses. Palo Alto Networks addresses this challenge by integrating best-of-breed security services to provide a layered, defense-in-depth architecture.
This article explores the powerful synergy between two key solutions offered by Palo Alto Networks: Remote Browser Isolation (RBI) and Advanced DNS Security (ADNS). By understanding how these services work together, organizations can build a resilient security posture that protects users from the most sophisticated web-based threats.
Core Concepts: A Quick Refresher
Before diving into the integration, let's define the two core services.
- Remote Browser Isolation (RBI): A preventative security service that neutralizes web-based threats by "air-gapping" the user from all web code. Instead of loading a website on the user's endpoint, RBI executes the browsing session in a secure, disposable container in the cloud. It then streams a safe, interactive visual feed of the site to the user, ensuring that no malicious code — including zero-day malware and exploits — ever reaches the device.
- Advanced DNS Security (ADNS): A cloud-based service that enhances traditional DNS security by applying Precision AI, real-time analytics, and deep learning to the DNS layer. Unlike standard DNS security, which primarily inspects DNS requests against static lists, ADNS inspects both DNS requests and responses. This allows it to detect and block a wider range of advanced threats in real time, including DNS hijacking, algorithmically generated domains (AGAs) used for command-and-control (C2), and zero-day phishing domains.
The Order of Operations: How RBI and ADNS Coexist
Understanding the sequence of security inspections is crucial to deploying these services effectively. The key takeaway is that every web request is fully inspected, with DNS Security acting first.
Here’s the step-by-step evaluation process:
- DNS Request & Inspection: When a user tries to visit a website, their device sends a DNS query. This query is inspected by the DNS Security service, governed by the Anti-Spyware Security Profile attached to the Security Policy rule. If ADNS detects the domain as malicious, it can immediately block or sinkhole the request. The session ends here; RBI is not invoked.
- DNS Resolution Allowed: If the DNS query is deemed safe, the user's browser proceeds.
- HTTP/S Request & URL Filtering: The browser initiates the web traffic (HTTP/S) to the now-resolved IP address. This traffic is evaluated by the URL Filtering Profile attached to the same Security Policy rule.
- Isolation Triggered: If the URL belongs to a category configured for isolation (e.g., newly-registered-domains, grayware, high-risk), the URL Filtering policy triggers the isolate action, redirecting the user into a secure RBI session.
- Continuous Security Within Isolation: This is the critical integration point. Every subsequent web session initiated from within the isolated browser—including user clicks, automated redirects, or scripts fetching content — goes through the full Prisma Access security evaluation cycle. This means for each new request, the flow starts over: it hits ADNS first, then the URL Filtering profile. Based on the policy, the new page is then loaded in isolation within the same browser tab, ensuring there is absolutely no degradation in security posture.
Defense-in-Depth: High-Value Integrated Use Cases
The true power of combining ADNS and RBI emerges from creating a flexible, multi-layered defense that can adapt to different user needs and threat scenarios.
Use Case 1: Enabling Safe Threat Research by Prioritizing Isolation
- The Scenario: Specialist teams, such as threat intelligence analysts or incident responders, need to investigate potentially malicious websites to understand attacker techniques. A standard security policy that blocks malicious domains at the DNS level would prevent them from doing their jobs.
- The Integrated Solution: This is where policy customization becomes a powerful use case. Administrators can create a specific, more permissive Anti-Spyware profile for these designated user groups.
- In this custom profile, the policy action for certain threat categories (e.g., Malware Domains, Phishing Domains) is intentionally set to allow instead of the default sinkhole.
- This profile is applied via a Security Policy rule that targets only the threat research team.
- The result: When a researcher accesses a malicious link, the DNS query is permitted, allowing the web request to proceed. The URL Filtering policy then correctly identifies the risky URL category and triggers the isolate action. The researcher can now safely interact with and analyze the live, malicious site within the protection of the RBI container.
Use Case 2: Neutralizing Malicious Redirects and Traffic Distribution Systems (TDS)
- The Challenge: A user is isolated while visiting a seemingly benign website. However, that site contains a malicious script designed to redirect the browser through a chain of domains (a TDS), ultimately landing on a malware-hosting page.
- The Integrated Solution:
- The initial redirect attempt from the isolated browser is treated as a new web session. It is sent back through the full Prisma Access inspection cycle.
- ADNS inspects the DNS query for the next domain in the redirection chain.
- When a query for a known-malicious domain is made, ADNS blocks it. The redirection chain is broken, and the browser is prevented from ever reaching the final malicious payload.
Use Case 3: Defending Against DNS Hijacking Within an Isolated Session
- The Challenge: An isolated website attempts to load a legitimate resource, like an image from a Content Delivery Network (CDN). However, an attacker has hijacked the DNS response for that CDN, causing it to resolve to an attacker-controlled IP address that serves malware instead of the image.
- The Integrated Solution:
- The isolated browser's request for the CDN resource initiates a new inspection cycle.
- Advanced DNS Security's unique ability to inspect DNS responses becomes critical. It analyzes the response for the CDN's domain, detects the malicious redirection, and blocks it. The malware is never fetched, even within the isolated browser.
Use Case 4: Stopping Zero-Day Phishing Within an RBI Session
- The Challenge: A user is browsing a forum in an RBI session and clicks a link to a brand-new, zero-day phishing domain. This domain is too new to be in any URL filtering database.
- The Integrated Solution:
- The user's click initiates a new web session and triggers the full security evaluation. The first step is a DNS query for the new domain.
- ADNS doesn't need a signature. Its ML models instantly analyze the domain's characteristics (e.g., algorithmically generated, newly registered) and identify it as suspicious.
- It blocks the DNS query, preventing the phishing page from ever loading. ADNS stops the threat at the earliest possible stage, even before the URL Filtering policy for RBI is evaluated for this new link.
Frequently Asked Questions (FAQ)
- Q: Does web traffic go through ADNS inspection twice — once from the user and again in isolation?
A: Not for the same request. The initial DNS query from the user's device is inspected by ADNS. If that is allowed and the session is isolated, any new web sessions initiated within the isolated browser (e.g., for embedded content, redirects, or newly clicked links) will trigger their own full inspection cycle, which starts with ADNS. It's a sequential process that ensures all DNS lookups, no matter their origin, are secured.
- Why wouldn't I just block all risky traffic at the DNS layer? Why do I need to isolate it?
A: Blocking is the right strategy for the majority of users and known-bad traffic. However, isolation serves two key purposes that blocking alone cannot:
- Productivity and Safety for Unknowns: For uncategorized or potentially risky "gray" sites that aren't confirmed as malicious, isolation allows business to proceed without exposing the organization to risk.
- Enabling Advanced Workflows: As described in Use Case 1, it allows specialist teams to safely conduct vital research on live malicious sites without compromising security.
References
