Okay, welcome. Good morning. Good evening. Good afternoon. Depending on where in the world you are currently located and welcome to another company, call webinar. My name is Alexei Balaganski. I am the lead Analyst at KuppingerCole and today I am joined by is a bio monk who is the chief product officer at 42 crunch and the topic. So today is API security separating truth from fiction. But before we begin and also to give, just give our 10, a minute to safely and community connecting to the system, a few words are about call.
So we are an independent Analyst Analyst company, headquarter in Germany, but with a substantial presence all around the globe, from the us to UK, continual to Europe, all the way down to Australia and Singapore, we offer went neutral guidance, technical expertise until leadership in almost every topic regarding identity and access management or cybersecurity, risk management and compliance, and basically the anything about the digital transformation or among our core functions.
Core services we offer are the events they range from free online events like this webinar all the way up to pretty large and pretty well known real world conferences. If you will, which attracts hundreds of visitors from all around the world and perhaps the most well known one flagship one is the European identity home conference, which will be having this may in Munich, Germany for the 13th year in a row. And on this slide you can see, or the panels for some of us, a major event, we are planning for this year.
As you can see us or Europe, APAC, identity, blockchain, digital finance, cybersecurity, you name it, looking forward to seeing you at some of these events, a few guidelines for the webinar. You are all new to central, so you don't have to worry about anything. Just relax and listen, and look at our slides.
We record the webinar and we will publish the recording on our website tomorrow. The latest and everyone is supposed to get an email, a link to the recording. We will behave in the Q and a session at the end of the webinar, but as usual, please submit your questions.
As soon as you have them and you have that special questions boxed on the go to webinar control panel, you probably have on the right part of your screen. Now the agenda for today's webinar is also fairly standard.
First I, as an Analyst would give you some general introduction and overview of the topic today's methods and challenges of API security. Then I will hand over to Isabelle Munk. We'll be talking about more technical and more practical recommendations and best practices are in the area of API security. And finally, in the end, we will have the Q and a session.
And without further ado, let's jump to the myth. Number one, and the myth number one is probably the biggest API security challenge. Everyone is facing nowadays that nobody or too few people actually take it seriously.
They would at least it's a few of the words I've heard way too often from our customers. API suggested an it thing. We are not software developers. Why should we even care? Or we are not using, we're not planning to use APIs anytime they're not relevant for our business. And what is it anyway, I'm not planning to give you a one or one course on APIs today, but just a short introduction to the evolution of API.
So yeah, APIs have started as a purely it purely, and it thing or a concept which developers have been to, to with since at least 1960s. And as soon as computer applications became more complex and a single developer could actually program people have been thinking about how to make different parts of the program, communicate with each other in our efficient, reliable, and standardized way.
And we've come a long way or back in the nineties, when windows appeared, we've had this distributed objects, frameworks where we could let developers from different companies plug their applications together on a single computer. And then it came to network based architectures in the late nineties, even large enterprises have adopted some form of API to power, service oriented architecture, where different business apps were communicating with each other along a single fat pipe. If you be running through the whole enterprise and then in the early two thousands, the cloud happened.
And that was way was another purely it thing at the time and look where it have come now. And with the cloud, it came a need to exchange huge amounts of data across huge distances across regions, across or different cloud providers and different heterogeneous it systems. And finally, in year 12, 17 Forbes, well respected magazine has announced that 2017 is the year of the API economy.
Finally APIs have evolved into which can bring you money in the modern digital economy. Data is the product for many companies and API is logistics.
So API economy, or on simple slide, I try to illustrate the way how digital economy, many companies, or have their core competence be just data or some business logic or just digital interfaces to their existing, offline functionality, banking, insurance companies, finance, retail, anything, and they want to unlock this core competence to the world. You want to expand the circle of partners consuming that services to a much wider audience.
So they, they produce APIs and all those partners, the customers, they consume those APIs, or they use someone else's APIs as a way to outsource some of less relevant business process to a third party and focus on their own core competence. And again, APIs are the glue APIs are the information.
Highways, APIs are single language. This parties are talking to each other to ensure that all this data, all this competence, all these services work at the cloud scale. And when you're looking at the situation, now APIs are truly everywhere.
So if you honestly believe that you are not using APIs, or if you're not planning using them anytime soon, you are making a great mistake. You are already using APIs. You probably already have lots of APIs within your systems. You just don't know the exist yet. Maybe you just forgot about them or that maybe your own APIs, partner APIs, third party products, cloud services, mobile devices, IOT, things, everything is now powered by API and everything on the internet basically happens over at API.
And always APIs are like thousands of new doors and new gates and windows into your corporate perimeter. And of course not just your partners, but bad people as well are curious to look into those windows and do something nasty.
And here we come to the second myth that API security is easy. Like if you know a single tool about how APIs actually work about the soap and the rest protocol, you'll probably saying that APIs are indeed extremely simple. They were invented by lazy developers who did not want to spend much time integrating their applications.
This is why they became so popular, and this is why they are so widespread. But then again, ATIs are simple because they do not focus on anything else. They do not focus on security. They do not cover reliability, do denial of, or any other multiple problems, which can arise in addition to all the existing threats, which your existing systems may be facing already. So if someone will tell you that APIs are just dumb pipes, which do not create any tech vector, think again.
And if you still believe into the principle of security by OBS, or that nobody will ever hack us because we are hiding in the shadow, we are not exposed in our interfaces.
And then again, think again, the danger does not necessarily come from outside. There are multiple ways to exploit those APIs, those internal APIs, which were never supposed to be exposed to anyone else.
And if we are looking at the very simple version of the API breach timeline on this slide, I just tried to put just a couple of the most well known publicized data breaches, which were later discovered to be caused by API exploits three years ago, there was one fairly popular bank, probably the biggest online bank in Germany, which accidentally found out that their APIs, their mobile APIs could be exploited by anyone because they were not properly secured.
And again, that's a bank, that's a company which is supposed to be one of the most regulated and highly secured industries ever here later, we heard a couple of other pretty well known names.
Instagram, for example, was allegedly caused by someone basically forgetting to Rena authentication API. After some testing again, or last year was probably the year of well publicized, very large scale API problems.
Panera is a very popular us food retailer, T-Mobile telco, Facebook needs no introduction, ups, even the largest and well established companies with hundreds of thousands of employees, which probably have fat budgets for it, security and large teams of experts running the it security still did not escape, did not avoid having the API hack. Could it be you this year?
And when we just briefly look at the just sum of API specific risks, namely the risks, which you only get when you add APIs as an additional window into your it infrastructure, not counting all the rest existing threads, which target your endpoint databases, whatever other systems you already have, the biggest probably the human factor.
So yes, APIs are created by laser developers. Those developers are constantly pressured, pressured into making their code to, to deliver their code as quickly as possible in bringing their new fancy app to the market as quickly as possible.
And then security becomes not even the second priority. Probably the 10th one. There is a lot of mistakes developers could be making in their code. Some really stupid one like hard code credentials in the code missions, some vulnerabilities, or again, trying to learn this old proven methods, method of security by security, basical to human. We all know it. There is lots of interesting ways to make your APIs stop working by implementing a denial of service attack.
And of course we all know about those highly publicized dumb denial of service attacks, where anyone can use, or an army of bots of hundreds, of thousands of devices to just hammer down infrastructure.
But on top of that, there is a lot of less trivial ways to ensure that your API simply stops solving value customers and your business process are processes are interrupted and you losing money.
If anything else, even more advanced techniques exist for so-called payload attacks where well known and not yet known weak spots in various network and API protocols are exploited to plant some kind of logical bumps into the API calls, which may seem legitimate at the first glance. And of course, none of the existing security tools be it firewall or application firewall or any other traditional perimeter based security tool will ever catch them.
And yet, or again, a simple chasing schema violation or the wrong, wrong perimeter value, or even just a couple of extra symbols in API endpoint URL can lead to a massive injection attack, which will not just disrupt your API, but actually lead to a data breach. And again, there is a lot of other ways to breach your business backend through an API. Be it exploiting the weakness in an encryption library. You probably heard about the hard blade story with the open SSL library a few years ago, ever dreadful authentication problems.
Again, it, it doesn't have to be a technical problem. It can be very simple misguided developer forgetting to enable something in the API definition or man in the middle stealing credentials over legitimate API consumer, and then hijacking his session, or just about thousand of other possible attack vectors. This is why anyone who believe that API security is easy as to think twice on this slide.
I've just presented a short, concise version of a diagram, which we created once to you say the scope of API security. I won't read it all aloud, but just consider that to secure your API.
And then again, it all comes on top of the existing multiple layers of traditional it security, the firewalls, the antiviruses, the IAPs, and the encryption tools for your databases, which you already have. There are multiple other ways which you have to be thinking about now, multiple new threat vector, which range from the low level transport security again, which could be partially covered by your existing firewall, but definitely not all the way because firewall is not smart enough to know about API exploits, that protection.
Again, maybe you already have a code vulnerabilities scanner at place, but we scan your API definition. Access control, role based attribute based definitely have something.
I mean, all is a pretty well established authorization protocol for APIs as well, but does it take behavior anomal Analyst into consideration? We will detect someone using a legitimate credential, but logging in on Saturday night from China or North Korea data integrity. How do you know that the data which is coming from your partner actually comes from your partner?
How can you be sure that it has not been manipulated to cause integrity issue in your backend database, or maybe downright disrupt your industrial equipment to IOT equipment, which relies on that data for operations and in any case, how do you know that you even have all your APIs under control, that you know, that they exist, that you monitor and cover and audit all those activities?
Continue this diagram just for another second.
And again, probably the last minute today in that, okay, we've done our homework. We test our code, we have an API management solution. We've checked our infrastructure. We actually hired some white hackers. Surely we are finally safe, right?
Well, unfortunately like any other aspects of it, security APIs, probably even more so are not frozen in time. APIs evolve, just like your backends, like your operations evolve or APIs have their own lifecycle, or which start with a design, or even before anyone writes a single line of code, they usually start with an API definition. Even if you have not heard about swagger or open API or any other standard existing margin in this area, even the common sense loan suggest that yeah, you start with a design.
And in that area, if you were to integrate security as a part of this design process, you would actually benefit hugely on the later stage because not only will reduce your potential attack surface or the later latest stages of this life cycle, but it'll actually ensure that your developers and your operations and your security people are working together proactively on making your whole digital business secure from the, not even the first part of step number zero.
And of course, or with new technologies, new threats, emergent daily, how do you stay current?
How do you ensure that you know about all those threats and challenges? So API security probably starts with a book encyclopedia with a, a forum, some kind of community where you can go and look for best practices, patterns, and anti patterns. Basically you have to educate your developers security to guide your operation guys continuously. And this is the life cycle of API security.
And with that, we are coming to my last slide for today. The key takeaway are actually pretty straightforward and you always start with a strategy. API security is no different.
It's not, not less, no more complicated than any other area of it. Security. It requires careful planning and commitment and or participation of every stakeholder in your development and ops and security teams. Education is key even more so for developers.
And again, API security experts because threats are, are constantly waring, probably even are a bigger scale and the bigger complexity, any other area of it security because after API security is such a young field of security at all, you always start with knowing your APIs, because if you don't know what you are protecting, you obviously cannot protect it. And you have to consider all APIs, not just your own, but or knows which you are consuming yourself and which you just happen to have on premises, because you are using a third party product or solution.
And of course you have to to see your API security as a process. As I just said earlier, you cannot just stop and feel secure. You have to run as fast as you can just to remain in one spot. And if you want to move somewhere, you have to run even faster and finally, or other kind of means to set the stage for the second part of our presentation, consider automation, API security is complicated within seen that today.
Do it, it doing it manually is slow and prone to mistakes. Yeah, you probably heard a lot of AI replacement for human security experts, but there is definitely more than to API security automation adjust AI. And with that, it's about it's now your turn.
Well, thank you very much for, for the introduction Alexei say, and yeah, I'm good morning afternoon, everybody. So yeah, we were discussing about security and how, you know, automation would be important. So that's one, be one of the key things I want to discuss this afternoon. But before that, I'm gonna add a myth to the list that we hear a lot about when we talk to our customers, which is, well, you know, I'm already, you know, passing all my information under my APIs through SSL TLS. I have some, a, some kind of auth in place for security and tokens, I guess this is it right?
I'm I'm, I'm done. And, and that's one of the first issues, which is to better understand the scope of API security at a technical level and how you basically need to need to address it. That's one problem.
And, and the second one that we see a lot is, okay, well, everybody pretty much agrees if they have an API, which they deem as an open API as a public API, because, and by public, they mean, well, we have a developer Porwal we are advertising this.
We have a developer community.
I mean, that's, that's very public, right? But public is really not.
The, that's not the sense of public. The sense of public is it's on the public internet. So there is an end point running somewhere in the internet that people can connect to.
And, and that pretty, pretty much concerns everybody because one of the key reasons for creating APIs today is, is to create applications mobile or web applications. And basically the APIs are the entry points in the architecture that those applications actually talking to. So even if you're not actually advertising, Hey, I've opened an API on that address.
It doesn't make them private right back to that security by OBS, maybe Alexei say, was talking about, so that that's a really misconception that because I'm not advertising, it's actually not public, but it's extremely easy to actually find that some endpoints are running and there are bots all over the world that just can a range of IP addresses and, and actually find listening ports and tar, you know, playing with those and, and sending all kind of requests to see what's behind that open endpoint.
Right? So it it's really important to actually understand that this concerns all kind of APIs.
And another concept I'm talking, I'm gonna talk about here is really trust, right? Which is, well, I trust that, you know, this API is inside my company and there's only, you know, a certain set of people who have access to it or certain number of partners I have access to. So that's okay. I don't need to secure that the same way I'm securing all kind of other APIs that I deem maybe are, are more exposed.
And, and also that can be the source of a lot of problems as we go through the presentation, I'll touch more on, on why this can be a, a problem. So the first thing is at the technical level, you know, what is API security and what aspects they have to look at.
And, and the first thing is, is really about, you know, something extremely basic.
We're gonna talk about again in a minute, which is input, output validation, right?
So, you know, this data I'm receiving the data I'm sending back, is that really what I'm expecting to receive and expecting to actually send back? Am I sure, you know, this famous CIA tried, right. Confidentiality, integrity, availability, am I sure that the data I'm receiving really has not been read by somebody else has not been changed in flight?
And, and basically I assure that I'm not going to be overwhelmed in terms of, of the system, because availability is actually part of security. That's part of dos and DDoS type of attacks is to just make you fall and therefore losing your, the ability of the system.
Then, then things we're more probably, you know, inclined to attach to security, which are authentication and authorization, who is calling me, do they have the right to do what they're reacting to do?
And finally, the last part that some people were very conscious of because of legal obligations, which basically is non non reputation, but it is also extremely important from a security perspective for APIs and, and in general, to have all the information and what's going on in your assistant to be able, you know, if something happens or you have to trace back, have forensics basically on, on, on the activity within your, your enterprise through those APIs. So we're gonna get into that.
And, and on what other aspect is, is, which is, I think is very critical. You know, there will be a lot of different people on this call of all kind of industries and all kind of APIs.
And, and one side is unfit all here. So you, you really need to know, first of all, you need to know what you have as, as I said, was saying, and there APIs out there somewhere on, on your enterprise that you may not even know of.
So you have to, first of all, know what, you know, which ports are open out there and what they're allow to access.
And, and then you have to understand your API is what did they do? You know?
So to, to take a very simple example, I will talk to everybody. If I'm in the banking industry, it is not the same to security, open banking API. That allows me to list the ATMs that a bank has versus the API that allows me to do a payment between account a and B, as you know, it's kind of obvious that the risk attached to each of those and the sensibility of the data is completely different. And therefore the security applied to each of those APIs cannot be the same. It has to be looked at individually so that you know, what you have.
So the first thing you really have to do is to know what you have and kind of classify, you know, those are my APIs, it's kind of three, four profiles of security that I have within my company.
And, and that allows you basically to then start and say, okay, what should we do now with those APIs and how should we secure them? And as a methodology, I would say because of the very nature of APIs and how they're being developed in extremely agile fashion.
And, you know, when you have applications to write as a developer or a mobile application and business is pressuring you to release that for yesterday, it's very, it's gonna be very difficult to actually do security properly, unless you automate all of it, ideally, or at least part of it.
So what I'm going to describe now is kinda a methodology around the, the six blocks that you see now, you don't have to do all of that at once, of course, but of course it is something that you can adopt, I would say gradually, but in one way or another, at the end of the day, and maybe, you know, months from now, you'll have to cover all that C curl to being sure that you're properly secured.
And the reason also for this is I think API security is really the team job, right?
There is three communities within a company where impacted when, when you open APIs, of course there is a development community writing APIs, but there's a security community and the operations community. And, and if you wanna do properly security, the three communities have to work together, cuz you cannot take back to risk. If you take our payment API, we can secure from a development perspective, we can secure API the best we can, if it is not properly secured and deployed, then it is not secure properly, right?
Even if one community has done the best they could to actually support it, that that's security. So it, it is important to understand that this is a team job basically across all the community. So let's start with development. So in terms of development at 42 crunch, really, we push people to really start with really understanding what the API contract is.
And what I mean by that is understand thoroughly the inbound and outbound interface of my API. What does it take in as data? What is the format of the data?
And we do this as precisely as possible, and that's really the work of the developers. They're the one we really know within the company, what the API actually does and how you can interact with it.
And, and one of the, you know, key standard, if not the key standard now for actually doing that is open API. AKA also known as, as swagger in his previous name, which really allows you to very properly defining that contract. So it can be contract first type development. When you start from that contract and you create the code, it can also be you create the code and you annotate that code and then you generate the contract. But in any case, you already have to understand that because that's the roots of everything in terms of how you're going to interact with the system.
And, and then, you know, if you look at the breaches that are happening today, many of those could be avoided by simply covering the basics and by covering the basics, I mean, validating so back to trust, right? You don't trust the data that comes in and you even try to trust the data that comes out. And what I mean by that is whatever is coming in, whatever is coming out, you have to validate that this is actually what you expect to come in and come out. So come in kind of, you know, makes sense.
You say, well of course, if I'm receiving some bad characters or injections or so I wanna stop, but why outbound, why outbound is very important as well, because if somebody actually a Hager has succeeded to get in, you wanna prevent them from, you know, taking stuff out through that API that does not the format that it is supposed to, to be using.
So it is also very important to validate outbound information and of course, tokens. So I'm saying tokens, you know, the, the thing about tokens is they can be stolen. They can be forged, they can be replaced.
So you also want to make sure you don't blindly trust the tokens that get to you and accept them simply because the signature is valid or something, right? So there's an entire IFC, an entire standard on how to properly validate Jason web tokens, for example, and all the different things you have to look at in the standard Jason web token in order to properly validate it. And therefore granted, and, and as, as being valid and acceptable.
And another thing is, so for those of you out there using a, as you will know, there is many different ways of using ath and, and you can have multiple ways of obtaining an a token.
So again, choose that carefully. This is very important. Not all those grant types are equal. Some are much more secured than others. So be careful about that. Choose the right ones, depending again, on the risk and your industry and, and, and what you're doing with those.
And, and finally something that is not so considered or pop from me now in the open banking industry is beyond SSL and, and encrypting basically the channel look at encrypting or, and, or signing basically the payload as well, just to ensure that confidentiality and integrity that we were talking about. So again, you don't wanna do all of that encrypting and signing for any payload and any API.
There's probably some things back to my payments where for payments, you absolutely wanna sign the payload to make sure that if somebody, you know, is doing a transfer of 100 euros from account a and B, it's not being transformed to 1000 euros on the way, right?
So this is important.
And, and finally, beyond using, you know, what you do, basically in terms of validation and, and, and the definition of the API itself, try to limit really the, your, your dependencies on, on, on external libraries, right? It's very easy today to just go and Fe you know, libraries from all over the internet scripts from all over the internet. And this is like the best way for somebody to actually put, manages code inside your application without even hacking you. So you have to be very careful about this use trusted library.
Don't try to, you know, reinvent the wheel in terms of implementing security solutions, you know, write your own a server, for example, this kind of stuff. You know, it is very complicated to do unless, you know what you're really doing.
It's, it's the open door to introduce a lot of vulnerabilities into your system.
So I've, I've put a link here to a, an article that I wrote on, on token management that can be useful to better understand and, and deep get deeper into that topic.
And, and back to to libraries is an interesting actually article that you, you guys should, should look at if, if you're using no GS in particular, because it is extremely the same, very easy people need something to, you know, add one and two and they'll go NPM install, you know, adding one and two package and off it goes, it's inside dozens of, of application. So you have to really be careful on, on what you inject in your code and where it came from and read that article from this gentleman. Who's a hacker, and that's gonna make you think twice about how you use NPM install, if you are then.
So that's development now, okay.
I've developed my API, have it now auditing, what is it about? So looking at the code and looking at the contract. So typically from a security point of you've been using static code analysis type of tools to look at, you know, potential problems like injections and such things inside the code. That's still valid in, in there.
And, and the other thing you probably want to use as well is back to what I was telling about libraries is also validating those third party libraries and making sure that they're not, they don't have any vulnerabilities CVEs attached to there's multiple tools for that. I just talk as Nike as something we've been using at some point in our development and, and GitHub dependencies also give you interesting information. And another part like Docker is like the way now of distributing applications.
So a lot of clouds now offer scanning capabilities so that when you push an image to their registry will look at the image and look, if there are any known again, vulnerabilities within the libraries that you're using.
So all of that you can easily automate and, and block basically the deployment, if you find this kind of things.
But then, you know, there's nothing like having humans to also looking at code and, and doing some code reviews. So, you know, business as usual here in terms of analysis and, and you know, this MPM back to one of the things that came up some, some weeks ago, a couple months ago now is basically, it comes down to that article that I, I, I was talking about somebody pretty much did what that article was describing, gained the trust, basically through of the, the committers of, of that specific package and committed the code in there. And that was downloaded 8 million times.
If for somebody realized that actually some management codes had been had put in there. So that's the type of problems that you will detect.
If you have an automatic system last, last night to actually in your code, if you have that problem, it will pop up as being, as being a problem. Just an example, and, and ourselves for, to crunch will also, you know, I have delivered recently a set of tools to actually analyze your open API swagger files and, and give you information about, okay, is this a valid actually description? Is the authentication definition properly done?
The authorization is transport configured properly. How, you know, well defined are the CHES in your system. And all of this, you know, is free of charge. It's our community tool that, that we give. And it comes also with the encyclopedia of all kind of problems, going to the education part at Alexei, a was talking about in terms of, you know, understanding and knowing those are the potential issues that can happen, you know, depending on what I do in, in, in my code.
So I encourage you to, to go to there and, and, and try that tool with your, with your APIs then scanning.
So the previous part, the audit thing is really the static analysis. So I'm just looking at the code, right? But now I also have to test the actual implementation itself. So here we, we have in our powder platform, what we call confirming scan. So basically some scanning fuzzing that you can use to test what I call the hacky path, right? So one of the methods, basically for hacker to understand how they can get through your API is they want to understand what's behind it, right?
And, and one of the things they're gonna do to do that is send to your API, all kind of really bad requests, two big, two, small, bad characters, all kind of things, to see how your API is gonna react to that.
And, and that's very important because what I see in a lot of APIs is basically unhandled error cases, where you get some XML when you should get some Jason, where you get some exception trace coming back.
And that's like, you know, extremely interesting information for anybody trying to get in, because now they know, oh, you're using just as an example, tracks version two, two with the old version that has not been patched. So they go somewhere, there's this basically list of exploit the look at what we're using. And then that can, now you have more information to try all kind of exploits against your system. So this hacking of sending to your system, all kind of stuff, it doesn't expect is extremely important. And that's what we do in our tool. And also we tend to forget about this.
So there is the code, but then there's also transport, right?
So how safe is your, how well is deployed your API and how is it configured? Is it using old SSL versions and old TLS versions, even? So you have tools that you, you know, that you can use to actually do this kind of things that will give you report on how well this is configured. And of course, depending again, on the risk and who you are, you can go further with bug bounty and pen testing on the implementation and try to, to break basically your API before any anybody else breaks. It. That's kind of the idea right now.
How do you protect yourself? Right? So you scan, you found the thing. So typically you will have to put in front of your API, something that allows you to block this kind of request that your unwanted requests, and, and there there's two, you know, key things that people are doing today that they deploy w application, you know, web application firewalls.
So if you have a web application for all deployed in front of your, of your APIs, there's some stuff that you're going to stop, but it's not all of it.
And the reason for this is because web application firewalls were designed way before APIs even existed. So they kind of look at all the traffic, but they don't understand API traffic, they understand HTTP traffic, so we understand each other, right?
So, so we really want to put here a solution that is API specific, such as, you know, what we do. So you have to be careful on, on making sure that whatever you deploy to protect yourself is actually API.
And, and the other thing is you really have to protect all the APIs that you have public private, the SaaS APIs are using all of these are tunnels and, and open access to your system.
So it is very important that you apply kind of the same security mechanism across all your APIs, wherever they're supposed to be accessed by again, taking the risk in, in accounts. So it's probably less risky to have it open to three partners than open to, you know, Jodo anywhere in the world, of course, but that doesn't mean it's, doesn't need to be protected. Okay.
So you wanna make sure you do do, you know, dos the protection in here, validation, all this validation we were talking about. So validate everything before you even hit any API behind the scenes. That's extremely important. And also do this in an automatic fashion. So one of the key things about DevSecOps etcetera, is that all the testing should be done by the developers as early as possible with security on, right. What we see too often happening is the API deploy development happens the entire cycle, all the way to functional testing.
And then somebody says, oh, we forgot a security testing. And, and usually there's not enough time for the security people or anybody in, in charge of doing that to actually do a proper job there because they don't have the time to actually do that. So instead of doing this like firewall, you know, not firewall, I'm sorry, you know, do this at the last minute. You wanna do this and a agile way and doing, doing it as early as possible. So you just publish an API, even if it's not finished, you put security in place.
So it forces everybody to basically test it with security on, and you wanna do that in an automatic fashion again. So it makes, it happens just automatically. I push my API to GitHub, to, you know, some C, C, D pops up at the end of it. I have some patronized Docker image running somewhere.
That's protecting my API. And I don't even have to think about it. That's the ideal probably way of, of actually doing that and finally deployment. So this is really important. People tend to neglect also a little bit. This is really part of the overall overall architecture of things.
You know, back when I started working on, on development, we had this cool concept. Some people are gonna remember that was model view controller, NBC.
And, and the whole point of this was to say, well, I have data. I have a controller in the middle. That's kind of my con you know, accessing and responsible for accessing that data. And then I have a, you know, a view in front, my, my UI, if you want, that can talk to the controller that controls the data. Now we have it, we have some tools and, and things in, in, in my services or services doesn't really matter.
That allows way too easily. I think to just say, oh, this is my database. Let me point this here. And let me generate an API, right?
First of all, I'm going to disagree with anybody doing this, that this thing you generated is actually an API, because an API is a business thing. It is, as Alexei say, was saying, it is not a data access object on the data. It is a business thing. So it needs to be designed for the customer, I would say.
And, and the consumer of that information. So exposing straight data to the front, that's a very, very bad idea, right? So the same MVC architecture we have to translate, even if you're running in the cloud, right?
In, in those different layers, you still have a data layer and that's your precious layer as well. The very important information is, and you certainly don't want anybody to get to that directly.
You have a process layer that basically maybe combines information from multiple data and renders, and then you have a front layer that talks to the process and render information customized for the client, whatever the client is, mobile or, or UI application.
So it, it is in, in probably what you want is those three layers to be like physical, physically separated layers as well, and have mutual TLS across all of that. Just to make sure that if somebody gets into the front layer, you know, they cannot go straight into the data layer through the means of network, you know, once they're inside.
So it, it is very important to ensure that this protection I was talking about before you deploy at the edges, if you want though, there's not really an edge right now on, on how things are done.
Like, we are more like a, a hub with plenty of holes that all need to be protected, but also in front of, if you're working on a Microsoft environment architecture, I'm sorry, then you probably want to put those lightweight protections as well in front of every single microservice, just to ensure that you have proper security per service and then proper, which will be a different set of policies, both probably then, and then also have apply the same protection on your front API.
That's brought most likely the one that the consumers are going to see. Okay.
And, and of course monitoring. So, you know, you can't fix what you don't know.
So it's, it's very important to understand what you have in terms of what is deployed or the calls from coming from have alerts and something unexpected is happening. And you really want to treat that's very important and you wanna treat vulnerability as bugs. So the same way you have a JIRA on kind of tracking system to actually track the vulnerabilities in your code from a functional level, you want to have the same thing for, for vulner security vulnerability. So you can track that.
Yeah, we have fixed that. So we have a regression test to address that vulnerability. So we know that is not gonna happen again in a month when somebody changes the code. And also you also have all this, you know, forensics and information.
So if something happens, you can go back to the root of the problem and actually act on it, right?
So that's, that's also a critical aspect. So in the conclusion also to repeat a bit what, what Alexei a was, was saying at the beginning, a API security is not a one time thing, right? You're gonna the same, you're continuously changing your APIs and evolving them. And therefore it cannot be a one time shot. It's not something you set once and forget about, right? So you really need to continuously apply the security measure and, and ensure that those security measures are properly, you know, in place with everything, we talked about, treat all APIs.
If they were public, that would be my recommendation. Don't try to do differences between their internal, their external, not treat them all as public. And then you'll be safe, understand the security risk, attach your APIs, and then adapt the security depending on that risk.
And, and indeed there's a lot of education to be done. So invest into educating all the stakeholders, developers, security teams, operation teams on the APIs, what they are, you know, what they do, what are the implications in terms of exposing them and, and make sure you look at specific API, you know, API specific solutions to protect your APIs, and then try maybe to reuse some security stuff you have for web applications that are not maybe adapted to, to, to the actual requirements of, of APIs at this point.
And, and yeah, that's, that's what I had. So I encourage you to, to go to our API secret audio site, we're trying to do as, as a company, as ready to crunch what we can for this education I was talking about. And as part of that, we have different tools and newsletter join that it's free. You'll get to learn about breaches and what happens in, in the API world. And hopefully that will help you, you know, not to make the mistake that some of your peers may have been doing and, and outreach better API security together. And with that, I guess we are ready to take some Q and a Alexei.
All right, thanks a lot, Isabelle for this very insightful view or into the kind of immense depth of API security. And before we PL into the Q and a session, and by the way, I encourage you again to submit your questions, as soon as you have them, just let me quickly recap probably the three biggest messages for everyone out there regarding API security. So first of all, APIs are no longer an I an it thing.
APIs are probably, well, maybe the second after the cloud is the second most important or revolution in this whole digital transformation thing, which is still happening in our society for many companies on there, regardless whether they are developing their software themselves, or just consuming someone else's APIs would be the primary channel of communication with partners, customers, suppliers, and the rest of the world. And also one of the primary attack vectors for current and future hackers.
And the second message would be that API security is pretty complicated.
It's not a one product which you could just buy, install and forget. You can try it, you can do it to the traditional way, and eventually end up with 25 different separate products, which you have to juggle and invest sleepless nights into a, trying to make some work properly. Or you can do it the right way by starting with the strategy involving all the teams and basically planning everything in advance. And the third final message would be educate and start with your, with yourself.
For example, I can only, and totally neutrally as an Analyst recommend the newsletter, which 42 is sending out on API related challenges and news. Even for me, as an Analyst, working pretty deeply into the area myself, I find it very useful and let's go to the Q and a session. And the first question would be, that's do it properly. And the first question would be, so what are the most common API issues you are currently observing? What are the, the, the biggest, most common ch challenges which people should be looking out for?
Oh, well, I'll, I'll take that. And you can, you can add to that if you want Alexei say, so the, the, if you look at the, the problems that we see with customers today, so the first biggest part problem is, is really the basics, which is improved validation still have, I guess, cuz it's, it's, you know, it's the tedious job job to actually validate every single piece of information that comes into your API and, and it, you have to do it every single time. You change something as well. So there's still a lot of breaches out there which are linked to basically data not being validated properly.
And, and there's one thing in particular that has emerged. I think that was the Facebook issue and, and this was the T-Mobile issue as well, which is that once you're authenticated. So I have a valid token, I'm a user, I have a valid token and I'm basically, let's say in the T-Mobile case, it was, I have a valid token and I'm checking the status of my phone number.
So I, I input in there, my phone number and I get information about my profile because I get my phone number. Now, what happens if I put the phone number of somebody else?
And, and that's something that basically didn't, didn't look properly. So as long as I was properly authenticated, well, I could look at the phone numbers of many different people. So somebody created this bot that will just go and create phone numbers on the fly and, and like that they could extract a lot information on phone, through their phone numbers on many different users.
And, and that happens quite often. And, and, and the other one I would say is I would, you know, careful, not, not being careful when you do updates of objects in particular. So say I have an object customer and, and I want to update just the first name and many APIs basically instead taking just the first name. They will take the entire customer object as a parameter. So if I put the entire customer object, I can actually override all the information in there and, and override may be some inform related to the rights and the roles and, and the permissions of that specific user.
So that would be like the three top things that we see all the time.
Okay. From my side, I would add probably the thing number zero. I think the, the biggest problem of API security nowadays is just where very few people actually take it seriously.
For some, it just translates into kind of ignorance is place. They have no idea that APIs are even a threat. The others are more like, okay, yeah, APIs, we have a firewall, we are safe. So this is probably the biggest mistake many companies are making.
And yeah, all those challenges, which you just mentioned are absolutely valid and important. But if you are still on that stage where you basically don't believe API security is the thing, then there is no point discussing the rest. Right.
Indeed.
Okay. Next question. So who should we worry about more bots like the automated effects or human hackers?
Hmm.
Well, it, it, bots are definitely very, are definitely a threat in terms of dos type of attacks, but it's kind of the combination of the two, because what happens is you have those bots that will go and fish for information I was mentioning before. So they'll make those automated calls to your APIs until they kind of discover something. And then that's something is being exploited by humans, right?
So it, you have to be careful of the bots because obviously they never get tired and they will just send timeless requests to your systems until they find something again, you know, try to do a little test, just start an open API on any cloud out there. And after five minutes, you will start to see automated calls to slash, to slash you know, to their and all kind of requests. So those bots are there all the time. So it it's a combination of both, I would say,
Right. So basically it's like asking, so what should I be protecting more from THS? Like my front door or my windows both. Right.
So basically, yeah, I've actually read a report from one of the media Dedos protection services on there. And they mentioned many times this rising trend of human hackers using those automated bot attacks as a decoy from their nefarious activities. So here absolutely monitoring botax is a must. And even if you are pretty sure that you are safe and you have a anti tight DDoS solution in place, so nobody will bring your API down. It's still a thing it's kind of, it's a very important bit of threat intelligence.
So as long as you notice something like that, you have to be double vigilant, look, look for human hackers as well. Right. Or I think we have a minute for the last question for today. It's really interesting one. So what about internal APIs?
Like, do we really have to consider the threat of insider tech on internal API?
Indeed. Yes. I get that pushback all the time from, from people thinking, but I trust the guys next to me, you know, that's okay, nobody inside the company is gonna try to, to get to us, what would they do that?
So there is a very little presentation, of course, you know, probably of voluntary things are happening because you know, some employee has a grudge on the company and they actually try to do that, but that's not the, the, the main thing, the main thing is basically people getting hacked through social engineering or fishing, all kind of different ways. And it's not that they're voluntary letting something happen. It's just that, because they've been compromised now that helps hackers get inside the enterprise through them.
So it's not about not trusting the person basically, but simply the fact that it's, it's, they're just another risk factor and through, and unfortunately some, some hacking somebody can get inside the enterprise and therefore once they're inside, then they have access to the internal endpoint. That's, that's the key thing.
Right? And by the way, I would actually recommend our attendees to watch a recording of a couple of our earlier webinars, which we did on the whole topic of human factor and insider threat management.
And in fact, you know, the vast majority, like three quarters of all the insider attacks are covered by security vendors, security Analyst, Analyst are all from basic negligence. There isn't no malice behind it, but still those negligent employees losing the credentials or running malware or anything else writing down their passwords, stuff like that is the same applies to APIs as well. And those are the, the cost list for their companies when it comes to data breachs.
And the second aspect I would like to briefly mention are that even if your API is a hundred percent internal and not exposed to the outside, you still have many attack vector, like bring your own devices or just third party product. It might not even be an industrial device. Like for example, those IOT industrial IOT things, or, or scatter things, which are, for example, usually serviced from the outside by third party admin, there was this hugely publicized hack. I think it was something like a casino hacked through an aquarium pump, which was connected to the network.
Yes.
So the one should consider even those, or maybe that sounds a little bit too exotic, but consider that you probably have an office printer, which has a server running inside with APIs, which are probably 10 years old and have no protection at all. That's also an attack vector. It has nothing to do with trusting your employees because your employees have no idea what's going on in that printer. Just one other less obvious facet, if you will, of API security. All right. And with that, we have reached the end of our webinar. Thanks a lot to all the attendees for being with us today.
Thanks to Isabelle for joining us and have a nice day.
Thank you very much. Alexei Alexei, have a nice day, everybody. Thank you very much.
