>>Hello, everyone. Welcome to the cubes presentation of the a startup showcase. This is our season two episode four of the ongoing series covering exciting hot startups from the a AWS ecosystem. And here we talk about cybersecurity. I'm John furrier, your host we're joined by Carl Mattson, CISO, chief information security officer of no name security, keep alumni. We just chatted with you at reinforce a business 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. Is APIs everywhere, securing them and manage them. It's really a top conversation at many levels. One, you're gonna have a great API, but if you're gonna 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 gotta have good plumbing. Where, what do you do? How do you secure that? How do you manage it? How do you lock it down? >>Yeah, so the, the more critical APIs become the more important it becomes to look at the, the API as really a, a, a unique class of assets, because the, the security controls we employ from configuration management and asset management, application security, both testing and, and protection like, like EDR, the, the, the platforms that we use to control our environments. They're, they're, they're poorly suited for APIs. And so >>As the API takes prominence in the organization, it goes from this sort of edge case of, of, of a utility now to like a real, a real crown jewel asset. And we have to have, you know, controls and, and technologies in place and, and, and skilled teams that can really focus in on those controls that are, 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, to sharpen our tools, so to speak, to, to focus on the API as the centerpiece of a, of an application security program, >>You know, you guys have a comprehensive view. I know the philosophy of the company is rooted in, in, in API life cycle development management runtime. Can you take a minute to explain and give an overview of no name security? And then I wanna jump into specifically the security platform and the capabilities. >>Sure. So we're an API security company just under three years old now. And, and we we've taken a new look at the API, looking at it from a, from a, a full lifecycle perspective. So it, it, isn't new to application security professionals that APIs are, 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, cuz APIs are, are changed very rapidly. So in order for us to counter API risks, we have to look at the, the full life cycle from, from the moment the developer begins, coding the source code level through the testing gates, through the, the operational configuration. And then to that really sophisticated piece of looking at the business logic. And, and as you mentioned, the, the business logic of the API is, is unique and can be compromised with, with exploits that, 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 APIs becoming more in the conversation for CSOs and companies to secure? And why is it a problem? >>Well, take, take APIs that we had, you know, eight, 10 years ago, most of those were, 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 that was, is we kind of get away with a little bit of sloppy hygiene when it's internal to 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, 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, other area of course, is then just the sheer use of a 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 wanna look at all, all of the sort of facets 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 what I mean, what's the reason what, what's the focus, why full life cycle of an API? Why should a company take this approach? >>Sure. So there's, there's really three sort of primary control areas that we look at for, for APIs as like what I call the traditional controls. There would be those to, to test and ensure that the source code itself has as quality or is, is secure. And that can, that can, of course, usually a step one. And that's, that's an important thing to, to do, but let's say let's 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, there's not the developer's fault. Now we have a misconfiguration in production. And so that's a, that's a type of example also where now a, an attacker can send a sort of a single request to that API without authentication or with, you know, misformed authentication types and, and succeed resulting in data. >>The waft 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, good API design and source code doesn't solve all challenges for their production environment. We have to look at the whole life cycle in order to counter the risk IBM's research last year in its X worth 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, the, the source code testing and design. >>It's, 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 you sling an API, Hey, you know, Carl, you have an API for that. Oh, sure. I'll bang it out tonight. You know? So, so the, 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 now plumbing. Okay. So organizations have, are dealing with this, they're dealing with APIs 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 CSO do? What does a staff do saying, okay, you know what? We don't wanna stop the API movement cuz 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 does, how does an organization know exactly where it stands with the state of their APIs? >>Yeah. That, and that's usually where we started a discussion with a, with a customer is, is, is a diagnosis, right? Because when we, when we look at sort of diagnosing what our API risk exposure, the, you know, the, the first critical control is always know your assets and, and that we, we have to discover them. So we, we, 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 WF, we have to see the full picture and then analyze that API footprint in terms of its network context, it's vulnerabilities, it's configuration qualities so that we can see a picture of where we are now in, in any particular organization, we may find that there's a, a, a, a high quality of source code. >>Perhaps the gaps are in configuration, or we may see the reverse. And so we, we don't necessarily make an assumption about what we'll find, but we know that that observability is really the, the first step in that, in that process is just to really get a firm sort of objective understanding of, of where the APIs are. And, and the really important part about the, 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 AP thousand APIs is an extraordinary amount to, 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 have, 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, work courses that keep the lights on, but not particularly high risk when it comes to sensitive data. >>So that, that, that triage process of like really honing in on the, on the high risk activity or the high risk APIs that they're carrying sensitive data, and then then sort of risk exposure assessing them and 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 teams, the ability to kinda let the developers do their thing and, and then have this kind of security ops kind of platform to watch and monitor and any potential attacks. So I can see the picture there. I have to ask you though, as a CSO, I mean, what's different now, because back in the old days where API's 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'd been referring to people, stealing data, things are in transit with APIs. What is the, the big picture, if you had to kind of scope out the magnitude of like the API problem and, and relevance for a fellow CSO, how, how would you have that conversation? You'd be like, Hey, APIs are outta control. You gotta reign it in. Or is it a 10 and a 10? Is it a eight? I mean, yep. Take me through a conversation you're having with security teams or other CSOs around the magnitude of the scoped scoping the problem. >>Yeah. So I, I think of the, the, the API sort of problem space has a lot of echoes to the, to the conversations and the thought processes we were having about public cloud adoption a few years ago. Right. But there was, there were early adopters of public cloud and, and over the course of time, there was sort of a, 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, if we have anything in the data center left, we're, we're trying to get to the public cloud as fast as possible. And so I think organization by organization, you'll, you'll see a, a, a reminiscent sort of trajectory of, of API utilization, because like an application we're out of gone are the days of the monolithic application, where it's a single, you know, a single website with one code base. >>And I kind of compare that to the data center, 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 the, that that trend continues and that applications in the, you know, 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, as the, as the output of software development. Whereas there's a, there's a journey to, towards that path that we see. And so, so a security team looking at this problem set, what I, you know, advise for, for a CISO. The looking at this maybe for the first time is to think about this as this is the competency that we, our security teams need to have. That competency may, may be at different degrees of criticality, depending on where that company is in transition. But it's not a, 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 it, if you're not on this, you're gonna 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, sling APIs around no problem, Linga Franco 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 a, as you say, connective tissue in the cloud native world, this is real. You agree with that obviously? >>Yeah, absolutely. I mean, I think that the, I think that these, these API connections are, are, are the connective tissue of most of what we do right now. Even if we are, are not, you know, presently conscious of it, but they're, they're increasingly gonna become more and more central. So that's, that's, that's a, that's a journey whether, whether the, 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 prep preparing for where the organization goes in the future. But both of those, both of those are true. Or both of those are valid reasons to emphasize the investment in API security as a, as a talent processes, technologies all the above. >>Okay. You sold me on I'm the customer for a minute. Okay. And now I'm gonna replay back to you. Hey, Carl, love it. You sold me on this. I'm gonna get out front we're we're in lift and shift mode, but we can see APIs as we start building out our cloud native. And, but I'm really trying to hire a team. I got a skills gap here too. Yep. That's one customer. Yep. The other customers, Hey man, we've been on this train for a while. Kyle. We, we, we feel you, we in DevOps pioneer, we're now scaling out. We got all kinds of sprawl, API sprawl. How do I reign it in? And what do you guys do? What's your answer to those scenarios from a security platform perspective and how does that, what's the value proposition in those scenarios? >>I think the value proposition of what we've done is really to, to lean into the API as the, as the answer key to the problem set. So, you know, whether it's integrating security testing into a code repo, or a C I C D pipeline, we can automate security testing and we can do that very efficiently in, in such a way that one applic when a one API security specialist with the right tools, it ins insulates the organization from having to go out and hire 10 more people, because they've all, 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 integrations. 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, to use automation to scale and to approach the problem set without needing to go to the, the, sort of the impossible ask of growing these growing teams of people with special skills and, and who aren't available anyways, or they're extremely expensive. So we definitely see ourselves as, as a, as a sort of leaning into the API as, as part of the answer and creating opportunities for automation. >>Yeah. So I got one more kind of customer role play here. I says, I love this. This is a great conversation. You know, there's always the, the person in the room, Carl, hold on, boss. This is gonna complicate everything on the network layer, application changes. There's a lot of risks here. I'm nervous. What's your, how do you guys handle that objection that comes up all the time. You know, the, the person that's always blocking deals like, oh, it's risky implementing no name or this approach. How do you, how do you address the frictionless nature of developers? Wanna try stuff now they wanna get it in and they wanna try things. How do you answer the quote, complication or risk to network and application changes? >>Sure. Two, two really specific answers. The, the first is, is for the developers. We wanna put a API security in their hands because when they can, 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 they, and developers Le 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. And we want to empower developers to, 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. So >>For the record, just for the record, you guys are self-service to the developers. >>Yeah. 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, you know, defect, fixes, things like that. And then perhaps you establish like a firm control gate that says that, you know, vulnerabilities of, of medium and above are a, 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 can apply, but yes, the developers can self-service service and the, and the security team can set the threshold by which the, the, the, the source code moves through the SDLC. Everybody will. Yep. Exactly. And, and, but we're, we have to, we have to practice that too, because that's a, that's a new way of, of, of the security team and the developers interacting. >>So we, we, we, we have to have patterns that that teams can then adopt procedurally because we aren't, we aren't yet accustomed to having a lot of procedures that work that way. So yeah, we, we have templates, we've got professional services that we want to help those teams get that, that equation, right? Because it it's a, 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, on the network side, by the way, I, I too am mortified of breaking infrastructure and, and which is exactly why, you know, what, what we do architecturally out of band is, is really a, a game changer because there are technologies we can put in, in line, there are disruptors and operational risks that we can incur when we are, where we utilizing a technology that, that can break things, can break business, critical traffic. >>So what we do is we lean into the, the, the sort of the network nodes and the, and the hosts that the organization already has identifying those APIs, creating the behavioral models that really identify misuse in progress, and then automate, blocking, but doing that out of, out of band, that's really important. That's how I feel about our infrastructure. I, I don't want sort of unintended disruption. I want, I want to utilize a platform that's out of band that I can use. That's much more lightweight than, you know, putting another box in, in the network line. Yeah, >>What's 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, get in the way and the developer, Hey, here's a new tool. We agreed in a, in a vacuum, go do this. I think now more than ever, developers are setting the agenda on, on, 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 if it's self-service, it's gotta be self-service for the developer. Otherwise they won't use it pretty much. >>Oh, well, I couldn't agree more. And the other part too, is like, no matter what business we're in the security business is, is yeah, it has to honor like the, the, the business need for innovation. We have to honor the business need for, for, for speed. And we have to do our best to, to, to empower the, the sort of the strategy and empower the intent that the developers are, are delivering on. And yes, we need to be, we need to be seeking every opportunity to, to lift that developer up and, and give them the tools sort of in the moment we wanna wrap the developer in armor, not wake them down with an anchor. And that's the, that's the thing that we, we want to keep striving towards is, is making that possible for the security team. >>So you guys are very relevant right now. APIs are the favorite environment for hackers was seeing that with breaches and in the headlines every day, I love this comprehensive approach, developer focused op security team enablement, operationally relevant to all, all, all parties. I have to ask you, how do you answer and, and talk about the competition, cuz 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 pitch in 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, the, the first thing to mention is that, you know, companies that are in the space of API security, we, we have a lot more in common. We probably have differences cause we're focused on the same problems, but there's, there's really two changes that we've made bringing to market an API platform. Number one is to look full lifecycle. So it used to be that you could buy, you know, DAST and SAS software testing tools, no name has API testing in, so, 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, is architectural fit. Particularly in a runtime production environment, you have to have a solution that does, does not create significant disruptions. >>It doesn't require agent deployment that can maximize the, the, the infrastructure that an organization already has. So we think our, you know, a big advantage for us in, in the production environment is that we can, 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 on, you know, data centers and, and, and public cloud and, 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, in the customers, in the large organizations and enterprises that have adapted us because we can adapt really any condition. >>Yeah. And that's great alignment too, from an execution consumption standpoint, it's gotta be fast with a developer. You gotta be frictionless as much as possible. Good stuff there. I have to ask you Carl, as, as you are a CISO chief information security officer, you know, your peers are out there. They're they're, they got, man there's so much going on around them. They gotta manage the current, protect the future and architect, the next level infrastructure for security. What do you, what do you see out there as a CSO with your peers 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, if you were in the hot seat in a big organization, I mean, obviously you're 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 are they the frog and boiling water right now? Or like, like what's going on in their world right now? How would you describe the state of, of the CISO in cyber security? >>Yeah, there's, there's, there's two kind of tactical themes. I think almost every CISO shares the, the, the, the, the first tactical theme is, is I as a CISO. I probably know there's a technology out there to solve a little bit of every problem possible. Like, that's you objectively true. But what I don't wanna do is I don't wanna buy 75 technologies when I could buy 20 platforms or 12 that could solve that problem set. So the first thing I wanna do is as I, I want to communicate what we do from the perspective of, of like a single platform that does multiple things from source code testing, to posture and configuration to runtime defense, because I, a CISO's sensibilities is, is, is, 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, I don't want another technology to implement and manage. That's, that's just throwing money. Oftentimes at, at suboptimal, you know, we're not getting the results when we just throw tools at a problem. So the, that that platform concept is I think really appealing cuz every CSO 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, what are my options for talent, for mitigating? What is sort of, I, 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 the utilizing third parties who have expertise in professional services that I can deploy to, to, to, to solve my problems, but also then to employing automation. So, you know, the, a great example would be if I have a team that has a, you know, a five person application security team, and now next year, my applications security or my, my applications team is gonna develop three times the number of, 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, the, the successes that we can achieve with automation so that a CISO can look at us as, 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, and, you know, I pursue that in, in my practice, which is to, is to figure out how to sort of limit the complexity of what is already very complicated, you know, role and protecting an organization. >>Got it. And when you, when, when the CSO says Carl, what's in it for me with no name, what's the answer, what's the bumper bumper sticker. >>It, it's reducing complexity. It's making a very sophisticated problem. Set, simple to solve for APIs are a, are a class of assets that there's an answer for that answer includes automation and includes professional services. And we can, 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, this is a solvable problem space and, and we can do so pretty efficiently. >>Awesome. Well call, thank you so much for showcasing no name. And 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 enthusiastic about the solution? Share some, yep. Give the plug. >>Sure. We're, we're, we're a company of just about 300 employees now all across the globe, Asia Pacific, north America, Europe, and the middle east, you know, tremendous success with the release of our, of our software testing module, which we call active testing. We have such a variety of ways also to, to sort of test and take Nona for a test drive from sandboxes to POVs and, and some really amazing opportunities to, to show and tell and have the organizations diagnose quickly where, where they are. And so we, we love to, we love to, to, to show off the platform and, and let people take it for a test drive. So, you know, no name, security.com and any, anywhere in the world, you are, we can, we can deploy a, a, a sales engineer who can help show you the platform and, and show you all the things that, that we can, we can offer for the organization. >>Carl, great insight. Thank you again for sharing the stats and talk 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. That's the, this is the ADBU startup showcase. John fur, your host season two, episode four of this ongoing series covering the exciting new growing startups from the AWS ecosystem in cybersecurity. Thanks for watching.