 Hello everyone, welcome to theCUBE's presentation of the AWS Startup Showcase. This is our season two, episode four of the ongoing series covering exciting hot startups from the AWS ecosystem. And here we're talking about cybersecurity. I'm John Furrier, your host. We're joined by Carl Mattson CISO, Chief Information Security Officer of No Name Security. Key of Alumni, we just chatted with you at Reinforce AWS's event. We're here to talk about securing APIs from code to production. Carl, thanks for joining. Good to see you again. Thanks for the invitation, John. You know, one of the hottest topics right now about APIs is, you know, it's a double-edged sword. You know, on one hand, it's the goodness of cloud APIs. Make the cloud, that's the API first. Now you're starting to see them all over the place, there's APIs everywhere. Securing them and manage them is really a top conversation. At many levels, one, you can have a great API, but if you're going to manipulate the business logic, that's a problem too. So a lot going on with APIs, they're the underpinnings of the modern enterprise. So take us through your view here. How are you guys looking at this? You want to continue to use APIs. They're critical, connective tissue in the cloud, but you also got to have good plumbing. What do you do? How do you secure that? How do you manage it? How do you lock it down? Yeah, so the more critical APIs become, the more important it becomes to look at the API as really a unique class of assets because the security controls we employ from configuration management and asset management, application security, both testing and protection like EDR, the platforms that we use to control our environments, they're poorly suited for APIs. And so as the API takes the position of prominence in the organization, it goes from the sort of edge case of a utility now to like a real crown jewel asset. We have to have controls and technologies in place and skilled teams that can really focus in on those controls that are unique to the API, especially necessary when the API is carrying like business critical workloads or sensitive data for customers. So we really have to sharpen our tools, so to speak, to focus on the API as the centerpiece of an application security program. You guys have a comprehensive view. I know the philosophy of the company is rooted in API lifecycle development management, runtime, can you take a minute to explain and give an overview of no name security? And then I want to jump into specifically the security platform and the capabilities. Sure, so we're an API security company just under three years old now. And we've taken a new look at the API, looking at it from a full lifecycle perspective. So it isn't new to application security professionals that APIs are a software asset that needs to be tested for security vulnerabilities, security testing prior to moving into production. But the reality is, is the API security exposures that are hitting the news almost every day, a lot of those things have to do with things like runtime errors and misconfigurations or changes made on the fly because APIs are changed very rapidly. So in order for us to counter API risks, we have to look at the full lifecycle from the moment the developer begins coding, the source code level, through the testing gates, through the operational configuration, and then to that really sophisticated piece of looking at the business logic. And as you mentioned, the business logic of the API is unique and can be compromised with exploits that are specific to an API. So looking at the whole continuum of API controls, that's what we focused on. It's interesting, you know, we've had APIs for a while. I mean, I've never heard and seen so much activity now more than ever around APIs and security. Why is it recently we're seeing this conversation increase with specific solutions? And why are we seeing more breaches and concerns about security? Because APIs are hardened. I mean, like, what's the big deal? Why now? What's the big focus? Why is API becoming more in the conversation for CISOs and companies to secure? And why is it a problem? Well, take it at APIs that we had eight, 10 years ago. Most of those were internally facing APIs. And so there were a lot of elements of the API design that we would not have put in place if we had intended that to be public facing. Authentication and authorization that is, we kind of get away with a little bit of sloppy hygiene when it's internal for the network. But now that we're exposing those APIs and we're publishing APIs to the world, there's a degree of precision required. So when we put an API out there for public consumption, the stakes are just much higher. The level of precision we need, the business criticality, just the operational viability and the integrity of that API has to be precise in a way that really wasn't necessary when the API was sort of a general purpose, internal network utility as it was in the past. And then the other area of course is then just the sheer use of an API at the infrastructure layer. So you think about AWS, for example, most of the workloads in the modern cloud, they communicate and talk via API. And so those are, even if they're internally facing APIs, misconfigurations can occur and they could be public facing or they could be compromised. And so we want to look at all of the sort of fast sets of APIs because now there's so much at stake with getting API security right. You know, this brings up the whole conversation around API to API and you guys talk about life cycle, right, the full life cycle of an API. Can you take me through that and what you mean by that? Because, you know, some people will say, hey, APIs are pretty straightforward. You got source code, you can secure it, code scanning, do a pen test, we're done. Why the full cycle approach? Is it because APIs are talking to third parties? Is it because, well, I mean, what's the reason? What's the focus? Why full life cycle of an API? Why should a company take this approach? Sure, so there's really three sort of primary control areas that we look at for APIs as what I call the traditional controls, there would be those to test and assure that the source code itself has quality or is secure. And that can, of course, usually is step one and that's an important thing to do. But let's say for the sake of discussion, that API that is designed securely is deployed into production, but the production environment in which it's deployed doesn't protect that API the way that the developer intended. So a great example would be if an API gateway doesn't enforce the authentication policy intended by the developer. And so there we have, it's not the developer's fault, now we have a misconfiguration in production. And so that's a type of example also where now an attacker can send a sort of a single request to that API without authentication or with, you know, misinformed authentication types and succeed resulting in data. The WAF didn't protect against it, it was secure code. And so when we look at the sequence of API controls they all really have to be in sync because source code is really the first and most important job, but good API design and source code doesn't solve all the challenges for the production environment. We have to look at the whole life cycle in order to counter the risk. IBM's research last year in its own X-Force survey estimated that 60% of all API breaches are due to misconfiguration not to source code design. And so that's really where we have to marry the two of the runtime protection, configuration management with the source code testing and design. It's interesting, you know, we've all been around the block we've seen the early days and, you know, it was really great back in the day is slinging API. Hey, you know, Carl, you have an API for that? Oh sure, I'll bang it out tonight. You know, so, you know, they've gotten better. I'm over simplifying, but you get the idea. They've been kind of really cool to work with and connect with systems. It's not plumbing. Okay, so organizations are dealing with this. They're dealing with API and more of them. How do they know where they stand? Is there like a API discovery capability? What do they do? What does a CISO do? What does a staff do? It's saying, okay, you know what? We don't want to stop the API movement because that's key to the cloud. How do we reign it in? How do we reign in the chaos? What do they do? Is there playbook? What is, how does an organization know exactly where it stands with the state of their APIs? Yeah, and that's usually where we start a discussion with the customer is a diagnosis, right? Because when we look at sort of diagnosing what our API risk exposure, you know, the first critical control is always know your assets and that we have to discover them. So we employ usually discovery as the very first step to see the full ecosystem of APIs, whether they're internal, external facing, whether they're routed through a gateway or whether they're routed through a WAF, we have to see the full picture and then analyze that API footprint in terms of its network context, its vulnerabilities, its configuration qualities, so that we can see a picture of where we are. Now, in any particular organization, we may find that there is a high quality of source code, perhaps the gaps are in configuration or we may see the reverse. And so we don't necessarily make an assumption about what we'll find, but we know that that observability is really the first step in that process is just to really get a firm sort of objective understanding of where the APIs are. And the really important part about the observability to the API inventory is to do it with the context also of the sense of the data types because, you know, for example, we see organizations, our own research showed that for organizations over 10,000 employees, the average population of APIs is over 25,000 in each organization. 25,000 APIs is an extraordinary amount to even contemplate a human understanding of, so we have to fingerprint our APIs. We have to look at the sensitive data types so that we can apply our intellect and our resources towards protecting those APIs which are carrying sensitive data or which are carrying critical workloads because there are a lot of APIs that still remain today even sort of internally facing utilities, workhorses that keep the lights on, but not particularly high risk when it comes to sensitive data. So that triage process of like really honing in on the high risk activity or the high risk APIs that they're carrying sensitive data and then the risk exposure assessing them to see where an organization is that's always the first step. You know, it's interesting. I like your approach of having this security platform that gives the security team's ability to kind of let the developers do their thing and then have this kind of security ops kind of platform to watch and monitor and be in any potential attacks. So I can see the picture there. I have to ask you though, it's a CISO. I mean, what's different now? Because back in the old days where APIs even on the radar and two, there's a big discussion around software supply chain, this kind of this API is now a new area as you've been referring to people stealing data, things are in transit with APIs. What is the big picture? If you had to kind of scope out the magnitude of like the API problem and relevance for a fellow CISO, how would you have that conversation? And you'd be like, Hey, APIs are out of control. You got to rein it in or is it a 10 and a 10, is it a eight? I mean, take me through a conversation you're having with security teams or other CISOs around the magnitude of the scoping the problem. Yeah, so I think of the API sort of problem space has a lot of echoes to the conversations and the thought processes we were having about public cloud adoption a few years ago, right? But there were early adopters of public cloud and over the course of time, there was sort of an acquiescence to public cloud services. And now we have like actually like robust enterprise grade controls available in public cloud. And now we're all racing to get there. If we have anything in the data center left, we're trying to get to the public cloud as fast as possible. And so I think organization by organization, you'll see a reminiscent trajectory of API utilization because like an application, we're out of gone are the days of the monolithic application where it's a single website with one code base. And I kind of compare that to the data center in this comparison, which is the monolithic application is now sort of being decomposed into microservices and APIs. There are different differences in terms of how far along that decomposition into microservices and organization is. But we definitely see that trend continues and that applications in the three to five to 10 year timeframe, they increasingly become only APIs. So that an organization's app development team is almost exclusively creating APIs as the output of software development. Whereas there's a journey towards that path that we see. And so a security team looking at this problem set, what I advise for CISO, looking at this maybe for the first time is to think about this is this is the competency that we are security teams need to have. That competency may be at different degrees of criticality depending on where that company is in transition, but it's not a question of if it's a question of when and how fast do we need to develop this competency in a team? Because our applications will become almost exclusively APIs over time, just like our infrastructures are on the way to becoming almost exclusively public cloud hosted over time. Yeah, I mean, get on the API bus basically is the message. Like, look at it, if you're not on this, you're going to have a lot of problems. So in a way there's a proactive nature here for security teams. At the same time, it's still out there and growing. I mean, the DevOps movement was essentially kind of cavalier, very Maverick oriented and the APIs around no problem. Linguafranquic connecting to other systems and API to an endpoint to another application. That's what it was. And so as it matures, it becomes much more of, as you say, a connective tissue in the cloud native world. This is real. You agree with that, obviously. Yeah, absolutely. I mean, I think that the API connections are the connective tissue of most of what we do right now even if we are not presently conscious of it, but they're increasingly going to become more and more central. So that's a journey. Whether the focus on API security is to, let's say, put the toothpaste back in the tube for something that's already broken or whether it is preventative or preparing for where the organization goes in the future. But both of those are true or both of those are valid reasons to emphasize the investment in API security as a talent processes, technologies, all of the above. Okay, you sold me on, I'm the customer for a minute. Okay, and now I'm going to replay back to you. Hey, Carl, I love it. You sold me on this. I'm going to get out front. We're in lift and shift mode, but we can see APIs as we start building out our cloud native. But I'm really trying to hire a team. I got a skills gap here, too. That's one customer. The other customer is, hey man, we've been on this train for a while, Carl. We feel you. We've been DevOps pioneer. We're now scaling out. We got all kinds of sprawl, API sprawl. How do I rein it in? And what do you guys do? What's your answer to those scenarios from a security platform perspective? And what's the value proposition in those scenarios? I think the value proposition of what we've done is really to lean into the API as the answer key to the problem set. So whether it's integrating security testing into a code repo or a CI CD pipeline, we can automate security testing and we can do that very efficiently in such a way that when a one API security specialist with the right tools, it insulates the organization from having to go out and hire 10 more people because they've all of a sudden have this explosive growth and development. There's so much about API security that can capitalize on automation and capitalize on API integration. So the API integrations with web application firewalls, with SIM systems, those types of workflows that we can automate really do empower a team to use automation to scale and to approach the problem set without needing to go to the sort of the impossible ask of growing teams of people with special skills and who aren't available anyways or they're extremely expensive. So we definitely see ourselves as sort of leaning into the API as part of the answer in creating opportunities for automation. Yeah, so I got one more kind of customer role play here. I said, I love this, this is a great conversation. There's always the person in the room, Carl, hold on. Boss, this is going to complicate everything on the network layer. Application changes, there's a lot of risks here. I'm nervous, how do you guys handle that objection that comes up all the time? The person that's always blocking deals like, oh, it's risky implementing no name or this approach. How do you address the frictionless nature? Developers want to try stuff now. They want to get it in and they want to try things. How do you answer the quote complication or risk to network and application changes? Sure, two really specific answers. The first is for the developers, we want to put an API security in their hands because when they can test and model the security risks on their APIs while they're developing like in their IDE and in their code repos, they can iterate through security fixes and bugs like lightning fast. And developers really appreciate that. They appreciate having the instant feedback loop within their workspace, within their workbench. So developers love being able to self-service security. We want to empower developers to do that self-service rather than tossing code over the fence and waiting two weeks for the security team to test it then tossing it back with a list of bugs and defects. That annoys everybody. It's an inefficient one. Just for record, you guys are self-service to the developers. Yes, self-service to the developers. And that's really by customer sort of configuration choices. There are configuration choices that have, for example, the security team establishing policy, establishing boundaries for testing activities that allow the developers to test source code, iterate through defect fixes, things like that. And then perhaps you establish like a firm control gate that says that vulnerabilities of medium and above have to be remediated prior to that code committing to the next gate. That's the type of control that the security policy owner can apply. But yes, the developers can self-service and the security team can set the threshold by which the source code moves through the SDLC. Everybody will. Yep, exactly. And we have to practice that too because that's a new way of the security team and the developers interacting. So we have to have patterns that teams can then adopt procedurally because we aren't yet accustomed to having a lot of procedures that work that way. So yeah, we have templates, we've got professional services that we want to help those teams get that equation right because it's a truly win-win situation when you can really stick the landing on getting the developers the self-service options with the security team having the confidence level that the controls are employed. And then on the network side, by the way, I too am mortified of breaking infrastructure and which is exactly why what we do architecturally out of band is really a game changer because there are technologies we can put in line. There are disruptors and operational risks that we can incur when we're utilizing a technology that can break things, can break business critical traffic. So what we do is we lean into the, through the network nodes and the hosts that the organization already has, identifying those APIs, creating the behavioral models that really identify misuse and progress and then automate blocking, but doing that out of band. That's really important. That's how I feel about our infrastructure. I don't want sort of unintended disruption. I want to utilize a platform that's out of band that I can use that's much more lightweight than putting another box in the network line. What was interesting is what you're talking about is kind of the new school of thought and the script has flipped. The old school was solve complexity with more complexity, get in the way, inject some measurements software agents on the network and get in the way. And the developer, hey, here's a new tool we agreed in a vacuum, go do this. I think now more than ever developers are setting the agenda on the tooling. If it's, and it has to be self-service at our super cloud event that was validated across the board that it's self-service, it's got to be self-service for the developer, otherwise they won't use it pretty much. Oh, I couldn't agree more. And the other part too is like, no matter what business we're in, the security business has to honor like the business need for innovation. We have to honor the business need for speed. And we have to do our best to empower the strategy and empower the intent that the developers are delivering on. And yes, we need to be seeking every opportunity to lift that developer up and give them the tools sort of in the moment. We want to wrap the developer in armor not wake them down with an anchor. And that's the thing that we want to keep striving towards is making that possible for the security team. So you guys are very relevant right now, APIs are the favorite environment for hackers are seeing that with breaches and in the headlines every day. I love this comprehensive approach developer focused our security team enablement, operationally relevant to all parties. I have to ask you, how do you answer and talk about the competition? Cause with the rise of this trend, a lot of more people entering this market, how should a customer decide between no name and everyone else pitching API security? What's the, is there nuances? Is there differences? How do you compare what's the differentiation? Yeah, I think, you know, the first thing to mention is that, you know, companies that are in the space of API security, we have a lot more in common, we probably have differences cause we're focused on the same problems. But there's really two changes that we've made bringing to market an API platform. Number one is to look full life cycle. So it used to be that you could buy, you know, Dast and Sast software testing tools. No name has API testing in sort, you know, for source code and for pipeline integrations, along with then the runtime and posture management, which is really the production network. And so we really do think that we span east-west, a much broader set of controls for the API. And then the second characteristic is architectural fit, particularly in a runtime production environment, you have to have a solution that does not create significant disruptions. It doesn't require agent deployment. They can maximize the infrastructure that an organization already has. So we think are, you know, a big advantage for us in the production environment is that we can adapt to the contour of the customer. We don't have to have the customer adapt to the contour of our architecture. So that flexibility really serves well, particularly with complex organizations, global organizations or those that have, you know, data centers and public cloud and multiple varieties. So our ability to sort of adapt to a customer's architecture really makes us sort of like a universal tool for organizations. And we think that's really, you know, bears out in the customers and the large organizations and enterprises that have adopted us because we can adapt to really any condition. And that's great alignment too from an execution consumption standpoint. It's got to be fast with a developer. You got to be frictionless as much as possible. Good stuff there. I have to ask you, Carl, as you are a CISO, Chief Information Security Officer, you know, your peers are out there, they got so much going on around them. They got to manage the current, protect the future and architect the next level infrastructure for security. What do you see out there as a CISO where your peers are in the marketplace, you know, practitioners, you know, evaluating companies, evaluating technologies, managing the threat landscape, unlimited surface area evolving with the edge coming online. What's on their mind? How do you see it? What's your, what's your view there? What's your vision? If you were in the hot seat in a big organization, I mean, obviously you got a hot seat there with no name, but you're also, you know, you're seeing both sides of the coin at no name. You know, the CISO, so they the frog in boiling water right now? Or like, what's going on in their world right now? How would you describe the state of the CISO in cybersecurity? Yeah, there's two kind of tactical themes, I think almost every CISO shares. The first tactical theme is, as a CISO, I probably know there's a technology out there to solve a little bit of every problem possible. Like that's objectively true. But what I don't want to do is I don't want to buy 75 technologies when I could buy 20 platforms or 12, that could solve that problem set. So the first thing I want to do is, as I want to communicate what we do from the perspective of like a single platform that does multiple things, from source code testing to posture and configuration to runtime defense, because a CISO sensibilities is challenged by having 15 technologies I really just want a couple to manage. Because it's complexity that we're managing when we're managing all these technologies, even if something works for a point problem set, I don't want another technology to implement and manage. That's just throwing money oftentimes at suboptimal. We're not getting results when we just throw tools at a problem. So that platform concept is I think really appealing because every CISO is looking to consider how do I reduce the number of technologies that I have. The second thing is every organization faces the challenge of talent. So what are my options for mitigating what is sort of I can't hire enough qualified people at a remotely reasonable price to staff what I'd like to. So I have to pursue both utilizing third parties who have expertise in professional services that I can deploy to solve my problems but also then to employing automation. So a great example would be if I have a team that has a five person application security team and now next year my application security or my applications team is going to develop three times the number of applications and APIs. I can't scale my team by a factor of three just to meet that demand. I have to pursue automation opportunities. And so we really want to measure the successes that we can achieve with automation so that a CISO can look at us as an answer to complexity rather than as a source of new complexity because it is true that we're overwhelmed with the options at our disposal. Most of those options create more complexity than they solve for. And I pursue that in my practice which is to figure out how to sort of limit the complexity of what is already a very complicated role in protecting an organization. Got it. And when the CISO says, Carl, what's in it for me with no name, what's the answer? What's the bumper sticker? It's reducing complexity. It's making a very sophisticated problem set simple to solve for APIs are a class of assets that there's an answer for. That answer includes automation and includes professional services. And we can achieve a high degree of sophistication relatively speaking with a low amount of effort when we look across our security team. This is a solvable problem space and we can do so pretty efficiently. Awesome, we'll call. Thank you so much for showcasing no name. In the last minute we have here, give a quick plug for the company. Give a little stats, some factoids that people might be interested in. How big is the company? What are you guys doing? If people enthusiastic about the solution, share some, give the plug. Sure, we're a company of just about 300 employees now all across the globe, Asia Pacific, North America, Europe and the Middle East. Tremendous success with the release of our software testing module which we call Active Testing. We have such a variety of ways also to test and take no name for a test drive from sandboxes to POVs and some really amazing opportunities to show and tell and how the organization is diagnosed quickly, where they are. And so we love to show off the platform and let people take it for a test drive. So, nonamesecurity.com and anywhere in the world you are we can deploy a sales engineer who can help show you the platform and show you all the things that we can offer for the organization. Carl, great insight. Thank you again for sharing the stats and talking about the industry and really showcasing some of the key things you guys are doing in the industry for customers. We really appreciate it. Thanks for coming on. Thanks, John, appreciate it. Okay, this is the AWS Startup Showcase. I'm John Furrier, host. Season two, episode four of this ongoing series covering the exciting new growing startups from the AWS ecosystem in cybersecurity. Thanks for watching.