Zscaler, SASE Outbound inspection and protection, Season 1, Episode 3

Hi everyone, my name is Patrick Foxhoven and I've got two titles at Zscaler. I'm CIO for the company, but then my other day job is I look after our emerging technologies team, which is a team that has built some of our products. I've been with Zscaler from the beginning. We've been around for about 10 years now, and very happy to meet you two.

Sure. So obviously SASE is kind of a broad definition, but when you take the parts of SASE that we play in, the first product that we have is called Zscaler Internet Access, or I may use an acronym ZIA for short. And you can't stop our marketing team from putting Z in front of everything, so you'll see a naming scheme here on our products. But Zscaler Internet Access is basically our outbound security gateway in the cloud that has evolved over time. It started as a web proxy 10 years ago, and then over time has evolved to, I think, the true definition of SASE, meaning it's not just web traffic anymore, it's all ports and protocols. It's cloud sandboxing and advanced malware protection, it's data loss prevention, it's browser isolation, etc. So that's our outbound cloud gateway, so to say, that a user goes through on their way out to the internet.

Yeah, so if I talk about SASE a lot, Gartner has their 'Future of Network Security is in the Cloud' paper and they actually have a pretty good definition of SASE. If you don't mind, I'll share that quote here on my screen. This is the best representation of SASE, I think, that is available. Hopefully you can see that screen okay. In my mind, SASE is all about finding one vendor, or what is really another way of saying one platform, meaning SASE is not service chaining, it's not stitching together a bunch of point products. You want one platform that's going to do obviously secure web gateway, CASB capability, cloud access security brokering, DNS security, they included zero trust network access which is kind of the inverse of the outbound gateway, and browser isolation. So that's, I think, that's usually the best quote that I've found to reference what SASE is from Gartner.

Yeah, so we've been, I would say it's extremely mature. We've been playing as a pure play, born in the cloud, security delivered as a service offering from the beginning for 10 years now, which not many companies I think can claim to have that level of maturity. We've never, you know, SASE is all about consuming these kinds of services in the cloud as a utility, and we've never provided our service in the form of a single tenant box or appliance that a customer would run or a piece of software that they put in their environment. We've only ever delivered our service as a cloud. And so I think we're pretty bullish to say that we've been doing this the longest from a maturity perspective. We've been delivering this as a service for 10 years now. We're not an organization that's trying to take again a single tenant appliance version of how you used to deliver this service and virtualize it, put it as a VM and host it in a cloud and then call that SASE. We've only ever delivered this as a cloud service from the beginning, so extremely mature. And you've seen what we've done over the last decade, you've seen the evolution of our platform where like I mentioned before we started as a secure web gateway and just was handling web traffic, and then over the years added the ability to take all ports and protocols and then deepen the security capability with DLP and browser isolation and sandboxing and things like that. So we've evolved this platform over the last 10 years and it's, I think that's why we've been, if you talked about Gartner SASE term, you know, where SASE started, the secure web gateway, we've been in the magic quadrant, we've been the furthest right for the last nine years running, meaning the most visionary, and last year we just got to the furthest to the top too. So I think we're getting pretty good recognition around how mature the platform is.

Yeah, so we wanted to try to make it as simple as possible to consume as a customer. That's one of the advantages of any as a service offering or cloud capability. So it's quite literally priced as a per seat, so it's a price per user per month annualized. And that price will vary depending on, you know, we have different bundles or you can do a la carte service offerings. You can buy an enterprise license that has everything that we do from an outbound security perspective or you can buy a point license that's just one piece of functionality. So the price will vary, but we didn't want to get into the world of having to count how many devices a user has or even try to estimate things like concurrency or peak usage or things like that. It's just a fee per user per month annualized and we assume inherently that users will have multiple devices. I mean, I looked at my profile last night, I think I have 11 devices that are actively syncing through our service. So we assume a user is going to have a phone, tablet, PC, etc.

It is. It's up to the customer to determine what policies they want to have in play. If I put my other hat on as CIO, you know, in our company, how do we protect some of our critical data on a BYOD device? What we do is we basically have a policy that says when a user is logging into a critical service like Salesforce or a file sharing service or whatever, those services are configured to point identity to Zscaler. Zscaler transparently sees if they're going through our cloud or not, and if they are, allows them in. If they're not, rejects it. It's kind of just a transparent authentication hop. And so that's a very strong way I think to help with some of the BYOD challenges where we basically say if you want to access corporate data with your own device, you have to install our app so that you're going through our service, and if you don't, you just can't get to the data. It's as simple as that. And that's how we've, you know, we're a big BYOD shop internally, and that's how we've been able to kind of have a light-handed touch to making sure that it's being secure but not so draconian where you can't access the data at all.

Yeah, yeah. So it's kind of a way to transparently protect your data that are the things that people are accessing that's business critical, without again being really, really that painful for the end user.

Yeah, I'd be happy to. And I'll do that in kind of two ways. So I'll start with some diagrams, some diagrams that I'll walk through a couple builds just to kind of tell the story to illustrate it. And then I'm happy to break out a PowerPoint anytime that I get a chance to and I can give you some live views or demos of what some of the... Later on we'll dive into more specific questions about secure web gateway, but for now let's just start from high level architecture and dive in. Yeah, sure. So let me walk you through a little bit of the journey and what I think it takes to deliver SASE correctly. So we knew when we were starting from the very beginning that to do a service like this in the cloud in a way that you're not slowing users down and you're not introducing choke points or bottlenecks is you have to be as massively distributed at the edge as you can be. And another way of saying that is no one can go faster than the speed of light. So that means we have to be as physically close to the end user that we're serving as they go out to the internet. You don't want, you know, I'm sitting here in the San Francisco area today, I forgot what this feels like to get on an airplane to travel anymore, but so let's say I got on an airplane and I traveled to London, you don't want a user that's in London all of a sudden now to have to backhaul back through San Francisco or even the east coast. You want to be as physically close to the end user as you can. So what that means is you want to be as close from a latency perspective as you can, you want to be less than 50 milliseconds usually to wherever the user is. And so the way the internet is architected today, I think the right number of sites that you need to do that is probably a little over a hundred. We think now it's a little, we're at about 150 data centers. That's what in my mind is one of the prerequisites to even start talking about being a true SASE player because it's the E word is edge. I mean, it's a service's edge, it's you have to have a massive network at the edge and the edge has to do 100% of your inspection capabilities. Otherwise if the edge is just backhauling you to a more centralized region, it's just a little bit better but it's accentuating the same problem around no one is going to go faster than the speed of light. You're going to, even if you have an edge site at one location, you're backhauling 300 miles to another site where you actually have compute to do the inspection. That's going to be not an ideal end user experience. It's going to break localization, it's going to not be great from a latency perspective to do this service right. You've got to be massively distributed at the edge. You have to be in essence just a transparent pop or two on the user's way to the internet wherever they're going. And so that's why when you look at our architecture, we knew from the beginning we had to be massively distributed at the edge. That's the map I'm showing here, we're at over 150 sites at the edge. And you don't again do things like service chaining or backhauling when you're introducing more and more capability. Everything that you run has to happen at the edge that is real time. Naturally there's certain things that by definition are not real time like sandboxing. If you're going to download a file that a user is downloading and detonate it in a VM and watch it for two minutes, that doesn't need to be done at the edge. But if you're in line inspecting SSL traffic or applying malware scanning or applying bandwidth optimization or throttling or shaping or all those things that are real time and very latency sensitive, they have to happen at the edge. And so when we started building this architecture, let me advance to the next diagram. We said we had to come up with an architecture that would accommodate that, meaning be massively distributed at the edge, but then there's certain parts of the service that you don't want to be as distributed at the edge. And so we kind of had the luxury of doing a clean slate architecture where we basically said we're going to come up with three planes to our architecture and then we're going to build them ourselves. And you don't have the luxury of building an architecture like this again if you're trying to retrofit a single tenant appliance version of your service and create a VM of that and call that a cloud. We went so clean slate that quite literally we went solo level, we designed the TCP stack from scratch, we wrote our own TCP stack and built multi-tenancy in at that level. And so when you go that low level and then you build everything else out, you have an architecture I think that looks a lot like this. And so there's kind of three planes to our architecture. The top plane here, which is what we call the control plane, this is where customers define policy and configure how we're going to authenticate their users and what they want to have happen. And so that's somewhat centralized, that needs to be within regions, within major theaters, US, EMEA, APAC, but it doesn't need to be massively distributed at the edge. Then you have the middle piece which is what we call the enforcement plane, and this is those 150 sites. This is the inline piece of how we do what we do, which is basically another way of saying the proxies or the things that are in line, brokering or proxying traffic. Massively distributed at the edge, they get their policy from the control plane, but they need to get that and be able to operate with cached policy and update when things change. And we had to build real-time protocols to make that happen. And then last but not least the bottom piece is the logging plane. You want to aggregate your logs back to particular regions or theaters. And that is a big reason why is because you don't want as a customer when they start adopting a service like ours, they don't want the liability of worrying about their data being potentially sharded or stored in 150 sites around the world. They want to make sure that it's more aggregated back. And so when we come in line to the traffic in the enforcement plane, we never touch the drive with any pieces of customer data, we don't cache it, would only benefit us and we don't want the liability of that. We never write logs to local disks, they basically stream the logs in real time back to the logging plane. And by the way the logging plane can be, we can guarantee if you're a customer in the US, we'll store your logs in the US. We guarantee if you're in the EU, we'll store in the EU. If you're a large financial institution, let's say one of the largest Swiss financial institutions in the world is a customer of ours, we can guarantee the logs are stored in the borders of Switzerland, or we can even store it in private logging clusters on-prem if there's data sovereignty privacy requirements, if it's a government use case. And so then what happens is when a user is roaming through this infrastructure, there's no marriage of a user to a data center or even a stack of VMs or services. It's a multi-tenant design from the scratch architecture. So if the user's here in New York today, they're going to get their policy delivered on demand and 100% of their inline traffic will stay in New York, never service chained. And then if they travel to London tomorrow, the policy will migrate, we'll follow that user wherever they go. But ultimately it's a transparent experience to the end user where they basically roam throughout these 150 sites anytime, anywhere around the world. And again because we built it to be multi-tenant from scratch, there's no marriage of infrastructure to tenants so to say. That's a very different architecture than I think a lot of other approaches in the industry where they're trying to not do the hard work and they're doing this with VMs. They have the ability to provision a VM for a tenant in every site that they want to have service in and then they'll try to do some kind of loose orchestration to keep these VMs in sync. And that's a totally different model than designing this from scratch.

So if I recall what you mentioned is that you are doing your multi-tenancy at the protocol level. That's what you're doing. We wrote this... does the differentiation... Yeah, I'm using that as kind of an extreme engineering example to show how low level, how purpose built the architecture has been. We started at the TCP stack level and then built out.

Absolutely.

You do. So as... sorry, keep on. So every customer or every... they're going to be a bunch of IPs based on London data center, New York data center, just depends from where I'm coming. This is my source. If you're going to be... I'm guessing it is, it's going to be... we publish a pool of hundreds of thousands of IPs if you want to map that out. We do publish that transparently but it is going to be... and I think that's part of the security of our solution is from the user as they go out to the internet and they're getting their traffic scrubbed, there's nothing identifying that company or that end user. That's a benefit of our service I think from a security perspective, it minimizes the attack surface as the user is going out to the internet. Now that can break, there's lots of organizations that have legacy notions like they're going to a website that is filtered based on source IP. So we do have the ability for a customer to extend the enforcement plane, the middle piece, into their environment in the form of a VM or what we call a connector, and they can configure policies that says when a user is going to this destination, we want it to come out that VM on-prem in their own data center or in an AWS VPC.

Okay, makes sense. Yeah, I lost this bet ten years ago. I thought that today we would never have that because source IP based security is not that strong and obviously we've seen anything from spoofing to route hijacking illustrate that. So I didn't think it'd still be the case today but it very much is still the case quite often. So that's why we productize this feature that we call source IP anchoring that allows a customer to still work with a cloud service like this using their own IPs so to say, but without sacrificing security. It's not a... when they do that, the connector that they run in their environment is not an appliance, it's not listening to anything, it's managed and part of our cloud. The only reason why it runs there is to basically take on the customer source IP.

Yeah, so when a user comes to us, we're not an open proxy. We'd be kicked off the internet long ago if we were just a totally open proxy. So we always authenticate when a user comes to us. We do that by tying into the customer's existing identity environment. So that's done most commonly with SAML. So we'll talk SAML to if the customer has Azure AD or Active Directory or Ping or Okta of the world. We'll talk SAML to them and that's how we're doing user authentication. And if we want to consume group policies, so that often in a large organization they're not doing policies at the per user level, they're doing it in groups. Customers also define locations as a part of your policy. So you say this is my London office and I'm going to define that by source IP address ranges or define it by tunnels. So we can take tunnels from devices, routers, firewalls that they have on their prem and obviously the tunnels then have authentication as a part of that. And you can define your policies at any level of granularity. You can create a tunnel at your office and say send the default route to Zscaler and then within that tunnel you can define all your individual subnet masks or ranges and say 10.0.8 is my guest network, don't authenticate, let it go out. Because it's coming through the tunnel, it's still getting authenticated through us. So there's a really flexible policy engine that allows you to then determine how you want to do it. But the short answer to your question is we will talk SAML and authenticate the users via SAML.

Yeah, so there's lots of that capability in what we do. That's a perfect one example of many. So we have reporting, analytics, alerting that come into play inherently in our service. And then we realized that a lot of customers would want to use that but not have that kind of visibility siloed just with us. They want to maybe take the visibility that we have and correlate it with other infrastructure that they are logging or have management of like endpoint device logs, other things like that. So we actually have a productized offering that allows even the logs to stream out of our service in real time back to the customer's environment on-prem. That's what we're depicting here on the bottom right of this diagram, what we call nanolog streaming, where you can choose to take the full fire hose, all logs all the time, and stream it out into your SIEM, into a Splunk or ArcSight or QRadar or whoever. Or you can choose to say just send certain levels of events. And most mature deployments will have multiple streams going to different places as well. And that can then even add the anomaly detection and security insight that we have and even correlate it with everything else that they may have like say an EDR endpoint agent on the device with server log files or other things that they are aggregating.

That's if you want to correlate it. You can skip that option and just take advantage of the anomaly detection and alerting that we have inherently in what we do. The way we handle things like that is we basically are calculating a user risk score, a 0 to 100 number, and that score will go up the more risky the user is and will go down the less risky. And you can tie your policies and get alerting and even report on that trend. That over time we aggregate user risk scores up to company level risk. And I'm happy to show some of that if you'd like to see what that looks like. But I mean, you don't have to bring in a third party, that would only come if you want to correlate it with other things.

Okay, so let me pivot out of slides. And I never like to do canned demos. So this is our live production cloud. I'm logged in as the CIO of Zscaler, so you'll see actual live data from Zscaler's perspective. So to illustrate the point I was just referring to, under our analytics we have, I'll start at the macro level, we have company-wide risk score. And the company-wide risk score is showing that again that number that we're calculating, zero being good, 100 being bad, and aggregating across all of our users, all of Zscaler users, based on their activity. Meaning do we see malicious activity coming from them, do we see them browsing suspicious destinations, do we see the machine actually compromised with command and control and it's phoning home through us. All these different data points come into a score at the per user level and then aggregate up into the company level. Now don't be alarmed, this is a pretty high score. This is because we have our security threat researchers going through our service and always testing and testing the efficacy. So you'll see that I'll scroll down and show you the username.

Yep, yeah. So it starts to get into more conditional access like capabilities then where depending on how safe you are, you're tying access policies around that, absolutely. So here's our company risk score over time, the last 30 days. I can do different time frames if I want.

Well, so it actually varies based on the industry and also the individual company's tolerance for risk. So if it's one of our federal customers, so we're US FedRAMP certified and we've got federal agencies going through us, there's pockets of users where the risk score will be zero because they're not even doing general internet browsing, they're in air gap offline networks, so they're doing very little. And then you'll have a Bay Area tech company that the risk score will be 70 or what we're showing here because we don't really filter anything. So it depends. The way we've tried to help customers grasp that is you'll see here that we've got distribution graphs of what user risks are, the most risky users. In this case everyone's working from road warriors from home, we don't have any of our corporate offices because no one's in the office. But then we also allow you to compare across your industry, so one percent of peer organizations. So you'll see that we're in the technology vertical, so we've got a very high risk like I was saying. That's not something you want to be over cheating again, but this is again these are all security researchers getting 100 as their risk score because they're doing our research. And then we allow you to compare in your vertical and then across all of our cloud as well. And again you can go down to the user level here, like I'm literally picking on a particular security researcher.

This is just one view of many obviously. We can drill into, out of the gate, we've got dashboards that show all the different views of our service.

Yeah, yeah. So probably two parts to the question. Let me cover that just how we scale in general first and then pivot into the public cloud part of that question. So the secret that not many people know is what does the name Zscaler mean? You can tell that an engineer named the company. It stands for Zenith of Scalability. That's what Zscaler actually was founded on. We knew that scale was going to be probably the biggest challenge to solve in delivering a service like this. And by scale I mean true internet scale, meaning when we deploy a company with 300,000 employees or a small company in one location with 10 employees, we end up taking all of their traffic that goes to the internet and often not just when they're at the office but when they go home. We were even more pervasive than a traditional ISP would be at a particular site because we're handling all that traffic all the time across all their devices. And so scale was the biggest challenge we knew we were going to have to solve. To give you kind of a data point, we process a little over 100 billion internet transactions a day through our infrastructure, which we think is pretty unprecedented. We think it's definitely the largest security as a service offering. Compare that, that's a little more than 10 times the number of Google searches done in a day.

So the short answer is, let's say you load a website and there's 10 transactions within it, fetching an image, doing different fetching, JavaScript, etc. Those would be ten transactions in our metric because every single transaction that goes through us we log and we analyze from a security perspective and choose what level of inspection to do. So if it's a PDF being downloaded, obviously that's a transaction we're going to send through sandboxing is one example of many. But yeah, that's why. And the transaction count has kind of scaled in a crazy way. We've been ahead of Moore's Law, we've been doubling more than every 18 months. In fact, I'll share the graph because we like to geek out about this stuff and it also obviously is important when you're planning capacity. But yeah, we're more than doubling every 18 months that transaction count. So if we were talking less than two years ago we'd be at 50 billion. If you think about just the raw data of every transaction could be potentially one to two kilobytes of file size, I mean we're talking crazy amounts of petabytes. We had to figure out how to massively scale our logging infrastructure, how to massively scale machines in line processing traffic. That's why we had to go solo level like I was mentioning, writing TCP stacks from scratch because we needed to have that level of optimization to handle it. And there's like crazy events, we've got crazy statistics like when you see if you look at how people were working and all of a sudden everyone started working from home, the traffic patterns just went crazy because there was concentrations from corporate offices to now distributed around the whole world. And you have events like the explosion of Zoom. If you look at web conferencing traffic, Zoom exploding as a result of COVID too. One of the metrics that we've been sharing, our private access offering, because everyone started working from home, we saw a 10x increase in literally one business day when the world went on lockdown in different regions. So it's, yeah, we've I think we've very much been delivering on the vision of the company, Zenith of Scalability. And again you had to be a purpose-built architecture. If we were trying to pivot to kind of your second question, if we were trying to build an infrastructure like this just in AWS or just in GCP or just in Azure, we wouldn't make money to be honest. Because when you're processing this amount of volume, we end up becoming some of the largest consumers of even transit internet in particular countries or regions, and that just is not a model that makes sense in the cloud providers. We do use them selectively, so we do use AWS and Azure and GCP and in places like China, Alibaba for scale reasons, especially instantaneous scale like when things like COVID happens. But we do have 150 sites that are our own. And we do think, I'll share one more diagram with you that's architectural that I think is near and dear to my heart. We do think when you're delivering especially in the context of SASE, when you're delivering a service edge, you have to have sites that are your own because even the AWS, Googles, and Azures of the world, they don't allow you to run compute at the edge. Google has 30 some sites that is where you run VMs, they have 107 plus sites at the edge, but those edge sites just backhaul to where you run the compute. And if you can't run compute at the edge at that massively distributed way, then what you end up having is this is the model on the left is what we end up looking like. So users, devices, locations, as they go let's say in this example they're going to Office 365, that's the number one destination of traffic that comes through our cloud for natural reasons. What ends up happening is they come through one of our edge sites, we're likely directly peered with Microsoft in one of those 150 sites and takes one hop to Microsoft and is off on its way. If we built out our SASE architecture let's say hosted on an IaaS provider and running a VM, what that would literally look like, and this is real, you can't, I don't think anyone's ever refuted this, you basically have their front doors or edge sites and they backhaul to more centralized regions that run VMs. Just a year ago Google only had 20 of those. What ends up happening is the traffic comes to the edge, goes back to where the VM or the compute is running to run the service, pops back out to the edge, then peered to Microsoft, and then go to 365. There's a very different architectural approach on the right versus what we've done on the left. We don't see this, there's more than just us doing the left, but there's not very many. Because a lot of people think they can fast track to this space by just virtualizing, creating a VM and deploying them. Google has half the internet or whatever, but it's not really true as you start peeling the layers of what that architecture actually looks like.

Yeah, so there's two fundamental ways people connect to us or use our service. There is we provide a software agent that runs on Windows, Mac, iOS, Android devices. It's in all the app stores. We call it the Zscaler app, there's the Z in front of everything again. And the Zscaler app is not doing anything on the device, it's not trying to do any inspection on the device. It's basically just configuring or instrumenting the device to always go through Zscaler when need be and to authenticate. That's all it really does. All of our services are done in the cloud. It's just a lightweight way to have the device forward traffic to us. So they can deploy the app on the endpoints and that's it. Or they'll often also deploy when it's a fixed location, a branch or a headquarters or a campus where they own or control the network, they'll create tunnels at the edge of that network to us. So that's from a traditional router or an SD-WAN device or it can even be a firewall creating an IPsec VPN. The two tunnels we commonly will see is GRE tunnels from networking devices or IPsec from...

Security devices, is this kind of as a reference of GRE or IPsec? We don't, other than the fact that GRE will often on their side be a lighter weight, more scalable option because IPsec adds, you know, crypto overhead and often performance for IPsec on a box on their site also manually limitation a bit. Like I cannot run like a five gig on GRE or an IPsec.

Yeah, so you can do multiple tunnels and load share among them. Or if it's like a really high volume site, you know, for example, the state of North Carolina, all K through 12 students go through Zscaler. That's 1.2 million students. That's hundreds of gigabits of traffic. You don't even want to necessarily mess with tunneling that. We can extend our inspection plane into their environment in the form of either the physical boxes, the same physical boxes we deploy in our data centers, or if it's smaller deployments, VMs that they can run. And that can help alleviate the need to even tunnel it then, if that makes sense.

Yeah, that's the SD-WANs modernize that. And actually, we have open APIs that all the SDN players have consumed that make that be really easy to turn up and then automate or orchestrate failover. Even the legacy routers, what we end up doing is we provide best practice configuration depending on the vendor. They call it something different. Cisco calls it IPSLA probes, Juniper calls it RPM probes. We basically give you the ability to monitor the tunnels and do auto failover on the device if it does go down. So even legacy devices, we can get a little bit more modern in terms of doing failover and fault tolerance.

Yeah, I do too. Great.

Yes.

Well, so that's up to the customer's configuration. You can give the users the option to turn it off, or you can password protect it where they have to have a one-time password that it gives them to turn it off, or you can make it completely hidden where they may not even need to see anything to be able to interact with. So it depends on the company's use case on how they want to configure that.

Yeah, so this was an area of recent enhancement. Z App used to take just web, but we've added the ability to take all ports and protocols through Z App now. It's actually always taken it for ZPA bound flows for five years. We added it to ZIA bound flows now as well because we naturally over time added a cloud firewall in our internet access offering. So you absolutely want to be able to take all ports and protocols then.

Yeah, well, actually, to be honest, kind of both. It was, you know, a very common user request because they want the exact same level for the users wherever they go, not just when they're on the corporate office getting all ports protocols, when they go home still getting the same protection. So that's a natural ask, but it was also the inevitable. We always had planned to do that. If you've kind of seen how we've gone to market, you know, we tackled web first and then added more capability because doing a web proxy at scale is the hardest problem there. Adding all the other traffic is actually not, wasn't as hard.

Yeah, so our Z App does have the ability to do endpoint checks, what we call posture checks. And it's more commonly done on our ZPA offering than ZIA, but your policies then can be consumed based on criteria of the posture. Is the machine on the domain? Does it have a certificate on it? Our government customers love to say, 'Does it have a CAC card or a smart card inserted into it?' And you allow more or less access dependent on those criteria.

So yes, the short answer is yes. We do have some of our service provider partners that will take what we do and white label it or integrate it at the network level and then sell it as a white label service back to the end users. And we also have OEMs, you know, router device manufacturers that do the same. They'll use APIs and they are transparently integrating or forwarding traffic to our service in a way that the end user doesn't even see an agent or have anything on their network that's doing the redirect. So yeah, we do have some of those relationships as well. I can give you an example. If you've heard of, have you heard of the router Wi-Fi vendor Eero that Amazon purchased? Yeah. So if you buy Eero security, their Eero Plus offering, the actual internet security filtering and scrubbing is Zscaler. It's just white-labeled Eero and they're doing that on the back end with APIs and integration. They don't hide it completely, but it's an end-user branded experience. It's just another tab that shows up in your Eero app on your phone.

Sure. So URL categorization is kind of a commodity now, so to say. It's not a big area that any company differentiates in. We have always done a dual approach where we have our own categorization and our own databases that we've been building over time. If you think about, you know, 100 billion transactions a day now for even just a month, that's a lot of categorization. And we've invested heavily in machine learning and dynamic categorization on the fly. So we've got our own source and that's the primary source. And then we absolutely OEM from a couple third parties that the rest of the industry uses. We OEM those databases as well to kind of fill the gap if there's a particular language or region or geo that we don't have full coverage for. So we do a combination of both just to make sure that that's never, you know, that's the kind of table stakes. If you don't have good basic categorization of the internet, everything starts breaking. Whether you're trying to throttle bandwidth, you know, making YouTube videos stream properly versus prioritizing Office 365, or obviously security is really important. The security categorizations, we take it a step further. We have about 60 collectively third-party feeds, and these are partnerships that we have with companies like Microsoft and Google's of the world. They're community-driven initiatives, you know, the PhishTank and common community sources of intel. And then we purchase, you know, antivirus is another commodity thing. You know, we OEM AV databases. We won't try to reinvent the wheel when we don't have to. And so we bring in 60 third-party security feeds. Collectively, the security and the URL categorization, one number we're kind of proud of is we are updating our intelligence, those data sources, a little over a hundred thousand times a day collectively. And that's, you would never see an appliance company try to update an appliance with a hundred thousand database updates a day. That's only when you have a cloud service can you start turning like that.

We do. We have a threat research team. This counter to the naming scheme, they're called Zscaler ThreatLabz with a Z at the end. But there's still a Z in there. They actually have a great security blog that's for the industry that's often quoted and referenced a lot. And they're also charged with the security efficacy of our service and doing all the modern tool sets, whether it's, you know, community exchanges with things like STIX and TAXII to analyzing when we see some new emerging threats that no one's seen before publicly, disclosing and talking about them with the rest of the community to running our sandboxing infrastructure.

Yeah, yeah. So there's a couple parts to that. You know, one common angle is a newly registered domain, something that was registered, you know, an hour ago and is all of a sudden now serving malware that no categorization would have. We have policies that allow you to say don't allow a user to go to any newly registered domain that's been registered in the last 30 days. That's actually pretty effective because very rare will you find legitimate applications that get hurt by that. You get a lot more security by just saying don't allow newly registered domains. So that's a policy element we see very powerful. We also allow customers to do things like if it hasn't been categorized, to display a CAPTCHA or a caution. So don't prevent the user from getting there actively, but give them a warning that, hey, this could be something pretty suspicious. And so they'll often implement CAPTCHAs or things like that in addition.

Yeah, so we've always had the ability to say file types allow or deny. And so commonly, you know, there may be groups of users that should never download an executable and that's a common policy. But more commonly now, what we end up doing is our sandboxing capability. You basically say allow the user to download it, but it has to go through the sandbox first. And if the cloud has never seen it before, or well, let's say they're downloading a file that the cloud has seen before, we do a checksum hash on any file that's going. If we've seen it before, it can fast path, they can download it right away. If we've never seen it before, you can literally set your policy to say quarantine it. And the end user experience is quite good still. They get a page that says, 'Hey, we're going to scan this, please wait,' and a couple minutes later then it pops up and says, 'Hey, it's been scanned,' and then it's available to download. So we've got that end user workflow pretty nice there. A lot of the other sandbox players hadn't ever built the quarantine capability because they weren't a full proxy. They were doing it on the network on the side, where we can kind of really own that user experience. And that's, I've seen, that's how Zscaler protects ourselves is everything has to go through the sandbox.

So the short answer is yes. No, that's naturally always going to be a cat and mouse game. We'll come up with new evasive techniques and we'll come up with new countermeasures and that's always, that's part of what our threat research team does on a daily basis is keep that up to date. The where we, I think, we shine a little bit is because our heritage is a true proxy. We're a full layer seven proxy and so we are, you know, actively proxying that content, not trying to scan it passively like the way a stateful firewall would. So that gives us the ability to detect and unminify or de-obfuscate JavaScript and look for zero-pixel iframes and do all the kind of, you know, unpacking techniques because we're a full proxy. That gives us an advantage there. We also can still send those objects through sandboxing. And the last piece is we made a recent investment in browser isolation and that can, I think, be very helpful. You can write a policy that says when a user is browsing a suspicious website, don't let that content render on the user's browser. Render it on a headless browser in the cloud and just stream pixels or images down to the end user's device. So it's a truly transparent end user experience, but from a security perspective, a huge win because, you know, some of the current web threats are more isolated and never even going to the endpoint.

Yeah, absolutely. People like the idea of browser isolation. It is a huge win for the company. I think so without a doubt, as long as it's a modern way of isolating where it's transparent to the end user where they may not even know it's there. A lot of the early browser isolation technology that we all saw was compromised either with performance or, you know, the user experience was not great. But, you know, we acquired a company almost a year ago called Trustdome that had a very modern approach to how to do this and I think it's been a huge win.

It would. The way to think about it, and our engineering leader of the team is in emerging tech and he'll throw something at me if he hears me dumb it down this much, but this is the right way I think to kind of think about what it's doing. I'm sure you've done a remote desktop connection to a Windows machine and then launched a browser within that. What's literally happening is browser isolation there. That content's staying rendered locally there. You're just sending mouse clicks and getting image refreshes. A modern browser isolation platform, that's all it's doing. I mean, we're literally running a headless version of Chrome in the cloud and using an optimized protocol to stream mouse clicks and screen refreshes. That's the right way to do it. And then any application is going to work in that environment. I mean, we literally can have even video, we can stream YouTube through it and it works fine as long as that protocol is optimized correctly.

Yeah, yeah, yeah. Fundamentally, we've been playing in the CASB shadow IT space before it was even called those things. We called it five, six years ago before those terms were really around, we called it Web 2.0 app discovery and control. Fundamentally, when a user is going to the internet, we've always been identifying who the user is, what application they're accessing, and then allowing more granularity around do you don't just allow or deny that website or that service, but maybe allow them to go to Box and download files but not upload, or, you know, provide more granular controls on that. That's always been a core part of what we do. Even before it was called that, what we've chosen to also do that I think is differentiated, I'll share a screen here. One of the dashboards that is in our admin UI is what we call cloud applications. We've got a cloud application dashboard here which is showing shadow IT, all the services that are being used. But we wanted to take it a step further, not just show that they're there, but allow companies to get an understanding of how risky that is. So we're providing a risk level for the applications. And it's not just us, we didn't want to have just a Zscaler point of view there. So we'll bring in, depending on the partner, which service they have, we'll bring in data from, I'll pick on this one, Twitter. Everyone's pretty familiar with Twitter. Here's Microsoft's, we have syndicated data from Microsoft's Cloud App Security. It has more visibility to why they say it's good or bad and different things. We bring in Bitglass, we'll bring in, we actually had partnerships with some of the core CASB players to bring that into our UI. And then you can write your policies around these risk levels and understand what applications exist.

Yeah, so one minute, I can do that. So a big part of DLP to be effective today is to be able to do SSL inspection. I think that's obvious. I would predict in less than 18 months the internet's going to be 100% SSL encrypted. We see some of our customers measure by 90% or more now. So because we're a full proxy, we can, we're not blind to any SSL transaction. That's really, that's table stakes for DLP. When we're inspecting SSL, like a user going to Gmail uploading an attachment, we have out-of-the-box pre-defined dictionaries or engines. I can share that on a screen. So we've got out-of-the-box engines that you can use in a few clicks. And you can say, I want to look for credit card numbers as a particular engine. So we've got these pre-defined dictionaries here like look for adult content or credit card numbers or financial statements or gambling. These are all pre-defined dictionaries you can just in two clicks apply and say when a user tries to post credit card numbers to anything, block it, alert it, log it, allow it to go through but send an audit trail back to auditors. This is kind of basic forms of DLP that is really powerful. Again, when you're not blind to SSL, we added in the last few years, I'd say, really advanced DLP functionality that our customers asked us to do, which is doing what's called the exact data match technology. I don't know if you're familiar with EDM, but EDM basically allows, we give what's called an indexer, a VM that a customer can run on their prem and their network. They can connect to their exact data sources, so their file shares, their database mounts, etc. And we never wanted liability as a third party of storing their data or even having visibility to it. No matter what a third party would say, I would never trust a third party with certain pieces of data in my organization. So what we do is we do a one-way cryptographic hash of what that content is. So if it's a bank account number, we're going to do a one-way cryptographic hash and just send that hash to our cloud. And then as a user is browsing the web, going to, doing whatever they're doing, we can apply in real time that exact same algorithm to hash whatever content they have. And if it matches, then we have an exact data match and we can block that from leaving the organization. And so we've seen, you know, that was developed initially for a large financial customer where they said, you know, we've got hundreds of millions of accounts and billions of other data points and we want to exactly identify if this is ever leaking out to the internet, but we can't trust you with having visibility to it. And our EDM capability in DLP is really differentiated because you cannot even think about touching half of what we're doing there unless you have a true multi-tenant elastic cloud infrastructure to be able to deliver it.

Yeah, so we do POCs in a couple different ways. We have, you know, pre-canned environments that are already pre-configured that's shared that they can start playing with very quickly. Or we do have, we absolutely encourage, you know, full POCs where we provision you just a normal tenant on our cloud in minutes. Not because, again, we're not dedicating or spinning up infrastructure. You can have an account in a few minutes and then you can go through configuring the whole service. And if the POC is successful, that's your production tenant. Then you can convert it to production. You know, there's nothing to convert other than adding a license to entitle it. So POCs are very, very commonly done. That's what it should be in the cloud world.

Yeah, and I actually do have a slide. Now these logos that are on here are not all inclusive, they're just representative of some of the vendors. But we kind of view the partnership space in a few buckets and I think this is also important because we're doing a lot, we're tackling a lot of different areas with just what we do ourselves, but we're not trying to be all things to all people. And this is how this has guided our product development as well, meaning areas that we choose deliberately not to go into. Because no one can be, you know, we don't want to ever be in the category of a jack of all trades, mastering nothing. So think of us as the inline security policy enforcement for anything coming in and out. We've deliberately partnered and created all these dotted lines or APIs. I mentioned before we consume identity from whatever they have. That's standard SAML-based integrations, but also more modern implementations like SCIM where we can do real-time attribute syncing and if a user is deprovisioned, they get kicked off our service immediately. We use SCIM as a protocol to keep that current. So we've invested heavily in those APIs. You can tell CrowdStrike, Carbon Black, MobileIron to kick somebody on the net for based on XYZ. Yep, yeah. The bottom left, the endpoint protection, that's where you got the EDR players like CrowdStrike and Carbon Black that can be policy integration, but that also is telemetry. So if, you know, we detect a threat that CrowdStrike needs intel on or vice versa, you can actually integrate so that the two's, you know, your CrowdStrike tenant is sharing indicators of compromise with your Zscaler tenant and vice versa. We've got APIs between those players. The MDMs on the bottom left, you know, the AirWatchs or Intunes or MobileIrons of the world, they often can be used to deploy our app. And so we've got API integrations with all of them. The bottom right, we already covered the branch devices, whether it's routers or more commonly SD-WAN devices, having APIs to ease traffic forwarding and orchestration. And then we also did cover the top right, which is the SOC SIEM vendors, the Splunks, ArcSights, QRadars of the world. Those have, we have API integrations so we can stream events out to them. So this is just a kind of a macro view of the platform. I saw you had some questions around other things like SOAR, DLP, EDR, etc., etc. I mean, we also have, if I try to logo you to death, we've got integrations available and in dev and future, I guess it's all going to find when you're on your website.

Yeah, so that, if you recall, I can share it here in a moment, the risk dashboard is, I really like the comparison to the rest of the market. I think that's a powerful metric that you have, right? But is there anything else, right, more deeper, more interesting that you can show us? Yeah, so when you talk about, you know, a C-level report, even the screens that I've been sharing with you are kind of the IT admins going into the console. We summarize, let me share my screen here. We summarize this data when you're talking about getting into like C-level reporting back on what's happening. We have a mobile app that is called Exec Insights that literally, as an IT admin, I can go create a C-level account and give them a login to this data on their iPhone or their tablet and they get a very high level, even further summarized view of this data that they can access in real time even if need be. And so we'll see CSOs use that to do board presentations and so forth. We also, you'll see here, we've got this bucket called executive reports. And this is kind of a one-page report that you can configure to, you know, email or send off to a group of execs in the company to kind of provide an overall summary. How many threats did we block in the last month overall? Security versus policy violations, what your percentage is versus the cloud average. Of the things that we blocked, what were some of the advanced things that we saw? So you'll see, you know, crypto mining, spyware, phishing, etc. We saw 198 phone-home botnets, usually that's always a metric that they care about. What value did the sandbox deliver? So this is kind of a very high level, this is a one-page report that, and it pivots beyond just security, it shows like where internet activity is going or what's consuming the most bandwidth or what business applications are there, etc. So we have these exact reports that is often used for that as well.

You are. And we again exploit the fact that because we're a full proxy, we can do very good bandwidth optimization. And by that I mean we're not a network device that's going to have a packet queue and then start dropping packets and then causing an end user to experience interruption. You see that when network devices try to do aggressive bandwidth throttling. Because we're a proxy, we can do things gracefully like control TCP window sizes, shrinking them up and down on one side or the other. And so when I'll share a screen here, when you write a policy that says streaming media shouldn't take more than 20% of my pipe, what we do is a YouTube video, rather than streaming into high def, we'll stream it standard def when there's times of contention and you'll never see a frame interrupted, preserving bandwidth. Only when you're a full TCP proxy can you do it that gracefully or selectively. And so that is just another element in your policy that you don't have to worry about how to classify traffic or how to get in line to the traffic on the side or things like that. Our bandwidth policies are really this simple. Streaming media, what here, if I show you the bandwidth classes, you can say what kinds of things is it? File shares, is it streaming media, is it VoIP, is it web conferencing? And you can either then start saying guarantee minimum bandwidth, maximum bandwidth, and these numbers then apply dynamically to whatever bandwidth values are set on the locations that you're applying the policies to. And this will work for offices and the Z App. This, in full transparency, does not work for Z App today yet. So that's coming. This is for fixed locations today, but won't be the case very soon.

I don't think so. I think you've covered a lot with your questions. Great. I'm just checking my notes. I don't, nothing comes to mind. I'm happy to tackle your questions.

Yeah, that varies dramatically based on region. North America, Western Europe will be much higher than Central, Latin, South America and parts of it. Varies dramatically. I think one of the macro numbers that we look at is just how much bandwidth sustained is, if you divide it over 24/7. You know, we see a hundred to a couple hundred kilobits of bandwidth per user sustained if you do it over an even time period. And actually that'll be very bursty because they're going to be doing an hour of work and just email and then all of a sudden stream the Netflix video and that'll be very different depending on that activity. But you know, you're usually talking definitely sustained less than a megabit consumed per second if you average it over time.

Yeah, so you could on your policy say, at the ZPA level, let it go direct. The reasons why you would commonly still go through Zscaler, there's probably three parts to that question. The first reason is if you still want to have visibility, reporting, analytics, where bandwidth is going. Now if it's users' home, then you may not care about that. But if you do want visibility to the reporting metrics, analytics, then it needs to go through us obviously to generate that. The second reason is from bandwidth optimization to the last question. If you do want us to preserve bandwidth for Office 365 over Netflix, it has to go through us for us to apply the bandwidth policies. And then the third reason is from a security perspective, even though those are considered trusted destinations, you still may want us there in case they ever did get compromised or, you know, a broader use case. Maybe Netflix and Zoom are not as good. Well, actually Zoom from a data loss prevention, you can attach files to a Zoom meeting. If you want DLP on that, you know, there's still benefit or merit to add there. But also if it's, you know, let's say it's my Google Drive, you know, lots of malware is hosted on Google Drive. A lot of security companies say, 'Oh, Google, that's a trusted destination, bypass.' We will never say that on our side because again the reality is, you know, there is bad content that gets hosted there.

Yeah, so because of our heritage as a proxy, it's a non-event for us. Because the way we do SSL inspection is not done using the... so what's changing in the industry is there's a lot of third-party devices or things attached on the side of a network on a span or tap port that was trying to inspect encrypted traffic and they were doing so because things like PFS wasn't required to be enabled in TLS prior to 1.3, whereas now it's absolutely required. You can't, 1.3 requires PFS and so that breaks their ability and how they were doing SSL inspection in the past. Because we're a proxy and we're not doing it that way, it's a non-event for us. I think it's just going to further require the need for proxies to be in play to handle 1.3 encrypted traffic because that's where the world is going. It's going to be 100% very soon, if not it already is in many networks already. So I think it's just going to further, it's going to, we already have seen malware shift when they try to exfiltrate data or when they're doing command and control to do so within TLS because they know that so many of the networks are blind to it. And with 1.3, ways that companies were looking at TLS are going to break or not work anymore. And I think it's just going to accelerate that curve.

Yeah, so one of our policy elements is if we cannot decrypt the traffic, do you want to allow or deny it? And so that could categorically block that. Now you can break other protocols, there's pinning of things and you'll maintain a bypass list for that. But that's the first policy element that helps in that equation. The second one is, I wanted to emphasize, you don't have to deploy our cert on the endpoint. We can actually leverage your existing certs. If the company is mature enough, they have existing PKI schemes or frameworks, we actually have the ability for a customer to basically bring their own cert to our service. They basically create us as an intermediary off of their existing PKI scheme. They can make that be very short-lived to mitigate the risks with us. And we have APIs that allows them to rotate that and we'll basically dynamically deliver certs to their users in their chain, not just with our cert, which is how we've been able to deploy SSL for large organizations where you don't even maybe want the risk of trusting a generic Zscaler cert for all your users. So that helps with that equation a little bit. And then last but not least, obviously we're a policy engine, so it's up to the customer to say, do I do SSL decryption all the time? Do I do it only for these categories of sites? Do I not do it when a user is roaming in China and do it when they're in the States? Or, you know, all the different policy elements that you would think are needed are there in our engine.

No, thank you very much. I enjoyed our time. Thank you.

Another piece of information that I think would be interesting to put as part of the publishing for the podcast is the link to the threat research team of yours. Sure. Because that would be very interesting. Yeah, I'll make sure we get that to you. And feel free if you wanted to, I don't know if you guys collaborate on Twitter or have discussions or anything. I'm very active, so feel free to share any content. I'll make sure you include that too.

Yeah, thank you guys. Nice to meet you.