 Hello, and welcome to theCUBE's presentation of the AWS Startup Showcase. This is season two, episode four of the ongoing series, covering exciting startups from the AWS ecosystem to talk about cybersecurity. I'm your host, John Furrier. And today we're excited to join by Amita Talwalkar, CEO of Sequence Security and Sabu Iyer, Vice President of Product Management of Sequence Security. Gentlemen, thanks for joining us today on this showcase. Thank you, John Browningis. You know, the title of this session is continuous API protection, lifecycle of discover, detect, and defend. Security APIs are part of it, they're hardened, everyone's using them, but 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 on 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 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 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 us have become popular. That way they're able to influence things like elections, shopping habits, personnel. We work with similar profile companies and we see this all the time. 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 bots or 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, Mia, 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 CISO, 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 things like APIs. This is not just about CISO, Chief Information Security Officer. This is Chief Security Officer issues. What's your reaction? Very much so. I think this is a security problem, but it's also an 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. They have to conform to those regulations and they have to look at that. It's not just a CISO problem anymore. In case of 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. Just to give an example, we work with a similar social media platform that allows OAuth-based login to their platform. That is using tokens. You can sign in with Facebook, sign in with Twitter, sign in with Google. These are APIs 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 login to other social media platforms. So although one social platform might be taking care of its API or what problem, if something else gets breached somewhere else, it has a cascading impact on a variety of platforms. Yeah, that's a really interesting dynamic. And if you think about just the token piece that you mentioned, that's kind of under the covers. That's a technology challenge. But also you get into the business logic. So let's go back and unpack that. Okay, they discontinued 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&A deal on the table. And so if someone wants to unwind that deal, all they got to 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 that technology, okay, they got a security breach, but here with Twitter, you have an M&A deal and acquisition that's being contested because of the APIs. So if you're in business, you got to 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 core question. Okay, you got my attention. Risk with the API. What do I do? So I'll talk to you in my previous interview. The start is basically knowing what to protect. In most cases, you see these API breaches that are hitting the wire pretty much every week now there is a major API breach. In most cases, you will 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 has escalated after the pandemic even more because now you have teams that are completely distributed. They do M&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 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 want to target in terms of runtime protection. Yeah, I want to dig into that API kind of attack surface area, management, runtime monitoring capability in a second. But Sibu, I want to 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 utilizing APIs in completely legitimate manners, but exploiting those APIs to expel trade information or key sensitive information that was probably not thought through by the developer or the designers of 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 differentiate against other vendors in this market. Just what are those key differentiated ways to identify the malicious intents with APIs? 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 ability to actually detect such traffic. We have built out a very sophisticated that 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 IP address ranges, but also which infrastructures do they operate on and stuff like that, which actually helps a lot in many environments, especially V2C environments, that alone accounts for a lot of efficacy for us in detecting or reading out bad traffic. The second aspect is in analyzing the requests that are coming in, the API traffic that is coming in. And from the requests itself, being able to tell if there is credential abuse going on, credential stuffing going on, or known patterns that the traffic is exhibiting, that looks like it is clearly trying to attack the APM. And the third one is really more sophisticated as they go farther and farther, it gets more sophisticated. The sequence actually has a lot of machine learning models built in, which actually profile the traffic that is coming in and separates out 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 that 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, one of the founders of Intel, you know, let chaos, let the chaos happen, and then reign it in. It's APIs, you know, a lot of people have been creating them and you got a lot of different stakeholders involved in creating them and now securing them and now manage them. So a lot of creation, now you're starting to secure them and now you got to manage them. This all is now a big focus, as you pointed out. What are some of the dynamics that customers who have to deal with them, the product side and organization, let chaos reign and then reign in the chaos, as the saying goes, what do companies do? Yeah, typically companies start off with like, like Amaya talked about earlier, discovery is really the key thing to start with, like figuring out what your API attack surface is and really getting your arms around that problem. And typically we are finding customers start that off from the security organization, the CISO 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 stopped the attacks, a lot of different techniques. You know, runtime, you mentioned that earlier, the surface area monitoring, what's the choices? Where are, where is everybody? Is everyone in the boiling water, like the frog in boiling water, or do they know what's happening? Like, what did they do? What's their opportunity to get into that position? Yeah, so 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 other things, that market grew with the journey to the cloud pretty much in lockstep. What has happened in the API side is the API space has kind of lagged 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 team is completely unaware of. We talked about in the past about the perimeter. The perimeter 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, they're three and four DDoS and then you go into the application and do the business logic. That perimeter is just gone because it's now could be living in multi-cloud environment. It could be living in an on-prem environment which is permanent is friendly. And so security teams that are used to protecting apps using a perimeter defense, first 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 the space which is giving you that uniform view which is first giving you that outside and looking for what APIs to protect. And then let's use or take the journey of securing the API lifecycle. So I would say that every company, now here we are on this, indulge 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 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. So the goodness is there because of APIs. Now you got to reign it in, reign in the chaos. 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 perimeter doesn't exist. People have APIs deployed in multiple environments, multi-cloud, 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 are the only clear in this phase that can protect your APIs purely as a SaaS solution or purely as a non-prem deployment. And that prem could be a SaaS platform. It doesn't need to be a rack and stack, but we also support that. And it could be a hybrid deployment. We have some deployments which are on your prem and the rest of the solution is in our SaaS. If you think about it, customers have secured their APIs for sequence with 15 minutes going live from zero to live and getting that protection instantaneously. We have customers that are processing a billion API calls per day across a 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 you need to sequence that we offer that nobody else is offering today. Okay, so 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 Sooboo's answer. Of course everyone will say that, that's great. That's my argument. There are two types of API attacks. One is a syntactic problem, which is exploiting a vulnerability in an API. So what you're saying is my APIs are secure. It does not have any vulnerability. I've taken care of all such vulnerabilities. The second type of attack that targets APIs is the business logic abuse. There's 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, retweeting, liking or commenting that the bots are targeting, which they have no defense against, right? And then none of the other social networks do. So there are many examples. Uber wrote a program to impersonate users in different geolocations to find lifts, pricing and driver information and passenger information. Completely legitimate use of APIs for illegitimate purpose using bots. So you don't need bots, by the way. Don't make this about bot versus not. You can use APIs sort of for the purpose that they're not designed for sort of exploiting their business logic, either using a human interacting or human farm interacting with those APIs or a bot farm targeting those APIs. I think that's the problem when you have, even when you've secured all your APIs, you still have to worry about these sort of challenges. I think that's a 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 backlash of having a simplistic API, which people designed to, right? You know, as you pointed 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 is dead too, right? So how do you stop that business logic? What's the solution? What's the customer do about that? Because their goal is to create simple, scalable APIs. Yeah, I'll give you a little bit and then I think Subu, you should really go into a little bit of the depth of the problem. But what I think the answer lies in what Subu spoke earlier, which is RML AI is good at profiling first split between the API users are these legitimate users, humans versus bots. That's the first split we do. The second split we do is, even when these classified users as bots, you 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 world, there are aggregators that are spending your data and aggregating for end users to consume, right? Your men, your godly and other type of financial aggregators, FinTech companies like MX. These are good bots and you want to allow them to use your APIs. Whereas you want to stop the bad bots from using your APIs. Subu, if you want to add some good bots versus bad bots, that's the focus. Subu, go ahead, weigh in. Go weigh in on your thoughts on this. Really, it really breaks down into three key areas that we talk about here, it's a sequence, right? One is you start by discovering all your APIs. How many APIs do I have in my environment that sequence will immediately hide out 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 eye-opener for them to at least know where they are 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 IP addresses, so-and-so infrastructure, so-and-so countries, and so on. Not usually is another eye-opener for them. They then get to see where their API traffic is coming from. Let's say if you're running a pizza delivery service out of California and your traffic is coming from Eastern Europe, you go, wait a minute, nobody's trying. 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 APIs. It is hitting your API that has, that is vulnerable to a broken object level that authorization vulnerability and so on. And then comes the defend aspect. The defend aspect is where you can take action and say, I want to block certain types of traffic or I want to rate limit certain types of traffic. If you're seeing spikes there or you could maybe insert a header so that it passes on to the end application and the application team can use that bit to essentially take a conscious response and so on. 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 were built for the goodness of cloud. They're now the plumbing. Anytime you see plumbing involved connection points, it's pretty important, people are building it out and it has made the cloud what it is. Now you got a security challenge. You got to add more intelligence, more smarts do it. This is where I think platform versus tools matter. Can you guys just quickly share your thoughts on that? Because a lot of your customers and future customers have dealt with the sprawls of all these different tools. 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 around how you guys are engaging with customers. Can you share your thoughts on tooling platforms? Your customers are constantly and inundated with the same tsunami of, here's a new thing. Why watch, how should they look at this? Yeah, I mean, we don't want to be, we don't want to 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 SIEM systems or SOAR systems and allow customers to integrate the information that we are detecting or mitigating and feed them on to enterprise systems like a Splunk or a data log where they may have sophisticated processes built in to monitor 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 out of the box. Okay, Amiya, 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 super cloud or now multi cloud or hybrid world of cloud. Share 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 sequence security. Yeah, we've been on this journey, an exciting journey it's been for about eight years. We have very large virtual 100 global 500 customers that use our platform on a daily basis. We have some amazing logos both in Europe and in US. Customers, this is basically not a shelf where product customers not only use it but depend on sequence. Several retailers, we are sitting in front of them handling Black Friday, Cyber Monday, Christmas shopping or any sort of holiday seasonality shopping and we've handled that. The journey starts by just simply looking at your API attack surface, just do a discover call with sequence, figure out where your APIs are hosted, 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 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 what's next in the next 12 to 18 months. It certainly is one of the top two or three items on the CISO's budget list for next year. So we are extremely busy but we are looking for for what the next 12 to 18 months are in store for us. Well, congratulations to all the success. Cebu, you run the roadmap. APIs are the plumbing, if you will. They're connection points. You want to kind of keep them simple as they say, keep the pipes dumb and make the intelligence around it. You see more and more intelligence coming around not just securing it, but where does this go in your mind? Where do we go beyond once we secure everything and manage it properly? APRs aren't going away. They're only going to 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 API space. As digital transformation happens to most enterprise systems, many applications are getting transformed. You're 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 out of deployments are now splintered across multiple different cloud environments out of 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, the nature of APIs. And we're 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, 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 the CSOs. Amiya Subbu, thank you so much for joining me today. I really appreciate it. Thank you. Okay, that is the end of this segment of the AWS startup showcase season two, episode four. I'm John Furrier, your host and we're here with sequence security. Thanks for watching.