Transcript of a discussion on how APIs, microservices, and cloud-native computing form a new frontier for cybersecurity vulnerabilities -- as well as opportunities for innovative defenses and resilience.
Rise of Broad Reliance on APIs Brings Novel Vector for Security Concern and Need for New Defenses
1. Page 1 of 12
Rise of Broad Reliance on APIs
Brings Novel Vector for Security
Concern and Need for New Defenses
Transcript of a discussion on how APIs, microservices, and cloud-native computing form a new
frontier for cybersecurity vulnerabilities -- as well as opportunities for innovative defenses and
resilience.
Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: Traceable.ai.
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 application programming interfaces (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
2. Page 2 of 12
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 continuous integration and continuous delivery (CI/CD). That creates the velocity.
You’re changing things once every hour, sometimes even more often.
That 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?
Speed and safety needed for cloud-native apps
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
If you have more bugs in your code
because you are moving very, very
fast, it creates a greater challenge.
3. Page 3 of 12
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 software as a service
(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
fundamentally can 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?
When you’re calling on third-
party APIs ... all of those
APIs are not secure, and so
your system fundamentally
can become more secure.
4. Page 4 of 12
API attacks on the rise, a global threat
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?
Learn More
About Traceable AI.
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.
It’s a matter of now taking
these threats seriously.
For a long time, people
didn’t think about APIs.
5. Page 5 of 12
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 APIs and
be serious about securing them.
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.
History of troubleshooting, one company at a time
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.”
We have to learn as an
industry to … secure
APIs and be serious
about securing them.
6. Page 6 of 12
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.
Learn More
About Traceable AI.
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
[Getting in control]
means learning how the
data flows between
these different APIs.
7. Page 7 of 12
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 understand the behavior apply to
what’s going on in operations as well as what goes on in development? Is this a one-
size-fits-all solution? Or do you have to attack those problems separately?
One-size-fits-all approach
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, such as
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: Let’s look at 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 vulnerabilities are these people already seeing?
When you have such
instrumentation tracing,
you can take the same
approach everywhere.
8. Page 8 of 12
Vulnerable points to protect
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 it also includes more sensitive data.
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 a long time. And normally you
would have things like SQL injection and cross-site scripting, and those were always in
that list.
Now there’s an additional 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.
Learn More
About Traceable AI.
Just recently in 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 Amazon Web Services
(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.
As you can see from these examples, we are starting to see 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.
9. Page 9 of 12
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?
Know what’s there, protect it, and get proactive
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.
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, with new microservices. 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
It’s a big mistake if
companies are not
getting to this faster.
They are exposing
themselves in a big way.
10. Page 10 of 12
do they get called? What kind of data passes through them? What kinds of data are they
fetching out of where? And on and on.
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 you have an attacker trying to use an API to extract much more data than what is
normal for that data, you know that something is abnormal about it. 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. 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 the potential vulnerabilities, 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.
Learn More
About Traceable AI.
Gardner: Jyoti, what should businesses do to prepare themselves at an early stage for
API security? Who should be tasked with kicking this off?
Build your app security team
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 to 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.
For APIs, you have to build
a behavioral learning-
based system. … That’s
how we get to a very high
degree of protection.
11. Page 11 of 12
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 get
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.
Thanks again for listening, please pass this along to your business associates, and do
come back next time.
Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: Traceable.ai.
Transcript of a discussion on how APIs, microservices, and cloud-native computing form a new
frontier for cybersecurity vulnerabilities -- as well as opportunities for innovative defenses and
resilience. Copyright Interarbor Solutions, LLC, 2005-2021. All rights reserved.
You may also be interested in:
• Learn More About the Technologies and Solutions Behind Traceable.ai.
• Three Threat Vectors Addressed by Zero Trust App Sec
Most businesses have to get an
understanding and some kind of
control over the APIs that are
there. Then … start securing and
getting a better security posture.
12. Page 12 of 12
• Web Application Security is Not API Security
• Does SAST Deliver? The Challenges of Code Scanning.
• Everything You Need to Know About Authentication and Authorization in Web APIs
• Top 5 Ways to Protect Against Data Exposure
• TraceAI : Machine Learning Driven Application and API Security