>>Hello, and welcome to the cubes presentation of the AWS startup showcase. This is season two, episode four, the ongoing series covering exciting startups from the AWS ecosystem to talk about cyber security. I'm your host, John feer. And today we're excited to join by a Mediatel Walker, CEO of Quin security and sub IER, vice president of product management of sequence security gentlemen, thanks for joining us today on this showcase. >>Thank you, John PRAs. >>So the title of this session is continuous API protection life cycle to discover, detect, and defend security. APIs are part of it. They're hardened, everyone's using them, but they're they're target for malicious behavior. This is the focus of this segment. You guys are in the leading edge of this. What are the biggest challenges for organizations right now in assessing their security risks? Because you're seeing APIs all over the place in the news, just even this week, Twitter had a whistleblower come out from the security group, talking about their security plans, misleading the FTC on the bots and some of the malicious behavior inside the API interface of Twitter. This is really a mainstream Washington post is reporting on it. New York times, all the global outlets are talking about this story. This is the risk. I mean, yeah, this is what you guys do protect against this. >>Yeah, this is absolutely top of mind for a lot of security folks today. So obviously in the media and the type of attack that that is being discussed with this whistleblower coming out is called reputation bombing. This is not new. This has been going on since I would say at least eight to 10 years where the, the bad actors are using bots or automation and ultimately using APIs on these large social media platforms, whether it's Facebook, whether it's Twitter or some other social media platform and messing with the reputation system of those large platforms. And what I mean by that is they will do fake likes, fake commenting, fake retweeting in the case of Twitter. And what that means is that things that are, should not be very popular, all of a sudden become popular. That that way they're able to influence things like elections, shopping habits, personnel. >>We, we work with similar profile companies and we see this all the time. We, we mostly work on some of the secondary platforms like dating and other sort of social media platforms around music sharing and things like video sharing. And we see this all the time. These, these bots are bad. Actors are using bots, but ultimately it's an API problem. It's not just a bot problem. And that's what we've been trying to sort of preach to the world, which is your bot problem is subset of your API security challenges that you deal as an organization. >>You know, IMIA, we talked about this in the past on a previous conversation, but this really is front and center mainstream for the whole world to see around the challenges. All companies face, every CSO, every CIO, every board member organizations out there looking at this security posture that spans not just information technology, but physical and now social engineering. You have all kinds of new payloads of malicious behavior that are being compromised through, through things like APIs. This is not just about CSO, chief information security officer. This is chief security officer issues. What's your reaction >>Very much so I think the, this is a security problem, but it's also a reputation problem. In some cases, it's a data governance problem. We work with several companies which have very restrictive data governance and data regulations or data residency regulations there to conform to those regulations. And they have to look at that. It's not just a CSO problem anymore. In case of the, the news of the day to day, this is a platform problem. This goes all the way to the, that time CTO of Twitter. And now the CEO of Twitter, who was in charge of dealing with these problems. We see as just to give you an example, we, we work, we work with a similar sort of social media platform that allows Oop based login to their platform that is using tokens. You can sort of sign in with Facebook, sign in with Twitter, sign in with Google. These are API keys that are generated and trusted by these social media platforms. When we saw that Facebook leaked about 50 million of these login credentials or API keys, this was about three, four years ago. I wrote a blog about it. We saw a huge spike in those API keys being used to log to other social media platforms. So although one social platform might be taking care of its, you know, API or what problem, if something else gets reached somewhere else, it has a cascading impact on a variety of platforms. >>You know, that's a really interesting dynamic. And if you think about just the token piece that you mentioned, that's kind of under the coverage, that's a technology challenge, but also you get in the business logic. So let's go back and, and unpack that, okay, they discontinue the tokens. Now they're being reused here. In the case of Twitter, I was talking to an executive here in Silicon valley and they said, yeah, it's a cautionary tale, for sure. Although Twitter's a unique situation, but they abstract out the business value and say, Hey, they had an M and a deal on the table. And so if someone wants to unwind that deal, all I gotta say is, Hey, there's a bot problem. And now you have essentially new kinds of risk in the business have nothing to do with some sign the technology, okay. They got a security breach, but here with Twitter, you have an, an, an M and a deal, an acquisition that's being contested because of the, the APIs. So, so if you're in business, you gotta think to yourself, what am I risking with my API? So every organization should be assessing their security risks, tied to their APIs. This is a huge awakening for them. Where should they start? And that's the, that's the core question. Okay. You got my attention risks with the API. What do I do? >>So when I talked to you in my previous interview, the start is basically knowing what to, in most cases, you see these that are hitting the wire much. Every now there is a major in cases you'll find these APIs are targeted, that are not poorly protected. They're absolutely just not protected at all, which means the security team or any sort of team that is responsible for protecting these APIs are just completely unaware of these APIs being there in the first place. And this is where we talk about the shadow it or shadow API problem. Large enterprises have teams that are geo distributed, and this problem is escalated after the pandemic even more because now you have teams that are completely distributed. They do M and a. So they acquire new companies and have no visibility into their API or security practices. And so there are a lot of driving factors why these APIs are just not protected and, and just unknown even more to the security team. So the first step has to be discover your API attack surface, and then prioritize which APIs you wanna target in terms of runtime protection. >>Yeah. I wanna dig into that API kind of attack surface area management, runtime monitoring capability in a second, but so I wanna get you in here too, because we're talking about APIs, we're talking about attacks. What does an API attack look like? >>Yeah, that's a very good question, John, there are really two different forms of attacks of APIs, one type of attack, exploits, APIs that have known vulnerabilities or some form of vulnerabilities. For instance, APIs that may use a weak form of authentication or are really built with no authentication at all, or have some sort of vulnerability that makes them very good targets for an attacker to target. And the second form of attack is a more subtle one. It's called business logic abuse. It's, it's utilizing APIs in completely legitimate manner manners, but exploiting those APIs to exfiltrate information or key sensitive information that was probably not thought through by the developer or the designers or those APIs. And really when we do API protection, we really need to be able to handle both of those scenarios, protect against abuse of APIs, such as broken authentication, or broken object level authorization APIs with that problem, as well as protecting APIs from business logic abuse. And that's really how we, you know, differentiate against other vendors in this >>Market. So just what are the, those key differentiated ways to identify the, in the malicious intents with APIs? Can you, can you just summarize that real quick, the three ways? >>Sure. Yeah, absolutely. There are three key ways that we differentiate against our competition. One is in the, we have built out a, in the ability to actually detect such traffic. We have built out a very sophisticated threat intelligence network built over the entire lifetime of the company where we have very well curated information about malicious infrastructures, malicious operators around the world, including not just it address ranges, but also which infrastructures do they operate on and stuff like that, which actually helps a lot in, in many environments in especially B2C environments, that alone accounts for a lot of efficacy for us in detecting our weed out bad traffic. The second aspect is in analyzing the request that are coming in the API traffic that is coming in and from the request itself, being able to tell if there is credential abuse going on or credential stuffing going on or known patterns that the traffic is exhibiting, that looks like it is clearly trying to attack the attack, the APM. >>And the third one is, is really more sophisticated as they go farther and farther. It gets more sophisticated where sequence actually has a lot of machine learning models built in which actually profile the traffic that is coming in and separate. So the legitimate or learns the legitimate traffic from the anomalous or suspicious traffic. So as the traffic, as the API requests are coming in, it automatically can tell that this traffic does not look like legitimate traffic does not look like the traffic that this API typically gets and automatically uses that to figure out, okay, where is this traffic coming from? And automatically takes action to prevent that attack? >>You know, it's interesting APIs have been part of the goodness of cloud and cloud scale. And it reminds me of the old Andy Grove quote, founder of, in one of the founders of Intel, you know, let chaos, let, let the chaos happen, then reign it in it's APIs. You know, a lot of people have been creating them and you've got a lot of different stakeholders involved in creating them. And so now securing them and now manage them. So a lot of creation now you're starting to secure them and now you gotta manage 'em. This all is now big focus. As you pointed out, what are some of the dynamics that customers who have to deal with on the product side and, and organization, let, let chaos rain, and then rain in the chaos, as, as the saying goes, what, what do companies do? >>Yeah. Typically companies start off with like, like a mayor talked about earlier. Discovery is really the key thing to start with, like figuring out what your API attack surfaces and really getting your arms around that problem. And typically we are finding customers start that off from the security organization, the CSO organization to really go after that problem. And in some cases, in some customers, we even find like dedicated centers of excellence that are created for API security, which go after that problem to be able to get their arms around the whole API attack surface and the API protection problem statement. So that's where usually that problem starts to get addressed. >>I mean, organizations and your customers have to stop the attacks. A lot of different techniques, you know, run time. You mentioned that earlier, the surface area monitoring, what's the choice. What's the, where are, where are, where is everybody? Is everyone in the, in the boiling water, like the frog and boiling water or they do, they know it's happening? Like what did they do? What's their opportunity to get in >>Position? Yeah. So I, I think let's take a step back a little bit, right? What has happened is if you draw the cloud security market, if you will, right. Which is the journey to the cloud, the security of these applications or APIs at a container level, in terms of vulnerabilities and, and other things that market grew with the journey to the cloud, pretty much locked in lockstep. What has happened in the API side is the API space has kind of lacked behind the growth and explosion in the API space. So what that means is APIs are getting published way faster than the security teams are able to sort of control and secure them. APIs are getting published in environments that the security completely unaware of. We talked about in the past about the parameter, the parameter, as we know, it doesn't exist anymore. It used to be the case that you hit a CDN, you terminate your SSL, you stop your layer three and four DDoS. >>And then you go into the application and do the business logic. That parameter is just gone because it's now could be living in multi-cloud environment. It could be living in the on-prem environment, which is PubNet is friendly. And so security teams that are used to protecting apps, using a perimeter defense plus changes, it's gone. You need to figure out where your perimeter is. And therefore we sort of recommend an approach, which is have a uniform view across all your APIs, wherever they could be distributed and have a single point of control across those with a solution like sequence. And there are others also in this space, which is giving you that uniform view, which is first giving you that, you know, outside and looking view of what APIs to protect. And then let's, you sort of take the journey of securing the API life cycle. >>So I would say that every company now hear me out on this indulges me for a second. Every company in the world will be non perimeter based, except for maybe 5% because of maybe unique reason, proprietary lockdown, information, whatever. But for most, most companies, everyone will be in the cloud or some cloud native, non perimeter based security posture. So the question is, how does your platform fit into that trajectory? And specifically, why are you guys in the position in your mind to help customers solve this API problem? Because again, APIs have been the greatest thing about the cloud, right? Yeah. So the goodness is there because of APS. Now you gotta reign it in reign in the chaos. Yeah. What, what about your platform share? What is it, why is it win? Why should customers care about this? >>Absolutely. So if you think about it, you're right, the parameter doesn't exist. People have APIs deployed in multiple environments, multicloud hybrid, you name it sequence is uniquely positioned in a way that we can work with your environment. No matter what that environment is. We're the only player in this space that can protect your APIs purely as a SA solution or purely as an on-prem deployment. And that could be a SaaS platform. It doesn't need to be RackN, but we also support that and we could be a hybrid deployment. We have some deployments which are on your prem and the rest of this solution is in our SA. If you think about it, customers have secured their APIs with sequence with 15 minutes, you know, going live from zero to life and getting that protection instantaneously. We have customers that are processing a billion API calls per day, across variety of different cloud environments in sort of six different brands. And so that scale, that flexibility of where we can plug into your infrastructure or be completely off of your infrastructure is something unique to sequence that we offer that nobody else is offering >>Today. Okay. So I'll be, I'll be a naysayer. Yeah, look, it, we are perfectly coded APIs. We are the best in the business. We're locked down. Our APIs are as tight as a drum. Why do I need you? >>So that goes back to who's answer. Of course, >>Everyone's say that that's, that's great, but that's my argument. >>There are two types of API attacks. One is a tactic problem, which is exploiting a vulnerability in an API, right? So what you're saying is my APIs are secure. It does not have any vulnerability I've taken care of all vulnerabilities. The second type of attack that targets APIs is the business logic. Use this stuff in the news this week, which is the whistleblower problem, which is, if you think APIs that Twitter is publishing for users are perfectly secure. They are taking care of all the vulnerabilities and patching them when they find new ones. But it's the business logic of, you know, REWE liking or commenting that the bots are targeting, which they have no against. Right. And then none of the other social networks too. Yeah. So there are many examples. Uber wrote a program to impersonate users in different geo locations to find lifts, pricing, and driver information and passenger information, completely legitimate use of APIs for illegitimate, illegitimate purpose using bots. So you don't need bots by the way, don't, don't make this about bot versus not. Yeah. You can use APIs sort of for the, the purpose that they're not designed for sort of exploiting their business logic, either using a human interacting, a human farm, interacting with those APIs or a bot form targeting those APIs, I think. But that's the problem when you have, even when you've secured all your problem, all your APIs, you still have to worry about these of challenges. >>I think that's the big one. I think the business logic one, certainly the Twitter highlights that the Uber example is a good one. That is basically almost the, the backlash of having a simplistic API, which people design to. Right. Yeah. You know, as you point out, Twitter is very simple API, hardened, very strong security, but they're using it to maliciously manipulate what's inside. So in a way that perimeter's dead too. Right. So how do you stop that business logic? What's the, what's the solution what's the customer do about that? Because their goal is to create simple, scalable APIs. >>Yeah. I'll, I'll give you a little bit, and then I think Subaru should maybe go into a little bit of the depth of the problem, but what I think that the answer lies in what Subaru spoke earlier, which is our ML. AI is, is good at profiling plus split between the API users, are these legitimate users, humans versus bots. That's the first split we do. The split second split we do is even when these, these are classified users as bots, we will say there are some good bots that are necessary for the business and bad bots. So we are able to split this across three types of users, legitimate humans, good bots and bad bots. And just to give you an example of good bots is there are in the financial work, there are aggregators that are scraping your data and aggregating for end users to consume, right? Your, your, and other type of financial aggregators FinTech companies like MX. These are good bots and you wanna allow them to, you know, use your APIs, whereas you wanna stop the bad bots from using your APIs super, if you wanna add so, >>So good bots versus bad bots, that's the focus. Go ahead. Weigh in, weigh in on your thought on this >>Really breaks down into three key areas that we talk about here, sequence, right? One is you start by discovering all your APIs. How many APIs do I have in my environment that ly immediately highlight and say, Hey, you have, you know, 10,000 APIs. And that usually is an eye opener to many customers where they go, wow. I thought we had a 10th of that number. That usually is an eyeopener for them to, to at least know where they're at. The second thing is to tell them detection information. So discover, detect, and defend detect will tell them, Hey, your APIs are getting traffic from. So and so it addresses so and so infrastructure. So and so countries and so on that usually is another eye opener for them. They then get to see where their API traffic is coming from. Let's say, if you are a, if you're running a pizza delivery service out of California and your traffic is coming from Eastern Europe to go, wait a minute, nobody's trying, I'm not, I'm not, I don't deliver pizzas in Eastern Europe. Why am I getting traffic from that part of the world? So that sort of traffic immediately comes up and it will tell you that it is hitting your unauthenticated API. It is hitting your API. That has, that is vulnerable to a broken object level, that authorization, vulnerable be and so on. >>Yeah, I think, and >>Then comes the different aspect. Yeah. The different aspect is where you can take action and say, I wanna block certain types of traffic, or I wanna rate limit certain types of traffic. If, if you're seeing spikes there or you could maybe insert header so that it passes on to the end application and the application team can use that bit to essentially take a, a conscious response. And so, so the platform is very flexible in allowing them to take an action that suits their needs. >>Yeah. And I think this is the big trend. This is why I like what you guys are doing. One APIs we're built for the goodness of cloud. They're now the plumbing, you know, anytime you see plumbing involved, connection points, you know, that's pretty important. People are building it out and it has made the cloud what it is. Now, you got a security challenge. You gotta add more intelligence, more smarts to it. This is where I think platform versus tools matter. Can you guys just quickly share your thoughts on that? Cuz a lot of your customers and, and future customers have dealt with the sprawls of all these different tools. Right? I got a tool for this. I got a tool for that, but people are gravitating towards platforms, but how many platforms can a customer have? So again, this brings up the point point around how you guys are engaging with customers. Can you share your thoughts on tooling platforms? Your customers are constantly inundated with the same tsunami. Isn't new thing. Why, what, how should they look at this? >>Yeah, I mean, we don't wanna be, we don't wanna add to that alert fatigue problem that affects much of the cybersecurity industry by generating a whole bunch of alerts and so on. So what we do is we actually integrate very well with S IEM systems or so systems and allow customers to integrate the information that we are detecting or mitigating and feed them onto enterprise systems like a Splunk or a Datadog where they may have sophisticated processes built in to monitor, you know, spikes in anomalous traffic or actions that are taken by sequence. And that can be their dashboard where a whole bunch of alerting and reporting actually happens. So we play in the security ecosystem very well by integrating with other products and integrate very tightly with them, right outta the box. >>Okay. Mia, this is a wrap up now for the showcase. Really appreciate you guys sharing your awesome technology and very relevant product for your customers and where we are right now in this we call Supercloud or now multi-cloud or hybrid world of cloud. Share a, a little bit about the company, how people can get involved in your solution, how they can consume it and things they should know about, about sequence security. >>Yeah, we've been on this journey, an exciting journey it's been for, for about eight years. We have very large fortune 100 global 500 customers that use our platform on a daily basis. We have some amazing logos, both in Europe and, and, and in us customers are, this is basically not the shelf product customers not only use it, but depend on sequence. Several retailers. We are sitting in front of them handling, you know, black Friday, cyber, Monday, Christmas shopping, or any sort of holiday seasonality shopping. And we have handled that the journey starts by, by just simply looking at your API attack surface, just to a discover call with sequence, figure out where your APIs are posted work with you to prioritize how to protect them in a sort of a particular order and take the whole life cycle with sequence. This is, this is an exciting phase exciting sort of stage in the company's life. We just raised a very sort of large CDC round of funding in December from Menlo ventures. And we are excited to see, you know, what's next in, in, in the next, you know, 12 to 18 months. It certainly is the, you know, one of the top two or three items on the CSOs, you know, budget list for next year. So we are extremely busy, but we are looking for, for what the next 12 to 18 months are, are in store for us. >>Well, congratulations to all the success. So will you run the roadmap? You know, APIs are the plumbing. If you will, you know, they connection points, you know, you want to kind of keep 'em simple, as they say, keep the pipes dumb and make the intelligence around it. You seem to see more and more intelligence coming around, not just securing it, but does, where does this go in your mind? Where, where do we go beyond once we secure everything and manage it properly, APRs, aren't going away, they're only gonna get better and smarter. Where's the intelligence coming share a little bit. >>Absolutely. Yeah. I mean, there's not a dull moment in the space. As digital transformation happens to most enterprise systems, many applications are getting transformed. We are seeing an absolute explosion in the volume of APIs and the types of APIs as well. So the applications that were predominantly limited to data centers sort of deployments are now splintered across multiple different cloud environments are completely microservices based APIs, deep inside a Kubernetes cluster, for instance, and so on. So very exciting stuff in terms of proliferation of volume of APIs, as well as types of APIs, there's nature of APIs. And we are building very sophisticated machine learning models that can analyze traffic patterns of such APIs and automatically tell legitimate behavior from anomalous or suspicious behavior and so on. So very exciting sort of breadth of capabilities that we are looking at. >>Okay. I mean, yeah. I'll give you the final words since you're the CEO for the CSOs out there, the chief information security officers and the chief security officers, what do you want to tell them? If you could give them a quick shout out? What would you say to them? >>My shout out is just do an assessment with sequence. I think this is a repeating thing here, but really get to know your APIs first, before you decide what and where to protect them. That's the one simple thing I can mention for thes >>Am. Thank you so much for, for joining me today. Really appreciate it. >>Thank you. >>Thank you. Okay. That is the end of this segment of the eight of his startup showcase. Season two, episode four, I'm John for your host and we're here with sequin security. Thanks for watching.

(upbeat music) >> Hello, and welcome to this CUBE Conversation. I'm John Furrier, host of theCUBE here in Palo Alto, California for a great remote interview with Ameya Talwalkar, CEO of Cequence Security. Protecting APIs is the name of the game. Ameya thanks for coming on this CUBE Conversation. >> Thank you, John. Thanks for having us. >> So, I mean, obviously APIs, cloud, it runs everything. It's only going to get better, faster, more containers, more Kubernetes, more cloud-native action, APIs are at the center of it. Quick history, Cequence, how you guys saw the problem and where is it today? >> Yeah, so we started building the company or the product, the first product of the company focused on abuse or business logic abuse on APIs. We had design partners in large finance FinTech companies that are now customers of Cequence that were sort of API first, if you will. There were products in the market that were, you know, solving this problem for them on the web and in some cases mobile applications, but since these were API first very modern FinTech and finance companies that deal with lot of large enterprises, merchants, you have it, you name it. They were struggling to protect their APIs while they had protection on web and mobile applications. So that's the genesis. The problem has evolved exponentially in terms of volume size, pain, the ultimate financial losses from those problems. So it has, it's been a interesting journey and I think we timed it perfectly in terms of when we got started with the problem we started with. >> Yeah, I'm sure if you look at the growth of APIs, they're just exponentially growing because of the development, cloud-native development wave plus open source driving a lot of action. I was talking to a developer the other day and he's like, "Just give me a bag of Lego blocks and I'll build whatever application." I mean, this essentially- >> Yeah. >> API first is, has got us here, and that's standard. >> Yeah. >> Everyone's building on top of APIs, but the infrastructure going cloud-native is growing as well. So how do you secure APIs without slowing down the application velocity? Which everyone's trying to make go faster. So you got faster velocity on the developer side and (chuckles) more APIs coming. How do you secure the API infrastructure without slowing down the apps? >> Yeah, I'll come to the how part of it but I'll give you a little bit of commentary on what the problem really is. It's what has happened in the last few years is as you mentioned, the sort of journey to the cloud whether it's a public cloud or a private cloud, some enterprises have gone to a multi-cloud strategy. What really has happened is two things. One is because of that multi-environment deployment there is no defined parameter anymore to your applications or APIs. And so the parameter where people typically used to have maybe a CDN or WAF or other security controls at the parameter and then you have your infrastructure hosting these apps and APIs is completely gone away, that just doesn't exist anymore. And even more so for APIs which really doesn't have a whole lot of content to be cashed. They don't use CDN. So they are behind whatever API gateways whether they're in the cloud or whatever, they're hosting their APIs. And that has become your micro parameter, if you will, as these APIs are getting spread. And so the security teams are struggling with, how do I protect such a diverse set of environments that I am supposed to manage and protect where I don't have a unified view. I don't have even, like a complete view, if you will, of these APIs. And back in the days when phones or the modern iPhones and Android phones became popular, there used to be a sort of ad campaign I remember that said, "There is an app for that." >> Yeah. >> So the fast forward today, it's like, "There's an API for that." So everything you wanted to do today as a consumer or a business- >> John: Yeah. >> You can call an API and get your business done. And that's the challenge that's the explosion in APIs. >> Yeah. >> (laughs) Go ahead. >> It's interesting you have the API life cycle concept developing. Now you got, everyone knows- >> Right. >> The application life cycle, you know CI/CD pipelining, shifting left, but the surface area, you got web app firewalls which everyone knows is kind of like outdated, but you got API gateways. >> Yep. >> The surface area- >> Yeah. >> Is only increasing. So I have to ask you, do the existing API security tools out there bring that full application- >> Yeah. >> And API life cycle together? 'Cause you got to discover- >> Yep. >> The environment, you got to know what to protect and then also net new functionality. Can you comment? >> Right. Yeah. So that actually goes to your how question from, you know, previous section which is really what Cequence has defined is a API protection life cycle. And it's this concrete six-step process in which you protect your APIs. And the reason why we say it's a life cycle is it's not something that you do once and forget about it. It's a continuous process that you have to keep doing because your DevOps teams are publishing new APIs almost every day, every other day, if you will. So the start of that journey of that life cycle is really about discovering your external facing API attack surface which is where we highlight new hosting environments. We highlight accidental exposures. People are exposing their staging APIs. They might have access to production data. They are exposing Prometheus or performance monitoring servers. We find PKCS 7 files. We find Log4j vulnerabilities. These are things that you can just get a view of from outside looking in and then go about prioritizing which API environments you want to protect. So that's step number one. Step number two, really quick is do an inventory of all your APIs once you figure out which environments you want to protect or prioritize. And so that inventory includes a runtime inventory. Also creating specifications for these APIs. In lot of places, we find unmanaged APIs, shadow APIs and we create the API inventory and also push them towards sort of a central API management program. The third step is really looking at the risk of these APIs. Make sure they are using appropriate security controls. They're not leaking any sensitive information, PCI, PHI, PII, or other sort of industry-specific sensitive information. They are conforming to their schema. So sometimes the APIs dba.runtime from their schema and then that can cause a risk. So that's the first, sort of first half of this life cycle, if you will, which is really making sure your APIs are secure, they're using proper hygiene. The second half is about attack detection and prevention. So the fourth step is attack detection. And here again, we don't stop just at the OWASP Top 10 category of threats, a lot of other vendors do. They just do the OWASP API Top 10, but we think it's more than that. And we go deeper into business logic abuse, bots, and all the way to fraud. And that's sort of the attack detection piece of this journey. Once you detect these attacks, you start about, think about prevention of these attacks, also natively with Cequence. And the last step is about testing and making sure your APIs are secure even before they go live. >> What's- >> So that's a journey. Yeah. >> What's the secret sauce? What makes you different? 'Cause you got two sides to that coin. You got the auditing, kind of figure things out, and then you got the in-built attacks. >> Yeah. >> What makes you guys different? >> Yeah. So the way we are different is, first of all, Cequence is the only vendor that can, that has all these six steps in a single platform. We talked about security teams just lacking that complete view or consistent and uniform view of all your, you know, parameter, all your API infrastructure. We are combining that into a single platform with all the six steps that you can do in just one platform. >> John: Yeah. >> Number two is the outside looking in view which is the external discovery. It's something Cequence is unique in this space, uniquely doing this in this space. The third piece is the depth of our detection which is we don't just stop at the OWASP API Top 10, we go to fraud, business logic abuse, and bot attacks. And the mitigation, this will be interesting to you, which is a lot of the API security vendors say you come into existence because your WAF is not protecting your APIs, but they turn around when they detect the attacks to rely on a WAF to mitigate this or prevent these threats. And how can you sort of comprehend all that, right? >> Yeah. >> So we are unique in the sense we can prevent the attacks that we detect in the same platform without reliance on any other third-party solution. >> Yeah, I mean we- >> The last part is, sorry, just one last. >> Go ahead. Go ahead. >> Which is the scale. So we are serving largest of the large Fortune 100, Fortune 50 enterprises. We are processing 6 billion API calls per day. And one of the large customers of ours is processing 1 billion API calls per day with Cequence. So scale of APIs that we can process and how we can scale is also unique to Cequence. >> Yeah, I think the scale thing's a huge message. There, just, I put a little accent on that. I got to comment because we had an event last week called Supercloud which we were trying to talking about, you know, as clouds become more multicloud, you get more super capabilities. But automation, with super cloud comes super hackers. So as things advance, you're seeing the step function, the bad guys are getting better too. You mentioned bots. So I have to ask you what are some of the sophisticated attacks that you see that look like legitimate traffic or transactions? Can you comment on what your scale and your patterns are showing? Because the attacks are coming in fast and furious >> Correct. So APIs make the attack easier because APIs are well documented. So you want your partners and, you know, programmers to use your API ecosystem, but at the same time the attackers are getting the same information and they can program against those APIs very easily which means what? They are going to write a bunch of bots and automation to cause a lot of pain. The kind of sophistication we have seen is I'll just give a few examples. Ulta Beauty is one of our customers, very popular retailer in the US. And we recently found an interesting attack. They were selling some high-end hair curling high ends which are very high-end demand, very expensive, very hard to find. And so this links sort of physical path to API security, think about it, which is the bad guys were using a bot to scrape a third-party service which was giving local inventory information available to people who wanted to search for these items which are high in demand, low in supply. And they wrote a bot to find where, which locations have these items in supply, and they went and sort of broke into these showrooms and stole those items. So not only we say are saving them from physical theft and all the other problems that they have- >> Yeah. >> But also, they were paying about $25,000 per month extra- >> Yeah. >> For this geo-location service that was looking at their inventory. So that's the kind of abuse that can go on with APIs. Even when the APIs are perfectly secure, they're using appropriate security controls, these can go on. >> You know, that's a really great example. I'm glad you brought that up because I observed at AWS re:Inforce in Boston that Steven Schmidt has changed his title from chief information security officer to just chief security officer, to the point when asked he said, "Physical security is now tied together with the online." So to your point- >> Yeah. >> About the surveillance and attack setup- >> Yeah. >> For the physical, you got warehouses- >> Yep. >> You've got brick and mortar. This is the convergence of security. >> Correct. Absolutely. I mean, we do deal with many other, sort of a governance case. We help a Fortune 50 finance company which operates worldwide. And their gets concern is if an API is hosted in a certain country in Europe which has the most sort of aggressive data privacy and data regulations that they have to deal with, they want to make sure the consumer of that API is within a certain geo location whereby they're not subject to liabilities from GDPR and other data residency regulation. And we are the ones that are giving them that view. And we can have even restrict and make sure they're compliant with that regulation that they have to sort of comply with. >> I could only imagine that that geo-regional view and the intelligence and the scale gives you insights- >> Yeah. >> Into attacks that aren't really kind of, aren't supposed to be there. In other words, if you can keep the data in the geo, then you could look- >> Yep. >> At anything else as that, you know, you don't belong here kind of track. >> You don't belong here. Exactly. Yeah, yeah. >> All right. So let's get to the API. >> Yeah, I mean- >> So the API visibility is an issue, right? So I can see that, check, sold me on that, protection is key, but if, what's the current security team makeup? Are they buying into this or are they just kind of the hair on fire? What are security development teams doing? 'Cause they're under a lot of pressure to do the hardcore security work. And APIs, again, surface area's wide open, they're part of everyone's access. >> Yeah. So I mentioned about the six-step journey of the life cycle. Right? We see customers come to us with very acute pain point and they say, "Our hair is on, our hair on fire. (John laughing) Solve this problem for us." Like one large US telco company came to us to, just a simple problem, do the inventory and risk assessment of all our APIs. That's our number one pain point. Ended up starting with them on those two pain points or those two stops on their life cycle. And then we ended up solving all the six steps with them because once we started creating an inventory and looking at the risk profile, we also observed that these same APIs were target by bots and fraudsters doing all kinds of bad things. So once we discovered those problems we expanded the scope to sort of have the whole life cycle covered with the Cequence platform. And that's the typical experience which is, it's typically the security team. There are developer communities that are coming to us with sort of the testing aspect of it which integrated into DevOps toolchains and CI/CD pipelines. But otherwise, it's all about security challenges, acute pain points, and then expanding into the whole journey. >> All right. So you got the detection, you got the alerting, you got the protection, you got the mitigation. What's the advice- >> Yeah. >> To the customer or the right approach to set up with Cequence so that they can have the best protection. What the motion? What's the initial engagement look like? How do they engage? How do they operationalize? >> Yeah. >> You guys take me through that. >> Yeah. The simple way of engaging with Cequence is get that external assessment which will map your APIs for you, it'll create a assessment for you. We'll present that assessment, you know, to your security team. And like 90% of the times customers have an aha moment, (John chuckles) that they didn't know something that we are showing them. They find APIs that were not supposed to be public. They will find hosting environments that they didn't know about. They will find API gateways that were, like not commissioned, but being used. And so start there, start their journey with an assessment with Cequence, and then work with us to prioritize what problems you want to solve next once you have that assessment. >> So really making sure that their inventory of API is legit. >> Yep. Yep, absolutely. >> It's basically- >> Yep. >> I mean, you're starting to see more of this in the cloud-native, you know, Sbot, they call 'em, you know, (indistinct) materials. >> (Ameya faintly speaking). What do you got out there, kind of full understanding of what's being instrumented out there, big time. >> Yeah. The thing is a lot of analysts say that APIs is the number one attack vector this year and going forward, but you'll be surprised to see that it's not the APIs that get targeted that are poorly secured. Actually, the APIs that are completely not secured are the ones that are attacked the most because there are plenty of them. So start with the assessment, figure out the APIs that are out there and then start your journey. That's sort of my recommendation. >> So based on your advice what you're saying is there's a, most people make the mistake of having a lot of undocumented or unauthorized APIs out there that are unsecured. >> Yeah. And security teams are unaware of those APIs. So how do you protect something that you don't know even exists? >> Yeah. >> Right? So that's the challenge. >> Okay. You know, the APIs have to be secure. And as applications connect too, there's the other side of the APIs, whether that's credential passing, so much is at stake here relative to the security. It's not just access it's what's behind it. There's a lot of trust coming in. So, you know, I got to ask you a final question. You got zero trust and you got trust kind of coming together. What's (laughs), how do you respond to that? >> Yeah. Zero trust is part of it in the sense that you have to not trust sort of any API consumer as a completely trusted entity. Just like I gave you the Ultra Beauty example. They had trusted this third party to be absolutely safe and secure, you know, no controls necessary to sort of monitor their traffic, whereas they can be abused by their end consumers and cause you a lot of pain. So there is a sort of a linkage between zero trust. Never trusts anybody until you verify, that's the sort of angle, that's sort of the connection between APIs security and zero trust. >> Ameya, thank you for coming on theCUBE. Really appreciate the conversation. I'll give you the final word. What should people know about Cequence Security? How would you give the pitch? You go, you know, quick summary, what's going on? >> Yeah. So very excited to be in this space. We sort of are the largest security of API security vendor in the space in terms of revenue, the largest volume of API traffic that we process. And we are just getting started. This is a exciting journey we are on, we are very happy to serve the, you know, Fortune 50, you know, global 200 customers that we have, and we are expanding into many geographies and locations. And so look for some exciting updates from us in the coming days. >> Well, congratulations on your success. Love the approach, love the scale. I think scale's a new competitive advantage. I think that's the new lock-in if you're good, and your scaling providing a lot of benefits. So Ameya, thank you for coming, sharing the story. Looking forward to chatting again soon. >> Thank you very much. Thanks for having us. >> Okay. This is a CUBE Conversation. I'm John Furrier, here at Palo Alto, California. Thanks for watching. (cheerful music)

(gentle upbeat music) >> Okay, welcome back everyone to theCUBE's live coverage here in Boston, Massachusetts for AWS RE:INFORCE 22. I'm John Furrier, your host with Dave Vellante co-host of theCUBE, and Shreyans Metah, CTO and founder of Cequence Security. CUBE alumni, great to see you. Thanks for coming on theCUBE. >> Yeah. Thanks for having me here. >> So when we chatted you were part of the startup showcase. You guys are doing great. Congratulations on your business success. I mean, you guys got a good product in hot market. >> Yeah. >> You're here before we get into it. I want to get your perspective on the keynote and the talk tracks here and the show. But for the folks that don't know you guys, explain what you guys, take a minute to explain what you guys do and, and key product. >> Yeah, so we are the unified API protection place, but I mean a lot of people don't know what unified API protection is but before I get into that, just just talking about Cequence, we've been around since 2014. But we are protecting close to 6 billion API transactions every day. We are protecting close to 2 billion customer accounts, more than 2 trillion dollars in customer assets and a hundred million plus sort of, data points that we look at across customer base. That's that's who we are. >> I mean, of course we all know APIs is, is the basis of cloud computing and you got successful companies like Stripe, for instance, you know, you put API and you got a financial gateway, billions of transactions. What's the learnings. And now we're in a mode now where single point of failure is a problem. You got more automation you got more reasoning coming a lot more computer science next gen ML, AI there too. More connections, no perimeter. Right? More and more use cases, more in the cloud. >> Yeah. So what, what we are seeing today is, I mean from six years ago to now, when we started, right? Like the monolith apps are breaking down into microservices, right? What effectively, what that means is like every of the every such microservices talking APIs, right? So what used to be a few million web applications have now become billions of APIs that are communicating with each other. I mean, if you look at the, I mean, you spoke about IOT earlier, I call, I call like a Tesla is an application on four wheels that is communicating to its cloud over APIs. So everything is API yesterday. 80% traffic on internet is APIs. >> Now that's dated transit right there. (laughing) Couldn't resist. >> Yeah. >> Fully encrypted too. >> Yeah. >> Yeah, well hopefully. >> Maybe, maybe, maybe. (laughing) We dunno yet, but seriously everything is talking to an API. >> Yeah. >> Every application. >> Yeah. And, and there is no single choke point, right? Like you spoke about it. Like everybody is hosting their application in the cloud environments of their choice, AWS being one of them. But it's not the only one. Right? The, the, your APIs are hosted behind a CDN. Your APIs are hosted on behind an API gateway behind a load balancer in guest controllers. There is no single. >> So what's the problem? What's the problem now that you're solving? Because one was probably I can imagine connecting people, connecting the APIs. Now you've got more operational data. >> Yeah. >> Potential security hacks? More surface area? What's the what's what are you facing? >> Well, I can speak about some of the, our, some of the well known sort of exploits that have been well published, right. Everybody gets exploited, but I mean some of the well knowns. Now, if you, if you heard about Expedian last year there was a third party API that was exposing your your credit scores without proper authentication. Like Facebook had Ebola vulnerability sometime ago, where people could actually edit somebody else's videos online. Peloton again, a well known one. So like everybody is exposed, right. But that is the, the end results. All right? But it all starts with people don't even know where their APIs are and then you have to secure it all the way. So, I mean, ultimately APIs are prone to business logic attacks, fraud, and that's what, what you need to go ahead and protect. >> So is that the first question is, okay, what APIs do I need to protect? I got to take a API portfolio inventory. Is that? >> Yeah, so I think starting point is where. Where are my APIs? Right, so we spoke about there's no single choke point. Right, so APIs could be in, in your cloud environment APIs could be behind your cloud front, like we have here at RE:INFORCE today. So APIs could be behind your AKS, Ingrid controllers API gateways. And it's not limited to AWS alone, right. So, so knowing the unknown is, is the number one problem. >> So how do I find him? I asked Fred, Hey, where are our API? No, you must have some automated tooling to help me. >> Yeah, so, I, Cequence provides an option without any integration, what we call it, the API spider. Whereas like we give you visibility into your entire API attack surface without any integration into any of these services. Where are your APIs? What's your API attack surface about? And then sort of more details around that as well. But that is the number one. Is that agent list or is that an agent? >> There's no agent. So that means you can just sign up on our portal and then, then, then fire it away. And within a few minutes to an hour, we'll give you complete visibility into where your API is. >> So is it a full audit or is it more of a discovery? >> Or both? >> So, so number one, it's it's discovery, but we are also uncovering some of the potential vulnerabilities through zero knowledge. Right? So. (laughing) So, we've seen a ton of lock for J exposed server still. Like recently, there was an article that lock four J is going to be endemic. That is going to be here. >> Long time. >> (laughs) For, for a very long time. >> Where's your mask on that one? That's the Covid of security. >> Yeah. Absolutely absolutely. So, you need to know where your assets are what are they exposing? So, so that is the first step effectively discovering your attack surface. Yeah. >> I'm sure it's a efficiency issue too, with developers. The, having the spider allows you to at least see what's connecting out there versus having a meeting and going through code reviews. >> Yeah. Right? Is that's another big part of it? >> So, it is actually the last step, but you have, you actually go through a journey. So, so effectively, once you're discovering your assets you actually need to catalog it. Right. So, so I know where they're hosted but what are developers actually rolling out? Right. So they are updating your, the API endpoints on a daily basis, if not hourly basis. They have the CACD pipelines. >> It's DevOps. (laughing) >> Welcome to DevOps. It's actually why we'll do it. >> Yeah, and people have actually in the past created manual ways to catalog their APIs. And that doesn't really work in this new world. >> Humans are terrible at manual catalogization. >> Exactly. So, cataloging is really the next step for them. >> So you have tools for that that automate that using math, presumably. >> Exactly. And then we can, we can integrate with all these different choke points that we spoke about. There's no single choke points. So in any cloud or any on-prem environment where we actually integrate and give you that catalog of your APIs, that becomes your second step really. >> Yeah. >> Okay, so. >> What's the third step? There's the third step and then compliance. >> Compliance is the next one. So basically catalog >> There's four steps. >> Actually, six. So I'll go. >> Discovery, catalog, then compliance. >> Yeah. Compliance is the next one. So compliance is all about, okay, I've cataloged them but what are they really exposing? Right. So there could be PII information. There could be credit card, information, health information. So, I will treat every API differently based on the information that they're actually exposing. >> So that gives you a risk assessment essentially. >> Exactly. So you can, you can then start looking into, okay. I might have a few thousand API endpoints, like, where do I prioritize? So based on the risk exposure associated with it then I can start my journey of protecting so. >> That that's the remediation that's fixing it. >> Okay. Keep going. So that's, what's four. >> Four. That was that one, fixing. >> Yeah. >> Four is the risk assessment? >> So number four is detecting abuse. >> Okay. >> So now that I know my APIs and each API is exposing different business logic. So based on the business you are in, you might have login endpoints, you might have new account creation endpoint. You might have things around shopping, right? So pricing information, all exposed through APIs. So every business has a business logic that they end up exposing. And then the bad guys are abusing them. In terms of scraping pricing information it could be competitors scraping pricing. They will, we are doing account take. So detecting abuse is the first step, right? The fifth one is about preventing that because just getting visibility into abuse is not enough. I should be able to, to detect and prevent, natively on the platform. Because if you send signals to third party platforms like your labs, it's already too late and it's too course grain to be able to act on it. And the last step is around what you actually spoke about developers, right? Like, can I shift security towards the left, but it's not about shifting left. Just about shifting left. You obviously you want to bring in security to your CICD pipelines, to your developers, so that you have a full spectrum of API securities. >> Sure enough. Dave and I were talking earlier about like how cloud operations needs to look the same. >> Yeah. >> On cloud premise and edge. >> Yes. Absolutely. >> Edge is a wild card. Cause it's growing really fast. It's changing. How do you do that? Cuz this APIs will be everywhere. >> Yeah. >> How are you guys going to reign that in? What's the customers journey with you as they need to architect, not just deploy but how do you engage with the customer who says, "I have my environment. I'm not going to be to have somebody on premise and edge. I'll use some other clouds too. But I got to have an operating environment." >> Yeah. "That's pure cloud." >> So, we need, like you said, right, we live in a heterogeneous environment, right? Like effectively you have different, you have your edge in your CDN, your API gateways. So you need a unified view because every gateway will have a different protection place and you can't deal with 5 or 15 different tools across your various different environments. So you, what we provide is a unified view, number one and the unified way to protect those applications. So think of it like you have a data plane that is sprinkled around wherever your edges and gateways and risk controllers are and you have a central brains to actually manage it, in one place in a unified way. >> I have a computer science or computer architecture question for you guys. So Steven Schmidt again said single controls or binary states will fail. Obviously he's talking from a security standpoint but I remember the days where you wanted a single point of control for recovery, you talked about microservices. So what's the philosophy today from a recovery standpoint not necessarily security, but recovery like something goes wrong? >> Yeah. >> If I don't have a single point of control, how do I ensure consistency? So do I, do I recover at the microservice level? What's the philosophy today? >> Yeah. So the philosophy really is, and it's very much driven by your developers and how you want to roll out applications. So number one is applications will be more rapidly developed and rolled out than in the past. What that means is you have to empower your developers to use any cloud and serverless environments of their choice and it will be distributed. So there's not going to be a single choke point. What you want is an ability to integrate into that life cycle and centrally manage that. So there's not going to be a single choke point but there is going to be a single control plane to manage them off, right. >> Okay. >> So you want that unified, unified visibility and protection in place to be able to protect these. >> So there's your single point of control? What about the company? You're in series C you've raised, I think, over a hundred million dollars, right? So are you, where are you at? Are you scaling now? Are you hiring sales people or you still trying to sort of be careful about that? Can you help us understand where you're at? >> Yeah. So we are absolutely scaling. So, we've built a product that is getting, that is deployed already in all these different verticals like ranging from finance, to detail, to social, to telecom. Anybody who has exposure to the outside world, right. So product that can scale up to those demands, right? I mean, it's not easy to scale up to 6 billion requests a day. So we've built a solid platform. We've rolled out new products to complete the vision. In terms of the API spider, I spoke about earlier. >> The unified, >> The unified API protection covers three aspects or all aspects of API life cycle. We are scaling our teams from go to market motion. We brought in recently our chief marketing officer our chief revenue officer as well. >> So putting all the new, the new pieces in place. >> Yeah. >> So you guys are like API observability on steroids. In a way, right? >> Yeah, absolutely. >> Cause you're doing the observability. >> Yes. >> You're getting the data analysis for risk. You're having opportunities and recommendations around how to manage the stealthy attacks. >> From a full protection perspective. >> You're the API store. >> Yeah. >> So you guys are what we call best of breed. This is a trend we're seeing, pick something that you're best in breed in. >> Absolutely. >> And nail it. So you're not like an observability platform for everything. >> No. >> You guys pick the focus. >> Specifically, APS. And, so basically your, you can have your existing tools in place. You will have your CDN, you will have your graphs in place. So, but for API protection, you need something specialized and that stuff. >> Explain why I can't just rely on CDN infrastructure, for this. >> So, CDNs are, are good for content delivery. They do your basic TLS, and things like that. But APIs are all about your applications and business that you're exposing. >> Okay, so you, >> You have no context around that. >> So, yeah, cause this is, this is a super cloud vision that we're seeing of structural change in the industry, a new thing that's happening in real time. Companies like yours are be keeping a focus and nailing it. And now the customer's can assemble these services and company. >> Yeah. - Capabilities, that's happening. And it's happening like right now, structural change has happened. That's called the cloud. >> Yes. >> Cloud scale. Now this new change, best of brief, what are the gaps? Because I'm a customer. I got you for APIs, done. You take the complexity away at scale. I trust you. Where are the other gaps in my architecture? What's new? Cause I want to run cloud operations across all environments and across clouds when appropriate. >> Yeah. >> So I need to have a full op where are the other gaps? Where are the other best of breed components that need to be developed? >> So it's about layered, the layers that you built. Right? So, what's the thing is you're bringing in different cloud environments. That is your infrastructure, right? You, you, you either rely on the cloud provider for your security around that for roll outs and operations. Right? So then is going to be the next layer, which is about, is it serverless? Is it Kubernetes? What about it? So you'll think about like a service mesh type environment. Ultimately it's all about applications, right? That's, then you're going to roll out those applications. And that's where we actually come in. Wherever you're rolling out your applications. We come in baked into that environment, and for giving you that visibility and control, protection around that. >> Wow, great. First of all, APIs is the, is what cloud is based on. So can't go wrong there. It's not a, not a headwind for you guys. >> Absolutely. >> Great. What's a give a quick plug for the company. What are you guys looking to do hire? Get customers who's uh, when, what, what's the pitch? >> So like I started earlier, Cequence is around unified API protection, protecting around the full life cycle of your APIs, ranging from discovery all the way to, to testing. So, helping you throughout the, the life cycle of APIs, wherever those APIs are in any cloud environment. On-prem or in the cloud in your serverless environments. That's what Cequence is about. >> And you're doing billions of transactions. >> We're doing 6 billion requests every day. (laughing) >> Which is uh, which is, >> A lot. >> Unheard for a lot of companies here on the floor today. >> Sure is. Thanks for coming on theCUBE, sure appreciate it. >> Yeah. >> Good, congratulations to your success. >> Thank you. >> Cequence Security here on theCUBE at RE:INFORCE. I'm chatting with Dave Vellante, more coverage after this short break. (upbeat, gentle music)

(Upbeat music) >> Welcome to theCUBE's presentation of the AWS Startup Showcase, the next big thing in AI, security, and life sciences. We're here in the security track, and in this segment we feature Cequence Security. I'm your host, Dave Vellante, and today, we're joined by Subbu Iyer, who's the vice president of products at Cequence Security. And we're going to discuss the importance of rapidly discovering and addressing common API security gaps. We live in this API economy, and there's dangers out there. Welcome, Subbu. Great to have you on the Cube. >> Thanks, Dave. I'm happy to be here. >> Okay, every week, there's some other report in the paper, in the news, high profile security breaches. We all know about the Experian breach, the Clubhouse, a pretty popular app, and many, many others. But you know what's perhaps more scary is the ones we don't hear about, and there are a lot of those. APIs are increasingly targeted by cyber criminals as a weak link to steal data and commit fraud. So, Subbu, in thinking about your customers and how they're using your solution, what are some of the patterns that you're discerning, and how are you addressing this problem within your community? >> Yeah, APIs are a very common avenue for exploiting vulnerabilities in applications, and what we are discovering amongst our customers is that there are elementary gaps that are being left behind in APIs. For instance, APIs that are completely unauthenticated, and it's practically like leaving your front door open and allowing anybody to walk in. I mean, there are APIs that aren't authenticated, APIs that are exposing sensitive information, like credit card numbers or social security numbers completely out in the clear. Or APIs that are using weak forms of authentication that are very easily bypassed. The OWASP API top ten is actually a pretty good handy list for people to look up, and those are, we see many of those as being very commonly seen vulnerabilities in APIs. >> Yeah. I mean, your adversaries, they're experts at automation. They knock on that door, and if it's open, they come right in. (Laughs) They don't even have to manually do it. They just automatic. So, talk a little bit more about that, that problem of poor API visibility in this world in which we now live. >> Yeah. You nailed it. I mean, visibility is the number one thing that everybody should be thinking about. In an age where APIs are ubiquitous, like everything talks to everything else by APIs, lack of knowledge of how many APIs there are out there that a customer has exposed is the number one challenge that anybody should start with. Getting your arms around the problem statement of how many APIs do I have that are publicly exposed, are privately exposed to other organizations, is really where it all starts. And once you have discovered all those APIs, then you basically look at what risk those APIs pose to you, like how many of those APIs aren't authenticated? How many of those APIs are using very weak forms of authentication or are exposing sensitive information on, you know, subject to some of the other commonly seen risks? >> You know, authentication is the other area. And not just humans. You know, talking about machines as well. So, this is a critical weak link, and it's fraught with complexity. You've got multiple devices. You've got service connections. And it's very error prone. How much of a problem is this, and what can we do about it? >> Authentication is actually the most basic and the most commonly seen vulnerability or flaw in APIs. The most common flaw that we see in APIs is the problem of APIs not having any authentication at all or having very weak forms of authentication. To kind of go back to our front door analogy, that's like either leaving your front door completely unlocked, or leaving your front door locked and leaving the key under the doormat hoping that nobody is going to pull up the doormat and find the key in there. Like, it's pretty much the equivalent of that for APIs that we see. That's really the gambit of like authentication related issues that we see, like in that ballpark of either weak forms of authentication that attackers really don't have to even break a sweat to kind of find their way around them and walk in. >> You know, I recently wrote about this. I wanted to ask you about another disturbing trend that we see, and that's, you know, adversaries, they're looking in our environments, and they're stealth. You know, they're living off the land and using your tools against you so you don't even see them a lot of times. While they're there, they're exfiltrating troves of very valuable information. In one study I read, they were committing fraud and identity theft, but they were also stealing sensitive data so they could act on it, like front running a trade. And so... And then they would hold that data, that sensitive data. Another example, it was healthcare data, private information. And they're hold it on reserve, so to speak, so they could extort victims once they're discovered and there's an incident response. So this exposure to sensitive data, it's an enormous problem, and I wonder if you could share your thoughts on this topic and how to help remediate it. >> Yep. Sensitive data exposure is another one of the OWASP API top ten, and something that we see pretty often with APIs. And you're right. Adversaries basically look for avenues where they can exploit these sensitive data flaws that an API may have. Common ways of doing that are maybe the attacker discovers or finds the mobile application for that particular application. It may be a retail app, a finance app. And the user may create a valid account in there, so get in there as a valid account, and see the APIs that are being communicated by the mobile app with the API backend, and then see if they can retrieve other people's information or that same API, by changing the user ID or other tokens that they are sending back. And if they are able to break in and they're actually able to get other users' information, that's basically exfiltration, data exfiltration. And they just run that in a script and are able to exfiltrate lots of data from the API backend if the access control on the backend is weak and this API is really not protected very well. So, one of the key things that we do in Cequence is provide visibility to our customers about what form, which APIs are exposing sensitive data information. What sensitive information are they? So, are they credit card numbers, social security numbers, some other proprietary identifiers that a customer may have, and really how are they leaking this information? Is it in the response body? Is it in the response header? And so on. So, we really give them the ability to hone in on where the leakage is happening. >> Okay. So, full visibility. Maybe talk a little bit more about that. I mean, can you share a little bit about, you know, your secret sauce, if you will? Your kind of unique approach to solving this problem? >> Yeah. That's a good questions. So, Cequence is in the business of providing continuous visibility and monitoring and protection to customers for their public facing web applications and APIs. And we do this by essentially providing the ability, to start with, to customers to discover all of their public facing APIs. And we do that by essentially tapping into their network at various points. We can tap into an API gateway, a load balancer, or really deep into their microservices applications, to tap into their modern API-based applications as well. And by tapping into multiple sources within their environment, we are essentially gleaning a complete picture of what their application attack surface looks like. So, all of these become what we call sensors that essentially communicate information back to a central repository and aggregate all that information together, and then produce this visibility of saying you have however many APIs. And then that's where a lot of analysis happens to see who's communicating all of these APIs. Are we getting traffic from external sources? internal sources? How are the API communications happening? Is it in clear text? And so on. And that's where the visibility really happens. >> And these so-called sensors, they're sort of embedded as part of your service. So, I'm acquiring a service from you, correct? Maybe you could describe a little bit more about how I interact with your product portfolio. >> Yep, yep. So, our technology is flexible enough that it can be completely deployed as a software as a service, so needing nothing to be deployed on a customer's premises at all. Or it can, or we are flexible enough to actually support on premises deployments for some of our larger customers like financial customers or other data privacy related customers who would rather have this infrastructure on their premises. And these sensors are really these little modules that go in their network environment, so they're easy to deploy, easy to integrate with any network-based options like load balancers or firewalls or API gateways. And really, the backend can be consumed either as a software based application like a docker or Kubernetes application on the customer's premises, or consumed within the sequence cloud, so needing absolutely nothing to be managed or maintained by the customer at all. So, really the customer, to start with, essentially comes to Cequence and says, "Hey, how do I get an environment up and running where I can play with my, where I can discover my APIs?" And we can spin up an environment in our cloud in a matter of minutes or hours. And before you know it, we can drop a couple of sensors in their environment, and we are discovering their APIs. >> And then what? So, if you... You discover some APIs, the key under the doormat, so to speak, what do I then do as a customer? How do you help me accelerate that remediation? >> Excellent. And that's where one of the important aspects of our product called mitigation comes in the picture. Mitigation is a remediation action where a customer can actually take action in the run time to actually stop some of this back traffic from happening. For instance, if you see an API that... One of the common things that we discover in APIs are what we call shadow APIs. So, when we talked about API visibility, what a customer discovers is all of their known APIs and unknown APIs. So known APIs are APIs that they know about. Oh, that's my payment API. This is my billing API, and so on. And they also discover APIs that they did not know exist, like a newer version of an API that the development team has exposed. And they go, "Wait a minute. When, how did that get exposed to the public? We haven't even done a security audit of this thing." So, if they see APIs like this that should not have been made public but are public and are being used, they can use Cequence to essentially block traffic to those APIs, these unreleased APIs, or these hidden APIs that should never have gone public but are public, either because of unintentional mistakes on somebody's part or because of certain compliance loopholes or something that these were made public. So, we can take action and prevent traffic from hitting these APIs. >> And I would imagine, Subbu, that, I mean, every environment's different. I mean, I would imagine people make the same mistakes across different environments, but every environment is really a snowflake. I mean, it's an individual, you know, configuration. And so... But I wonder, are you seeing, well, sort of what was my first question, what kind of patterns are you seeing? But are you seeing, you know, customers exposed in sort of the same areas? Or are you seeing like I'm describing, every situation is different? >> We do see situations being different. >> Hmm. >> I have seen environments where the production environment had a weaker security posture than a development environment. >> Hmm. >> That was presumably because the development environment was running a newer version of their application, so it had plugged some of these API gaps, was not leaking sensitive information. But the production environment is running an older version. So, it had flaws that the development environment did not. And I've seen vice versa as well. So, really it depends upon like how their CI/CD processes, how soon are they able to get these applications into production, and so on. And accordingly, they put in actions in, let's say, in the appropriate environment, the dev environment or the prod environment to stop these attacks from hitting that environment. >> So, if a customer comes to you, you know, fresh, you haven't worked with that customer, and then you deploy these sensors and you help them sort of clean up their operation. And presumably they want to keep working with you because their environment is constantly changing, are they then... You know, it's kind of a cliche, but shifting left, you know, where they're building this in to their development process as opposed to saying, "Okay, we've just deployed. Now let's call Cequence in." Right? Are you able to align with the development life cycle more closely? >> Yeah. Yeah, yeah. That's an ideology that we do here at Cequence. What we say is shift left while shielding right. What that means is, yes, shifting left is an important strategy for you to essentially take these actions earlier on in the development process before these APIs become public. But one of the key tenets of application security is to shield your applications from bad traffic. Shield your applications from these attackers who are trying to enumerate these IDs and trying to exfiltrate information. So, you need to protect your applications from bad traffic. So, while shielding the right, we allow customers to start shielding left so that they can start testing some of these APIs before they go into production. So, before these APIs even become, see the light of day, let's say a newer version of an API, we are working with customers in that journey so that they can find this sooner and sooner in the development life cycle. So, yep. We absolutely see that as an evolution for customers. >> Thank you for that. So, I got two more questions for you. The first one is kind of a fun question that theCUBE team, you know, wanted to ask. We're asking all the startups. Remember, the event, it's all about cloud scale. And so, of course, when you launch a company, a startup, it's exciting time. You're innovating, developing new products, moving fast, breaking things, helping customers out, disrupting. All those cool things. Growing the company. You know, increasing revenue. Great. But there's more even. And so what we're asking folks like yourself, Subbu, is what is your defining contribution to the future of cloud scale? >> Yep. So, cloud scale is not possible without a digital transformation of applications. So, applications have to be digitally transformed so that they are ready for the modern cloud age. And in order to do that, applications have to become API first. They have to understand APIs. They have to communicate to other applications why APIs and allow other applications to communicate by APIs. So, to truly achieve cloud scale, digital transformation is an absolute must. And we are playing our part in that journey for customers in digital transformation by allowing them to go on to their digital transformation journeys and allowing cloud scale by protecting their APIs, allowing them to discover their APIs and protecting their APIs, allowing them to reach cloud scale. >> Great. Thank you for that. Now, let's summarize, and I wonder if you can sort of bring us home, and give us your thoughts. I mean, there's a balancing act that we have to do between you want to tap into the API trend and the value that it brings, but at the same time, you got to mitigate the risks associated with that. And just give us a summary on the right prescription. >> Yep. So, to kind of bring it all together, right? API security is top of minds for many (indistinct) across the board. And it all starts with API visibility. You cannot protect what you cannot see. So, you have to be able to discover your entire API attack surface so you know what's going on with your APIs. And then you put in shield right strategies where you essentially are blocking the bad traffic from hitting your applications. That's basically the logical evolution from, you know, discovering the bad traffic in your environment. First, visibility, and then protect what is going on. And then start shielding left, shifting left, by essentially being able to take these actions sooner in your development life cycle so that some of these bad traffic can never possibly hit your applications because you have shifted left. >> Excellent. Well, Subbu, thanks so much for coming on theCUBE today. It was great to have you. Great stuff. >> Thank you, Dave, for having me. This was great. Thank you so much. >> Our pleasure. And thank you for watching theCUBE's presentation of the AWS Startup Showcase, the next big thing in AI, security, and life sciences. Keep it right there for more great content. (upbeat music begins) (upbeat music fades out)

>>Mhm Yes. Welcome to this cube conversation. I'm john Kerry host of the cube here in Palo alto California. We've got two great guests all the way from Ohio and here in the bay area with sequence securities is our focus on cloud growth companies. Sri and met a co founder and CTO of sequence security and Jason Kent hacker in residence at sequence security. We're gonna find out what that actually means in the second but this is a really important company in the sense of A P. I. S. As they are starting to be the connective tissue between systems and and data. Um you're starting to see more vulnerabilities, more risk but also more upside. So risk, reward is high. And anyone who's doing things in the cloud obviously deals with the A. P. I. So Trey and Jason. Thanks for let's keep conversation. >>Happy to be here >>guys. Let's let's talk about A P. I. Security. And but first before we get there trans what does sequence security do? What do you guys specifically build? And what do you sell >>sequences in the business protecting your web and um A P. I. S from various kinds of attacks? Uh We protect from business logic attacks, A P. I. Uh do your api inventory, uh also the detect and defend against things like a town taker. Where's fake account creation, scraping pretty much anything and everything. An application on a PDA is exposed to from from the Attackers. >>Jason. What do you what do you do there as hacker and residents? I also want to get your perspective on api security from the point of view of, you know, uh attack standpoint from a vector. How are people doing it? So first explain what you do and uh 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 be on the client's backdoors and and try to hit their A. P. I. S. 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. Um as a hacker and residents, my mostly my position is client facing. But I do spend an awful lot of time being research and looking for the next api threat that's out there. >>You gotta 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, very highly visible company, It represents that new breed of digital companies that have a new approach and it's absolutely 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 A. P. I. Issue recently. Um what does it mean? Is that, is that something we're gonna see more of these kind of leaks in these kind of vulnerabilities? What do you guys think about this political thing, >>You know, from an attacker's perspective as a really boring attack? Um, but it led to a huge amount of data leaking out. Same with, you know, the news has been been right with this lately, right, john Deere got hit. Um We've seen yet another credit bureau got hit right. Um and these attacks are coming off as fairly simple attacks that are dumping huge amounts of data, just proving that the FBI 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 can spend a little bit of time on it. But once you've taken a look at how the data flows, you end up with, you know, 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 like 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 can see everything. >>So we also saw a hack with clubhouse, which is the hot app now I think just opened up to android users, but they were simply calling it back and Agora, which is, you know, I've seen china, but once you've understood that the tokens work, once you understood what they were doing, you could essentially go in and figure things out. There seems to be like pretty like 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, like just make it less secure. Our Api is gonna be more secure in the future. What can customers do about what do you guys to think about this? >>Yeah, but the reality is, I mean that's just uh too many babies out there. I mean if you see the transition that is happening and that is the 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, a child development and and what matters is, I mean the starting point really is you cannot protect what, you cannot see what used to be. Uh an up hosted in your data center is now being hosted in the cloud environments, in the virtual environments, in several less environments and coordinators, you name it, they're out there. So the key is really to understand your attack surface, that's your starting point. So you're you're tooling your applications need to uh I need to be able to provide that visibility that that 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? Um 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 Schramm was talking about is huge. What what's going on the mind of the attacker here and the A P I S 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 endpoints. Um I've got scripts running in my attack tools that do things like show me comments uh in case the developer left some comments in there to tell me where things are. Um I basically I'm just going to poke around using it like a regular user, but in that I'm going to look for places. That makes sense to try to do an attack. So the login screen is a really easy thing. Everybody understands that you put in a user name, you put in a password, you can't go. What I'm gonna do is put in a bad username and a bad password. I'm gonna put in a good user name and a bad password and 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 back end, 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 a seat. Right. They just look like a regular user just doing regular things. It's when we decide. All right. I've found something that 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 A. P. I is when you look when you poke at them that people are are doing is that they're not really doing their homework. Doing good. Security designers are just more of tech risk. What's the most common vulnerabilities and risks? >>Well, so for me, I I've noticed a lot of the OAS KPI 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. Um but basically all it is is I log onto the platform, I'm authorized to be there, but I can see someone else's stuff and that's exactly what happened in peloton. Um 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 um that you know people need to focus on, but there's a few others that are outside the top 10 that really make a lot more sense as a defender strains probably has a little better answer to me. >>Yeah. So um I'm like like we said um creating that inventories is key, but where are they being hostess? Another another aspect of things. So so when when Jason spoke about um like 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 and other places is really eggs filtering. Exfiltrate ng that that information. Right. Is it, is it the O P II information, ph I information um and and you don't want to exfiltrate as a hacker, just one person's information. You 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 for that kind of visibility is key. Once you are bubbling up those behaviors, then you can go ahead and and and protect from these kinds of attacks. And it could be about just simply enumerating through I. D. S. Uh that paladin might have or uh experience 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 um that went down that hole enumerating through the I. D. S. Room I. D. S. And then the people just querying once they got an I. D. 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, I mean, you know, they were just rushing really fast. So So the question I have for transit and on a defense basis, people are going first party um with a P. I. S. A. P. I. First strategies because it'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 pelton problem. Is there a Is there a playbook or is their software tools that I could use? How do I build? My apologies from day one and my principles around it to be good hygiene or good design? What's the what's the >>yeah. So aPI security is sort of a looking uh less known given that it's constantly evolving and changing. And the adoption of A P. S. Have gone up significantly. So what you need to start with effectively is the runtime security aspect of things. When a an aPI is live, how do I actually protected? And it ranges from simple syntactic protection things around people. Can can go ahead and break these ap is by providing sort of uh 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 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, mps will will expose uh information, interact with the customers and partners, what what business logic are they actually exposing and how can it be abused? Understanding that is another big aspects and then you can go ahead and protect from a runtime uh from a long time security perspective, once you've done that and understood that, well then you can start shifting lap things, invest in your uh sort of uh Dass 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 uh time security tools, so I don't need to invest in dust or assessed whatever I have invested in my shift left aspect of things and uh and nothing will flow through. So you you need to start shifting left uh but covered all your bases properly, >>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 Ci cd pipeline? So that's a great point. How does how does someone and some companies and teams set that foundation with the run time? Do you think it's a critical problem right now or most people are do a good job or they just get get lazy or just lose track of it or you know what, what's what's the common um, use case? Do you see behavior behaviorally inside these enterprises? >>Yeah. So what, what we're seeing is adoption of new technologies and environments um, and they're not um, well suited for the traditional way of doing that time. Security. Like if if you have an app running in your kubernetes environment, if you have an app running in in in a serval less environment, how do you actually protected with the traditional appliance based approach? So I think being able to get that visibility into these environments, understanding the the user behavior, how these applications are interacted with being able to differentiate from that uh, normal human behavior or even sometimes legitimate automation uh from from the malicious intents or or the 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, you know, the next level of of innovation. Also you got cloud public cloud showed us a P. I. S are great. Now you're starting to see cloud operations, they call day two operations or whatever you call it A IOP. There's all kinds of buzz words are for it, but hybrid cloud and multi cloud, Edge five G. These are all basically pointing to distributed computing systems, basically distributed cloud. So that means more A P. I. Is gonna be out there. Um So in a way the surface area of a piece is increasing. What's your what's your view on this as a market? I mean, early days developing fast and what's, what's the, what's the landscape look like? What do you guys see from a attack and defense standpoint? >>Well, just from the attacker's perspective, you know, I see a lot more traffic going, what we call east west traffic, where it's traveling inside the application, it's a P is feeding a ps more data. Um, but what is really happening is we're trying to figure out how to hook third parties into our api is 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. Um, you know, it's, it's very beneficial for John Deere to be able to say I planted this seed at an inch and a half of depth and later, uh, I harvested 280 bushels of corn off that acres. 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 AP to AP means that there's far more attack surface and we're going to see it more and more. I I don't think that we're going to have less Ap is 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 A PS which was supposed to be just a dumb pipe or just, you know, rest api those glory days now it's not there. They're basically, it's basically connections. >>Yeah. You're absolutely right. John, I mean like what Jason mentioned earlier, uh, in terms of the way the A. P. I. S are going to grow and the bad guys are going to go after it. You need to think like a bad guy, what are they going to go after? Uh, these assets that are going to be in the cloud, in your hybrid environment, in in your own prem environment. And, and it's, it's a flip of a switch where an internal API can be externally exposed or, or just a new api getting rolled out. So all those things you need to be able to protect, um, and get that visibility first and then being 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 re factoring security, This is an area that's going to be explosive in development. Obviously the upside is huge. Um Quickly before to end, you guys take a minute to give a plug for the company. Um This is pretty cool. I love love what you guys do. I think it's very relevant and cool at the same time. So sequence security. What are you guys doing funding hiring? What's the plug? Tell folks about it. >>Yeah. So uh we we we started about six years ago but we like starting in the the body defense space by focusing on obscenity ice. And from then we 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 these uh articles depends on A. P. I. S. To interact with their customers. Uh We've we've raised our cities we last year we've we've grown our customer base. Uh Just in the last year when there was a lockdown people were all these retailers were transforming from brick and mortar to online. Social media also also grew and we grew with them. So >>Jason your thoughts. >>I think that sequence is his ability to scale out to any size environment. We've got a customer that does a billion and a half transactions a month. Um That are ap is from 1000 other clients of theirs. Being able to protect environments that are confusing and cloudy like that. Um 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 maybe they're right now, but they're going away and we're going to keep them away. >>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, that's playing out. You guys are solving great stuff and hey, you know when the cube studio ap I gets built, we're gonna need to call you guys up to to help us secure the cube data. >>Absolutely right. Absolutely. >>Hey, thanks for coming on the q Great uh, 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 for your host. Thanks for watching. Yeah.