 Hello everyone, welcome to AWS Reinforce here live in Boston, Massachusetts. I'm John Furrier, host of theCUBE. We're here at Carl Madsen. See so at no name security. That's right, no name security, no name security. It's also a featured partner at season two, episode four of our upcoming AWS startup showcase, security themed event happening in the end of August. Look for that at this URL, awsstartups.com. We're here at Reinforce. Carl, thanks for joining me today. Good to see you. Thank you for having us, John. So this shows security, it's not as packed as the AWS 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 genies out of 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 spot on. I think 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 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 modern applications. I want to get to no names, create a second one, 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 in the past now. DevOps, cloud scale, large scale data, the rise of the super clouds, 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, the success of DevOps has created another sea of problems and opportunities. That is more complexity. As benefits of DevOps and open source continue to rise, agile applications that have value can be quantified. There's no doubt with a pandemic, there's value there. Now you have the collateral damage of success. A new opportunity abstract way more complexity to go to the next level. This is a big industry thing. What are the key opportunities and areas as this new environment? Because that's the structural change happening now. What's the key dynamics right now that's driving this new innovation? And what are some of those problem areas that are going to be abstracted in a way that you see? Well, the first thing I suggest is 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 capabilities. And so we want to have on our security teams in particular is we want to have the talent and the tools that are leaning into and capitalizing on exactly those strengths of the underlying capabilities that you're securing rather than to counter that trend that the security professional needs to get ahead of it and be a part of that discussion with the developers and the infrastructure teams. And again, the structural change could kill you too as well. Some benefits, you know, data is the new oil, but in the day it could be a problematic thing. Sure. All right, so let's get to the no-name. 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 it a quick overview. Well, we're a company that's just under three years old and what APIs go back, of course, a decade or more. We've all been using APIs for a long time. But what has really shifted over the last couple of years is the transition 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 software endpoint just like any other endpoint in our environments that we're historically used to. That's an endpoint that needs full lifecycle protection. It needs to be designed well, secure coding standards 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 risks to that API in production. So when you add that up, we're looking at a full lifecycle 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 practices that help keep that API secure. Yeah, it's interesting. It's not like what I was saying earlier. They're not going anywhere. They're not going anywhere. They're the underpinning, the underlying benefit of cloud, cloud native. So it's just more operational stability, scale, growth. What are some of the challenges 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? What are you doing? Sure, so I think API security, even as a discipline is not new, but I think the traditional look at API security looks only at the quality of the source code. Certainly quality of the source code of API is sort of step one. But what we see in practice is most of the publicly known API compromises, they weren't because of bad source code. They were because of network misconfiguration or the misapplication of policy during runtime. So a great example of that would be a developer designs an API, designs it in such a way 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 conversation on API security is helping fill all those little gaps from design and testing through production so that you can see all of the moving parts in the context of the API to see how it can be exploited and how we can reduce risk independent of an individual. So this is really about hardening the infrastructure around, because the developer did their job in that example. So I could do an API as well formed, working, but something didn't happen on the network or gateway box or some sort of network configuration or middleware configuration. Absolutely, so in our platform, we essentially have sort of three functional areas. There's API code testing and then we call it next is posture management. Posture management is 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 runtime 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, posture protection? Posture and protection, absolutely. Define that. What does posture protection mean? How would you define that? Sure, I think 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 an error. It's a mistake that's been made. So by identifying that misconfiguration of posture, then 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 call out, thanks for sharing. All right, so I'm a customer. 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 augment those platforms with what they don't do well and also when they're not used. So for example, in any environment, we aspire to have all of our applications or APIs protected by a web application firewall. First question is, are they even behind the web? Are they behind the WAF at all? We're going to find that. The WAF 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 WAF is not going to be able to see. So the WAF and the API management plane, those are the key control points and we can help make those better. You know what I think is cool, Carl, is 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 topologies aren't static anymore. And now you have more microservices, more APIs being turned on and off. This runtime is interesting. So you start to see this holistic view of, hey, the secret sauce is you've got to be smarter. And that's either machine learning or AI. So how does that relate to what you guys do? Is it because it sounds like you've got something of that going on with the product? Is that fair? Yeah, absolutely. So yeah, we talked about posture. So that's really the inherent quality or secure posture 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 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 independently for itself. Because we want to learn how that API is supposed to behave, where is it supposed to be talking, what kind of data is it supposed to be trafficking in, in all of 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 insider employee is doing something with that API that's different. And that's really key with APIs is that no two APIs are alike. They really do have to be modeled individually rather than I can't share my threat signatures for my API with your organization because 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, all those things. All right, take me through the life cycle of an API this pre-production, post-production. What do I need to know about 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 app sec team, the ability to test that API during its development. And source code testing is one piece, but also in pre-production, are we modeling production variables enough to know what's going to 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 is going to interact with the world once it's 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 all of those same testing of posture and configuration issues in runtime. But really, it may sound cliche to say we want to shift security left, but an API is that's 100% true. We want to keep moving 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. 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 first thing that we differentiate ourselves from the customer or from our competitors is really looking at the API as an entire lifecycle 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 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 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 lifecycle. 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 have an advantage, I think, in looking at this space and being able to talk with pretty much any customer in any vertical and having a solution that gives them something value right away. And how do I get started? I like it, you sold me on operationalizing it. I like the one-stop shop. 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, knownamesecurity.com, of course 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 do proofs of concept and value in a matter of minutes to achieve that value. So whether it's a dedicated sandbox for one customer, whether it's a full-blown POC for a complicated organization, you know, whether it's here at the AWS conference or knownamesecurity.com, we would love to do like a free demo test drive and assessment. Awesome. And now you guys are part of the elite alumni of our AWS startup showcase where we feature the hot startups. Obviously it's a security focus, this episode's about security. You guys have been recognized by the industry and AWS as, you know, making it happen. What specifically is your relationship with AWS so you guys doing stuff together? Cause they're clearly integrating with their partners. 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 AWS is as a very, very small company, most of our first customers were AWS customers. And so to develop 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 that company to be through your marketplace. We need you to be a partner. And so the partnership with AWS has really grown from, you've gone from zero to 60 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 work with us from a direct purchase through the APA's marketplace, through channel partners and VARs. We really have that footprint now in AWS because our customers are there and they brought our customers to AWS with us. It's a nice thing. The customer pulls you to AWS. AWS pulls you more customers. You get kind of intermingled there, provide the value. And certainly they have the hyper-scale. Well, that creates depth of the relationship. So for example, as AWS itself is evolving and changing, new services become available. We're 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. So it's a really great vantage point to be in as a startup. Well, Carl, as a CISO for No Name Security, you're here on the ground, I'll see 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 are 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 exhibit hall has the words cloud native associated with it. But I also think that's the best thing about it, which is we're seeing companies, and I think No Name 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 securing the cloud applications in our environment. So it's a real win for the cloud. It's something of a victory lap. 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 and 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 reporting responsibility are becoming less and less meaningful, and that's a good thing. So we're having just as 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 convergence around where our interests lie in securing cloud assets. So developers ops, security all in the boat together. Absolutely. Together or win together? We win together, but we don't win on day one. We have to practice, as organizations, we have to rethink our tech stack, but we also have to rethink our organizational models, our processes, to get there to get that win. Keep the straining boat in the low waters. Carl, thanks for coming on, No Name Security. Why the name? Just curious, No Name. I love that name, because there's a restaurant here in Boston that used to be a role of people that know that. No Name Security, why No Name? Well, it was sort of accidental. In the company's first few weeks, there's an advisory board of CISOs who provides feedback to seed companies on their concept of where they're going to build platforms. 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 CISOs, basically there was unanimous feedback that 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 a few weeks passed and all of a sudden they were locked in because sort of by popular vote, No Name was formed. And now the legacy and the origination story is now known here on theCUBE. Carl, thanks for coming on. Really appreciate it. Thank you, John. Okay, we're here live on the show floor of AWS Reinforced in Boston, Massachusetts. I'm John Furrier with Dave O'Lothay who's out and about getting the stories in the trenches of the analyst meeting. He'll be right back with me shortly. Stay tuned for more CUBE coverage after this short break.