(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)