SlideShare a Scribd company logo
1 of 12
Download to read offline
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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

More Related Content

Recently uploaded

Introduction-to-Wazuh-and-its-integration.pptx
Introduction-to-Wazuh-and-its-integration.pptxIntroduction-to-Wazuh-and-its-integration.pptx
Introduction-to-Wazuh-and-its-integration.pptxmprakaash5
 
Arizona Broadband Policy Past, Present, and Future Presentation 3/25/24
Arizona Broadband Policy Past, Present, and Future Presentation 3/25/24Arizona Broadband Policy Past, Present, and Future Presentation 3/25/24
Arizona Broadband Policy Past, Present, and Future Presentation 3/25/24Mark Goldstein
 
Generative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdfGenerative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdfIngrid Airi González
 
Tecnogravura, Cylinder Engraving for Rotogravure
Tecnogravura, Cylinder Engraving for RotogravureTecnogravura, Cylinder Engraving for Rotogravure
Tecnogravura, Cylinder Engraving for RotogravureAntonio de Llamas
 
All These Sophisticated Attacks, Can We Really Detect Them - PDF
All These Sophisticated Attacks, Can We Really Detect Them - PDFAll These Sophisticated Attacks, Can We Really Detect Them - PDF
All These Sophisticated Attacks, Can We Really Detect Them - PDFMichael Gough
 
Arti Languages Pre Seed Pitchdeck 2024.pdf
Arti Languages Pre Seed Pitchdeck 2024.pdfArti Languages Pre Seed Pitchdeck 2024.pdf
Arti Languages Pre Seed Pitchdeck 2024.pdfwill854175
 
The work to make the piecework work: An ethnographic study of food delivery w...
The work to make the piecework work: An ethnographic study of food delivery w...The work to make the piecework work: An ethnographic study of food delivery w...
The work to make the piecework work: An ethnographic study of food delivery w...stockholm university
 
Accelerating Enterprise Software Engineering with Platformless
Accelerating Enterprise Software Engineering with PlatformlessAccelerating Enterprise Software Engineering with Platformless
Accelerating Enterprise Software Engineering with PlatformlessWSO2
 
React Native vs Ionic - The Best Mobile App Framework
React Native vs Ionic - The Best Mobile App FrameworkReact Native vs Ionic - The Best Mobile App Framework
React Native vs Ionic - The Best Mobile App FrameworkPixlogix Infotech
 
THE STATE OF STARTUP ECOSYSTEM - INDIA x JAPAN 2023
THE STATE OF STARTUP ECOSYSTEM - INDIA x JAPAN 2023THE STATE OF STARTUP ECOSYSTEM - INDIA x JAPAN 2023
THE STATE OF STARTUP ECOSYSTEM - INDIA x JAPAN 2023Joshua Flannery
 
Top 10 Hubspot Development Companies in 2024
Top 10 Hubspot Development Companies in 2024Top 10 Hubspot Development Companies in 2024
Top 10 Hubspot Development Companies in 2024TopCSSGallery
 
Email Marketing Automation for Bonterra Impact Management (fka Social Solutio...
Email Marketing Automation for Bonterra Impact Management (fka Social Solutio...Email Marketing Automation for Bonterra Impact Management (fka Social Solutio...
Email Marketing Automation for Bonterra Impact Management (fka Social Solutio...Jeffrey Haguewood
 
Automation Ops Series: Session 3 - Solutions management
Automation Ops Series: Session 3 - Solutions managementAutomation Ops Series: Session 3 - Solutions management
Automation Ops Series: Session 3 - Solutions managementDianaGray10
 
Deliver Latency Free Customer Experience
Deliver Latency Free Customer ExperienceDeliver Latency Free Customer Experience
Deliver Latency Free Customer ExperienceOpsTree solutions
 
Bitdefender-CSG-Report-creat7534-interactive
Bitdefender-CSG-Report-creat7534-interactiveBitdefender-CSG-Report-creat7534-interactive
Bitdefender-CSG-Report-creat7534-interactivestartupro
 
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...JET Technology Labs White Paper for Virtualized Security and Encryption Techn...
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...amber724300
 
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...BookNet Canada
 
A PowerPoint Presentation on Vikram Lander pptx
A PowerPoint Presentation on Vikram Lander pptxA PowerPoint Presentation on Vikram Lander pptx
A PowerPoint Presentation on Vikram Lander pptxatharvdev2010
 
Efficiencies in RPA with UiPath and CyberArk Technologies - Session 2
Efficiencies in RPA with UiPath and CyberArk Technologies - Session 2Efficiencies in RPA with UiPath and CyberArk Technologies - Session 2
Efficiencies in RPA with UiPath and CyberArk Technologies - Session 2DianaGray10
 
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdf
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdfHCI Lesson 1 - Introduction to Human-Computer Interaction.pdf
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdfROWELL MARQUINA
 

Recently uploaded (20)

Introduction-to-Wazuh-and-its-integration.pptx
Introduction-to-Wazuh-and-its-integration.pptxIntroduction-to-Wazuh-and-its-integration.pptx
Introduction-to-Wazuh-and-its-integration.pptx
 
Arizona Broadband Policy Past, Present, and Future Presentation 3/25/24
Arizona Broadband Policy Past, Present, and Future Presentation 3/25/24Arizona Broadband Policy Past, Present, and Future Presentation 3/25/24
Arizona Broadband Policy Past, Present, and Future Presentation 3/25/24
 
Generative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdfGenerative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdf
 
Tecnogravura, Cylinder Engraving for Rotogravure
Tecnogravura, Cylinder Engraving for RotogravureTecnogravura, Cylinder Engraving for Rotogravure
Tecnogravura, Cylinder Engraving for Rotogravure
 
All These Sophisticated Attacks, Can We Really Detect Them - PDF
All These Sophisticated Attacks, Can We Really Detect Them - PDFAll These Sophisticated Attacks, Can We Really Detect Them - PDF
All These Sophisticated Attacks, Can We Really Detect Them - PDF
 
Arti Languages Pre Seed Pitchdeck 2024.pdf
Arti Languages Pre Seed Pitchdeck 2024.pdfArti Languages Pre Seed Pitchdeck 2024.pdf
Arti Languages Pre Seed Pitchdeck 2024.pdf
 
The work to make the piecework work: An ethnographic study of food delivery w...
The work to make the piecework work: An ethnographic study of food delivery w...The work to make the piecework work: An ethnographic study of food delivery w...
The work to make the piecework work: An ethnographic study of food delivery w...
 
Accelerating Enterprise Software Engineering with Platformless
Accelerating Enterprise Software Engineering with PlatformlessAccelerating Enterprise Software Engineering with Platformless
Accelerating Enterprise Software Engineering with Platformless
 
React Native vs Ionic - The Best Mobile App Framework
React Native vs Ionic - The Best Mobile App FrameworkReact Native vs Ionic - The Best Mobile App Framework
React Native vs Ionic - The Best Mobile App Framework
 
THE STATE OF STARTUP ECOSYSTEM - INDIA x JAPAN 2023
THE STATE OF STARTUP ECOSYSTEM - INDIA x JAPAN 2023THE STATE OF STARTUP ECOSYSTEM - INDIA x JAPAN 2023
THE STATE OF STARTUP ECOSYSTEM - INDIA x JAPAN 2023
 
Top 10 Hubspot Development Companies in 2024
Top 10 Hubspot Development Companies in 2024Top 10 Hubspot Development Companies in 2024
Top 10 Hubspot Development Companies in 2024
 
Email Marketing Automation for Bonterra Impact Management (fka Social Solutio...
Email Marketing Automation for Bonterra Impact Management (fka Social Solutio...Email Marketing Automation for Bonterra Impact Management (fka Social Solutio...
Email Marketing Automation for Bonterra Impact Management (fka Social Solutio...
 
Automation Ops Series: Session 3 - Solutions management
Automation Ops Series: Session 3 - Solutions managementAutomation Ops Series: Session 3 - Solutions management
Automation Ops Series: Session 3 - Solutions management
 
Deliver Latency Free Customer Experience
Deliver Latency Free Customer ExperienceDeliver Latency Free Customer Experience
Deliver Latency Free Customer Experience
 
Bitdefender-CSG-Report-creat7534-interactive
Bitdefender-CSG-Report-creat7534-interactiveBitdefender-CSG-Report-creat7534-interactive
Bitdefender-CSG-Report-creat7534-interactive
 
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...JET Technology Labs White Paper for Virtualized Security and Encryption Techn...
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...
 
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...
 
A PowerPoint Presentation on Vikram Lander pptx
A PowerPoint Presentation on Vikram Lander pptxA PowerPoint Presentation on Vikram Lander pptx
A PowerPoint Presentation on Vikram Lander pptx
 
Efficiencies in RPA with UiPath and CyberArk Technologies - Session 2
Efficiencies in RPA with UiPath and CyberArk Technologies - Session 2Efficiencies in RPA with UiPath and CyberArk Technologies - Session 2
Efficiencies in RPA with UiPath and CyberArk Technologies - Session 2
 
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdf
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdfHCI Lesson 1 - Introduction to Human-Computer Interaction.pdf
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdf
 

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