 Well, welcome to this CUBE Conversation. I'm John Furrier, host of theCUBE here in Palo Alto, California. We got two great guests all the way from Ohio and here in the Bay Area with Sequence Security. This is our focus on cloud growth companies, Shreyaans, Meta co-founder and CTO of Sequence Security and Jason Kent. Hacker in residence at Sequence Security. We're going to find out what that actually means in a second, but this is a really important company in the sense of APIs as they are starting to be a connective tissue between systems and data. You're starting to see more vulnerabilities, more risk, but also more upside. So risk reward is high and anyone who's doing anything in the cloud obviously deals with APIs. So, Shreyaans, Jason, thanks for this CUBE Conversation. Happy beer. Guys, let's talk about API security and but first, before we get there, Shreyaans, what does Sequence Security do? What do you guys specifically build and what do you sell? Sequence is in the business protecting your web and APIs from various kinds of attacks. We protect from business logic attacks, API, do your API inventory. We also detect and defend against things like account takeovers, fake account creation, scraping, pretty much anything in everything an application on an API is exposed to from the attackers. Jason, what do you do there as hacker and residents that also want to get your perspective on API security from the point of view of an attack standpoint from a vector, how are people doing it? So first, explain what you do and love the title hacker and residents, but also what does that actually mean from a security standpoint? Yeah, so we can't be in the business that we're in without having an adversarial approach to where our customers are deployed and how we look at them. So a lot of times I spend my time trying to beat on a client's back doors and try to hit their APIs with as many kinds of attacks that I can. It helps us understand how an attacker is going to approach a specific client as well as helps us tune for our machine learning models to make sure that we can defend against those kinds of things. As a hacker and residents, mostly my position is client facing, but I do spend an awful lot of time doing research and looking for the next API threat that's out there. Yeah, you got to stay ahead of the bad guys, but let's bring up some kind of cutting edge relevant topics. One is all over the news cycle, you heard Peloton, a highly visible company. It represents that new breed of digital companies that have a new approach and it's obviously doing very, very well the new consumers like this product. And you're seeing a lot more Peloton-like companies out there that are leveraging technology. So they're fully integrated. They had an API issue recently. What does this mean? Is that something we're going to see more of? These kind of leaks and these kind of vulnerabilities. What do you guys think about this Peloton thing? You know, from an attacker's perspective is a really boring attack, but it led to a huge amount of data leaking out. Same with the news has been ripe with this lately, right? John Deere got hit. We've seen yet another credit bureau got hit, right? And these attacks are coming off as fairly simple attacks that are dumping huge amounts of data, just proving that the API attack surface is really a great place to get a rich amount of data, but you have to have a good understanding of how the application works. So you got to spend a little bit of time on it, but once you've taken a look at how the data flows, you end up with pretty rich data set. As an attacker, I go after them just by simply utilizing their products, utilizing the programs and understanding how they work. And then I drag out all the pieces that I think are going to be interesting and start plucking away at it. If I see a profile, for instance, that I can edit, I wonder, can I edit someone else's profile? And this is how the Peloton attack work. I'm logged in, I'm allowed to see my things. What other things can I see? And it turns out they could see everything. So we also saw a hack with Clubhouse, which is the hot app now. I think it just opened up to Android users, but they were simply calling it back in to Gora, which is, you know, I've seen China. But once you've understood how the tokens work, once you understood what they were doing, you could essentially go in and figure things out. This seems to be like pretty trivial stuff, but it gets exposed. No one kind of thinks it through. How does someone protect themselves against these things? Because that's the real issue. Does this make it less secure? Our API is going to be more secure in the future. What can customers do about it? What do you guys to think about this? Yeah, so the reality is, I mean, there's just too many APIs out there. I mean, if you see the transition that is happening, that is to transformation where it used to be like a one app or two apps before, and now there are like hundreds and thousands of applications driven by the DevOps world, Agile development, and what matters is, I mean, the starting point really is, you cannot protect what you cannot see, right? What used to be an app hosted in your data center is now being hosted in the cloud environments, in the virtual environments, in serverless environments, and Kubernetes, you name it, they are out there. So the key is really to understand your attack surface. That's your starting point. So your tooling, your applications need to be able to provide that visibility that is needed to protect these applications. And you can't rely just on your developers to do this for you. So you need a right tool that can secure these applications. Jason, what's the steps that an attacker takes to uncover vulnerabilities? What goes through the mind of the attacker? I mean, the old days, you used to just do port scans and try to penetrate, you get through the perimeter. Now with this no perimeter mindset, the surface area as Shreya was talking about is huge. What's going on in the mind of the attacker here and the APIs and vulnerabilities? So the very first thing that we do is we sign up for an account. We use the thing, right? We look at all the different end points. I've got scripts running in my attack tools that do things like show me comments in case a developer left some comments in there to tell me where things are. I basically, I'm just going to poke around using it like a regular user, but in that I'm gonna look for places that make sense to try to do an attack. So a login screen is a real easy thing. Everybody understands that. You put in a username, you put in a password, you hit go. What I'm gonna do is put in a bad username and a bad password. I'm gonna put in a good username and a bad password. I'm gonna see what changes. What are the different things that your application is telling me? And so when we look at an application for flaws and ways to get to the data on the backend, all we're doing is seeing what data do you present me on? Standard use. And then I'm going to look at, well, how can I change these parameters or what are the things that I can change in my requests to get a different response? So in the early phases of an attack, attackers are very difficult to see, right? They just look like a regular user, just doing regular things. It's when we decide, all right, I've found something that it starts to get actually interesting and we start to try to pull data out. What are some of the common vulnerabilities and risks that you guys see in the APIs when you look, when you poke at them that people are doing? Is it they're not really doing their homework, doing good security design? Or is it just more of tech risk? What's the most common vulnerabilities and risks? Well, so for me, I've noticed a lot of the OWASP API top 10, the first couple of things you see them on almost all applications. So broken object level authorization is the first one, it's mouthful. But basically all it is is I log on to the platform, I'm authorized to be there, but I can see someone else's stuff. And that's exactly what happened in Peloton. That and what we call insecure direct object reference where I don't have to be logged in, I can just make the request without any authentication and get information back. So those are pretty common areas that people need to focus on, but there's a few others that are outside the OWASP top 10 that really make a lot more sense. As a defender, Shrainz probably has a little better answer than me. Yeah, so like we said, creating that inventories is key, but where are they being hosted is another aspect of things. So when Jason spoke about hackers are actually probing, trying to figure out what are the different entry points, it could be your production environment, it could be your QA environment, staging environment and you're not even aware of. But once you've actually figured out those entry points, the next step of attack was like at Peloton and other places is really exfiltrating that information. Is it your TII information, PHI information? And you don't want to exfiltrate as a hacker just one person's information, you're automating that business logic that is behind it. Ability to protect and defend against those kinds of attacks, giving that visibility, even though you might not have instrumented that application for that kind of visibility is key. Once you're bubbling up those behaviors, then you can go ahead and protect from these kinds of attacks. And it could be about just simply enumerating through IDs that Peloton might have or XP in might have and just enumerate through that and exfiltrate the information behind it. So the tools need to be able to protect from those kinds of attacks out there. Yeah, I think I was actually on Clubhouse when that went down, that whole enumerating through the IDs, room IDs and then the people just querying, once they got an ID, they essentially just sucked all the content out because they were just calling the back end. It was just like the most dumbest thing I've ever seen. But they didn't think about it. I mean, they were just rushing really fast. So the question I have for Sriyans is, on a defense basis, people are going first party with APIs, API first strategies. Because there's just some benefits there as we were talking about. What do I need to do to protect myself so I don't have that Clubhouse problem or the Peloton problem? Is there a playbook or is there software tools that I could use? How do I build my APIs from day one and my principles around it to be good hygiene or good design? What's the, what's the, what's the problem? Yeah, so API security is sort of a little less known, given that it's constantly evolving and changing and the adoption of APIs have gone up significantly. So what you need to start with effectively is the runtime security aspect of things. When an API is live, how do I actually protect it? And it ranges from simple syntactic protection, things around that people can go ahead and break these APIs by providing sort of going after endpoints that you don't think exist anymore or going after certain functions by giving large values that they're not sort of coded to accept and so on and so forth. Once you've done that runtime protection from a syntactic aspect, you also need to protect from a business logic aspect. I mean, APIs will expose to information interact with the customers and partners. What business logic are they actually exposing and how can it be abused? Understanding that is another big aspect and then you can go ahead and protect from a runtime, from a runtime security perspective. Once you've done that and understood that well, then you can start shifting left things invest in your sort of a DAS tools or static analysis tools, which can catch these things early so that they don't bubble up all the way. But none of them are actually silver bullets, right? So that you have a good runtime security tools or I don't need to invest in DAST or ASAST, whatever I've invested in my shift left aspect of things and nothing will flow through. So you need to start shifting left but cover all your basis properly. Yeah, you can't shift left, there's nothing to shift from. I mean, if you don't have that baseline foundation, what does that even mean to shift left and get that built into the CICD pipeline? So that's a great point. How does someone and some companies and teams set that foundation with a runtime? Do you think it's a critical problem right now or most people are doing a good job or they just get lazy or just lose track of it? Or what's the common use case? Do you see behavior or behaviorally inside these enterprises? Yeah, so what we're seeing is adoption of new technologies and environments and they're not well suited for the traditional way of doing runtime security. Like if you have an app running in your Kubernetes environment, if you have an app running in a server less environment, how do you actually protect it with a traditional appliance based approach? So I think being able to get that visibility into these environments, understanding the user behavior, how these applications are interacted with, being able to differentiate from that normal human behavior or even sometimes legitimate automation from the malicious intents or the probing and the business logic attacks is key to understanding and defending these applications. Before we wrap up, I want to just get your expert opinion since you guys are both here around the next level of innovation. Also, you've got cloud, public cloud showed us APIs are great. Now you're starting to see cloud operations, they call day two operations or whatever you want to call it, AI ops is all kinds of buzzwords for it, but hybrid cloud and multi-cloud edge, 5G, these are all basically pointing to distributed computing systems, basically distributed cloud. So that means more APIs are going to be out there. So anyway, the surface area of APIs is increasing. What's your view on this as a market? I mean, early days, developing fast and what's the landscape look like? What do you guys see from an attack and defense standpoint? Well, just from the attacker perspective, I see a lot more traffic going, what we call East West traffic where it's traveling inside the application. It's APIs feeding APIs more data, but what is really happening is we're trying to figure out how to hook third parties into our APIs more and more. The John Deere attack was just simply their development API platform that they open up for other organizations to integrate with them. You know, it's very beneficial for John Deere to be able to say, I planted this seed at an inch and a half a depth and later I harvested 280 bushels of corn off that acre. So I know that's perfect. I can feed that back to my seed guy. Well, that kind of data flow that's going around from API to API means that there's far more attack surface and we're gonna see it more and more. I don't think that we're gonna have less APIs communicating in the near future. I think this is the foundation that we're building for what it's gonna look like for almost every business in the near term. I mean, this is the plumbing of integration. I mean, as people work with each other, data transfer, data knowledge, format, you mentioned syntax and all these basic things in computer science are coming to APIs, which was supposed to be just a dump pipe or just, you know, rest API was a glory days. Now it's not, it's basically connections. Yeah, you're absolutely right, John. I mean, like what Jason mentioned earlier in terms of the way the APIs are gonna grow and the bad guys are gonna go after it. I mean, you need to think like a bad guy. What are they gonna go after? These assets that are gonna be in the cloud, in your hybrid environment, in your on-prem environment. And it's a flip of a switch where an internal API can be externally exposed or just a new API getting rolled out. So all those things you need to be able to protect and get that visibility first and then protect these environments. That's awesome. You guys represent the new kind of company that's going to take advantage of the cloud scale and as people shift to the new structural change and people are refactoring security, this is an area that's going to be explosive in development, obviously the upside is huge. Quickly to end, you guys, take a minute to give a plug for the company. This is pretty cool. I love what you guys do. I think it's very relevant and cool at the same time. So, SQL security, what are you guys doing? Funding, hiring, what's the plug? Tell folks about it. Yeah, so we started about six years ago, but like starting in the bot defense space but focusing on apps and APIs. And from then we've grown and we've grown significantly in terms of our customer base, the verticals that we're going after in financial, retail, social media, you name it, we are there because pretty much all these verticals depends on APIs to interact with their customers. We've raised our cities B last year, we've grown our customer base in just in the last year when there was a lockdown, people were, all these retailers were transforming it's from brick and mortar to online. Social media also grew and we grew with them. Jason, your thoughts? I think that the sequence is ability to scale out to any size environment. We've got a customer that does a billion and a half transactions a month that are APIs from a thousand other clients theirs. Being able to protect environments that are confusing and cloudy like that is really, it makes what we do shine. We use a lot of machine learning models and AI in order to surface real problems. And we have a lot of great humans behind all of that making sure that the bad guy may be there right now but they're going away and we're going to keep them away. Yeah, it's super, super awesome. I think it's a combination of more connections distributed computing at large scale with a data problem that's playing out you guys are solving great stuff. And hey, you know, when the Cube Studio API gets built, we're going to need to call you guys up to help us secure the Cube data. Absolutely. Absolutely. Hey, thanks for coming on the Cube. Great insight and thanks for sharing about sequence. Appreciate you coming on. Appreciate the time. Okay, it's a Cube conversation here in Palo Alto with remote guests. I'm John Furrier, your host. Thanks for watching.