In this episode, we talked with Pat Clawson, chairman and CEO of Resurface Labs. Resurface Labs is a data-driven API security service that uses continuous API scanning to detect and respond to the attack in real-time. 

We talked about the growing importance of APIs in modern software architecture and the challenges companies face in managing hundreds or thousands of APIs. We also explored the unique challenges in API security, such as broken object-level authorization, API parameter tampering, session hacking, and other exploit types. 

Key Questions:

●      What are the problems to solve in terms of API security service?

●      Why are existing security systems, like Firewalls and API gateway, insufficient to defend the API network?

●      What does the unknown zone leading to the attack surface indicate, as shown in the graph? (Please insert the link of the graph mentioned on the podcast)

●      What are the focus areas in API security for modern software services?

Erik: Pat, good afternoon. Welcome to the podcast.

Pat: Thanks for having me. A pleasure to be here.

Erik: I'm looking forward to this conversation. Cybersecurity is stretching my bounds of know-how. So, I always enjoy talking to experts that are well past my domain of expertise. This is certainly a case. In particular, I think you've been in this space for — what is it now? 20 odd years?

Pat: Yeah, 21, 22 years for sure and a little bit.

Erik: A mix of entrepreneur slash executive. So, it looks like you've probably been involved — I mean, you've also had board positions. So, in total, it looks like there might be 10 plus companies that you've been involved with to some extent. But I suppose more or less degrees.

Pat: Yeah, totally. I've run probably six of them. I've been on boards of another four. Interesting path, though. I got into this back in 2000, 2001. It was the early days of even firewalls. People were still trying to figure out what they were. I had a NASDAQ turnaround, layer seven firewall company, which was amongst the best of the best in the planet. We're able to turn that company around and grow it. We tried to buy a competitor, and the competitor bought us in return. We exited that one, I think, January of '06. But that was the first foray into it. It was back then firewalls were evolving. They weren't just firewall. They were firewall VPN. We acquired another company, started integrating web filtering. So, it was the beginning. It started to expand. You get way products from there. Definitely, a gateway solution, layer seven solution.

Then tipped it on its year, I took over a company that was called PatchLink. Patch remediation platform is very much an endpoint solution. Completely different. Just before I got there, it looked like Microsoft was excited to give that stuff away for free. So, we had to pivot and move much more into a broader endpoint management security platform, which we did change the company name to Lumention. At the end, we had about 3,500 customers around the world. So, very global, very much an endpoint and agent-based solution, which is fabulous. I sold that.

Then my next move, interestingly enough, went into data. We went out of the product and into really data end of life. That was a company called Blancco. We listed it on the AME exchange out of London and ran that for two and a half years. Let's see. Along the way, I was on the board of a cyber — our competitor, a company called eDMZ, which was incredibly interesting. We sold that to Quest and then on to Dell. I was on the board of a company called Prolexic. Prolexic was the preeminent DDoS protection platform. It was the first one really in the cloud. We sold that to Akamai. Took over a dark web monitoring company. We evolved that into a digital risk protection company called Terbium Labs, and sold that to Deloitte about a year and a half ago. Now we're having fun. We're in a completely new space, which is API security.

Erik: Okay. It sounds like it's been an interesting ride and a lot of circumstances where you are coming into, let's say, a young, fast-growing existing company, and then operating it. How did you develop — it seems like that's a specialization that you have. I haven't interviewed that many people that have done this systematically. I've met a couple people that have done this once or twice, but this seems to be somehow a specific competence of yours. How did you end up developing that capability?

Pat: You know, I think it was grounded in my soul. When I was a young guy, right out of college, I worked for a great company out of Atlanta called Lanier. They had an incredible training program. They trained you how to sell. They trained you how to manage salespeople. They trained you how to manage units, business units. I've always been able to take it. I learned those fundamental business rules and tools, and I was able to apply them wherever I've been. Part of it, it's breaking down what you are and what you're not. You got to be honest with yourself. Sometimes you're not when you're in the middle of it. So, let's break it down, figure out who you are, and then figure out how to grow. I've been fortunate to be able to do this successfully.

Erik: I guess the cybersecurity market is an interesting space for this. Because it's also such a rapidly evolving market that you're always having new challenges emerge, new companies would be born to solve them. If you kind of look back on your career, how have you seen the threat landscape evolve for cybersecurity, and then the waves of technology innovation to try to address those threats?

Pat: Man, that's a huge question. I remember the early days trying to articulate how it was moving forward. There were big companies. They might have been Symantec and McAfee. Those names really don't even exist anymore, right? Now you've got CrowdStrike and all kinds, FireEye. You name other big companies that have evolved, and Proofpoint. You pick them. They have evolved over time. Everything about how the attacks have happened continue to change. As soon as you feel like you've made a technology advancement to try to manage it, they find a new vector.

The ones we'll talk about today is API security. As web traffic started moving more towards APIs, as apps proliferated, as devices proliferated, and all of them are using APIs for connectivity, you saw — I think it was a couple years ago. Akamai said that now 83% of all web traffic goes through APIs. But interestingly, we're not doing a lot to secure that part of the world. That's a whole new thing. As the industry changes, the communication changes, storage changes. All of that starts to invite new attack vectors. APIs are new attack vectors today.

Erik: Yeah, let's discuss that. APIs are emerging as the new attack vector because they're just being used so heavily. Maybe legacy is not the right term. But let's say, the incumbent players, why are they not able to quickly get up a product and move into this market? They have the customer base, et cetera. They certainly identify the problem. Why is there space for a young company to come and become a market leader in this space?

Pat: Well, I think that's always been the case. When you look at some sort of cybersecurity hierarchy, you've got the big, big, big companies. Then there's the mid-tier, and then there's the new upstarts. The upstarts are trying to solve problems that the big guys are just too slow to be able to go react to. They've got huge customer installed bases. They've got a lot of problems that they're working on solving every single day. There's a bunch of false flag next generation technologies that don't work out.

Fortunately, API security has been incredibly heavily invested in. It's been recognized on like T-Mobile's most recent attack. It's a very serious issue that's not well dealt with right now. So, I think what they'll do is, they'll let guys like us work it out and fight it out for what the best approach is in customer accumulation, and then probably come knocking on our door somewhere down the road.

Erik: Yeah. Okay. Got it. I guess outsourcing R&D to younger companies seems to be a workable strategy for these new problems.

Pat: Indeed.

Erik: Let's discuss API security then. Maybe before we get into the technical details, just from a business standpoint, a managerial standpoint, what's the problem to solve here? What's the threat to the business?

Pat: Let me answer that as somebody who wanted to be a consumer but didn't know the product existed yet. When I was running a company called Terbium Labs, we had very dedicated APIs for delivery of our technology and our outputs to big global customers. I didn't know we had a problem until the customer told us we had a problem. So, I didn't know what the quality of the traffic was and what our individual API's performance is — were they quality? Did I have slow-performing code? Did I have slow-performing APIs? We didn't know. You only knew when somebody told you you had a problem.

I also didn't know how secure they were. Were these things safe? Sure. They're safe and everything, we tell you. But then, you start reading about it. Around 2018, you started seeing analyst firms starting to publish and write about the complete lack of security within APIs. They're being pushed out and pushed out fast. They were. APIs manifest themselves in two major ways. One, we would call it east and west. Those are the ones companies use internally between their different systems, et cetera. Then you have north and south, those that are externally facing.

There are different rules. The bigger the company gets, the bigger the problem gets. Because you have people standing up APIs without any rules around them. They can connect to something to make their lives easier. But there's no quality check on it before it gets in there. There's no registration process. If that person leaves the company, it's sitting there as a zombie or whatever that might be. As the time has gone on, as APIs have proliferated, as businesses merge with other businesses, and people come and go, you've got this accumulation of veins hanging out of the corporate leg that are completely unmanaged. Completely unmanaged. Some are outside the firewalls. Some can be leveraged, and nobody knows you're using them — sometimes for good reasons, sometimes for bad. So, it's been this spider web of problems that have been evolving for, call it, five years.

Erik: Yeah, that's an interesting perspective. APIs are unique from other infrastructure that companies often build in that they don't have necessarily a dedicated manager. How many APIs might a — I guess it's different to the size of company. But what are the volumes that we're talking about in terms of individuals?

Pat: Well, you look at it in a couple different ways. One is the numbers of APIs. Almost every company we've talked to, honestly, will tell us, "We're not really sure. We think it's X. Sometimes it's 5,000. Sometimes it's 6, 7, 10. Sometimes we only have 10 or 20. It might be a banking environment, and it's their mobile apps and their b2b banking. So, the numbers of APIs can vary greatly.

The second thing is the calls, the call volume. I'll let you know a little something about it. You might have a regional bank that will have 40 to 50 million calls a day, but their call size is small. Then you have a government entity that's storing images. They may have far fewer, but the call size is greater. So, there's a lot of variables that go around API traffic and what makes it up today. Every business is a little bit different. Did I answer that?

Erik: Yeah, it's an interesting point. I was having a conversation with another cybersecurity company that was more focused on IoT endpoints a couple of months ago. You mentioned this topic of performance. They had maybe a similar problem, which is people don't know how many IoT devices they have on their network. They just don't know. They don't know. So, they were a cybersecurity solution. But they found out that their solution was also very valuable for helping companies manage performance in the network — just knowing how many devices do we have, where are they, are they on or are they off — which are not necessarily cybersecurity problems, but they're problems that you can solve if you have the data that you're processing. Exactly. It sounds like this might be a similar circumstance here where there's issues related to cybersecurity, but there's other performance-related issues. The same data sets can help you to address both of them to some extent.

Pat: They can. If you follow the guidelines from the bigger governing entities — NIST is one — it's not only the attack. So, there's a couple of categories. There's a governing body called OWASP. They have their Top 10. We have top 10 for API security. So, you want to be able to identify if any of those things are out of band, so you can fix. Then you've got known attack types, which you want to be able to flag on instantly, which is helpful. Then you have what they refer to as anomalies. These anomalies are, they could be poor performance. It could be slow performing which is like a future DDoS attack. It could be bad code. The way they look at anomalies being NIST is their future attack surfaces. A bad guy will figure out what's not working right and figure a way to leverage it. So, it's not just that it's an attack today, but it's presenting itself as a future attack surface or vehicle. Did that make sense?

Erik: Yeah, it makes sense. I guess you have your existing security system. So, you have your firewall. You might have an API gateway. Say, other systems, why are these not sufficient to defend your API network?

Pat: It's a great question. We have a graphic that I wish I could throw up magically and share with everybody. But as a former firewall guy, you got WAFs and you've got gateways. We don't do what they do. We're after those. As people authenticated in with credentials like Peloton attacked valid credentials, but did malicious things after they were through those products. So, there are certain things they're able to see in effect. But we're after those and in the microservices. So, we're seeing everything that's going on within the APIs — their complete request and response datasets. It's something that they can't see.

It's also a little bit unique. Because we're looking at that completely unredacted, unencrypted, and in runtime. So, we're getting a different picture. The way we like to refer to it is, say, "Look, we don't do what they do. We help them be smarter." Because when we implement with, for example, a gateway provider like Tyk, we want to be able to let them know what we know so that it can adjust its settings to be more efficient at the gateway, if that makes any sense.

Erik: Yeah, and you have this "security analyst in-a-box" concept. But is this basically the concept of your accessing the information unfiltered? So, you're directly on the API service.

Pat: Yeah, in a way. But what we try to do is we try to use ML to take a look at the attacks that are registering within a client environment. Instead of telling, "Uh-oh, you've had this type of attack triggered 58,000 times today in your enterprise," that's the number that happens. That's no use to you, right? Sending 55 alerts or 55, 58,000 emails, or 58,000 Slacks, or Teams, or whatever that might be is rendering the product useless to them. So, we try to give them context. We'll send them a single alert into Slack that says, "Hey, this is the attack that's happening. In the last 24 hours, you've had 58,000 of these happen. Here's exactly what it is. Here's the remediation that you should use to take." But that attack itself, that attack alert, also has a remediation path to an existing platform, a security platform they already own. It may be going to an XDR platform or a SOAR platform so that they can begin their playbooks or their orchestration for remediation.

So, we automate that process. We let the administrator know, so they don't have to sit there worrying about it or watching the screen. We let them know how pervasive the issue is. But behind the scenes, we're already telling one of their existing platforms what it is and all the detail around it so that they can start to fix it.

Erik: Okay. Got you. I'm looking at this graph. I think it's probably the one that you mentioned. We'll link to this in the show notes. You have the area that Resurface is defending between the API gateway and the API micro services, and some of the potential topics to monitor, let's say. So, insiders, supply chain partners, API, KPIs, et cetera. Then you have this area zone of the unknown, which is basically leading into the attack surface. What does that indicate? What is the unknown here?

Pat: Unless you have an API security platform that's truly an API security platform — not one that's sitting on a WAF, not one that's sitting on a gateway — one whose light exists after those, that's the zone of unknown. Most businesses today don't have that kind of a view into that element of the attack surface. Right now, it's shrouded. It's just, we just don't know. Unless the problem happens, we don't know. That's the zone of the unknown that we're trying to bring out of the darkness for everybody else.

Erik: Okay. So, it's kind of a shift in mindset from responding reactively once an attack has been identified to proactively understanding the behavior in the network and identifying that there might be potential for an attack, or there might be an attack underway, or there might be certain behavior that you need to then flag and react against.

Pat: Yeah, correct. So, we've built these series of rules that are specifically around those three categories I talked about. Is there anything that's going on in there that's a violation of an OWASP Top 10? Because we got to tell somebody. We have all the known attack types. Is there anything in here that looks or smells like it's an attack type that's taking place right now? Because we need to let somebody know. The third bucket is, are there any — is there any anomalous software, API behaviors that we should alert a development team or an AppSec team or whatever, so that they can get in front of it instead of it becoming a problem down the road?

Erik: Okay. Got it. Well, let's take a step back and look at this from a different perspective, which is the perspective of who you're working with. Everybody is managing APIs today, right? I guess, hypothetically, anybody could be your customer. But I'm sure, to some extent, you're focusing on certain company types, certain industries. What are the focus areas? Then why have you chosen them as focus markets?

Pat: Perfect. Thank you. When I first came into here, we did a lot of research. Within our sector, there are 9 or 10 different verticals that everyone's trying to get their arms around. So, we can't do that. Let's go for the three that we think have the highest need, most regulated, and the most to lose if they fail.

The number one is the BFSI category — banking, finance securities, and insurance. That's our number one. It's a majority of the dollars. They have heavily-regulated big fines. They're highly reliant on APIs for their mobile apps and their B2B apps and B2C apps, stuff like that. The next one we focused on was healthcare of the world. Again, whether you're on the insurance side, or you're on the provider side, or you're ambulatory, you're acute, it doesn't matter. API is so impact your world. Even the medical device folks are heavily reliant on APIs to keep those medical devices up to date and et cetera. So, it's incredibly large. The third one that we're focused on is high tech, which includes telco and defense. That category itself represents about 40% of the global cybersecurity spend. Those are the three that we focus on the most. That's where our customer types are coming from today around the world.

In terms of the size of business, this may sound a little contrarian, but we originally thought there'd be a lot in the middle, mid-market guys that would be buying it. They're the ones that don't have the experts on their teams. They don't understand the risks that the APIs are imposing. They have small staff. They can only handle so many problems at once. They're the ones that will say, "Okay. My WAF's got me covered." You get into the bigger companies that fit in those three categories; they have people on their teams that know the problem. They're coming to you with what their problem is, and how can you help them solve that. So, our target market is larger within those verticals, because they have people on board who get the problem and want to solve it before it gets them first.

Erik: Okay. Yeah, that's interesting. It does make sense. Then the folks that you'd be working with, is it typically a top-down approach coming from the CIO, or is it individual teams, individual product owners who identify spot problems and then contact you to solve those specific issues?

Pat: It's funny. In the beginning, it's been largely CISOs or CTOs that have driven, "You need to go find a solution to this problem. Tell us what our choices are here." We've been pulled in those conversations. What we saw a lot of in 2022 was, it was the first time these conversations were being had. CISOs had teams taking a look at platforms, trying to get sense of cost, scales, impact, workload effort, how they alerted, and what kind of a remediation path there was. There's a lot more in budget for 2023 because the problem has been recognized. But again, largely, CISO teams, CTO teams and their direct reports.

Erik: Okay. That means that these are solutions that companies prefer to standardize then across the organization, as opposed to allowing to be used or individual product owners to select the solution for their product.

Pat: We're seeing it. I'd like to tell you that's 100% the case, but we're seeing it both ways. The bigger the company, the more broken up they are with acquisitions, with geographies. So, we see a little bit of everything. But I would be nice.

Here's a part of the challenge. You may have five different gateway providers in a big company. You have different web or cloud solutions. So, these guys may be AWS. These guys may be Azure. These guys might be IBM OpenShift. I mean, you got everything going on. You got to figure out how you can work with all the different environments.

Erik: The geographic topic is interesting. I don't know how much this is impacting you. I mean, certainly, on the cloud level, China has its own ecosystem. India is also starting to look in that direction. Europe has its own set of regulations that are somewhat unique. Does this impact your ability to work with companies across different regions, or do you need to customize it to any extent to address these different regional regulatory differences?

Pat: That's a great question. It's one of the reasons that I joined this company. Our founder, Rob Dickinson, this isn't his first observability platform. But when he built this, he recognized an issue. Part of that is, you can take the strictest regulations in the world, and you understand who our verticals are in what we do. If we need to see all of their API traffic in runtime, unredacted and unencrypted, that's never going to happen in a third-party AWS environment or Azure. It needs to happen in their environment so it's safe, and they don't violate GDPR or any other rules about where that data is residing. The alternative is you have to heavily redact it. Then it's latent in a third-party environment. You just don't get to see everything. You don't.

We are a first-party only solution, but we're a cloud platform agnostic. So, we've added OpenShift. We're having to add Alibaba's cloud because Saudi Telecom has standardized on that for their clients. So, we're within inches of all of them. Within our website, you can see four or five, six different cloud platforms that we support out of the box right now. Our ability to extend ourselves around the world is very straightforward.

Erik: Okay. Interesting. Maybe we can look at this from a couple other perspectives in terms of the decision-making process. I guess global standardization is one area. It sounds like you have an infrastructure that allows you to address those issues. I guess performance could be another issue. You're talking about very high volumes of traffic. You're talking about real-time analysis. I guess performance would be one thing that CISO—

Pat: Put us in a sidecar. We operate like a Kubernetes sidecar. So, we do not impact their performance. That's the great thing about that architecture. We're able to let them run like crazy, and we don't get in the way.

Erik: Okay. What is the latency in terms of the analysis versus the data flow?

Pat: It's immediate. It's hot here. It's coming at you hot.

Erik: Okay. Interesting. I mean, is that a differentiator, or is that something that other providers would also have? I'm just thinking at the technological challenge here.

Pat: Yeah, I know. We're the only first-party platform out there. I think that's one. It's just we're openly belligerent about it. I haven't spoken to a CISO at a large bank in the world, or healthcare organization, or telco, or defense entity — you pick it — that is okay having their data at all in a third-party environment. The only way to really do it and understand is to have in theirs. So, I think that's unique.

The second part to come unfold, there's two of the pieces that unpack themselves because we are first party. First thing is, it's not redacted. We get it all in runtime, so we see it. The other vendors can't because no one's going to let them do that. They're not going to let all that data into a third-party environment. So, we see all requests and response datasets, which we think is pretty important. But it also allows us to create a data lake of at least the last 30 days of API traffic. So, when the zero-day attack happens, they got no idea.

We built a crazy little Google-like search tool into our database that allows them to say, "Hey, I've got a new log for J," and it will immediately analyze their traffic and let them know if they've been impacted, which APIs, et cetera so they can prioritize their mediations. No one else can do that. Because no one's going to let you create that data lake in a third-party environment. So, a couple of really unique capabilities. They're very practical that we're able to deal with because of where we sit.

Erik: Okay. Interesting. It's always so interesting to talk topics like cybersecurity. Because the underlying infrastructure that you build, the architecture that you build really determines how you're able to address the problem. Once you establish the architecture, 10 years later, when you're addressing different problems, it's quite difficult to evolve to those problems, right?

Pat: Yeah.

Erik: I guess, at least, maybe there's others. But one other issue that certainly is going to be top of mind is pricing, and how does pricing scale. Because you're talking about companies that are managing very high volumes of APIs and traffic. How do you look at the pricing issue? How do you address these questions?

Pat: Simple. Look, we took a little — one of the things we tried to wrestle with was what were the pricing standards within our industry. If we looked at 10 different competitors from around the world, there were 20 or 30 different variables that they would use with number of endpoints, number of developers. It was incredibly complex.

We really, really don't care about that. Architecturally, we are Docker, Kubernetes, and Trino. Trino is that database structure. It used to be the Presto team in Facebook. 13 or 14 of them left. It's an open source, massively scalable SQL database. So, we have standard Trino. Then we have Iceberg. It's really the number of nodes. In our basic small volume environment, every million to 2 million calls is an additional node. We got customers. So, you can get into it for about 18,000 a year for a single node. But if you go Iceberg, we're 500 million calls per node. So, you have this massive daily capability with instantly accessible data. That's closer to $32,000 per node. It's per node. It's really based on your call volume and size of call. That's it.

Erik: Okay. Got it. So, it sounds like you're looking at smaller organization, maybe in the five figures and then, I guess the larger organizations probably looking more at seven figures or something as they scale up.

Pat: Yeah, in the small side, we're seeing an average deal size of around 54,000 to 55,000. In the larger deal size, you're seeing them starting at around 150 going as high as 950.

Erik: Okay. Got it. Actually, that doesn't seem actually like that much money to be solving API security issues, given that —

Pat: We agree with you.

Erik: Yeah, well, I guess it's always easier for somebody to justify this after they've been burned once or twice, and then they see the liability.

Pat: That's unpacked, and that problem could have been solved, and they're paid attention. But they're a great networking company. They're not an application layer company. So, they don't really understand the risk of those applications we're presenting, right?

Erik: Yeah, I got it. Aside from these topics, what else would be a critical decision factor when a CISO is assessing should we solve this problem? Then what are we looking for in terms of a solution?

Pat: Yeah, I think data privacy is probably at the very tip, pointy end of the spear. It's something they have to be concerned about. I think the other thing — this is one of the biggest things. Gartner really enforces this. Discovery is a huge deal. Yes, we can plug into existing tools like API gateways or VPC mirroring or things like that. But as a vendor, you need to be able to discover things that they don't know about — your zombie APIs, stuff like that. The bigger the organization, the greater the amount of the unknowns happen to be. For you to be able to correlate that and bring it back to your client is incredibly helpful.

A lot of our guys don't want to admit that they don't know. We understand that. But they're also very eyes wide open when they take a look at that first couple of weeks of analysis. They're like, "Whoa, that's different." So, I think having a vendor that really gets the discovery process, that can run runtime, that can embrace the data privacy laws, and data residency laws that places like Europe enforced, Japan, Singapore, California, I think that's kind of the standard you got to be thinking about.

Erik: Okay. Maybe we can wrap up here with the look at a few use cases. Feel free to anonymize customer names if you need to. But I think it's always interesting to look at something a bit end to end. Who are you working with? What was the problem? Why did they reach out to you? Why would they find a solution? Then how did they deploy? What were the results that they achieved?

Pat: I can give you three right off the top of my head. First one is a banking environment. It's international. It's running in IBM OpenShift. I think the comments — I was just trying to recall some of the quotes. We use them sometimes. It's the first time they've seen the totality of their API traffic in a single place actually. Then what the actual outcome of that API traffic — do they have redirects? Do they have malformed? Do they have actual attacks happening? Do they have client errors? I think the other comment for them was they never really understood APIs as increasing their attack surface. But once they saw that the outcome of all their traffic, it adjusted their view, like, "Oh, this is a problem." We don't really have an existing solution that's actually looking at what's going on inside of our APIs, right? Whether you're a great platform like SentinelOne, you pick it, or Palo Alto, they don't necessarily know what's going on inside the API. They could kill an API, but they can't go stop a service within one. We got to move a little bit forward there. So, I think that one is kind of an attack surface. One, they never really realized the risk.

I think — I'm looking over my cheat sheet here just to help me figure it out. The second one is another international bank. Their comments were along the lines, they had no idea that they actually had actual attacks happening on a regular real-time basis, and the level of anomalies within their API infrastructure. That was a shock to them. I think it also allowed them to identify rogue and/or zombie APIs. But importantly, they have legacy APIs. They can't plug into their gateways. They're too old, and they're not going to work that way. But we're able to observe those as well, and help them improve and protect them. They have no other way of doing that other than through our product.

The third one gets into the medical device world. It's really around audit and compliance. These guys are heavily API-driven. But they have a requirement to prove their compliance but also their connectivity and availability of these medical devices. It's not like — there's a buddy on another subject who said to me the other day, you know, banking, you can attest that you have what you need in order to get it done. In the healthcare world, you can't. You actually have to be able to audit, present, and prove that that is real, it's working, and it's not infected, and it's doing the right thing at all times. Those are three different use cases with three different needs from buyers, all driven by CISOs or CTOs.

Erik: Okay. I'm thinking of a use case. I don't know if this is a use case or not. Maybe you can share your thoughts on this. There's been a lot of discussion around ChatGPT in this topic. Andreessen Horowitz, they had a little podcast discussion earlier this week or maybe last week, where they asked some of the partners what are the top topics that you're interested in 2023. One of the partners said they're interested in the topic of compliance of banking. Because apparently, at banks, it's become 10% of total revenue, sometimes more, is dedicated to compliance. That means you have 15,000 people at a large bank doing compliance. Then the look is, okay, in the next five years, is that going to shift from outsourcing to India to using GPT-6? Or once it matures to a point, is it using basically an AI algorithm to do this?

I'm imagining then, potentially, just vast amounts of API traffic. I don't know if that would be API traffic. Maybe not. But then, doing something that's very related to compliance. It has a unique regulatory environment. But how do you see the — I mean, this is just one use case. But you can imagine that there's a lot of companies that are looking at shifting the manual processes towards machine-driven processes, AI-driven processes. How do you see that impacting API traffic in your business? Will it have an impact, or is this kind of a tangential topic?

Pat: No, I think it continues to drive the explosion of APIs as communication tools. I think it just gets bigger. The scale and the growth of API, there's a bunch of numbers. I can't rattle them off right now. But it's so extreme. Then new versions like GraphQL and stuff like that are just launching and taking over businesses. Look, I think that's one of the pieces of the puzzle. But the more distributed, the more IoT that we do, all of these things are relying on APIs.

I think one of the big questions is, as we start to realize that APIs were built for productivity, for revenue generation, for ease of all of them, they weren't necessarily built to be secure. So, the concept of shifting left and getting security in from the beginning as you introduce this explosion of these new APIs is a really healthy conversation. Being able to understand and run your APIs and understand if there are anomalies within it before you stand them up into production is another healthy conversation to have.

Erik: Yeah, interesting. I was talking, again, to another cybersecurity company. This one is focused on med tech. Again, on IoT devices. But they had some statistic. I'm not capturing it exactly. But it was like 10x times more expensive to retroactively secure a device after it had launched into the field versus addressing security issues during development. I guess there's some kind of similar multiplier here.

Pat: Yeah, it's been that way. Go back to the automotive world. If you deliver junk car with a warranty, it can cost you a lot more to keep it running properly than just to do it right in the first place.

Erik: Great. Well, what's on the roadmap? Obviously, this is still a very rapidly evolving space. So, if you look at Resurface over the next 12 months, 24 months, what are the big priorities for you?

Pat: You know, I think it's all around security, exposing different postures. It's also, I think, making it — we pride ourselves on simplicity. If you stand us up in 15 minutes, in a single home command, we're fast. We're straightforward. I think the tricks come in. Relationships with the best gateway vendors out there, with users with the GCPs, with the AWSs, the IBMs, the Alibabas, all of those guys. Because those interactions in the F5, you pick, those relationships allow not just knowing about the problem, but it allows you to create a network of similarly interested vendors that want to solve the problem as well. Knowing about it is one thing. Remediating, it's another. Making those relationships seamless is a big effort that we have. Our community, our partnerships is right at the top end of what we're focused on right now.

Erik: Yeah, great. Well, Pat, super interesting business that you're building here. Any last thoughts for the folks listening?

Pat: Oh, it's just, don't be afraid to recognize that it's an issue, it is an attack surface issue. It is bigger than you think. Don't be afraid of sticking your hand up and saying, "Let me try it for free. Let me understand my problem," and then I'll come talk to you. It's real. It doesn't cost you anything to figure it out.

Erik: Yeah, great. I see you're offering a demo on your website. So, for the folks that are listening, that's resurface.io. Pat, thanks for your time today. Thanks for having me.