 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 sequence security. I'm your host, Dave Vellante and today we're joined by Subu Ayer who is the Vice President of Products at Sequence 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 Subu, great to have you in theCUBE. Thanks Dave, I'm happy to be here. Look, every week there's some other report and the paper and the news, high profile security breaches. I'll know about the Experian breach, the clubhouse is 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 Subu, 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 practically like leaving your front door open and allowing anybody to walk in. I mean, there are APIs that are unauthenticated, 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 OASP API top 10 is actually a pretty good handy list for people to look up and we see many of those as being very commonly seen on vulnerabilities in APIs. Yeah, I mean, the adversaries, they're experts at automation. They knock on that door. If it's open, they come right in. And they don't even have to manually do it. They're just automatic. But so talk a little bit more about 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 via 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 or 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 are unauthenticated? How many of those APIs are using very weak forms of authentication or are exposing sensitive information or subject to some of the other commonly seen risks? You know, authentication is the other area. Not just humans, about machines as well. So this is a critical weak link. And it's fraught with complexity. You got multiple devices, you 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 door mat hoping that nobody is gonna pull up the door mat and find the key in there. It's pretty much the equivalent of that for APIs that we see. That's really the gamut 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 and walk in. You know, I recently wrote about this and 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. And 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 and other example it was a healthcare data, private information. They'd hold it on reserve, so to speak so they can 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 OS API top 10 it's something that we see pretty often with APIs. And you're right, adversaries basically look for avenues where they can exploit the sensitive data flaws that an API may have. And common ways of doing that are maybe the attacker discovers the 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 are actually able to get other users information that's basically 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 long. So one of the key things that we do in sequence is provide visibility to our customers about 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 the 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, talk a little bit more about that. I mean, can you share a little bit about your secret sauce, if you will your kind of unique approach to solving this problem? Yeah, that's a good question. So sequence 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 two 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 is communicating over 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. Yeah, yeah. 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 app 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 are 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 sequence 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 discover some APIs and the key under the doormat, so to speak, what do I then do as a customer? And 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 runtime to actually stop some of this bad 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 the 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 did, 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 sequence 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 take and prevent a traffic from hitting these APIs. And I would imagine, Subu, 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 configuration. And so, but I wonder, are you seeing, we have sort of was my first question, what kind of patterns are you seeing? But are you seeing 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. I have seen environments where the production environment was actually had a weaker security posture than a development environment. 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 CICD processes, how soon are they able to get these applications into production and so on. And accordingly, they put in actions in that, let's say in the appropriate environment, the dev environment or the product 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 at presumably, they want to keep working with you because their environment's 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 sequence in, right? Are you able to align with the development lifecycle more closely? Yeah, yeah, that's an ideology that we do here at sequence. 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 expel great information. So you need to protect your applications from bad traffic. So while shielding 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 lifecycle. So yep, we absolutely see that as an evolution for customers. Thank you for that. So I got two more questions for you. And the first one is kind of a fun question that the CUBE team 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, increasing revenue, great. But there's more even. And so what we're asking folks like yourself, Subu, is what is your defining contribution to the future of cloud scale? Yeah, so cloud scale is not possible without a digital transformation of applications. So and 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 via APIs and allow other applications to communicate via 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 onto 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 could 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. Yeah, so to kind of bring it all together, right? API security is top of mind for many CISOs 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 write strategies where you essentially are blocking the back traffic from hitting your applications. That's basically the logical evolution from discovering the bad traffic in your environment. First visibility and then protect what is going on. And then start 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, Subit, 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.