Rise of Broad Reliance on APIs Brings Novel Vector for Security Concern and Need for New Defense

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Thinking of IT security as a fortress or a moat around your compute assets has now given way to a more realistic and pervasive posture. A cybersecurity perimeter, it turns out, was an illusion.

A more effective extended-enterprise strategy protects business assets and processes wherever they are — and wherever they might reach. As businesses align to new approaches such as zero trust and behavior-modeling to secure their data applications, infrastructure, and networks, there’s another rapidly expanding digital domain that needs modern protection.

Stay with us now as we explore how APIs, microservices, and cloud-native computing in general form a new frontier for cybersecurity vulnerabilities — as well as opportunities for innovative defenses and resilience.

To learn more about why your expanding use of APIs may be the new weak link in your digital business ecosystem, please join me in welcoming our special guest, Jyoti Bansal, Chief Executive Officer and Co-Founder at Traceable.ai. Welcome, Jyoti.

‍Jyoti Bansal: Thank you, Dana. I’m very excited to be here.

Gardner: Jyoti, has the global explosion of cloud-native apps and services set us up for a new variety of security vulnerability? How serious is this new threat?

‍Bansal: Well, it’s definitely new and it’s quite serious. If you look at every time we go through a change in IT architectures, we get a new set of security challenges. The adoption of cloud-native architectures means challenges in a few things.

One, you have a lot of APIs and these APIs are doors and entryways into your systems and your apps. If those are not secured properly, you have more opportunities for attackers to steal data. You want to open the APIs so that you can expose data, but attackers will try to exploit that. We are seeing more examples of that happening.

The second major challenge with cloud-native apps is around the software development model. Development now is more high-velocity, more Agile. People are using DevOps and CI/CD. And that creates the velocity. You’re changing things once every hour, sometimes even more often.

That all creates new kinds of opportunities for developers to make mistakes in their apps and in their APIs, and in how they design a microservice; or in how different microservices or APIs interact with each other. That often creates a lot more opportunity for attackers to exploit.

‍Gardner: Companies, of course, are under a lot of pressure to do things quickly and to react to very dynamic business environments. At the same time, you have to always cover your backside with better security. How do companies face the tension between speed and safety?

‍Bansal: That’s the biggest tension, in many ways. You are forced to move fast. The speed is important. The pandemic has been even more of a challenge for a lot of companies. They had to move to more of a digital experience much faster than they imagined. So speed has become way more prominent.

But that speed creates a challenge around safety, right? Speed creates two main things. One is that you have more opportunity to make mistakes. If you ask people to do something very fast because there’s so much business and consumer pressure, sometimes you cut corners and make mistakes.

Not deliberately. It’s just as software engineers can never write completely bug-free code. But if you have more bugs in your code because you are moving very, very fast, it creates a greater challenge.

So how do you create safety around it? By catching these security bugs and issues much earlier in your software development life cycle. If a developer creates a new API and that API could be exploited by a hacker — because there is a bug in that API around security authentication check — you have to try to find it in your test cycle and your software development life cycle (SDLC).

The second way to gain security is by creating a safety net. Even if you find things earlier in your SDLC, it’s impossible to catch everything. In the most ideal world, you’d like to ship software that has zero vulnerabilities and zero gaps of any kind when it comes to security. But that doesn’t happen, right?

You have to create a safety net so that if there are vulnerabilities because the business pressure was there to move fast, that safety net that can still block what occurs and stop those from trying to do things that you didn’t intend from your APIs and applications.

‍Gardner: And not only do you have to be thinking about APIs you’re generating internally, but there are a lot of third-party APIs out there, along with microservices, when doing extended-enterprise processes. It’s a bit of a Wild West environment when it comes to these third-party APIs.

‍Bansal: Definitely. The APIs you are building and using internally through your microservices may also have an external consumer calling those APIs. Other microservices may also be calling them — and so there is exposure around that.

Third-party APIs manifest in two different ways.One is that you might be using a third-party API or library in your microservice. There might be a security gap there.

The second way comes when you’re calling on third-party APIs. And now almost everything is exposed as APIs – such as if you want to check for some data somewhere, or call some other SaaS service or cloud service, or a payment service. Everything is an API, and those APIs are not always called properly. All of those APIs are not secure. And so your system can fundamentally become more insecure.

It is getting close to a wild, Wild West with APIs. I think we have to take API security quite seriously at this point.

‍Gardner: We’ve been talking about API security as a function of growing pains, that you’re moving fast, and this isn’t a process that you might be used to.

But there’s also malice out there. We’ve seen advanced, persistent threats in such things as zero-day exploits and with Microsoft Exchange Servers recently. We’ve certainly seen with the SolarWinds exploits how a supply chain can be made vulnerable.

Have we seen people take advantage of APIs, too, or is that something that we should expect?

‍Bansal: Well, we should definitely expect that. We are seeing people take advantage of these APIs. If you look at data from Gartner, they stated that by 2022, API abuses will move from an infrequent to the most frequent attack vector. That will result in more data breaches in enterprises and web applications. That is the new direction because of how applications are consumed with APIs.

The API has naturally become a more frequent form of attack vector now.

‍Gardner: Do you expect, Jyoti, that this is going to become mission-critical? We’re only part way into the “software eats the world” thing. As we expect software to become more critical to the world, APIs are becoming more part of that. Could API vulnerabilities become a massive, global threat vector?

‍Bansal: Yes, definitely. We are, as you said, only partially into the software-eats-the-world trend. We are still not fully there. We are only 30 to 40 percent there. But as we see more and more APIs, those will create a new kind of attack vector.

It’s a matter of now taking these threats seriously. For a long time, people didn’t think about APIs. People only thought about APIs as internal APIs; that you will put internal APIs between your code and different internal services. The external APIs were very few. Most of your users were coming through a web application or a mobile application, and so you were not exposing your APIs as much to external applications.

If you look at banking, for example, most of the bank services software was about online banking. End users came through a bank web site, and then users came through mobile apps. They didn’t have to worry too much about APIs to do their business.

Now, that’s no longer the case. For any bank, APIs are a major source of how other systems integrate with them. Banks didn’t have to expose their systems through those apps that they built, but now a lot of third-party apps are written on top of those APIs — from a wallet app, to different kinds of payment systems, to all sorts of things that are out there– because that’s what consumers are looking for. So, now — as you start doing that — the amount of traffic coming through that API is not just through the web or mobile front-ends directly. It’s significantly increasing.

The general use of internal APIs is increasing. With the adoption of cloud-native and microservices architectures, the internal-to-external boundary is starting to blur too much. Internal APIs could become external at any point because the same microservice that our engineering team wrote is now being used by your other internal microservices inside of your company. But they are also being exposed to your partners or other third-party systems to do something, right?

More and more APIs are being exposed out there.We will see this continued explosion of APIs because that’s the nature of how modern software is built. APIs are the building block of modern software systems.

I think we have two options as an industry. Either we say, “Okay, APIs could be risky or someone could attack them, so let’s not use APIs.” But that to me is completely wrong because APIs are what’s driving the flexibility and fluidity of modern software systems and the velocity that we need. We have to just learn as an industry to instead secure them and be serious about securing APIs.

‍Gardner: Jyoti, your role there as CEO and co-founder at Traceable.ai is not your first rodeo. You’ve been a serial startup leader and a Silicon Valley tech visionary. Tell us about your other major companies, AppDynamics, in particular, and why that puts you in a position to recognize the API vulnerability — but also come up with novel ways of making APIs more secure.

‍Bansal: Yes. I have a unique advantage in that I have founded companies to solve big problems like these in the past. AppDynamics was my first company, which I started back in 2008. The purpose was to give development teams good solutions to diagnose and troubleshoot when something goes wrong in their distributed software systems.

At that time, we were starting to see a lot of service-oriented architectures (SOA). People were struggling when something was slow and users experienced slowdowns from their websites. How do you figure out where the slowdown is? How do you find the root cause?

That space eventually became what is called application performance management (APM). What we came up with was, “How about we instrument what’s going on inside the code in production? How about we trace the flow of code from one service to another service, or to a third service or a database? Then we can figure out where the slow down and bottlenecks are.”

By understanding what’s happening in these complex software systems, you can figure out where the performance bottleneck is. We were quite successful as a company. We were acquired by Cisco just a day before we were about to go IPO.

The approach we used there solves problems around performance – so monitoring, diagnosing, and troubleshooting diagnostics. The fundamental approach was about instrumenting and learning what was going on inside the systems.

That’s the same approach we at Traceable.ai apply to solving the problems around API security. We have all these challenges around APIs; they’re everywhere, and it’s the wild, Wild West of APIs.

So how do you get in control? You don’t want to ask developers to slow down and not do any APIs. You don’t want to reduce the velocity. The way you get control over it is fundamentally a very similar approach to what we used at AppDynamics for performance monitoring and troubleshooting. And that is by understanding everything that can be instrumented in the APIs’ environment.

That means for all external APIs, all internal APIs, and all the third-party APIs. It means learning how the data flows between these different APIs, which users call different APIs, what they are trying to achieve out of it, what APIs are changed by developers, and which APIs have sensitive data in them.

Once you automatically understand that — about all of the APIs – then you start to get in control of what is there. Once you are in control of what’s there, you can learn if some user is trying to use these APIs in a bad way. You know what seems like an attack, or if something wrong is happening. There might be a data breach or something. Then you can quickly go into prevention mode. You can then block that attack.

There are a lot of similarities from my experience at my last company, AppDynamics, in terms of how we solve challenges around API security. I also started a second company, Harness. It’s in a different space, targeting DevOps and software developers, and helping them with CI/CD. Harness is now one of the leading platforms for CI/CD or DevOps.

So I have a lot of experience from the vantage point of what do modern software engineer organizations have to do from a CI/CD DevOps perspective, and what security challenges they start to run into.

We talk to Harness customers doing modern CI/CD about application and API security. And it almost always comes as one big challenge. They are worried about microservices, about cloud-native architectures, and about moving more to APIs. They need to get in control and to create a safety net around all of this.

‍Gardner: Does your approach of trace, monitor, and understanding the behavior apply to what’s going on in operations as well as to what goes on in development? Is this a one-size-fits-all solution? Or do you have to attack those problems separately?

‍Bansal: That’s the beauty of this approach. It is in many ways a one-size-fits-all approach. It’s about how you use the data that comes out of this trace-everything instrument. Fundamentally it works in all of these areas.

It works because the engineering teams put in what we call a lightweight agent. That agent goes inside the runtime of the code itself, running in different programming languages, such as Java, PHP, and Python. The agents could also run in your application proxies in your environment.

You put the same kinds of instruments, lightweight agents, in for your external APIs, your internal microservices APIs, as well as the third-party APIs that you’re calling. It’s all the same.

When you have such instrumentation tracing, you can take the same approach everywhere. Ideally, you put the same in a pre-production environment while you are going through the software testing lifecycle in a CI/CD system. And then, after some testing, staging, and load testing, you start putting the same instrumentation into production, too. You want the same kind of approach across all of that.

In the testing cycle, we will tell you — based on all instrumentation and tracing, looking at all the calls based on your tests – that these are the places that are vulnerable, and these are the APIs that have gaps and could be exploited by someone.

Then, once you do the same approach in production, we tell you not only about the vulnerabilities but also where to block attacks that are happening. We say, “This is the place that is vulnerable, right now there is an attacker trying to attack this API and steal data, and this is how we can block them.” This happens in real-time, as they do it.

But it’s fundamentally the same approach that is being used across your full SDLC lifecycle.

‍Gardner: I don’t want to put the cart in front of the horse as we talk about the solution because I’m afraid that there is still a degree of education that is required about how big this problem is and how large it could become. So, let’s go back to all the people in these roles or personas, be it developer, operations, SecOps, and traditional security. Do you have any examples or metrics of where API vulnerabilities have cropped up? What are the major categories of API vulnerabilities that these people already seeing?

‍Bansal: A lot of API vulnerabilities crop up around unauthenticated endpoints, such as exposing an API and it doesn’t have the right kind of authentication. Second is around not using the right authorization, such as calling an API that is supposed to give you data for you as user 1, but the authorization had a flaw that could be exploited for you to take data — not just as user 1 but from someone else, a user 2 or maybe even a large number of users. That’s a common problem that happens too often with APIs.

There are also leaky APIs that give you more data than they should, such as it’s only supposed to give the name of someone, but when you call the API it gives an entire object that has 10 other fields that also includes more sensitive data than just the name you asked for.

There are these patterns of attacks and threats that are starting to emerge in the APIs.

In the world of application security, we have the OWASP Top Ten list that the app security teams and the security teams have followed for along time. And normally you would have things like SQL injection and cross-site scripting, and those were always in that list.

Now there’s a parallel list called the OWASP API Security Top Ten, which lists the top threats when it comes to APIs. Some of the threats I described are key parts of it. And there are a lot of examples of these API-involved attacks these days.

Just recently, 2020, we had a Starbucks vulnerability in API calls, which potentially exposed 100 million customer records. It was around an authentication vulnerability. In 2019, Capital One was a high-profile example. There was an AWS configuration API that wasn’t secured properly and an attacker got access to it. It exposed all the AWS resources that Capital One had.

There was a very high-profile attack that happened on T-Mobile in 2018, where there was an API leaking more data than it was supposed to. Some 2.3 million customers’ data was stolen. In another high-profile attack, at Venmo, a public API was not exposing the data for the right users so 200 million transactions of data were stolen from Venmo. You will see these 10 examples, and we are starting to see these patterns emerge on the vulnerabilities attackers are exploiting in APIs.

‍Gardner: Now, these types of attacks and headlines are going to get the attention of the very top of any enterprise, especially now where we’re seeing GDPR and other regulations require disclosure of these sorts of breaches and exposures. This is not just nice to have. This sounds like potentially something that could make or break a company if it’s not remediated. And now that you know that it’s a risk you have to think about how to best remediate, right?

‍Bansal: Definitely. No one should take API security lightly these days. A lot of the traditional cybersecurity teams have put a lot of their focus and energy in securing the networks and infrastructure. And many of them are just starting to get serious about this next API threat vector. It’s a big mistake if companies are not getting to this faster. They are exposing themselves in a big way.

‍Gardner: The top lesson for security teams, as they have seen in other types of security vulnerabilities, is you have to know what’s there, protect it, and then be proactive. What is it about the way that you’re approaching these problems that set you up to be able to be proactive — rather than reactive — over time?

‍Bansal: Yes, the fundamentals of security are the same. You have to know what is there, you have to protect it, and then you become proactive about it. And that’s the approach we have taken in our solution at Traceable.ai.

Number one is all about API discovery and risk assessment. You put us there in your environment and very quickly we’ll tell you what all the APIs are. It’s all about discovery and inventory as the very first thing. These are all your external APIs. These are all your internal APIs. These are all the third-party APIs that you are invoking. So it starts with discovery. You have to know what is there. And you create an inventory of everything.

The second part, when you create that inventory, is to give a risk score. We give every API a risk score: internal API, external API, and third-party, all of them. The risk score is based on many dimensions, such as which APIs have sensitive data flowing through them, which APIs are exposed publicly versus not, which APIs have what kind of authentication to them, and what APIs are internally using your critical database systems and reading data from those. Based on all of these factors, we are creating a risk heat map of all of our APIs. So that’s really the first part, you have to understand, create an inventory, and know what is there.

The most important part for APIs security is to do this continuously. Because you’re living in the world of CI/CD, any kind of API discovery or assessment cannot be static, like you do it once a month, once a quarter, or even once a week. You have to do it dynamically all the time because code is changing. Developers are putting new code continuously out there. So the APIs are changing, new microservices, new all of everything. All of the discovery and risk assessment has to happen continuously. So, that’s really the first challenge we handle at Traceable.ai.

The second problem we handle is to build a learning model. That learning model is based on a very sophisticated machine learning (ML) approach on what is the normal usage behavior of each of these APIs. What users are calling an API? What sequence do they get called? What kind of data passes through them? What kinds of data are they fetching out of them? What APIs are used in what order? If you call our external API, what internal services APIs that API will internally use?

So we are learning all of that automatically. Once you learn that, you start comparing every new API request with what the normal model of how your APIs are supposed to be used.

Now, if now you have an attacker trying to use an API to extract much more data than what is normal for that API, like normally people ask for data for one user, and then suddenly you have an API call where someone’s asking you for data for 100,000 users,  something is abnormal about it, so you could flag it, and that’s a key part of how we think of the second part, which is how do you protect these APIs from bad behavior.

That cannot be done with the traditional web application firewall (WAF) and runtime application self-protection (RASP), and those kinds of approaches. Those are very rule-based or static-rules-type of base approaches. For APIs, you have to build a behavioral learning based system. And that’s what our solution is about. That’s how we get to a very high degree of protection for these APIs.

The third element to the solution is the proactive part. After a lot of this learning, we also examine the behavior of these APIs and where the potential vulnerabilities are, based on the models. The right way to proactively use our system is to feed that into your testing and development cycle. That brings the issues back to the developers to fix the vulnerabilities. We can help find them earlier in the lifecycle so you can integrate that into what you’re doing in your application security testing processes. It closes the loop on you doing all of this – only proactively now.

‍Gardner: Jyoti, what should businesses do to prepare themselves at an early stage for API security? Who should be tasked with kicking this off and being the instigator int he organization to take API security seriously? Who’s shoulders does this fall on?

‍Bansal: API security falls under the umbrella of app security. In many businesses, app security teams are now tasked to secure the APIs in addition to the traditional web applications.

In many places, we are also seeing businesses create teams around what they call product security. If you are a company with FinTech products, your product is an API because your product is primarily exposed through APIs. Then people start building out product security teams who are tasked with securing all of these APIs. In some cases, we see the software engineering team directly responsible for securing APIs.

Whatever the model is, the first thing every business has to do is to create a responsibility around securing APIs. After that, you have to bring in something to understand the inventory. I still am amazed every time I see so many businesses we talk to struggling with just even knowing what APIs are there.

The problem is they don’t even know what all of their APIs are. They may have 500 or 2,000 developers in the company. They are building all of these APIs, and can’t even track them. So most businesses have to start by getting an understanding and some kind of control over the APIs that are there. Then you can start securing and getting a better security posture around those.

‍Gardner: I’m afraid we’ll have to leave it there. You’ve been listening to a sponsored BriefingsDirect discussion on how APIs, microservices, and cloud-native computing may be the new weak link in your expanding digital business ecosystem. And we’ve learned how modern security strategies of tracing, analyzing, and modeling behaviors provide opportunities for new API defenses and resilience.

And now a big thank you to our guest, Jyoti Bansal, Chief Executive Officer and Co-Founder at Traceable.ai. Thank you so much, Jyoti.

‍Bansal: Thank you, Dana.

‍Gardner: And a big thank you as well to our audience for joining this BriefingsDirect API protection discussion. I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host throughout this series of Traceable.ai-sponsored BriefingsDirect discussions.

Stay tuned for our next podcast in the series, again with Jyoti, for a deep-dive into ways that APIs can be made more robust in production as well as in development.