Episode Summary

In this episode, Cole Cornford speaks with Anand, an API security expert at Traceable AI with over 18 years of experience in crafting innovative IT solutions. Anand's expertise spans API design, microservices architecture, cloud technologies like Kubernetes and AWS, and security architecture including IAM and OAuth. Together, they delve into the critical importance of API security in today's digital landscape, discussing why traditional web security measures are insufficient, lessons learned from incidents like the Optus breach, the challenges of managing API inventories, and how AI and machine learning can enhance security practices. Anand also shares his experience writing a book during the pandemic and the value of continuous learning. This episode is packed with insights on modern application development, cybersecurity, and plenty more.

Timestamps

4:20 - Understanding API security challenges

9:30 - The role of AI in API security

16:55 - The importance of API inventory management

24:00 - The business impact of API security

28:00 - Cole & Anand discuss books & writing

34:00 - Current state of API security in Australia

Mentioned in this episode:

Call for Feedback

Hi, I'm Cole Cornford, and this is Secured, the podcast that dives deep into the world of application security. Today, I've got Anand on my podcast. Now, Anand has been participating in the API industry for over 10 years. He's been in all sorts of consulting firms. He's been at Kong, which is an API gateway company. And recently, he's moved over to work at Traceable. You are bringing a new approach to API security to the Australian market.

Now, with that, we spend a lot of time discussing really technical details of API security, whether it's how traditional solutions that are protective controls, are not very good at doing broken object level access or that we can't really even do asset discovery and inventory management of APIs effectively to enterprise scale, let alone even at smaller businesses.

And even just how the industry has evolved over time from just looking for malicious payloads to looking at the historical way that APIs should be consumed and then trying to leverage that intelligence to make better business decisions. So I think it's a really interesting conversation because we move away from just purely about the technical details for API security and also into how it affects businesses too.

And I'm a big proponent and supporter of Traceable. I think it's good that they've got a really different way of working than most of the existing players. And so go have a listen to the podcast and tell me what you think. So without further ado, this is Anand. Anand, how are you going, mate?

I'm doing awesome. The weather is nice. We are getting into spring, so enjoying the weather and looking forward to jumping in the pool very soon.

I always tell the story all the time, but I used to work for a company out of the states, and when I started Galah was because my missus was saying to me, "Hey, Cole, you work 2:00 AM until 11:00, and then you clock off from work and just go swimming and drinking beer in your pool, have you considered doing something productive of your life?"

And I said, "Oh, I don't know. What does that mean?" She's like, "Maybe you should think about, I don't know, a business." So then I just rang up ASIC basically, and I was like, "What is a business? How do I business?" And here I am, four years later. So I'm looking forward to jumping in my own pool. So it'll be fun to take Monica for a swim now that she's pretty much approaching two, so she'll just have a great time bundling around in the water being useless.

So yes, enough about swimming. How about you tell everybody a bit about yourself and what you're an expert in and how you even got there?

Yeah, so my name is Anand Rai. I worked for a company called Traceable AI. So Traceable AI is a company based in the US and we worked on API security. Before joining Traceable AI, I was working for a local brand, I think you all know a company called Versant, and I was a Facebook solution advisor. Prior to Versant, I was product manager, product manager for Kong API Gateway. I think that's also pretty much every listener would know about that.

And prior to that, I was in Axway as a VP of pre-sales. In between, I had a short assistant at Macquarie Bank working as responsible for API and integration architecture. And before that, did a number of other companies. But my background to summarize is into API. I've been as an engineer, as a designer, as an architect. I've been doing building solutions around APIs. And then last nine or 10 years I've been working for different API companies.

I'm also in love with things like Kubernetes and Service Match. I wrote a book on Istio last year. It's called Bootstrapping Service Mesh Implementation using Istio. API fascinates me and there were a few things in APIs, especially around API security. I was very curious about, around 2019, I even wrote a paper internally for a company that I thought we should be doing.

And it's I think in the last two, three years with accessibility to AI and machine learning and so many advances in technologies. I saw my dream of that modern API security is getting realized by companies like Percival. And that's why I'm here and talking to you about API security today.

Yeah, I think that it's quite topical. That last couple of years has been a lot of things going wrong because of people either forgetting that they've got APIs exposed or they're misconfiguring them. I know that the NALA service is happening all the time as well, and it's always felt like the general response was to stick a WAF in front of your APIs and hope for the best.

And I don't think that's been terribly effective. But yes, maybe you should give a bit of a background about what even is API security from your perspective because I feel like a lot of people still think that it's as straightforward as validate the input and you're good.

Yeah, yeah, sure. In past, I would say past 10 years, probably around 2015, that's when microservices became popular and there were so many APIs getting built. Right now today we can say, I think I had some numbers from Cloudflare that Cloudflare is a CDN and they say that 55% of their traffic of dynamic traffic flowing via Cloudflare is API traffic.

So APIs have become a mainstream integration technology, especially with the increased adoption of cloud native application, microservices, architecture and API driven application. API become, you can say, a critical glue that bind almost everything to everything else, including internally as well as to the external world.

What has not grown as quickly as API adoption is how we secure those critical communication. Most organization will attempt to secure API with traditional web protection technologies like WAF, API gateway, and they treat APIs same as they treat any other web application. But there's a big difference between a web application and API. And API is a web application, but it's a different kind of web application.

In past three, four years, there has been an explosion of APIs to a point that APIs have become man-managed. I'm sure we all are familiar about Optus. I advise everyone to go and read about the Optus case, the litigation file by ACMA know we can search for it and you will see the code filing by ACMA.

You will see usually when such things happen, we can't even interpret or guess that what would've gone wrong. But in this case, it is written, it is filed in court. So you can see things like API and lack of API inventory management, having so many APIs and with so much agility and cloud-based development where developers are building things very quickly, they're releasing, doing very frequent releases.

Everything is as a code, for example, security is also as a code. So it has become more and more highly likely that you can do a mistake and it can go unnoticed. Optus was one classic example where an API was exposed, internet-facing returns customer data was exposed since 2017 but was inactive. But then in 2018, someone accidentally removed the access control from the API, still no notice.

And in 2022, someone exported the API to steal 36% of Australian consumers' data. So that's a classic example, and that can happen. We see a lot of that happening across the globe with various companies and having a WAF, saying that we do a pen testing every three months or every release I have an API gateway gives you a false sense of API security.

So yeah, so our goal is to educate organizations on why, what is that false sense of API security and what is a modern way of securing your API and what technologies do exist to help you secure those APIs more confidently and protect your assets.

Yeah, I think that the traditional approach of just applying what we used to do for web applications in the API ecosystem just fundamentally doesn't work because if I think about say, static analysis, our traditional static analysis is to look at attained analysis. So we are going to say, how does data flow through this function and end up from a source like a web request or a file or whatever into an executable context where something bad happens.

And the problem with doing it for a serverless or cloud native API is that generally these SaaS tools operate on a single piece of code, and that's one API, but has no visibility about how each API calls a different API because they're usually not at all entwined within the same code base. And so I've found that a lot of traditional SaaS vendors have really, really struggled to actually move across into API world.

And even when I think about penetration testing, it's a point in time analysis. Now, the speed of development is that hopefully, people are updating apps on a regular basis, and these APIs may be ephemeral and active only for a very specific period of time, especially if they're serverless assets.

And so when you do a penetration test, who's to say that what you are testing is actually going to be the same asset in the next five minutes, let alone in two weeks time when you finish the test. And so I don't think that that type of assurance activity, like the ones that we're used to, works in an API ecosystem. So how does a product like Traceable help companies with managing the risk associated with custom-written APIs?

Yeah, I always say your production environment is a shape-shifter, if you know what a shifter is, it's evolving all the time. When it comes to securing your API, what we need is a 24/7 security posture of API. So you need to monitor every assets which is exposed to internet via API to see that how secure they are.

So I will give you some examples. So for example, I asked these question to organizations a lot, and I'm going to ask this question to all the audience listening to this podcast. So imagine you have got an API, which is returning non-sensitive data, or let's say, which is returning our data. So let's say it's called a GetCustomer API for example. So a logged-in user logs in and gets a customer data using calling that API. And often this API would be interfaced by a front-end application.

So the user is not calling the API programmatically, they're going to something like internet banking logging in and then fetching their profile data. So let's say something goes wrong with this API and that API starts returning number of unique set of user data.

Then hypothetically, let's say if that happens, how quickly the cybersecurity teams will get notified about that happening in production. I mean, if you look at the traditional way, you will pick it up when other end-user, what happened with Qantas app where I log in and I see Cole's fly detail or something like that, or maybe someone testing the API or maybe we do a pen testing and you find it.

As you said before, the API and the underlying building blocks enabling the API are changing frequently. So the mistakes can do happen. The API itself just is a delivery mechanism. It might be relying on another system to provide the data, and the data might be nesting data from somewhere else. So if something goes wrong in that supply chain of software building blocks, which are empowering this API, how quickly you can pick those changes and do something about it?

So the approach we take is we rely on AI and machine learning tools to inform us about, first of all, understand what is a user behavior. So when I say user behavior, sorry, when I say the API behavior, what I basically mean that there are different contexts under which the API is called. And there are different environmental factors.

For example, who the user is, who's calling the API, what is the role when they call the API, how they are authenticated to that API, from what device they're calling the API, right? On what network the device is placed from where they're calling the API, how frequently they change the device when they call the API.

The API they're calling, what sort of data that API is returning? What sort of vulnerability are already known in that API? What is the threat landscape at that point of time? The business function enabled, whether that API, how important that business function is for the company and so on. And these are just very small number of contexts I'm talking about so that we can easily understand.

There are many number of contexts we need to be thoughtful of. And so we look at all these contexts and then decide that if this particular API call which is happening, is it safe or not? So we do things like baseline behavior analysis so we understand what is a baseline behavior, what is good, and then if you find something which is not aligned with the goods, is it anomalous?

Is it anomalous but not malicious or it might be malicious too. So we use different machine learning models to identify that behavior and then we look for all the abnormalities from the baseline behavior and then we pick that up and then we can raise alerts or we can take actions to stop that exploit from happening. So that's one way.

We also have things around testing for example. Most of the traditional testing people do is like DAST or SAST. We have taken a different approach what we call as an xCAT. So in xCAT what we do, when you do a normal testing, you need to know what users you'll be using for testing the API.

APIs are not just API, they're part of a transaction. So you are doing a transaction, and when I say transaction, I basically mean I'm a user. I log into my mobile banking, I fetch my profile, I get my list of accounts, I click on one account, I get the account detail, I make a transaction, I fetch a statement, and so on.

So when you test an API, you want to test an API as if it was used by a real user in a transaction. So often, organizations will not know in what sequence and APIs are called, what are the different transactions in which the API participate. So what we do, because we see the production traffic and we are doing this baseline behavior and we are doing various contextual analysis, so we can form those transactions.

And then what we do in your non-production environment, we can basically mirror the actual traffic coming to your non-production environment. And then in the mirror traffic, we can do threat injection and then we can replay those transactions to test those APIs to find any vulnerabilities proactively.

What I like about it is you're basically creating a call graph. So you can say that we've analyzed this existing behavior of all of these APIs and we understand what is the transaction from end to end. And so this is the call graph and if you know what that flow is, because it's just a graph representation of how different APIs call each other, and it's not like one API just calls one other API, they can call a variety of APIs.

So your graph, that's why it's a graph, it's not just a flow. And then from there, it's often quite difficult for manual testers to have the exact same way to test these APIs because they don't know what that backend actually looks like. Do you ever have to worry about timing or race conditions? Is that something ever comes up in that kind of scenario?

Not really. For example, our goal is to break the APIs. So we are doing vulnerability injection, so we do want to test risk conditions. So I think we do not come across with issues. This sort of testing apart from the external APIs also very important for internal APIs. So if you ask companies that, hey, have we really done vulnerability testing of all your internal APIs?

So we actually worked with an organization who had 2,500 internal APIs, we call it as East-West traffic or East API. And they had this regulatory compliance that they have to test all the internal APIs. When they did some analysis, they realized that it's around 25 person days effort for every API to find, first of all, to know what those APIs are, to reverse engineer their spec to understand a payload they can use to call the API to understand the graph you mentioned.

So if you take 25 days multiplied by 2,500 APIs and multiply by average dollar rate for a person to work on that, it's basically a lot. So what happens then, you don't do it.

Whereas with the CST example I gave in that example, you just turn it on and then all of a sudden you will have a hundred thousand test cases run across so many APIs and a report saying, hey, we found all these vulnerabilities and these are the mitigations you should be doing. So that's quite powerful. And the goal is to protect your API stack, irrespective of it is external or internal.

Yeah. So for me, I think there's a few things that I care about when I think about APIs, because I would say I need to have a good understanding about what even exists in my environment. And almost every business that I've ever spoken with, they barely understand what software assets they have, let alone are able to go a little bit more granular and starts talking about APIs or dependencies or containers.

Even in cloud environments, oftentimes they have no idea what they're doing. So I think it's important to be able to quickly identify what assets they have, which ones are. And for the audience, unless you've done networking, you may not know east west and north-south. But all we're talking about, I might be wrong for this, but you are probably smarter for me. North-south's data coming in, data going out of a business and east west is that traffic that's within your business going left to right. Yeah.

Within your network is east west and anything coming from outside your network is north-south. So you are very spot on. So inventory management is the first thing you need to do. So you need to understand all your IT assets. APIs are also your IT assets which are exposing data or delivering business function.

So you need to understand what are the different APIs you have exposed in your network. Traditionally, what people have been doing is they will have a domain, they will say, okay, all my APIs come from API... Right? And they'll ask someone to go and scan the domain for all possible HTTP endpoints and they say, yep, this is my inventory.

So that's approach I call as outside-in approach. And the problem with that approach is that you are trying to find APIs with the domains, right? I mean it's just like you're trying to find the known unknowns.

Whereas what we do, we take a push call inside out. So we basically see from inside the network that what all data is coming into a network, so what all the different endpoints are getting access from outside, not in one day or a period of time. And then we distinguish those access from normal access to API access.

So is it really an API call? For example, might be getting a call to access a CSS file for us that's not an API know. So anything which has got that API footprint. So we find those API footprint, so we find them and then we list them as the endpoints we have discovered. That's just a step one of inventory management.

The step two is to then reverse engineer their spec, like what is a shape and form of the API, what input it takes and what output it returns and so on. Then we go and engineer the spec of those API after we have done that. The third thing is to classify, to apply data classification on those API because APIs are as good as the data they return.

APIs are just a means of delivering data or accepting data. So we try to understand what data is coming in, what is the data sensitivity. So we apply labels to of data on those APIs. So we'll say, okay, these four APIs are handling PII data, these five are handling PHI, these are handling non-sensitive data so that you know these assets are handling these kind of data.

Once you have done that, so that's number three. Number four is to then understand the risk posture of the API. Like, out of all these APIs, which APIs are riskier? So for example, what vulnerabilities are hiding in those API? How many of them have got the right authentication? How many of them are handling encrypted data and so on.

So yeah, so this posture data classification, their specification and their list is what we constitute to the API inventory. And that is the first step you start, you do on the API security journey.

And I really like that breakdown because if you don't know what you have, it's hard to protect it. Once you've figured out what you have, then you need to know what is the purpose and how do each of these things work. And then you need to know what data is being handled and if it's exposed or doing something important for the business.

So that lets you start doing either attack surface reduction and turning off APIs that are not necessary, or at least not prioritizing controls on things that don't matter. Because ultimately, if you look at point solutions like WAFs and API gateways, do you really want to be leveraging each of those when they cost money and putting them in front of things that are internally exposed assets that do stuff that just doesn't really particularly matter for your business?

But you absolutely want to have those if you know that the data coming into those is coming from a source that is completely untrusted or is externally exposed or so on and so forth. And what I like about this is I think you can look at API security, not just from a pure cybersecurity perspective, but using this product you can also say, hey, we have all of these APIs, which we know we're spending a lot of money on, but they actually haven't been used and now we've got evidence over six months that they haven't been turned on or touched. So maybe we'll just go turn those off.

Or maybe we've got the ability to do different types of analysis because APIs, their payloads are really quite distinct. They have weird, weird purposes all over the place. It could be authentication, it could be running banking transactions, it could be purchasing some kind of asset, it could be operations, it could be updating photos on the internet.

And so some of these have business cases that are important like understanding how somebody's going through an e-commerce transaction and identifying that they're all dropping off at a certain location. And you may not be able to do that without using a product like full story or something that lets you see what the customer journey is end to end.

Well, why not have that customer journey coming without having to use a third party integration? Because you can look at the API calls, right? So what other scenarios and use cases outside of security, do you see this style of inside out analysis creating?

Yeah, once you have the API inventory, you are better placed to make decisions. For example, what if an API is getting used a lot, but you never invested revamping that API or making it better?

I mean, you can find out which are the most used API. Also, if there is an API, which is returning highly sensitive data, but you never knew about it. So this comes a lot. I did analysis I think four years ago that what is how... APIs are designed also for use. These are like Lego blocks. So you design them to be reused by a number of other systems.

So it's like building a business function, which can be then be plugged into different business processes and be used by other parts. But APIs are not reused. Why? Because first of all, you do not know what APIs exist. You will know them when you build them, but as the generations come in, two, three, four years pass by, you lose track of what you're building, the developers are gone, the contractors are finished. So you lose track of what you have built.

So because you've lost track of what you build, you cannot use them. Even if you find them, then you do not understand how to call them, right? Because you don't know what data to pass, what data to expect back from the API. Even if you understand that, there's always some chronic cases where you will need something more.

In that cases, you are very scared to change the API code because you do not know what else will break because there might be other consumers calling the API. So I mean, API inventory not just gives you a better security posture, but also drives reuse and adoption of API. And in long run, will reduce overall cost of API. Why? Because you are now getting a better ROI on those APIs.

And that's obviously a really good business investment is to work out where you should be spending the most money. If you've got a single authentication API that's used across all of your suites and you've only just noticed there's actually a backdoor one for some reason that half your business has been using and you put literally no security protections on that whatsoever, it just makes sense to me to say, okay, well I didn't know that was there and I don't know why people are going around the main API. Maybe it's too hard to use it.

But yeah, it's an interesting space, mate. What got you really interested in API security? Because you said you've been there for over a decade, so it's clearly something that's been a passion for you for quite a long time.

Yeah. Look, I said before, I come from API I integration background and API has become the de facto for integration. So everything is integrated with API. I love APIs, I love cloud, I love microservices. I love service mesh. So what really makes me happy is that when I'm able to help someone solve a problem, then you really get that satisfaction.

And I see that this API security problem is so widespread across organization. Most of the people are not really well-informed about APIs and how to secure the API. So they have this false sense of API security that, yep, I've got API getter, I've got a WAF, I've got this controls and I'm really safe.

And it's really sad to see when things like Optus happen, when things like contest issues happen and so on. So working at Traceability, we try to help organizations to make the right decisions and educate them about trying to securing APIs.

That's it. So what was it like writing a book, by the way? I know a lot of people during the pandemic, they went hard at just picking up hobbies. Some of my friends were into starting businesses, I guess like me, other people were baking bread or just picking up things they could do for home. But you went for writing a book. So what was that? What was that process?

Two reasons for this. So one was I consumed a lot of information from internet from different articles on Medium and so on. And I always thought that, am I contributing back to the community, taking so much information but not really giving back? So Istio was a complex topic and a lot of users like me were struggling to understand what Istio does.

So book was one way to contribute back to the community. I'm a big fan of reading books, so I read lots of books. So was one way to contribute back. So that was number one. And number two was my son was preparing for exam and he was saying, "Look, I study so hard." So I said to him, "To match your study hours, I'm going to also do something which looks like a study."

So writing a book was more like to also inspire him that if you decide to do something, you can get it done. In 10 months, I spent around 1,100 hours in completing that book along with working full time and working for the US company when I start my day around 2:30 in the morning. So it was tough, but I came out good at the end.

You're still going. All right. So I remember doing the stint where I had to do that, and oh man, it was very, I guess time was ephemeral, it didn't really matter too much, but during the pandemic I could have just woke up at one AM and no one would've known the better that well, and all my colleagues were looking outside and saying, "Hey, is that the sun rising?" And I'm like, ah, yes, that's great fun to do that. But yeah, it's a tough gig.

I also have a few friends who run businesses that are global and they follow the sun, and I'm just like, when do you get to sleep? And then they laugh at me through bleak bleary eyes saying I have made a mistake. So I agree with you about books by the way, and it's something I want to dive into. I find a lot of people focus on, I'm recording a podcast right now, but podcasts is quite common. They learn from podcasts, but I also find that as more entertainment than it is specific directed learning.

And then video content as well as blog posts, which I think are actually pretty short shot and not necessarily as well-thought-out as a book. And so I encourage people all the time to say, the thing about books is that the amount of effort that goes into it, and it's not just writing the content, it's actually structuring everything. With books, what I find is that authors have to be... They need to know their topic extremely well. So they'll do inordinately more research than someone who is just writing a blog post for just getting clicks on their website.

Secondly, they need to structure it in a way that's both consumable and that they just distill a lot of content into something that's really hopefully comprehensive but also readable. And I guess the last piece is the sheer amount of editing and effort that goes into creating a high quality product. Because books generally are high quality products.

When you consider that everything else that's like a TikTok video or just a YouTube explainer or a how-to blog post can often be like ChatGPT content, farm rubbish that's just pushed out there. So I'm a big fan of books as well. So speaking, if you're a big fan of books, I'd like to know top three books that you would recommend to people.

Interesting. I have got few. So what sort of book? Like technology books or career development books?

Just go for books that you are interested in that you think are helpful for people to learn from? And again, one thing I love on this podcast I ask about books a lot. And the reason I do, and I never say, Hey, what's your favorite hacking book or your favorite API security book or whatever. I'm pretty certain on my shelf behind me, I've got API Microservices Security and Action and Micros and API Security sitting over there.

But for me, I like listening to people when they say things like The Design of Everyday things because it helps me learn how to do user experience or the Wealth of Nations because I had needed to learn about how markets worked to grow my business. And so I'm a big fan of getting books that are from completely different disciplines and then bringing those perspectives into cybersecurity discussions. So what are the books you recommend?

So probably I would start not with the technical books, this book is called The Mind Illuminated. It's a really nice book written by a researcher who researched on meditation and it talks about the five level of meditations you can go through and how to meditate. Believe me or not. I have bought this book seven years ago. I have not even reached level one of the meditation, but this is really an inspiring book. It just gives you a different perspective about life and meditation.

The other one's called Designing Your Life by Bill Burnett, and it says How You Can build Perfect Career step by step. I have read it in, still not build my career, perfect career, but I'm trying to. And the last one is anyone who wants to get hands-on with machine learning, it's a book called A Hundred-page Machine Learning Book by Andrew Boko. It's a book, it's a small book designed for so that we can read them over two weekends or maybe a month.

And you'll not understand fully this book. But you'll get all the buzzwords and get some idea of what machine learning is, what are the key algorithms and models and so on. Yeah, so I always say because reading book requires investment of time, so you choose carefully where to invest. Yeah, so these are my three favorite books as of now. They keep changing.

Everyone, welcome to the book club. So I'll give a few more tips I have for people who love letting about books. I don't get talk about books much. Let's do this. One is if you pick up a book, you don't have to read it start to finish. You can just abandon it if it's poorly written.

And if you also don't like the author or a way of read, it's not a failure on you to choose to just say, this is a bad book and I don't want to read it. So just feel free to just pick up something, start reading it if you hate it and throw it away. So I know another thing is you don't have to read things back to front. You can just say, the only thing I'm really interested in is risk. So I'm going to skip the first seven chapters of how to run a business and go straight to risk.

And that's okay. You don't have to read things, say introduction about how they're really smart and their business and you can just skip over all of that. And I think the final thing I'd really recommend is especially for books that are coming from anecdotal experience to be hyper conscious that almost every person who's made it in life in some capacity had a variety of lucky breaks.

And their context is not necessarily going to be your context and what you think what they say worked for them may not work for you. And so I've met, I see this commonly even in tech where people start to emulate big tech companies with decisions around how do we build an engineering function or why does Google do a paved road to security like oh, chaos engineering and turn off services randomly to build resilience and have SREs.

And then I think to myself, well, you guys haven't even adopted DevOps yet, so I wouldn't really be worried too much about going down that route. Moving back to the techie side and getting away from book club, what do you think the state of API security in Australia is at the moment or just even APIs?

Yeah, so it's really interesting when it came to microservices, API cloud adoption, Kubernetes, I always found Australia to be very advanced. In my previous company, we'll work globally. But the feedback would be that the Australian customers are very smart, they're very demanding, they're very well aware in that space. Somehow when it comes to API security, I feel that as a country, we are lagging behind.

I would say not just in API security, but in general security. If you look in this part of the world, like in APJ, I find that in my conversations with customers in, for example in Philippines, I'm working with various customers in Taiwan who are high-tech manufacturing companies. So they are much more aware of why they need different API security.

Whereas in my conversation, in Australia, I find that we have this false sense of API security that we've got WAF and API gateways and so on, and we are good. Whereas I think everywhere I go, I take the software's example and then everyone is interested to know about that and they try to learn what are the lessons from that episode. But in Australia, I think we need to do more when it comes to API security.

Yeah, I think there's a few things like a, we've got a she'll be right culture, which I think a lot of cybersecurity risk is just effectively accepted and not managed just because they think that it's totally fine. But otherwise, I think we also have an extremely deep penetration by CDN providers domestically who have been saying, hey, we've got everything on CDNs.

And so that means that our API, your APIs are managed on a CDN, therefore, they're secure because we deal with denial of service. We have web application firewalls that are blocking malicious payloads. So how can your APIs get hacked? And I think that's quite incorrect because in my experience, most API security issues are because there's a lack of business logic, understanding and authentication, authorization issues and context.

I'm almost certain that none of these CDN providers would ever have any real understanding about the data that's coming in and going out of each API and then of that data other than looking for, I don't know, malicious strings like double hyphens and PHPXX and OGNL expressions and so on, they're just not going to know what to do with it, and if it is malicious or not.

Take a negative $200. Is that malicious? Is it, I don't know, no context. It could be malicious if you're looking at a transaction because that's just giving someone money. But what happens if you're entering an accounting record and you're doing double entry accounting, maybe that's totally fine, and maybe it's not even a number, you're just putting a string in there how much you want us to discount on something. So the context really does matter a lot too. So do you think that those themes are correct?

No, no, you're spot on. And just to add one more example to what you already mentioned. So we work with a customer in US who is a cloud provider company, and they had this option where users can come in with a valid credit card, they can do a sign-up. When you do a sign-up, you get X amount of worth of credit free, let's say $300 worth of credit free.

It's very valid business scenario. They were doing this for a PLG so that they can get more users. When we got deployed, what we found that there was a lot of fake accounts signups happening. So fake users signing up using a valid credit card, then using... And nowadays, you don't need to go log into web server to sign up. We can do programmatically via API. So you can use an API to do a sign-up, then you can use an API to consume all those computer sources.

And they were getting used for crypto mining in this scenario. So a particular threat actor was doing around 4 million worth of fraud by consuming those free resources, by creating fake accounts, and then consuming resources and using it for crypto mining. And this was all under the threshold. So any CDN or WAF will say, this is legitimate API call, a valid card, authenticated user making the call. There's nothing wrong with that.

So this is a more advanced level of what I call as in a business logic exploit attacks. So these are not know WASP category, so they will not fall into a WASP category. Well, a new modern way of exploiting APIs. So yeah, they completely get undetected by your WAFs and CDN.

Often, they can be caught at your core services, but often people don't think about those scenarios, zero-day attacks, so mean scenarios, which you have not anticipated. If you would have covered, you would've done something for that. Right?

It sounds like I need to get a new business model, which sounds like just committing tremendous amounts of API fraud. Right? But anyway, thank you so much, Anand. It's been an absolute pleasure to have you on.

I would've asked you the book question at the end, but we've already covered a bit earlier. So I've really thoroughly enjoyed our conversation, just diving deep into API security details. So thank you for coming on.

Thanks, Cole. Thanks for having me. It was a very fun conversation.

Thanks a lot for listening to this episode of Secured. If you've got any feedback at all, feel free to hit us up and let us know. If you'd like to learn more about how Galah Cyber can help keep your business secured, go to galahcyber.com.au.