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

Hi, everyone. Welcome to today's webinar, API Discovery, Inventory and Security. My name is Stephanie Kubina, Webinar Program Manager from F5. Before we get started, I usually like to go over a few basic housekeeping tips. [Operator Instructions] We'll be addressing questions at the end of the session, time permitting. Also, you can download various resources in the Resource Engagement widget you see on your screen. We have today's presentation as well as other informative resources. We also do appreciate your input at the end. If you could just fill in that webinar survey, we really do like your input. So I'll remind you also at the end to fill that in. And to see if you're listening, I do have an Attendee Chat feature. Can you let us know where you're listening in from? And that should be under the Attendee Chat area. And also, we have these emoji reaction icons. So throughout the presentation, if you can give us a thumbs up, a smiley face, let us know how we're doing. Presenting today, we have Joe Martin, Senior Solutions Architect from F5; and we have Cameron Delano, Strategic Security Architect from F5. And Cameron, looking forward to today. Can you please get us started? Thank you.

Great. Thanks, Stephanie. So I just have a few slides here, and then we'll jump into a demo of some of the API discovery and security capabilities of the F5 Distributed Cloud Platform. APIs have been top of mind for a lot of us these days. I was recently at a conference, and I was giving a booth talk on API security. And as I was developing what to say, I started thinking about how many APIs I was interacting with just in the morning on my walk down to the conference center. So I'm a runner, so checking the weather app to see if I need sunscreen, syncing my fitness data, checking my bank data, and when it was over, scheduling a Rideshare to the airport, checking my flight. And we use APIs for everything from the most essential to the most mundane. And more and more are being created every day, all driven by our desire for convenience in the palm of our hand. And even if every new like It tech thing that we see, whether it's blockchain or AI, a lot of these services are being extended and consumed via API. So it's a very timely discussion. API requests currently comprise roughly 83% of all Internet traffic. And API calls have been growing 300% faster than overall web traffic. And according to estimates by F5's office of the CTO, the number of APIs in production will increase exponentially over the next few years. And by 2030, there could be anywhere from 500 million to more than 1 billion APIs in production. And that is a very large and complicated tech service. So complicated, in fact, that it's led to 9 out of 10 enterprises have reported to having experienced an API incident. And we've seen recent breaches that have exposed the personal data of millions of people. I personally have had my data leaked at least 4 times that I know about. Most recently, my DMV leaked -- exposed the data of everyone in my state with a driver's license or an ID. So that's great. It's not just a pitch, it's personal to all of us, and data leaks can have serious consequences if exploited. So as citizens and consumers, we need it taken seriously. So how are APIs being attacked? Well, luckily, we have the OWASP Foundation to provide us that information. This is the updated 2023 API Security Top 10. And we see many attacks that we're used to, DDoS attacks, man-in-the-middle, injection. And we also see attacks related to insecure API key generation, auth hijacking, and it's all exacerbated by insufficient logging and monitoring. So if you haven't taken a look at the recent updates to the top 10, I highly suggest.

Hey, Cameron. The one thing I thought would be interesting to mention here is, while there is certainly some overlap in the OWASP Top 10 for web apps with the API Security Top 10, there is a lot of this that is unique to APIs. And unfortunately, if we go back to the first OWASP Top 10, I can't remember, it was like 2004 or '03 or -- I can't remember when it was, but some of these same things were on that list. So APIs, unfortunately, while there is a lot of sprawl, the protections of them where we've kind of stepped back a good 10 years in security posture when it comes to APIs.

Absolutely. So how do we start protecting these APIs? Well, we use a continuous approach that is a combination of management and enforcement that includes discovery and learning for the detection of unknown or shadow APIs, authentication status, sensitive data and to generate an open API schema. Also monitoring to baseline endpoint parameters and characteristics and behavior so we can identify anomalies easier. And then, of course, security, blocking suspicious requests, rate-limiting and schema enforcement. So let's go ahead and dig into a few of these here. So API discovery, automatically learning the API surface based on request and response traffic, observing the API calls to determine methods, POST, GET, PATCH, behavior and then valid values. It will build a visual rendering of the APIs as well as a Swagger definition or OpenAPI Specification. You can export that definition and do drift detection on what is defined based on the definition that you're -- or the spec that your developers have given you and what's learned and do drift detection and see what's changed. This is very useful for APIs that change frequently and for discovering shadow APIs. And using AI and ML, models were made for errors, latency, request metrics. And you can get a detailed analysis for how an end point has performed over time. Now behavior analysis, to give us that baseline so that we can easily identify anomalies and spikes and request rates, latency, response sizes as well as identify any sensitive data. API authentication discovery, to authenticate -- or excuse me, to identify the authentication state. The service can document authentication types based on open API spec and associate this data with the app endpoint itself. Also discovers header, payload and signature information in JSON Web Tokens, so identifying useful fields for downstream analysis and visibility. It can detect user roles or user IDs and identify sensitive data in the job token payloads. Also details vulnerabilities and assign a risk score based on what's been found. And since the AI/ML engine discovers and maps all APIs for the given application end points, it allows for the detection and flagging of PII that's been exposed. Organizations can quickly and easily identify any critical PII that's being shared. So remediation can be put in place, such as masking, using the data guard feature. You can also define custom-sensitive data types. So for example, for users that are outside the United States and have a different social identification number format, this gives organizations flexibility and ensures compliance with regional data privacy regulations. And we'll demo a lot of this as well. So one of the cornerstones of API security is schema validation. This ensures that the API requests and responses align with the schema defined in our specification, reinforcing data structure conformity and validating input/output data. The platform provides flexible configuration options, allowing you to apply schema validation to all or specific end points within your API definition. And with multiple enforcement types and customizable sets of properties to validate against your specification, you have granular control over that process. And additionally, you can create fall-through rules to effectively handle anything outside the specification that comes up, or shadow APIs that may arise. And that's it for the slides. So we'll go ahead and kick off the demo to showcase much of what we just talked about. So this is a recorded demo simply for time purposes, to allow the learning to run and to get everything and to be able to send you off with a link to the demo in case you want to touch back on anything seen. And then following the demo, we'll go ahead and have some time for a Q&A. Welcome, and thanks for tuning in. I'm Cameron Delano, Security Solutions Architect with F5. And in this video, we'll be going over the API security capabilities offered by the F5 Distributed Cloud Web App & API Protection Service. Throughout this demo, we'll walk you through several key features. First and foremost, we'll demonstrate how simple it is to activate the API protection and discovery capabilities within the platform. You'll see firsthand the ease of enabling this essential layer of security. Next, we'll explore the functionality of discovering shadow APIs. We'll guide you through the process in downloading the learned schema and seamlessly importing it into our API definition. The streamlined workflow ensures that your APIs remain secure and compliant. Next, we'll showcase the effectiveness of schema validation and matching. You'll see how the platform actively verifies the conformity of API requests and responses to the defined schema, providing an additional layer of security for your APIs. To conclude, we'll take a quick glance at the end point security posture in dashboards. This comprehensive view allows you to assess and monitor the security status of your end points, empowering you to make informed decisions. So let's go ahead and get started. To start with, we need to enable and configure API protection and discovery on our load balance. Now once we're logged in at the console, the first thing we do is click on the web app and API protection tile. For this demo, we have a distributed cloud load balancer that is fronting the OWASP Foundation's completely ridiculous API. Now since we've not enabled any protection or uploaded the specification file, we have no insight into the structure of the API. And without this, we have no way of protecting it from attack. Luckily, enabling API protection and discovery on the platform is extremely easy. Click on the 3 dots next to our load balancer and select managed configuration. Once the configuration page renders, we click edit configuration on the top right, and using the menu to the left, navigate to API protection and once there, use the API definition drop-down menu and select enable. Next, we click the API definition selection drop-down and click add item. This takes us to the API definition creation page. Once there, we give our definition and name. And in the Swagger spec drop-down, we select upload file. Here, we name the Swagger spec, upload the file and click continue twice. Next, we need to enable and configure spec validation. Under the validation drop-down menu, we select all end points and leave the open API validation processing mode as validate. For this demo, we will leave the validation enforcement type on report. But in a production environment, we may choose to turn on blocking. Next, we choose our request validation properties. We'll keep the defaults of query parameters, path parameters and header properties and add content type, cookie parameters, HTTP body and security schema. Next, we configure fall-through mode for any APIs that are not in our specification. These are our shadow APIs. Here, we'll choose custom and configure our custom fall-through rule list. Once in the fall-through rule page, we select add item to create our rule. We'll give the rule a name and select our action. For the demo, we'll leave it at report, but we may choose to block or skip and continue processing the request. We'll set our rule to apply to the base path and choose the value suggested by the platform. Finally, we need to enable discovery. Here, we click the API discovery drop-down menu to select enable. Now by default, discovery only learns API end points and patterns from traffic with response codes of 200. To also enable learning on response codes of 300, click the learn from traffic with redirect response and choose enable. Now we won't be configuring it for the demo, but I just wanted to highlight the sensitive data detection capabilities of the platform. If required, you can disable a built-in detection based on your requirements. For example, if you're outside the United States and have a different social identification format, you can disable the social security number detection and add a custom-sensitive data type. And now that we've finished our configuration, we scroll to the bottom of the page and choose save and exit. And that's it. It's that easy. Now we need to generate some traffic for the platform to learn from. To do this, I'm going to use the official Postman Collection for the API and Runner function to generate some traffic. For the sake of timing, I've sped this up to give the platform time for the process to run and learn the schema from the traffic. Next, we'll move on to demonstrate the results of the learning and shadow APIs. Now let's head to the security dashboard and see what the platform has learned. Here, we can see that we've made some discoveries. To get to the API end points dashboard, you can click from the API classification trial or at the tab at the top of the page. In this dashboard, you can see APIs that were discovered as well as any inventoried or shadow APIs, if there are any. Now the difference here is inventoried APIs are the ones that we have definitions for, and shadow APIs would be discovered APIs that were not in the definition. Here, we can see the POST identity API auth verify was not in the specification and is a shadow API. And now that our API has been discovered, we can download the spec that's been generated from the learning. Now let's head back and edit our configuration and add the learned specification to our API definition. We just edit our definition and under Swagger spec, choose add item to upload the learned spec for identity API auth verify as a supplement to our existing specification. Now as a best practice, it's recommended to inspect and validate the learned schema and incorporate that into your overall specification. But for the sake of the demo, I'll just be applying the learned schema directly as an addition to the base schema. Now let's head back to our dashboards and take a look at our API tree. Here, you can see identity API auth verify is no longer a shadow API and is in our inventory. And now we can protect it from attack. Now let's run some schema validation checks. Once again, we'll be relying on the official Postman Collection to generate our traffic. We'll modify the body of the request and remove some expected content. In this case, we'll remove product ID and quantity from the POST to the create order API. We'll also set authorization to no auth to remove the expected header. Now we'll send a few requests and then take a look at the security analytics. Here, we can see the events generated by our traffic. If we dig deeper into the logging, we can see our violations. We have a security schema violation due to our missing auth header as well as the HTTP body violations from our missing properties. Now let's take a look at end point security posture and the dashboards. Here in the API endpoints dashboard, we can see data on our top attacked APIs listed in order of percentage of attacks, the top 3 sensitive data types found, the total API calls and their response codes and the most active APIs. In the table view of our inventory, we have data related to each end point. Here, we can see if any sensitive data types have been found, the threat level of the API based on volume of attack traffic, the authentication status, API category and calculated risk score. If we click on the end point, we can see additional details related to its health, authentication, both learned and inventory specification and security posture. In the security posture tab, we can see vulnerabilities found, in this case, our JSON Web Token has some issues. We can also see the description of the vulnerabilities found as well as risk score, evidence and remediation. I hope you enjoyed this quick demo of some of the API protection capabilities of the F5 Distributed Cloud Platform. The connected world runs on APIs. Your banking app uses them. Your Rideshare app uses them, even that weather app you check before walking out the door, it gets that data from an API. We interact with them multiple times throughout our daily life to do everything from the most essential to the most mundane. They are simply everywhere and more and more are being published every day. Given the sensitive nature of the data that can be exposed by unprotected APIs, the need for effective security cannot be stressed enough. Thank you, and thanks for tuning in. Thank you, everyone. That's it for the demo. Stephanie, do we have any questions?

Yes. [Operator Instructions] I got a lot of questions here. Let me see what we can get to. And then Joe, don't forget to also unmute yourself and get on camera. Let's see what we got here. All right. First question I'm seeing is, we usually see discovery mentioned in an API management context as a part of an API gateway. But you are presenting it more as part of security. Can you discuss a few of the reasons for that?

I'm happy -- go ahead, Cameron.

Sure. So really, we do see it a lot with API managed -- on the management part, but it really kind of straddles both lanes there. It's an essential part of security simply because you can't protect what you don't know about. And it also gives us the ability to do things like detect PII, detect your authentication status and things like that. So it really just kind of straddles that line between the two. Joe?

Yes, I was just going to say, and I think you kind of covered it a little bit in the slides, but you can't protect the things that you don't know about. Discovery is just a huge piece of that, right?

Okay. Thank you. Another question I'm seeing, how long does it take for Discovery to map out the API?

So that's going to be dependent on a couple of factors. Obviously, things like amount of traffic, is it preproduction, where you're generating your own traffic against all your known end points? Or is it post-production traffic where something has changed and you're -- traffic is hitting it and you're learning in that fact. So the amount of traffic that's hitting it as well as where it falls, that traffic falls within the -- when the discovery process runs, that time line. So it could be anywhere from, say, 10 minutes to a bit over an hour.

Okay. Thank you. Cameron, I'm not sure if you froze. I don't know if it's me. There you go.