About The Guest: Jeremy Snyder
Jeremy Snyder is the Founder and CEO of FireTail.io., a company that offers simple, yet effective API security.
Before that, Jeremy’s long list of accomplishments in the cloud industry includes being one of the earliest people at Amazon Web Services (AWS) in ASEAN.
He has always been an IT practitioner and counts among his experience running data centers and back-end systems for several SaaS and video game companies in the early part of his career.
If you found him familiar, you are not wrong. He helps the Ask A CISO podcast interview U.S.-based guests, including luminaries like Chuck Brooks, Perry Carpenter, Sounil Yu, and Mikko Hypponen.
About The Host: Paul Hadjy
Paul Hadjy is co-founder and CEO of Horangi Cyber Security.
Paul leads a team of cybersecurity specialists who create software to solve challenging cybersecurity problems. Horangi brings world-class solutions to provide clients in the Asian market with the right, actionable data to make critical cybersecurity decisions.
Prior to Horangi, Paul worked at Palantir Technologies, where he was instrumental in expanding Palantir’s footprint in the Asia Pacific.
He worked across Singapore, Korea, and New Zealand to build Palantir's business in both the commercial and government space and grow its regional teams.
He has over a decade of experience and expertise in Anti-Money Laundering, Insider Threats, Cyber Security, Government, and Commercial Banking.
Transcript
Raphael
Hi everyone.
Welcome to another episode of the Ask A CISO Podcast, powered by Horangi. I'm Raphael Peryet, the Vice President of Product here at Horangi, and I'll be sitting in for Paul, our CEO.
Before I introduce our guest, please don't forget to like and subscribe or follow us on YouTube, Spotify, and Apple Podcasts, and help us grow.
This is our second to last episode for the season. We'll take a break in December and return in February, 2023 with more exciting guests and content. So remember to tune in again next year.
With me today is Jeremy Snyder, a cybersecurity veteran and the founder of cybersecurity startup FireTale dot io, a company that offers simple yet effective API security.
Before that, Jeremy's long list of accomplishments in the cloud industry includes being one of the earliest people at Amazon Web Services ASEAN. He's always been an IT practitioner and counts amongst his experience running data centers and backend systems for several SaaS and video games companies in the early part of his career.
If you find him familiar, you're not wrong.
He helps the Ask A CISO podcast interview US-based guests, including luminaries like Chuck Brooks, Perry Carpenter, Sounil Yu, and Miko Hypponen.
Hi Jeremy. Welcome to the Ask A CISO podcast.
Jeremy
Hey, Raph. It's great to be here.
Raphael
Welcome back.
How does, how's the guest seat feel? Is it comfortable?
Jeremy
It feels fine. It is a little bit funny, kind of waiting for the questions to be asked instead of being the person steering the conversation but I'm more than happy to share some of my time and answer anything that you might want to know about FireTale and about API security in general.
So let's get into it.
Raphael
Great.
So in the past, you know, we've been talking about cloud security a lot, but today we wanna focus really a lot more on API security. What's the connection between cloud and API security, and what is API security for those who don't know?
Jeremy
So let's come to that second question in just a minute, but let's answer the first one first, which is, what's the connection between cloud security and API security?
My journey into API security actually came from my experience in cloud security. Between 2016 and 2020, I spent a lot of time actually flying around the world in kind of pre-pandemic era, meeting with large scale digital native companies, helping them design strategies to implement cloud security at scale and at speed.
And one of the common things that I heard from them was they really get the most benefit outta the cloud when they start thinking about the cloud as a computing platform, and they move away from thinking about operating systems as the computing platform.
So if they look at everything the cloud has to offer them as part of what they can embrace and what they can build on, they get a lot more agility and they get a lot more flexibility in how they build their applications. Plus a lot of the things that I was hearing from them is that actually operating systems are holding them back.
And what I mean by them is, of course, like we need operating systems to run applications and application software, but we don't actually need to manage the operating system. The operating system on its own, represents a large management overhead and a massive attack surface that you have to think about.
You have to patch it, you have to install all the agents you might need on it. You might have a process of baking, like known good operating system images, and then somebody has to monitor that only those images are making it into production.
There's a whole host of issues that comes with it. So what I heard from these digital natives was actually what they really wanna move to is they wanna move to this end state where the cloud is the platform that they run on.
They just write their business application logic, whatever form that takes, they drop that on top of some cloud platform and it just runs. And it scales automatically for them, and it provides the functionality that their users need and so on.
And so when you ask, well, what does that actually look like? You find that it looks like a shift away from kind of, you know, virtual machines and a shift towards serverless functions and containers.
And then you asked the next question, well, okay, what does that mean? What does that imply for how you need to think about security?
And again, the commonality that kept coming out was, okay, great, it's gonna be a set of modular system components, something that you'll often hear called a microservice architecture.
And all of these components are going to have an API at the edge of them. And that API is gonna be how you interact with that component. Whether that is, you know, executing some function call, providing some bit of functionality, providing access to a data set, whatever it may be.
It always comes down to having an API.
And so that was really kind of how I started thinking about it. And that is where I say, you know, the connection lies. It's kind of this evolved, you know, maybe a couple years in advance for some customers, maybe today for others, but it is where kind of cloud security leads to as a natural evolution.
So to your second question, what is API security?
Well, it's that question of if you have an API and it's sitting at the edge of some functionality or some data set, how do you secure it? How do you know that it is only answering the callers that it should be answering, that it is only providing the functionality that it should be providing, that it's only providing access to the data that it should be providing.
So there's a whole set of kind of logical questions that it needs to answer, in addition to kind of making sure that the API itself is built in a secure manner.
We don't have, let's say, vulnerabilities in the application stack that's running our API. We don't have, let's say, bad code running there, but there's a whole set of use cases around that that we can get into if it makes sense.
But it is effectively making sure that that API that is sitting at the edge is secure.
Raphael
Thanks, Jeremy.
So does that mean that in this new kind of model of the cloud with that's heavily, you know, a microservice architecture that this interface between these services should be considered a critical part of the infrastructure that needs to get more attention from security team.
Jeremy
I mean, certainly in our opinion, yes.
And if you look at kind of, let's say, an architectural diagram of you know, a cloud infrastructure layer, an application stack consisting of an operating system, serverless functions or containers, and then what gets exposed at the edge, the API actually represents 90% of that attack surface for a lot of these microservice architecture patterns.
Everything else may be abstracted one or two levels removed from kind of the edge of the network. You might have VPC constructs, you might have, you know, security groups and access control lists that kind of protect some of that underlying infrastructure.
But, you know, what is exposed at the edge as the API, and to your question, yes, absolutely it should be getting more attention.
Raphael
So we've been seeing API security starting to get a little bit more air time, appearing in the news. It's still very kind of kinda recent.
What would you tell the listeners that, you know, don't necessarily believe today? ell, you know, 90% of my attack? Like, that's huge! Wouldn't I? Wouldn't I know already? Like what would you tell them?
Jeremy
Well, to be clear, it's 90% of the attack surface represented by that modular component, right?
So let's not say it's 90% of the overall attack surface. Just to clarify that, I don't want to scare people into thinking like, oh my gosh, you know, the world is falling down if you're not protecting your APIs.
Look, what we know today is that more than 80% of all internet traffic is actually API calls, right?
So if you think about what happens when, let's say you order food off of a mobile app. You make one call off of your phone, which by the way is an API call to a cloud service that kind of starts the whole chain of events. But then, you know, that service is coordinating with the restaurant to place the order with a payment processor with a delivery service to get a driver to deliver the food to, and all of that.
And pretty much all of those calls are happening over between backend services, right? So more than 80% of all internet traffic is, you know, effectively, systems talking to other systems, software talking to other software, not humans talking to software.
So that's one step that I'll throw out there to just kind of frame the importance of how big or how crucial APIs are on the modern internet.
Second, we know that the volume of attacks against APIs is up like dramatically, something like 30x over the last year or so. And, you know, 30x off of a relatively small number to start off with. So again, let's not paint this picture as the world is burning down, but it is rising dramatically.
And you know, Gartner, take their predictions as gospel truth or not, I tend to think they're often like kind of directionally right, but maybe have the timeframe off. They predicted at the beginning of this year that 2022 would be the year that the API becomes the number one attack surface.
I tend to think that's wrong.
I tend to think that it's still maybe like third, fourth, or fifth on the list for a lot of cloud-native organizations. Business Email Compromise is still number one in my mind. Phishing, et cetera.
And then number two is probably, you know, cloud infrastructure misconfigurations. So things like what CSPM is solving is probably still a little bit more important category for some.
And then, of course, you know, endpoint detection and response, et cetera.
And maybe somewhere in the top five is API security. But I do think the trends are clear. You know, customers get into the cloud, they start an evolutionary process towards a more cloud-native architecture. They start to leverage cloud platforms as more of a cloud operating system, and they do transform the way that they run and the way that they design their systems.
And it will become increasingly, you know, relevant for them in the years to come.
Raphael
One of the reasons here, you know, that you're saying, there is the shift, it's still important, the existing areas of security that you already know and care about. Is it that the attackers are changing? Is it that, you know, the maturity of organizations has reached kind of a kind of a good enough state in these existing areas that now you know, an area that's less well-protected is API security, a combination of those?
What do you think is driving this shift?
Jeremy
Look, it's a combination, but what I would say is attackers go typically for the path of least resistance, right?
Like all of us, they have a limited set of resources, mostly limited by time. So you're gonna go to where you can breach data the quickest and kind of, you know, least effort, most cost-effective. So if you find that APIs, like every company has APIs, you can design a set of attempted attack vectors against APIs. You can automate that.
You can build software that runs API probing tests, et cetera, et cetera, and it's not very hard to figure out what those attack vectors are. You can kind of do root cause analysis against the breaches that have taken place so far, build a set of attacks that try to leverage those vulnerabilities or those weaknesses.
And then just kind of repeat at scale through automation, right?
Just like they do with phishing campaigns, just like they do with attempting to send malware, attempting to send, you know, viruses in PDF attachments, et cetera, et cetera.
It's just another tool in the arsenal, and it's becoming more important as organizations have more APIs and as developers build and deploy more.
And we know that they repeat some of the mistakes of the past in terms of, you know, how securely they're building their APIs. So attackers are getting savvy, businesses are launching more. It's definitely a combination of all of the above.
Raphael
Perfect story.
Jeremy
Perfect story.
Yeah.
Raphael
Yeah.
We always love those in security. This makes these big, big visible breaches. So maybe tell us a little bit more about FireTail, and let's go into some details here about how you started.
What's the gap that you're that you're addressing within API security? How are you helping organizations with that?
Jeremy
Yeah.
Let's first start with understanding where the main weaknesses in API security are, and the main weaknesses are actually at the application layer, and they're fundamentally with application logic. So if you think about what needs to happen for an API call to execute successfully, what should happen is, okay, you establish connectivity, you then authenticate, you then issue the request that you're trying to issue.
And what should happen is that that request gets parsed and it gets checked for, you know, is Jeremy authorized to send this API request? Is Jeremy authorized to call the function that he is trying to call? With the data that he is trying to call?
And then is there anything in the response that we're going to send back to Jeremy that we don't want to send?
So there's a set of kind of logical checks. They're all very simple. They're all kind of yes no, or pass fail, however you want to think about it.
And that is fundamentally like what API security is built on. It's like, are we accessing a valid API with valid credentials using a valid call with a valid role that has the valid permissions to do this thing?
And that's really where we started to attack the problem from the FireTale perspective. What we saw was, in the majority of breaches, the problems were not things like network security controls or things like, you know, IP allow or deny list or what have you.
It was really things like, does the application and the API have logical controls to check the validity of the API call. And so we addressed it from the standpoint of trying to figure out, well, what layer in the stack do you need to sit at in order to see that, you know, see the data elements to make a good, well-informed decision about, you know, yes, no, allow this API call?
We realized it's the application layer and we realized that the best way to get into the application layer is to provide something that's very, very lightweight, easy for a developer to include in their API code, and should take, you know, no more than about 10 to 15 minutes to implement. And it's about 15 to 20 lines of integration code.
So effectively there's an application code library that sits in line and performs a set of logical evaluations against the API call that's coming in. And that's how we're addressing the problem.
Raphael
So, essentially it's kind of like a filter.
You just added this piece of code and now every single culture API gets vetted against a set of rules. What types of rules or, you know, what types of checks are they, and maybe what types of API attacks? If you could illustrate a little bit, you know, the typical API attacks that kind of go hand-in-hand?
Jeremy
Yeah.
So one of the common attacks is basically, well, let's rewind for a second.
Most APIs are built on common Open Source frameworks, okay? And some of the most popular frameworks today are things like Open API, Swagger, GraphQL, et cetera.
And I realize there's, you know, a little bit of nuance in some of those terms, but let's just think about them for a second.
So, with something like Swagger, you have a Swagger file that kind of defines your API and it tells your API, like, what are the existing endpoints, which is to say like, what are the existing functionality on this API? How do you access it?
And with something like GraphQL, you have a similar thing that tends to kind of implement a GraphQL endpoint that you may or may not want to make accessible.
One of the common attacks is basically the attackers know that these are the common frameworks and these are the common patterns. So they kind of probe and enumerate around an API that they find, and they look for things like an admin endpoint, a GraphQL endpoint, a swagger endpoint that's going to basically expand and expose more functionality than the developer intended.
And so one of the checks that is done first by the FireTail library is: we know the valid routes and methods that are associated to your API in its end point, and anything that doesn't match a valid route with the proper method, we're just going to fail immediately.
And so that prevents that kind of enumeration or probing of your API to discover things that you don't want exposed. One of the next checks that we run is what type of authentication does your API require?
We're going to check is that authentication in place, whether that's an API key or a token, like a JWT. And we're going to check is that a valid authentication token?
So these are, you know, two examples of some of the rules. We've got other things that we're working on, but those are, you know, kind of two examples of common API attack vectors and how we look at preventing against them.
Raphael
Cool.
I know it gets a lot more technical, a lot more details there.
What are the differences fundamentally between, you know, that approach, which is very, very close to the code and other kind of typical security approaches so you'll have people saying, okay, you know, why don't I just have an agent, you know, endpoint detection or network detection, response, those kind of things?
Jeremy
Yeah, look, I think an agent approach can be valid, but it requires that you have an operating system or someplace to install that agent.
And again, what we heard consistently is a desire to shift away from operating systems to more serverless functions and containers.
So you may or may not have an attachment point for that agent. So that can be problematic.
On the network side, one of the big problems is you just don't see all the things you need to see. So you may have TLS termination in place, so you may be able to see an unencrypted request.
Great.
But you may only see, for instance, the header and things like source and destination and maybe partial request parameters, but maybe not all of them. And you certainly can't see the response being sent back.
So with that network layer, like you may not get visibility into all the things you need. Or you may not be able to block it, depending if you're using like a WAF or more like a network detection and response logic, but either way you're not seeing all the components you need to see.
And then, you know, we haven't talked about, really, one of the biggest problems around this, which is authorization. And authorization is really just, you know, the set of permission.
And the truth is, like with network visibility, you just don't see it no matter what. And with agent visibility, you might, but if you don't have integration into the application code, you may not have a place to actually go check that authorization is being calculated or being calculated correctly.
And that's why we, you know, kind of explicitly chose that application layer to work at. Of course, there's a whole set of challenges that comes with that, which is that pretty much no two companies do authorization the same.
And so what we're working on is a kind of an abstract way to look at authorization calculations and maintaining like a high level authorization graph for customers. But it's not really something we're ready to talk too much about just yet.
Check us out maybe like February, March of next year. Maybe by the time the new season of Ask A CISO is out, we'll have something to announce on that.
Raphael
Perfect.
I find it personally like super exciting because as you said, authorization, it seems so simple, but it gets complex so incredibly, incredibly quickly. Right?
Like the business logic is, I mean, sometimes you have pages and pages of documents internally just explaining like, what we intend.
Jeremy
Yeah.
Raphael
And then you need to translate that to code.
Jeremy
Yeah.
Raphael
And like, obviously loads of opportunities for mistakes or emissions as we go, right?
Jeremy
Yeah. Yeah.
I mean, this is why on that side in particular, there's kind of three common, I say common, common in the API security space. There's three four-letter acronyms that get thrown out there pretty frequently around this. IDOR, BOLA, and BFLA, and all of them are fundamentally authorization problems that have been kind of observed at scale on APIs out in the wild.
Raphael
And I mean, if we're just thinking conceptually about this authorization, I mean, it's been one of the great advantages of cloud as an Infrastructure-as-a-Service with super fine grain controls everywhere, but also kind of the nightmare that comes with managing 11,000, 12,000 different permissions, right?
Like ...
Jeremy
Totally.
I mean, it's funny you say that.
If you, uh, video of our listeners want, they can probably still go on YouTube and find a webinar that I did with a coworker of mine about three or four years ago talking about Cloud IAM security, and I can't remember the exact title that we use for the webinar, but if you just google, you know, cloud IAM, Jeremy Snyder, et cetera, you'll probably find it.
But we basically played out two sides of the argument.
One is that the fact that it is so fine-grained gives you just amazing control and you can effectively accommodate for any edge case of permissions that you want. And the other is because it's so fine-grained and you can accommodate any edge case, it's a nightmare to manage, and to keep central visibility on.
And I think both sides are true.
It's just that it is such a problem to know, and to really like understand the implied permissions of any kind of user group, attribute, role, permission set combination that comes out there.
And you add to that the fact that you can also now make it dependent upon tags on the user, tags on the group, tags on the resources. Uh, it's a lot.
Raphael
And there's a reason why all this functionality is added, right? It's great people use it, but also every single organization does it differently.
And once that flexibility and, you know, what we see a lot of is organizations that aren't as mature, they're going to use, you know, they need something that's manageable.
Jeremy
Yeah.
Right.
Raphael
Whereas mature organizations, they're like, okay, I wanna tune this. I wanna really do these least privilege, et cetera.
And I imagine that you're gonna be seeing exactly the same kind of things at the API level for all the same reasons.
Jeremy
Yeah, a hundred percent.
I mean, even so far, look, we're, we started the company officially in February of this year. So we've been out about nine months now, and we've worked with a pretty small set of closed beta customers up to this point.
But even across our kind of small customer base, as of November when we're recording, we've seen 4, 5, 6 different ways of tackling this authorization problem.
You know, and it is kind of, like I said, every customer does it differently because of circumstances or requirements or edge cases or what have you. It is very challenging.
So yeah, it's been a learning process even so far around this authorization problem, but I will say from our side, we do feel like we've got some interesting approaches to try to tackle it and to try to make it something that can be consumable almost by any organization, no matter where they fall on that maturity spectrum that you just described.
Raphael
Great. I mean, like a lot of generations of this kinda new technology, we often see a little bit, very custom things at the beginning and then some phase of consolidation around a certain number of standards, like you mentioned, Open API, Swagger, et cetera.
So hopefully, you know, we'll see the same there.
Maybe to get back to FireTale, what is the perfect customer for you? Well, you know, what kind of attributes do they have? What do they need to have in terms of teams and processes and maturity?
Jeremy
Yeah, look, runs on AWS would be one. We've pretty intentionally designed the system to start with integrations with AWS from the standpoint of API discovery, cataloging, and prioritization.
And that's what we've seen from customers. Their adoption curve is not necessarily ready to go deploy the code library on day one. It's really more, Hey, let me start with observing my APIs for a little while to understand which ones are most crucial. So that's where we start, right?
So runs on AWS. Whether they run on an EC2 environment or a serverless or a containerized platform, that doesn't really matter for us. We've got solutions for both sides there.
What I will say is, funny enough from the code perspective, what we've learned though is that certain frameworks work really well for what we've built in other ones. We've got a little ways to go around them.
So for instance, today we have great support if you're building on top of like Python with Open API, if you're building with NodeJS and Express, if you're building with Ruby and Rails, if you're building with Goling and Open API, we've got great support for some of those combinations.
We're a little bit behind on .Net and Java. And to be honest, we've not seen a lot of demand for them. And I have some hypotheses in my head around why that is.
I tend to think it's, you know, these are customers who are dealing with more monolithic application architectures and they maybe haven't gotten to that point of starting to really, you know, break down their applications into more microservice-oriented architecture.
So that's one.
So, you know, a lot of Open Source, a lot of kind of shift towards microservice already.
As far as things like industry or size of the organization, it's been interesting, again, even with a small set of closed beta customers that we've worked with so far, we've not really seen any consistency there.
But one thing I will say is we've seen more demand for kind of born in the cloud companies than for, let's say, large scale legacy enterprises that are, you know, going through a cloud transformation process.
We've talked to a couple of those and we've worked with a couple of those, but probably more demand on the born-in-the-cloud side.
Raphael
Probably also because I guess like adoption trends, like the people that are looking at that, that are ready for that, probably already have some good baseline on some other kind of cloud-native way of thinking around security and so got the people in place, et cetera.
Jeremy
Well, I think that last point in particular, right?
They've got the people in place. These are people who came out of other organizations, probably where they were already doing cloud things, and they joined these companies that are kind of born in the cloud and they say, oh, okay, well, I learned this from my last job, so here we're gonna get it right from day one and we're going to build, you know, kind of very cloud-native from day one.
So that's, I think that's definitely a contributing factor.
Raphael
Yeah, it's exciting to see like, there's always so much, you know, the cloud is here, but yet the cloud isn't quite here yet, even though I think at this point it is the default, but yet there's still so much in terms of getting to the maturity level of what we expected or we currently expected, you know, pre-cloud, on premise environments.
So it's really interesting to see that journey and be part of that journey as well.
Jeremy
Yeah, absolutely.
And I mean, I was at an event earlier this year where a group of CEOs and industry analysts were talking about the state of the cloud today and you know, kind of, third quarter of 2022. And nobody has an exact statistic that they can, you know, definitively point to and say like, this is the percentage of workloads that are running on the cloud.
But to your point, I mean, it's still somewhere between 40 and 60 percent, and it's kind of been at that number from the stats that I've heard for the last three or four years. And you'd say, well, like, is it not changing?
But the truth is, it is changing.
That 40 to 60 percent range is huge. And if you think about kind of like the bell curve, this is exactly the largest area under the curve.
So this transition where we reached the tipping point of going from, you know, below 50% to just above 50%, that's a lot of workloads to migrate.
So I still think we're kind of maybe early, maybe kind of the late part of the early stage, if you will. Kind of the end of the beginning maybe is a way to think about it.
But we still got a lot of workloads to migrate and if not to migrate, you know, we're also gonna see the evolution of certain sectors where some legacy businesses get cannibalized by some new up-and-comers. Just as we've seen for the last however many years, you know, Blockbuster, Netflix was just one classic example.
But, you know, there's gonna be a lot more disruption that happens in various industries over time.
Raphael
Yeah, and as you were saying, in terms of that trend, there's also the, you know, one way to look at it is what is actually running, and obviously that has a large existing base versus if you look at, oh, everything new that's coming online, you know?
Maybe that's already on the cloud, you know, majority, but there's just so much legacy and it's gonna take years and years and years ...
Jeremy
Absolutely.
Raphael
that, you know, that winds down, end of life, et cetera, et cetera.
Jeremy
Yeah, absolutely.
Raphael
Great.
Is there anything else that you'd like to share with the audience?
Jeremy
Yeah.
We've developed kind of a framework for thinking about API security as kind of a end-to-end process, right?
And I think it's important to think about, look, no one approach to security is right for every organization. And I always stress that to people when they ask me about anything.
Well, how should I do cloud security? How should I do endpoint security?
First and foremost, you should do it in a way that's actually gonna work for your organization. If you ever try to change the way your organization works in order to accommodate one strategy or one approach. Like that's a process. That takes time.
And you know, when I was, I don't know where this phrase originally came from, but you've probably heard it as well, which is that culture eats strategy for breakfast.
And if you kind of try to, like, force something on your organization that your organization is not ready for, like it's just gonna fail.
Like, for instance, I hear a lot from people, well, I should just automate all of my security.
Great.
In theory, that's right.
But if your organization's not ready for automation, you try to put that in and like everybody's just gonna revolt or your people will quit or whatever, but it's probably not gonna go well for you. So the way to think about any security approach is first and foremost, whatever works for your organization.
So start by thinking about, let's just take API security, as an example.
Start by thinking about who owns that function.
And if you don't have an answer to who owns that function, then the second question is, who would normally own the function of security for a new approach?
And then ask are they the right person to own this one? Or is this an opportunity to think about things differently.
Wherever you land on that question, let's talk about where in the lifecycle different security elements of API security come into play. So if you think about kind of the most "shift left" strategy, where you push this all the way into the design and code phase.
There are a couple things you can think about there.
Things like eliminating third party vulnerabilities, whether that is in kind of the infrastructure that you're designing from an infrastructure as code perspective, whether that is in third party libraries or whether that's like container images that you're pulling, what have you.
So let's get vulnerabilities outta the way, and then let's think about what we can do on top of that with things like secure code analysis or source code, kind of composition analysis, et cetera.
Next, as we kind of move from that code and design phase into more of the, you know, almost ready to go live phase, kind of the testing or the staging phase as you might call it, there's a set of tests that you can do there. Fuzzing is something you'll often hear about, but one thing that we really stress on the API security side is: because we know that for the most part, the problems are actually application logic problems, one of the things you may need to do here that you haven't thought about in other contexts is actually test your API with multiple valid sets of credentials.
And think about that.
Let's just take a simple example where you have kind of a user, a super user, and an admin. You may need to test your API with all three of those kind of roles in place, and then test access to the function and the data combinations for each, including testing things that you should not have access to.
So if I take that super user role as an example, can I access the admin functions? Can I access the admin functions with all of the data elements, right?
Like all of my different user types or product types or transaction types or what have you, right? And that level of logical testing is something that we don't see a lot out in the real world.
And that's something that is actually super critical for API security because we know the problems are logic problems, right? And then finally, when you think about kind of getting into production into the run time, what's important there?
Well, what's important there is actually, you know, monitoring, preventative controls. You know, do you have something in place that is checking that even though we thought it was secure when we built it, once we put it out into the real world, is there anything different about our production environment from our staging where we might have some implications we didn't think about?
And then definitely last but not least in any way.
One of the challenges we've heard consistently around APIs is you can run an API anywhere. As we've mentioned a couple times, you can run it on EC2, Lambda, EKS, Fargate, what have you, right?
Well, guess what?
All of those things log to different locations by default. And if you think about kind of security forensics and incident response, one thing that's actually really important is to get all your logs into one place. So do you have any kind of process in place for centralizing your API logs?
So those are some of the runtime controls that we think are really important.
And then last but not least, you asked the question earlier, Raph, is are attackers getting more sophisticated? Well, yes is in part the answer and part of the reason is that they have started to understand things like AWS in much more detail. So they know that if they get a foothold in through, let's say, a vulnerable application server, they can, for instance, look to enumerate the permissions of the role that is attached to that.
And then see what they can do with that role. They can get the AWS CLI like everybody else. They can figure out what the commands are. They can try to describe the role and then leverage the role to issue API calls to other parts of the infrastructure, kind of move up and down the stack, leveraging a compromised identity.
All of these things are super crucial.
So one of the last steps that we really think about with API security is, okay, great, you've done everything kind of left to right on that timeline. Now you need to think about kind of up down the stack, how do you, correlate your API to the application running under it to the infrastructure that's powering it?
And what do you know about kind of the blast radius that might be at risk from a vulnerability at the API layer? That's maybe a little bit like two steps ahead and the kind of the most evolved customers thinking about API security. But it is something that we're starting to have conversations about and we're starting to hear about.
It's like, where does my API security overlay my cloud security?
It's another area where we see those things coming together. So I know that's a lot, but, you know, hopefully people can kind of, I don't know, maybe go back and listen to that again. Use the little back 15 function and listen to that two or three times if you need to.
Raphael
Thanks, Jeremy.
That was super helpful.
Once again, thank you for coming onto the podcast, Jeremy. I thoroughly enjoyed our conversation and hope you did too, as a guest this time around to those listening to the podcast, thank you for tuning in.
Once again, this is the Ask A CISO podcast and this is Raphael signing off.
Jeremy
Thanks so much.
Raphael
Thanks, Jeremy.
