We Hack Purple Podcast Episode 38 API Security Best Practices

With our guest being unable to make it, host Tanya Janca gave a lesson on API security best practices. She also shared a twitter link with a list of API security testing tools, as well as a downloadable PDF about the best practices discussed.

Thank you to our sponsor Thread Fix!

Buy Tanya's new book on Application Security: Alice and Bob Learn Application Security.

Don’t forget to check out  We Hack Purple Academy’s NEW courses, #AppSec Foundations taught by Tanya Janca! https://academy.wehackpurple.com/

Join our Cyber Security community: https://community.wehackpurple.com/
A fun and safe place to learn and share your knowledge with other professionals in the field. 

Subscribe to our newsletter! Sponsorship info: info@wehackpurple.com . 

Find us on Apple Podcast, Overcast + Pod 

Transcript

0:00

Hi everyone, and welcome to The we had purple podcast, where each week, normally, we meet a different person from a different career with an information security this week though our guests could not make it. Yep, that sucks. Sometimes things come up very last minute, hipped from Scotland. Sometimes things come up last minute and there's nothing we can do, and so I hope Marais... Well, I'm sure she is. But a last minute scheduling, couple IAM. So instead, I was thinking that I would briefly tell you about API security best practices. So I'm saying Hi everyone in the chat because I can... So basically, I can sell and I teach, and we have a secure coding course that I've been teaching life, but we haven't finished recording it so that we had... We have oral Academy, can actually have it on demand for everyone. And one of the things we teach is API security best practices. And unfortunately, for some reason, a lot of Debs, when they start doing writing Apis, they just forget, they forget about security, they think there's no front and therefore no one's gonna find it. Yes, we are. And they don't follow all the best practices, plus the extra things that are specifically helpful for API... So I'm gonna go over a few. So first, let me explain what Apis are. So it stands for Application Programming Interface, but ABI can be just how a compare talks to another computer, it does a service for someone usually, so there are internet like web Apis where there's a service and you can call it and it'll do things like look up a postal code for you, let's say you give it the dress looks up a postal code, you give it a postal code, it looks at the address. Awesome, so your web app is just calling this little service and it goes in it, it does something for you, and it sends you back some data or it does the task that you asked it to... Yes. Awesome. In your operating system, their Apis, all sorts of things have Apis, and it's just little services that go off and do magic. Honestly, it's really nice to... Of services that just go and do all these things, we don't even think about them most of the time, the reason why Apis have become front and Sunder recently in security or application security specifically, is that developers have started putting them on the internet, they've started making applications where there's a micro services architecture, so Microservices architectures where basically there's a big Giller end beautiful ness that your users see, but behind it, there's all these different little services Apis, if you will, and they go off and do whatever the things that the app needs done. And so if one of them goes down the rest of your app, it still up, if you need to change something in one, you don't have to risk re compiling and re deploying the entire app, you just deploy this one little tiny thing, and if it does one little tiny service, the risk is so much lower. It's complex to manage a microservice architecture, but it's worth it in many different ways, and so the reason why Apis have become so exciting is because developers have not been protecting them, and by developers, I mean a very significant percentage. So I don't wanna say exactly this percentage or not writing security into their Apis, but it's enough such that it's the first thing fantasies look for, and they'll do things like talk to your API when they shouldn't be allowed to. Only your app or the service account for your app should be able to talk to that API. A lot of Apis aren't doing authentication and authorization and making sure they know who they're talking to and that they should be talking to that person. Another thing a lot of Apis are not doing is, you know, making sure that they're not being called over and over and over and over and over again, abusive Apis, and by that I mean specifically calling it way too many times trying to brute force your way in etcetera, again, is a thing that a lot of Devs aren't accounting for, and it's happening a lot successfully, and so the first thing I Tatar wants to do is figure out how to talk to your API, and lots of devs just have the swag or file the open API definition file just open on the net. That's great. As an attacker, thank you. Now, I know exactly how to ask for what I want. So there's some comments in the chat that I'm just gonna get to, so there's very little guidance for Security and API, it's not discussed as much as it should be, which is why you're training so... Awesome, well, things, Ben, there's often a lack of boundary checking and Apis... Yep, I agree with all of the things you said. So first of all, I'm gonna put a link to an API Best Practices download from... We have purple so that you can just... You have to sign up for a newsletter. I know it's the worst, but are due letters free, and then you can just unsubscribe if you don't want to, or you can keep subscribing because... I think it's awesome. I don't even write it. Someone else writes it. Oh, there we go. And so if you wanted to get the download, you go to newsletter that we had purple dot com API as security, and then you can just download it there or just tweets, we have purple and we'll just share it with you. But basically, I'm gonna talk about those things today, there's another comment in the chat. Hi, I've deployed and broken my app before, I wish I had a micro services or a texture at that point. Oh my gosh, yes, Kellen. Yes, there's a lot of, yes. One more thing I wanna mention about Apis before we go into the best practices is there's a lot of complications around testing Apis, and I had a link already and then of course... Of course, then I lost it. But okay, here it is. So there's this hashtag I created called Ask infosec, so has as infosec on Twitter. And I ask questions, and I retweet other people using it so that we can all find answers to things we want, and so I asked, Can anyone recommend an automated API security testing tool to me? I want fast, dynamic APEC testing for Apis. And There was a lot of responses, so a lot of people told me, You can use post man. Yeah, I know if I wanna manually test something post man rules, it's awesome, it's a great tool to the made it, I want point and click for my clients when I'm not there. And quite frankly, I don't do Petes anymore, I do like application security consulting and teaching, and I don't sit there and hacks, I have a job now, so I want a tool for them that's automated, so a lot of people suggested, if you get your swag or definition file or your wisdom file, if you're doing older types of Apis, you can feed it into a tool like burst and then able to know how to talk to it, but again, you're still stuck doing some manual testing, like most of these tools that I have seen up until this point, what they do is they do a passive scan of the API and they will verify the cookies, the settings on your cookies, they'll verify if you have security heaters, they'll tell you if your encryption looks okay, they'll say you're passing a parameter in the clear that seems like a no, no. But that's it, that's the whole thing. And so there's newer companies out there that are adding to this, so some of the suggestions were neuralgia, some of the suggestions were wrestler from Microsoft, some of the suggestions were Crunch, 42. Oh, thank you, Ben, then send a an interesting one to my Twitter, I appreciate that stack, which is sort of like a beautiful guy overlay managing thing for Zap said Attack Proxy from a loss, and they said they have many improvements specifically based around Apis, shameless self promo and I was like, Yeah, that's what the threats for do it. So some people were saying the Apis, app spider could do a Norell. Just 'cause I haven't seen that do that. Fortify web inspect was suggested by Fortify. So mostly the vendors were suggesting themselves, and that is fine. A bunch of people suggested very silly things like tin foil or holding your breath, hijack existing smoke with integration tests. I don't know what hijack existing smok means, but I'm like, Okay, that's pretty cool. There is an AAs tool, which I had not heard of yet called API check, I'm just gonna put a link of that in the chat in case people wanna check it out, and I'm gonna just put it on the screen here... Oh wait, no, that's the Twitter. Ignore that. To second hit that, I'm gonna...'cause when you get something from Twitter, then it wants to put its own Twitter thing on it, so... There we go. I like promoting the Open Source projects from ALS because if you know me at all, you know I'm a big fan of Alaska. Partly cohesion. I've never heard of cohesion before, so this was kind of exciting, contrast security has a community edition now, and apparently it does Apis, and I was like, Dang it, I gotta check that out. More than one person suggested zap, more than one person suggested brute were... Then one person suggested wrestler, which is from... Which is from Microsoft. Some people posted about networker and I was like, Cool, And then more than one person suggested about neuro Legion, so that's awesome. I am on the board for neuralgia, so I try not to constantly push the things I'm on the board for, even though I think they're awesome, but I have not used it to do extensive testing, I have scanned an API with it before. And we found all the things I told you about, but what I believe is that they can do a lot more than just that. So those are some tools, and again, I put the link in the chat from my Twitter status or whatever, or just like, Just follow me and look on my profile and you could find it, which is at... She has purple. Yeah, contrast is not a cheap tool. And the fact that they made a community edition is really cool, also kind of like for startups, so it does one app and everyone accepts startups or open source projects have more than one app. Right, so If you're an enterprise and you start using it on one half and you really like it, then you're gonna buy it... That's the idea. I really, really like that they made a community edition, I actually asked them At RSA a few years ago if they would consider it, and then they actually did it, which I have to say is amazing that like I could put a request out into industry and I'm sure, I'm not the only one who asked, but seeing it happens really exciting. So let's talk about some best practices, specifically around Apis, so the very first thing you wanna do is get inventory of all your Apis, it is hard. Inventory of Webby things is hard. If you want inventory of physical things or of infrastructure, it's way easier, But... Webby inventory is difficult. There are some companies that do public facing inventory of your domains, and so those are the ones that I know of that I've seen are bit discovery and asset note, which I'm just gonna put in the chat and then put up on the screen for you. So it discovery is based out of America, asset notes based out of Australia. And I've seen them both in action and I'm like, I am... You found a lot of cool stuff, they Still base it on your public footprint, but they will find your whole public footprint and that's really cool, but you probably have all sorts of domains you're not aware of, and also you probably would just... A ton of things that don't have a way front end and therefore don't have a domain name, really that they can go and check. And so when I say inventory for Apis, things are internal and public facing, if someone can talk to it, you need to know who's talking to it, and so some ways that you could create an inventory of all your Apis would be for starters, if you have an on premises data center get and map and every single different zone of your network run and map and look for open ports at 4, 43. So 80 HTTP for 43 is HTTPS. And so you wanna scan and if there is something open and there's probably a web thing on there, and if there isn't, then close it either way, it's a good exercise, if you are using Cloud stuff, if there's a Platform as a Service, a path that as an app on it, it just does, you don't buy a pass and then not put an app on it, so all of those are gonna be apps, and then look at your infrastructure, so your containers and your virtual machines... And again, if 8 0 or 4 4, 3 is open, that is definitely probably something Webby or a mistake, and you wanna close it, so go check all those who... Another thing you can do is look in your code repository, and I know this is gonna sound really dumb, but look up API, everything that opens is probably an API, but you probably wanna look through every single project because all of those are probably web app and a bunch of them are in proud and you wanna add those tormentor,'cause you wanna know the web apps to Then go to your CI CD system. So whether I use Jenkins, Azure, DevOps, GitHub, actions circle, CI bamboo, bulaga, GitLab has come out with a bunch of AP SEC tools recently, and I would love to get my hands on those in case get labs watching. I'm very interested in all the cool stuff you've been doing Anyway, so go check out all your CICS, anything that's being released is probably an app or infrastructure is coat, check through there, there's probably a bunch of Apis being released and then put all that together and then send out a survey, like a manual survey to your teams and ask them... In the comments, someone says, Get Lab, it's so cool. Yeah. Agree. But the fact that they've made a huge play to be like the dev SEC ops pipeline just obviously attracts me because I am obsessed with Dev SEC ops and I wanna play with their staff, but also budget is a thing. Anyway. Thanks, Ben. So those are some ways that you can get inventory and then literally ask the teams, and you want to make this inventory available to your instant response team, you wanna make it available to the architects, like the security architects and the regular Webby architect people, all The dads probably wanna know what this inventory is and you wanna know not only like what the app does, does it have sensitive data, a link to it, or how it's accessed, what technology it's built in, and who the contact people are as a very minimum... Those are the things I would wanna know. You could do one better and add where the code is, a link to Dev, QA, staging, proud, etcetera. That would be awesome. The more information you can put in there, the better ones... That's accurate. Okay, so now let's assume that you have an inventory of your Apis, I believe the old external facing Apis should be connected via epic away Because a gateway, so like you know how you have a door on the front of your house and then people theoretically have to go through the door to get in. I realize windows are a thing, but let's pretend windows aren't to think, so everyone comes in through the door, I Ate my door's class, I'm not over, but some of it so I can go and look and be like, I wanna open the door to that person, usually unfortunately, 'cause I live in an apartment building, it's someone delivering pizza to one of the other people, and then it always smells awesome. It upsets me because I'm usually not having pizza. But anyway, I tell them to go around to the side or the side of one of the other apartments, and then you end up feeling frustrated that I'm not having pizza. But anyway, the point is, is having a door lets you check who's coming. So API gateways will do authentication and authorization for you, so you don't have to do it. So you know who you're talking to, and if you should be talking to them, it can also do throttling and quotas. So throttling is slowing things down when someone's going too fast, if you have children in your life, you'll know that they'll just run raises for a front door and you're like, You are gonna step on the carpet and then flip and land on your Batman, be really sad. Don't go running through the doorway, walk as though you are mature. And so this is the same thing that happens with Apis, like they get abused, and by that, I mean some bot will call them over and over and over and over again, and either I'll call very, very quickly and try to prove force its way in. And so troubling slows it down, and then quotas, another thing that API gateways do is they actually will stop, so they'll just... They'll say, You've got this much and you're done now five ICU tomorrow in 24 hours or so you next week or see you never... 'cause you've abused us and you're not low back... I'm on to you, it can block an API. I can block an IP address for you. And so an API gateway means that no one can talk to our API unless it's through this gateway, and they know who they're talking to and that they should be, so they're on a list of... Okay, to talk to. And all of that is extremely helpful. The next thing that I expect is like best practices would be do the same logging, monitoring and alerting as you would for any web app API, still need to log... I know logging space is expensive if you use the cloud... I know, and I know it's cheaper if you only keep them 90 days, don't keep them 90 days. Keep them 365 days. I know it costs a lot, but if you read my book, so of course, I refer to my book all the time... Well, I know why,'cause I know everything in it. It's really helpful. So I wrote a book called lab learn application security. And in it, I quote this awesome article from Slashdot, where they state that it takes 276 days, I believe, on average, before people notice a data breach in their company... That Is a long time, if you wipe your logs after 90 days, almost all the time, there's gonna be an error almost all time, and that's really bad for obvious reasons, that's not gonna work. And So it's very important that you keep your logs for way longer than 90 days, preferably 365 days, then the next thing... Monitoring. Yes, Kellen. The next thing you wanna do is monitoring, so you wanna know what's going on if your API is down, you wanna know... And so monitoring is like, it watches what's happening and then alerting, is it telling you... I'm scared. So some things that you could set so you can pay that monitoring. You can actually set up alerting yourself in your custom app. So I actually talk about that a lot. So let me share another link that's again from... We had purple. So where is it? Air Handling and logging, so These are all the specifications of what I think you should log... What I will warn you, you should definitely not logo, I'm just gonna put it on the screen, so it's newsletter that we hack Pepe dot com errors with an s DAs and logging. But we actually cover alerts too, and so the reason why it is important is because sometimes people log sensitive information they shouldn't... And the also a reason why it's important as they don't log things, they should... If your app can alert you when something is wrong, that is extremely valuable, so for instance, if the API gateway has its being overwhelmed, it will alert you because it's a tool that you pay for, but if your little API has something else going on with it, you need to alert on that. So some examples of when you should alert, if you think it's being Bruce forced, so if you're not using an API gateway, which I really want you to, but maybe you're not... Lots of people are, I would say way more than half the people in industry are like, lots and lots aren't... If someone is trying to rotor you, I would say someone that tries to log in 10 times in 24 hours or less, no human is so patient that they will try that many times, if someone is making repeated mistakes in their requests, like the grammar or the protocol that they're using to talk to your API is incorrect. And it's coming from the same API or the same IP address. Humans make mistakes, computers don't make typos, so if it's wrong, wrong, wrong, wrong pocket, and if it's a real person, I just send it a message that says, Call A said this number and we'll talk, and I assure you they're not gonna call you 'cause they're a malicious actor, another thing that you should alert on, so in my opinion, you should try and then catch all your errors, so all errors should be caught, but to make sure you've got every area, you should have a global exception handler. So let's say your API does four things and it tries this, and if it doesn't get it, it catches the error and it handles it properly. And so it does that for all four, but you have a global exception handler in case something really wacky happens and it fails, not in one of those places. The Global exception handler will catch that you wanna alert because one, let's say you missed a place where you should be catching an error, it'll tell you that, but two, it means something really weird is happening, and when something really weird is happening, there's a decent chance it's a security problem. Okay, so that is logging, monitoring and alerting. I have more stuff to say, so for all web apps, you should do this, but for Apis, we forget it a lot, we should block all of the HTTP methods that we're not using, so almost all web apps, you get input, they use it like it's going out of style, and they're really happy. But there's also... So, Oh, they just get and post, but there's also put... There's delete, there's trace, there's head. If you are not using them as part of your API or application, block those, turn them off, disable them. Because guess what I'm gonna do, I'm gonna try to call your API on a delete call, I'm gonna try it on a... Get on a put. And so, as an example, so of course, famous examples help Facebook, we're trying to say No to a bounty hunter that had used a Get Command to delete a picture from another user, and so the delete command usually verifies that you're only deleting your own stuff. You can't delete stuff from another user, that's usually bad in every app unless you're the administrator, you shouldn't be able to delete other users stuff. And so they had denied the request and said, No, no one would ever do a delete action on a gut call, and so what the person did was they went to Mark Zuckerberg Facebook profile and started deleting his photos and... Yeah, that got their attention. Because think of if you treat modulator just a second, lots of people would be deleting a lot of things. Right. Okay, so you wanna disable all the HTTP methods that your app isn't using, whether it's an API or it's a regular web app with a front end Next service man, if you are using... So if you have an app and it has two Apis on the back end, you don't need a service math, you're fine, but if you are someone like Netflix and you have a micro services architecture with tens and tens and tens, they have millions of services... I believe like over one million. That's amazing. If you have that many services doing all their little things, guess what happens, boom. They bang into each other by accident because our networks and protocols were not made for that, like HTTP as a protocol would never meant to even keep a session, it was never even meant to be used for our person could log in, it was just supposed to be... You see a static web page, you read it and then you go away, that was like the whole plan for the web originally that was it. And so instead, we changed it and we added stuff on top to make it do the things we wanted, and So specifically with a microservices architecture, you would just have so many services doing so many things and they'll bash into each other. So service mesh was created, and service much specifically is it's a layer of infrastructure, you don't need to change your code, it encrypts everything like to and from all the actions are encrypted and all of the little services go through it. And what happens is, is it make sure they don't bang into each other, it makes sure that they talk to each other extremely quickly, much faster than a regular network would be able to do, and it protects them from anyone spying on them because it encrypts it, a service Mesh can be... Service math can be agnostic, so to... I'm just gonna take that and I'm gonna put it on the screen because it's a fake weird word, it's a brand name, so It is agnostic, so it can be used on any Cloud and on prem, but every single one of the major cloud providers like GCP AWS Azure. They all also have their own... I don't find any specific service math to be extraordinarily exciting personally, but if you are going to do a hybrid situation where you have some of your stuff on premises in your own data center and some up in the cloud, if You're just using service match in the cloud and you only had microservices on the cloud that would work, and you could just use that cloud providers mesh. But If you're gonna have some stuff on prem, do you really wanna have two different tools, or if you're gonna do a multi cloud approach, so let's say your company and you do everything in AWS and then you buy a little start up and they do everything in Azure, do you wanna have two service meshes that you have to handle or do you wanna have one... So often people will choose an agnostic service mesh... Okay, I need to thank my sponsor, I completely forgot, I was super flustered because our guest was unable to come to the show, which obviously really sucks, but... I wanna thank our sponsor, thread fix, powered by denim group. They make the most depends vulnerability management system, the side of the Galaxy actually really love their tool. I genuinely think it's awesome. I am a huge fan of metrics, and that is what it is used for, so it gathers up all the data and then it shows you trends over time, it shows you which team kicks as and which team needs a little more help, and being able to see all of your salts in the same place is extremely helpful. Okay, hopefully that was... Hopefully, that I felt like that was really good. Okay. Yes, or being or sponsor does mean they gave me a free license... Yes, I did ask for one. Okay, so more things, I think that we should implement standards in organizations for what we wanna see for our APIS, if we're like, Oh, the Devs aren't making care Apis, did you give them guidance on what you want. So please feel free to just like grab the one that I already shared at newsletter, we had purple dot com, API security. Feel free to just use that one. That's Cool. Feel free to be way more specific. I think you should have a secure coding policy, and I think that you should have a special part for Apis, you still have to validate all the inputs to your API, do not trust anyone or anything... As I joke, don't even trust your mom, because my mom once sent me a virus and she's like, That was so many years ago, Tony. I don't have to keep bringing it up, but that means even a person who's a mathematician chemist who is incredibly intelligent and who I trust extremely, like I trust this person so much, even that person can make a mistake. That's the purpose of this. So I think that it's really important that you still follow the exact same secure coding best practices with your Apis and that you provide guidance to your debs. So you actually get what you want. Another thing that I would suggest is strict lending of your API calls. So I think we should strictly lend to everything what is a... Later you ask. So a winter is a tool that looks at your code and make sure that you are not taking any poetic license, it is a little bit like the grammar police, but for your code. So you know how there's some languages where you don't have to declare what type of variable it is, it's like, Oh well, we'll just figure it out when you use it, grab our police. And by that, I mean the lender says, No way, Jose, tell me exactly what you plan to do with this variable, or I will not compile you, when we remove all of those things and we make sure that we are following the letter of the law of our framework and our language were a lot less likely to fall into security trap. So strict lending really helps. If you are not gonna use an API gateway, it is important that you authenticate, and by that, I mean figure out who you are talking to, and Then authorize. Then let them in and show them the areas they're allowed to see if you decide... Even just letting them in enough to the code where you authorize them... That's too far. If you don't know who they are, another thing for API specifically is avoiding for most error messages, I remember the first time that I patented an API, it is like, you keep telling me exactly what I did wrong, and they're like, Yeah, 'cause you might make a type on my computers, don't make typo, Stop giving me so many hits, smash... You want like an API has no front end, it should only be speaking to computers, you don't need to give it a nice message at all, it's just like invalid input, and that's a yes, that would annoy you user, but a user should never be calling your API a human never becoming your API, if a humans calling your API, if they are not your pen tester or Red Team or a Deva person who's testing, you were in serious danger, this person is a malicious actor, and so you don't need nice error messages. Okay, so I have two more things. Oh yeah, actually, I already said one of them, so you need to follow all the same secure coding practices that you normally would, so this means doing proper input validation, not Sanitation, doing parameterized queries, checking the bounds, etcetera, like be just district, you would be without... Do just as much testing as you would, etcetera, and Then the last one, which again, a place to All Apps, decommission, old or unused versions of the API, if you're on version 31 of your API, 30 should not be running and 20 should not be running. All those should be turned up, sometimes people forget, and if you have an inventory going through like every quarter and checking to see if they're all still there and that the inventory is accurate and that you... Decommissioned things are supposed to have commission could save you a breach. There are so many things that are out there on different enterprise networks because some person got reassigned to some other group or they got a promotion, or they left and went off to work somewhere else, and they didn't mean to leave an old app live, but they did. And one, you're paying that bill at the very least, you wanna turn it off because of that, and two, it's not getting security updates, is not getting security attention or testing or anything, it's not getting dev attention. You don't want that to be live, and so those are the best practices that I have for you right now. There's a few more comments. Sometimes the mobile app has a different set of Apis than the web app does, and you can abuse one or the other through that, so for instance, uncalled API functions in the app can be enumerated. Yes, and that's so true. That's very true. Yeah, I remember my first web at Pen Test, I go in for the meeting, I'm like, Hi, everyone, high. And I was like, May I assume in the Scope that's gonna include all the Apis behind the mobile app and the two debts look at each other and they're like, How can you see those? And it's like, Oh, I just did this with Berlin now, I can just see them. They're right here, can you see... And they're like, You're already hacking her up, I'm like, No, no, no, no, no, I just did like a little proxy so that I can write up the scope document for this engagement, and so I named them all and I just wanted to make sure that all of them are in scope, that I did get all the ones who wanted and they just looked like they wanted to crawl under their chair and die, and it turned out that they said to the boss, we don't need to include Apis in the whatever, because no one could ever see them and me saying that I had totally made their manager's point, unfortunately. Anyway, do we have any last questions? If you want to, you can put them in the chat, and we teach this and more at We have purple, and usually it's less of a whirlwind and I'm a bit more... Someone's like, Boris. Amazing. Yeah, I agree. Usually there's lessons and exercises and other things I can teach, it's not just me lagging on for 40 minutes because I wanna make sure that you actually learn all of the content. I hope that you found this useful, I really hope everything is super cool and totally awesome with Farah, and maybe she just slept through an alarm or something, if we can, we will have Ron because she's totally awesome. I definitely wanna talk to her all about her amazing Balti hunting, and I bet she has a lot of comments though, Apis, I'm gonna think our sponsor one more time... Thread fix. Awesome, so all around, I wanna thank my amazing sound engineer for being here with me and always making me sound and look amazing, this would be so much more work without you and I really appreciate you. There's one more comment in the chat, I thought people would be using Kubernetes for macro services rather than just HTML, Kubernetes manages containers rather than like micro services are more the apps, so like infrastructure versus software... I know the infrastructure sort of is software now, so that's like a bit... Yeah. Thank you, Ben. Thank you, Kelly, thank you to everyone who came. I really appreciate it. And this was... We had purple and we will see you next week.