Press Release
Application development is moving from a web-centric world to an API-centric world. If you’re wondering what that looks like, what the security implications are and what an API is, you’re in the right place.
There is no shortage of new application security strategies to familiarize ourselves with as cybersecurity adapts to changing times.
That’s why I invited Rob Dickinson, CTO at Resurface Labs, to explain APIs, continuous API operation observability, and prevalent challenges in the API economy.
Join us as we discuss:
- Moving from a web-centric to an API-centric world
- The value of opbersing API operation in production environmentÂ
- Tackling security issues in the API economy
To hear this episode, and many more like it, you can subscribe to The Virtual CISO Podcast here.
If you don’t use Apple Podcasts, you can find all our episodes here.
Listening on a desktop & can’t see the links? Just search for The Virtual CISO Podcast in your favorite podcast player
Announcer (00:06):
You’re listening to the Virtual CISO Podcast, a frank discussion providing the best information security advice and insights for security, IT and business leaders. If you’re looking for no BS answers to your biggest security questions or simply want to stay informed and proactive, welcome to the show.
John Verry (00:27):
Hey there, and welcome to yet another episode of the Virtual CISO Podcast with you as always, John Verry, your host. And with me today, Rob Dickinson. Hey, Rob.
Rob Dickinson (00:37):
Hi. Thanks so much for having me.
John Verry (00:39):
Yeah. Looking forward to the conversation, man. So I always like to start off easy. Tell us a little bit about who you are and what is it that you do every day.
Rob Dickinson (00:46):
So I’m a data head. I’m a data nerd. I’m a data engineer. My day job right now is I’m CTO at Resurface Labs. We’re an API security company. And so we’re dealing with a lot of API data at scale, so right in my wheelhouse. This is my second observability company. My previous company, we were very web-centric and we sold that business to Quest Software. And we were part of Dell Software. We really saw the writing on the wall that we were moving from a web-centric world to an API-centric world. And so Resurface is really the reboot of all of our ideas around that.
John Verry (01:24):
Cool. That’s an interesting way you said that that I’m going to want to drill down on, because I have a hard time when I’m chatting with clients to talk about new architectures versus old architectures, API-centric architectures and how you refer them. Sometimes I’ll say like more single webpage application-oriented, and folks kind of get that. So I like the way that you said web versus API. So I’m going to drill down on that. Before we get to that though, I always ask. What’s your drink of choice?
Rob Dickinson (01:49):
Chai tea.
John Verry (01:50):
Chai tea. Really? You may be the first person who gave me chai tea.
Rob Dickinson (01:56):
Really?
John Verry (01:56):
Yeah. I think so. Well, chai has such an interesting flavor profile. I mean, some of them I can actually drink and enjoy and some of them have some flavors that I just find a little bit challenging. I’m drinking a green tea myself right about now. So I do enjoy a good cup of tea.
Rob Dickinson (02:12):
So I just added myself as some kind of crazy hippie or something, I guess.
John Verry (02:17):
Well, I mean, you started with the fact that you were a data head, now you went chai tea. I’m a little worried this is starting to go off the rail so I think we’re starting to lose people. So bring it back in. Bring it back in center. You could have said bourbon. We would’ve been fine. Everybody knows to say bourbon when they come on.
All right. So thanks for coming on today. I think this topic of API’s really important. So from a practitioner’s perspective, I think we’ve reached a point where application security is starting to get the attention it deserves, which is remarkable that it took this long. However, and this is to what you were talking about before, just as this is all happening, application architectures have made a significant change, right? They’ve gone from that older web-based three-tier. I don’t know the right way to say it, because I’m not a data head the way that you are. But we went from this older model to this new API-centric model. A lot of times I’ll use the term single-page architecture, single-page application because folks kind of understand inherently that’s backed by a bunch of endpoints.
So I think in many instances now, application security and API security have become effectively synonymous. So let’s just make sure though we’re all on the same page. Can you define what an API is, and if you’d be so kind, is to talk about that transition that happened so that you frame APIs in the context of what came before it as well?
Rob Dickinson (03:35):
Yeah, it’s absolutely the right place to start because for a lot of people they hear the term API, they go to Wikipedia, they see what that says. Application programming interface. Great. What does that mean? What is that telling me? So let me start with a non-technical answer first. So what APIs are is the culmination of what we’ve been working towards in automating our business practices for the last 50 years or so. So if you think about buying stock for example, buying securities, in the ’80s, in the ’90s, you would’ve called your stock broker with your phone you may have sent a fax, right? So there’s kind of a transient and a durable version of communicating with your stock broker. You might also send a letter, right? You move forward to web-centric, you’re using web browsers, you’re using email. So now I’m looking up the quotes myself, I’m filling out a form on my stock platform and I’m submitting my order without ever picking up the phone. And maybe I get an email confirmation of that transaction.
Now fast forward to, we have applications talking to other applications across the internet. But really when you step back and you think about like what is an API, it’s really the modern version of calling your stock broker on the phone, which some of us are actually old enough to have done, right? But that’s what it is. It’s how does that technology show up in your everyday life in terms of your business, your organization, interacting with the other organizations in your sphere, your suppliers, your customers, your supply chain, everything that goes through that. What you used to do over phone or fax or through websites or through emails is now turning into I’m using one kind of app, it’s talking to another kind of app, or many different kinds of apps all at the same time. And so really from a non-technical perspective, that’s the continuum that it really fits into.
John Verry (05:45):
Yeah. Would it be fair to say that it’s a transaction of some sort, right? It’s something taking an action. It might be you saying to your Alexa device, “Hey, Alexa, play X on Spotify,” right? And the Alexa cloud is going to make an API call out to the Spotify cloud, pass at the right parameters. “Hey, play this song.” It knows how to communicate to it and then it’s going to get that response back and forward that response thus. I mean, effectively, right? I mean, an API is a way of affecting something, right? Making something happen, making a measurement, making a change, issuing an order. Doing something, right?
Rob Dickinson (06:25):
Yes. So for the people that already know what an API is, if you’re coming at this from a development perspective or a more technical perspective, the thing to clarify here is that when we’re talking about the API economy or we’re talking about API security, we’re talking about APIs calling other interfaces across a network. So there are lots of other kinds of APIs as it turns out. There’s things like Java low level collections APIs and things that the STL gives you in C++. The Python language is a kind of an API. But that’s not what we’re talking about here. And those truly are application programming interfaces.
But the kinds of APIs that we’re talking about from a business perspective, from an API security perspective, is exactly what you said. It’s just one piece of software calling another piece of software over the internet. It’s not web servers and web browsers. We’ve let go of that and we’ve said it’s a generic kind of client, it’s a generic kind of server. And just like you said, the API call is the transaction. It’s the handshake between those systems that says, “Please do this bit of work for me.” And then here’s the result that comes back from that.
John Verry (07:42):
So a question for you. So going back to that transition from that web server, web-centric model to the new model. When I’m chatting with somebody, what’s the proper way… Or if someone who’s a CXO who’s not in the technical world is chatting with their technical people and they want to understand if we’re using this new modern architecture, what’s the right way to say that? Like I said, I’ve fallen back on that single-page architecture. What’s the right way to ask somebody about the architecture of an application and find out whether or not it’s skinny front end with all of the processing happening at these APIs where some people refer them as endpoints, right?
Rob Dickinson (08:22):
Well, I think the short answer which you might not like is, yeah, it’s gotten really hard.
John Verry (08:28):
Rob, you’re telling me I’m not a complete idiot. Thank you. You’re recovering. The chai thing I’m starting to forgive you for.
Rob Dickinson (08:34):
So having gone on this journey, when we used to talk about web specific architectures, single-page architectures, three-tier architectures, those were fairly specific blueprints about what that meant and about what those zones of responsibility would be and what technologies would be involved in different parts of that stack, right? A lot of that still applies. But the thing that shifted I think the most, when you think about going from web-first to API-first is think about your classical three-tier architecture, which is client, server, database, right? But in that architecture, that was always a trusted client. That was your client. That was something that from the outside perspective, the application was that client. You weren’t connecting directly to the server side middleware. You weren’t connecting directly to the database. So the way that you interacted with that application was through that trusted client that the vendor provided to you. And that’s a website model, right? I’m going to stand up a website. It does all the things. I’m going to deliver that to you. You’re going to use it.
But as soon as you go from something like that to something like Twilio for example, that’s 100% API oriented. Well, Twilio has no trusted client. You can call Twilio from any programming language, from any kind of application. So in doing so, Twilio is open to all kinds of customers that they’re not having to monetize that third part of the tier of the architecture directly, right? You’re skipping down a layer. But you’re also losing a whole lot of control because there isn’t really that concept of a guaranteed client or a trusted client that you actually have that direct control over. Instead, you’re saying, “Here’s this REST endpoint. Here’s this GraphQL endpoint. As long as you do the right thing, we’ll try to do the right thing. And it’s game on.” So we inherit a lot of those concepts from single-page architectures or from three-tier kind of thinking, but it’s a new spin on kind of who owns and what parts are easily replaceable.
John Verry (11:12):
Right. Your timing was perfect. And that you began to kind of delve into whether or not there were security differences between the different models, right? And do in the good old days, which is just five years ago or so, right? When people first started really doing a lot of application testing, we were looking at OWASP Top 10 attacks, right? Now we’ve kind of migrated to OWASP ASVS and more robust models. But fundamentally, a lot of people still use that OWASP Top 10 as a good general framework. You just mentioned the fact that we no longer have this trusted client. So are the attack vectors for APIs the same, or do APIs bring additional attack vectors, right? And then I would extend that and ask, do APIs increase the importance of having a strong SDLC?
Rob Dickinson (12:01):
Yeah. So I would say that APIs inherit the same security issues that have plagued web-based systems forever, and then add some more on top of that. So remember the scene and the Matrix where they’re attacking the secure facility based on that it has to follow the rules of a building? It’s the same kind of thing here. The way that you’re API is actually implemented, it’s implemented on top of a web-based microservice. That microservice is basically a little web server that’s running your application. So all of those traditional vectors that you would use to attack a web application apply to attacking that microservice container. So that’s all the code injection kinds of things, protocol manipulations, all those kinds of things. And then you add on top of that API level attacks that are really user impersonation kind of attacks user right escalations kind of attacks that are very much at the application level.
Take GraphQL as an extreme example of that, right? I can pass in a GraphQL query that itself is so intensive to process that it takes down the endpoint. I mean, that is obviously highly specific to a GraphQL type of API. But you can also typically attack a GraphQL API through method injection, broken authentication. All those kinds of things still apply just like the web applications always do.
And I think to your question about the SDLC, I think part of this is acknowledging that the SDLC extends into production. So the SDLC doesn’t just stop when things get pushed into production, but you actually need better feedback loops to say, “This is what’s actually happening in production. Let’s feed this back into the design process.” When you think about it, I mean, one of the things that scares me a little about this API landscape is we’ve taken a step back in visibility. If you’re web-centric and your web-first, well, anybody in your company can go to your website and see what’s going on with it. You go to something that’s APIs, now the development organization owns that, there’s more gate keeping around it. But it’s fundamentally harder to just even understand what’s there, right? So even that presents a problem. So what you see a lot is cases where those APIs, they work on the developer’s machines, they work in these sanitized test environments, QA environments, staging environments, then they get out into production. And it’s a very, very different picture.
John Verry (14:55):
Isn’t there a little bit more… Like if you use the concept of attack surface management, I mean, one of the things that we had when we had the traditional older applications is that was sort of like a gated community, right? Because a limited number of people had the ability to log into the front end, that meant that we had less exposure. APIs by their nature intended to be interacted with in a diversity of ways, whether it’s a mobile app, whether it’s a web app, whether it’s a direct call. And we end up in the situation where those same functional units, those same pieces of code, if you will, that used to be protected by this gated community no longer are, right? So inherently, even if the vulnerabilities haven’t potentially changed, the threat actors, the threat agents have, right? Because there’s so much greater exposure.
Rob Dickinson (15:47):
Absolutely. It’s always been core security dogma just as you said to reduce your attack surface as much as humanly possible and find creative ways to do that. But let’s face it, the move towards microservices, the moves towards APIs is completely counter to that idea. It’s exactly the opposite of that. It’s saying, “We’re going to open this up to anybody that wants to use it without pre-qualification.” And that sounds scary. And it really is.
John Verry (16:29):
It absolutely is. I think it speaks to why you guys are doing what you are doing at Resurface. Now, you use the term observability. I guess what you meant by that earlier is the fact that you’ve got… Like in the old days, people were looking at their Apache logs, right? They were looking at their BA logic logs to figure out what was going on inside of the application, right? Now, as we’ve moved to this API-centric approach, we no longer have those sources of data, right? So you guys have developed what you guys are referring to as continuous API scanning. I’m guessing that’s the observability term that you used. To me, when I was researching your company, I kind of looked at it and said, “Hey, this feels like it’s Wireshark for APIs.” Is that a fair analogy? And can you explain a little bit about how continuous API scanning works?
Rob Dickinson (17:17):
Yeah, absolutely. So I love that analogy. I’m a huge Wireshark fan myself and have used that for many years. But we wanted to go beyond that. So Wireshark, as we know, is a really good tool for capturing HTTP traffic and helping you decode that, kind of show that at the protocol level, help you understand what that was that you’re looking at in terms of that transaction that’s going over the wire, right? But with all respect to that project, it’s really a protocol analyzer. It’s at the protocol level. It’s also tends to be for very, very limited amounts of data. And what we’re doing with Resurface is we have that ability that Wireshark has to gather data, index it, help you understand what you’re looking at, but we go beyond that in terms of we have a data lake.
So you can think of Resurface as a big data version of Wireshark. We’re not just collecting the transactions that you’re doing for testing. We’re collecting all the transactions that happen in the production environment, creating a database, searchable database out of all of that data. And then the continuous scanning is basically about automatically searching that codex of information for known problems that the organization should be paying attention to and raising the red flag and driving the automation flows then around those things. So it’s kind of like if you took Wireshark and-
John Verry (18:50):
And SIEM. It almost sounds a little SIEM is, right? You know, S-I-E-M, right? I mean you’re taking real time data of what’s occurring in the API. You’re keeping a record of that. And I’m assuming that you’ve got some mechanism to apply logic correlation rules, things of that nature against that to say, “What I’m seeing here looks like something that I’ve never seen before. Or what I’m seeing here looks like an attack. You should be aware of that.” You’re raising that to the individuals and then they’re going to, hopefully, take intelligent actions based on that observability that you provided.
Rob Dickinson (19:22):
Exactly. One thing that’s really unique about Resurface and partly why I do love the analogy with Wireshark is, Wireshark is a piece of software that you control. It’s a piece of software that you install, you run on your own equipment, you control the data going in and out of it. That’s also true with Resurface. So we are the only first party API security vendor that’s out there right now. We only do first party. We are not a SAS.
John Verry (19:51):
Real quick, I just to make sure we’re on the same page. When you say first party, you mean that you are installing your software in my environment as the customer?
Rob Dickinson (19:58):
Correct. And so basically if you’re running on AWS, you just install Resurface on AWS alongside the APIs that you’re running there. We make that super easy. We do all the automation through Kubernetes and Helm. So it’s very, very easy to do. But we’re the only vendor that operates in that fashion. You’re never sending your data to Resurface so that we can analyze it and keeping a copy of that data. Having to go through that third party data transfer is a huge no-no for a lot of the folks that we work with.
John Verry (20:32):
Yeah. Well, that’s also probably good for you guys too, because who knows what kind of data’s coming back in those API calls? If it’s HL7 integration, you’re going to have medical information. You don’t have to deal with all of the data privacy, data security issues, right? They don’t have to trust you. They’re responsible for their own trust, which they already had to trust anyway. So a question for you. Like a SIEM you have the concept of signatures or the concept of these attack profiles. So I’m assuming that you have some ability to learn from the masses and provide them content that comes into their environment to help them pick up on these patterns or attacks or best practices?
Rob Dickinson (21:12):
Yeah. We’re doing exactly that. We have a library of signatures that we provide out of the box, both as kind of to help drive a minimum standard of care, but also to demonstrate what the platform can do and what we’re capable of. One thing that we hear a lot is the OWASP rules, I mean, that’s a great place to start, but I know what my API is supposed to be doing. So can I enforce more specific policies about what I know that my clients should be doing? And so that ability to create bespoke signatures or custom signatures without any kind of custom programming and without having to go back to Resurface as a vendor, but just being able to do that on the fly is something that we’ve put a lot of time and energy into optimizing. So we’re providing both of those, right? We’re providing, here’s the standard set that most folks are running and we’re improving that and extending that all the time, but then we make it very easy to supplement that with your own policies.
John Verry (22:16):
Okay. So like as an example when you say a bespoke rule of that nature, let’s say have an API function that returns data on a request. I might say this particular API should never return anything more than these three responses or this quantity of data to ensure that if somebody was to send let’s say an overly permissive, back in the old days, return a star dot, and not that people are falling for that anymore, but that would be an example of where a bespoke rule that would be very, very specific to the actual function that an API is actually executing, correct?
Rob Dickinson (22:51):
Exactly. And let’s think about what the alternative would be. So with Resurface, we’re doing that kind of analysis completely asynchronously to the application, completely asynchronously to the API and the calls that it’s making, right? So if I only had perimeter security available to me, I would have to, what you just said about about limiting the data inputs and data outputs, I would have to express that as a rule on the firewall and I would pay a performance penalty for doing that. The more of those rules I add, the more processing my firewall has to do, the slower it gets, right?
So everybody who’s using a WAF, which is pretty much everybody that we talk to, it’s not a question of whether you’re using a WAF or not. The question is, how much of a performance penalty are you willing to pay on the WAF? What kinds of inspections are you really looking to do on the WAF? You need that immediate level of interception. Shut that session off, versus how much of that can you do asynchronously where you’re really driving a workflow that’s more about hardening the API or improving the quality of the system rather than just about attenuating the user session. So we want to open up that whole second swim lane there around being able to do all different kinds of both out of the box and custom inspections on this traffic without introducing any performance penalty or any latency on the transactions themselves.
John Verry (24:26):
That makes sense. So that’s where you use that term observability versus, let’s say enforcement, right? So just to be clear, you’re not “in line,” you’re not intrusion protection of any sort, you’re not taking any action dynamically. You are providing critical information that developers and folks that are a part of the application stack can use to optimize their API security?
Rob Dickinson (24:53):
That’s exactly right. We are a surveillance camera. So we can’t interfere with the burglars, but we can watch the burglars and we can bring the alarm bell.
John Verry (25:03):
Good. That’s actually a really good analogy. And then I was going to ask you about the WAF. So you look at your technologies in WAF as being complimentary, not competitive technologies. While there might be some places where both can do this sort of the same thing, you can transport plywood on top of a VW Beetle like you can in a pickup truck, but each of those two vehicles have their optimized use case. You guys would be the same.
Rob Dickinson (25:35):
Yeah, that’s absolutely right. I see us as highly complimentary, especially when it comes to the data lake that we’re providing and what that means in terms of zero day analysis whether that’s for quality or for security. There’s no WAF that I’m aware of that will tell you what happened yesterday or last week or the week before that. What we’re doing… So again, kind of going back to the idea of having a surveillance camera, we’ll give you 30 days of footage. We’ll give you 30 days that you can go back through that audit trail and ask any kind of question. And that’s where it’s not just predefined signatures like an anti-virus scanner would be for example, or something more in that mode.
So for example, when Log4j, Log4Shell came out, we could just query the database and say, “Where have those JNDI URLs been showing up?” and without having any information in advance about what it is that we’re supposed to be looking for, go back through the last 30 days or 60 days of history. And now you can say, “Have we been attacked with Log4Shell, what systems have been attacked? Let’s patch those first.” Compare that with, “Oh my God half of our systems could be vulnerable to this. We need to take some number of months to patch everything.” If you don’t have that ability, if you don’t have that observability in terms of knowing how your APIs are actually being used, you’re guessing in a lot of those cases. And that’s not bad. I mean, if that’s as good as you can do, then sometimes you have to guess. But really being able to take more of a data centric approach, more of an empirical approach and having the data to do that we think is the better way.
John Verry (27:23):
So interesting question. We know that, like you mentioned, you pay by the rule, if you will, on a WAF. The observability is going to give me insight into perhaps misbehaving or not optimally behaving APIs. So could there be a financial benefit to implementing what you’re doing in terms of reducing my computational load at the WAF, preventing APIs that are effectively computationally enhanced, financially expensive that operate that may not need to be running?
Rob Dickinson (27:55):
I would say yes to all of that. It goes even further. When you think about these API calls themselves representing transactions, well, what is the record of that transaction? Did that transaction complete successfully? If that transaction didn’t complete successfully, was there revenue lost? So a lot of the use cases that we drive towards, I mean, yes, we’re a security company and so we’re obsessed with security, but a lot of security problems are also quality problems. And a lot of those quality problems have negative customer outcomes or lost revenue attached to them.
Where this becomes a security problem, I think first and foremost is that one thing that’s horrible about the API economy is the API providers that we talk to, their attackers actually dominate their user traffic. It’s not an attacker showing up every once in a while. Their attackers are actually in the majority. So you can’t statistically baseline these people out very well. All those traditional techniques don’t work. And for me as a developer myself, that means it puts this horrible pall over what I thought I knew about things like response codes and errors and things like that. So that means every time in my log if I have a 500 error that popped up, well, now I’ve got like a 50/50 chance. Either that was a real user that was impacted and there might have been revenue loss associated with that, or it was an attacker doing something stupid and trying to crack in.
If I can’t answer that question right away, I don’t even know what I’m looking at when I see this stuff in my logs. So I think, unfortunately, these environments that we’re operating now, they are so hostile and so different than the web systems that we used to have back in the day that you really can’t ignore that security aspect to it. So just taking a pure development observability perspective, what code is being executed and was that code good enough? You really have to understand the intent of the user to really turn that into something actionable for the organization in these kinds of environments.
John Verry (30:22):
So that was really interesting to me because increasingly with more forward thinking CIOs, CSOs, CXOs, we see a recognition that it would be better to think about information security as not only value preservation, but value creation. And really, so that idea of information security solving a business problem is a great example of where information security can create value for your organization. It’s not just about mitigating risk, right? It’s about creating value for the organization. So if an observability tool gives me the ability to shed some of that malicious traffic in such a way that I have greater effectiveness and efficiency of my team, my development team, putting their efforts into the right areas to advance the company, if it’s reducing the number of Lambda function calls that I’m paying for. So I actually think what you said was really germane to the conversations that I think we need to be having as an information security community these days.
Rob Dickinson (31:22):
Yeah. And remember that point that I made earlier about extending the software development life cycle. So if your developers don’t know what that malicious traffic looks like, how are they designing the systems to be resilient to that, right? And what I see traditionally is the ops group and the security group owns the production systems. And of course, to minimize your surface area, you want to limit the number of people that have access to those systems. So what does that translate to? Well, that translates to development sees the code on their machine, in their sanitized test environments, in their QA environments and then when it goes into ops, it goes to somebody else.
So as a designer, as a developer, you don’t have those feedback loops technically. So I love when people say like, “Well, there wouldn’t be security problems if the systems were designed right to begin with. It’s like, yes, but part of that is acknowledging that these systems are being designed in to clean a room. It’s not just that the designers don’t know what they’re doing and if they could only do better, it’s the environment in which those systems are being created.
John Verry (32:33):
Right. I mean, what you’re almost saying is our staging environments should be on the internet next to our production environments, because otherwise you have no way of really… Like you said, it’s almost like that Chaos Monkey concept, right? Unless you’re actually going to interject really like bad crap into that part of the process, the likelihood of you being prepared for the bad crap to happen when it does happen is pretty damn low, right? Because you can’t possibly mirror what’s going to happen in the real world. That’s really interesting. I never really thought about that specifically as being… Because that’s where if you go back to the old model, those models were kind of alike, right? Because there was some type of a gated… You were in gated community and you moved to another gated community. Our problem is that we’re in a gated community during the development stage and QA processes, but then we’re moving to a non-gated community for production. Interesting.
Rob Dickinson (33:28):
Yeah. I love that way of putting it.
John Verry (33:30):
Yeah. That’s really interesting. Well, we beat this up pretty… Well, I got one last question that’s not on my list, but I’m thinking of this now. What particular use cases verticals are you seeing the most uptake? Where are people most excited about in what you guys are doing? When we’re chatting with people, where are we going to see people… If somebody’s talking about their APIs and some of the challenges they’re having, what’s going to resonate with them? Who are the people that this resonates with?
Rob Dickinson (34:01):
So a lot of the folks that we’re talking to are financial services, crypto, even if they’re not directly monetary transactions but folks who really see their APIs being their front lines of their business and that really being their interface to the world. And in a way, I mean, what Resurface is doing, we’re doing the API-centric version of an idea that’s been around for a long, long time. When you used to call your stock broker and buy stock over the phone, there were laws saying that phone call had to be recorded and kept as a record of that transaction. Same thing for web. So we’re moving in that direction with APIs in general. So really taking API calls to that point where they can really be considered durable business transactions. And that’s really the common thread of everybody that we’re working with.
And again, in the context where you want to own that data, you don’t want to have to work with a third party vendor and have that third party handoff. You want that data to be consumed in the jurisdiction that it was generated in. We were going through all of this as GDPR and CCPA came online and all these things. And so we put a lot of time into thinking about how to rationalize all those requirements. But we see ourselves as really being the easy button for what OWASP has talked about for a long time, sufficient logging and monitoring of your APIs that goes beyond just intrusion detection, but is actually about auditing the activity that’s there. That’s not a new idea. We’re just trying to deliver that without an army of Hadoop engineers and all the people that it would take to do something like this with the other technologies that are out there now.
John Verry (35:57):
So effectively, any API-centric company, right? Any SAS, anyone whose company relies on APIs, right? Their business critical, that observability would benefit them. And then one last question. So I see the use case of this being deployed operationally and being this record like you talked about of what’s going on in my environment, the ability for me to continuously improve my API security by using your tools, do you have a model for folks like us that when we’re going in at the front end, when we go in to do an engagement with our clients, we’re doing let’s say an OWASP ASVS level to assessment or something of that nature, but is there a model by which somebody can use your tool during an assessment to get a sense of what’s going on in the APIs, right? Do you have a business model for that? And if not, it might be an interesting idea for folks like us because I could see value to us using that during an assessment of a client.
Rob Dickinson (36:56):
Yeah. I’d love to go into that deeper obviously, but I think we do, how we think about our relationship with our customer is, we want to be an analyst in a box. So we want to be able to cut through all that noise. For us, we see our mission is not just gathering this data, but helping people get to the place where those insights and those improvements can happen quickly. And everyone that we talk to, they don’t have enough help in this area. We’re not making enough security analysts, SREs, advanced QA and escalations people. We’re just not making enough of them even to satisfy the current demand, let alone where the demand is going to go in the future. So we always come back to that thinking about how we’re structuring what we’re doing and what our workflows.
So for example, we don’t expect that people log in to Resurface and stare at our data. That’s a job for someone to have to do. Our experience for our customers is there’s a JIRA ticket that shows up because your application is breaking and that was automatically resurfaced to you. You didn’t actually have a human analyst that generated that ticket. But that’s how we see the future of continuous intelligence and really fitting into the workflows that the people already have. Because at the end of the day, there’s a lot of important human operators in these systems. So you kind of want to find that balance point between how to accelerate what they’re doing, using the tools that they already know and love and helping with the observability part of that and cutting out the guesswork.
John Verry (38:43):
Yeah. And one thing which we haven’t even talked about, which we won’t but it would also be interesting is how much of the log data that you’re generating would be important to automated compliance. Which is interesting because so many of our clients now, the conversation is not about just implementing controls, but how do we operationalize them in such a way that they do the types of things you’re talking about. They automatically generate the tickets that need to be acted on, but they’re also generating the audit evidence so that way that doesn’t have to be done manually, right? And someone knows when a process… Because one of the things that Agile has screwed up for all of us in continuous development is that what used to be a, “Oh, four times a year. We make a push four times a year. I got to be able to demonstrate that the application went through these X security gates.” Now half of those X security gates are now X times three. And now that’s happening not once a quarter, it’s happening once a day or twice a day in many instances.
So being able to automate that compliance so that people don’t have to gather that. So I’d be curious as to one thing to look at at some point is what you’ve got in those logs and how much of that might be valuable from that perspective as well.
Rob Dickinson (39:54):
Yeah, that sounds great.
John Verry (39:55):
Cool. So we beat this up pretty good. And I thought you did a great job of helping folks understand what the value prop here is and how important these are. Anything we miss?
Rob Dickinson (40:04):
No, I don’t think so. It’s a good set of questions.
John Verry (40:07):
Are you saying I get a gold star from my performance today? I think that’s what you’re saying, Rob.
Rob Dickinson (40:10):
Yeah. I think it is five stars. Yeah, five stars.
John Verry (40:14):
I love getting those gold stars. You just made me think of a… You’re a geek, right? So you might have watched this show, Community?
Rob Dickinson (40:14):
MeowMeowBeenz. Exactly.
John Verry (40:22):
MeowMeowBeenz? So you’re basically giving me five MeowMeowBeenz? That was such a great episode. And we just lost a whole bunch of people. But if you’ve never watched the TV show Community, you don’t know what… Dan Harmon is a brilliant guy. And of course I love Rick and Morty as well, right? Because anything Dan does is great.
All right. So hopefully you prepared. Give me a fictional character, a real world person you think would make an amazing or horrible CISO. And why?
Rob Dickinson (40:49):
Gosh. So when people say CISO, I think people think of like a Sherlock Holmes type, but I would say probably horrible CISO, like I wouldn’t want to work for that guy. Yeah, probably really talented, right? But nah. Nah. I wouldn’t want to be Watson in that scenario. So I’d have to go Carl Sagan on this one because Carl was… I mean, he was such an amazing scientist and amazing technologist, but he also had the ability to think organizationally and think beyond himself and about the storytelling that goes with reaching that larger audience and just how to get people to care about something that seems arcane to a lot of folks, unless you’re really into astronomy. But anyway, Carl’s a personal hero of mine. So
John Verry (41:42):
Carl Sagan? He’s like the yesteryears version of… Who is the black gentleman who’s also the astronomy guy that’s really popular right now? You know who I’m talking about,
Rob Dickinson (41:52):
Neil Degrasse Tyson.
John Verry (41:53):
Ah, I’m drawing a blank on it. I can see his face. He’s great.
Rob Dickinson (41:56):
Right. Who is Sagan’s protege?
John Verry (41:58):
Yeah. Neil Degrasse Tyson.
Rob Dickinson (41:59):
So yeah.
John Verry (42:02):
That’s what I’m saying. So for anyone who doesn’t recognize the Sagan reference, think of Neil Degrasse Tyson, like who he would’ve been… How long ago was Sagan? 50 years ago?
Rob Dickinson (42:13):
Oh gosh. Am I that old? Not quite that long. Yeah, it’s been a while.
John Verry (42:17):
Okay. 30 years ago? 30? Yeah. Because listen, I remember Carl Sagan too. I thought you went with the Watson. I thought you were going to say and go do something with Sherlock Holmes with something with the secondhand smoke, but you didn’t go there. So I was surprised. I was surprised by that. All right. So if folks want to get in contact with you guys and find out what you’re doing over there, what would be the right way to do that?
Rob Dickinson (42:37):
Yeah, it’d be easy. Available by email [email protected] and also on Twitter at the handle @robfromboulder.
John Verry (42:46):
Excellent. Thanks, man. This was fun. I really appreciate it.
Rob Dickinson (42:49):
Thanks so much for having me on. Anytime.
Announcer (42:53):
You’ve been listening to the Virtual CISO Podcast. As you probably figured out, we really enjoy information security. So if there’s a question we haven’t yet answered or you need some help, you can reach us at [email protected]. To ensure you never miss an episode, subscribe to the show in your favorite podcast player. Until next time, let’s be careful out there.
