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

All right. I got top of the hour. I'll give everyone another minute or 2 to jump in.

I just got a note from somebody that is going to reconnect from a different computer. So he'll be joining back momentarily.

Oh, okay. Great.

Yes, we'll give him a moment for him to -- that was Mike.

Oh, no worries. Lots of time.

Yes.

There's Mike. All right. I think we're 2 after. I think it's -- get started. Yes. I'll turn on my video temporarily. I'll turn it off when we start in these labs. Good morning, everyone. There's Lyle. Good morning, Lyle. All right. Well, I'll go ahead and kick it off. Thank you, everybody, who has joined on your busy morning or afternoon to the SLED Test Drive Lab Series. This is -- we're going over F5 Distributed Cloud, the WAF and WAAP deployment, so just a deeper dive. So we'll actually dig into some configuration. We welcome questions and comments just as far as how to protect different things or how this might correlate with e-WAAP policies that you guys might all be running as BIG-IP customers. By all means, I really enjoy a conversational meeting. So if you guys just want to raise your hand and have a comment, please do. If not, that's okay, too. Both Reed and I will be monitoring the chat when we kind of tag team the presentation. So by all means, feel free to chat away within the chat. And I guess I'll introduce myself. I've been with F5 for just about 2 years. Previous to F5, I worked for a financial services institution. And then I also worked for state government, my home state in Washington State. I have been an F5 customer for nearly a decade before joining F5. So I'm very familiar with the product from both sides of the table now. And most of my background has mostly been cybersecurity. I've worked nearly every role in cybersecurity besides C level. And yes, that's my passion. I love it. So -- and [ AppSec ] is definitely the new avenue as commonly said, the new edge of security. So I think with that, I'll pass it over to my colleague, Reed. Go ahead, Reed. Oh, can't hear you. Double mute.

Here we go. How is that?

Yes, that's great.

All right. Very good. The lighting in my hotel room here is kind of subpar. So hopefully, doesn't make me look too orange. But I hope everyone is doing all right. Thanks for joining us today. Exciting topic that we always love to talk about, which is our Distributed Cloud Services, specifically with a security slant to today's conversation. Look forward to working with you guys. I'm an SCE with F5, based in the Southeast based in Tampa, been with the company for 11 years. And as Krista said, feel free to ask questions. We'd love to make it interactive. I want to make sure that you guys get quite a bit out of this session today. So look forward to it.

Nice. Thanks, Reed. Appreciate it. And oh, and he brought up a good point I didn't touch on. I cover the Pacific Northwest and Alaska region. So I saw that -- I don't know if everyone made it from the Colorado team, judicial team, but we have chatted in the past. So hello out there in Colorado. All right. So with that, let me share my screen. We'll jump in. Great. All right. So where we are in, we just did interest. I won't bore you with that page. Let me go ahead and tap [indiscernible] to you. All right. So this is the lab guide. There's going to be a few opportunities to click this link by -- for anybody who wants to jump ahead and start looking at the lab guide, by all means, feel free. Just for awareness, we're probably going to spend a good 20 minutes on getting you guys into the lab because probably actually setting up and deploying distributed cloud WAF in distributed cloud is very easy. Getting into the lab will probably be more of the struggle today, which is a good thing, right? So this is the survey. By all means, we appreciate all the feedback, good or bad, that we get from customers on these so that we can continue to improve. So there's a survey link. I'll also have it up at the end of the presentation, too, if you don't want to grab it right this second.

I just dropped it in the chat also. So that way, just click on it from there. There's a question in chat. Krista, do you know if this is going to be recorded? Or do we already have a recording of this that we'll be able to share? I don't know. Lyle, do you know off-hand?

Yes -- yes, I just responded to that. We will not be recording it. But kind of what we've been telling everyone throughout this whole series for the last few months is -- it's no problem at all if you'd like to run through this lab yourself or if you have other colleagues at your agency or whatever, you can just reach out to your account team and they can spin it up for you. And you can work on it at your own pace if that works better for you.

All right. Thanks, Lyle. And I would like to what Lyle said that the account team, it's very easy to spin these up and then your team can work out at your guys' leisure, right? So you might have guys who want to work on a Friday afternoon during no change Friday, right? This is -- we'll be happy to do that and get you in touch with the account team as well. So all right. So hopefully, everybody has received this e-mail. This is the e-mail that comes from the F5 lab environment, which we call UDF. If you have it, that's okay. Please, in the chat, let us know, and I'm going to do the talking. So I'm going to let Reed do his best to manage all that, and we can get this sent to you right away. But I thought -- I think I captured everybody. So hopefully, you have this e-mail. If you haven't done anything yet, great because we'll walk through it. If you've already done some stuff, no problem. We're going to go ahead and do it. But the problem you see now is it's a little busy. But truly, we needed to click this third link that you have -- that we have here on the -- on your e-mail. So if you're following along now, wonderful. Go ahead and do that. Questions, please raise your hand. Go ahead and keep going on. So when you do click through that link, it's going to ask welcome to the lab environment. You're invited user. And then at this point, you're actually not going -- you're going to actually register in, okay? So you'll be a selected user. You can enter your username and password if you are a returning user. So if you did Agility, for example, a few months ago, you probably have already registered within this environment. And you're welcome to go ahead and do that. If you hadn't -- if you did Agility and you're like I don't know my password, just click forget password. Go ahead and go next. So this is the forgot password experience. So if you did forget your password, it's going to send it to the e-mail that you registered for the lab too, and then it's a going to send you a code and then kind of just do kind of like typical e-mail MFA. And then after you've reset your password, you'll be redirected back to sign in. And then off you go into the UDF. Something that's new into our lab environment and that is using MFA. So I believe it also applies to older users as well. This particular screenshot was with a new user. But basically, you have to like authenticate your e-mail to try to prove who you are, right? So this is kind of the steps that you'd be taken through. And definitely, if you were a new registrant, you would go through. You would click send me the code. It's going to send your e-mail a code to then enter into the UDF framework. And then from there, it will take you to the course that you've registered for, which is today. And it would be the F5 Test Drive Lab and then you will click launch, I can't see the screenshots here. You have everyone just a second to breathe and catch up here if you've been following along.

Does anybody have any questions so far? Does this kind of jive with what you've seen during your login process, hopefully? It's several steps to get logged in. So we just kind of want to make sure that everyone gets through this. Great. Thank you.

Yes. Thank you. It's really important to us to make sure that you do get on. So don't be shy. All right. So hopefully, you've gone through the UDF. That's just one piece to actually register or finish registration into the class. Now you have been taken into the session, you're going to click join. There's one piece that I wanted to highlight. Here now is a clickable link to go into the lab guide for what we're doing today. And in this messaging here, you can kind of see down here where I labeled #1 that you actually want to hit the second one. Unfortunately, the [ carriage ] return did not show up as we would have liked to in the web rendering, but it's there, the link is right. So please click this WAF, WAAP deeper dive lab guide down here, not the first one. I mean, you can do the first one, but we'll be talking about something else. Once you go ahead and you got your lab guide kind of set up on a different browser window or however you'd like to manage that, go ahead then and click join. So clicking join is -- will take you kind of to an interesting page. The first page you will get dumped into is this documentation page right in here. Don't panic. That's actually a good thing. What's basically happening behind the scenes is we're actually creating an AWS user for yourself to then access our distributed cloud platform. So what I'd like you to do is -- the first step is just to go ahead and click the deployment. And so during the deployment, you should be actually seeing some gears -- some yellow gear spinning. And basically, all of like the automation magic is happening behind the scenes. And when you get to the green arrows, that's when you know that your user in a distributed cloud has been created successfully. So -- and it takes about 1 or 2 minutes. So when I get done talking here, I'm going to give us about 2 minutes to make sure everyone is caught up in that. For the most part, everybody's lab environment has spun up. Once you have the green arrows there, go ahead then and switch back to the documentation page here, and then we're going to have you click into your tenant -- in that distributed cloud tenant. And then -- and once again, there's one last opportunity to click that lab guide in case you missed it in the previous screen. All right. With that here, I'm going to kind of pause and take a look in chat to see if anything Reed hasn't already grabbed and give everyone about a minute catch up here.

Yes. Might be easier pulling a chat and try to find it in there. So I just put it in there as a redundant way to find it.

Thanks, Eric. Yes, it takes a few minutes. So the client wheel -- that's a good thing. So we'll -- let's let it get to green. If you don't mind, let us know when it does get to green just so I can get kind of an idea where most people are at.

Is there anybody that hasn't yet gotten to the point where you see the gears turning, anybody stuck at any point up to that point? If the gears are turning you're good, just we'll give it a minute and just takes a couple of minutes to get it spun up.

My arrows are green, but when I click on the lab link, you've asked me to log in and gives me an invalid username, password.

Okay. Hang in there, Mike.

Okay. Not quite ready yet. I'm jumping the gun.

You're jumping the gun, but you're in a good place.

Okay. Thanks.

Yes, you're welcome. All right. I'm going to give it 30 more seconds. We'll jump ahead and catch up to Mike. So now this is hopefully where Mike is and where most of you are now. Once you click that link, that went into the F5 [indiscernible] tenant, what we call tenant. You should have your e-mail that you're registered for, yes, and it's probably going to give you some sort of like this is an unfamiliar user. So what has happened in the background is that we have created a user with the e-mail you're registered with, but now you need to reset that password, right? We're not going to send you a password. We want you to create your own. So go ahead and click forgot password enter in the e-mail that you use for registration. That's key, not a different e-mail but definitely the e-mail that you registered through UDF and where we kicked off all the automation and then go ahead and click submit. And then you should then get a prompt here that's saying that your password has been updated and that an e-mail basically saying to go ahead and change your password and go through those steps. The next -- yes, then you'll get an update password, and then that your account has been updated. One piece to know, it seemed pretty snappy this morning when I ran through the lab this morning with a test user. Sometimes it takes a minute or 2 to get your e-mail from distributed cloud for reset password. So if you didn't get it right away, not a problem. But if you don't get it in the next minute or 2, please let us know in the chat. I'll stop here just a second just to make sure everyone can run through that forgot password process because that is a process everyone will need to do. How's everyone doing? Has everyone gotten all the way to this point where you can log in and get to work and reset the password? If we could get a show of hands, that would be great. All right. I'm going to give it 1 more minute. All right. I'm going to keep going forward. Mike, I think we're catching up to you. [indiscernible] identify yourself screen. So oh, yes, I know what you're talking about. All right. Mike's jumped ahead. That's great. That means he's in. So the next part here is please enter in the tenant, very similar to public cloud. And we can talk about role-based access here in a sec, but you have a tenant which would be assigned to your organization. And then within tenants, we have what's called name spaces. And then in name space, you can carve out role-based access based on application, group, et cetera. But you're going to be logging in to your tenant and the tenant today is F5-XE-lab-SEC. So with that mouthful, please enter that in. Enter in your e-mail in the password that hopefully you reset successfully. And then off you go. You will review and accept our terms. You're welcome to read those. I won't cover those now, but if you have questions, let us know . And here, this isn't a huge deal because we can get to you -- you'll be able to see everything as we walk through things. But go ahead and click all of the check boxes. There will be some limited access today based on your lab account, just FYI. So if you go to click on something, you really -- you can't edit a thing, and you're curious about it, feel free to ask. We are advanced users today. So please click advanced. And then from here, there is a walk-through as far as kind of click through kind of like a widget assistant. You're welcome to click through that. I think right now, it's probably 3 or 4 clicks. You're welcome to do that. And then from here, just to -- basically, at this point now, we are going to grab what's called the name space. And so each user of this lab will be assigned their own name space. So we're going to go and search for that. There's a few ways of doing it, but this is the way I'll show you here and then if anyone struggles finding it, I will help you out. So we're going to go ahead, you're going to click this upper-right icon, which is your user icon pretty common. Go to account settings. And then when you go to account settings, go ahead, and I believe it's going to have you select -- you're going to go to a multi-cloud app connect. Pardon me, I don't know if I did a very good job of highlighting that when I grabbed this screenshot. But you're going to select the service, and then the service you're going to select is multi-cloud app connect. So ahead and do that. And then we get there, there's not going to be anything set up, but that's okay. We're actually looking for this piece in the URL. And I'm sorry, it's really hard to see it in this particular screenshot, but you're going to see the full URL. It's going to say slash name space slash some unique attributes. Mine yesterday was grand-kid or this morning, it was kodiak-bear. So you're going to find something, we try to make it a little funny, some sort of funny URL parameter or attribute that you're going to grab. And that would be your name space. if anyone has any issues finding that, by all means, please raise your hand, and we'll help you get to it. So once you get that, just take note of that, we're going to use that throughout the lab today. That's important to -- basically, we'll be referencing your name space. And then after that, we're just going to check DNS management and making sure that domain delegation has occurred within your name space. So you're going to go ahead and go to select service going to DNS management. You're going to go into delegated domain management. And then here, you're going to see labset-f5demos.com. You'll see the associated name servers for distributed cloud. Those are our 4 main name servers. And this is another piece that's helpful to kind of either write down or screenshot because we'll be actually leveraging this domain. We'll be appending subdomain to this so that we can use this basically website for testing. And then after you've found that and that you feel that the -- you've captured all the DNS stuff, you're welcome then -- we're basically ready to rock. So you're welcome to actually come back -- let's see -- let me back up. You can go back to the main screen. I don't have a screenshot here, but you can click the F5, and it'll take you back to this main screen with all the widgets or you're welcome to go ahead and click into multi-cloud app-connect. That's actually where the first lab starts. And you can go to the site map or go into performance dashboard, whatever you'd like to get started. And well, it's a step-by-step process in the lab that we'll guide you correctly through. Basically, you'll go into manage -- into load balancer and you're going to create your first load balancer. And with that, I'm going to stop talking. I'll take a look in the chat and let everyone catch up and make sure everyone's got their name space, was comfortable and was able to see the delegated domain to the lab demo site and see if there's any other questions. And thank you for your patience, everyone walking through this. I've given this talk, this webinar and lab a few times. And like I said, getting into the lab is -- it's just -- there's a lot of steps to it just because there's a lot of different platforms that are working. And we want to set up these really cool [indiscernible] environments for you guys to do all the testing you want. So just takes a minute, but it's worth the 20 minutes to spend on it to make sure everyone's got access. And again, by all means, don't be shy. Feel free to speak up if you're having any issues. This could be the most successful lab logging in group.

I was about to say that went very smooth.

Kudos to this group. Kudos.

It looks like a lot of them have already taken the preceding labs. So this is second nature.

Touche, touche. You're dismissing or you're diminishing their light, Lyle. All right, I'm going to give it 30 more seconds, and we'll go ahead and jump into this. And by all means, if you're still kind of catching up, the first few slides are kind of just going over general concepts that you probably have already gone through. Just kind of dusting off the old topics, and then feel free in the chat ping any of us and we'll help you out. Okay. You guys have probably already seen the slide here, but this is just kind of talking through, obviously, the overall sprawl that we've all dealt with at some point in our career or dealing with now. But just overall, like where applications deployed, where does security need to be deployed and who is accessing different environments, right? And so this has been just a huge issue throughout any environment I've worked through in like the big push to figure out how to cover public clouds, your on-prem environment, and then any other third-party apps that you might actually have going on, how are you able to secure these? How are we able to monitor the different types of access to them? So this is F5's ability to mitigate this risk, start improving that risk posture of moving into different environments because as things have changed in the last 5 to 10 years, not everybody is in public cloud. I don't think anybody will be all in with public cloud. I mean, there's the exceptions, but for the most part, most of us work in some sort of hybrid environment. And so that's where distributed cloud shines is that we're able to operate in our own infrastructure, our own edge to cover all of these different environments across the Internet. So the struggle is real. This is one of my favorite slides because we all joined our organization at some point in our career where we have the primary and secondary data center, all was well. And that all -- that seemed like a lot of work in its own right. But over time, we had different use cases and reasons to move into the public clouds, whether that was for disaster recovery, that's where different APIs were available that we needed to leverage, et cetera. So those interconnections in that networking need to exist. And again, now there's different gateways and opportunities to then access potentially your company's data or environments, and now we need to protect those. And then let's not forget, most of us don't just work in a single building, but potentially tens or hundreds of buildings across either the country, the globe, et cetera, where you need to interconnect all these remote sites. Remote sites might be hosting different resources that you do need for your applications. Partners are my favorite. Everybody has to leverage a third-party partner for whatever reason, right? Coming from the financial services industry, most recently, we would have partners that did like some of the mortgage servicing that we didn't want to do in-house. So those were all more APIs we needed to figure out to communicate with applications that we hosted mostly in our primary data center, but some other pieces of it in the public cloud. And then we have not just -- obviously just hosting the application, but we have our end users, we have clients, maybe we have APIs that we need to provide out to other people. And let's not forget ourselves, right? So beyond, obviously, providing the application out to our customers, we need to access them, and we need to access all of these different environments. So it's a huge job, right? And the distributed cloud platform is going to help us start streamlining some of these things, maybe taking away some of the pieces of actual hardware or virtual hardware that needs to be installed and then just using a SaaS platform just to cut down on the complexity. And so just talking to that point with that centralized control, I'll talk here just in the next slide on like how we do deploy the F5 infrastructure, but we're able to then effectively allow folks both your end user and your administrative users to then access distributed cloud, provide the application to your end user seamlessly. They have no idea how many possible resources and locations of those resources may exist, and we're able to integrate within CICD pipelines. We're able to then provide that security piece, which we're talking about specifically today on to those applications regardless of where they're located. Oh, and let's not forget, and we'll talk about this at the end, and we don't talk in a ton of detail on it, but I'll be happy to go down the rabbit hole with you if there's any more questions. We do integrate with SIM platforms, and you're able to pull the logging of distributed cloud and the security events out of our systems into your SIM environments, whatever those might be. So the key building blocks of distributed cloud. Today, we're truly just beating the drum on application security. So it's going to feel very heavy-handed in the WAF discussion today. I don't want to take away, though, from some of the other things you might have already heard about through other test drive labs or see some other test drive labs coming up. Just touching quickly on the networking piece. We do have an absolutely fascinating way how we're able to do multi-cloud networking using what we call customer edges that definitely deserves a listen. So something to think about that's being able to extend distributed cloud services into more locally into your environment, so there's use cases for that. For example, you want to do some internal load balancing within your network that's not actually on the Internet edge to not talk to one of our regional edges. We can extend distributed cloud into your internal network using what's called a customer edge. So that's a networking piece that's very valuable, highly recommend listening to that at another test drive that's available to you. On the right here, we have the application delivery component. So we do offer like Kubernetes as a service platform. So you're able to host your site at F5 distributed cloud. So bringing your site closer to your customer, there's an entire gamut of things. It's really cool. If we do end up -- if I show you a few dashboards from our demo site, that's kind of what the F5 SCs use. That's a site that's completely hosted on our Kubernetes platform in distributed cloud. So it's not leveraging AWS or Azure for that service. It's F5 service. So there is also that piece to distributed cloud that we won't talk about today. But just to kind of keep it on your radar, it is out there and available. Oh, into the map. Honestly, I think this map could be outdated. We are -- this infrastructure that you're seeing here, these are what we call REs, regional services. As you're probably familiar with POPs, we don't like to call them POPs necessarily because typically, a point of presence is just like a relay of another main data center services so like a POP within AWS, it's just like relaying the service to a closer presence to whatever your app might be or that data center. We're a regional edge in distributed cloud is actually hosting the service. So each one of these yellow dots on this map is an actual origin of the Distributed Cloud Services. And the point of that is just to reduce latency, right, to be able to provide the Distributed Cloud Services to you, not as a relay, but actually an origin of that service anywhere in the world. So here, we're looking at 24 regional edges. And this is an F5 infrastructure that is completely owned by F5, owned and managed by F5, which I know our government customers really like this is using at any [ CAS ] network. So we're able to route if you so want. If you have a user in North Africa, and you need to provide that service to them, they're going to hit that Madrid RE, right, even though maybe a fewer services are actually hosting in Seattle. So we're able to route the customers as quickly as we can or end users, excuse me, as quickly as we can to our distributed cloud and provide the application to them with as little latency as possible. And I didn't check this morning, Reed might know. I believe we are still in the top 10 for BGP peering in both IPV4 and IPV6.

I will check. If we're not #10, we might be #11.

Okay.

Yes. But we're definitely in there, for sure.

I'd just like to throw that out there. I know it doesn't mean too much. But I just -- to me, I was pretty impressed that we have been top 10 in that BGP peering [indiscernible]. It just shows like the robustness of what F5 is investing into distributed cloud. And folks who have been long time F5 customers, which -- thank you. This isn't just like another byproduct or some other new thing F5's investing in. Like we are heavily investing into distributed cloud. We absolutely believe this is the future of the company.

Yes, we are in the top 10 for both V4 and V6. I'll paste the link into chat, so everyone can see that.

Nice. Yes. Thank you. Before I move on to going in the weeds with WAAP and WAF, are there any questions to the architecture or just the kind of overall distributed cloud deployment? All right. Silence is compliance. No, I'm kidding. So if you have a question down the road, by all means, please ask. All right. I really, really enjoy this slide here because let me back up real quick. I just want to make sure my animation was working because this is talking through, which was always very important to me. What are the actual layers? What is the actual technology being triggered when a user is accessing the site, right? Like when is SSL encryption happening? When is it re-encrypted to be sent out? Like how is the proxy working? And I really enjoy this slide because it's going to show here, and we're going to -- I'll touch on the pieces we're going to cover today on when the specific F5 technology kicks in. First thing, I'll back up a step. Distributed cloud WAF and WAAP protection, it's not just a WAF. You're not just buying a WAF with signatures that are kind of reactive, right? Signatures are things that have to be developed after an attack or a threat has been identified. It's an entire package of things, right? And it's an entire strategy of deploying application security for your application. So even though we're going to touch on WAF here. And just in this particular lab right here, know that when a user does hit the distributed cloud proxy, you're first going to hit like a layer 3 and 4 DDoS protection if you had -- if you so have that enabled. You can have that enabled specifically for your tenant. But overall, F5, you kind of get a double dip here, which is great because, obviously, F5 is going to protect our own infrastructure, right? So you get the benefits of F5 that now batten down the DDoS bad guys to protect our own environment. So that's kind of a nice like residual effect from that. And then from there, we're able to do the ACLs, right, layer 3, networking and stuff. And then the fun stuff -- and then the fun part starts, right? That's when we do the SSL decryption, if you so choose that allow us to decrypt your traffic. And then we're able to inject technologies such as malicious user, which we'll touch more on, really great technology because that is a more proactive technology, where you're using machine learning and AI to actually baseline traffic. And then they're not even necessarily block the traffic outright, but to actually monitor it and then even potentially do more of a quality of service delivery to the user. Maybe we tell a bad guy that's been identified by malicious user like, okay, you can't use a site for 20 minutes to see if the IP rolls and then moves on, it becomes a legitimate IP. It's a really great technology that you'll see here throughout this course that it's been very effective in attacks that we have seen. And then we move into service policies. We will also cover that today. And that's all the goodness that many folks are probably aware of from deploying WAF, for managing WAF, deploying where you get the IP reputation, geo-filtering, [ TLS ] filtering, et cetera. All of this goodness occurring here in service policies. And the service policies for distributed cloud is incredibly configurable. So on top of the things, you can configure specifically for security. You can do more with that as far as with like routing and different sort of injection. So if you really started going down the path of distributed cloud and moving more [ traffic ] in distributed cloud, service policy becomes your friend. Beyond the service policies, you would get into our bot defense, and the bot defenses are AI-driven bot protection. So within the WAF, and you'll see that today, you're going to have bot protection, which is our signature-based bot protection, sorry, overuse of the word. The bot defense is actually if folks had uses [indiscernible], we had acquired a company now close to 4 or 5 years ago called Shape Security. Shape Security was just incredible at being able to identify correctly key and back down malicious bot actors and campaigns. And so F5 acquired them, rebranded into distributed cloud, and that is where that technology takes place. This is a separate license to the base package of the security package that you would get with distributed cloud, but it is available, extremely effective. I was previously a customer of this technology, and it worked well. But right now, for the lab and what I'm going to talk to here in the next 5, 10 minutes, we're going to talk through the WAF deployment, how that works, threat campaigns how you turn that on, not hard. And let's get started. Too far, okay, great. Talking through that stack, this is -- we couldn't actually write here on the lab, but this is actually a breakdown of an attack that happened on NGINX.com. As most folks know, F5 now owns NGINX. And on NGINX.com, I believe this happened earlier last year. We had significant attack. I don't want to call it a DDoS attack because it's more sophisticated than just a bunch of traffic. And it was interesting because you can see here where that malicious user piece, leveraging TLS fingerprinting, really batted down more of the attack and where the application firewall did take down some of the attack, but maybe not all of it because so much of that machine learning and AI had backed down that traffic. Now how do the customers say this, like, well, then why have a Web Application Firewall -- like all these other technologies engaged. I think it's important to note that not every attack's the same. Some attacks are different, right? So if we have a particular attack that was able to work around the malicious user filtering, that doesn't engage right away, but it was -- we already had a signature in place to back down like a spring framework attack or sort of Strut. I always love to pick on Struts, Struts attack. The WAF is going to be able to back that down. And it just goes back to the old paradigm that we always love the same security, defense and depth always security and layers. And so I really like to show this and just again talk through how each one of these components will go through today in the lab really kind of sets us up for an overall security strategy. It's not just setting up one technology. So specific to the WAF, so we're now changing focus. We're going to talk very specific to the Web Application Firewall. Both now in distributed cloud, that's even a little different from AWAF. We have the signature-based identification, the same signature as you get in AWAF or folks maybe on the line here, maybe have Silverline deployed. Those same signatures are also ported over into distributed cloud. So you would have that very large R&D base of signature base. In addition to that, distributed cloud gives you is that we do also have behavior-based technology associated to the firewall itself to help recognize malicious attacks and identify those quickly in a dashboard that will actually talk to through the lab. There's a forensics tab on the right, upper right, as we start doing some attacks and stuff that you're able to pull out. And through the technology of like behavior-based identification, start picking up malicious actors quickly. And then you're able to then block either block IP, user agent, et cetera, based on that type of identification. Just talking through, these are just some of the high points to what WAF offers, the signatures that I just talked to, IP reputation's included in this, the advanced client behavior technology, again, using more of that machine learning piece, bot protection. Again, the bot protection in this particular module is a signature-based one, but it's effective as folks with AWAF, and I did, too, had turned on, and it was effective at batting down known bad actors. And I think the really nice point to it, and I encourage everyone to kind of -- when you finish the lab and we're still waiting on others to kind of click through the visibility and go to tuning because when you do start generating logs, you're able to pick a log and then make a decision based on that single log, which is really nice. You don't have to basically change windows. So the pieces here that I want to touch to and you'll see through the lab, the first thing is first, you're going to create the HTTP load balancer. To my former F5 administrators out there, this is effectively your virtual server. So the HTTP load balancer is what's going to advertise your site where you want it to be. Whether that's the Internet, whether that's internally, this is your proxy. I don't love how it's named, but it's the HTTP load balancer, it's effectively your application proxy that's here. It's important to configure this first because then we then associate a WAF policy to an HTTP load balancer. I don't know if it's in the documentation clear, but you can associate a WAF per load balancer or you can associate a WAF policy across your environment. It can be a shared object. You can do it based on a route. It's very flexible. So -- and you'll see that throughout the platform that things are very modularized, so that you're able to basically reuse objects and not recreate the wheel. Application firewall. These are going to be some things you're going to see in your dashboard. You probably won't see this many violations because you're spinning up an application, just doing a few things very quickly here in these next 2 hours, but I'll be on standby. Reed and I talked about it. Maybe I'll be able to have time and I'll show you some of the kind of full dashboards that we have all set up from other testing on F5 tenants. These are some of the dashboard. So this dashboard over here on the left probably looks pretty familiar to you. This is when you logged in. This is the widgets that you could easily click in to see. And then these are some of the dashboards that you would be able to see kind of clicking from the HTTP load balancer into where they're seeing from an application perspective and what you're seeing from a security perspective. And with that, I'll stop for questions and what you lose on the first lab -- before I open up for questions, I think we're just going to -- I give you guys about 10, 15 -- probably, I don't know, 12 minutes, I'll split the difference, 12 minutes to do the lab. I'm not going to talk during that time, but if anyone has a question or an issue, speak up. And we'll jump in to help you, and maybe we'll take you to a breakout room to figure it out for you and then go from there. I see a question in here. Hold on. Let me see that real quick. Between distributed cloud app and traditional ASM policies. Okay. Great question. Thank you very much for asking that question. So I think the biggest difference, and we're going to see this here right now during the lab is that the AWAF policies that you're familiar with [ BIG-IP ] are incredibly granular, incredibly granular. And I don't know how deep you have gone with some of these policies, but I know I personally had gone as far as like configuring the meta character that was allowed to be called to an API for whatever reason. I have my reasons. But that granularity, that complexity turns into overhead. And it turns into some maintenance that is very hard to relay across teams and to really enable other teams besides the security team to protect applications, right? So distributed cloud is going to have the machine learning WAF firewall base. They're going to have the same signatures, but you're not going to have the same tuning ability as far as down to the meta character down to the specific call. Now you would be able to get through like very close to different routes, different types of URLs that you want to protect, and you want to protect them a little differently. But I discuss it as like a mixing board at a concert. So if you go to a large concert like go to Aerosmith or something, they have a mixing board that's massive like 4 seats wide of a mixing board. There's so many knobs and turn, that's AWAF. Distributed cloud is just as powerful, but that mixing soundboard is condensed into like a small like handheld mixing board device. We're able to deploy very similar defenses at just like a less configuration. If you did have a use case for you needed to like have extreme granularity on a specific call or API, you can run distributed cloud and AWAF in tandem, where -- and I've envision these architectures where you would have distributed cloud batting down 95% of the bad guys, right? It's like all the known garbage out there, all the [indiscernible], all that junk would get taken care of by WAF and malicious user. And therefore, like the really specific crazy meta character restrictions. You can continue to use AWAF if that was a use case you had. But I would look at distributed cloud being able to cover most of your security risk with I attempted the complexity, and you're going to see right now in the lab like how much easier it is to configure. Does that answer your question? And if there's any debate, I'm open to that, too. All right. I got a smiling face. Yes. Thank you. Okay. Great. Yes. And these are the types of questions I absolutely encourage. Both Reed and I have a lot of experience in AWAF, too. So we can definitely go down in the weeds with you. This is the call for that. All right. With that, it's 10:52. So I guess at 10:59, I'll check in and see how people are doing. I am also doing the lab, too, kind of in tandem. So by all means, chime in if you have any questions.

When we're adding our pool, do we want to change the port to be port 80 or leave that on [ 443 ]?

Yes, you did change it to port 80.

Okay.

All right. How's everyone doing? Feel free to raise your hand, thumbs up, something. Maybe don't raise your hands. I might think you have a question. Thumbs up, finished the lab or pretty close to it. Thanks, Josh. All right. If anyone needs more time, this is your last moment to speak up. Otherwise, feel free to work through the piece.

Should we do a quick 5-minute break, and folks can choose to take that break or to take another 5 minutes on the lab? Or what do you think?

Yes, for sure. Thanks for keeping me -- I did say let's take 5-minute breaks every hour, but we already gone through an hour. Just so excited to keep going. Yes, let's take a 5-minute break, for sure. So yes, love that. I'll put up a timer. Let's do it. [Break]

Reed, do you mind taking over the share? I'm going to help a user in a breakout room after this break.

Yes, totally.

Just give me a heads up so you can get queued up if you're not already.

I am ready.

Sweet. Okay. I'll wait after this one more minute. I'm going to take 1 minute myself. [ Stop ] of sharing. All right, Reed. So how are you.

Very good, very good, clicked on the wrong thing here. Let me close that. Okay. All right. Hopefully, everyone can see that. So what we're going to do -- well, first off, I presume the lab work for everyone -- if you didn't finish, don't worry about it. Don't stress. It's totally cool. There's going to be opportunities in the future. Basically, I would probably recommend is if you want more time with the lab environment, reach out to your SC for your account team, for your territory. They have the ability to actually set this up for customers on an ad hoc basis, and they're more than happy to do that. So definitely reach out to them. They can carve out a day, a slice of time for you to be able to log in, go through the lab guide yourself, and it's totally cool. So what I would probably recommend is if you didn't get finished, go ahead and just table that and move on to Lab 2 and just kind of focus on what we're talking about here. So yes. Does anybody have any questions on the previous lab? I'm assuming it worked for everybody. There's a question in chat here. Let's see. The labs will be available for a day. I don't know what time these labs were scheduled to shut down. We'll check with Krista when she gets back. I think she was the one that set them up. But they do spin down automatically at a given time. I just don't know what time was set for that. So we'll check with her when she gets back from the breakout room. So cool. Very good. So let's move on to Lab 2. Now what we want to do here is kind of compare and contrast the topic in Lab 1 with the topic in Lab 2, right? Topic in Lab 1 is WAF. And when we're talking about WAF, what we're talking about is overt attacks on a web application, right? So what we're talking about there is obvious -- and I say obvious, but I mean, if you were to look at the packet and you were to have signatures that can match what's in that packet, that's obvious, right? Because okay, we're looking for this as a signature in the packet, we see that, obviously, after it's decrypted. And we have imagined that's obvious that, that's an attack, right? Basically what these folks are doing is they're trying to exploit vulnerabilities in the framework of the application. And there's different motivations for that. These days, remote code execution seems to be the big one, to be able to plant something like ransomware or what have you. But it's all about exploiting the vulnerability of the framework of the application. Now when we segue from there to the next section when we're talking about bots. Bots are equally as important as protecting vulnerabilities from exploits. But it's a very different kind of a problem, and it's important to kind of understand that. So what we're talking about here -- well, first off, let's go ahead and continue with this. Basically, what we're looking at here is what's circled in red, right? Krista had noted the different layers that we have for protection in distributed cloud. Bot defense is one of those layers. It's one of the later layers. So we have other mechanisms that kick in before this, that's able to filter out the vast majority of the traffic before it even gets here. But obviously, this is still important, right? So when we're talking bots, what's the problem, right? The problem is these are no longer overt, obvious attacks. These are now covert attacks. These are synthetic clients, automated clients that are basically doing everything they can to look human. The motivation for this almost always is some type of fraud. And it's not an attack on the code of the application. It's an attack on the logic of the application, right? So for example, probably the most popular type of attack that bots carry out these days is credential stuffing. Credential stuffing is basically taking stolen credentials, any number of different ways those could be stolen. But basically sticking those into a bot and pulling them into a website and working off the assumption that if a user has used a certain set of credentials on one site, there's a chance that they've also used those same credentials on a different site. Because human nature is -- unfortunately, humans like to reuse passwords instead of using unique passwords. So that's one example of credential stuffing. Bots go out of their way to act human, and it's a very difficult problem to solve. Over the years, I'll be honest, the bad guys have kind of had a leg up with -- on the folks that are trying to stop the bleeding from these types of bot attacks, because they're very, very good at looking human. And it takes a solution with a very high level of efficacy to be able to really do what's necessary to be able to get the visibility to be able to do something about it. We'll talk about how F5 does that. Okay. So first and foremost is what's called basic bot defense in distributed cloud. I think we also call it fundamental bot defense. But what it comes down to is signatures, and signatures are a type of a network signal. When I say a network signal, what I'm talking about is something that's in the packet, not necessarily at the network layer, but it's in the packet. It can be seen with a packet capture. So it's a network signal. Problem with network signals from an efficacy standpoint for bot mitigation is that they can be easily spoofed. Adversaries and owners of bot armies have the ability to, quite easily from their point of view, spoof the information in there to look human, right? So we do offer this as a fundamental layer of bot protection. This is something similar to what a lot of companies offer as well, but it's really table stakes when it comes to bot protection. And it really only eliminates the bots that are super, super obvious. And because the goal from their point of view is to look human, there's a dubious level of efficacy when it comes to basic bot defense, I'll be real honest. Really where the rubber meets the road in terms of mitigating a motivated adversary who's using automated clients, bots and really making themselves look human, you really need to kind of take a step up from there. And this is what we call standard bot defense, and we also have advanced bot defense. We're not going to be talking about advanced bot defense today, but it basically uses the same principles that standard does. It just adds a couple of layers of managed services and dedicated appliances and things that we can really bring to bear to protect the organizations that are most at risk from the most significant bot campaigns on the planet. We're talking about the top hotel chains in the world. We're talking about the top airlines in the world, the top financial institutions in the world, folks that really have something to lose from an automated bot campaign from a fraud standpoint. Again, fraud is kind of the goal here as far as bots are concerned. So as far as standard goes, difference between bot defense and basic bot defense and standard is that standard goes above and beyond signatures, right? Signatures -- our table stake signatures are in the packet. Signatures are network-level signals that we see. But when you kind of take a step beyond that, you get the ability to not only look at network signals, but you also look at 2 other categories of signals. We're able to look at behavioral signals, and we're able to look at environmental signals. Environmental signals are basically signals in the browser of the way the browser's configured, at least the way that the client is telling us the browser is configured, right? And the behavior is basically the way that the human, or the synthetic human, is controlling their browser, controlling their client. So we're able to really get a high level of fidelity with over 200 different signals that we see to be able to really, again, with a high degree of fidelity, be able to definitively have an outcome of this is a bot or this is not a bot. We do leverage an AI machine learning engine that we feed those signals into. There's no application data that we're collecting. We're not collecting foreign fields or PII or anything like that, but we are collecting meta data. We're collecting signals of the clients. And we're feeding that into the machine learning engine and then giving it a definitive outcome of whether they're a bot or not. So when we're talking about browser signals, browser signals have to do with things again that the browser is telling us, like what spots does the browser support? What screen size do they have their window configured to? What plug-ins do they have installed in the browser? Does the time zone of the browser match the time zone that the operating system is reporting? What types of emojis are supported in that browser? So we're doing all this comparison to make sure that their browser actually looks like what we expect it to look like. And if it looks like some of that's been monkeyed with, their trustability of this particular user goes down, right? That's kind of what happens. Behavioral signals are the way the user is interoperating with their client. We're looking at mouse movement. We're looking at key strokes, not the keys themselves that are being pressed, but the cadence of the user. So when they're pressing keys, do they press all of the keys with the exact same interval between those key strokes? Or are different keys pressed at different intervals? So there's, again, lots and lots of different things that kind of play into this. If it's a mobile client, for example if it's a phone or a tablet, those have gyroscopes in them. So -- and you're holding it in your hand, so that gyroscope is always slightly moving. And if we look at the gyroscope signals in the browser, does it say that it's moving, right? And is it moving at a pattern that's predictable? Or is it moving in a pattern that would mimic the way a human would actually be holding that device? So many, many different signals, hundreds that we're not even mentioning here just because we don't want folks to reverse engineer, right? So a lot of the intellectual property that goes into this, a lot of secret sauce, some pretty cool behind the scenes techniques that we're actually able to detect bots. So with that in mind, does anybody have any questions before we jump into Lab 2? I see a question in chat. Well, looks like it's just Krista dropping it in there. Cool. Very good. Okay. So feel free to go ahead and jump into Lab 2. We'll give everyone an undetermined amount of time to go ahead and work through that. Again, if you don't get finished, no sweat. No harm, no foul. But we'll check in with you in a little bit and see how everybody's doing.

I think that was the lab -- that was the break slide.

Yes, I'm with you. I'm with you.

Yes.

Cool. Do you know when these labs -- what time these labs are supposed to shut down? Are -- they shut down right at the end of the lab or they go for like...

They don't. They stay up.

Okay.

And so that's what I kind of mentioned in the chat that the -- there's no guarantees after the course, but they do generally stay up a day or 2 after the course. So...

Got you.

Yes.

Okay. If anybody's finished, I guess, when you get finished, feel free to drop that into chat so we can see that or put your hand up or something so we can see that folks are done and look at the overall completion of the group.

Just running through this lab again, I forgot it's kind of a longer lab.

Oh, is it really?

Yes. It's documented for 25 minutes. So yes. I'm also -- I'm not done with it yet either, and I've done those like 5 times.

I'm with you. [ Less better all clocking ] time, right?

Yes. I had written down like check in at like 11:40.

Cool.

All right. How's everybody doing? Got a show of hands. People are at thumbs up, thumbs down. All welcome.

Yes. I found a cool article on the subject of bots if anyone wants to -- if you're looking for a good bedtime story, this is actually interesting article here on -- this is our threat research site, which is not product related. It's simply about threat research and folks helping other folks from a security standpoint. It's vendor-neutral. I pasted the link in the chat. It's talking about human captcha solving farms, typically offshore and how those are used to really make captchas ineffective as far as stopping bots goes. I think a lot of folks are under the false pretense that captchas actually do a lot more than they do. And it's unfortunate, but they're very easily defeated. So it's a good thing to -- good article just to read and be aware of as far as what the options out there are for bot protection solutions that are actually going to do what they say that they're supposed to do. So with that in mind, do we want to get a show of hands to see who is finished here?

I saw Josh and Mike, they were done. I know there's a few folks just following along. Give it, I guess, another 2 minutes. I finished it up. I enjoy this lab because I think it's kind of cool at the end where it shows that common Javascript insertion into the traffic. I know as a previous deployer of security technologies, I was always kind of like, you didn't really want to mess with the application traffic if you could avoid it, right? And so being able to inject that Javascript without impacting the application is key. And the important piece [ of ] that Javascript that I think the lab description lacks is that, that particular Javascript will then connect up to our AI-driven bot defense technology. And then they will be able to pull different IoCs that the Javascript is able to basically observe within that flow. It's really fascinating. It's not just like 3 or 4 IoCs. I -- the last time I talked to one of the engineers of that technology, they were collecting over 30 different pieces of IoCs, kind of what like what Reed covered, like mouse movement, key stroke, just being able to determine whether or not it's a malicious attack or if it's an attack that's automated. Obviously, those are the ones to [ goff ] down right away. But to that point of the article, there's a whole farm of people that are just in there breaking captchas at $0.10 a minute or whatever they're getting paid to do it. And those are the types of IoCs, though, that Shape or formerly known as Shape Security, but bot defense is able to pick up on and hopefully back down without impacting too much the development of the application itself. You know what, Reed? So you don't have to play Vanna. I can take over.

Okay.

We are ready to do that. We get to present -- oh, man really? Bear with me. Oh, you know what? I'm just not being a good PowerPoint user. Hold on. [ Move then just ] please. All right. I'm going to jump into Service Policies. Anyone that's still working, that's all good. We'll just -- feel free to catch up. And feel free to ask questions, any parts of the lab, all things are on. So all right. So kind of going back to this logical flow of how traffic routes through from the client to the actual web server. Service Policies is definitely the meat of distributed cloud and how we're able to deploy the technologies that you're probably familiar with from AWAF. And then there's also some new things in here as well, too. So there's API protection that's also included in here, able to map your APIs and then download Swagger files from that monitoring, rate limiting, IP reputation, geo-filtering. And those are some of the things we're actually going to configure today in the lab. So the things with Service Policies, and I don't want to call these the equivalent to an [ eyeroll ] on a BIG-IP appliance, but it kind of serves the same purpose of being able to customize a policy within distributed cloud, kind of like how you can customize how the BIG-IP behavior is on an appliance. So very similar. There's some like programming concepts that all of us understand, and that's how Service Policies works. So one thing to keep in mind, they're written for like a client-server relationship. So there's like a source and destination, that type of interaction. Keep that in mind, and that rules can be applied to all requests from server to the client. It will make a little more sense when we start going through the lab. But fundamentally, when you start getting into service policy, and you'll see this right now in the GUI, you're going to have a policy set. A policy set can be applied to an entire name space. You can then apply policies per application or per load balancer. And then there are specific rules within that policy. And the rules are hierarchal. I believe I have that covered in the next slide, where, yes, order of operation. So you're going to want to stack your service policies, as you begin to become more sophisticated with them, from like a top-down approach, very similar to [ a lot of ] firewalls that have been out there forever, right? Let me see if there was any additional -- yes, I want to make sure there wasn't any more automation to that. So kind of looking at this particular screenshot, allowed IPs are #1. We want to make sure things are coming from, let's say, subnets that we care about. And then you'll go through your list of basically filtering or what you're kind of washing through. So like denied countries is one. Maybe you do like a blacklist of all the OFAC countries. This is something you would build within service policy. Disallowed IPs, maybe a specific list that you have coming from different resources, et cetera. At the very bottom there, you'll see that [ VES-IO- ] allow all of that. That's kind of like a general rule that's always at the bottom of your share -- of your policy, excuse me, your service policy. And it's basically to allow that traffic that they have gone through the different role sets to then allow to the [ ordering resource ] wherever this policy is applied. So there's not a lot of like meat to this particular presentation. It really makes a lot more sense running through the lab asking questions as you go through the lab because then you're going to actually set up a policy, build roles within that policy and then apply them to the HTTP load balancer. So with that, back -- hands back on keyboard. I believe this lab is -- we're seeing about 30 minutes, but we have a smaller group in here, and people seem very proficient. So I'll probably check back in, in 15 and see how people are doing. So at 12:05 Pacific Standard Time. And during that time, by all means please raise your hand, chat to the group or just to Reed and I directly, and we'll help you out. I just noticed the typo in the lab. You guys are -- most people probably moved past this already, but it was in number one says within web app API protection under the managed section, it's actually the security section on the left-hand NAV menu, select Service Policies. Pretty sure for it, but just in case somebody was thinking about it.

I see Aaron's question in chat about doing geo-blocking for a larger region. I believe you can do -- instead of a denial list for countries, I think you can do an allow list. So if you want to allow like the United States and Canada and that sort of thing, it might be easier to manage it via an allow list. I'm going to check just to make sure that, that's correct, but I believe that, that's the case.

I was thinking about that. There's still 20-something countries in North America, too. It would be nice to be able to do that but on a continent or something.

Right. Right. Yes. Let me check on that. I think it's just country-based, though, right now.

Just checking in. I don't think anyone's done yet, but if you are, great. Raise your hand. If not, going to give it a little more time. This is a pretty long lab. All right. Folks, I'm going to give it 1 more minute, and then I'm going to let Reed go ahead and get started on malicious user. Just feel free to, if you're still working on it, go ahead and keep working on it or table it for now. You can work on it after the class. So fair warning, 1 minute. Oh, I've got 12:15 now. It's a cool lab. I like this lab. It just...

[ the one with Euler ] or the one -- which one?

I like the service policy lab. It's just interesting how you can really layer on.

Totally. And there's so much to Service Policies. I mean, just -- it's hard to put all that in the lab, too. Like I don't think TLS, malicious TLS fingerprints is in the lab, if I -- is it? I don't think it is.

No, it's not.

We'll talk about that here because I think that's important. We'll touch on it just so everyone knows what it is, but pretty cool.

Yes. I mean, honestly, Service Policies probably deserves its own class.

Yes.

So...

Yes.

In case people are in this part of the lab, there's a portion of like where it talks about routes and how you can do routing within distributed cloud. And you can do routing in the kind of like pre-HTTP load balancer and within the HTTP load balancer. And you can apply Service Policies at that piece, too. It's a little rushed in the lab, so I don't feel like it's explained well. But if there's any additional questions from what you saw in the lab, feel free to ping us.

All right. Should I go ahead and share?

Yes. I wasn't sure if you wanted me to be Vanna, I can let you. Cool.

All right. Malicious user, all right. So before we jump into malicious user, I just want to touch on TLS signatures actually. Partially because it applies or can apply to malicious users also. So there's a connection there. But TLS signatures is something -- it's not specific to F5, but someone several years back outside of F5 realized that different clients and even different versions of the same client negotiate TLS slightly different with the handshake. And because of that, you can uniquely identify the type and version of the client that is attempting to make the connection. So it's an interesting way. It's kind of like a client fingerprint, but it's specifically done using a hash of the way the client negotiates TLS. So that being said, there are certain clients out there that are only used for nefarious purposes. And within Service Policies, we have a large number of those identified. And you have the ability to build a service policy and block connections from clients that present that TLS fingerprint. So that's an interesting thing you can do within the service policy. Now when we're talking malicious users, right, so this is kind of segueing into the next section here. Malicious users, the term itself, it definitely requires or it helps to have a little bit of context there because a lot of times, you think of a user in terms of a person, right? Basically, what this is, is a way for distributed cloud to look at connections that are coming in and certain connections that you've identified as being part of the same client. You have the ability to have it take automated behavioral action based on that. So let me try to explain that a little bit better. Basically, the first thing we need to do is we need to identify what we consider a user, right? By default, what it considers a user is just an IP address, but those of us that have been around for a while probably recognize that you can have a large number of users or a large number of clients behind a single NAT address, and the level of fidelity there is not very good because one IP address now actually ranges over a large number of users, a large number of clients. So within distributed cloud, you have the ability to get a little more fine-grained than that, which we do recommend, kind of going beyond the default of just IP address. And what I commonly do is when I set this up, I do IP address plus the TLS signature. And typically, the combination of those is pretty good to get a good level of fidelity for a specific user, specific client that is making connections to an application. So that being said, in that scenario, if you see a specific IP address with a specific TLS fingerprint that has done 100 malicious things in the last 10 seconds, you're able to, down to that degree of fidelity, start to enforce more heavy-handed tactics to be able to limit access for that particular user. So again, this does use machine learning, AI, that's the buzzword these days, AI, to be able to have this automatically ratchet that user down, kind of put them on the naughty list and then assign them a threat score. And if the threat score exceeds a certain threshold, depending on what the threshold is and how heavy-handed you want to get, if it's over a certain threat score, you could have them automatically blocked, which is basically what's considered IP shunning. And even over time, what happens is if a user stops misbehaving, their threat score will improve. Now obviously, every time they do something malicious, we will block them based on the malicious action even if we don't block them as a malicious user, right? So -- but the malicious user capability is basically just a prefilter. It's a way of filtering things that are obvious bad stuff before they get to more fine-grained filters within the WAF, right? So it's being able to detect something that's highly likely to be malicious, and take action on it before we even recognize that it is malicious, right? So pretty interesting, pretty interesting. Great. So that's it in a nutshell on malicious users, kind of what it is. There's a number of other ways other than IP address and TLS fingerprint that you can identify a "user." You could use like a cookie, right? You could set a cookie and if you see the user coming back with that cookie, you could say, "Okay, well, that's the same user." There's a number of things that kind of could play into that to be able to uniquely identify a client and then have policies set to be able to enforce what they're doing from a malicious standpoint. So at any rate, it's a pretty cool capability, leveraging the brave new world of machine learning. So yes, go ahead and jump into that lab, and let us know if you have any questions.

This lab runs a little faster. It's about 10 minutes, and then we'll wrap it up.

Cool. Well, looks like the wrap-up section is maxed, do you want me to take that?

Yes, sorry, Reed. Yes, why don't you go ahead and wrap it up. I have written down 12:34, about 10 minutes since we last spoke.

12:34 as -- maybe we should move on.

Yes.

So be at 4 minutes.

Yes. Took me about -- Just like I said, [indiscernible] of the lab from everyone took me about 10 minutes.

12:33. Hopefully, everyone is ready to move on here with another, a little bit. Okay. 12:34 after, how's everybody doing? Does anybody have any questions? All right. Well, hopefully that lab went well for everyone. I think, again, that's a pretty darn cool feature to be able to proactively block malicious users based on past behavior and have it automatically manage that process behind the scenes, so pretty darn cool. All right. Let's see here. So yes, I mean -- slide that we've seen a few times that are basically taking multiple layers of filtering to be able to effectively mitigate different types of events probably consider them at a large level, undesirable, could be malicious. It could be just a nuisance but I think undesirable is probably a good way to categorize it. Lots of different layers of filtering to kind of go into this, but yet at the same time, relatively easy to manage, right, compared to what Krista was talking about earlier in terms of the WAF that's on our appliances, BIG-IP, advanced WAF, formerly ASM. A lot of knobs that you can turn just like on a mix in order to the concert. Here, pretty straightforward, pretty simple. And it's very much a goal of the company to continue to improve the simplicity. So taking something that's already pretty simple that you've seen today and continuing to improve the usability of it over time to make it even more simple. So yes, something we're all very excited about as we kind of move on. So again, distributed cloud, effectively a central way to be able to provide holistic and robust application security for web applications no matter where they're deployed, be it on prem, be it public cloud, be it a combination of the two and with a consolidated methodology, not only a consolidated set of tool but also a consolidated set of policies to bring consistency in the way you deliver security controls for web applications kind of checks a lot of boxes all at the same time, integrating with modern DevOps tool sets and principles to be able to do configuration and monitoring with those tool sets as part of the CI/CD pipeline, but also being able to take data that's generated within the platform in terms of security violations and reporting and also performance information of the application and having that streamed to either a SIM or some sort of a logging or a learning platform like Splunk or Datadog. So this is definitely a big part of the future of F5. We'll continue to make appliances because there are a lot of customers that still need them. And as Krista also mentioned, we kind of feel like the future is hybrid, right? Because for a lot of organizations, it makes sense to do both, right, have a cloud solution to be able to, from a security standpoint, block as much as you can upstream. That way, you never even see that nuisance, malicious and undesirable traffic. But yet having things like BIG-IP on-prem to be able to add an additional layer maybe from a security standpoint, but more specifically from a traffic steering standpoint, being able to do local VIPs on-prem, that sort of thing. So yes, that's kind of what we're looking at here. From a monitoring standpoint, dashboards, analytics, you don't see a whole lot of that in the lab, just simply because this is an artificial kind of an application that doesn't really exist in the world. You don't get a lot of rich telemetry in the lab just simply because the only traffic is coming from you. But there's a lot of rich information here. And actually, you know what, we can probably jump out as the PowerPoint and actually show you the tenants that we have that we can log into as SEs. That way, you can actually see what these dashboards look like. Let me try to share this on my screen here. You see that, Krista?

Yes, we can see your screen.

All right. So why don't you go into the demo main space and just kind of pull up our demo application, going to security monitoring. And this is a demo application that we have set up exposed to the outside world. And as such, we see a lot of interesting requests that come into it. So these are dashboards, this is high-level information here, but you can drill down on any of this. We were working with malicious users a few minutes ago. You see that in the bottom left-hand corner down here. Violations, top attack signatures, client-side defense, which I don't think we even covered in this particular lab, but it's a very interesting capability that's built in, which effectively deals with supply chain effects. In terms of JavaScript that could be -- JavaScript developers have leveraged because developers want to be as efficient as possible, just like everybody does, and they typically don't want to have to recreate the wheel each time, they need a function within their application, they'll leverage certain tool sets that already exist and a lot of that is JavaScript-based. So they'll leverage libraries of JavaScript that already exist out there that are used by many organizations. But the problem is sometimes there's code repository so that shared JavaScript can get compromised, right? And if a developer ends up leveraging a compromised piece of JavaScript, right, and inserting that into their application unknowingly, right? They don't know that it's compromised, and it's now nefarious but they're borrowing it, they're using it just simply to -- so they don't have to recreate the wheel for a certain function within the application. And what happens is that JavaScript gets delivered down to the client, the client runs that JavaScript locally in their browser, and then that call from the browser goes directly out to the bad guy, like that doesn't even flow back through distributed cloud and flow back through the server, right? Basically, a direct connection between the client and the adversary at that point. So what we can see here as the traffic is coming down to the client, we can see that JavaScript. We can detect certain domains that we know are affiliated with certain malicious campaigns out there. And there's a number of pieces of context that we can glean to be able to notify. Typically, folks want to not block based on this, although we do have the ability to block based on this. As Krista mentioned before, a lot of times, you want to get things to modifying the behavior of the application, people are a little weird about that in a good way, right? Because you don't want to break the application. So at the very least, leverage this feature to give visibility to JavaScript that's going down to the client that may potentially be malicious like we see here in this particular dashboard, so that at least you can pass this along to the developers so they can look into it, right? They may not even be aware, in fact, they probably aren't aware that this is happening. So definitely some cool stuff to dashboards. It's visibility that, quite honestly, you wouldn't have any other way, right, because of the fact that we are decrypting the traffic, we get visibility to the packet. We're getting the network signal, but we also have the ability to look much, much deeper than just that. Again, we talked earlier about being able to look at meta data. Here, we're looking at JavaScript. So things that are normally not even really considered from a security standpoint, really providing that visibility and letting you guys take the action on it that you feel is appropriate and really having a pretty interesting way to be able to protect your applications. Here's an interesting view I think some folks might like to see, change this to last 30 minutes. So this is our security analytics which has the ability to be able -- using machine learning to be able to look at different security violations and kind of like malicious user detection. What it does is it tries to make sense out of the noise, right? You have a lot of security fatigue and alert fatigue in the industry. Folks are just tired of seeing these logs and an individual violation doesn't really tell you much. But if you're able to take a step back from that and have something that will make sense out of those violations and do some correlation, that's what this is, right? This is the incident-based view for security analytics. So here you can see here, you have 7 million events which are all bot driven from a single source, which is this IP address, right? And you can kind of scroll down and you see a lot of similarities there, different IPs addresses. You can go ahead and get into the details here for this particular event. We can also see in addition to being bot traffic, it also has a ton of exploits in the payload, right, in the packet itself. So those are, again, overt types of attacks, not covert. So combination, kind of a blended attack here that we're seeing. So pretty cool visibility, right? Being able to actually not only see information that you didn't see before, but also having it make sense in a way that possibly you've never seen. So at any rate, Krista, anything that you'd like to add to that? Let me make sure we hit all of the important slides here.

Yes. No, I think that's great. Thanks for showing the dashboards of [ low balance ] or what traffic going through it. I think it's really important to see the visibility, and there's a lot more to see. It's not completely covered in this lab like the application performance dashboards are really great being able to track client to proxy then proxy back to origin server. We don't -- you typically have a kind of like a blind spot from your client that hits for BIG-IP appliance, but we're able to see that with distributed cloud. Thank you, while for mentioning that. Also, the distributed cloud platform, the infrastructure is currently under [indiscernible] review, and it should be ready. I think the hope is by the end of the year.

Looks like we did get the survey fixed, thanks to the person that mentioned that earlier, this particular session was not listed. If you go into that link now, it's actually kind of funny, they put the wrong data in there, but the session is now listed. So if you see a session for September 12, it's actually today's session, September 13. So go to the session that said September 12, and we really appreciate the feedback. This is very important to where we think the company is going and as being a piece -- it's not the overall future of the company, but it's a very, very critical piece of where I think the company is going. And we definitely would appreciate feedback helping us steer the content is going to be most relevant and most helpful for you guys. So yes, we appreciate the feedback on that. And it looks like Krista is just pasting the link back in the chat there so.

Hey Josh, did we -- did -- while answer your question on your data sovereignty question? Which I think is a...

Yes. I just want to bring it up because it was a roadblock that I had trying to get that set up because you needed to have an extra IP in order to get that set up. You couldn't do it with the initial IP that comes with the subscription.

Yes. Absolutely.

And that wasn't something that either our SE was aware of and it wasn't made clear initially. So I just want to make sure anyone else who is looking -- moving to it, a little bit aware of that data sovereignty was an issue.

Yes. No, I appreciate you bringing that up, Josh, because that is a very -- it's definitely within like governments and revenue department industries where it's really important that the actual [indiscernible] is known and where or not like decryption does take place. And to your point, when a tenant is purchased within distributed cloud here and signed an IP address, and that IP address may not be specific to a U.S.-based. Now there is a setup, there's configuration to where we can restrict traffic. So that's not any task network. So users from anywhere in the world can access your site if that's what you want. Obviously, we just talked about source policies and how we could block that. But we can allow anyone to access the site. And what happened is that they would route to the nearest RE that, that particular Regional Edge then knows to then route that traffic intended for the site that needs restriction to a U.S.-based RE and then does require an additional IP address cost. It's not overly expensive at yearly cost, but it is an additional cost that most folks like to get quoted prior to figuring out budgets and stuff. So if there's any additional questions to that within the group, please let me know. And thanks again, Josh. I think it's a great point for our government customers.

All right. Does anybody have any other questions before we wrap?

Just one more question. What is your opinion is moving from something like Silverline to the F5 cloud on trying to either transfer over the policies and exceptions that were made or just let the F5 cloud and its tools refigure things out?

So you're talking about Silverline line for WAF or for DDoS?

WAF.

Yes. So the WAF and Silverline is based on advanced WAF or ASM. And as we talked about before, it's a very different paradigm in terms of creating and managing policies. I mean I'll let Krista, I love your thoughts on this as well, my theorem is, unless there's a real compelling reason to port those advanced WAF rules over or Silverline rules over, I would probably start fresh, right, with the new paradigm rather than trying to take old wine and put it into new bottles. I would kind of start fresh just because it's an opportunity to kind of move into the future and start to modernize the way things are done. Krista, since you actually came from an operations background, I'd love your thoughts on that as well.

Yes. No, this is a great question. I was like "I don't understand it". I agree with Reed actually. So Silverline is effectively using ASM. It's an older version of our WAF solution on BIG-IP appliances. And so I'm sure and Josh, you would know better than we would. Now there could be some very specific like software, libraries or languages that, for whatever reason, they'll play a nice period with any WAF, right? So I would take a look at those exceptions like, yes, no matter what this particular call just doesn't work with, we need to make an exception for that. But I would say, generally speaking, exceptions made to baseline rules. I would let it run in a transparent mode and distributed cloud and see what it comes back with. My hunch is that distributed clouds, attack signatures and just the general machine learning component that's attached to that. Signature engine is more sophisticated. And I think a lot of the exceptions needed to be made in that particular TMOS version that runs on Silverline, you wouldn't need to be made any more in distributed cloud. But I would keep a keen eye out for like some of the software libraries that just won't play nice if anything. I hope that makes sense, Josh.

It makes sense to me. How does -- like in other opinions because that was my thoughts as well.

Right. Yes. It's cool to let it run in transparent mode and it's going to let the traffic go through and you get an opportunity to see when it's going to stop or not. Awesome. Well, thank you so much, everyone, for hanging with us, this is a long Zoom call, and we're well aware of Zoom burnout. So we appreciate everyone's hanging tight all the way through it. And like I mentioned earlier, the lab should be available to you through the rest of the day, so feel free to continue. No guarantees. And -- but I'm -- so far, I would say, 99.9% sure, it's going to be great until end of day 5:00 p.m. Pacific standard time. But if you need more time where you'd like to invite other folks to run through this lab or any other lab that's been presented throughout the course of the SLED Test Drive Series, just let your account team know, and we can set it up for you very easily.

All right. Thanks, everybody. Appreciate you joining, and look forward to seeing everyone on the next one.

Thanks again Reed for the help.

All right. Take care. Goodbye.

Goodbye.