F5, Inc. (FFIV) Earnings Call Transcript & Summary

Hi, everyone. Welcome to today's webinar, Securing Apps in Distributed Environments. My name is Stephanie Kubina, marketing strategist from F5. Before we get started, I want to go over a few basic housekeeping tips. [Operator Instructions] We'll be addressing questions at the end of this presentation, time permitting. Also, you can download various resources in the Resource Engagement widget you see on your screen. You can download today's presentation as well as other resources at any time. At the end of the webinar, a webinar survey will pop up on your screen, and we do appreciate your input, if you can fill in the webinar survey. Also, what's exciting about this platform is we have a field called Attendee Chat. That is meant to be interactive with everybody. So if you can hear me okay, can you let me know what state that you are listening in from? Presenting today, we have Chad Lesley, Senior Manager of Solutions Engineering; and Colin Clauset, Senior Product Marketing Manager from F5. Okay, Colin, I'm going to go ahead and give you control, if you can please get us started. Thank you.

Awesome. Thanks, Stephanie. Like -- as Stephanie said, my name's Colin Clauset. I'm a Senior Product Marketing Manager with F5 focusing on the secure multi-cloud networking solution area, and I'm very happy to have Chas joining me today. I wanted to set the stage a little bit. When we talk about secure multi-cloud networking, part of that solution area is really focused on securing distributed apps across different environments. When we talk about multi-cloud networking with -- sort of in the customer environment, there's a very academic definition of what MCN actually means, what multi-cloud networking means. And that really emphasizes the Layer 3 connectivity between clouds. We here at F5 think that's a very limited view of what a customer environment actually looks like and what customers are actually trying to do. So we've broken it down to 4 different pillars. We've got your Distributed Cloud WAF or distributed app security, which is kind of where we're going to be focusing on today, but you've also got your app tap or service connectivity, which creates connect -- like secure connections between different apps, whether or not they're legacy or modern. You've got your secure networking fabric, which is basically like that Layer 3 connectivity piece and that very academic definition of multi-cloud networking. And then there's also the secure DMZ scalability, and this is our ability to help you kind of scale up your DMZ and make sure that can adjust to customer demand as you need it to. But again, as I said, we're going to focus really today on the Distributed Cloud WAF, which is really securing applications in their local environments in -- with the tools and policies that they need in order to be properly secured. So I'm going to hand it over to Chas to talk a little bit more about the Distributed Cloud platform and what Distributed Cloud Services actually means across F5.

Well, thanks, Colin. And so when we're talking about -- when Colin's talking about secure multi-cloud networking, right, what is F5's strategy in that space? And what tools, what services, what functions are you using? If you're not familiar with F5 Distributed Cloud, it's our SaaS services platform, and it's part of our portfolio, right, that we use to address secure multi-cloud networking, the topic that Colin has introduced us to today and how we do WAF and API security and other security services within that context. And so if you're not familiar with Distributed Cloud, we're going to spend a little bit of time just diving in here real quickly, and then we're going to raise it back up to Colin here in a minute to give us some concepts on what we're doing in this space. And then we'll get into the weeds a little bit, we'll talk about use cases and some other things. But before we get there, let's give you some anchors, right? So when -- if you weren't aware, F5 is a SaaS company, right? We actually operate a SaaS platform. It's a global network, and this platform called F5 Distributed Cloud Services, it's got 4 kind of key pillars or 4 kind of key components that I want to familiarize you with as we talk today. So first and foremost, it is a global private network. There is a -- what we call regional edges. So those are our -- some may refer to them as PoPs. We refer to them as regional edge, the edges of our global network. These are where we advertise services from. But that global network is private. Our regional edges are hosted in Tier 1 facilities, and we deliver service from -- we deliver services from those regional edges, and we interconnect that fabric with our compute resources that we offer in each of those regional edges. We'll look at that in just a moment here. There's a distributed compute stack, which is actually the technology that incorporates a lot of the F5 portfolio products into a SaaS-based consumption model. So the WAF engine, the WAF -- the same WAF engine we run in NGINX, the same WAF that we run in our BIG-IP portfolio sits inside this distributed compute stack as well as our API security services, other security services and it anchors that delivery model at a global scale. It's one of the largest Kubernetes-driven fabric applications globally. The neat thing about that is you can actually run that inside your enterprise as well as a -- what we call a customer edge. So we operate and operate globally. We bring that into our customer edge environment, which we're going to talk about a little bit as we talk about secure multi-cloud networking. It's all API first. So if you've ever played with any of the F5 products, it's -- rest assured that everything we do in this platform is API first, and the console activity is driven by API. And it allows you to do security at the edge, right? We've talked about the security services just a moment ago. So this is really wherever your edge is, right, whether you're national, international, local or locality, whether you're one cloud or multi-cloud, right, it gives you the ability to extend security at the edge of what your enterprise reach is to your customers. So we'll kind of -- we'll speak through here a little bit and we'll raise it back up again here in just a minute, but this is a picture of that global network. And you can see all the interconnections. I won't spend a lot of time here, but I just want to kind of anchor it visually for you. And this is again, like Stephanie mentioned, some collateral that you can take with you. But it shows you that we're aligned to all the major cloud providers. And I should say that this is -- what we're doing in F5 Distributed Cloud is unique to F5, right? We're not trying to be an AWS, an Azure, a GCP, right? Those -- we partner with those environments and we partner with you in those environments, right, in terms of stuff here in the U.S. and for other cloud providers like Alibaba, others globally, right? But we -- but the focus of F5 Distributed Cloud Services is really the things that you come to F5 for in terms of delivery and security of your applications wherever they may be hosted. And so this global network as a SaaS platform environment is critical to allow you to extend across multiple cloud environments and provide consistent security. So that's that key underpinning. And I did mention that compute stack. So I want to kind of come back to that compute stack and mention that this is what it looks like under the covers, right? When we talk about the compute stack that's running in our global network, we were looking at this fabric that you see on the left hand of the screen, right? We have networking components that allow you to appear and privately peer our fabric. There's obviously application delivery controller functionality, all the security services that you're expecting from an F5 portfolio, along with a lot of visibility and durability, a tremendous amount being pulled into a single console that allows you to manage a larger real estate of security across multiple environments, right, your data centers and your cloud environments at the same time. And again, this is all driven by -- managed through an edge framework, a framework that is actually driving our platform, but also a platform that you can consume on-prem as well or in your cloud environment. So we refer to the -- you may hear me slip and refer to these as what we call them in some of the product information as mesh and app stack. We're going to be talking about those here in just a moment. But they're critical to our secure multi-cloud networking strategy because these services can be deployed literally anywhere. They can be deployed in our global network and they can be deployed into your network, be that in public or private cloud. And so that's super critical. So let's take a little bit of a step back, and we'll talk a little bit about the security. And Colin, kind of walk us through -- bring this up a little bit before we go into deep dive about why this is so critical to those that are listening today.

Absolutely. Thanks, Chas. So I really wanted to like kind of anchor us on what we talk about when we say multilevel application security and why application security is important. For us at F5, we really want to make sure that you can create consistent security policies and roll them out to every app across your environment regardless of where they are. And that protection comprise of 3 different tiers: you've got your global services tier, you've got your site services tier and your application services tier. The global services tier really focuses on protection at Layer 3 and 4 against those big broad spectrum DDoS attacks and ensuring standard security policies can be created across every single app that you've got. This also includes a lot of bot and fraud protection and detection and that sort of thing. At the site services tier, that gets a lot more localized and a lot more granular. We really want you to have the control over each individual site to create policies that like maybe build on those standardized security policies that you've got across your entire environment. And then we zoom into the app services tier, and that's where we really get into like the workload-specific controls and making sure that all of your workloads can like have the fine-tuned security that they need in order to be protected in the right ways. And I think our platform across Distributed Cloud is really great at delivering services at all of those tiers. We understand that each different -- each app has different requirements at each different tier, and we offer a platform that helps you orchestrate all of those policies together. You don't have to worry about creating like a new policy for each like point solution that you may have deployed in your environment. You don't have to worry about adjusting it based on which cloud environment you're working in. Everything can be done through the single F5's Distributed Cloud console. And I think that's a really cool differentiator for our platform that like -- that not many -- that no one else really has. So let's dig into a couple more of the components here. So when we talk about modern application security, especially delivered through a SaaS-based platform, there are kind of 5 different key elements that you want to be thinking about. The first one is going beyond like just a web application firewall and thinking about your protection against automation, bots and fraud attacks. You may have point solutions for each of these threat types, but managing each of them creates a lot of overhead and can take a lot of time to roll out the same policies everywhere. A single platform means your point solutions to manage, and that also brings in that modern protection that you need in order to protect against the newer threats out there. You need to have a solution that can scale and deploy to any cloud for any app. Like a lot of customers in a lot of environments are working across a lot of distributed regions, Distributed Cloud providers, on-prem, edge. You name it, it's probably out there. You need to have a way to deploy and enforce these policies across locations wherever your apps are located and aligned to wherever customer traffic is coming from so you can respond to the right security threats at the right time. The third thing you want to make sure about is you've got -- you have a way to securely and efficiently handle increasing like the different requests and traffic that are coming in. In modern environments, a lot of these requests aren't being cached anymore, especially locally. So that's where the need for a global backbone like the F5 global network really comes into play in order to manage and maintain and monitor all that traffic. The fourth thing is making sure that you have a way to simplify the management and policy enforcement and deploy secure apps faster. You need policies that can be built once and deployed anywhere with automation so that your teams can really focus on like defining that policy and going off and taking care of the next challenge as opposed to doing all that maintenance work. All of the major cloud providers, all of the on-prem servers do things differently and so having some orchestration to make sure that you don't have to adjust -- like build out your teams a little bit more or adjust like how things are being done makes it a lot easier for you to monitor those changes and ensure that everything is protected properly. And the final component is an advanced monitoring visualization suite. You need tools to maintain observability across a growing disparate app ecosystem. A lot of these apps are really critical to the running of your businesses, and you need to ensure that you've got the right metrics and the right visualization to understand everything that's going on and make sure that you're like -- your logging systems, your work system, your notifications and your SIEM tools are all able to access the same kinds of data. So those are kind of like the 5 big overall tenets of what you need within an application security platform. Now we're going to dig into a little bit more about what F5's App Security as a Service is going to look like. F5 brings together 4 different like key tools: you've got your API security, you've got your bot defense, you've got your web app firewalls, and you've got your DDoS mitigation tools. At the core of all of this is the web application firewall. This is kind of based on the F5 BIG-IP advanced web application firewall that's deployed through our big appliances, and so we're using kind of the same level of protection. Like we're bringing in some advanced machine learning, which helps identify threats that are outside of what a signature-based engine can find, we've got threat campaigns which allow threat intelligence gathered by F5 to be incorporated into the web application firewall offering that we've got through Distributed Cloud. The idea here is like really ensuring that we are cutting down the number of false positives. We're getting like the most accurate threat data possible and like the WAF is always going to be learning and continuing on that way. Second, we've got our DDoS mitigation capabilities. Like that really focuses on delivering multilayer protection against attacks that are intended to disrupt critical network resources, disrupt your app performance and impact the app performance -- the app experience across Layers 3 through 7. This includes network-level shielding from volumetric DDoS attacks, denial-of-service signatures, service policies that include rate limiting, IP reputation analysis and advanced scrubbing. So it's a really great tool that we've gotten incorporated in there. The third thing we've got is the bot protection. This monitors and deflects malicious automation attacks in order to prevent sophisticated human-emulating attacks, brings together a lot of unified telemetry, network intelligence and AI and machine learning with human analysis to identify and defend against automated threats. And then finally, there's the API security component of this. This safeguards APIs from threat actors attempting to exploit them, trying to facilitate a breach for services outage. We've got an automatic API discovery tool that can identify and map all the API endpoints within your environment, and so you never have to worry about like anything kind of slipping through there. You can easily observe, refine and enforce the right API behavior across every single one. And I think that was a lot of just sort of words getting thrown out there, but really, the key takeaway here is that security nowadays is about going beyond the web application firewall and DDoS protection. There are -- like making sure that you are protected against bots and automation attacks and making sure that your API endpoints are all secured are huge components of this and making sure that your apps in a modern environment are secured. All of that needs to come together to make it easy for all of your teams to protect applications, manage policies and view all the security insights. And that happens across wherever your applications live. They can be on-prem, they can be in the cloud, on the edge locations, anything. So that's kind of the overview of App Security as a Service. Chas, I think our attendees would really benefit from digging into this a little bit more and understanding how the components all work together. So I'm going to hand it over to you and -- but walk us through kind of what security actually means and what it's all going to look like.

Yes. I think you're right, Colin. There's a lot of words that we just used there, and I know -- there's probably -- like you, there's a lot of -- like me, there's a lot of propeller heads on the call, so we want to kind of get in the weeds. And what does this really mean? We give you the tacticals on this. And what are we trying to accomplish, right? As you talked about earlier, we have this -- we had this platform, F5 Distributed Cloud, which is a SaaS service. A lot of the services are -- that you know F5 for are in the platform as a SaaS consumption model. And so -- and then the delivery model of that can be extended. We'll actually walk through a use case here in just a second. But what Colin just mentioned, this is really the flow of security. It doesn't matter if we're delivering it from our global network fabric, right? Think of that as an ADC in the cloud, right, an ADC across all the ADCs, if you will, an application delivery controller. Got to use the full abbreviation there. But this is that flow of security, right? This is the flow of security that we execute as a regional edge in the global network and we can execute as a customer edge within your data centers, within your public cloud, within your private cloud, right? And so when we look at this, right, obviously, if we're looking at the flow of security from the global network, we actually have DDoS hardware sitting in our regional edges that can help mitigate attack. So there is a huge push there, obviously, to use the global fabric to take the benefit of that. We'd still have DDoS in software, so we can do that obviously in the global network as well, but that becomes more of a component within maybe a customer edge deployment, where you're deploying the software inside of a cloud environment and you're controlling your ISP in or on an on-prem data center. But all these other services, right, all these components and they're kind of what we title them in platform and just their underpinning kind of concepts, become layers in security, as Colin just talked about. And this is how it flows through the engine from decrypt to re-encrypt and going to the origin or to your application wherever -- or API wherever may be hosted. It's really important that you -- that the flexibility of what you see here is available to you as a consumer protecting applications because you need to have things that can really identify clients coming in and mitigate those clients coming in like malicious user, being able to typify them, and then use all the telemetry around them to say, before they even start accessing the application, hey, guys, we've seen this behavior over time. Let's block this user, or having great limiting tools. And I won't read every aspect of the slide, but that layered security model allows you in a secured multi-cloud networking strategy to be able to mitigate threats of varying types with strategies, right? Maybe I want to block on TLS fingerprinting, some header component, maybe I want to block on some [ sticky ] component identifying my users and I want to rate limit them or do different things or have the application control or get into some advanced mechanism with our bot defense capabilities where we look at, no, is this a human or this is not a human that's coming to my website, either doing data injection in forms or logging into my portals or any kind of data ingest that's coming into the site. So it's really critical that we have that available to this. And this becomes the flow of security in reality of what Colin was just mentioning in the value of this. So how does this manifest again in the Distributed Cloud from a SaaS standpoint, right? So when we're looking at this, you have those box of services that Colin was presenting in his slide, but you also have the ability to extend those using as a SaaS service in a platform. So think of this as we have a global network that can sit in front of your applications wherever they're hosted, or I could deploy -- you can see those little blue LEGO blocks that you see in the bag around there, or I can deploy that same level of security consistently across public cloud, private cloud, my colo facilities. And all this telemetry, all this detail is coming into a dashboard, a single centralized environment where I can evaluate, manage, mitigate and control and visualize those attacks and understand how my environment is working. I don't have to go to 3, 4 or 5 different tools. Obviously, many of you are using SIEM tools that you can bring back into and that helps you in that journey, but we're talking about actual enforcement here, right? I have the same enforcement sitting in Azure that I have sitting in AWS that I may be having -- as I have on-prem. And that type of consistency that Colin was talking about is really what is really critical in secure multi-cloud networking, being able to understand how effective you are in all those different locations and being able to be consistent, having the assurance that when you deploy a bot defense policy or a WAF policy or an API protection policy on an endpoint in public cloud or on-prem, in that, that resource has to migrate to public cloud that you can actually take that security journey with you and then instantiate that in any cloud environment you deploy it in. And that's really the vision and mission of F5, right, to secure any app anywhere, whether -- and this platform gives us and you the flexibility of being able to do that. So let's just not talk theory. Let's talk actual application use cases. Let's go down another layer, and we'll talk about actual deployments, right? This is a modern manufacturing customer that's using Distributed Cloud today. When we're talking about those components that make up our global network, because we've built it on the fabric that we have, we can also represent that mesh service, there, I used the word, that security stack inside an image, right? So this could be an EC2 image in AWS, it could be an Azure image, right? But that mesh node, that software stack, can run in an ESXi, Hyper-V, KVM environment. If you're running in data centers, they can run in public or private cloud. There's templates, there's Terraform and API workloads that can help build these out. So now if you imagine this customer, their primary requirement was I wanted to have consistent security across my 2 data centers and my 2 cloud providers, my disparate providers, in this case, AWS and Azure. We deployed the customer edge node inside of those environments as a service, right? They're managing all those endpoints through Distributed Cloud console. So all the telemetry, all the enforcement, all the security events, all request logs are coming from those 4 deployments and coming back to that global console so that they can see. SecOps personas can look at the security events. Delivery team members, net ops teams can look at the networking components here. But I'm managing -- notice that the cloud in the middle is grayed out. They're really not proxying to Distributed Cloud. They're just going directly to those environments, and they're managing them as independent points and using DNS load balancing, which is also available in the SaaS platform, to steer the traffic between those different endpoints. But they're managing one single policy across all those different environments, and it's the same policy pushed in the same manner with the same API control. When they build exclusions, those exclusions -- exclusions are overrides of false positives, say, for example. They can deploy them consistently. When they put an IP reputation build or a threat campaign filter, a geo block, they can do that consistently across all those environments with click ops or with an API call, which is awesome, right? Because this is what -- if you've ever run BIG-IPs in multiple environments or tried to synchronize security between -- I have one security platform in cloud and another security platform on-prem, being able to have that level of consistency, operational consistency, makes those 2 and 3, 4 a.m. calls a lot easier, right, in terms of being able to digest data, being able to work agilely and being able to mitigate with controls. And the benefit of this as we break down, right -- so what was the benefit to this particular customer, right? When we look at those things, I kind of called them out, right, uniform security, uniform policy development, having their -- the same strategies for WAF and API and bot be consistent across those environments, being able to have that visibility and being able to be repeatable. What if tomorrow, a new executive came into this company, which -- they're not at risk for that, I don't think, but they say, know what, Google is our new cloud environment. Can I get to -- how can you give me this in Google? Well, just deploy another mesh node in Google and then deploy the configurations that you already have. Done. Now I have another -- I have a third cloud provider, right? So this gave them the ability to be very agile in how they executed security, be it adding another data center, adding another public cloud provider. Fast forward a little bit, right, now their journey is changing a little bit, right? They recognize that maybe they don't want to ingest that data on their ISP links in those different regions. So they can do secure multi-cloud networking here. And this can be done -- I think I should say, it can be done with a single cloud provider, this can be done with multiple cloud providers as is in this use case. But maybe they don't want to take that ingress in those 4 different locations. Maybe they don't want to do DNS load balancing across those different regions, right? There may be a multitude of reasons, or maybe they just need more volumetric capability to mitigate attacks. Well, with a click of a button, they can. And it literally is a click of a button. I'm not digressing there or doing anything nefarious. They literary can change the way that the proxy actually behaves and actually advertise it out to the global network. And now the same configuration that I was running on-premise, at the edge and, say, cloud 1 or cloud 2, can now be extended to our global networks. And now we're absorbing all the L3, L4, all volumetric works, advertising globally on our global network. We're mitigating attacks regionally, right, for -- if the client's coming in from Australia, not to pick on any Australians that may be on the call, if they're coming from Australia, then we're blocking the attack in Australia. We're never letting it get all the way to origin. So giving you, our customers, the ability to extend and flex with how your applications need to be located or delivered is a click away in the platform. I want to advertise this at this site. You're going about that site security model that Colin was talking about this earlier. I want to advertise at this one specific site versus, you know what, this is an external application. I want to advertise it globally. I want to take advantage of the services of Distributed Cloud from a global network perspective. And we're Anycasting that. So all that addressing is one DNS name, one IP address, and we are regionalizing how they get based on BGP advertisers to the global network. Super powerful, super -- whether it's advertised at the regional edges or the customer edges, all consistent in platform. So let's have a look at what that visibility looked like. I'm not going to go through a whole lot of screenshots here, but I want to give you some idea of what you can see and what you'll be able to see when you're reviewing the slides later, right? Being able to have kind of heads up displays on traffic, being able to look at individual metrics in terms of what threat categories are coming in on different things, being able to drive down into events and look at API security elements in the flows and actually have -- these are all screen shots from platform, from environments, right, where you're seeing the actual API flow or web flow of traffic to the various endpoints in an application and being able to see what mitigations, what controls I need to do, what controls I may need to add. What if we're talking in terms of an API, what is discover? What are the discovered endpoints? Do I want to inventory those and take those as a Swagger file or do I -- and do additional security? And what is -- if I import an inventory of a Swagger file, what is outside the boundary of that Swagger file that's being hit, right, so the shadow API endpoints. So being able to provide this very rich contextual data makes my security journey in a multi-cloud world a lot easier. It gives me the context and the confidence, more importantly, to be able to act and do things that I need to do. And when we're digging down into the different mitigation tactics, right, using the different technologies of security available in Distributed Cloud through F5's portfolio of security services. Things like -- we've talked about API protection just now, we've talked about bot security, malicious user protection, being able to take a client -- identify a client through identification mechanisms and then track that user's -- that identity's behavior across rate limiting, across access to web applications, across security event data and being able to surface that data and use it as a really strong mitigation mechanism at the beginning of your application flow, right? Going back to that other slide, being able to use that and saying, if I see the fingerprint come in, this calculated fingerprint that I have built to identify this user, I just want to drop it. I want to -- or I want to put him in a penalty box or I want to put a JavaScript on it, right? I want to be able to do that. That's a hugely powerful thing that I can then look at more granular controls, if I can use that word, like WAF policies, maybe API-specific policies, maybe bot defense policies to really get focused and strategic on security. This is what's really important when we're looking at security across an ecosystem of applications, across an ecosystem of deployment models and being able to be consistent, right, and be -- and have that be cohesive across those environments. This also extends to visualizations on those DDoS attacks, right? So when I see something that is in -- this is -- this actually renders and plays when you see the PowerPoint presentation [indiscernible] you won't be able to see it moving, but it does move, right? We're actually showing the attacks in dashboard as they -- that are happening and being able to control those. So a lot of services, a lot of detail here. So the point of those diving into that use case was, one, to show you really a tactical application that has been deployed in one manner that can be pivoted to another manner very quickly without heavy retooling. I'm taking my security journey with me wherever I am going to make it consistent and having the multitude of security services within platform and the visualizations to boot, right? You can still log stream all the event logs, security logs to the SIEM tools and pipeline them into your existing ecosystems of security services and SoC operations, but in platform, we're giving you advanced analytics and some forensic tools to look at your traffic to make sure as you're trying to achieve security in this kind of ever-evolving multi-cloud, modern world where your applications are multi-parted across different environments, to give you some level of assurance and consistency on how they're being delivered and how they're being secured. So with that, Colin, I think I'll kick it back to you and talk about how this overall simplifies everything.

Well, thanks, Chas. Yes, this really all just brings everything together. You've got your global network in the middle of it. You can connect any kind of public cloud, SaaS provider, branch, private cloud or any other -- like any other public cloud instance into the same kind of big network and really kind of simplify that app-to-app connectivity, the app-to-app security, call it North-South and East-West traffic. I think I wanted to leave you all with a couple of key takeaways here and key differentiators for how F5 stands apart and why we think this is a great platform. Number one is the proven security efficacy. Like we've got a lot of great app security technologies like web application firewalls, bot and fraud protection, API security, all that delivered through a single SaaS platform. That helps increase agility, help unify management and really make sure that everything can be consistent. You've got your deployability anywhere. Backed up by the global private -- the global F5 network and purpose-built for multi-cloud environments, these security solutions can go to any environment that you need them to. Anywhere your apps are deployed, you can deploy those same security solutions wherever you need them to be. And finally, there's a common platform for all of these tools. Not only do you get the web application and API protection solution suite, you've also got the ability to like enable a service match and connect your modern legacy applications wherever they're located, create a single network fabric across any cloud, on-prem or edge site and really take advantage of the ability to scale up your DMZ. All of that is available through secure multi-cloud networking and through the F5 Distributed Cloud platform. So with that, I want to say thank you all for joining us today. And I would love -- Chas and I would love to answer any questions that you might have. Stephanie, if you want to hop back on, let us know if there are any questions that you wanted to bring up for us today.

Yes. This is my favorite part, questions. And one question I'm seeing, Chas, I think you could address this one, is -- are the Anycast source data centers controlled by the customer?

So it's a great question. So Anycast, when we're talking about global networking, right, usually, ISPs and net service providers, by standard, we always advertise at /24, right? We're Anycasting addresses. Obviously, there's address space that's been allocated to Distributed Cloud that we're Anycasting those addresses globally. In the deployment models for Distributed Cloud, we're going to Anycast the addresses, but I think the root of the question is more along the lines of where does the proxy behavior occur or where does decryption occur. And to the question, yes, you can't -- we don't control the Anycast advertisement because we still are subject to the rules of the Internet, if you will. But you can control which regional edges the proxy occurs at within Distributed Cloud. So they're called advertised policies. Every -- in Distributed Cloud, you get allocated to a tenant. That tenant gets a default tenant IP address that's used for the Anycast. You can associate additional public IP addresses that you can lease from platform like EIPs, for example, or you can bring your own /24 that we can Anycast out. But in the advertised policy, you can say -- apologies, I'm getting a little winded here. You can pick which regional edges you advertise out of. Obviously, you want to advertise out of more than one for redundancy purposes. But yes, you can control that part of the journey.

Okay. Thank you. Okay. Another question. How can we integrate Distributed Cloud WAF with other F5 technologies like BIG-IP?

Great question. So when we're looking at Distributed Cloud, understand that F5 has a large portfolio of products. If you're not familiar with BIG-IP, it's one of our portfolio products. And we can run BIG-IP as visualizations in public cloud or on-premises, right? And what we do with Distributed Cloud for existing BIG-IP customers is that maybe I need -- maybe I have BIG-IPs deployed in my data center, maybe I have BIG-IPs deployed in public cloud. And I'm providing a lot of security -- local security controls, tactical control there. But I really want to have some extended services, right, that I need to do more DDoS-level services in front of those environments, where I want to cut down the noise coming into those environments directly. Because I may need to have -- there's different teams watching them, and I have to have different tactical controls because I'm maybe doing more programmatic things with iRules in WAF in those platforms, and it's more respective to that kind of site security versus a global security model, going back to those tiers of security services that Colin was talking about. So we do have customers that will layer, right? They'll layer WAFed out ads at the edge and then maybe use BIG-IP, LTM and maybe some WAF policies or even NGINX behind the scenes to address that layered security model. So we've seen those layered security models happen, and it gives a lot more fluidity, if you will, to the deployment model. There are -- I guess I should hint at the fact that, yes, F5 is working to bring that BIG-IP portfolio and the Distributed Cloud portfolio together as well so you have a more cohesive management or visibility, at least initially, of those resources. And that's evolving in the road map. But we do see today customers doing layered design with security, and it's really effective in terms of blocking a lot of noise at the edge and then doing more discrete last-mile controls with either NGINX or BIG-IP in an environment, depending on the environment and application, obviously.

Okay. Thank you. So not to forget, I was looking at Attendee Chat, and someone made a comment. We have not been able to successfully use Bot Defense in Silverline due to the nature of how it works. Do you have any comments to that?

Yes. So that's a great question. And so for those who are not familiar with Bot Defense, Bot Defense is our automation tool for detecting human or nonhuman behavior, right, in terms of application access. It's highly accurate in terms of detection mitigations, and there are different strategies for implementation. There is a JavaScript that gets delivered to the client that collects signal sets that allows us -- and no signal sets get sent in with the request, that allows us to evaluate the signal sets and say, well, is this human or not. Depending on deployment models, and I think I know [ Wayne ] pretty well. is that depending on how it's implemented, we can either do this through an iApp on BIG-IPs, we can do it in the application through actually adding those JS tags in the implication or we can deliver it. It becomes an in-line model, right? It's actually in the flow of how that is delivered. In Distributed Cloud, we actually use an API mode for the standard protection services. So it actually gives a little bit more flexibility in how we view that, how we view the injection and a little bit more control of the behavior because it's an API call versus an in-line flow to the decision-making process. So it would be worth, I think, looking at that. But it depends on the application, right? It depends on how the application is controlling different services within its page and the correct operation. But that's something that we can dive into a little bit more. But in Distributed Cloud, we're using the same service, we're using API mode connectors. We can do in-line mode as well. But it just gives us a little bit more fluidity on the option models for deployment.