>>Hello, Ron. Welcome to AWS reinforce here. Live in Boston, Massachusetts. I'm John feer, host of the cube. We're here at Carl Matson. CSO at no name security. That's right, no name security, no name securities, also a featured partner at season two, episode four of our upcoming eightish startup showcase security themed event happening in the end of August. Look for that at this URL, AWS startups.com, but we're here at reinforc Carl. Thanks for joining me today. Good to see >>You. Thank you for having us, John. >>So this show security, it's not as packed as the eight of us summit was in New York. That just happened two weeks ago, 19,000 people here, more focused crowd. Lot at stake operations are under pressure. The security teams are under a lot of pressure as apps drive more and more cloud native goodness. As we say, the gen outta the bottle, people want more cloud native apps. Absolutely. That's put a lot of pressure on the ops teams and the security teams. That's the core theme here. How do you see it happening? How do you see this unfolding? Do you agree with that? And how would you describe today's event? >>Well, I think you're, you're spot on. I think the, the future of it is increasingly becoming the story of developers and APIs becoming the hero, the hero of digital transformation, the hero of public cloud adoption. And so this is really becoming much more of a developer-centric discussion about where we're moving our applications and, and where they're hosted, but also how they're designed. And so there's a lot of energy around that right now around focusing security capabilities that really appeal to the sensibilities and the needs of, of modern applications. >>I want to get to know name security a second, and let you explain what you guys do. Then I'll have a few good questions for you to kind of unpack that. But the thing about the structural change that's happened with cloud computing is kind of, and kind of in the past now, DevOps cloud scale, large scale data, the rise of the super cloud companies like snowflake capital, one there's examples of companies that don't even have CapEx investments building on the cloud. And in a way, our, the success of DevOps has created another sea of problems and opportunities that is more complexity as the benefits of DevOps and open source, continue to rise, agile applications that have value can be quantified. There's no doubt with the pandemic that's value there. Yeah. Now you have the collateral damage of success, a new opportunity to abstract away, more complexity to go to the next level. Yep. This is a big industry thing. What are the key opportunities and areas as this new environment, cuz that's the structural change happening now? Yep. What's the key dynamics right now. That's driving this new innovation and what are some of those problem areas that are gonna be abstracted away that you see? >>Well, the, the first thing I I'd suggest is is to, to lean into those structural changes and take advantage of them where they become an advantage for governance, security risk. A perfect example is automation. So what we have in microservices, applications and cloud infrastructures and new workloads like snowflake is we have workloads that want to talk, they want to be interoperated with. And because of that, we can develop new capabilities that take advantage of those of those capabilities. And, and so we want to have on our, on our security teams in particular is we wanna have the talent and the tools that are leaning into and capitalizing on exactly those strengths of, of the underlying capabilities that you're securing rather than to counter that trend, that the, the security professional needs to get ahead of it and, and be a part of that discussion with the developers and the infrastructure teams. >>And, and again, the tructure exchange could kill you too as well. I mean, some benefits, you know, data's the new oil, but end of the day it could be a problematic thing. Sure. All right. So let's get that. No names talk about the company. What you guys do, you have an interesting approach, heavily funded, good success, good buzz. What's going on with the company? Give the quick overview. >>Well, we're a company that's just under three years old and, and what APIs go back, of course, a, a decade or more. We've all been using APIs for a long time, but what's really shifted over the last couple of years is the, is the transition of, of applications and especially business critical processes to now writing on top of public facing APIs where API used to be the behind the scenes interconnection between systems. Now those APIs are exposed to their public facing. And so what we focus on as a company is looking at that API as a, as a software endpoint, just like any other endpoint in our environments that we're historically used to. That's an endpoint that needs full life cycle protection. It needs to be designed well secure coding standards for, for APIs and tested. Well, it also has to be deployed into production configured well and operated well. And when there's a misuse or an attack in progress, we have to be able to protect and identify the, the risks to that API in production. So when you add that up, we're looking at a full life cycle view of the API, and it's really it's about time because the API is not new yet. We're just starting to now to apply like actual discipline and, and practices that help keep that API secure. >>Yeah. It's interesting. It's like what I was saying earlier. They're not going anywhere. They're not going, they're the underpinning, the underlying benefit of cloud yes. Cloud native. So it's just more, more operational stability, scale growth. What are some of the challenges that, that are there and what do you guys do particularly to solve it? You're protecting it. Are you scaling it? What specifically are you guys addressing? >>But sure. So I think API security, even as a, as a discipline is not new, but I think the, the, the traditional look at API security looks only at, at the quality of the source code. Certainly quality of the source code of API is, is sort of step one. But what we see in, in practices is most of the publicly known API compromises, they weren't because of bad source code that they because of network misconfiguration or the misapplication of policy during runtime. So a great example of that would be developer designs, an API designs. It in such a way that Gar that, that enforces authentication to be well designed and strong. And then in production, those authentication policies are not applied at a gateway. So what we add to the, we add to the, to the conversation on API security is helping fill all those little gaps from design and testing through production. So we can see all of the moving parts in the, the context of the API to see how it can be exploited and, and how we can reduce risk in independent of. >>So this is really about hardening the infrastructure yep. Around cuz the developer did their job in that example. Yep. So academic API is well formed working, but something didn't happen on the network or gateway box or app, you know, some sort of network configuration or middleware configuration. >>Absolutely. So in our, in our platform, we, we essentially have sort of three functional areas. There's API code testing, and then we call next is posture management posture. Management's a real thing. If we're talking about a laptop we're talking about, is it up to date with patches? Is it configured? Well, is it secure network connectivity? The same is true with APIs. They have to be managed and cared for by somebody who's looking at their posture on the network. And then of course then there's threat defense and run time protection. So that posture management piece, that's really a new entrant into the discussion on API security. And that's really where we started as a company is focusing on that sort of acute gap of information, >>Posture, protection, >>Posture, and protection. Absolutely >>Define that. What does that, what does posture posture protection mean? How would you define that? >>Sure. I think it's a, it's identifying the inherent risk exposure of an API. Great example of that would be an API that is addressable by internal systems and external systems at the same time. Almost always. That is, that is an error. It's a mistake that's been made so well by, by identifying that misconfiguration of posture, then we can, we can protect that API by restricting the internet connectivity externally. That's just a great example of posture. We see almost every organization has that and it's never intended. >>Great, great, great call out. Thanks for sharing. All right, so I'm a customer. Yep. Okay. Look at, Hey, I already got an app firewall API gateway. Why do I need another tool? >>Well, first of all, web application firewalls are sort of essential parts of a security ecosystem. An API management gateway is usually the brain of an API economy. What we do is we, we augment those platforms with what they don't do well and also when they're not used. So for example, in, in any environment, we, we aspire to have all of our applications or APIs protected by web application firewall. First question is, are they even behind the web? Are they behind the w at all? We're gonna find that the WAFF doesn't know if it's not protecting something. And then secondary, there are attack types of business logic in particular of like authentication policy that a WAFF is not gonna be able to see. So the WAFF and the API management plan, those are the key control points and we can help make those better. >>You know what I think is cool, Carl, as you're bringing up a point that we're seeing here and we've seen before, but now it's kind of coming at the visibility. And it was mentioned in the keynote by one of the presenters, Kurt, I think it was who runs the platform. This idea of reasoning is coming into security. So the idea of knowing the topology know that there's dynamic stuff going on. I mean, topes aren't static anymore. Yep. And now you have more microservices. Yep. More APIs being turned on and off this runtime is interesting. So you starting to see this holistic view of, Hey, the secret sauce is you gotta be smarter. Yep. And that's either machine learning or AI. So, so how does that relate to what you guys do? Does it, cuz it sounds like you've got something of that going on with the product. Is that fair or yeah. >>Yeah, absolutely. So we, yeah, we talked about posture, so that's, that's really the inherent quality or secure posture of a, of an API. And now let's talk about sending traffic through that API, the request and response. When we're talking about organizations that have more APIs than they have people, employees, or, or tens of thousands, we're seeing in some customers, the only way to identify anomalous traffic is through machine learning. So we apply a machine learning model to each and every API in independently for itself because we wanna learn how that API is supposed to be behave. Where is it supposed to be talking? What kind of data is it supposed to be trafficking in, in, in all its facets. So we can model that activity and then identify the anomaly where there's a misuse, there's an attacker event. There's an, an insider employee is doing something with that API that's different. And that's really key with APIs is, is that no, a no two APIs are alike. Yeah. They really do have to be modeled individually rather than I can't share my, my threat signatures for my API, with your organization, cuz your APIs are different. And so we have to have that machine learning approach in order to really identify that >>Anomaly and watch the credentials, permissions. Absolutely all those things. All right. Take me through the life cycle of an API. There's pre-production postproduction what do I need to know about those two, those two areas with respect to what you guys do? >>Sure. So the pre-production activities are really putting in the hands of a developer or an APSEC team. The ability to test that API during its development and, and source code testing is one piece, but also in pre-production are we modeling production variables enough to know what's gonna happen when I move it into production? So it's one thing to have secure source code, of course, but then it's also, do we know how that API's gonna interact with the world once it's sort of set free? So the testing capabilities early life cycle is really how we de-risk in the long term, but we all have API ecosystems that are existing. And so in production we're applying the, all of those same testing of posture and configuration issues in runtime, but really what it, it may sound cliche to say, we wanna shift security left, but in APIs that's, that's a hundred percent true. We want to keep moving our, our issue detection to the earliest possible point in the development of an API. And that gives us the greatest return in the API, which is what we're all looking for is to capitalize on it as an agent of transformation. >>All right, let's take the customer perspective. I'm the customer, Carl, Carl, why do I need you? And how are you different from the competition? And if I like it, how do I get started? >>Sure. So the, the, the first thing that we differentiate selves from the customer is, or from our competitors is really looking at the API as an entire life cycle of activities. So whether it's from the documentation and the design and the secure source code testing that we can provide, you know, pre-development, or pre-deployment through production posture, through runtime, the differentiator really for us is being a one-stop shop for an entire API security program. And that's very important. And as that one stop shop, the, the great thing about that when having a conversation with a customer is not every customer's at the same point in their journey. And so if, if a customer discussion really focuses on their perhaps lack of confidence in their code testing, maybe somebody else has a lack of confidence in their runtime detection. We can say yes to those conversations, deliver value, and then consider other things that we can do with that customer along a whole continuum of life cycle. And so it allows us to have a customer conversation where we don't need to say, no, we don't do that. If it's an API, the answer is, yes, we do do that. And that's really where we, you know, we have an advantage, I think, in, in looking at this space and, and, and being able to talk with pretty much any customer in any vertical and having a, having a solution that, that gives them something value right away. >>And how do I get started? I like it. You sold me on, on operationalizing it. I like the one stop shop. I, my APIs are super important. I know that could be potential exposure, maybe access, and then lateral movement to a workload, all kinds of stuff could happen. Sure. How do I get started? What do I do to solve >>This? Well, no name, security.com. Of course we, we have, you know, most customers do sandboxing POVs as part of a trial period for us, especially with, you know, being here at AWS is wonderful because these are customers who's with whom we can integrate with. In a matter of minutes, we're talking about literally updating an IAM role. Permission is the complexity of implementation because cloud friendly workloads really allow us to, to do proofs of concept and value in a matter of minutes to, to achieve that value. So whether it's a, a dedicated sandbox for one customer, whether it's a full blown POC for a complicated organization, you know, whether it's here at AWS conference or, or, or Nona security.com, we would love to do a, do a, like a free demo test drive and assessment. >>Awesome. And now you guys are part of the elite alumni of our startup showcase yep. Where we feature the hot startups, obviously it's the security focuses episodes about security. You guys have been recognized by the industry and AWS as, you know, making it, making it happen. What specifically is your relationship with AWS? Are you guys doing stuff together? Cuz they're, they're clearly integrating with their partners. Yeah. I mean, they're going to companies and saying, Hey, you know what, the more we're integrated, the better security everyone gets, what are you doing with Amazon? Can you share any tidbits? You don't have to share any confidential information, but can you give us a little taste of the relationship? >>Well, so I think we have the best case scenario with our relationship with AWSs is, is as a, as a very, very small company. Most of our first customers were AWS customers. And so to develop the, the, the initial integrations with AWS, what we were able to do is have our customers, oftentimes, which are large public corporations, go to AWS and say, we need, we need that company to be through your marketplace. We need you to be a partner. And so that partnership with, with AWS has really grown from, you know, gone from zero to 60 to, you know, miles per hour in a very short period of time. And now being part of the startup program, we have a variety of ways that a customer can, can work with us from a direct purchase through the APS marketplace, through channel partners and, and VA, we really have that footprint now in AWS because our customers are there and, and they brought our customers to AWS with us. >>It's it nice. The customers pulls you to AWS. Yes. Its pulls you more customers. Yep. You get kind of intermingled there, provide the value. And certainly they got, they, they hyperscale so >>Well, that creates depth of the relationship. So for example, as AWS itself is evolving and changing new services become available. We are a part of that inner circle. So to speak, to know that we can make sure that our technology is sort of calibrated in advance of that service offering, going out to the rest of the world. And so it's a really great vantage point to be in as a startup. >>Well, Carl, the CISO for no name security, you're here on the ground. You partner with AWS. What do you think of the show this year? What's the theme. What's the top story one or two stories that you think of the most important stories that people should know about happening here in the security world? >>Well, I don't think it's any surprise that almost every booth in the, in the exhibit hall has the words cloud native associated with it. But I also think that's, that's, that's the best thing about it, which is we're seeing companies and, and I think no name is, is a part of that trend who have designed capabilities and technologies to take advantage and lean into what the cloud has to offer rather than compensating. For example, five years ago, when we were all maybe wondering, will the cloud ever be as secure as my own data center, those days are over. And we now have companies that have built highly sophisticated capabilities here in the exhibit hall that are remarkably better improvements in, in securing the cloud applications in, in our environments. So it's a, it's a real win for the cloud. It's something of a victory lap. If, if you hadn't already been there, you should be there at this point. >>Yeah. And the structural change is happening now that's clear and I'd love to get your reaction if you agree with it, is that the ops on security teams are now being pulled up to the level that the developers are succeeding at, meaning that they have to be in the boat together. Yes. >>Oh, lines of, of reporting responsibility are becoming less and less meaningful and that's a good thing. So we're having just in many conversations with developers or API management center of excellence teams to cloud infrastructure teams as we are security teams. And that's a good thing because we're finally starting to have some degree of conversions around where our interests lie in securing cloud assets. >>So developers ops security all in the boat together, sync absolutely together or win together. >>We, we, we win together, but we don't win on day one. We have to practice like we as organizations we have to, we have to rethink our, we have to rethink our tech stack. Yeah. But we also have to, you have to rethink our organizational models, our processes to get there, to get >>That in, keep the straining boat in low waters. Carl, thanks for coming on. No name security. Why the name just curious, no name. I love that name. Cause the restaurant here in Boston that used to be of all the people that know that. No name security, why no name? >>Well, it was sort of accidental at, in the, in the company's first few weeks, the there's an advisory board of CISOs who provides feedback on, on seed to seed companies on their, on their concept of, of where they're gonna build platforms. And, and so in absence of a name, the founders and the original investor filled out a form, putting no name as the name of this company that was about to develop an API security solution. Well, amongst this board of CSOs, basically there was unanimous feedback that the, what they needed to do was keep the name. If nothing else, keep the name, no name, it's a brilliant name. And that was very much accidental, really just a circumstance of not having picked one, but you know, a few weeks passed and all of a sudden they were locked in because sort of by popular vote, no name was, >>Was formed. Yeah. And now the legacy, the origination story is now known here on the cube call. Thanks for coming on. Really appreciate it. Thank you, John. Okay. We're here. Live on the floor show floor of AWS reinforced in Boston, Massachusetts. I'm John with Dave ALO. Who's out and about getting the stories in the trenches in the analyst meeting. He'll be right back with me shortly day tuned for more cube coverage. After this short break.