 Application security can protect applications running on a wide variety of platforms, from old-fashioned application servers running on bare metal to containers running in Docker or Kubernetes or ECS on Amazon, right up to Fargate and all the way to serverless functions like AWS Lambda. For this demo, I'm going to show an example with AWS Lambda. What you're looking at here is the AWS console for Lambda, and what I have is a single function written in Python 3 in this case, and it's just a simple hello world application. And I have this connected to an API gateway, so I can run the function just by loading this URL. So when I refresh, the function executes and returns this content. Now this function, for demo purposes, I've added an intentional vulnerability. You can simply include in the URL a file parameter like this, and when I load the URL, the Lambda function is going to grab any file I give it and just serve up the contents. So when we load this page, you'll see there's the contents of slash EDC password. Now you'd never write an application like this intentionally, but it's useful for a demo. And the idea is this simulates an accidental vulnerability that might be part of your application, either in the code that you've written yourself or in a third-party library that your application might depend on. So what we're going to do during this demo is protect this function with application security so that this vulnerability can't be exploited. So what we're going to do is install the application security library and protect the function. We're using a capability of AWS Lambda called Lambda Layers. We're going to add a layer to our application, and this is a layer that is created and published by us for our customers, and it contains the security library. So you can see here we've added the layer, and it also contains a custom runtime for Lambda. So instead of using the official Python 3.6 runtime, we're going to change this to custom runtime. What this allows is the custom runtime automatically instruments the function we're protecting. So we don't need to modify any of this code. This is an optional way to install. You can also install keeping the official runtime, and it just requires a few lines of code here. But many customers like this method of installation because it doesn't require any modification of the actual Lambda source code. So this allows you to install protection without modifying your build pipeline or your tooling that generates these Lambda functions. You can do this through the console like we're doing here or through any AWS supported method like cloud formation templates or the AWS API. The last step for installing our security library is to configure it with its credentials, and you can see here I've already added the key and the secret required for this library to communicate with our backend. So I'm going to save this environment. So you see here that saving our additional layer and the change to the custom runtime. Nothing else has been changed in this case. So when I go back to my function here, I'll remove my exploit and I'm going to load the page again. You'll see this initial request is a little bit slower. This is the cold start period of the Lambda environment. Part of this time is just initiating the Lambda environment itself. And then part of it is our security library initializing itself. So during this time it's pulling the configuration and the policy from our cloud dashboard and initializing the security in the function. You can see later requests are back to being fast again. So what we're going to do now is our same exploit like before. But what you'll see is in the background the security library is analyzing this request. And when we run it, you'll see an alert appear in the dashboard and we'll look there in a moment. So you can see it still executes. We still get our content. But over to our cloud one application security dashboard, you can see some new events showing up. And there's actually two new events here. One is a malicious payload and one is an illegal file access. So what we're going to do now, you can see my application on the side with inside my list of all my vulnerable applications. This is the one we're looking at right now. And we're going to look at these two threats that were detected. The first is a malicious payload. So I'm going to click on there to get some more details. You can see because this is a Lambda function, we automatically extract a set of Lambda-specific metadata. So we have the AWS request ID. This allows you to correlate these events with your CloudWatch logs and any other AWS system. We also get the function name in Lambda, the function version, and the full invoked ARN with the region and the account ID. We also get specific information on the malicious payload. So you can see here we've identified a likely local file inclusion. We've got a description along with some CVE references. And then the specific payload we detected in this request. And there's our file equals EDC password. A key point here is that this alert, our malicious payloads, they're telling you that the request coming in looks bad. It's matched this signature to say that this payload looks bad. But at this point, we're not telling you anything about the application. We don't know if the application is vulnerable. To see that, we go to the next threat type, the illegal file access. This is leveraging the information we have from our deeper instrumentation. And you can see we've got all the same Lambda metadata for the request. But we also get some more specific information about the illegal file access. And what you see here is that the application opened the EDC password file. But we have a default rule that prevents reads from anything under EDC. So when the application security library sees this file being opened, it knows it's in violation of the policy and it flags it up as a potential attack. Because we're inside the application, we also have access to the full stack trace leading up to execution. So you can see here, we have the source code file name, the line number, and the function being executed. So if we look at line eight over in our Lambda function, you can see that's where the actual call to open occurs. So with this stack information showing source code details, and all of this information on the function itself and the actual exploit that we've seen, it makes a full package of information that you can pass to your developers that gives them everything they need to identify where the vulnerability is, reproduce it, and also in a sense evidence that this is an actual vulnerability that is reachable from the Internet, because we're telling you what actually occurred in the application. Now this is all great information to fix the vulnerability and plug that hole, but you'll see here this request wasn't actually blocked. We still got the contents of the EDC password file. So what we're going to do now is we're going to update the policy for this Lambda function, this application, to actually block the malicious payload. So we're going into the policies for my application here, and the illegal file access, we're going to set it to mitigate so that it actually blocks the bad requests when it sees them. Any policy change like this is pushed out automatically to the protected applications. Lambda is slightly different where it's only executing while the function is actually running. So you'll see here I'll refresh this URL with my malicious payload. The first time may work, but very quickly we'll see the new policy and it will be blocking my request. There you go. So now every request to this Lambda function is using the new policy and any attempt to open a file in this restricted path is automatically blocked. If we go back to my Cloud One application security console you can see we've got more events and if we click on the illegal file access you'll see now these requests are being blocked. Even on the blocked requests we still get all the details on the request and the vulnerability, but the open call opening this file is blocked. So that content is never actually accessed and never actually returned to the user. So these things combined give you all the information you need to fix the vulnerability and understand it and the protection in the interim that this vulnerability can't be exploited. These two together give you the time to fix this vulnerability properly without needing to scramble a team of engineers or bring down the application to prevent this from being exploited. So what you've seen in the demo, we've protected the Lambda function very quickly. We've got the details of the vulnerability that was intentionally left in this Lambda function and we've protected the Lambda function so that this cannot be exploited in the wild. These three points kind of highlight the overall value of the product and really show how quickly you can get a benefit from installing. So thank you very much.