All right, I think we're two after. I think it's, It's, yeah. I'll turn on my video temporarily and turn it off when we start doing these labs. Good morning, everyone. There's Lyle. Good morning, Lyle. Hey, Krista. 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 Cloud Test Drive, Test Drive Lab series. This is, we're going over F5 Distributed Cloud, the WAF and WAAP. Deployment, it's 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 AWAF policies that you guys might already be running as BIG-IP customers. By all means, I really enjoy a conversational meeting, so if you guys just wanna raise your hand and have a comment, please do. If not, that's okay too. Both Reid and I will be monitoring the chat when we kinda 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 two 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 my background has mostly been cybersecurity. I've worked nearly every role in cybersecurity besides C-level, and yeah, it's my passion. I love it. So an 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, Reid. Go ahead, Reid. Oh, can't hear you. Double mute. There we go. How's that? There we go. Yeah, that's great. All right. Very good. The lighting in my hotel room here is kind of subpar, so hopefully, it doesn't make me look too orange. But, hope everyone's 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 a SE with, F5, based in the Southeast, based in Tampa. I've been with the company for 11 years, and, as Krista said, feel free to ask questions. We'd love to make it interactive. Wanna make sure that you guys get, quite a bit out of this session today. So look forward to, look forward to it. Nice. Thanks, Reid. 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 and jump in. Okay, great. All right, so you know where we are, and we just did intro, so I won't bore you with that page. I'm gonna go ahead and stop sharing my camera too. All right, so this is the lab guide. There's gonna be a few opportunities to click this link, but if for anybody who wants to jump ahead and start looking at the lab guide, by all means, feel free. Just, just for awareness, we're probably gonna spend a good 20 minutes on getting you guys into the lab, because probably actually setting up and deploying Distributed Cloud AWS, a WAF and Distributed Cloud is very easy. Getting you in the lab will probably be more of a struggle today, which is a good thing, right? So, this is a 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, so you don't wanna grab it right this second. I just dropped it in the chat also, so that j ust click on it from there. Love that. There's a question in chat. Krista, do you know if this is gonna 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 offhand? Yeah. Excuse me. Yeah, I just responded to that. We will not b e recording it. I got you. But you know, kind of what we've been telling everyone throughout this whole series for the last few months is, you know, it's no problem at all if you'd like to run through this lab yourself, or, you know, 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's, you know, if that works better for you. All right. Thanks, Lyle. And I, I would like ditto to what Lyle said, that the account team, it's very easy to spin these up, and then your team can work at it at your guys' leisure, right? So, you know, you might have guys who wanna work on it Friday afternoon during No Change Friday, right? We'll be happy to do that and get you in touch with the account team as well. All right, so hopefully, everybody has received this email. This is the email that comes from the F5 lab environment, which we call UDF. If you haven't, that's okay. Please, in the chat, let us know. And, I'm gonna do the talking, so I'm gonna let Reid do his best to manage all that, and we can get this sent to you right away. But from the, I thought, I think I've captured everybody. So hopefully you have this email. If you haven't done anything yet, great, because we'll walk through. If you've already done some stuff, no problem, we're gonna go ahead and do it. Now, the problem with this email is it's a little busy, but truly, we need you to click this third link that you have, that we have here on the, on your email. 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 gonna ask, "Welcome to the lab environment. You are an invited user." And then for, at this point, you're actually not going, y ou're gonna 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 haven't, if you did Agility and you're like, "Well, I don't want to remember my password," just click Forget Password. Go ahead, next. So this is the forgot password experience. So if you did forget your password, it's gonna send it to the email that you registered for the lab to, and then it's gonna send you a code, and then kind of just do kind of like typical email 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 authenticate, you have to, like, authenticate your email 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 It's gonna send your email 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 Applied Test Drive Lab, and then you will click Launch. Kind of see the screenshots here. Give 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're seeing is, during the login process, hopefully? It's, it's several steps to get logged in, so we just kinda wanna make sure that everyone gets through this. Great. Thank you. Yeah, 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 gotten through the UDF. That's just one piece to actually register or finish registration and in the class. Now, you've been taken into the session. You're gonna 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 number one, 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 last lab, 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 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 go ahead and click the deployment. During the deployment, you should be actually seeing some gears, some yellow gears spinning, and basically all of like the automation magic that's happening behind the scenes. When you get to the green arrows, that's when you know that your, your user in the Distributed Cloud has been created successfully. It takes about 1 or 2 minutes. When I get done talking here, I'll, I'm gonna give us about 2 minutes to make sure everyone's caught up and 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 gonna have you click into your tenant, in that Distributed Cloud tenant. And then once again, there's one last opportunity to click that lab guide in case you missed it, you know, in the previous screen. All right, we're back here. I'm gonna kind of pause and take a look in chat to see if anything Reid hasn't already grabbed and give everyone about a minute to catch up here. Oh, already put in the lab guide link, so that Reid- Might be easier than pulling out a chat and try to find it in there. So just putting in there as a redundant way to find it. Oh, thanks. Thanks, Eric. Yeah, it takes a few minutes. So the client wheel, that's a good thing. So let it. 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, that hasn't yet gotten to the point where you see the gears turning? Anybody stuck at any point up to that point? If you get 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, it asks me to log in and gives me an invalid username and 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. Yeah, you're welcome. All right, I'm gonna 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 XC Lab Stack tenant, what we call tenant, you should have your email that you're registered for. Yes, and it's probably gonna give you some sort of, like, this is an, you know, an unfamiliar user. So what has happened in the background is that we have created a user with the email you're registered with, but now you need to reset that password, right? We're not gonna send you a password. We want you to create your own. So go ahead and click Forgot Password. Enter in the email that you used for registration. That's key. Not a different email, but definitely the email 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 email basically saying to go ahead and change your password and go through those steps. Next. Yeah, then you'll get an update password, and then that your account has been updated. One piece to note, it seemed pretty snappy this morning when I ran through the lab this morning with a test user. Sometimes it takes a minute or two to get your email from Distributed Cloud for a 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 two, please let us know in the chat. And I'll stop here just a second just to make sure everyone can run through that forgot password process, 'cause 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. Thank you, Josh. Thank you. All right, I'm gonna give it one more minute. All right. I'm gonna keep going forward. Mike, I think we're catching up to you on the next C on the Identify Yourself screen. So o h, yeah, I know what you're talking about. All right. Mike's jumping ahead. That's great. That means he's in. 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, you know, assigned to your organization, and then within tenants, we have what's called namespaces. And then in namespace, you can carve out, you know, base, role-based access based on application, group, etcetera. But you're gonna be logging into your tenant, and the tenant today is F5-XC-lab-sec. So with that mouthful, please enter that in. Enter in your email and 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'm not covering those now, but if you have questions, let us know. Here, this isn't a huge deal because we can get you access, you know, you'll be able to see everything as we walk through things, but go ahead and click all of the checkboxes. There will be some limited access today based on your lab account, just FYI. So if you, if you go to click on something, you realize you can't edit the 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 walkthrough as far as kind of clicking through, kind of like a widget assistant. You're welcome to click through that. I think right now it's probably three or four 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 Namespace. And so each user at this lab will be assigned their own Namespace. So we're gonna go and search for that. There's a few ways of doing it, but this is the way I'll show you here, and if anyone struggles finding it, I will help you out. So we're gonna go ahead. You're gonna 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 gonna have you select, you're gonna go to 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 gonna select a service, and then the service you're gonna select is Multi-Cloud App Connect. So go ahead and do that. And then when you get there, there's not gonna 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 gonna see the full URL. It's gonna say slash namespace slash some unique attribute. Mine yesterday was grand-kid, or this morning it was kodiak-bear. So you're gonna find something, we try to make it a little funny, some sort of funny URL parameter or attribute that you're gonna grab, and that would be your namespace. If anyone has any issues finding that, by all means, please raise your hand, and we'll help you get to it. Once you get that, just take a note of that. We're gonna use that throughout the lab today. That's important to you. Basically, we'll be referencing your namespace. Then after that, we're just gonna check DNS Management and making sure that a domain delegation has occurred within your namespace. You're gonna go ahead and go to Select Service, go into DNS Management. You're gonna go into Delegated Domain Management, and then here you're gonna see lab-sec-f5demo.com. You'll see the associated name servers for Distributed Cloud. Those are our four 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 a 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. Oops, give me a second. 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 the 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 outside. You can go to the site map or go into Performance Dash or whatever you'd like to get started, and we'll it's a step-by-step process in the lab that will guide you correctly through. Basically, you'll go into Manage, into Load Balancers, and you're gonna create your first load balancer. With that, I'm gonna stop talking, take a look in the chat and let everyone catch up and make sure everyone's got their Namespace, is comfortable, and was able to see the delegated domain to the lab demo site, and see if there's any other questions. 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 in the lab is, you know, it's just there's a lot of steps to it, just because there's a lot of different platforms that are working and, you know, we wanna set up these really cool, environmental environments for you guys to do all the testing you want. So just takes a minute, but it's, 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. Looks good from what I can see. Yeah, t his could be the most successful lab logging in group. I was about to say, that, that went very smooth. Kudos to this group. Kudos! First, a lot of them have already taken the preceding lab, so this is second nature. Mm. Touché. Touché. You're, you're diminishing their, you're diminishing their life, Lyle. That's true. Back in their life. All right, I'm gonna give it 30 more seconds, and we'll go ahead and jump into this. By all means, if you're still kinda catching up, the first few slides are kind of just going over general concepts that you probably have already gone through. Just kinda checking, you know, dusting off the old topics and then feel free in the chat, ping any of us, and we'll help you out. All right, I'm gonna go ahead and jump in. Okay, you guys have probably already seen this slide here, but this is just kinda 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 are applications deployed, where does security need to be deployed, and who is accessing different environments, right? So, you know, this is, this has been just a huge issue throughout any environment I've worked through, and, like, the big push to figure out how to cover public cloud, your on-prem environment, and then any of the third-party apps that you might actually have going on. How are we able to secure these? How are we able to monitor the different types of access to them? So this is, this is F5's ability to mitigate this risk, start, you know, improving that risk posture as moving into different environments. Because as, you know, things have changed in the last five-10 years, not everybody's in public cloud. I don't think anybody will be all in the public cloud. I mean, there's an exception, 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, you know, we all, we all joined our organization at some point in our career where we had the primary and the secondary data center, all was well. And that all, that seemed like a lot of work in stone, right? But, you know, over time, you know, we had different use cases and reasons to move into the public cloud, whether that was for disaster recovery, that's where different APIs were available that we needed to leverage, etc. So those interconnections and that networking needed to exist. 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. Then, you know, let's not forget, you know, most of us don't just work in a single building, but, you know, you know, hundred, potentially, you know, tens or hundreds of buildings across, you know, either the country, the globe, etc., where you need to interconnect all these remote sites. Remote sites might be hosting different resources that you do need for your application. Partners are my favorite. Everybody has to love a good third-party partner for whatever reason, right? I c oming from the financial services industry, most recently, you know, we would have partners that did, like, some of the mortgage servicing that we didn't want to do in-house. So those are all more APIs we needed to figure out to communicate with applications that we hosted mostly in our primary data center, but, you know, some other pieces of it in the public cloud. And then we have not just, you know, 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, you know, obviously providing the application out to our customers, we need to access them, and we need to access all these different environments. So it's a huge job, right? And, the Distributed Cloud platform is gonna help us start streamlining some of these things, maybe taking away some of the pieces of actual hardware that or virtual hardware that needs to be installed, and then just using a, 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 and just in the next slide on, like, how we do deploy the F5s, the infrastructure. B ut 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. You know, they, they have no idea how many possible resources and locations of those resources may exist, and we're able to integrate within CI/CD pipelines. We're able to then provide that security piece, which we're talking about specifically today, onto 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 won'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 some platforms, and, and we're able to pull the logging of Distributed Cloud and the security desk out of our systems into your SIEM environments, whatever those might be. So the key building blocks of Distributed Cloud, you know, today, we're truly just beating the drum on application security. So it's gonna feel very heavy-handed in the WAF discussion today. I don't wanna 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 in 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. There's use cases for that. For example, you wanna 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, you know, 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 SE view. That's a, that's a site that's completely hosted on our Kubernetes platform in Distributed Cloud, so it's not, 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. On to the map. You know, honestly, I think this map could be outdated. We are absolute this, this infrastructure that you're seeing here, these are what we call RE, Regional Edges. 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, a relay of, of another main data center services. So like a POP is an AWS. It's just like relaying the service to a closer presence to wherever you're at, might be, or that data center, where a Regional Edge in Distributed Cloud is actually hosting a 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 Edge s, and this is an F5 infrastructure that's completely owned by F5, owned and managed by F5, which I know our government customers really like. This is using an anycast network, so we're able to route if you so want. You know, if you have a user in North Africa, and you need to provide that service to them, they are gonna hit that—they're gonna hit that Madrid RE, right? Even though maybe if your services are actually hosted 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, you know, with, with as little latency as possible. And, you know, I didn't check this morning, Reid might know, I, I believe we are still in the top 10 for BGP peering on both IPv4 and IPv6. I will check. If we're not number 10, we might be number 11. Okay, okay. Yeah, but we're definitely in there, for sure. I just like to, like, throw that out there. I know it doesn't mean too much, but it just t o me, I was pretty impressed that we had been top 10 in that BGP peering for so long. It just shows, like, the robustness of the way F5 is investing in the Distributed Cloud. And folks who have been, you know, longtime F5 customers, which thank you, I thought this isn't just, like, another by-product or some other new thing F5 is investing in. Like, we are heavily investing in the Distributed Cloud. We absolutely believe this is the future of the company. Yeah, we are in the top ten for both V4 and V6. I'll paste the link in the chat so everyone can see that. Nice. Yeah. Thank you. Before I move on to going in the weeds with WAF and WAF, are there any questions on 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, I really, really enjoy this slide here because. Let me, let me back up real quick. So make sure my animation is 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 decryption happening? When is it re-encrypted? Did you send it out? Like, how does the proxy work? You know, and I really enjoy this slide because it's gonna show here, and we're gonna, I'll touch on the pieces we're gonna cover today, on when the specific F5 technology kicks in. First thing, I'll back up a step. You know, Distributed Cloud WAF and WAF protection, it's not just, it's not just a WAF. You're not just buying a WAF with signatures that are, you know, 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 gonna 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 gonna hit, like, the layer three and four DDoS protection, if you have, if you so have that enabled. You can have it enabled specifically for your tenant, but, you know, overall, F5, you kind of get, kind of get a double dip here, which is great, because, you know, obviously, F5 is gonna 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, you know, like, residual effect from that. And then from there, we're able to do the ACLs, right, layer three, 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 will allow us to do encrypted traffic. And then we're able to inject technology such as Malicious User, which we'll touch more on. Really great technology, because that is not, t hat is a more proactive technology, where we're using machine learning and AI to actually baseline traffic, and then to 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. You know, maybe we tell a bad guy that's been identified by malicious user, like, "Okay, you can't use the site for 20 minutes," to see if the IP rolls and then moves on and 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 AWAF or managing AWAF. Deployments where you get the IP Reputation, Geo-Filtering, TLS filtering, et cetera. All this goodness is occurring here in Service Policies. And the Service Policies for Distributed Cloud is incredibly configurable. So on top of the things you can configure specific, specifically for security, you can do more with that as far as with, like, routing and different sort of injections. So if you're really sort of going down the path of Distributed Cloud and moving more traffic to Distributed Cloud, Service Policy becomes your friend. And beyond the Service Policies, you would get into our Bot Defense, and the Bot Defense is our AI-driven bots protection. So within the WAF, and you'll see that today, you're gonna have bots protection, which is our signature-based bots protection. Sorry, overused the word, but Bot Defense is actually if folks have used this event, we had acquired a company, now close to four or five years ago, called Shape Security. Shape Security was just incredible at being able to identify correctly, key, and back down, malicious bot actors and, 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, it worked well. But right now, for the lab and what I'm gonna talk to you here in the next 5, 10 minutes, we're gonna talk through the WAF deployment, how that works, threat campaigns, how you turn that on, not hard, and, let's get started. Oh, okay, great. Talking through that stack, this is w e 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. It was I don't wanna call it a DDoS attack because it was 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, I've had other customers say this, like, "Well, then why have, why have a web Application Firewall if, like, all these other technologies, you know, engage?" I think it's important to note that not every attack is 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 we already had a signature in place to bat down, like, a Spring Framework attack or some sort of, you know, stress. I always go to pick on stress, Struts attack. So WAF is gonna be able to back that down, and it just goes back to the old paradigm that we always build the same security, you know, defense in depth, always security in layers. And, so I really want to show this and just to, again, talk through how each one of these components we'll go through today in the lab, really kind of set this 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 gonna 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 signatures 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, a signature base. And in addition to that, 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 we'll actually talk to through the lab. There's a Forensics tab on the right, upper right, as you start doing some attacks and stuff, that you're able to pull out and through the technology of, like, behavior-based identification, start taking out malicious actors quickly, and then you're able to then block, either block IP, you know, 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 is included in this. T he 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. It goes with WAAP, and I did see it had turned on, and it was effective at batting down known bad actors. I think a 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 the 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 what the piece here that I wanna touch to, and you'll see through the lab, but first things first, we're gonna 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 gonna advertise your site where you want it to be, whether or not the Internet, whether that's internally, this is your proxy. You know, I don't love how it's named, but it's the HTTP Load Balancer. It's effectively your application proxy that's here. But it's important to configure this first, because then we 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 that a nd 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 gonna be some things you're gonna see in your dashboard. You probably won't see this many violations because you're, you know, you're spinning up an application and just doing a few things very quickly here in this next two hours. But, I'll be on standby. And the reason I talked about it, maybe I'll be able to. We'll have time. I'll show you some of the kind of full dashboards that we have all set up from other tests on F5 products. These are some of the dashboards. So this dashboard over here on the left probably looks pretty familiar to you. This is when you log in. This is the widgets that you can 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 what 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 let you loose on the first lab. Before I open up for questions, I think we're just gonna, 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 gonna 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. Oh, I see a question in here. Hold on, let me see that real quick. Traditional cloud and traditional and some policies. Okay, great question. Thank you very much for asking that question. So I think the biggest difference, and we're gonna see this here right now during the lab, is that the WAAP policies that you're familiar with, the BIG-IP, are incredibly granular, incredibly granular. I don't know how deep you have gone with some of these policies, but I know I personally have gone as far as, like, configuring the meta character that was allowed to be called through an API, for whatever reason. I have no reason. 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? Distributed Cloud is gonna have the machine learning WAF firewall base. We're gonna have the same signatures, but you're not gonna 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 wanna protect, and you wanna protect them a little, little differently. But I, 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, you know, they got a mixing board that's massive, like, you know, four feet wide of a mixing board. It has so many knobs to turn that they laugh. Distributed Cloud is just as powerful, but that mixing sound board is condensed into like a small, like, handheld mixing board device. We're able to deploy very similar defenses at just like at a less configuration. If you did have a use case where you needed to, like, have extreme granularity on specific call or API, you can run Distributed Cloud and AWAF in tandem, where, you know a nd I've envisioned these architectures where you would have Distributed Cloud batting down 95% of the bad guys, right? It's like all that known garbage out there, all the script kiddies, all that junk would get taken care of by WAF and malicious user. And then for, like, the really specific, crazy, you know, meta character restrictions, you can use-- 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 risks with, you know, a tenth of the complexity. And you're gonna see right now in the lab, like, how much easier it is to configure. Does that, does that answer your question? And if there's any, and if there's any debate, I'm, I'm open to that, too. All right, I got a smiley face. Yes, thank you. Okay, great. Yeah, and these are the types of questions I absolutely encourage. And both Reid and I have a lot of experience in the AWAF, too, so we can definitely go down the weeds with you. This is a 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 a 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 wanna change the port to be port 80 or leave it on 443? Yeah, you do 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 hand, 'cause I might think you have a question. Thumbs up. Finish the lab. Pretty close to it. Thanks, Josh. How's everyone doing? 2 more minutes? All right. If anyone needs more time, this is your last moment to speak up. Otherwise, feel free to work through the next piece. Should we do a quick five-minute break, and folks can choose to t ake that break or to take another five minutes on the lab, or what do you think? Yeah, for sure. Thanks for keeping me. I did say let's take five-minute breaks every hour, but we've already gone through an hour. Just so excited to keep going. Yeah, let's take a five-minute break for sure. So yeah, love that. I'll put up a timer. Let's do it. Oh, all right. Hey, Reid, do you mind taking over the share? I'm gonna help a user in a breakout room after this break. Yeah, 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 and take one minute myself. That's annoying. Okay, we're done. I'll stop sharing. All right, Reid, so are you. Very good. Very good. Clicked on the wrong thing here. Let me close that. Okay. All right. All right, hopefully everyone can see that. So what we're going to do w ell, first off, I presume the lab worked for everyone. If you didn't finish, don't worry about it. Don't stress. It's totally cool. There's gonna be opportunities in the future. Basically, what I, I would probably recommend, if you want more time with the lab environment, reach out to your SE through your account team, for your, 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, so definitely reach out to them. They can carve out, a day, slice of time for you to be able to log in, go through the lab guide yourself, and it's totally cool. So, you know, what I would probably recommend is, if you didn't get finished, go ahead and just table that, and, move on to lab two, and, just kind of focus on what we're talking about here. So, yeah. 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 two. Now, what we wanna do here is kind of compare and contrast the topic in lab one with the topic in lab two, right? Topic in lab one 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 a match, and 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. You know, 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, 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, the, probably the most popular type of attack that bots carry out these days is credential stuffing. Credential stuffing is basically taking stolen credentials, you know, 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, so we, we do offer this as a fundamental layer of bot protection. This is something similar to that a lot of companies offer as well, but it's really table stakes when it comes to bot protection. It really only, it really only eliminates the bots that are super, super obvious. And because the goal from their point of view is to look human, you know, 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 to using automated clients, bots, and really making themselves look human, you really need to kind of, take a, 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, 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, the difference between bot defense and Basic Bot Defense and standard is that standard goes above and beyond signatures, right? Signatures are table stakes. 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 two other categories of signals. We are 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 is 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, 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 form fields or PII or anything like that, but we're not collecting metadata. We're collecting signals of the client, 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 fonts does the browser support? You know, what screen size do they have their window configured to? What plugins 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 or the way the user is interacting with their clients. We're looking at mouse movement, we're looking at keystrokes, 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 keystrokes 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 a nd 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? 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 two? Let's see. I see a question in chat. Oh, looks like that's just Krista dropping it in there. Cool. Very good. Okay, so, feel free to go ahead and jump into lab two. 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. Yeah, I'm with you. I'm with you. Yeah. Cool. Do you know when these lab, what time these labs are supposed to shut down? Or they shut down right at the end of the lab, or they go for like. They don't. They stay up. And so that's what I kind of mentioned in the chat, that they. There's no guarantee after the course, but they do generally stay up a day or two after the course, so. Gotcha. Yeah. Okay, anybody who's finished, I guess when you get finished, feel free to drop that in the chat so we can see, 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? Yeah. It's documented for 25 minutes. Oh! Yeah. And I'm also not done with it yet either, and I've done this like five times. Well, that's right. Yeah. I had written down, like, checking it at, like, 11:40. Cool. All right, how's everybody doing? Get a show of hands. People are at thumbs up, thumbs down. All welcomed. Yeah, I found a cool article, you know, on the subject of bots, if anyone wants to. If to. If you're looking for a good bedtime story, this is actually an interesting article here on this is our threat research site, which is not product related. This is simply about threat research and folks helping other folks from a security standpoint, vendor neutral. Pasted the link in the chat, 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, you know, 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 g ood article just to, you know, read and be aware of, as far as, you know, what the options out there are for bot protection solutions that are actually gonna do what they say that they're supposed to do. So with that in mind, do we wanna get a show of hands to see who who's finished here? I saw Josh and Mike, they're done. I know there's a few folks just following along. Give it, I guess, another two 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 technology, there was always kind of like, you didn't really want too much 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, 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, it's really fascinating. It's not just like 3 or 4 IOCs that t he 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 Reid covered, like mouse movement, keystroke, just, just being able to determine whether or not it's a malicious attack or if it's a, you know, an attack that's automated. Obviously, those are the ones to block down right away. But to that point of the article, you know, 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. Those are the types of IOCs, though, that Shape or Shape, formerly known as Shape Security. B ut Bot Defense is able to pick up on and hopefully bat down without impacting too much of development of the application itself. You know what, Reid, so you don't have to play Vanna, I'll, I can take over. Okay. I'm ready to do that. Let me get the present. Bear with me. You know what? I'm just not being good. Probably leave this. Hold on. From here, please. All right, I'm gonna jump into Service Policies. Anyone is still working, that's all good. Well, just feel free to catch up, and feel free to ask questions, you know, 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, that you're probably familiar with from AWAF, and then there's some, 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 spider 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, you know, the, the equivalent to an iRule on a BIG-IP appliance, but it, 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, and that's how Service Policies work. So, one thing to keep in mind, they're written for, like, a client-server relationship. So, you know, 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'll 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 namespace. You can then apply policies per application or per load balancer. And then there's specific rules within that policy. And the rules are hierarchical. I believe I have that covered in the next slide, where order of operation. So, you know, 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, you know, firewalls that have been out there forever, right? Let me see if there was any additional y eah, we want to make sure there was any more automation to that. So kind of looking at this particular screenshot, allowed IPs are number one. You know, 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, deny countries is one. Maybe you do like a blacklist of all the OFAC countries. This is something you would build within service policy. Just allowed IPs, you know, maybe a specific list that you have coming from different resources, etc. At the very bottom there, you'll see that ves.io/allow-all. That's kind of like a general rule that's always at the bottom of your shared policy, excuse me, your Service Policy, and it's basically to allow that traffic that they have gone through the different rule sets to then allow to the origin 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 rules within that policy, and then apply them to the HTTP Load Balancer. So with that, hands back on keyboard. I believe this lab is, they're saying 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 Reid and I directly, and we'll help you out. I just noticed a typo in the lab. You guys are prob-- most people probably moved past this already, but it was in number 1, says within Web App & API Protection, under the Manage section, it's actually the Security section. On the left-hand nav menu, select Service Policies. Pretty, pretty straightforward, but just in case somebody was thinking about it. I see Aaron question in chat about doing geo-blocking for a larger region. I believe you can do, instead of a deny list for countries, I think you can do an allow list. So if, if you want to allow, like, the United States and Canada and, you know, that sort of thing, it might be easier to manage it via an allow list. I'm gonna check just to make sure that that's correct, but I believe that that's the case. Yeah, I was thinking about that. There's still 20-something countries in North America, too. It'd be nice to be able to do that by, like, continent or something. Right. Right. Yeah. Let me, 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, I'm gonna give it one more time. This is a pretty long web. All right, folks, I'm gonna give it one more minute, and then, I'm gonna let Reid go ahead and declare on the 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. We can work on it after the class. So fair warning, one minute. Oh, I got 12:15 now. It went fast. Yeah, it did. This is a cool lab. I like this lab. It just The computer or the one, w hich one? I like, I like the Service Policy lab. It's just interesting how you can really layer on. Oh, totally. And there's so much, there's so much to Service Policy. I mean, you just, it, 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, 'cause I think that's important. We'll touch on it just so everyone knows what it is, but pretty cool. Yeah, it's, I mean, honestly, service policy probably deserves its own class. Yeah. So. Yeah. 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, you know, 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? Yeah, I wasn't sure if you wanted me to be Vanna. I can let you- It doesn't matter. 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, you know, 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, all 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 who 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 that the level of fidelity there is not very good because one IP address now actually you know ranges over a large number of users, 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. You 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 know, you're able to, down to that degree of fidelity, start to enforce more heavy-handed tactic, tactics to be able to limit access for that particular user. So again, this does use machine learning, AI, you know, that, that 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 the threat score. If the threat score exceeds a certain threshold, depending on what the threshold is and how heavy-handed you want to get, you know, if it's over a certain threat score, you could have them automatically blocked, which is basically what's considered IP shunning. 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? But the malicious user capability is basically just a pre-filter. It's a way of filtering things that are obvious bad stuff, before they get to more fine-grained filters within the web, 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, quote, unquote. 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, you know, 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, yeah, 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. I'll go ahead and stop sharing. Well, it looks like the wrap-up section is next. Do you want me to take that? Or just you want to step away? Yeah, sorry, Reid. Yeah, why don't you, 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 when we should move on? Yeah. So we got 4 minutes? Yeah. Took me about, just like I said, I was just running a little ahead of the lab from everyone. Took me about 10 minutes. It's 12:33. Hopefully everyone is ready to move on here. Give it another little bit. Okay. 12:34. 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. Pretty darn cool. All right. Let's see here. So, yeah, I mean, slide that we've seen a few times, right? Basically, taking multiple layers of filtering to be able to effectively mitigate different types of events. Probably consider them at a large level, undesirable. You know, could be malicious, 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 mixing board at a concert. Here, you know, pretty straightforward, pretty simple, and, you know, it's, it's very much a goal of the company to continue to improve the, the simplicity. So taking something that's already pretty darn simple, that you've seen today and, continuing to improve the usability of it over time to make it even more simple. So, yeah, 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 tools, but also a consolidated set of policies to bring consistency in the way you deliver security controls for web applications, you know, kind of checks a lot of boxes all at the same time. Integrating with modern DevOps tool sets and principles to be able to, you know, do configuration and monitoring with those tool sets as part of the CI/CD pipeline. B ut 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 SIEM or some sort of a logging or a alerting 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 so many customers that still need them. And, as Chris also mentioned, you know, 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 and malicious and undesirable traffic. But yet, having things like BIG-IP on-prem to be able to add an additional layer, maybe from security standpoint, but more specifically from a traffic steering standpoint, being able to do local VIPs on-prem, that sort of thing. So, yeah, 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, you know, there's a lot of rich information here. And actually, you know what? We can probably jump out of the PowerPoint and actually show you, the tenant 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. Can you see that, Krista? Yeah, we can see your screen. Cool. All right, so let me go into the demo namespace, and just kind of pull up our demo application. Go into 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 you know, again, 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 attacks in terms of JavaScript, that could be. You know, JavaScript developers have leverage because developers want to be as efficient as possible, just like everybody does. 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 those code repositories for 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, you know, now nefarious. But, you know, they're borrowing it, they're using it just simply to, you know, so they don't have to recreate the wheel for a certain function within the application. And what happens is, that JavaScript, it 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? It's 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 when it gets into modifying the behavior of the application, people are a little, you know, weird about that in a good way, right? 'Cause you don't wanna break the application. So, at the very least, leverage this feature to get 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 in these 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 signals, but we also have the ability to look much, much deeper than just that. Again, we talked earlier about being able to look at metadata. Here, we're looking at JavaScript. So things that are normally not even really considered from a security standpoint, you know, really providing that visibility, 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, again, 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, this is the, the incident-based view for security analytics. So here you can see here, you know, 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 IP 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, in, in the packet itself. So those are, again, overt types of attacks, not covert. So, combination, kind of a blend of attacks 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 I we hit all of the important slides here. Yeah, no, I think that's great. Thanks for showing the dashboards of load balancer with traffic going through it. I think it's really important to see the visibility, and there's a lot more to see that'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 know, you typically have a kind of like a blind spot from your client that hits your BIG-IP appliance, but we're able to see that with Distributed Cloud. Thank you, Lyle, for mentioning that. Also, the Distributed Cloud platform, the infrastructure is currently under FedRAMP review, and it should be ready. I think the hope is by the end of the year. Looks like we did get the survey, thanks to the person that mentioned that earlier, that this particular session was not listed. If you go into that link now, it's actually kind of funny. They put the wrong date in there, but the session is now listed. So if you see a session for September twelfth, it's actually today's session, September thirteenth. So go to the session that says September twelfth. We really appreciate the feedback. You know, this is very important to where we think the company is going, and, you know, 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. We definitely would appreciate feedback, helping us steer the content that is gonna be most relevant and most helpful for you guys. So, yeah, we'd appreciate the feedback on that. Looks like Chris has just pasted the link back in the chat there, so. Hey, Josh, did Lyle answer your question on your data sovereignty question, which I think is a good point? Yeah, I just wanted 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. Yeah, absolutely. That wasn't something that either our SE was aware of, and it wasn't made clear initially. So I just wanted to make sure anyone else who was looking at moving to it was aware of that as data sovereignty was an issue. Yep. Yep. No, I appreciate you bringing that up, Josh, because that is a very i t, you know, it's definitely within, like, government and revenue department industries, where it's really important that the actual, where the data is located is known and where or not, like, decryption does take place. And to your point, when a tenant is purchased within Distributed Cloud, you are assigned an IP address, and that IP address may not be specific to a U.S.-based RE. Now, there is a setup, there's configuration to where we can restrict traffic, so that's not anycast network. So users from anywhere in the world can access your site, if that's what you want. You know, obviously, we just talked about source policies and how we could block that. But, you know, we can allow anyone to access the sites, and what happens is that they would route to the nearest RE, but 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 that does require an additional IP address cost. It's not overly expensive, a yearly cost, but it is an additional cost that, you know, most folks like to get quoted prior to, you know, figuring out budgets and stuff. If there's any additional questions to that, within the group, please let me know. And thanks again, Josh. I think that's a great point for government customers. All right. Does anybody have any other questions before we wrap? Just one more question. What is your opinion if 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? You're talking about the Silverline for WAF or for DDoS? Yes. Probably WAF. WAF. Yeah. So the WAF in Silverline is based on Advanced WAF or ASM. And, you know, as we talked about before, it's a very different paradigm in terms of creating and managing policies. I mean, I'll, I'll let Chris, I'd love your thoughts on this as well. My opinion is, unless there's a real compelling reason to port those A- those Advanced WAF rules over, or Silverline rules over, I would probably start fresh, right? With, with the new paradigm, rather than trying to, you know, take old wine and put them into new bottles. I would, you know, kind of, kind of start fresh, just because it, it's an opportunity to kind of move into the future and start to modernize the way things are done. Kris, since you, you actually came from an operations background, I'd love your thoughts on that as well. Yeah, I know, this is a great question. I was like, "Ooh, I got, I got an opinion." I, I, I agree with Reid, actually. So, you know, Silverline is effectively using ASM. It's a- it's an older version of our WAF solution on BIG-IP appliances. And so, you know, there i 'm sure you know, and, 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, don't play nice, period, with any WAF, right? So I would take a look at those exceptions where like, yeah, no matter what, this particular call just doesn't work with y ou know, 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 in Distributed Cloud and see what it comes back with. My hunch is that Distributed Cloud's 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 wouldn't need to be made anymore in Distributed Cloud. But I would keep a keen eye out for, like, some of the socket libraries that just don't play nice with anything. I hope that makes sense, Josh. It makes sense to me. I just like getting other opinions, because that, that was my, my thoughts as well. Nice. Yeah, and it's cool to let it run in transparent mode and, you know, it's gonna let the traffic go through, and you get, you get an opportunity to see what 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, we're well aware of Zoom burnout, so we appreciate everyone 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, I'm, so far, I would say 99.9% sure it's gonna be great until end of day, 5:00 P.M., Pacific Standard Time. But if you need more time or you'd like to invite other folks to run through this lab or any other lab that's been presented throughout the course of this Live Test Drive series, just let your account team know, and we can set it up for you very easily. All right. Thanks, everybody. We appreciate you joining, and look forward to seeing everyone on the next one.