Transcript
Renato Losio: In this session, we’ll chat about designing for defense and architecting APIs with Zero Trust principles.
I would like just to give a couple of words about this panel and about myself, and clarify what we mean by designing for defense and what’s the topic today. API security has moved in the last decade from being, I wouldn’t say optional, but not that important. I’m old enough that when I started playing with APIs it was not on top of our mind, to be now essential, and is now a primary front in our system defense. Traditional security models are not enough anymore and that’s where Zero Trust security comes in.
My name is Renato Losio. I’m a cloud architect. Also, I’m an editor here at InfoQ. I’m not the expert here, the experts are our four experts coming from different companies, different sectors, and different backgrounds. I’d like to give them the chance to discuss the topic. Just a couple of more words about what we are going to discuss. We’re going to explore why APIs are the center of today’s security threats and how we are going to apply Zero Trust principles to protect them. I would like to give a chance to each one of our four panelists to introduce themselves, and share their professional journey in designing for defense and why they’re here today.
Ben Bridts: My name is Ben. I’ve been working as a Cloud Engineer, Cloud Architect for a little over 10 years. Specialized in AWS, so I’m also an AWS Community Hero. My background is in operations, which means that the longer I do this, the more security things I have to do, the more learnings on architecture, the more compliance, sovereignty becomes important.
Katie Paxton-Fear: I’m Dr. Katie Paxton-Fear. I am a Principal Security Researcher at Harness. My career journey I often say is that I used to make APIs and now I break them. I’m an API hacker. I find vulnerabilities in APIs before the bad guys can. I show companies how you can secure your APIs, be more effective. I write that a lot as technical content, webinars, blogs, white papers, all to really improve API security for everyone.
Nivedita Murthy: My name is Nivedita Murthy. I’m a Senior Staff Consultant here at Black Duck. I’ve been in this industry for 16 years now working in all areas of AppSec. Currently helping our clients improve their application security program by providing consultation on strategic initiatives out here.
Zsolt Németh: My name is Zsolt. I’ve been in cybersecurity for 16, 17 years. Started out as a developer of algorithms or symmetric ciphers, mainly. I got into the cloud space about 10 years ago. What we are doing now is actually using moving target defense for strengthening security postures, or hiding the attack surface against the attackers.
What Is Zero Trust Security?
Renato Losio: I’d like to basically start with the most basic probably question, but just to really set ourself on the same page and as well give a feeling of really what we are talking about. What is Zero Trust security? What is so important for APIs?
Katie Paxton-Fear: Zero Trust started out really as a methodology for securing networks and infrastructure, but it’s become a lot more than that. It’s become a general ethos around how we should think about security. It’s quite straightforward. Zero Trust is about assume breach, assume you’ve already been compromised and secure your assets accordingly. If you’ve got something like APIs, obviously they’re highly connected.
If one API is breached, how do you protect every other API, for example? It’s very much thinking about like principles of least privilege. Making sure that nobody or no API or no API user has more privileges than they should. It’s about making sure that any PII you have is protected appropriately with whatever precautions you want to put in place, like encryption, for example. Really, what we’ve really seen in the past few years is it’s becoming the way folks think about security and the way folks start to pull the pieces together around security and what good security looks like.
Renato Losio: I don’t know if you want to add anything else to the topic or maybe clarify what you think is important for APIs.
Zsolt Németh: The short version is, assume compromise always. That’s it. APIs, 10 years ago, it was like a vent on a house. Right now, this is the front door, and that’s why it’s important, because the side window or the garage, whatever, you can get in easily. Right now, it’s actually much worse because this is basically the front door the attackers are usually getting in. That’s why you need to basically defend it. Again, before that in the architectures, there were something like safe zones or whatnot, but that’s not true anymore.
Challenges of Applying Zero Trust, with no Background in Security
Renato Losio: I have a question as a practitioner myself, that is not coming from a security background. I’m old enough that every few years, I hear that things are getting worse and it’s getting harder and it’s getting more important. I find it as a developer always a bit scary as I don’t feel really enough. What are the main challenges for a software architect, software developer to applying those principles to get to the front, to protect that front or make it so essential in the technical journey? What are the challenges you see?
Ben Bridts: Like everything with software, there are so many options. There are so many things to get right, that it can be challenging to know where to start. It can be challenging to know what exactly you need. There’s a challenge in some way, like the thing that Katie said of like assume compromise, helps with that as well. You have to assume that it’s untrusted.
I think the main challenge is like, I have this API, like I’m used to this specific framework that I’ve been using for so long, like what’s my first step to start securing my APIs? Am I going to focus on more general approaches? This is an example. It’s not what I recommend. Like, am I looking at firewalls and stuff like that, or am I looking at authentication, authorization, like complete new policy languages? There’s a whole spectrum of things that all fall within the same thing, that knowing where to take your first step to start securing your APIs and to build something that you can comfortably say, this is where I trust, or I know that even though I don’t trust anyone, this is a valid request that I can actually act on.
Renato Losio: What do you see as the main challenge for someone like myself or a software architect that is not coming from a security background?
Nivedita Murthy: I think it’s the not complexity that you add when you start thinking from a security side. Let’s take, for example, a SELECT * from a table. It’s easy to write that query. There’s no filter. It gives me all the information. It’s easy to send it out. It’s easy for the developer to write it. When we start telling them, you cannot send the entire table. You need to put in filters. You need to put in checks. They need to add some filters out there. Adding that, especially in terms of an API, gets a little bit tricky, gets a bit more difficult. That’s where engineers say, security is making my work difficult here.
It’s just adding more time, more complexity to the problem out here. I just want to give my API out and make this functionality available to everyone. When security comes in and says, no, you cannot just make all the data available immediately to everyone, you have to put in certain checks. That same data has to be split into four different APIs, or maybe verify that the request is coming from the right place, or add in limits to the number of records coming in. That’s where the developer thinks it’s getting a bit more trickier, a bit more complex, a bit more difficult for me to just send out this functionality in the next two, three days that they have been given to set up the new API.
Incentivizing Devs to Apply Zero Trust Principles, Upfront
Renato Losio: I see that when you mention the extra effort is something that everyone was nodding. That’s actually the feeling I have sometimes as a developer, that always that concern, instead of saying, that’s one of the key aspects that I cannot get the API wrong. I cannot break security. Day one is like, I see that as a burden. I’m thinking as well, when I build something simple, like I’m using even a manual service, like an API gateway or whatever else, and I feel like, I can’t just do it. I can’t just put it out there. How do you interact with a developer that feels that applying those principles upfront is going to slow down development, or I’m just doing my first MVP, so it doesn’t really matter, but be sure I will take care of that later on. Why is that wrong? How should they adapt that?
Katie Paxton-Fear: I think it’s really challenging, especially for APIs in particular, and I’ll explain why. APIs as a product are very developer-driven. Unlike other products where we might have something like user requirements, and we’re thinking about customers. When it comes to APIs, our customers are developers, they’re us. They might literally be us, as in, we might be developing the next application that connects to that API.
One of the problems and the challenges there is that when developers are in a position where they’re being told to add security, if they’re being told by the security team, it’s like interfering with their child. This is something that they’ve designed from the ground up that meets their requirements, that they’re in complete control of, and the first thing we do as a security team is take it away from them. I can see how any developer would get really annoyed about it. It’s normal for people to get annoyed. I think for us as security teams, we don’t really consider the developer perspective that often. We’re so much thinking about security. We are in a world of security vulnerabilities. We’re reading the news about security breaches. Developers aren’t in that world. It’s up to us to be a resource for them. Not to be the person going, “No, you can’t do that. You can’t do that. Stop what you’re doing”.
Instead be, “You want to do that? Let me help you. I will do this. I will take on the cognitive load of figuring out the security side of this so you can focus on what you’re doing and what you’re best at”. I think really one of the main challenges I see in a lot of teams is that when APIs, particularly if they’re developed to be initially internal only, they do not have the same stringent security because it’s internal only. Who cares? For something like implementing Zero Trust, that’s so key. If your developers are in a position where they’re going, “It’s internal only, so it doesn’t matter. It’s for me and me alone, so it doesn’t matter. Stop telling me how to do my job. I’ve worked in this industry for 15 years. I know what I’m doing”. You have this recipe for a real breakdown in communications.
My first advice for any team is to go buy your developers donuts. Give them something. Give them a reason to want to speak to you. Stop telling them no. Start saying yes. Develop that friendship because that is where things will go wrong, that relationship between developer and security team.
Ben Bridts: For developers listening to this, it’s a two-way street as well. Security is not there to block you. We want everything that Nive said of rate limiting and stuff like that. Good security is good design. You want it in your API. Problems arise if you’re like, build everything first, and then go to security, trying to push it through in one day and now we need approval. If you come to security on day one, say, I’m going to build an API. Maybe you haven’t thought about this is going to be internal or external or things like Zero Trust. Maybe there’s a way to build that in from the start and not have that at the end.
Katie Paxton-Fear: As a security team, that’s where you should be. You need to be in the design phase. You need to be there. You need to be that resource, so they don’t have to think about there.
Zsolt Németh: However, the problem is like, we’re talking to a lot of CISOs, a lot of security teams, and they usually just tell the developers that, I’ve got this dashboard. It’s pretty easy to use. Why don’t you just do it? It’s super easy. There are three big problems. One is, developers are definitely not security guys. You need to figure out, not just how to talk to them. You have different priorities than us. Ours is security. We kept trying to get rid of that, like shift left and whatever. Like whatever happens down there, that’s the developer’s problem, or the head of DevOps, or DevSecOps, or you name it. It didn’t work.
The other problem is you have different priorities. The first thing, when I talk to a developer, the application has to work. Then, load testing, then resilience, then UX, and maybe then comes security. By that time, that’s just too much of a burden. As Katie said, security guys should help or could help, not just by buying donuts, but obviously going further and just start a conversation. That conversation is not really happening, according to our experience. That’s the biggest problem because you are there, they expect you to solve something which you don’t even have an idea about, and that causes bad luck.
Nivedita Murthy: I think Zsolt and Katie, all of you have mentioned about providing incentive in a way to the developer. What we do over here also is that when we provide them a security report, a penetration test report, for example, we always highlight first what are the good things that we found in their application, because you don’t want to go straight away for the bad points. You want to actually say to the developers what good did they do. They’ve actually, inadvertently, without them actually thinking maybe, they have secured their application. You want to point that out first that these are the good things in your application. You’re protected against authentication attacks, or authorization attacks, or maybe some validation attacks out there. You’ve done that and that’s great, but let’s also focus on these areas in your code which may need some improvement, may need some curing.
One of you mentioned over there that it should not be on the developer to think so much about security. It is the security team’s responsibility. That’s why this question should come at the design phase itself that, how do you design this application, so that it’s easier for them to just push out those APIs which are inherently secure, and does not give out the information that it’s not supposed to give in the first place. Pushing this requirement in the design phase itself helps in the long run. It reduces the effort involved in developing these APIs as well.
Internal APIs vs. External APIs: What’s the Difference?
Renato Losio: When you mentioned about internal versus external APIs, the high-level concept is very clear to me. As well, I can say, I have many different microservices all talking with their own API and different teams talking together. Sometime I ended up in a discussion that there was a bit of a mismatch what we meant. The other person meant internal means only private IP. There’s no public IP there. Some other really much more extended concept like, by internal I meant the specification was just for some internal product. How do you see that? When you meant internal, you meant just nothing in the public space, or what’s usually the definition of an internal API?
Katie Paxton-Fear: I meant both of them, because there is no really clear definition of what internal means. Obviously, with the kind of infrastructure we have at the moment, especially around mobile apps. Mobile apps are essentially just APIs at the end of the day, they all connect via APIs. For an organization to have a mobile app, you also need the API, that can’t be just restricted to your network. It has to be online. You don’t have to provide documentation. You don’t intend anybody else to use it, but your mobile app, the API still needs to be there. Often, people refer to that as the idea of an internal API, because as you say, only developers have access to the API docs. Then you have APIs that are really designed to be internal only, so they are going to be restricted. I will say, as an API hacker, that is rarely true. I have found many internal APIs that are publicly available on the internet.
Renato Losio: Through a proxy or whatever else, yes.
Katie Paxton-Fear: A proxy or you can usually pivot as well. Like you just need access to one API, then that will make requests on your behalf. Or just people are like, it’s not on a domain name, if it’s on an IP address, for example, but it’s still available. Or they’ve got references to it in the code, like in JavaScript, even if they’re not making API calls directly. That’s also another fun way to find internal only APIs. This goes back to why Zero Trust. Like, assume those APIs are compromised. Assume I can already see them. How does your security strategy for those APIs shift when that is the case?
Ben Bridts: I fully agree with that. I think the distinction of like internal versus external is an access level, not just for APIs, but for everything, is very risky. In terms of APIs, talking about like, this is a user API versus an administrative API, whether that’s callable from inside or outside, like own apps or different apps, it doesn’t matter. It has certain things it can do. That’s the important part. That will drive, how are we going to protect it? What are the policies we’re going to apply to certain endpoints?
Admin APIs vs. User APIs
Nivedita Murthy: You mentioned about admin API versus user API. APIs were introduced to just make it simple and easier for applications to interact or developers to get information from applications, just interfaces. Do we really need an admin API for that matter on an API level, is that necessary in the first place?
Ben Bridts: No, I think this is more of me putting on my developer hat and how I think about data models in the sense that both are accessed by principles that are going to be doing something. In some cases it’s going to be very clear, this principle is my end user, my customer that’s going to be acting on their data and need their permission model. That’s what I call the user API. It’s end user facing API. Whether that’s internal, external, where it is coming from, it’s doing something for the end user directly.
Then it’s like, I need reporting on that. Maybe I need a support team. Not even how I design my microservices, but like project concept. That’s more of like admin level stuff. That’s going to be acting on multiple users possibly, or impersonating a user, or all that kind of more risky stuff, more traditionally what you call like an internal API. It will still need to be authenticated to a certain user. It’s not like admin that can do everything. A certain support person can do certain support things.
Katie Paxton-Fear: Do we need an API to do that, because we’re talking about Zero Trust. You want to limit access. We want to also limit in terms of how the application can be accessed with elevated privileges. Would it make sense to have at an API level or just give an interface an actual web application, so it doesn’t go through an API. That’s from a design perspective.
Ben Bridts: For me, everything is an API. If that’s a PHP app that’s rendering web pages or that’s like a fat client, it’s an API. It’s doing something somewhere.
Where Should a Developer Prioritize?
Renato Losio: One of the challenging parts as an architect, as a software developer in general is, we say security should be part of implementing and designing robust and proper APIs, at least in theory. Things about rate limiting or whatever else I’m thinking about, or zero security, whatever else I want to implement. Somehow when I implement my API, I’m thinking about my problem. I think it’s not against the security team or against someone else. It’s just, I want to implement my feature A, that is, add a contact to the user, post something somewhere, and I feel like reinventing the wheel if I have to do at my layer, at my level. Either I’m using something that is out of the box, a tool or something that is doing it for me and someone else is managing that, possibly. Where should I worry? As a developer, should I think about rate limiting or is it something that comes later? Day one, where should I start from? Because if I have to implement it myself, probably it’s more complex than my API somehow. I feel like I’ve reinvented the wheel.
Katie Paxton-Fear: I can tell you about my very first vulnerability I ever found. It was on Uber, and I found this vulnerability. It was in a major Uber product. It’s long since resolved now. I’ve spoken about many times. It’s not sensitive. The way I found that is because I saw a RESTful API that was implemented correctly. As a developer, I knew that RESTful APIs are supposed to use PUT and DELETE. They’re supposed to use the different HTTP verbs. Have I ever developed an application that ever uses those? No, everything is POST and GET. By seeing that in the wild and seeing it on this application, I’m like, this is done correctly. There is no way a human wrote this. Surprise, the human didn’t write it. It was an automated tool, which then didn’t add the required authorization checks and actually authentication as well, because it was essentially just a generated API.
I see that all the time now of people trying to take a shortcut, especially nowadays you’ve got AI and vibe coding. I think tools are great. They are really great for allowing you to do things more effectively and more efficiently. I think you got to know some of the principles yourself as well. It’s not enough to just rely on them and just assume, the tool will handle everything so I don’t need to think about it, because the tool is dumb and you’re the smart one in the room.
Renato Losio: All my assumption of just putting some managed services and lead the security for that in front of my simply developed API is already gone.
Zsolt Németh: What I wanted to add just briefly about rate limiting. Obviously, it’s a heaven for attackers, so like DDoS, brute force, whatever, we call it the architectural sins. You need to be aware of that. As a developer, rate limiting isn’t easy stuff, like how you separate the data planes and the control planes. What we see at most of the customers, like they log everything without protecting the logs. You can basically just get there and mine your information out, or use AI to mine your information out. It all gets back to a bigger problem from the developer perspective, whether the API is ready or you need to write it from the ground up, because if it’s ready, you need to put the work in to redesign the whole thing. That’s a lot of overhead, which most of the CISOs or CIOs don’t like, because that’s additional money to be spent.
The Most Common API Vulnerabilities
Renato Losio: I’d like actually to go back to what Katie mentioned before, the case of Uber. I don’t want to go too much into detail of a specific case. I’d like to scare our developers a bit. Without necessarily naming a specific company, but share common API vulnerabilities, what are common things that usually developers don’t think about, apart from authentication, of course, that is the first, probably the only thing that we think about, or which method we use. One guilty one usually is POST, whatever it is, for GETs. That’s it. I don’t know if you have any story, anything you want to share that could tell us how to go to the next level and how to think a bit more about what we do. I had the feeling before you mentioned as well, don’t expose anything that you don’t need, like an admin, but if you have anything you want to share.
Nivedita Murthy: The one commonality that I saw in all the breaches that have happened so far, they’ve all collected information about people in the database, and sensitive information specifically. Today data is valuable. It is money, more than actual money. Sometimes data is money. It can be used for nefarious purposes, going from phishing, scamming, or whatever, but you can sell data to someone else for whom that information is valuable. I also have used APIs a lot to write my own scripts to automate stuff.
One of the easiest things to do is just call an API, get information about a certain thing and just push it into an Excel sheet, just export it out. This is basically data scraping. That is one thing that happens regularly with APIs. You’re just pulling information, pushing it into a file or into a database. You do that continuously. When you are an engineer developing an API, you need to think about this. What are the different ways a malicious user would basically get information out of my application and push it out somewhere else? Does that information need to be out there in the first place? From the U.S. side, does the SSN number have to be on an API? Does the address have to be on an API? Is that information necessary for the API to process? Those are the things that you need to think about.
Katie Paxton-Fear: I 100% agree. I think what separates out a lot of API attacks from other attacks that we see in the media is how targeted they are. If you look at something like ransomware, it is targeted. Criminal gangs will go after specific industries and they’ll go after the entire gamut of those industries, a bunch of different companies in that industry. However, the difference between that is that it’s often very opportunistic. There’s a vulnerability or there’s a known flaw that they can exploit and get the ransomware on the computer, or they’re just sending a bunch of phishing emails and then whichever company clicks it and runs the malware, that’s how they get infected.
One difference we see in API attacks is that the kind of attackers that go after APIs, they know what they’re doing. They often know about things like what the API does. They know that wider context. They know it’s got a social security number. They know it’s maybe got credit card information in there. They know that. They understand the API. They’re understanding the attack surface. Often, they can actually understand your API attack surface better than you do. What’s important to know is that most API security vulnerabilities are not ever going to be massive vulnerabilities. We’re never going to see the API security vulnerabilities on pure technical merit alone. It’s not like the hardware security people. Most API security mistakes are that little mistake, small mistakes.
In the entire library of an entire API where you have hundreds of endpoints, you have thousands of users, you have millions of requests every day, you just cannot spot the malicious stuff among all the noise. It might be the difference between one line of code and two lines of code. Where I see the most as a hacker is often silly little mistakes made in things like authorization. There’s no if statement to check if a user owns that object before they start to edit it. There’s no check to make sure the user’s logged in. Those are, again, silly little mistakes. They’re not massive, huge fundamental shifts in the way we think about technology. They’re, “I just didn’t write that”, kinds of mistakes.
API Monitoring
Renato Losio: I was thinking, as Katie just mentioned, sometimes there’s little mistakes or little things. In a large number of APIs, I might have an entire SDK, hundreds of APIs, whatever it is. How do I monitor? Do I monitor my API for that? I’ve built my nice app. Let’s go back to the example we had at the beginning of an app. Maybe I haven’t even published my APIs, but still, there’s something there. What should I do? Should I do something?
Zsolt Németh: It depends what you want to do. There are lots of open-source tools, but Harness is one of them, and so on, what you could use. From my perspective or our customer’s perspective, yes, we can put Falco in it for runtime container security, but more basic stuff. I think it’s mandatory now everywhere to sign your container, so that you use Cosign, or something like that.
Renato Losio: The way I see it, as a developer myself, either I’m using some managed tool, whatever, it’s from a cloud provider or something else, where I have some API, build my API, I build just my logic. Then the only real monitoring that I’m doing sometimes is just on a number of requests, error rates, or whatever. That as well doesn’t tell the full story, because as Katie mentioned, it can be a single mistake that opened up. Not necessarily I’m going to see a huge spike of errors or whatever, and my data might be out there. I was just wondering what I should do as a first step.
The Danger of a Malicious API Structure
How dangerous can an API malicious structure be for a company?
I assume it can be as malicious as not having the company anymore.
Nivedita Murthy: Think about traversal. We have something called as, you jump from one box to the other, the same thing can happen with an API as well. I think Katie mentioned an example where she was able to pick up an internal API from an API that was external. How we look at the structure is, is it sending information about an internal API that is not supposed to be available to other users, or, are you able to jump from one API to the other without verification? Maybe you need elevated privileges to use a certain API, but if you jump using one API to the next one, does it allow you to go over there? You have to think about, in that sense as well, as to, is the entire API design a faulty way by allowing to go places where you’re not supposed to go in the first place.
Katie Paxton-Fear: There’s two things to think about. I’m going to answer both of them because I’m selfish. If you’re wondering, do I have a rogue, malicious API? Has an attacker deployed an API on my systems for their own usage? That is bad-bad. The second attackers can deploy anything on your systems, the entire system is compromised, like full stop. If that is happening, you need to turn it off at the wall, like switch it off, do a full recovery, because you just don’t know how deep they managed to get into your infrastructure. If the question is not necessarily, is the API malicious, but are malicious users using an API, how bad can it be? It’s like saying, how long is a piece of string? It really depends on what that API is doing, what sensitive data it’s handling, what sensitive processes it’s handling, because it’s not always about data. Sometimes it’s about processes as well.
Somebody asked me once, they were like, is API security a million-dollar problem? I’m like, it depends on how many APIs you have and how valuable they are to your business. APIs now often are such big drivers for organizations to grow in terms of customers, to provide them as a product, just to enable people to deeply connect to them. Look at the backlash when Twitter removed its API from being able to be public and people had to pay for it. That caused massive backlash. APIs now often become the crown jewels of how a business functions. If you’re wondering, how bad can API security be, what industry are you in? If you’re in finance, maybe it’s financial losses, maybe it’s loss of customer trust, maybe it’s a further breach where they use APIs as an initial access point and then pivot into other systems.
Really, APIs are so dependent on the context in which they run, and that really makes them unusual when compared to other web applications as well. I can’t tell you how bad it is unless you tell me the company you work for, and then I’ll tell you as a hacker, here’s what I would do and here’s how I would target it and here’s what I would go after, because this is what I would see as valuable.
Open-Source Security and Monitoring Tools, for Devs
Renato Losio: Zsolt before mentioned some open-source tools, I would like to go a bit deeper in that sense. If there’s any tool that you think, not as a security expert, but a developer should be aware of, or should be familiar with, or should use to protect or even just to monitor, whatever. I don’t know if you have any recommendation.
Ben Bridts: It’s a hard question because there’s flaws with a lot of them. I think knowing about JWTs and how they work and what the pitfalls are there is probably the one that’s going to give you the most value. Wherever you’re working in the industry, you’re probably going to have to deal with that at some point.
On the other hand, if you want to look at what would be good authorization design or a good way to secure your API, I’m not the biggest fan of them necessarily. Very specifically, but I assume this exists in other clouds as well, for AWS, looking at how their Signature Version 4 signing works, for example, and how other people use that to imitate S3 in some cases. This is cool to have in your back pocket of how you can design APIs to only trust a request one time. I think it’s very useful and very good to know. I’m not sure if that is something that I would be able to implement at my day job as a developer, to come up with, now we’re going to full sign every request and have nulls on there, like you can only do it once. It’s going to be valid for a minute and then we throw it away. I would start with JWTs.
I also would really recommend looking at using a library for that. I think Google has a good one in Tink for that, that turns off all the things you don’t need. Turn everything off. There are so many things in there that you don’t need, just turn it off. Only use the specific thing you need.
Modern Programmatic Techniques of Securing APIs
Renato Losio: What is the best modern programmatic technique of securing an API? Does it depend on the type of API? What about two or something else?
Zsolt Németh: At a high level, I can start with that. How I would do it or how our guys are doing it here is that they’re not kind of collecting tools. We have OVAL. We have Kyverno. We have Oathkeeper. Basically, they focus on the weakest spots of the architecture, which either they find or we tell them that this is going to be a problem, have a look at it, and solve that specific problem first. Obviously, you can pre-scan your API pre-deployment. You have tons of tools for that, and so on. Basically, I think you should solve the problems first and not finding the problems, and trust the security guys or trust the security team to actually point out these problems first.
How to Identify a Compromised API
Renato Losio: Do you want to answer the one-million-dollar question of how to identify that your API was already compromised?
Katie Paxton-Fear: It’s weird because as an API hacker, I don’t often see that. I often am on the outside looking in at APIs. Some things to be aware of is, one, large amounts of data being transferred out of your organization. That’s the standard one. You’ll see it a lot mentioned because nowadays, we are seeing really large data breaches, as Nivedita said earlier. We are seeing people going after PII especially, usually to use in other kinds of attacks.
Other things to keep in mind, though, if you’re working in an industry, knowing what’s happening. In fact, the biggest recommendation I have to any developer ever about how to learn about API security or just security in general, go to a security conference. Go to your local BSides, go to DEF CON, go somewhere like that, become immersed in that world, and you will probably know what to look for. You’ll be able to see how that interacts with the system you have because you’re an expert in that, way more about than anyone else is in terms of how your organization is laid out. Actually listening, these are the kinds of attacks we’re seeing.
These are some of the IOCs, Indicators of Compromise that we’re seeing, like check these out. I think the number one mistake any organization makes is just doing nothing. When it comes to API security, it’s often left as a nice to have. People aren’t actively investing in it, so there’s not an awful lot of tools that can give you that information. There’s not in-depth monitoring and logging for APIs that you can easily get that’s free and open source. It’s a very specialist solution. With that, it makes it challenging, because any indicators that I could give you, you would have to have the right setup to look for them, so looking for them in the first place, having a process that you could go through those logs, review them, see what they say, go through that, how would I investigate this kind of attack? Creating those runbooks can often be far more valuable than any kind of individual indicator that I could give you, for example.
Renato Losio: If I understand, I need to have the logs. I need at least to keep an eye on my networking activity.
Nivedita Murthy: As a developer, especially someone who’s working on APIs, you definitely have access to Postman. Start off with, just try and manipulate the values that you’re sending to see how it reacts. Don’t do it like normal user functionality, I think, as a malicious user, maybe. Add an extra character, add too many numbers, for example, or just remove a filter and see how your own API reacts to that scenario. That’s your first step to testing out, is your API vulnerable to malicious attacks? Like Katie mentioned, this is a specialist scene on how to monitor whether it’s being vulnerable to, let’s say, multiple attacks out here.
One thing I could provide is, there is a page on the OWASP website. When I say OWASP, it is Open Worldwide Application Security Project, which gives a lot of free resources and open-source resources for securing your application, and also guidance on how to do that. There’s an entire page which lists out both commercial as well as open-source projects that’s dedicated to API security. You can pick out one of them, and see how it works, try and use it, and see whether your API is secure or not in certain manners. There are limitations to each tool for sure, but you can start off over there and learn how good is your API in terms of security versus how bad is it.
Resources for API Security
Renato Losio: What is a tool, what is even a paper, podcast, book, or even a conference, as Katie mentioned, that you recommend every developer should not miss? I don’t know if you want to give an advice, an idea for, go out of this roundtable, listen to this podcast or go join this conference, or something.
Ben Bridts: I help organize fwd:cloudsec in Europe, so I’m just going to mention that. I really like that one. Look for security-specific conferences. I think the OWASP thing is also a good thing to look at. I think we maybe should pivot back to APIs and Zero Trust, but the base vulnerabilities of sanitize your inputs and know what you’re getting. Especially in this time, don’t trust your client. Anybody can open your app and see what’s in there. Those things are also still going to be out there. That’s not new. We should just keep talking about it until more people fix them.
Zsolt Németh: I would go to the conferences as well, or if you’re here in the Bay Area, so a lot of meetups, but probably that’s happening everywhere as well. I know in the Netherlands, it’s a lot of activity going on in terms of security, not specifically an API, but more like Zero Trust, I’m sure.
Understanding Zero Trust in API Design
Renato Losio: As I understand it, Zero Trust in API design is primarily a concept with tools supporting each aspect, like assume breach maps to short-lived token, or never trust, always verify, map to OAuth on every API call. Do you have any comment about it?
Katie Paxton-Fear: When it comes to Zero Trust, it used to be far more prescriptive of how to meet these. It’s become much more a lesser methodology and more a philosophy around how you do security. With that, the way you implement Zero Trust in your APIs as you’re creating them can look really different. If you go with assume breach, that can mean short-lived token. It can also mean, what other APIs does this API have access to? What other data does this API have access to? Ensuring that you have things in place to not just have short-lived tokens, but also to recognize a compromised API to do something like rotate secrets, or something like that. When we talk about the idea of never trust, always verify, again, you can do that in multiple different ways. It really does depend on that API. I would say for Zero Trust, like practically how I would implement Zero Trust in an API, would be, follow the advice of assume breach.
Go through every single API and ask yourselves, if this was breached, what would happen? What would they do next? Even better like, I think Nivedita is absolutely correct, learn how to hack. Have a go at hacking. Have a go at API hacking and have a look into what attackers can actually do to help give your team ideas. Also, it’s just fun.
For a lot of developers, you don’t often get to do something just for fun. I’ve actually had quite a lot of good experiences with developers of teaching them how to hack to get them more engaged in security, but also have them thinking about security and what an attacker could do. It’s really about getting in that mindset of an attacker. There are some good easy wins there. OAuth, easy win. Tokens, easy win. Having expired, like all of them are easy wins. Fundamentally, they are easy wins. They are first steps. They are baby steps. There is a lot more that you can do to really inhabit the philosophy of assume breach.
Resources for API Sec, and Security in General
Nivedita Murthy: To the previous question, yes, security conference. The other thing, listen to some podcasts which is outside of application security. I like to listen to something outside of my domain just to get some ideas as to how attackers try to do things outside of it, and maybe apply in my application. How can I do that same thing? Can I replicate that in a way in my application, or use the same method? The one which I enjoy is by Jack Rhysider. He talks to various people and their experiences, what they have encountered, how did they open up an application.
There was one where someone made free video game money out of the video games by just changing a value or something. That was fun to listen. Those same principles can be applied in API. I would definitely recommend just listening to some stories. You can listen to that on podcast. You can listen to over here, like this webinar, or going to conferences or even local meetups, and just talking to people within the industry about their experience and what have they been doing out there.
Ideal Starting Point in API Security
Renato Losio: Until now, I got super excited thinking about being always in a brand-new API, start from scratch, zero principle, all great. Now, I’m in my reality, day-to-day programming job, and suddenly I have my 200 APIs already there written in Java, .NET, whatever you want, with some database behind, some authentication already in place. I want to do something in the right direction. How do I tackle it? Just ignore it, start from scratch? What are the baby steps in this case when I have already something in place? Where should I start?
Zsolt Németh: I think I’ll just reiterate what I said a bit earlier. Start with the weaknesses that you already have, and fix them one by one. We won’t get to zero weakness anytime soon, but your security posture is going to be much more solid.
Ben Bridts: My first reaction is you probably know in the sense that like it’s your APIs, it’s like your bunch of things. The question is like, what are the things that you feel like this is important data that’s behind it, or this is something that’s going to be a problem if somebody does something wrong with it. Or the other side of it, like what’s the thing you haven’t touched in 10 years? You know where the bodies you’re hiding is in your closet. Start with that one.
Low-Hanging Action Items and Key Learnings
Renato Losio: What’s an action item for our audience? Give an advice of what you can do tomorrow as a first step to take the advice from today and do something tomorrow. It doesn’t have to be, change the code, can be even just read a book, can be, see a podcast.
Katie Paxton-Fear: Literally anything. You’re doing better than 10% of organizations if you do literally anything about API security. Most folks have their head buried way in the sand. Simply listening to this, you’ve already taken your first few steps. Now it’s just time to keep on walking.
Nivedita Murthy: This is the regular advice I give all my clients in general. Have an inventory of what you have. You will then realize that there’s something out there that you created 12 or 15 years ago, but never used it, but it still exists as of today. You might want to just do a cleanup of your inventory or your APIs. Just whittle it down to a manageable number of APIs that you can think of, and which one’s important versus not so important. Just create an inventory, have that list ready. I love lists, create your list of APIs here.
Zsolt Németh: I would do actually much simpler. Go to ChatGPT and ask for a detailed plan. No, I wouldn’t. On a serious note, I would start with reading because I’m old school and I like reading. I would basically read, even just horror stories of what happened with unintended APIs, or when people figured out that, there was a behavioral drift in our API, and they figured out nine months too late. There is no too late. I’ve seen a couple of CISOs being fired because they noticed something way too late, and the attacker dwell time was usually like 5 years plus, not to mention one. Basically, I just want to rephrase what Katie said, yes, anything. I would personally start with reading short and sweet stuff.
Ben Bridts: I have two things. The first thing is like, go have fun and poke around your stuff. I’m not a serious hacker at all, but what I do is every time there’s an internal app, like we have to reserve parking for somewhere, or there’s like, this is how you book a meeting room, and you get a mobile app for that. See how that works. You’re a developer. You can do things that they don’t want you to do. Reserve that meeting room that’s only for the director, or stuff like that. It’s a very fun way to learn how those things work and to see what’s available to someone who is not trusted with the thing. You get the device, like they don’t trust you, but you can do all those things. Secondly, go get those donuts from the security team. Just talk to each other. It’s really helpful for both sides.
See more presentations with transcripts
