Transcript
For anyone who doesn't listen to us normally, this is our monthly podcast where we go through the Zscaler release notes for the various Zscaler products, and we come through and pick out anything that is particularly interesting from a security or admin quality of life perspective. With me this month, I have Chris. Hello, Alex. How are you? I'm good. Thanks, Chris. Thanks for being on. And Darren. How's it going? Happy to be here. As usual for the format, my guests have gone through the notes and they have picked out a number of features that they think are particularly interesting. So let's just go straight into it. I think the first feature we want to talk about, Darren, you picked this one out. This is the ZIA feature. My understanding is that there is now a AIML detection source column in the logs that customers can leverage to get a better understanding of how blocks have been done. Is that correct? Yes, absolutely. So before, let's say you get a SOC alert and the alert states that a connection was blocked to a suspicious domain, before we would state that the reason was blocked by advanced threat protection, but it didn't give you that much context or didn't give you really transparency into what was behind the advanced threat protection that made the block. So now you can see which AIML-based security modules Zscaler has that actually triggered the block. This really matters because your response is going to be different for each one. If it's the DGA model, you're looking for compromised endpoints. And if it's the C2 model, you might be dealing with an active breach. For leadership, the new cybersecurity insight widget gives you a straight answer to the question which AI engines are catching the most real threats. That's your ROI conversation in one dashboard panel. And here's the operational win. If you notice one model is generating a high false positive rate on a specific traffic pattern, you can now isolate that and get that tuned. How would you do that? So in a case like that, if we saw a large amount of false positives, what we would typically do is you've got some flexibility on creating exemptions. But in terms of a false positive, we would open up a support ticket and request our security team to investigate this to ensure that we focus on the specific area that can be improved. Okay, perfect. So something that the Zscaler Threat Labs would be handling. So for the next feature, Chris, I think this one is one of yours, right? This is still a ZIA feature. It's on the Cloud App Control side to do with Gen-I prompt configuration. Yeah, Alex. The Zscaler now lets you capture Gen-AI prompts right in the Cloud App Control configuration. So you can keep tools like ChatGPT, Microsoft Copilot, Gemini turned on. Users can use them and still stay in control by having visibility. You'll capture the user prompts up to about 2K worth of prompt will be logged in the Web Insights. And then you can allow folks to see them or not see them to audit them. This means you can log and see what users are asking within the AI-based applications, maybe spot risky behavior, investigate quickly, tighten down or relax acceptable use, you know, with real evidence. So you kind of compare what the users are doing with your policy and change it as needed. You of course will need SSL decryption enabled for these Gen-AI apps that you want to capture the prompts from. Most of them are just simply SSL. Now for Copilot, you will need to make sure that number one, that SSL decrypt rule is above the Microsoft one-click rule, of course, so that we don't bypass it in the SSL decryption. You also need to make sure that WebSocket inspection is enabled as Copilot uses WebSockets to connect. And then there is a list of domains again for Copilot that you will need to make sure that you allow the decryption on. And again, you can find all of this information or more of it in the help pages. So bottom line on this is that, you know, users can keep their productivity boost from these Gen-AI-based applications and then security and compliance gets the visibility they need and the control they need to make good decisions about what users are actually doing within the applications they're using. One last thing is this does require the license for what's in the TLP world, the data protection world called Gen-AI data protection. This should be, you know, something you talk to your sales team about if you're interested. Cool. Thank you, Chris. And then continuing on in the trend then, I think we've got at least one data protection feature that you were going to talk about. So go ahead. Yeah. So this is, you know, looking at, again, the timeout identifiers in your web insight logs for DLP rules, data protection rules. So we've extended a new field within the web logs that you can filter on or view and give you insight to what transactions are being bypassed in your DLP policy because the scan timed out for whatever reason. You know, maybe the file is very large and complex. Maybe you have a very complicated regex, the expression that you're using, but, you know, there are occasions when data protection policies hit that timeout setting and you can, of course, you know, change that if you need to, a little bit longer, a little bit shorter. But this gives you concrete evidence within your web insight logs as to which transactions were bypassed because of a timeout. And you can now add them to not only alert on them, you can audit them. You can use, as I said, that data to tune your timeout settings. And this gives you fewer things or violations that may slip through unscanned just due to a timeout. Perfect. Thanks, Wes. I think that concludes then the DLP features. So I think now we're moving on to the next main product, which is a digital experience. Yeah, absolutely. Thanks. So this is kind of moving ZDX, or as you say, Alex, ZDX, the proper way, as we mentioned earlier, into the Experience Center. So, you know, if our users have not started using the Experience Center, you really should take a look at what's there only because that is what is coming here very soon in the path of our products. But in this particular case, we're talking about some additional features that ZDX allows you to do in this new Admin Counselor, the single pane of glass, if you will. It includes, of course, ZIA, ZPA, ZDX features, Client Connector, Branch Connector, Office Connector. These are being all combined into one GUI. So here's what makes this really powerful, Alex. It gives you a horizontal view across multiple tenants. So if you're managing, let's say, a dev or a staging or a production, multiple production for separate business units, you can see the ZDX performance data across all of the platforms from the single interface. Why should you care? With ZDX and the Experience Center, you're getting not only this cross-horizontal visibility, but you're able to apply your AI-powered troubleshooting through the ZDX AI Copilot feature. We have a network intelligence dashboard that identifies ISP bottlenecks across the globe, device health scores. All of these things can help flag issues before the users maybe even know it. Integrate your UCAS-level analysis things for Zoom, Teams, WebEx, and that gives you a very clear visibility across the board. And now you can start to make that more of a proactive. We're integrating the ability to do remote remediation, where you can push PowerShell scripts to fix things without touching the machines physically. And this really turns your admins from a reactive firefight mode into more of a proactive problem solver mode, even in complex multi-tenant environments. Right. And of course, as you mentioned yourself, the advantage is the fact that it's a single pane of glass. So now you no longer have to log into separate admin consoles for all three of the main Zed Scaler products. You've got all of that data, all of those troubleshooting and remediation steps. All of that is available inside the single console alongside your Zed AI and Zed PA policies. Thank you, Chris. So with that, that's our one ZedDX feature for this month talked about, although it is a pretty good ZedDX feature. And then we have a number of Zero Trust branch features, which Darren, I believe you were talking about. So, yeah, for the Zero Trust branch, a quick introduction for those who don't know. The Zero Trust branch is a Zed Scaler solution that allows you to securely connect your branch offices or factories to the Zero Trust exchange without complex networking. It replaces legacy branch network access with identity-based direct-to-app connectivity. So for the specific feature, we've got the dynamic DNS updates for Windows endpoints. So in gateway mode, the Zero Trust branch is your DHCP server and your DNS gateway. It hands the Windows endpoint an IP address, and then Windows immediately tries to register its hostname back to DNS. That's just what Windows does. Every single time it gets an address, it renews the lease. Before this update, the DNS proxy saw the dynamic DNS update and didn't know what to do with it. It wasn't a standard resolution request. It wasn't matching a ZPA app segment. It didn't fit the allow block redirect policy model. So it just got dropped silently. And then you get the cascading effect. AD authentication starts failing because the domain controller can't resolve the endpoint by name. Windows tickets don't get issued properly, printers disappear, et cetera. So what the Zero Trust branch does now is recognize the dynamic DNS update packets and forwards them over to your DNS server. The endpoint doesn't know or care that the Zero Trust branch is in the path. It just now works. For branches running Active Directory, which is essentially every Windows shop, this is a difference between a smooth migration to Zero Trust branch and a week of, why is Kerberos broken? So that was it for the dynamic DNS update for Windows. The next feature that we've got is disable DNS proxy option for device segmentation within the Zero Trust branch. So before we jump in too deep, let me walk through how the DNS proxy actually works because this context makes the toggle meaningful. DNS proxy evaluates every DNS request against your policy in a top-down fashion. First match order with four possible actions. So the first possible action would be resolved by ZPA. If the FQDN matches the ZPA app segment, the proxy responds with that synthetic IP. Second would be allow. The request is encapsulated the client source IP and forwarded based on your traffic forwarding policy. It could go to ZIA. It could go direct. Third would be blocked. We had just silently dropped the DNS request. And then fourth is going to be a redirect forward to a specific external DNS based on your configuration. Now this limits support for deployments that require direct DNS resolution, right? An example would be where every IoT device gets a isolated 32 slash 32 IP address. These devices are not ZPA where they don't require access to ZPA or ZIA. They simply need to resolve an internal address directly. You disable DNS proxy on sites where devices need direct DNS resolution and you keep it enabled where devices legitimately need access to ZPA applications through synthetic IP resolution. So that's it for disabled DNS proxy service. Next we've got app connector auto recovery status and provisioning key usage limits. So this is specific to VMware based app connector deployments. To understand why this matters, we have to touch on what hardware IDs are and why they matter essentially. Again, for VM based app connector deployments, you provision the VM with a URL and provisioning key and there's two things with that. The provisioning key itself has a maximum reuse count that you configure and the underlying instance that consumes that key has a unique virtual hardware fingerprint. For example, the hardware ID. If and when you decide to migrate that virtual machine to a new host, the underlying hardware fingerprint changes. So the app connector notices the hardware ID mismatch and causes the app connector to go offline. Before this update, recovering from this was a manual process. But now when the hardware ID mismatch is detected, the connector automatically attempts to reprovision itself to self-heal. Now this has some implications to the maximum reuse count for the provisioning key. So if we're going to self-heal, we're going to be leveraging that same provisioning key and you could potentially hit the maximum reuse limit on the provisioning key. And what we've done here is if it can't recover because of the max reuse limit on the provisioning key, instead of the status reading the generic offline message, it will state provisioning key utilization count exceeded and the UI actually tells you what to do, which is to go increase the maximum reuse setting for that key. So would we generally advise that customers adjust their reuse limits upwards then to take this feature into account? I think it's important that before a VMware migration, that they consider this ahead of time. So yes, you could temporarily increase the provisioning key utilization count before the migration, remove the previous app connectors that go offline because of the hardware change, and then reduce the key count from there. That makes a lot of sense. And then we have, I believe, one last feature for this episode, which is a deception feature. And I think, Chris, it's back to you for this one. Okay. Thanks, Alex. Yeah. When you deploy deception, one of the types of decoys is called the landmine. These are decoys on your endpoint. They consist of decoy files, fake credentials, honeypot processes running on the laptop or device. And really, anything that touches them can trigger an alert, which is great to your EDR, your AV scanner, your backup agent. All these things are kind of poking at or touching these decoys and are supposed to. And if you allow this to happen, your SOC can get really drowned in false positives, right? Because of the way that we build the bypasses. So there is a new feature called a safe process or subtype within the safe processes. It's like a granular allow list, but smarter. So you're not just blanketing an EXE. You can say, allow this process to read the file, the decoy file, but if it tries to delete or rename them, then alert. So it gives you some subprocesses within the normal exemptions. Maybe for your processes running up in memory, if that process is killed, then alert. But if it's scanned by your EDR, then do not alert. So this really helps really greatly cut down the signal to noise ratio. And that's really what we're trying to do here. So if you put out these normal decoys and you have the normal kind of processes that backup EDR, AV, as I said, they're going to be getting a ton of alerts. Now, if you take these safe processes, and you can build the full safe process by indicating a hash for the legitimate process, so your AV file has a hash, you can put a certificate thumbprint, you can put full pathing. All these things will help with making sure you don't get too many hits or alerts. But at the end of the day, we can now take these processes and say, this process is allowed to not only touch the file, but only do a read or only do a scan. And this really, as I said, cuts down the amount of noise. And so getting this into your environment immediately, right? And don't wait to take two weeks to process it or let your SOC team get too many alerts where they're going to be overrun and annoyed and really get that kind of alert fatigue based on these deployments for these landmine decoys. If you take and put in these sub types and really tighten down what the legitimate processes are on your devices and keep them framed into what they're supposed to be doing, this then really gives you clean alerts from day one. As I said, no tweaking, no fire drills, because there's all these legitimate alerts coming in. But the bottom line is your SOC should be much more effective in getting the alerts that they really care about versus a bunch of alerts that are coming from legitimate scanning processes on your device. Yeah. And I think it's important to stress here, right, one of the biggest challenges to deploying deception in a production environment is the noise that it can generate from decoys being touched by sort of normal processes. So I think this is a fantastic feature just to make sense that that signal-to-noise ratio, as you mentioned, gets tilted more towards the signal side than the noise side simply by going ahead and excluding a bunch of safe touches on those decoy landmines. Absolutely. One of the tactics would be if somebody does compromise a device or a machine is really to try to mimic legitimate processes, right? So run an AV scanner that looks like a legitimate AV scanner, but in this case, if their certificate doesn't match or they try to do something like move a file or delete it, we're going to pick up on those sort of non-legitimate activities, and that's what we're alert on. And so it gives a much cleaner set of alerts. Perfect. So a great way for admins to solve one of the major problems with deception. So with that, I think it's everything we planned for this month's episode. So I want to say thank you, Chris, for coming here to talk about your features. Thanks, Alex. And thank you, Darren, for your features. Yeah, absolutely. It's been fun. And with that, we are done for this month. So see everybody next month's episode. Thanks, all.
