In this episode, we discuss the growing importance of APIs, as we shift from human centric internet to a hybrid internet in which the majority of interactions are system-to-system, or machine-to-machine. We also explore the challenge of defending APIs from increasingly sophisticated criminal organisations that use internal agents and best in class software, rather than brute-force to exploit vulnerabilities.

Our guest today is Rob Dickinson, CEO of Resurface Labs. Resurface Labs is a database where all APIs can be easily and responsibly monitored to power data science, customer support, auditing and compliance, and production debugging.

IoT ONE is an IoT focused research and advisory firm. We provide research to enable you to grow in the digital age. Our services include market research, competitor information, customer research, market entry, partner scouting, and innovation programs. For more information, please visit iotone.com

Erik: Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host, Erik Walenza.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Erik Walenza, CEO of IoT ONE, the consultancy that helps companies create value from data to achieve growth. Our guest today is Rob Dickinson, CEO of Resurface Labs. Resurface Labs is a database where all API's can be easily and responsibly monitored to power data science, customer support, auditing and compliance and production debugging. In this talk, we discuss the growing importance of APIs as we shift from a human centric internet to a hybrid internet, in which the majority of interactions are system to system or machine to machine. We also explored the challenge of defending APIs from increasingly sophisticated criminal organizations that use internal agents and best in class software, rather than brute force to exploit vulnerabilities.

If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Finally, if you have an IoT research, strategy, or training initiative that you'd like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you. Rob, thank you for joining us today.

Rob: Thanks so much for having me.

Erik: So Rob, you are a software architect. You've worked with many, many companies, and it's basically all in this area of software architecture. But maybe you can start just by giving us a quick walk through some of the more interesting points in your career and how you ended up then in 2019 leaving Intel and setting up Resurface Labs.

Rob: Software architect, to me, I think as being a software nerd really at heart. And for me, I mean, I'm an old school nerd. I mean, I got started programming. But the way that I got started was I wanted an Atari for Christmas. And my dad really wouldn't have any part of that; he was like, if you want to play games, and you should be writing the games, like you can do that; without really having any concept of what that meant or even whether or not I could actually do it. And so instead of getting an Atari, I got a PC for Christmas that year, and never turned back.

And early in my career, again, I'm at the age where making money in software at the time was considered kind of ludicrous. I mean, all the money was in the hardware; that's where the action really was. And I was doing software development to put myself through school, and by the time I graduated from school, I realized like, wow, I can actually make a living doing the software stuff. If not a better living, then I would going a traditional engineering route. So never really looked back and participated in the original web boom, did some startups at that time, and before we kind of struck it big.

And the last company that I was involved with started off as a startup here in Boulder. But then we grew and then we were sold to Quest Software, we were then a division of Dell. Like why I have a little bit of a chip on my shoulder there, but basically, when that fell apart, I went to Intel and I was a researcher at Intel for a couple of years. But I never really lost that appetite to want to start something and really take on that level of challenge. So I found myself in 2019, leaving my very, very comfortable little nest at Intel that I made for myself, and most days that still seems like that was a pretty good choice.

Erik: So that was a very clever strategy of your dad. I love these little tactics that parents use to guide their kids away from wasting time towards, I'm sure you still managed to play a lot of video games, but at least he managed to plant this bug in you.

Rob: Oh, yeah. Things are different now. But at the time, like the way that you actually did that was you'd get a subscription to bite magazine or PC Magazine and the program listings would actually be printed in the magazine. So they would print games, and they print the source code for the games. And so you'd get the magazine, you type it in locally and you'd have to figure out what you'd fat fingered and gotten wrong and debug it in order to get it running. But that was how we did it.

And so, now I'm in a place where I'm teaching my 10 year old son. He said that he wanted to learn programming, and I said, okay, you're not ready. And then he came back and said, oh, I want to learn Python, and I said, okay, you're ready. And step one is let's go to GitHub, and let's start pulling some games off GitHub and modifying them. So it's funny, like the mechanics certainly have gotten a lot easier of, I think, getting on that journey. And that's a great thing. And it's great to see other people falling into it too.

Erik: Rob, you've kind of piqued my interest about this. So I guess it was the acquisition of, if I'm pronouncing it right, is it ‘Xaffire?

Rob: Xaffire, it wasn't the best name from my perspective.

Erik: So acquisition of Xaffire of Quest by Dell, so what went wrong here?

Rob: Well, on the one side, it was one of the greatest experiences of my professional career to go from just a group of people sitting around a whiteboard, to working with just some huge accounts; folks, like Bank of America, Toyota Motor, USA, American Airlines. Some of those were even accounts that question Dell didn't necessarily have before we came on. And we really felt like we were an industry leading magic quadrant solution for APM and for web monitoring specifically. And I really felt like I had gone from teeny little startup to standing on top of some giant mountain.

At one point I was literally our account manager for one of our largest account. They had my cell phone number, and like they didn't even file support cases, they were just calling. It was just amazing like in terms of real tactile relationships with your customers. And that was very much related to what we're doing with Resurface. This was really system monitoring and web monitoring. What we're doing with Resurface is really shifting that to API monitoring.

But ultimately, what happened was we were part of Dell. I don't mean to impugn anyone at Dell. But Dell didn't really have much of a cloud strategy at the time. The strategy as we understood it was if you had a customer that was threatening to go to AWS, like at one point, Toyota, for example, told us we're going to be moving to AWS. What we were told was well, just wish them well, because they're going to be back with their tail between their legs in a few months when they realize how bad that stuff is.

And we could see the writing on the wall. But at the same time, we just weren't aligned with our corporate overlords, and really where the portfolio was going and really the portfolio strategy. It's exactly the same story with Zoom, originally started off as WebEx and then they were acquired by Cisco, and then they spun back out, because they didn't really like where the Cisco portfolio was going. So yeah, so it's a great story there, kind of on both sides of that because it certainly had its highs and its lows. And it was certainly bittersweet to walk away from Dell and that business that we operated for all those years.

But at the same time, we could see the writing on the wall, we could see that there, there's a completely new paradigm that was coming. And that was going to be a much more interesting opportunity ultimately. And that's really what we're pursuing now with Resurface.

Erik: Okay, well, that's a good first lesson for all the MBAs who are listening on the phone. There's certainly a role for MBAs in companies, but listen to your software folks, when it comes to software. Don't try to figure out the strategy yourself and think you understand what's happening.

Rob: It's hard.

Erik: This is actually an interesting I didn't know this about Zoom that Zoom was part of Cisco because I always kind of question okay, Cisco is this huge corporate, how are they managed to mess up so much their strategy? We used to use Cisco and then obviously, Zoom is just a [inaudible 11:08]. But that's an interesting historical note. I didn't know that, that was the case.

Rob: Yeah, it's a great backstory. I have a lot of respect for those folks.

Erik: But let's get into Resurface. I'd like to start from a business perspective. If you can give us really the quick 101 what is an API and why is it important? And then what are the challenges that businesses face in managing their APIs?

Rob: And so let's get the obvious part out of the way, what does API stand for? It stands for Application Programming Interface. Does that really help understand what those things are about? Not really. So, that may be the definition that you see when you Google that term. But here's really what that means from a human perspective and from a business perspective and an operations perspective.

What we're witnessing right now, is a transition from a web that was originally built for humans, and primarily built as an as an entertainment vehicle for humans to a business platform and operational platform, a global platform that really underlies everything. And take, for example, the outage that we had at AWS this week as an example of how a failure in one thing in one area can affect all these different businesses and all these different kind of ways, and everyone's pointing their finger back to AWS. That's the world that we're in. It's this highly, highly interconnected set of systems.

And the transition there is that with the original web, you had humans using web browsers to get content from web servers. And we're moving from that paradigm to a paradigm where you have APIs that are provided and those API's are consumed then by customers, by suppliers, by partners, by integrators, by a living ecosystem, by an open ecosystem, where the API provider doesn't necessarily provide all of the clients. There aren't necessarily like genuine clients or trusted clients.

And you can think of companies like Twilio, or SendGrid is kind of like the ultimate expression of that, because literally, their product surface is an API. But even if you're talking about companies like Salesforce or Expedia, that traditionally have had a very, very strong web presence, even for those companies, 90% of their traffic is through their APIs. And it's because of the benefit of that open ecosystem. And when you move from that concept of humans using web browsers to programs and humans working together, consuming this data that's available through these programmatic interfaces, you can get a sense of how big of a shift that really is.

And I think, a lot of what you hear about, like, especially around IoT is you hear like some of the specific use cases around like, well, it means connected cars, or it means that I have a smart refrigerator. But what it really means is that we're empowering those cars and those refrigerators to themselves be consumers of other kinds of software in interact with other kinds of automated systems. That's not under direct human control. That's a huge shift from where we started up.

Erik: So APIs, we can think of basically as programs that move data between different programs. There may be data commands, communication. If we drill in on IoT a bit more, what is the difference from a technical or functional perspective between two programs that are both based on a cloud communicating with each other, and maybe a back end procurement system on a cloud communicating with refrigerator something like this? Are there any fundamental differences that are important? Or is the underlying technology the same, it's just maybe a matter of figuring out how to how to launch this on a small compute?

Rob: I think one of the things that's really helpful as a strategy that we use all the time is to especially to try to understand some of these things that are kind of nascent, and just on the horizon is to look for analogs in the physical world of how we deal with some of these things.

So in the physical world, in the old days, you would call your stockbroker over the phone, and you would buy stock. And when you did that, there would be the little robot voice that would come on that would say, your call is being recorded for quality assurance. I mean, what was actually going on there is all of those calls are being recorded. Because if I call my stockbroker, even if I'm doing that over the phone, there needs to be a receipt of that transaction. Just because that takes place over the phone, it's still a business transaction, there's still real money on the line.

So, whether that's phone or fax, or whatever the vehicle is, but we have those standards of care, certainly, when there's money involved. You take that then you apply that to IoT, and you take that, and you apply that to this new world of the API economy. It's the same idea. You have a program talking to another program. Or you have a system talking to another system over the internet. And the API is just basically the conversation between those two. That conversation is being expressed in terms of API calls. So that's really the simple analogy.

API calls are really just the equivalent of phone conversations between computer programs. They just don't speak English. They speak REX or they speak Graph QL. There are specific protocols for these APIs that culturally allow these systems to talk to each other.

Erik: Yeah, I was just going to ask you about the relationship between API's and protocols, because you see also a lot of innovation right now in protocols, a lot of, let's say, blockchain companies that are trying to develop protocols, which are maybe highly ambitious projects that thus far haven't maybe generated so much in terms of tangible results. But at least, there's a lot of interest there, and also a lot of success in terms of more traditional protocols like OPCUA in the industrial space. And so the protocol would be basically defining the language that an API is communicating in, is that correct? Or what would be the relationship here?

Rob: I think that's a good simple way to frame it. I mean, I'm sure people might argue textbook definitions that are more narrow. But I think what really underlies what you just said that is a very wise insight is that we're moving in a direction where those protocols are becoming more specialized, and they're becoming more tightly optimized for specific kinds of use cases. And I'll just pick a very self-serving example here.

But I'm a database guy at heart. And so I know databases really well. And you look at the arc of database technology and the trend is every year there are hundreds of new kinds of databases in the world. It's a never ending journey of increasing specialization. Originally, we just had relational databases and now we have graph databases and analytic databases and in memory databases. Resurface is a database that is purpose built to capture and analyze and protect API traffic.

So it's a level of specialization that we're getting to in the market. But there's a lot of steps that we had to follow to get there. So I think there's really never ending opportunities to continue to develop new protocols, develop new API's, because we just always keep moving the goalposts in terms of building more and more specific solutions for specific domains.

Erik: So I wasn't thinking of Resurface as a database. So does that mean that Resurface is then a database where companies would store their APIs and then use this as also a management tool for debugging and tracking performance and so forth? Is that more or less how you view the company?

Rob: That's exactly right. Our goal is for resurface to be an API analyst in a box. We don't have enough API analysts to go around, whether those are quality analysts or security analysts. This is very quickly evolving technology, we have a real talent shortage. And specifically around security, like a lot of the folks that I talked to, there's not a general sense that we're winning necessarily when it comes to these things.

The trick is to use our technology to our advantage here. And that's why what we're doing this Resurface is where we're helping customers build these databases in-house, so this data stays in house. Resurface is not a SaaS, so we're not getting a copy of all of your data. Instead, we're evangelizing that data should be in the same jurisdiction under the same ownership the whole time. And we're providing our customers software to help capture that data and run it.

And so their experience, it looks like a database. It's like a Postgres or SQL Server. It's easy to run. It's easy to scale. And it's cloud native, so it runs natively on AWS and Azure. So it has all of the same benefits as a truly cloud native data platform, which it is. It's just that we're not providing it in a third party SaaS kind of package where it involves that third party data transfer. We just think that's jumped the shark a little bit. And we're also particularly interested in opportunities like IOT, healthcare, finance, crypto, where you're sending all that data to a multi-tenanted cloud based service that you don't own or control is going to be increasingly difficult.

Erik: Well, let's get a bit into why this is necessary. You mentioned security, so I guess that's certainly one of the big challenges here. Are there any other challenges? Or is it primarily how do we keep our APIs secure?

Rob: It's really a combination of security and quality and complexity. This surprised us like seeing some of the most recent numbers. But for example, if you say we'll just look at security. Well, as it turns out, about half of security breaches are due to misconfigurations, human error, or defects bugs that are exploited. So quality issues can easily become security issues. Security issues can also be loss of revenue events. So there's a real who's the dog, and who's the tail like being wagged here.

One thing that I think is very different about the landscape that we see today, specifically, from a security perspective is that the volume of threat traffic is so significant. When I was first started getting going with web systems, if you got hacked, or you got probed, it sounds funny to say it now, but it was almost like a little badge of honor. It was like somebody is really paying attention to what we're doing. There must be a buzz about us because somebody is trying to take what we've got. It was actually like a positive signal from the market. That's not the case at all now.

The case now is, if you expose an API, even if it's an API that you want to be private, so you say, I'm going to have this API, but I really only want it to be used by my mobile applications, for example, well, guess what, your intent doesn't matter. The fact that API endpoint is actually exposed to the internet means that it is going to be probed within minutes of that thing being reachable. It is going to be probed darn near continuously for the entire life of that thing, and so, trying to get that picture across what the volume of that looks like.

So you're talking about where the attack traffic is actually a majority of the traffic that you get, it's starting to drown out the legitimate customers. So think about that in the physical world. Think about what would a bank look like if half the people that came to the bank and walked in through the front door of the bank were there to rob the place, you would have to operate your bank very differently than the traditional approach where a bank robbery is rare and novel and dramatic.

This is the world that we are living in, unfortunately. And I know it's a dark thing to say, and I'm a bright person, but we are we are living in a world where we're basically constantly at war online. That's why the security people are grumpy for very good reason because these are very complex systems, they're changing very quickly. The nature of the attack vectors are changing very quickly. So there's a lot at stake and the goalposts are moving at the same time. That just presents some real significant challenges culturally, as well as technically.

Erik: I'm working with a lot of companies that are not digital natives at all: they're 50 years old, they're 100 years old, they're coming from mechanical background, or chemical or electrical engineering background. And then there, of course, now finding out that digital technologies are very important to how they run their business internally but also how they service their customers. I can then really clearly understand this proliferation of APIs or the need to create APIs to manage these solutions. But they're being done not by a bank, or by Microsoft, but by some company that builds industrial equipment, and now they're building APIs to manage relationships with customers.

On the security side, is the reason that this is such a challenging problem to solve? It's basically that people can automate these probing events. So this is highly automated, and then they're just residing in jurisdictions where they won't be prosecuted. So, is that kind of the environment that we live in today that there's enough places where somebody can sit and just kind of run automated programs that are probing the internet for vulnerabilities and we can't reduce the number of people out there? Is it more being protected in jurisdictions? Or is it more that we just can't find them, and it's challenging to actually make a legal case, regardless of where they sit?

Rob: I'm not sure that I actually have a very crisp answer that, but I'm actually curious to follow that a bit myself. What I can share is I think that the threat landscape has changed a bit, for sure here. Because I think what you described is a more classical view of what an attacker looks like. The classical view is the overseas attacker who's taking a relatively unsophisticated brute force approach. They're looking for unsecured SQL Server instances, or they're looking for unpatched Apache instances, like they're looking for known vulnerabilities that they know that they can use to gain control.

And certainly, there's a rich history of people doing really amazing things with those very limited and fairly primitive scripts. That's going to continue to happen. And there certainly are very good security companies around vulnerability scanning in particular and that need is not going away at all. But the problem with security ultimately is that failures in security a lot of times are not necessarily failures in competency. They're failures in imagination. These attackers are increasingly well funded. They are creative. They are professionals. They are coders too. They are researchers too. And they are very serious about their business, just like we're serious about keeping them out.

And so one of the vectors for example, and this is really where the idea of zero trust is really starting to gain a lot of traction in the market, it's not really a world anymore where you have trusted administrators and external attackers, and one is good and one is bad. We see a lot of cases where insiders are actually used to stage these attacks. Those people are extremely hard to find. You literally hear of companies running counterintelligence programs to try to identify these people. They’re literally hiring people from national security agencies to run those programs. Then at the same time, you have emerging threats where attackers sign up as customers.

So think about that whole idea of like I'm going to keep the attackers out means maybe I can block them at the network, or maybe I can block them at the perimeter. But what happens when a foreign intelligence service signs up as a paying customer to use your product, to use your service? It's even worse if you're giving these things away because then they can create as many free accounts as they want. But they actually have the money to sign up and be paying customers if they want to. And guess what, you're now inviting them in just like every other real customer, and your perimeter security is not going to prevent them.

So unless you're saying I'm just not going to get any customers from overseas at all, that idea of perimeter security based on nationality or traffic origin. I mean, that's absolutely still a technique that's used. But can that be the thing that we rely on to keep everyone out? Absolutely not. Look at the Peloton attack as a really classic example. That was not done by exploiting a vulnerability. That was done by using actual customer accounts, where the rights and permissions weren't being checked properly on the back end. And some of the folks that we've talked to that are doing research in this area, it really does keep you up at night when you hear about the numbers were virtually, any of these systems that are evaluated are ultimately susceptible to one or more of these forms of attack.

Erik: So let's go into a bit more maybe the technical details then of how your database works, and who would be the users and how would they fit this into their portfolio or their processes?

Rob: So what we're doing from a technical perspective is we're capturing the HTTP traffic that goes back and forth to your API. So that's the input to your API and the output to your API. And because all of the API's that we're talking about, for the most part are running over the internet, they're based on some variation of the HTTP protocol, whether that's REX, or whether that's Graph QL, or an industrial protocol, some of these are UDP.

But you're able to rely on the standard definitions; this is what an input generally looks like; this is what a request generally looks like; this is what a response generally looks like. And so we're creating a database that understands those concepts natively, understands REX, Graph QL, understands content types, understands when payloads are malformed, understands when Graph QL requests are nested too deeply. So you really have that application level awareness. Especially with some of the security vectors that we just talked about, you need that user level, sequence level, session level view into what's going on. And so that's how the system technically works.

But actually, the more interesting thing is how it culturally works. Because a lot of the systems that we see in the market today, they're not really solving that problem of that talent gap that we talked about earlier. A lot of the systems that you see, they gather data, they provide dashboards, they provide insights, but it still takes a lot of human intelligence to actually look at those bash boards, understand what all that means, and then turn that into an actionable case for the business.

So what we hear all the time when we talk to VPs of engineering, and CISOs and CEOs is how do I make my development team care more about quality? How do I help them care more about security? How do I breadcrumb our way towards that? And so what we're doing with Resurface is we are not just gathering data traffic, but we're analyzing that traffic and then we're guiding you towards what you should be paying attention to.

A lot of the folks that we're working with they haven't owned a system like this before. And so they're not exactly sure what questions to be asking, and how to separate signal from noise. So when you install Resurface, it's pre-trained on, for example, the OWASP top 10 threat vectors. And so we can find a lot of those kinds of attacks out of the box with the rules that we've got. And then you don't have to really hunt for them. Your experience culturally with Resurface then, is just like you would have with a human analyst.

So you work in Slack, you work in teams, and Resurface is sending new messages, opening cases that you should be taking a look at. And so you're trying to figure out what is signal and what is noise, and really be able to point to very, very specific cases and say these are cases where your perimeter security needs to be tightened up or where your application is failing, or where you're losing money and help you circle in on those very, very specific cases.

Erik: Is there a varied array of users that have some more from a business perspective, some that are coming from the security team, or is there a primary user here who is that sending out more actions to different people in the organization based on what they're viewing here?

Rob: It's been really interesting because we definitely have customers where they look at something like Resurface as a referendum on their quality. If you're having quality problems, if you're having things recur, also, if you have an external development team that you're having trouble wrangling, and you're seeing those quality gaps, then having a system of record where you can really point to all the cases, find the problematic cases, be able to handle those escalations more quickly, we've definitely gotten traction with customers that feel that kind of pain.

We also have other customers where the conversation starts with I want to run an OWASP top 10 compliance program in a way that doesn't make my developers heads explode. And so the entry point is more from that perspective. But what's really interesting is for a long time we thought, well, maybe that puts us in a place where we've got one foot in two canoes. And maybe that's wrong, maybe that's bad. But what we've really realized is that all of that meets in the middle. Because when half of your traffic or more is malicious in nature, then like almost every quality problem has a security component or security questions with it. And vice versa, like, if you're seeing a vulnerability is that due to a quality issue.

I think one of the things to keep an eye on is about a decade ago, we were talking a lot about DevOps, which was really the fusion of development and operations, which had really always been separate up until that point. I think we're seeing now a real need for DevSecOps or AppSec. There's different monikers being applied to that. But its right at the boundary between traditional development and traditional security where you need to take that richer look at these are all the different kinds of inputs that I'm getting, and this is how the system is responding. And is that really what I want? Is that really what we want to have happen? And how can we guide towards better outcomes?

And believe me, like, especially as a CEO, I would love to say, we are only doing quality or we are only doing security, but when we really start to peel the onion there, it really is a continuum. And I think it's increasingly hard to actually separate those out and truly consider them as orthogonal concerns. There was a time that you could say security is mostly about vulnerability scanning and securing your perimeter and that would be a very, very good standard of care for your security.

But go back to the story that we just talked about an attacker using a paid account as a staging ground, your vulnerability scanning, your perimeter defenses don't mean anything. That's a true Trojan horse. And now you're going to have to ratchet up that security and quality understanding at the application level.

Erik: And then I guess you'd have the most malicious case which is where you have an employee who is planted or imagined are engineers who could make a lot of money by floating from company to company working for one or two years, and either trying to insert code that they would then be able to pass on break, or at least just pass on information around database structures, and so forth to some kind of criminal organization. Because you could separate a quality issue into quality issues that are there done because somebody makes a mistake or forgets to do a proper quality check, and then there could be quality issues that are maliciously inserted, because the organization plans to then try to attack those vulnerabilities after they go to production? Is it at all possible to look at a situation and say this looks wrong? Or you just have to identify the issues and solve them but you don't necessarily know if the root cause was an honest error or a malicious activity?

Rob: This is not at all a new concept in insecurity. But I think that the trick is that you have to design your systems with overlapping silos, and with separated responsibilities. So that you, you limit the blast radius in any one area. And, I mean, that's how information security has always been handled by national security services, for example. It's always partitioned. It's always compartmentalized.

But the situation that you described there which might sound like something out of a movie, that's not just hypothetical. That is really actually what has been going on, not just now, but has been going on for years. I've had those conversations where, for example, someone that I know that was very, very high up at one of these big companies told me one of these stories at some point. He was like, yeah, you've got to understand we have very highly organized criminal gangs that are trying to get in here all the time. They find people with gambling problems. They find kids that have college debts that are drowning in debt. They will get these insiders that have clean criminal records and they will use these people as insiders to stage these larger attacks.

And for every one of those people that you have inside, you can have 30 more on the outside helping them do it. You look at some of the tactics that these large companies have to very quietly employ to try to find these people. And it's just like a Tom Clancy novel where you're reading the story about how they're trying to find a mole inside the CIA or whatever. It's exactly the same thing. But it's not happening on screen. It's happening to you. It's happening to your business.

I think it's hard to say that we've left that world behind where you can trust your technologists and you can trust the people on the inside. But the more that you have at stake, the more you're going to have to really take those things seriously. And just like we talked about at the top of this call, we're moving from an internet that was an entertainment vehicle for porn and cat videos and stuff like that to an internet that really matters for our cars to stay on the road and for our businesses operate properly. And there's a lot more at stake than there's really ever been

Erik: You placing yourself right in the thick of it's got to be a top three challenge for every IoT product company on the market and certainly a lot of other companies that aren't IoTs how to secure devices. This is a really a moving battlefield here. How do you look at Resurface going forward? What's on the horizon for Resurface to make sure that you're as much as possible staying ahead of the adversaries here?

Rob: We have a history of working with some really, really big enterprises on this kind of technology. And our goal with Resurface specifically is really to democratize that and to put that technology in the hands of every API provider that needs it, regardless of your budget or your operating footprint. If I wasn't doing Resurface, and I was doing something else, I would want a flight recorder like this on my APIs so that I could sleep at night so that I would know what's actually going on.

You go through so much time and effort and coffee is too late nights to build these things and then you put them out in the world and they're used differently than you expected. Sometimes that's good. Sometimes that's bad.

Every customer that we've worked with find some specific unique benefit almost right away when we start showing what's really going on, and you have that level of observability. The reactions are what well, that's wrong. Well, why are we doing that? Hey, we're wasting bandwidth. Why is that error code being served up? Which customers being affected by this thing that we didn't know is going on? And it's just like in the physical world, like, can you imagine operating a bank without a surveillance camera? That's kind of what Resurface does. We're, we're helping you audit all those transactions. We're helping you really understand all those cases.

Here's a specific anchor for you from a business perspective. A lot of the cases that we see, these are cases where it's not like AWS being down and there's a really obvious failure. The systems are up, the systems are performing the systems are working, but they're doing the wrong things. Either they're being exploited. They're not being used the way that they intended, or they're failing business rules, they're losing revenue. Your systems are working, but you're selling airline tickets that are supposed to be $5,000 for $5 apiece, real case, by the way.

And what's worse than all of this are the like the low and slow volume, whether it's an attack or whether it's a quality problem. The insiders who are really smart, they're not going to stage an attack that is large by volume, they're going to stage a very low slow attack going after very, very targeted vectors that are hard to find. The quality problems that are hard to find are the ones that affect a small percentage of your customers versus everyone.

So like the easy things are easy to find relatively speaking. But the hard things are really, really hard to find. And our goals are very much aligned with what points you were making before, that these API technologies are going into the hands of a lot of traditional companies that maybe don't have 100 years of experience in dealing with those kinds of factors. And this is new, yet they want to participate in the API economy and they want to modernize and be part of that. And those folks need more help to get there.

And at the end of the day, we're not making enough security analysts, we're not making enough quality analysts. We have a continuous talent shortage for all these things that we're trying to build. And again, the stakes are higher than they've ever been before.

Erik: And I think also managing a lot of these organizations, in my experience, this is just challenging from a management perspective because they're not able to compete with the big cloud based companies for the most experienced people. So they're often promoting people internally, who are great, great people, and they trust them, but they don't necessarily have the depth of experience that you would want them to have to be managing some of these challenges. Can we just quickly touch on the business aspects? What's the general model if somebody wanted to adopt Resurface?

Rob: We make it as easy as we possibly can. That is our brand. We have what we call node based pricing, just to start with. So because we're a first party solution, we don't charge based on the volume of data that is gathered, instead, we charge by how many nodes of the database we're going to license to run. And that's a really easy model for folks to get their heads around. The unit economics of that compares very, very favorably with that having to hire even one engineer or one analyst to do the same work.

And so our goals are really to make that whole process easy, make it easy to start in preproduction, make it easy to start with either your most valuable API or your most problematic API, and expanding out from there. So we're not your traditional enterprise software company that we just do a drive by and throw a million dollar contract at you. We're really working hands on with our customers. Our customers come and join our Slack community, and have direct access to our development team. And that's really how we're building our business right now is really getting that direct feedback between how the technology is being used, what cases people are interested in solving, and then feeding that back into a package that's really easy to use and very effective.

Erik: I really, really do hope that you and all the other good actors here that are trying to solve this problem are successful. Is there anything that we didn't touch on, Rob, that you think is important to share with the audience today?

Rob: Yeah. For all that we talked about here today and I know that there are some darker elements in there, for anybody who's thinking about going into tech, or anybody who's thinking about going from development to do something else, working in cybersecurity, I'm a relative newcomer to cybersecurity myself. My background is really solidly in databases and development and systems. So I still consider myself kind of a newcomer to the security market.

But I've been really amazed at the people that I've met, and just how welcoming, and inclusive. And I know tech doesn't always have the badge of being super welcoming, and super inclusive. But really, the security people that I've met are really amazing people, and they really believe passionately in their mission and calling that goes with that in the sense that they are doing something that really matters.

So, as much as there are challenges around the API economy, and around this level of interconnectedness that we're getting to, I do think ultimately this is all a force for good in the end. But I think the trend has always been in the right direction. There's a desperate need for talent, and more thought in this area. My advice would be if you have an interest in getting into this get into it, it's certainly not too late. It's really fascinating. It's a really amazing domain to go into for what it has to offer.

Erik: And for all the businesses that are listening, I think, also take this very seriously, and I think finding smart tools like this is critical because you can't just go out there and hire all the talent that you wish you had. So you have to approach this intelligently. What's the best way for folks to reach out to you or just to get in touch with the Resurface team in general?

Rob: I am always available. My email is Rob@resurface.io. I'm also on Twitter. My handle is @robfromboulder. You can also come to Resurface.io and just request a demo, you'll more than likely get me. I don't do all the demos. But you can also ask for me if you want to. We're easy to find. We're easy to work with. And yet to anybody who’s listening is wondering what API security really means, and a lot of the stuff that we've talked about here today is very, very new, and we're all trying to figure this out together. So always love to talk to folks in the space kind of regardless of what journey you're on.

Erik: Go to Boulder and meet Rob. I love this little message on your website, “Let's hang out.” But Boulder is a beautiful place. I've been stuck in Shanghai which is a great city but it's got 30 million people, so not the most major rich, been stuck here for a couple of years now because COVID. Rob, thanks for coming on, really appreciate the conversation today.

Rob: Thank you. Really, really pleasure to be here with you.

Erik: Thanks for tuning in to another edition of the industrial IoT spotlight. If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Finally, if you have an IoT research, strategy, or training initiative that you'd like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you.