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

Welcome to today's webinar. My name is Stephanie Kubina, Webinar Program Manager from F5. Before we get started, I'd just like to go over a few basic housekeeping tips. If you have a question, just a reminder, please submit it in the QA engagement widget you see on your screen. We'll be addressing questions at the end of the webinar, time permitting. Also, you can download various resources in the resource engagement widget you see on your screen at any time. And also at the end of the webinar, a webinar survey is going to pop up on your screen, and we really do appreciate your input. I'm just doing a sound check right now. Can you let me know in attendee chat, if you don't mind, what state are you listening in from today? All right. Let's get started here. So today's webinar focus is on API Security Going Beyond Discovery with Comprehensive Protection. Presenting today, we have Dave Remington, Director of Product Management from F5; we have Cameron Delano, Security Solutions Architect from F5; and we have Ian Dinno, Senior Product Marketing Manager from F5. All right. So Ian, I'm going to go ahead and give you control, if you can please get us started. Thank you.

Perfect. Thanks, Stephanie. Hi, all. So my name is Ian Dinno. I'm a Product Marketing Manager from F5. And what we're going to talk about is API Security and specifically API Protection. And so this is a follow-on to a webinar we did last month that was discussing Shift Left, the left side of this diagram and the importance of that to comprehensive API security to focus on the value and the reasons for integrating that critical security capabilities earlier into the software development life cycle, into the dev process and dev work streams. That is just so critical to reduce risks and API exposure, helping organizations find APIs before they go into production, inventorying, et cetera. That's so critical to do before they're running in production and exposed. Really, that should be the last line of defense rather than the first. And so discovering, testing, providing specific risk information on APIs prior to production is so critical. It allows defenders and app teams to find and test and validate potential API security gaps well before production. So that once in production, they can focus on continuously monitoring to find drift in schema, identifying behavioral anomalies that could be indicators of attack or compromise, identifying sensitive information in PII, possibly being exposed and enforcing and controlling and applying API protection policies and controls. So that right side is now what we're going to be talking a little bit more about today, that Shield Right of the diagram. And don't worry if you weren't able to join that webinar, we'll make sure that in our response after the webinar that you have that link to view that Shift Left webinar on demand. So let's kind of dive right into the Shield Right concept that's outlined here in this slide. And so with that, Dave, I'll bring Dave in. And first, I just want to talk a little bit about -- the first thing we're going to talk about is the vulnerability. So what risks do vulnerable unknown and unprotected APIs introduce to the business? What threats should organizations be worried about most when it comes to vulnerabilities and attacks targeting APIs? So I just -- Dave, before I hand it off to you, I think most of the security needs related to APIs, they're different than web apps, correct?

Yes, they are. They may be web apps, right? There are web apps that are powered by APIs or that leverage APIs. But that's not necessarily the case. You may -- you will often have APIs that are stand-alone services that are used for business-to-business communication, for example, transactional APIs. APIs that are intended to be leveraged primarily by automation for integration purposes or APIs that are primarily for mobile apps. And each of these poses unique challenges. One of the most critical differences between a traditional web app and an API-powered service is that with a traditional web app, you usually authenticate a user and you can track that user. You've got a session cookie, right? Identifying what constitutes a session or a legitimate flow or a legitimate use of multiple APIs is a much trickier game when it comes to APIs. And another real problem with APIs is, as you mentioned, unknown APIs. It is very common for the security teams in an organization to not be aware of all the APIs and where they are. So you really can't protect what you don't know about. And so even understanding your full inventory of APIs and what behaviors they have can be tricky to wrap your arms around. And another thing that's really challenging for APIs is that organizations that are deploying APIs are typically deploying them for new applications that are driving new business initiatives that are high profile. And so protecting those APIs is not just critical because of the nature of the transactions and data that they process, but these APIs can be very prone to business logic vulnerabilities, where the description of how to legitimately use the API and the enforcements around it are overly permissive. And the API allows -- it functions and it does what it's supposed to do for legitimate clients and legitimate users, but it allows behaviors that can be exploited for abuse in ways that some of the tips and tricks and techniques that we've developed for protecting web apps over the years aren't as applicable. And I know, Cameron, you've been thinking a lot about this. I wonder if you want to drill down into some of these vulnerabilities and how they apply to APIs.

Well, let's just take a look at the OWASP API Top 10, the counterpart to the standard OWASP Top 10. We see some of the same threats that traditional web apps are seeing, but also attacks that are specializing and targeting APIs specifically. And these are attacks that similar to, as you mentioned, they take advantage of the reduced ability to rely on things like session control or client awareness as well as new categories of threats that are attacking and exposing the stateless nature of APIs. So we'll see traditional attacks such as a SQL injection or a server-side request forgery alongside attacks that are going to try and manipulate logic or gain access to an object or its properties.

Perfect. Perfect. So now that we've talked about the nuance and why the types of threats and attacks around data, around business logic, that need to be protected, just the critical nature of APIs now and the functions that they enable. The next question and things we want to dig into is a little bit more about why are they becoming such a significant target? And we alluded to this, Dave already alluded to this. Just APIs represents just this growing threat surface and the pace and rate of changes is exponential when it comes to APIs. The use and pervasiveness of APIs is growing, expanding that threat surface that they represent and some of the research that we've done in our State of Application Strategy Report for 2024 organizations with revenue between $200 million and $1 billion reported having on average 235 apps, but almost 500 APIs. So -- and along with this, just the rise in growth of agile development and DevOps practices, you have new services, new APIs and updates happening a lot more frequently, so again, that could introduce as those APIs change as new ones are introduced, that introduces more to protect and other potential vulnerabilities that need to be identified and then taken care of either through code updates or some type of protection or control to put in place. So the other thing is just the increase in criticality, right? So APIs are responsible for more critical business function and accessing and transferring more valuable information, right? So just some key things to keep in mind as to why they are becoming such a right target. And Dave, do you want to expand a little bit on that on some other reasons why there's such a target?

Yes, for sure. And there's a sensitivity associated with these. If you think about your phone, right? Your phone has dozens or if you don't clean up like me, may have hundreds of apps on it, and we expect that when we tap that icon, right, it works immediately every time. When we use the app, we expected to act immediately all the time. And that means that the sensitivity for impact to APIs is 0. There's no sensitivity in an organization to have APIs offline. They may be tied into automation, and we can't have APIs that are able to be overwhelmed or that are intermittently unavailable or prone outages or have maintenance outages. The things that we used to do maybe now are not acceptable anymore. We live in an instant-on world. And so that's one of the reasons why the sensitivity of these APIs and the apps that they're driving are increasing in criticality. But another thing that we see is that we have less knowledge, less understanding, less mature tooling and less mature security practices around API security. We have about some of the new threats that are either easier to do against APIs like business logic attacks, or attacks that are due to the stateless or sessionless nature of APIs. All of the broken authentication vulnerabilities would be easier if we had user sessions and we were enforcing user sessions in the same way that we do an old sort of OG web apps. And so -- and this is not to criticize anyone. It's just that the APIs for many organizations were this thing that they maybe had a little bit. Maybe 5, 7, 8, 10 years ago. And now it's how everything is being built. So security practitioners have to up their game, the vendors that are supplying some of the solutions have to up their game. And we really need to increase that maturity. When we talk to organizations, over 50% of organizations report that they have no API security strategy or are in the exploratory mode for developing an API security strategy. So if you're little behind the curve, don't feel bad because you're with the majority and only a tiny percent, less than 5% say that they have what they would consider to be a mature and robust API security strategy. So as an industry, we need to learn. We need to develop more knowledge, and we need to understand what tools help and how they can help us. Another thing that is really a challenge with APIs is that a lot of the legitimate traffic to your APIs looks just like a bot. So all of the things that you could do to eliminate script-based recon tools and can exploit tools or to prevent things like web scraping or to prevent things like denial of inventory or those kinds of activities are not relevant if this is an API that is exposed to a business-to-business or a machine-to-machine type communication. We can't look at a cookie on the client. There is no cookie. We can't try to determine what browser version that is. They're still browser version. So all of our techniques for bot mitigation, we can't inject JavaScript. We can't throw up a captcha. So none of these things are effective. And that really means that we have to discern the difference between good and bad actors based on observation and heuristics and machine learning and AI instead of relying on more let's say static or more well-understood techniques. So really, the challenge here is that if I'm an attacker, I know that the tools are less mature. I know that there's new exploits. I know that there may be less expertise. I know these are being rolled out super fast. So maybe there's less security rigor than when we had, we would release a wave of an application three times a year or four times a year. Now we're doing it every day. So if I'm an attacker, I see, hey, this is critical, its carrying really important information and there's all these cool new exploits that I can go look for. And that's why in our platform, in our SaaS platform, we see that over 90% of the attacks that we block are aimed at APIs now. So it's by far the most attacked target in organizations and the attacks can be very damaging. So I'm just curious, Cameron, if you have anything to add to that about, I know you're very familiar with the development process and how automation is built. I wonder if you have any insights from that perspective on this.

Sure. Yes. So as you mentioned, that always-on type of paradigm that we're working under and an increased focus on time to value. Well, we have our traditional applications that may not fit into that pattern. So in the desire to modernize and decompose those apps into something more modern like a micro service, it's resulted in the loss of security controls that were perhaps provided by parts of the application that may no longer exist or that can be easily bypassed. For example, an application that was relying on a front end to provide things like auth or response data filtering. Well, with that front end now being decoupled from the underlying APIs providing the services, it often leaves them wide open to attack or responding with unfiltered data. And attackers know this and it makes them very, very low-hanging fruit from a target perspective. There are no authentication in front of them. There's perhaps a call from the front end that would respond with a very small subset of information contained into a back-end database record. Without that filtering, it might just kind of throw the entire record out there and all of that data, which could be PII data or any other type of sensitive data.

Perfect. So yes, thank you, guys for digging into that a little bit as to why are they vulnerable and why are APIs vulnerable? And why are they such a target. But that goes to the heart of what we're talking about today. And so the next topic and really the how, how do we protect, how organization is doing it today and what are some of the best practices in terms of capabilities to look for shielding right and protecting APIs in production. So Dave, how are organizations, how are we seeing most of our customers and organizations protecting APIs today? What are some of the common tools and practices that are in place today.

Yes, that's a good question. So of course, we have this new thing called API security. It's not really new, but that has emerged to address some of these gaps. But we really need to understand that API security or securing your APIs is a holistic approach. We need to enforce authentication and authorization. We need to look for like Cameron mentioned, just old school web attacks like injection attacks. And so what we see organizations do and what we advise them to do is if you're going to start protecting your APIs or increasing the level of protection for your APIs look at the tools that you have first. What can your API gateway do for you? What can your WAF do for you? If you've got a robust WAF, it probably parses most of the API protocols and can look inside and apply granular policy to the parameters inside the JSON for example. So look at your tools first because they're going to provide a lot of the protections you need. Your WAF or perhaps a SaaS service is going to provide Layer 7 DDoS protection, for example. And these are all important and necessary components of an API protection strategy. But they still have a gap. And one of the gaps that I'll talk about is web application firewalls for example have been able to do API schema enforcement for a long time. I know Cameron is going to drill down on this. But it was underutilized, maybe even not utilized at all. And this is because in most organizations, it was not really feasible to have a schema that the security team could confidently enforce. It might not be very strong, so it might provide a false sense of protection or it might just be old and outdated and not maintained properly. And so if you started enforcing it, it would block that. So what we also need to do from a security perspective, is apply the discovery. Both in various environments, talk about traffic, traffic-based API discovery. We could talk about other types of API discovery. Where what we're doing is finding all the endpoints, which helps with the, you can't protect when you can't see problem. But also in the process of doing that, we're identifying vulnerabilities and we're identifying legitimate patterns and behavior in the APIs, and that provides the foundation for doing things like behavioral protections, flow-based protections or pseudo flow-based protections that allow us to identify bad actors, identify abusive use of APIs by using higher order mechanisms like AI and machine learning to protect against these new attacks. If broken authorization of various types are a pretty -- a big problem. And it's very difficult to statically protect against those. Because the whole problem is that the app for the API is written wrong, or the authorization is enforced improperly. So you have to have some way to identify that a particular token is accessing things that it shouldn't or you have to be able to identify that you have private objects in the API and that every user should not be able to access every private object. And so -- because typically, you'll see in the pattern, user bill access is one private object whenever they go there one version of the private object, and Debbie gets a different one. Well, if Bill can also come in and get Debbie's private object, private information, that's a BOLA or a BFLA vulnerability. And you can really only protect against that by observing the legitimate behavior and being able to interject that bad behavior. So that's why we have this new category of capabilities called API security, which is what happens in the industry. We identify a gap, we come out with -- in the old days, we would come out with a pizza box that you put in your stack. Now we come out with new functions or new services in our SaaS or new capabilities that we deploy as a virtual machine or whatever, but it's basically the same thing. And over time, what also happens is that these merge together. We used to have a whole conga line of pizza boxes and then we started getting UTM firewalls, which smashed a bunch of stuff together, and those grew into next-gen firewalls. We had WAF and then WAF started taking on bot protection, and they started taking on Layer 7 DDoS protection. And so we'll see that as well with API security. At some point, it will stop to be a discrete product category. It will just become a set of capabilities. But today, this separate product category exists because it's addressing this gap that we have. And so when you take those together, the current tools that you have and then identifying where your gaps are in your organization and then seeking out the capabilities that you need to plug those gaps, it's really going to give you a good strategy for as we said, half of organizations don't have a strategy. Well, that's a really good start. Find your APIs and identify what gaps you have in your tool. And I'm just curious, I mentioned some stuff there. I know that we have a lot of capabilities we talk about. I don't know if you want to drill down on that a little bit, Cameron.

Sure. So schema validation could almost be table stakes when it comes to API security. And it's really the easiest way to do positive security for an API, but only if the scheme is active and up-to-date. Accuracy for the schema is extremely critical, and it actually makes something like validation useful and safe. Properly implemented, accurate schema run with validation run against it, could knock down so much low-hanging fruit, help reduce false positives. But the problem is that accuracy piece. And how well is our schema being maintained? Is it being generated from, just from code? Well, if there's problems in the code, there's going to be problems in the schema. So -- and that's going to turn into the enforcement being bad or not adequate. So at that point, we can't really assume that it's going to be 100% effective. So -- but when you combine code-based discovery for the day 1 or day 0 implementation or a release of your application, combined with day 2 type, day 2 plus type things like traffic-based discovery. This allows us to validate and improve the schema because it's constantly being updated by what we see in traffic. And by relying on the code, you're trusting them to use it as intended. But when you add traffic-based schema discovery as well, you're enabled to turn on validation, be confident in that validation and actually ensure that it's being used as intended instead just trusting that will be used as intended. And that's one of the key value propositions for distributed cloud API security.

Yes. Yes. So Dave, you talked about some of what organizations are doing today, whether that's API Gateway WAF, how they play their roles to control access, authenticate clients, rate limit, filter API-based traffic, API traffic based on known signatures, they play definitely a critical role in limiting reducing that attack surface, potential exposure via APIs in production. But -- and you've hit on some of this a little bit, but in terms of like some features and capabilities that organizations should be looking in their -- as they build their strategies to protect their APIs in production what are some of those key features and capabilities they should be thinking about implementing. Obviously, we did just talk a little bit about positive security and schema enforcement. What are some of those other things that they should be looking for?

Yes. And to sort of double down on what Cameron said, it is discovery that has come along and made schema validation practical. You can now build a closed loop, where you do the discovery in a continuous way, you constantly keep your schema updated. And that means that you're enforcing the behavior that all of the legitimate clients are being told they should be doing. So you get the ability to use that type of positive security because you can now rely on the schema. But there's other controls. One of the controls that's understood, but often overlooked is how we need to use rate limiting. And most tools have some sort of rate-limiting capability. It might be a fairly blunt instrument. It might be rate limiting by source IP or something like that. It might be rate limiting for the whole FQDN, perhaps rather than per endpoint. But there are certain types of end points that should always have rate limit. You should always have a per client and define client however you want to, a per client rate limit on your log in APIs. You could be fairly permissive but you certainly don't want people to be able to try over and over again. Even if the back end may or may not properly enforce that, you can ensure that there's a maximum amount of tries somebody can have by implementing rate limiting and you should do that. Other examples are heavyweight APIs that generate a lot of back end work. You should rate limit those so that you're constraining the behavior within a reasonable bound so that somebody cannot do just generate a denial of service by overloading a service. And there's other types of things. A denial of inventory where I buy all the tickets for the Taylor Swift concert. Or that's a problem. All of these ticketing companies, for example, have this problem. And rate limiting is not the end-all be-all protection against that, but it sure does slow that down. So you can build rate limiting instructions into your schema, so that legitimate clients will obey it. But you should also have an actual in-line control to enforce your rate limits. And those rate limits, it's useful if they cannot just be per IP address. It's useful that you can rate limit per each token has a specific rate limit, and that rate limit can be granular per API endpoint, different endpoints have different utilizations or maybe you can rate limit based on a cookie or a header. Those kinds of things that might be present in the traffic as defined by the application's behavior. Another thing that's really important for APIs is understanding the sensitive data that's in your APIs because when you have to triage and focus your development efforts and focus your remediation efforts, you really want to understand, first, the criticality, like where am I being attacked, where am I most vulnerable, but I also want to understand which endpoints carry the most valuable data. So what is the exposure associated with your various APIs. And being able to identify where you have simple things to detect like credit cards or social security numbers, but perhaps other interesting information like an address might be very sensitive depending on what type of service you're offering. So or what type of users you have. So understanding all the different types of sensitive data can be very important for helping you understand how to prioritize your work and understand where your greatest exposure is. And then also, if you've got the identification of all of those sensitive end points, you also know now, hey these are good places to rate limit. And I may or may not be at risk of violating compliance requirements from all the various compliance regimes that we might have to be in [ begin clients ] with. I can't think of a better word. But we want to understand where the most important data is traversing and where the most risk is in addition to having these kinds of controls on the API itself.

Perfect. Thanks, Dave. So we'll kind of stay with that high-level topic about capabilities. We talked about discovery via traffic. We talked about positive security, rate limiting and Layer 7 protections and then the data security and limiting and masking and blocking of sensitive data. In terms of -- and this, Cameron, I'll start with you here. What role can AI/ML play in helping organizations get ahead of the curve? What capabilities rely on this that -- and how does that benefit organizations in protecting their APIs?

Sure. So to start with, we can talk about that continuous traffic-based discovery that we've been discussing. Learning and analysis of the API structure and function to augment what was found from the discovery from code. And that gives us that additional lens to find Zombie shadow or any other type of undocumented or unknown API. . And one piece that we often, when we're talking about discovery, we often focus on things like the structure discovering what type of methods are being used, what parameters are in the body. But there's another piece of it, and that's kind of harking back to what Dave mentioned before. Well, discovery doesn't just find the API structure and function. It looks actually, it's looking at the entire traffic flow. So if something is coming through with PII, it discovers that as well and presents that. If there are -- it runs discovery on the authentication piece as well. So if there's problems with, say, the JWT token or something along those lines, those are going to be bubbled up to the user as well. And then kind of the detection and blocking of malicious clients based on anomaly detection. So this is looking for -- we'll analyze the traffic, get a baseline of what -- this is what we know good traffic should look like. And then if we start seeing anomalies outside of that or significant changes in that, those could be indicators for the potential for attack or that something otherwise malicious is happening. There's also another piece of that behavioral thing kind of looking to the future of what can happen. So once we have that baseline of what, this is what traffic looks like, this is what our normal volume of traffic looks like. But moving into a time where the scanning is running on that baseline and maybe there's an increase in traffic and having been able to automatically determine a rate limit based on the volume of traffic and then presenting that rate limit recommendation to the engineers to accept or deny or if we get to a point where we have enough faith in this to have it automatically start kicking in that rate limit based on just deviations from that base pattern that we've identified. Dave, I know you have some thoughts on this. What are your ideas?

Yes. And well, I will say the one -- the elephant in every security room at every company on the planet, every organization today, is AI now. So API Security had its brief moment in the limelight. We were the most important problem until this AI explosion came around and now everyone's freaking out. And I think rightly so about how they're going to securely use AI. And so this is really a challenge from an AI/ML perspective because, first of all, you really -- it is really quite challenging to secure like an LLM. It's very challenging because there's -- it's usually free-form input, and you can cause them to give all kinds of data that you really would prefer they not depending on what you've trusted the LLM with. And there's lots and lots of sneaky ways to get around, if you got some basic prompt security or whatever. There's lots of ways to evade them. You've got a problem where you, hey, here's a proxy. I'm filtering for legitimate prompts, and they just take a photo of the malicious prompt they want to do and upload that to the LLM and guess what? It may give the answer that he preferred it not. So this is a place where the only really good way to robustly protect AI is with AI itself. That's the only way we're going to build anything beyond sort of a heuristic-based protections. And the other problem that we have that AI has brought into our world is that it's very, very easy to build attacks using AI. So we have an arms race going on where the speed with which sophisticated exploits, possibly for a specific organization and a specific application can be generated rapidly. So zero day has become like zero minute almost because it's so easy to craft a sophisticated exploit using these new tools. And so again, it really is something where as security practitioners mandated it to protect organizations against these things and we really need tools that are as sophisticated as what the attackers have.

Yes. The speed, the response. So thanks, Dave, for that. So as we look to kind of round out, we talked a lot about a different set of capabilities to Shield Right. All the different controls and insights and capabilities. But you alluded to this a little bit about like 50% of organizations don't have like an API security top-to-bottom strategy. So when we talk about all these different controls, whether it's like the traditional WAF API gateway, when you're talking about traffic-based discovery, you're talking about out of band discovery or rate limiting for APIs, some of the data security, discovery and security elements, like when it comes to all of this, where and how should organizations be thinking about putting this together and applying these in their environment.

Ian, excuse me. This is Stephanie. I have a really good question here for David. .

Yes.

Okay. So the question is, can you provide insights on the best practices for rate limiting in distributed environments. Can you answer that, Dave, please?

I can. I'll try. Let's just put it this way. I'll try it. Distributing environments are really a huge challenge, for everybody. And it actually directly relates to the question that Ian just asked. And as security practitioners, we really have often very little control about where APIs are published. We may have business units that are publishing APIs in edge services. We may have -- we're publishing APIs in Azure or AWS or Google, pick your poison. We may have APIs that are shrink-wrapped and offered as a package, but deployed by a SaaS service under our domain with our data. It's our problem if it gets hacked, but we don't control the environment. So distributed environments is the nature of the game. It was supposed to be simple. We were supposed to move all of our stuff from the data center to a cloud. And then we were we're done. We'll all be happy. But what we found is, we're not moving everything and we're not moving it to a cloud. We're moving it to all the clouds. The vast majority of organizations use more than one cloud, for example. So what we want to do is look at our tooling for the different types of controls. And to the degree possible, you want to identify where you have consistent tooling. So if you have standard on, I just found a specific API gateway, that's probably the best place to enforce authorization and authentication. Because now you've got a tool that is, if not ubiquitous in your environment, maybe it at least supports the majority of all your APIs even if they're running in different clouds, for example of running in your private cloud. I may have a laugh that I've standardized on or mostly standardized on where I can say, hey, I'm going to do basic WAF inspections of APIs with this tool rather than trying to figure out how to use the different WAFs in all of these different environments. And for rate limiting, I think the gist of the question is not just what tool should I use but how do I actually rate limit? And that's actually even pretty big challenge because I may have 20 front ends for an API distributed across the globe. But I want to enforce a rate limit that prevents scraping, for example, or whatever. It doesn't really matter, a log-in, whatever. And it's ideal if I'm using a tool that is sophisticated enough to understand that the intent behind the rate limit controls is not a per instance or per security tool instance rate limit. It's actually a rate limit that's enforced across that distributed environment. We happen to have that in distributed cloud. That's the way our rate limiting works. But -- so looking at tools and identify because the alternative is to do the math. It's like, oh, if I only want 100 per second, and I've got 5 sites then I've got to limit it to like 20 -- or 20, maybe I give 25. So there's a little bit of room for variability. And that's probably pretty difficult and probably hard to operationalize. So I would say that the recommended practice would be to try to find a tool that is sophisticated enough to have distributed rate limits for that. And I think that would be the best solution for that challenge. And another thing that's a challenge in distributed environments is responsibilities, who is responsible for the various tools. And it may very well be that the wrong team has operational authority over the best tool. And so maybe where the security team and the API gateway is run by the application teams. And actually that happens fairly often or maybe it's an infrastructure team versus security team. But the security team still is responsible. It's our boss that gets to go to court if we get a breach. So we wanted to make sure that we could control that. So sometimes we have to address a security control in a tool we don't own. And in my opinion, the best way to do that is, first of all, develop the relationship. But secondly, leverage automation. Because you can work together to build the automation to control that tool that you don't actually log into and manage on a day-to-day basis, but you can define the requirements for it. And you can ensure the results of it, and you can monitor if it's being effective and you don't need operational control because you baked it into the automation in your environment.

Perfect. So David, that's a broad topic. I know we're not going to solve it today. And there's so many factors that go into that. So thank you for kind of addressing that. And to round us out before maybe couple of questions or something, we'll check back in with Stephanie here in a moment. The final thing we just wanted to touch on was F5's position and vision in helping customers with API security. And really, what we're working on at F5 is delivering the capabilities necessary to provide complete API protection that expands, spans the entire app and APIs life cycle from build and test through to release, operate and monitor. Really giving organizations a tool to more effectively discover and track all of their APIs to more easily govern and manage their inventory and documentation and secure their APIs with continuous inspection, uniform policies and schema enforcement with the capabilities to protect any API, any app and API anywhere. And so Dave, Shift Left, Shield Right, we talked a little bit about that. And we -- in the previous webinar, we talked about Shift Left, we addressed it at the beginning. Today, we talked a little bit more about Shield Right. So how do those -- what's the importance of fusing kind of those two viewpoints, if you will, and those capabilities together into a unified solution. What is that -- what's the value of that?

Well, so I can give you a really practical example. I may examine the code with my code scanning tool. And I may identify that I have an unauthenticated API end point that carries sensitive data because I've detected that in the traffic, detected it by examining the schema and it's not authenticated. But maybe it is authenticated. Maybe the actual authentication has been delegated to a gateway. Well, how can I know whether or not I have risk. Well, I can know whether or not I have risk, if I also I am doing dynamic testing, and I'm probing production-like environment. And I go and I try to do authorization, I try to do an authenticated request, and I get rejected. Or maybe I see that there's inadequate granularity in the user enforcement based on how the schema is defined, the security controls, or by looking at the code. Again, the gateway might be enforcing that, based on groups in active directory or based on a single sign-on provider, whatever, and I will be able to say, okay, I tried to get Debbie's information as Ben and I couldn't in the real environment, even though the code looks like it would allow that. And so that's why you have to have all of these functions working together and providing this holistic view because, first of all, it's going to dramatically reduce the amount of times you ask a developer to fix something and they come back and say you idiots, it works perfectly. It works as intended. You want to make sure you're focusing your resources and time where you need to. But also you can gain better insight. If you're only looking at code, you're not seeing the behavior that real clients have. If you're only looking at the schema that was provided, there may be vast gaps in the schema. And by observing legitimate users over time, you may be able to harden that schema and tighten the controls in it so that it's better able to enforce, for example, parameter length and type, maybe build an expression that defines the legitimate pattern within that parameter, for example. And so all these things working together give you better security, but they also make your operations more efficient because you're not saying, okay, my code scanning tool produced this output, and we're going to look at that my [ DAST ] tool produce this output. I'm going to look at that in my run time environment found all these problems, I'm going to look at those, and if it's not all fused together, then it's going to be exponentially more work to try to piece all that together, manually.

Perfect. Perfect. Well, thank you, Dave, and thank you, Cameron. Stephanie, do we have time for maybe a question or 2?

Yes. All right. We're sorting through the questions. One question I liked was, what is the best starting point to securing an organization's APIs?

Yes. I would say it depends. And Cameron, I don't know, do you have some thoughts on that?

Sure. So the best start, place to start is to take a look at what tools you already have and make sure that you understand their capabilities because you might already have something that can be the beginning of your API security strategy. And then after that kind of start branching out and seeing what else is out on the market and what else is will solve the most problems you have with the amount of -- with the most amount of ease. So you don't want a bunch of disparate tools out there where you're having to go out to each one of them to provide a subset of security for the entire piece that you need. So try to get the best solution that solves the most amount of your problems. But definitely start with taking a look at what you already have and then move on to augmenting that.

Yes. And if I could just jump in, just a second. That's a great answer. Another thing you can do right now to make your API security get stronger and stronger, is educate yourself. Seek out training. Our friends at APIsec University have a whole bunch of really good free training that you can take that will help you understand or there's all kinds of courses on Udemy and all those other places that will help you understand what's new and dangerous about APIs. Go look at [ OWASP's ] research. And that will let you understand what kind of tooling you should be looking for, what gaps you actually have. So education is also some place that you can go to, to really up-level your security.

Yes. That's definitely the best starting point, learning about it first.

Okay. So we have time for one more question. I see here. We don't want to mess with production traffic, what are our options for API security?

So I'll answer that, and I know that our time is precious now. But really, if you don't want to mess with production traffic and by that, I mean, maybe we don't want to sit in line and have intrusive in-line controls. First of all, I would say that you're going to have some controls in line already. And so maybe you can do some instrumentation there. But you can do vulnerability detection, you can do API discovery, you can do code analysis, you could do dynamic scanning. So you can use a lot of these capabilities and drive them back into the development process. So if you're not going to implement as many tools in production, you have to be much more aggressive about finding the problems and driving them back into the development teams so that they can be remediated quickly. So there are organizations that are reasonably successful securing APIs without a lot of in-line tooling. At F5, we obviously think that in-line tooling is pretty darn useful. But if you're not going to do that or there's an environment where you can't or don't want to do that, you just need to have tools that tell you where all the problems are. So the developers can fix as many of them as they can remediate.

Perfect. Thank you.

All right. Well, thank you very much. Unfortunately, that's all the time that we have today for questions at the end here. But any questions you did submit we didn't get you, I promise we'll address after this session. And as always, if you could just take a few minutes, please to fill in our webinar survey, we really do appreciate your input. And thank you, everybody, all our wonderful speakers today. And we look forward to seeing you at future F5 webinars. Have a great day, everybody. Thank you.

Thanks.