Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor KuppingerCole analysts. And like in every edition we have in this edition one guest joining me a fellow analyst and we will have 50 minutes or so to chat around a special topic. My guest today is Alexei Balaganski, lead analyst for KuppingerCole in Duisburg, Germany. Welcome Alexei.
Hello. Thanks for having me again.
Great to have you. So today we will talk about a topic that you suggested and then test the impressive title, the dark side of the API economy. And that sounds interesting. That sounds challenging. But to start with, can you give us a quick introduction into the terminology? What is an API anyway?
Well, I guess that's really the best question because so many people have this very old school perception that an API is something that only it should be thinking about. So API is an acronym, which means application programming interface. And again, it sounds very technical and it ish, if you will, about the point of that a while 10 years ago, 20 years ago, it was indeed like that. But nowadays API APIs are more just everywhere. They are also powering everything around us. They are one of the major drivers of the whole digital digital transformation, because to think of it, the monotone or we analysts like so much the digital transformation, many people still think that whenever they migrate from paper-based documentation to word and Excel, they have already undergone transformation. That's not true. Kind of accompany really becomes digitalized digitally transformed. If you will. Only when this digital information becomes a, the very essence of its processes and sometimes even its major product and source of revenue. And this is exactly what happened to so many companies, already large cloud service providers or companies like Google Facebook, or our other huge technical giants. Their product is useful information and their logistics are the API APIs. So basically the API APIs are the glue that enable digitally transformed businesses work together.
So these APIs represent digital services. So this is really something that you can use from your own application slash business model and leverage then functionality services that others provide via API.
Well, I mean, obviously services digital services have existed for decades already. So as long as we have networks, we already had some different service-based architecture like core bar with D comb in early windows agents. So XML RPC in the enterprise Unix world was like 30 years ago, 20 years ago. Nowadays, when we are talking about API, we are talking about specifically restful API APIs, which are extremely simple, lightweight based on the standard HTTP protocol, which powers all the world wide web. And yes, indeed, it's a very, it's a standard, it's an architectural button, which has extremely low learning curve. So everyone can start publishing their existing services as restful API APIs in or military maybe hours. And of course I can start consuming someone else's API APIs in minutes or hours. And while it's so easy to dive into, this is exactly what has led to this proverbial API explosion, because what just maybe 15 years ago was a period of technical term used by a handful of it, nerds or developers. Now it's APIs everywhere. Restful API APIs are basically, there's a backbone of the modem internet.
So we learned what an API is or what API is are because obviously lots around what then actually is meant with the term API economy.
Well, to be honest, I find this term a little bit deceptive because you do not earn money with API APIs. You earn money as your core digital competence. It might be a source of valuable information. It might be, or some online service. For example, justice, the simplest example would be online, a weather forecast. If you want to know the current weather, you don't have to look out of your window. You can just open the website if you are a human, but if you are a device, if you are someone else's mobile phone, basically you need, you need to call an API. And of course this API call might be, are not necessarily free. You can subscribe to an API, which is kind of monetized. And every time you call it, you have to pay a little bit less of your sense. But if you call an API millions of billions times, monthly revenue can skyrocket. So look at Google. I would say that API is probably like a majority of their income,
Right? That requires also when you subscribe to such an API that you authenticate, that you show the service provider who you are and that you are legitimate user of this service and that you most probably also will pay the bill afterwards. So there's security built in there.
Exactly, exactly. And this is exactly where with the second, most prevalent myth about API APIs. So that if API is the restful API is, are so easy to implement and surely it's, it should be just as easy to implement them properly. If you will. Unfortunately, it kind of implementing an API properly, meaning an API, which is resilient to denial of service attacks, which is always available, which is secure and cannot be exploited by malicious actors and so on and so forth. It's actually extremely difficult. So yeah, you can probably learn to play piano with one finger in an hour, but if you want to play something really well, you have to spend years exactly the same applies to API security. If you will, because security is such a complicated field that you could probably talk hours about this question alone, but we only have 15 minutes or let's talk about practical implications.
Okay. If we talk about practical implicates, of course, as we all have been using computer systems for quite some time, we know what can go wrong. So function call, which is behind an API might be not well implemented or the security layer in front of that is not well implemented. So there is a, a way around the actual authentication process, or if things just break down during processing, maybe some information still is left and returned via the API. But if we think of API security from the negative point of view and you sat, there is a dark side of the API economy, what has already gone wrong?
Well, to be honest, everything which could have gone wrong has already gone wrong so many times. It's just almost ridiculous to see I've been following this topic for quite a few years. I think I started at least five or six years ago when it was really very narrow and almost considered relevant for businesses. And even back then, it was obvious that traditional security tools are not good enough. Didn't with API threads, even though API APIs are basically running on the same HTP protocol as your quote unquote normal websites. And to think about modern websites are basically like 90% API based already traditional web security tool, like a web application firewall can not catch all the potential API related frites. And in fact, that's basically one of the topics which we've been pushing for years and years. And I think only last year to the API security has finally become noticeable amount of general public and quote unquote general security experts, probably because of the serious of really high profile and hugely my safe data breaches, which were affecting companies like Facebook and Instagram and United States, postal service and really huge companies, which suppose they have hundreds, if not thousands of security experts tasked to protect interfaces and they failed miserably because they were simply overlooking not immediately obvious API, the way to detect vectors.
And speaking of vectors, again, we could probably talk hours about all the possible combinations of attacks. I think in one of our earlier webinars, we have covered at least 25 of them or whatever like that finally last year, well known or was open the application security project organizations. They have finally come up with the API security, top 10 threats. So finally reputable and widely recognized security related company. We said, yes, you should have this top 10 API security threats in mind. And they are really interesting because they are covering various aspects of cybersecurity arranging from, as you mentioned earlier, authentication authorization, both on user level and an object level. They cover infrastructure level threats, like lack of rate-limiting and security misconfigurations they come more quote unquote traditional web related threats like SQL injections. But again, this is just only two of 10. And of course they are focusing on compliance related things like excessive data exposure. For example, when improperly coded API call invoked with a intentionally broken set of parameters, for example, returns your information from your whole user database instead of just one user. And this is exactly what happened with the us postal service a couple of years ago, where they managed to leak tens of millions of their customer sensitive data within weeks, basically.
Okay. So assume that attackers are out there that are just looking for API APIs for not well secured API APIs who do that maybe even automatically, so that they're really trying to find these API APIs that are not well-designed
Absolutely. And that, and by the way, here you are raising the, probably the most important API security related problem. The attackers out there, they are doing this spraying attacks basically, and they are targeting your whole network and they're able to discover API APIs and then explore them. And those who will be API switch you yourself had absolutely no idea about this is probably still the biggest problem for many companies. They simply do not know how many different API APIs have in their networks and their infrastructure. And it doesn't have to be your own API, like the one that exposes your own business logic. It can be a third party. API can be a management API for a smart device, like a printer or a back camera. It can be anything. And you probably heard about really in using a data breach in one of the, I think it wasn't a casino somewhere in the United States, which was hacked through a smart pump for a fish tank, which was displayed in a hole or an unsecured API for a smart pump for a fish tank in your casino. Its main hole was enough to Rob the casino of a substantial amount of money. Think of about potential implications of improperly configured, take care security.
But, but usually it will be one developer who designs an API for themselves or just as a helper API. And that is not well-protected and that can put a complete organization at risk. So this also needs to be identified are the tools to really find these not well-documented API APIs. If the attackers can find it, maybe the one, the ones who want to protect the organization might also be able to find that. Absolutely.
And then again, so I just, just start, I've been following this API security market for quite a number of years already. And I was totally frustrated seeing that there are so few companies who actually positions themselves as API security vendors because until probably a couple of years ago, every company in that market was an API management vendor. So basically they were thinking about how to publish your API as quickly as possible and how to start monetizing it, which is great, which is what powers the API economy. But again, from the security has always been overlooked and only in the recently published or leadership conference on apex security, which I did last year and which you can find on our website, by the way, I am happy to say that there is really a market segment for API security tools. Finally, if the year 2017 was proclaimed the year of API economy, either reputable Forbes magazine.
And I would say the year of 2019 was finally the year of API security. And again, the selection of these tools is extremely varied. There are some solutions which only focus on reactive security. If you build some escalators, they will detect if something bad is happening to your API and they'll alert you and let you investigate and fix it, which is how most other traditional security tools nowadays are functioning. But of course there are some companies which focus on practice security. They would say before you even start writing your code and the early stage of NPI design, when you create your so-called open API specification was swagger as it was previously known. And you only define which methods and properties you're exposing. You should already start thinking about security and they will help you create your API, design, your API structure in a way that it's as resilient to attacks as possible. And it's really nice to see that such developments are already ongoing and we will see more on those corrective API security solutions for this year and next year, of course.
Okay. So th this is really also the, the approach of security by design building the security into the API or not adding it afterwards as an afterthought and usually missing out one important check. Exactly. Okay. So now that we've come almost to the end of this podcast, if you could provide a few key takeaways for the audience out there, just which just had some bad feelings about the API APIs they might expose, what would you recommend to them?
Well, obviously the first and foremost recommendation would be stop thinking that API security is easy. It's not, it's extremely complicated and it really requires a very well thought out strategic approach and careful planning. And of course, to understand all the potential or third vectors, you have to educate yourself and you have to educate your other stakeholders, especially the developers, the actual people responsible for creating your API. And of course, or just like any other field of cyber security visibility is the key. You have to know all your API APIs, not your own, but also the third party API. So as I mentioned, or the management API hardware, API APIs, anything you have to discover them, you have to understand the potential risks. So basically you have to do some kind of threat modeling, enter risk assessment and classification based on those criteria. And you have to constantly monitor an API because as the real life example with, for example, Instagram heck indicate that even a very well-designed and very well protected API through a simple human mistake can go unprotected for a short period of time. That's exactly what happened with Instagram. A developer accidentally published a wrong version of API, which was not properly authenticated. So that's small of time. The hackers who managed to identify this opportunity immediately were able to hijack hundreds of high profile accounts from celebrities and bankers and actors and so on. You don't want this to happen to you, and because any company smaller than Facebook can't really bear that reputational damage can survive.
Okay. Got it. So thank you very much, Alex, for that. So of course, some of the audience are really interested in learning more about that course. I recommended two to read the leadership compass that you just mentioned about the API security products out there and to follow us on our website and you on our website when it comes to further developments here. And of course, if they want to get in touch with us or with you, please feel free to just contact us at KuppingerCole dot com or just drop us a mail. So thank you very much, Alexa. Again, I think this is a topic that deserves more than just one 15 minutes podcast or 20 minutes podcast. I will be happy to invite you for that topic again, and to, to dig a bit deeper into what's really going on there in the gory details. Anything else you want to add?
Well, first of all, thank you Mathias for inviting me again. I hope to return to this podcast in the future and discuss this and other topics as well. And thank you all for all the current and future listeners of this podcast for being with us. And again, I would like to emphasize that we are going to discuss today and in the future, hopefully topics which are not as hyped into the buzzword or the as like blockchain or AI cybersecurity and so on, but they are in no way less relevant or less dangerous or to overlook for API security is crucial for almost every company because API APIs should be really considered a part of critical infrastructure nowadays. Okay,
Great. Thank you very much. Thanks again. Thanks for listening. And I'm looking forward to having you all in one future edition office again. Bye-bye thanks.
Bye-bye .
