 Hi, everybody. Thanks for joining us today. I guess we're still maybe I'm like 30 seconds early on it. It feels like everybody's sitting around. So maybe we'll just get going. So thanks for choosing to come to see this session. This is a many-track conference, sometimes sort of hard to pick. I'm here today to talk about securing Cloud Foundry apps. Or I think the formal title was building security in how to use the platform to secure the apps. And this talk has some live demos in it, some live hacking. So apologies in advance if any of those break. But it does make them a little bit more engaging, even if the laughing is at my expense. So talk a little bit about me, just for context. So I am the CEO and co-founder of Sneak. We're right outside the door, if you wanted to ask questions after. And my background comes from the idea of the cyber parts of the Israeli army through the application security years, web firewall, web app security scanner, building those through a few acquisitions. And then more previously, I was sort of after that, I founded a web performance startup that got acquired by Akamai, where I was the CTO for a few years. And over the last sort of three years or so, I've been the CEO and co-founder at Sneak. So I have this sort of rich security background, most of my mindset, I sort of consider myself a security person. But over the course of the few years prior to Sneak, spent a lot of time in the DevOps evolution. And a lot of the concepts that I talk about here are around trying to apply some of those mindsets of sort of the DevOps, sort of maybe the performance and operations excellence into the world of security. So let's dive into it. Cloud Fundry invests a lot in security. It was like bullet number two today for Chip in it. And it does a lot to secure its own platform. So a part of it is around securing Cloud Foundry so you can get those sort of CVs remedied in 48 hours. And a lot of it is around helping you operate a secure system. The mirror notion, especially in the Paz version of it, which I don't know what the name is today. So I guess the application runtime is the new name for it. A lot of the security components are sort of built into the platform to allow you to operate a secure platform, updating stem cells, CV updates of the platform itself, SSH access, there are many, many concepts of it. Security is not a foreign concept to Cloud Fundry. It's a core capability. But all of these capabilities and all of this notion, they revolve around the platform. It's around the platform itself. There's this invisible line that gets drawn between securing the platform and securing the apps. So securing the apps is increasingly important. I'll talk about a few flaws, but application security and the mistakes that you can do within that space or that developers might do are equally severe and important. And we've just seen this, and I'll talk about this a little bit later on, with Equifax, where a vulnerable application dependency outside the purview of the Cloud Fundry platform ended up triggering a whole series of security mistakes or fiascos by that company, but fundamentally tripping a pretty massive data breach. So not all application security components can be centralized. A lot of these security flaws are specific to the business logic or the core behavior of the application, but many of them can be. So in this talk, we'll talk about how can you use the Cloud Fundry platform to secure Cloud Fundry apps? How can you introduce or take advantage of the capabilities that are in the platform to help you instill better application security through it? So this is kind of my funny slide. This is the one I'll come back to multiple times during the path. When you talk about how do you use the platform to secure the apps, the key point is hooks. So Cloud Fundry creates an opinionated stack. It has a certain flow, a certain workflow that you can then customize as an operator and modify, but it gives you all these opportunities as a part of your workflow to introduce questions, to introduce testing, to introduce reliability, and also to introduce security. So this is by no means a comprehensive slide, and there's somebody in Pivotal or somewhere who's going to shoot me for describing the CF pipeline in such simplistic terms. But fundamentally, it has a certain flow where you do CF push, build-back magic happens, and then that generates a droplet, and then that droplet gets run in many application instances with service brokers attached to it. So I'm going to focus on this simplified view, and I'll talk about the hooks that each of these steps allow. They're not comprehensive, but they're hopefully enough to get the thoughts going with some concrete examples. So in the build pack, and I'll show concrete examples of this in a sec, but in the build pack, you can introduce CI-CD styles of build style type of testing, block flaws maybe automatically fixed. Some issues we'll show that. Instrument in preparation for better monitoring. The droplet, maybe this is a little bit less well known, but the droplet is an entity. Maybe it's not a container, maybe it doesn't include an operating system under it, but it still has the code, it still has vulnerable libraries, and the Cloud Foundry API allows you to access that droplet. So that's another hook point for you to be able to monitor it less intrusively from the outside. And then the service brokers and the services around the application instances, they allow for a variety of other security controls, both in proxy and traffic, in CredHub, which is new, and in inspecting logs in a variety of other components. So I'm just going to use this set, but I just want to clarify that it's not a comprehensive set. All the places that you can hook into, that's hopefully enough to get your thoughts going. What we're going to do is we're going to take two types of risks that we will deep dive into, which is application secrets and vulnerable application dependencies, and I'll try to show a little bit of demos even of how this might work. And then we'll do some lighter mentions that use this framework, this sort of structure, to talk about other security threats that we didn't deep dive into and say, you know, just a few words about how you can address them. And then we'll do some conclusions. Cool. So far so good. And yeah, I know it's kind of a razor hand or clarify if there's mistakes or issues. There's a slight portion that requires audience participation, so be prepared kind of mentally. Okay, let's start with the easy stuff. Application secrets. So actually what I didn't get around to do is put a whole section around what are application secrets. So just to say it verbally, in your applications, there are a lot of credentials. They float around the app, API keys to access third parties, secrets or sort of usernames and passwords to access the database, maybe secret keys or tokens that are used to either authenticate your app to others or to encrypt information in the system, tokens galore, just many, many of these secrets in the code. So let's talk a little bit about how you can, these are secrets that are oftentimes fairly inherent to the application, but there are tools again in the platform that can help you use it. The first one, which actually, I won't spend a ton of time on, is CredHub. So CredHub, if you're unfamiliar with it, is this sort of new service that is a part of Cloud Foundry. This is not by any means a comprehensive overview of how to use CredHub, and it is quite new. So if I was to very overly simplify, you can set up a CredHub instance for your credentials as part of your platform. You can install it or set it up on your platform. You can optionally integrate a hardware security module to further secure the credentials that are stored inside of CredHub. And then you generate these sets of credentials. This is a key management system. So you generate credentials and set them in there. And CredHub has actually some nice features that don't just store the credentials, but also allow you to easily generate kind of like a one password or a last pass, like a password manager. They allow you to set these constraints or requirements to generate a secure password that actually never really passes some sort of human visual. It just sort of sits there. And then you control who has access to it. And on the other side, you can then audit who accessed those credentials. So you have some forensic trail to see if some problem occurred or if you're concerned about it, audit who accessed them. So this is what you do to set up as an operator of the platform. And then the app can in turn use those credentials. I must say that when I dug into this, when I knew the concepts of CredHub, I expected a little bit more on the app side. And it's not all quite there. So some of this is a little bit aspirational, like a little bit where you will be, but not necessarily today. But if you think about CredHub, it can be used for a variety of rollouts and deployments of your stack. I'm not focusing on that. But on the app side, you can consume it either by binding these credentials to a service, which implies you may never need to see this in the app. Maybe it's just a part of the routing and connection. Or what is more likely is that you would just use it as a key store. So instead of having these credentials like you do today as environment variables that you're storing in the system, then instead you can have in real time access CredHub, get the keys or the relevant keys, use them, and then drop them or stop using them so they're a little bit more secured. All of this is a little bit aspirational. I had some long conversations in preparations of this talk. And I want to say that CredHub is super promising. It's quite early. A lot of the focus today in terms of practical application is around rolling out new versions, basically tokens that are a part of the operation of the platform running through new versions and things like that. That's reasonably well thought out and probably usable today. The use of it on apps is a little bit further out. You know, it's intentional and there's all sorts of plans and documents out there that you can see on Slack channels and others, but it's not quite there yet. So I'm going to pause that and say just sort of a type of service you can do. Another example of an area where you can use secrets is in the Build Pack. And the Build Pack is a great place to block flaws, to sort of not let them continue. Yes, you might have had secrets that already made it to your system. So, you know, the fact that a secret made it to the Build Pack is not awesome already, but at least you can put some preventors of letting that secrets go on. So, for instance, what you can do is you can add a Build Pack test for keys and tokens. So you can test to see, hey, if there's something that looks like a token and it hasn't been ignored, then I will not let that through. I would fail the build. I will not generate the droplet and I will not go on to create the system. This type of test is fairly simple. You don't need to reinvent the wheel. There's a bunch of open source projects out there that just have the patterns for it. One useful one is AWS Labs Get Secrets, which you can also use on your own personal machine to prevent uploading, checking in a secret to get in the first place. And you can also sort of use your own patterns. This is an area where there's an 80-20, right? If you catch enough of the tokens, then you've provided a really good chunk of value. And just to make sure, if you did find this and if you did break the build because you found a token, make sure you cancel that credential, right? It already made it too far if it got to your attention. So let's see this a little bit in action. It's not terribly fancy, but it just gets us a little warmed up. So to demonstrate this, I've got a little custom build back here. We're just gonna look at the top one that has a little environment variable called fail-on-token, very elaborately named. And it has an equally elaborate security test in it, which really all it does right now is script for a UUID. This is not sufficient. You can do better. It's just meant to be simple for the demo. And if it happens, then it breaks the build. I'm going to use this. I've got a little vulnerable to-do application here. They'll all show some mistakes on as well. You can do actions like whatever, call mom. It doesn't really matter what this app does. This is a little node app that we have here. So what we're going to do is we're going to push this application. While we're at it, we're going to use a nifty new feature which is the multi-build pack. So we're just gonna push this app and we will specify the Node.js build pack to run it. And that would just go through. But then we would add two other build packs. One is this build pack that I just showed here. And the other is once again, the Node.js build pack. I'm kind of cutting corners here a little bit. The Node.js build pack the first time would build and then the build pack would run and then the Node.js build pack would run again to release, sort of finalize the release. So you probably could be a little bit more enabled. But if you did notice, I had a bit of a set and fail on token. This whole test only happened over here. Or was it? If I had fail on token true, so we're gonna set fail on token true and then we will do this push and then we will wait a little bit until this runs. So this notion of a pattern or some sort of core component, that some core test that fails the build is a very well-known concept for quality tests. The key difference between adding a security test here and a quality test is around reacting to the application. When you think about CICD tests, when you think about tests that are sort of functional, they also take a long time to run. But you want developers to constantly change them. You want them to adapt as the application evolves. These types of security tests should be things that are reasonably static. And, oops, what happens here? I think it failed for some other reasons. Did I do it wrong? Okay, we'll try this again and hope that magic happens. It just works. Again, live demos. But basically the security tests need to be a little bit more kind of cross-app. They shouldn't be quite as specific and they should be a little bit more long-lived. So we'll see if we'll let this run again and we'll see if it works just very quickly. It worked about an hour ago. So it's quite likely that it won't work again. Anyways, in the meantime, I'll come back to sort of see that this hazard has not succeeded. Well, bear with me one sec. I think this is just like a memory. Yeah, let me scale this down. Sorry, bear with me a sec. Anyways, let me pause this and go on with the talk. I think you get it even if you don't see the demo. It would fail. You would have seen a failure. So you have just now. So with that, let's talk about another hook. So these are two examples of hooks that you could use. Let's talk about a third hook, which is the logs. So this is a properly complicated view of how Cloud Foundry handles logs. Really, what we care about, though, in this sort of big logging emphasis is two things. One is when you have the log regator, so this notion of logs on Cloud Foundry, you can build custom nozzles on the other side to sort of just take in the log information and that some of that log information comes from the apps. So the flow of the application logs amongst other things gets through this monstrosity and eventually makes it to a nozzle. And what that means is that once again, this is a hook for you from a security perspective. What you can do now is you can go on, take one of those nozzles, create a nozzle of your own, or use some log management service and ask questions, but you can start introducing questions that monitor the runtime of the application. There are many, many questions you can ask. And again, this is not a new field. It's just about the fact that you can use the platform for it so you can ask questions like are the tokens exposed or which services accessed which other system. You can start getting fancy with patterns or trying to establish the baseline of the norm. How often should this happen? How often should systems access another credential or another system? What's the failure rate? This is a really good indicator. Typically in a well-running system, you expect credentials to work. Even a single failure is a little bit weird. Five failures, 10 failures implies maybe some enumeration or some attempt. All of those are good indicators. So this is just sort of one example. And again, this is more than the explicit example meant to be a mindset around saying there are three potential places that you could have introduced a generic security hook for application security into your Cloud Foundry flows. Let's see if by chance this thing worked. So it successfully... Okay, I'm gonna run the push as I talk about the next one. We might eventually see that work. So this is one problem. The second problem I'll talk about is vulnerable app dependencies. So this is a little bit less well-known. It's kind of my space. So let me talk about it a second. I think everybody here has heard of Heartbleed. Who here has heard of Heartbleed? This is not that common that an open SSL, remote memory exposure vulnerability makes it to like a CNN level radio. And it's because it was everywhere. It was a severe vulnerability. It wasn't more severe than many others, but it was definitely more prevalent than many others. So you see Heartbleed, you had ShellShock and LogJam and all sorts of like design vulnerabilities sort of brand name vulnerabilities. This is a pretty severe problem. And again, you're probably aware of this. Verizon states that most attacks exploit known vulnerabilities that have never been patched, despite patches being available for months or even years. And in fact, Symantec goes on to say that by 2020, 99% of vulnerabilities that were successfully exploited will continue to be ones known by security and IT professionals for at least one year. So, you know, this is like all speak for it's hard to wrangle servers like patching servers at scale is hard. This is a core premise of Cloud Foundry. This is part of the reason that you're using Cloud Foundry is because Bosch makes this better, right? And it allows you to deploy containers or apps better. And in fact, this was kind of featured. I should have had Chip in this picture, but I managed to put a timely picture in my slide. And this was this morning's keynote. It was touted again, kind of an early note about vulnerabilities and handling of their own system as well as for yours. But that's OS dependencies. What about application dependencies? They're just as hacker friendly. It's just these libraries from Maven, from RubyGems, from NPM that you're pulling in. The vulnerabilities are already found for the attackers, so they're easy to exploit. These libraries are used everywhere, downloaded by the millions. And just like it's hard to wrangle servers, it's hard to wrangle apps. It's hard to sort of know everywhere what you are using. So, there's a lot of these stats and again, a lot of information about this, but this is another security threat. You know, many of these issues actually remain unfixed. Nearly 60% of the vulnerabilities reported in Maven remain unfixed. And for those that do get repaired, it oftentimes takes a long time to fix them. 390 days, on average, and even for the real severe ones, 260 days. So, there's definitely a security threat here. And we've just kind of had a vivid demonstration of this with Equifax, which were compromised through a struts to vulnerabilities. So, this is not the same. Even if you were perfectly managing your stem cells and updating them, you would not have been saved from this type of flaw. It's an application security concern. And it's a classic one for the Cloud Fundry Flow to address. So, how can we protect against this? How can we build something into our apps? So, this time, let me take a different spin and start with the Droplet. These application dependencies fall in this sort of twilight zone between infrastructure and code. And because of that, we can take a kind of an infrastructure scanning type approach to scanning for application dependencies instead of scanning machines, we're going to scan droplets. So, the core flow is you use the API, fairly simple API, to discover the apps that are in there, and then you download the Droplet once again via the API. You test the Droplet, you expand it out, you test it for vulnerable libraries, and then you report the discovered issues. This is the core flow of it, and you can use it in different ways. I'm going to demo how to do this with SNCC. So, what we would do here is we would connect with, say, pivotal web services. This would work for any sort of Cloud Foundry instance, really. Go in, this would use the API to extract this view, to say, these are the apps that are in here. You can say, add them to SNCC, which would do, just as I said, would go off, download the Droplets, expand them out. I'm cheating here a little bit, I've already done it. Just to sort of save us some time. And you would end up with these reports. For instance, for this node application, you can see, here's a snapshot. It, in fact, is a demo of vulnerable applications. So, it has many, many such vulnerable libraries, including this cross-sets scripting and some remote command executions at the bottom. So, you can go off here and you can now act on it. This flow is important because it allows you again to sort of wrangle the applications. So, by working against the interfaces, you can do this comprehensive infrastructure scan. So, you can find all the different apps. And therefore, it allows you to know whether you have vulnerabilities in the system no matter how they got there, right? It starts from the facts. You have libraries and they have problems. And this is also true if you test them for secrets, if you test them for malware. So, it's all good and well, and this is a way to do it. This still failed, so. Oh, here we go. Found token, this is the right failure. Found token, breaking the build, done. Eventually worked. Just in time. So, this is the notion of a non-intrusive external scan for vulnerabilities, once again, using the app. It has a bunch of pros and cons. The advantages of it is that it doesn't break deployment. So, you don't need to talk to anybody to do this. This is gonna be a side security control that everybody, that you don't need to consult with all the dev teams to apply. It doesn't require rebuilding, you can just run it on the existing system. And it's again, this sort of central control on applications to test, that you could choose which ones are critical, which ones are not, you can kind of manage that against your security poster. The cons of that is that it doesn't block deployment. So, it's not gonna keep these libraries out of the deployed application, it's just gonna make you aware of the fact that it happened. We'll talk about that in a second. The reporting is done separately, once again, out of band, and typically by some governance team versus the developers themselves. And similarly, the testing of the applications are managed separately. So, whatever it is, you need some system, you can use NIC for it, you can do it yourself, but just keep in mind that you need some system to sort of manage which tests have been run on which application and who's using which libraries. Another hook that you can use is the build pack. Just like before, except instead of looking for secrets, we're gonna look for vulnerabilities. The flow is probably as we expected, we're going to test for vulnerabilities in the build pack. We can also do a similar test for licenses. I don't want to deploy a GPL component. You will break the build if that happens, or you would report found issues centrally, that's kind of your choice. And then we'll talk in a sec about patching. So let me show you this, let's see if this works. So if I go back to my wondrous build pack over here, multi-build pack, we added another component here. So again, I'm using sneak test, I can go on in the booth around why it's awesome, but you can use another tool here as well if you prefer. And I would run that test and see if I'm introducing a vulnerable library. What does this look like? I will set another token here, CFSET and fail on, Vaughn, I think, true. Fail on Vaughn. And then we will push again, V3 push. So again, I'm running this to sort of show it in action, but in reality, you don't necessarily have to run this. Like in reality, this would be the same failure as what we've seen before. So you could choose, like you do in a CICD process, to use Cloud Foundry in this case as a reporting vehicle. So you can use the build pack to report on which libraries are being used, for instance, as opposed to breaking the build. That's somewhat akin to testing the droplets. It's a little bit different because you're still doing it in the build pack, it still requires a rebuild, but it's similar inventorying process that would happen. Yeah, and I'm not gonna spend time here troubleshooting this, I think I'm a little bit light on my account's memory allowance. So I'll just leave it at that. So these are two examples of failures. Let's talk again a little bit about, I'm already behind time here, talk a little bit about pros and cons. The pros of it is that it blocks deployment exactly the opposite of what we talked about before. So the advantage is that you can set a line, draw a line in the sand, it says I will not deploy a GPL component, I will not deploy high severity vulnerabilities. And I guess I'm kind of flipping here a little bit, it allows for automated remediation, we'll talk about that in a second, and it's built into the platform. So unlike relying on developers to run this test, or relying on their expertise to do this, this would actually be something that is in the system. Now in my model, developers had to opt into the build pack. There is a plan or some thinking around simplifying an admin mandated build pack. So these types of tests for secrets or for others can start from a recommendation. They can go into your build packs, the default Node.js, Maven build packs that you provide and just sort of have these tests built into them, or they can be admin mandated once the multi-build pack matures a bit more. The cons are of course, it blocks, it breaks the deployment, you need to build some mechanism to say, okay, I've acknowledged this vulnerability, I want to continue, and it requires rebuilding, so it would not happen to the apps that ran two years ago, right? Or sort of two months ago. And then as I said, I can decide whether you opt in or out. Build packs offer an interesting opportunity to auto-fix. Now, this is interesting, you can do it for access controls a little bit, you can do it for maybe for just sort of streaming sensitive information, you can just desanitize it, you could have removed that token in the build process, and you can also do it for vulnerabilities a little bit. So I want to show you this as an example with Java. So this is something we're experimenting with a little bit, so Java Goof is another vulnerable application, it's also called Goof, and it has the infamous struts to remote command execution that compromised Equifax. So first, just for kicks, let's exploit it a little bit. So it's deployed here, and I can run this little exploit. Just to show you, I guess, what that looks like, just to understand just how easy to exploit this application is. Oh, hold on. In the wrong folder. So really, all you need to do is curl this. You just need to curl this as a content type header, it's a little funky looking, but nothing more really. And then just for convenience, we put a little command over here that you can swap with whatever command you have. So I can just run N, for instance, and curl this into my application, and I've already fixed it, hold on. I did MVN package, and I'm ruining my own thunder. This is what happens when you, sorry. This is poor planning here. Kind of killing my time here a little bit. So I'll show you this exploit in action in a moment. Let's talk about the concept of patching it. So as the, so you have this application, right, and it has this massive vulnerability in it. Typically the way that you would do it, the way that you would address these vulnerabilities is you found out about the vulnerability and now you want to fix it. Maybe let me kind of show you a little bit of an example of this. So for Goof, for instance, for the application we have here, if I was to go back to my little app here and look at the GitHub project version of it, then it's the same vulnerabilities that I would see here. This is just that same application on GitHub. And typically the way that I would address these issues is that I would open a fixed PR. I would say, which vulnerabilities do I want to fix? Here's a bunch of vulnerabilities. I would hit open a fixed PR. And you know, this is a convenience that we do at SNCC, but generally this is the logic that you would do. You would say which vulnerabilities you want to fix. You would go and explore which upgrades do you want to apply to make the vulnerabilities go away. And then if I go here to kind of files changed, I would see these types of changes here, right? Just go from body parser 190 to body parser 171 and the vulnerability would go away. And this is great, but it means that you need to apply this and then roll this through the system. Now that's fine for live and modern applications. It's a little harder to do for older applications. It's also time-consuming even for new ones because an upgrade is not always that easy to swallow. You need to do all sorts of verification tests. So for that, there's a set of tools, SNCC included, that provide patching capabilities. I might show you. Okay, cool. That provide patching capabilities for these libraries that allow you to patch the vulnerability without needing to upgrade. So let's kind of get back to how we do this in the build pack. You know, first, we're gonna be a couple of minutes over. I hope you don't crucify me for it. Kind of the promised exploit. In this case, I ran env. I did the cat, swapped the command for env and got the output of the environment variable. Anybody want something else? Maybe, maybe like the ATC PassWD. Good. Pivotal web services file system here. Got it. Trivial to exploit, right? This is more severe than most, but it's a problem. So for us to fix it, what we can do, and I'm gonna run this and then I will, so I'm gonna push and then I'll explain what happens, is I ran SNCC Protect. SNCC Protect marked the to-do list war file as needing to be patched. And then in the Java build pack that I walked over here, there's a little bit of logic. Let's see, it's in lib framework. SNCC in the Java build pack, in this case we are not using the multi build pack we've just edited, edited to the existing one. There's a little bit of code here that knows where to look for that patch, sees if this library has been marked for patch and then swaps it with a patched library instead. So this logic, which we can also see in the output over here, there's this SNCC auto-patch that ran over here, patches the library, swaps it with a patched issue and fixes it. Now in this case, I still had the developer control, right? It was still marked by the developer for patching, but when you think about Cloud Foundry security controls, then you could choose to unilaterally find these types of libraries that you know how to patch and just swap them out, just sort of automatically patch it in the system. Even if you don't have it for 100% of vulnerabilities, it's a good way to just instill and then make sure that you're swapping out vulnerable libraries for others. So I'll go back to my deck and maybe come back to show you. Actually, you've already seen a demo of what happens when this is patched when the vulnerability did not work before. Here, I might as well run it again and I get some exception because it just made application fault. So way over time here already. So let me kind of wrap up a little bit. So those are examples of how you can use the Cloud Foundry flows for securing vulnerable libraries, so the dependencies in the flow. You could also, by the way, when you do these components, you can use the service broker, a custom service broker, as a discovery mechanism. So you can use it to just tell you which applications are running and then allow you to go back and do maybe the droplet inspection, maybe introduce into the build pack. That's probably the role of the service broker here. So just very briefly, these types of flows can be used for other security controls. They just have one slide on each. You can use them for static analysis. For instance, you can block flows or volums, anything that is a security control you'd put in your CI CD. On the flip side, you can use the traffic service broker as a bit of a web app firewall. You don't need to be perfect here. You're introducing, you're boosting the security control for your applications in your platforms. So you can put a little security proxy, for instance, to prevent, even if I sort of pick on this sort of struts to example, prevent exploits of it. You can inspect the logs to see common attacks that might have happened or many SQL injection types attempts. And you can instrument earlier on to enrich the data that you get in those logs. You can use it to control access management centrally. Make sure that you are only allowing access from certain domains. Make that a part of the routing algorithm. Make that sort of a part of the core. This is borderline around whether this is app or platform really, but you can wrap the apps with these types of access controls with service brokers. You can use the inspections to prevent API abuse. So this is very much application logic, but you can give them services as part of your platform to detect those components, be able to look in the logs, identify cases where people are using your API a little excessively, or once again, identify failures, access to the API with an invalid token, indicating a problem. And you can even use it for malware detection. These droplets are persistent entities and they float around your system. So servers on CloudFundry and droplets that have been deployed may still be tampered with, they may still be compromised, and they may still hold malware. We're getting into pretty fancy tech around the tech for detecting malware. You're probably going to buy that, but in terms of where do you hook it in, then you would probably hook it in, or you could hook it in as part of those inspectors. So there are many more examples of it. And if I kind of go back to the high level concept, CloudFundry is a highly secure platform and you should make sure that you secure it properly when you operate it, but it does not fully secure apps. There's nothing inherent in the platform for it. It does allow you to introduce application security controls. It offers you the opportunity and you can tap into it. So you can use it as an app security platform. This is meant to be not a comprehensive list, but meant to be just sort of spark ideas. You know the hooks, you know the flows of your applications. These are all opportunities to instill an application security helper or an application security control. And that's basically it. Let's sort of extend the security from the apps and try to build security into the platform. Thank you. Thank you.