 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 me at Tall Walker, CEO of Sequence Security, protecting APIs is the name of the game. Thanks for coming on this CUBE Conversation. Thank you, John. Thanks for having us. So, I mean, obviously API's cloud 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, Sequence, 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 Sequence that were sort of API first, if you will. There were products in the market that were, 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 a 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 this problem. So it has, it's been an 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 way plus open source is 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 API first has got us here and that's the standard. 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 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. So what has happened in the last few years is as you mentioned in 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 perimeter anymore to your applications or APIs. And so the perimeter where people typically use to have maybe a CDN or WAF or other security controls at the perimeter 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 wherever they are they are hosting their APIs and that has become your micro perimeter 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 or an Android phones became popular there used to be a sort of ad campaign. I remember that said there is an app for that. 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 you can call an API and get your business done. And that's the challenge that's the explosion in APIs. It's interesting you have the API life cycle concept developing now you got Apple knows the application life cycle, you know, CI CD pipeline shifting left but the surface area you got web app firewalls which everyone knows is kind of like outdated but you got API gateways. The surface area is only increasing. So I have to ask you do the existing API security tools out there bring that full application and API life cycle together because you got to discover the environment you got to know what to protect and then also net new functionality. Can you comment? Yeah, so that actually goes to your how question from, you know, previous section which is really what sequence has defined is the 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 the KCS7 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 a 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 are 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 deviate at 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. The fourth step is attack detection. And here again, we don't stop just at the OVAS top 10 category of threats. So a lot of other vendors too, they just do the OVAS 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 to think about prevention of these attacks also natively with sequence. And the last step is about testing and making sure your APIs are secure even before they go live. So that's the journey, yeah. What's the secret sauce? What makes you different? Cause you've got two sizes to that coin. You get the auditing, kind of figure things out, and then you got the inbound attacks. What makes you guys different? So the way we are different is first of all, sequence 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 perimeter, 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. Number two is the outside looking in view, which is the external discovery. It's something sequence is unique in this space, uniquely doing this in this space. The third piece is the depth of our detection, which is, 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 we 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? So we are unique in the sense we can prevent the attacks that we detect and the same platform without reliance on any other third party solution. Yeah, yeah, maybe. The last one that is, sorry, just one last. This is a 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 sequence. So scale of APIs that we can process and how we can scale is also unique to sequence. Yeah, I think the scale thing's a huge message there. Just put a little accent on that. I got a comment because we had an event last week called SuperCloud, which we're trying to talk about. You know, as clouds become more community cloud, you get more super capabilities. But automation with SuperCloud comes super hackers. So as things advance, you're seeing the step function. The bad guys are getting better, so 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 attacks easier because APIs are well documented. So you want your partners and 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 you a few examples. Altar 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 hions, which are very high in demand, very expensive, very hard to find. And so this links sort of physical theft 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 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 are saving them from physical theft and all the other problems that they have, but also they were paying about $25,000 per month extra 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. This can go on. You know, that's a really great example. I'm glad you brought that up because I observed at AWS Reinforced 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 internet online. So to your point about the surveillance and attack setup for the physical, you got warehouses, you 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 biggest 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 are 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 are compliant with that regulation that they have to sort of comply with. I can only imagine that that geo regional view and the intelligence and the scale gives you insights into attacks that aren't really kind of supposed to be there. In other words, if you can keep the data in the geo, then you could look at anything else that 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. So the API visibility is an issue, right? So I can see that check, sold me on that. Protection is key, but 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? Because they're under a lot of pressure to do the hardcore security work. And APIs, again, surface area is 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 fire, 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 the 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 the same APIs were targeted 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 sequence 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, tool chains and CI CD pipelines. But otherwise it's all about security challenges, acute pain points and then expanding into the whole journey. Actually you got the detection, you got the alerting, you got the protection, you got the mitigation. What's the advice to the customer or the right approach to set up with sequence so that they can have the best protection? What's the motion? What's the initial engagement look like? How do they engage? How do they operate and analyze you guys? Take me through that. Yeah, the simple way of engaging with sequences is get that external assessment which will map your APIs for you. We create an assessment for you. We'll present that assessment to your security team. I'm like 90% of the times customers have an hour moment that they didn't know something that we are showing them. They find APIs that were not supposed to be public. They will find posting environments that they didn't know about. They will find API gateways that were not commissioned but being used. And so start their journey with an assessment with sequence 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 APIs is the key. It's basically, I mean, you start to see more of this in the cloud native, you know, SBOT, they call them, you know. Baseball materials, 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 exist, right? So that's the challenge. Okay, 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 as that stake here relative to the security is 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 and you got zero trust and you got trust kind of coming together. What's, 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 Alta 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 trust anybody until you verify. That's the sort of angle, that's sort of the connection between API security and zero trust. I mean, thank you for coming on theCUBE. Really appreciate the conversations. I'll give you the final word. What should people know about a sequence security? How would you give the pitch? You got, you know, quick summary. What's going on? Yeah, so very excited to be in this space. We sort of are the largest security or API security vendor in this space in terms of grabbing you the largest volume of API traffic that we process. And we're 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 is a new competitive advantage. I think that's the new lock in if you're good and you're scaling probably a lot of benefits. So I mean, thank you for coming and sharing the story. Looking forward to chatting again soon. Thank you very much. Thanks for having us. Okay, this is theCUBE conversation. I'm John Furrier here at Palo Alto, California. Thanks for watching.