Ep. #114, Automating API Security with Rob Dickinson of Resurface

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Rob Dickinson from Resurface. Rob, hello.

Rob Dickinson: Hi. Thanks so much for having me.

Brian: Yeah. So first question, I'm curious, who are you? What do you do? How did you get here?

Rob: I'm an old school nerd, I'm a CTO and Co-founder at Resurface Labs, which is a company I started in my basement while I was working at Intel. It's great, we've really made a big impact in the API security space and it's really exciting to see that space developing. Yeah, it's always a good time to talk about APIs and API security.

Brian: Yeah, cool. So started in your basement, how long ago did you start Resurface?

Rob: So this is my second observability company. My first company was a web observability company, so we were monitoring website traffic and web based transactions. We ultimately sold that business to Quest Software, we were part of Dell Software, and we saw the writing on the wall. We saw that everything was moving cloud based and moving API first, and so I ended up leaving and I went to Intel for a few years.

But I always thought that there was a huge need around API observability. I originally started working on Resurface as a portfolio project, just to build out my portfolio, and I was curious about doing data capture directly from the APIs instead of using a packet sniffer, and so I had a bit of a thesis there that I was following. Yeah, one thing led to another and here we are.

Brian: Excellent. Yeah, so when i think about API security there's lots that comes to mind so I'm curious, how are you approaching the problem?

Rob: Yeah.

The thing about API security is the starting point is that you want to take standard, well known security practices that have been around for a long time, things like the basic OWASP guidelines and NIST guidelines, making sure that you're doing those things. Then also recognizing that the API landscape does introduce some new requirements and some new threats to be aware of. It is a cultural shift in that way. So it's kind of this great mashup between old and new.

I think what we're doing at Resurface is NIST and OWASP have been talking about sufficient logging and monitoring for a long time, starting with things like intrusion detection systems. What we're doing is we're providing a full audit trail for all the API calls, so it's basically like a surveillance camera for your APIs. But there's a lot of ways, when people talk about API security it's really important to understand what facet of that they're talking about because some folks talk a lot about perimeter security with respect to APIs, which your firewall is doing.

Some people talk about endpoint protection in this context. Some people talk about bot detection, which always makes me grin because if you have an API, everything's a bot. It's all software using your API, it's not like you have clients on web browsers, right? So there's all these different facets of API security, but what we're really focused on is the observability part of that, that if you don't know what your APIs are doing with each and every transaction, then you're going to be vulnerable in all kinds of ways.

Brian: OK. So I skimmed through the landing page and checked it out, I didn't actually use the product. I installed it in my APIs. but I'm curious, is there alerts set up for being able to be notified if something is wrong? Or are you basically combing through and looking for weird instances?

Rob: Yeah, that's exactly right.

We're building a data lake out of all of these API calls, so it's a database and it's searchable. But our goal isn't just to collect all this data, the goal to your point exactly, is to turn this into meaningful signals for the organization. So we're bringing in these API calls, we're continuously scanning for different kinds of threats and failures and quality issues.

Something that's failing now that could be the basis of a future attack, as well as the real, hair-on-fire kind of attacks, and then alerting the organization through the channels where they already want to receive that information. So if you're using Jira, if you're using Ops Genie, PagerDuty, if you're using a SIM, our goal is to put those alerts up into those systems. We talk about Resurface as being a kind of analyst in a box.

One of the problems is that almost everyone that we talk to, they don't have enough help in this area. We're not making enough security analysts to keep up with the current demand, let alone where the demand is going in the future. So having automation and intelligence that helps with that, it helps focus your human assets.

So again, our goal is really to bring those to high level incidents that really the organization can respond to, and then routing it to the right person in the organization.

Brian: OK, yeah, because where I'm sitting right now, i have a company and we have a couple APIs that one is public and one is private, and so far i was able to throw together the earliest version. I had another contributor and now an employee who's put the better version out there, but the conversation around security is something that we haven't really put a lot of thought into.

My employee's definitely put thought into it, I put zero thought into security. I was like, "Let's just make this work, we'll be the first user of the API it works for us." We don't have a ton of users on that API currently, we're the main users. So what is first steps for me to think about using things like Resurface? Or even just starting to consider how to implement this in my API?

Rob: Yeah, so one of the questions I like to ask when people talk about private APIs, not to pick on what you said there, but if that's an API that's running on Azure or Google Cloud or Amazon, there's actually nothing private about that. And so that's the first thing to recognize, these environments are actually incredibly hostile. I'm not saying that to impune those platforms, but basically when you deploy an API on one of these major cloud platforms, and it doesn't matter which one, by the way, you are putting your API into a known IP address range that attackers are continuously scanning.

We've done these experiments ourselves where we put up honeypot applications in the cloud and we use Resurface to record who shows up. This is before you run for your first ad, before anything links to that, you're not driving any traffic to that API, right? You're going to see your first attack in about 30 minutes, and you're going to get about 150 attacks per day against that endpoint, before you've done anything. So we've really shifted from a world where you would expect attacks or expect security problems at a certain level of success or a certain level of notoriety, "Look, people are showing up to hack what we've got. We must be doing something right, people must be really paying attention."

I mean, that was true years ago, right? But now there's a whole cottage industry around scanning these networks, finding vulnerabilities, there's big money in it, so that's part of what's driving all this. I think another thing that goes with that is that for a lot of the folks that we talk to, unless you have a surveillance system for your APIs, you actually don't really know whether you're being attacked or not.

There's kind of a cultural element there too that you have to acknowledge. I mean, APIs are great, I love APIs, but we've actually taken a step back in terms of visibility When we were doing web based systems, anyone in the company, from the CEO on down could go to the website, fill out an order form, make sure that worked, "Did I get the right email back? Was that transaction successful?"

Now that we're API first, well, who in the organization is actually capable of doing that? It's usually just development, there's a tremendous amount of gatekeeping around that, so that's a fundamental part of this that we're really trying to crack, is that a lot of these organizations that we talk to, they know that they have APIs. They don't really know how many they have, they know there's new ones springing up all the time. But they don't really understand what the risks are associated with that yet.

Brian: Yeah. I bring up the private API thing, when I say private, we haven't done anything to lock it down as of yet. We do have plans in moving towards that direction. Private is basically we haven't shared it publicly, which I know doesn't actually quality as being private, because look at the network tab and find out the URL and you're good. But I didn't realise there was a whole cottage industry of folks just really scanning IPs for things that are hosted in the cloud.

I'm not in the business of setting up my own cloud, so yes, we're hosting on a cloud provider, so that is now concerning. It sounds like Resurface is something I should probably be looking into yesterday. But I'm curious of the target market, who is the focus as far as Resurface customers?

Rob: Well, we're really focused on API providers. So folks like yourself that are putting a lot of time and energy into building and operating those digital properties and who are ultimately responsible for the success of those, and making sure that those work properly, that they're not exploited. You're both sides of that coin.

One of the things that's really fun about what we're doing is Resurface is the only truly first party API security system of our kind on the market right now, so when we do our data capture, all of that data is collected in your environment. You're not sending all of your data to Resurface as part of our solution, and that's a big difference, and very counter-intuitive to us.

We started actually as a multi tenant SaaS. That's how anybody in their right mind would start building software today, but we just kept running into folks in financial services, in government, in healthcare, they're our three big verticals, and there's such an emphasis there on data providence and data jurisdictions, and not doing that third party data transfer. So that's actually been a really fun part of this, we can run truly air gapped. basically, wherever you're running your APIs, we'll put the database and the collection agents in that same environment so all of that data stays local.

Brian: OK, yeah. I was going to ask about that because you mentioned in passing the data lake. So I guess as Resurface, do you analyse the data and you send back what it looks like? Or be able to, what I see as Greek, are you translating that to me to say, "OK, this is the English words associated with what's happening"?

Rob: Yeah, we do a lot of high level scoring of the data and high level summaries of the kinds of attacks that are going on. What I always hear for, is I listen for folks that say something like, "I wish we could improve our security practices over time." Or, "I wish i could get my development team to care more about security."

The easiest way to do that is to say, "OK. Well, lets have a feed where those issues show up." So the same way that your QA team reports problems and your development team fixes them, let's do the same thing for production security with respect to these APIs. You really want to look for those API specific signals and keep it on that footing, but in terms of the process that the development team wants to handle or the security team wants to handle, they want to use the process they've always had.

So populate that data up into the tools and the workflows that they're already using, we think is really the best way to go. An example that's like that that I really love, is the folks who are doing vulnerability scanning as part of the CICD pipeline. It's like the same kind of a thing. You can admonish your people to care more about security and, "Hey, you need to run these security scans and that needs to be an extra thing that you're thinking about."

Or you can just integrate it with your pipeline where it's done automatically and you get the reports that you're expected to respond to, and you know what you're getting into. So that's really the processes that we're driving to, just normalizing this domain of API security so that you can tackle it with workflows that look very familiar.

Brian: OK, yeah. A lot of tools are coming out when you talk about attaching to the CICD pipeline where you get notified when the build is run, maybe there's some sort of pattern in your JavaScript or there's some SQL that's exposed or whatever it is for those tools. Are y'all servicing if there's a known... Again, going back to the cottage industries, if there was a known vulnerability in GCP, are you keeping track of that or is this mainly for my tools, my API itself?

Rob: It's really the latter. What we're doing specifically with Resurface is we're runtime security. So that data ends up being very useful for a shift left where you want to then be able to design your APIs to be more resistant to those kinds of attacks or those kinds of failures. But we're really starting with that runtime perspective.

One of the analogies that we use to help people understand this right, because these things are dark, is to use the analogy of running a bank. If you were running a physical bank you would have a security guard at the front door, and that's like your firewall that's going to keep out folks who are obviously there to rob the bank. Hopefully your security guard is keeping them out. But once those people come into the bank, you have an audit trail of what they're actually doing and you have surveillance cameras to tell what they're actually doing. So just like in football, you can go back to the game tape and see what actually happened and see where the areas are where you need to be improving.

It would be a terrible, terrible bank if I walked in the front door and then I could access anybody's bank account and do any kind of transaction that I wanted to. Unfortunately, there's too many APIs that we see that they're implementing basic authentication or they have basic firewall protection, but they don't really have a way to audit each and every transaction. And so that means you don't really understand how you're being attacked, you don't really understand what leaks are happening through those APIs.

But then there's the other side of that which is, when a customer actually experiences a problem, you don't know what happened in that case either. So you're having to interview that angry customer about how things broke and nobody likes to do that, so being able to go back to that objective record, this is what happened in all of those cases. So now we have ways of drilling down to what were the data dependent conditions, the state dependent conditions, did things go wrong? Did things go wrong?

Brian: Yeah. This may be a naive summary, but it sounds like you can prevent people from being on the front page of Hacker News and being sort of like Vulnerability Zero. Like, "Hey, this is So and So, got exposed through their API at runtime. Here's the case study." That's what i want to avoid, and if you can prevent that, all the money to you.

Rob: Yeah. One of the things about this that's really interesting, again just coming back to the cultural things that are shifting as we're moving more towards APIs, a lot of people when they start thinking about API security, they immediately think about perimeter security. "I'm going to need a firewall, I'm going to need a firewall that understands API level traffic better, I'm going to build a better moat around what I'm doing." But the thing that's fascinating about that is that when you interview these companies about why they're doing these API transformations.

The overwhelming reason is to be more open, to be more open to your customers, more open to your suppliers, to your partners, to your integrators, for all kinds of different software now that can be written against your platform. It's all about openness and I think that puts the whole concept of perimeter security in a little bit of a different light. Another way of saying that is it's all about your use case around this too.

If you have an API that's truly only used by your mobile applications, maybe that's a context where you can hold on a little bit to the idea of a secure perimeter and trusted clients. But if you're trying to be like Twilio or SendGrid or one of those folks, those APIs are open to everyone. I think that puts that idea of perimeter security in a completely different light.

Perimeter security is still important, still think about that as part of your balanced security diet here, but that really cant be the only way that you're securing. Unfortunately, we see a little bit too much emphasis on that, that the way to secure your API is you'll have a WAF and the WAF will block the attackers and you'll block them automatically, and that's the way that you're actually going to secure things.

For example, well, what about the attacker who signs up as a paying customer? This is the Peloton attack, and we're starting to see this more and more and more. Your firewall will not prevent those cases from happening, those people are going to breeze right through your firewall so you better have some other layers of protection and observability to trip up those folks.

Brian: Yeah, fascinating. Unfortunately, at the wind down in conversation, heading into picks, But yeah, I definitely could talk about this for a bit more. Mainly because I feel like I might be a good user for this, so I'll be in touch. Actually, I'll have my people reach out to your people. I appreciate that. I want to be able to actually point people to how they can get started or how they can even get connected if they're intrigued by this conversation thus far?

Rob: Yeah, Resurface.io is the website. We offer free trials, we're Docker based and Kubernetes based, so we're very easy to get up and get going. You can start on a laptop if you're a developer, you can start in production if you're an ops person, really any way that you want to go with that. We also offer services and white glove installations for folks that want to do that. All of our documentation is available to the public at Resurface.io/docs, so if you want to go in and see what the process looks like and what you're in for, we've got it all laid out there and try to make it as easy as we can.

Brian: Awesome, appreciate that. thanks, Rob. So I want to transition us to picks, these are Jam picks, things that we're jamming on, can be music, food, technology related. everything is relevant. If you don't mind, I'll go first. My first pick is actually Dall-E 2, it's actually getting opened up for anybody to sign up now. It was on a waiting list. Are you familiar with Dall-E 2 and this whole Open AI type of, what do you call it? Machine learning, automation, generative images?

I love the progress that's been made, and it seems like in the last year I think it's really picked up a lot of speed. Maybe because compute is getting cheaper because of the... I don't know, I have no idea what's going on right now, but it seems like a lot of VCs are pointed towards this. I know Nat Friedman has an automation VC fund that this got spun up, so I think everyone is moving from Web 3.0 to now pointing to how can we do generative images and Stable Diffusion type things?

I've been using it for generating avatars for some of my accounts. I've been using the same avatar on Twitter since i think my junior year of college, I've just never changed it. So I have that same avatar everywhere, but in some places I'm like, "I'm going to try a different image." So I've been generating Dall-E paintings because Dall-E 2, Dali, Salvador Dali, but just random stuff of melting pizza and stuff like that.

Yeah, I'm just generating art images and seeing how I can expand my scope. Actually, it would be fun to print these and put them on behind me. I don't know who owns the rights, if i can print those and put them on my wall. But I've actually enjoyed what Dall-E has been producing. If anybody is interested in a use case I can create a Discord where we can just throw our art pieces up.

Rob: Yeah, I think the AI generative art movement is just fascinating, what's going on there right now. It's really, really interesting.

Brian: Yeah. So I actually ran into a founder here, out in San Francisco at happy hour drinks for YC people. anyway, besides the point. His actual product which I already forgot the name of, he was generating similar to the generative art but for games, so if you're playing Grand Theft Auto and you're like, "Generate an NPC." So it's an NPC generator on the fly and you type in, "Man holding pizza, drinking coffee."

And he'll generate a man holding a pizza, drinking coffee that you can place in the game. I thought it was actually a really good concept, because these world building, expansive universe, imagine you're like, "Hey, it would be cool if I could walk into this tavern and this person is doing this thing or playing this song or whatever." Yeah, it's a good use case. It sounds extremely expensive, but that's their company and that's what they're working on.

Rob: That's awesome.

Brian: Cool. Do you have any picks for us?

Rob: One thing that I've been doing during the pandemic is I picked up the drums, and so one of the things that I've actually been playing with is, there's a couple now, AI powered solutions out there for removing drum tracks from music that you like or isolating out. Which is such a fascinating use of this, traditionally you do that just with filtering specific areas of the spectrum to trim those things out, but they're really getting into much more sophisticated ways of splitting those audio tracks.

Yeah, then just the whole idea. So I'm doing electronic drums of course, because I have a family and they would never put up with that. So also the electronic music control side of that and the MIDI signalling and all of that. It's so amazing what you can do now for very, very little money, with just a standard laptop and a cheap kit. So yeah, that's been super fun.

Brian: That's pretty cool. Yeah, I learned drums in college, actually, and it was mainly because I was playing music and I got Garage Band, and I could play all the other instruments and drums was something I wanted to add to that. But college me would be super, super excited about the fact that I could remove drums from tracks and play over them to perfection, which I'm a decent drummer, I'm not amazing.

Rob: Yeah, I'm terrible so it's all good.

Brian: Well, hats off to you for picking up a new skill during the pandemic. Mine was bread making, so I did that pretty heavily, and I guess I did YouTube as well as another pandemic project, which I have put on the shelf. I switched over to my company's YouTube and that's been going well so already.

Rob: Nice.

Brian: Well, Rob, appreciate you coming on, talking about Resurface. I'm very intrigued, lots of stuff for me to think about, but I'm thinking everyone who's listening, same thing. So definitely reach out, Resurface.io. And listeners, keep spreading the Jam.