Let there be light: Ensuring visibility across the entire API lifecycle

The following article is based on a webinar series on enterprise API security by
Imvision^[1], featuring expert
speakers from IBM, Deloitte, Maersk, and Imvision discussing the
importance of centralizing an organization’s visibility of its APIs
as a way to accelerate remediation efforts and improve the overall
security posture.

Centralizing security is challenging in today’s open
ecosystem

When approaching API visibility, the first thing we have to
recognize is that today’s enterprises actively avoid managing all
their APIs through one system. According to IBM’s Tony Curcio,
Director of Integration Engineering, many of his enterprise
customers already work with hybrid architectures that leverage
classic on-premise infrastructure while adopting SaaS and IaaS
across various cloud vendors.

These architectures aim to increase resilience and flexibility,
but are well aware that it complicates centralization efforts. In
these organizations, it is imperative to have a centralized API
location with deployment into each of these locations, to ensure
greater visibility and better management of API-related business
activities.

The challenge for security teams is that there isn’t one central
place where all APIs are managed by the development team – and as
time passes, that complexity is likely to only get worse. Moreover,
this complexity doesn’t stop at the infrastructure level, but
carries on into the application layer.

Deloitte’s Moe Shamim, Senior Technology Executive and Deputy
CISO of US Consulting, sees non-monolithic application development
as key. He claims that organizations must now break down those
millions of lines of code into API-based, modularized processes and
systems in order to remain competitive, all while ensuring that
threat vectors are kept down to a minimum. This requires
significant rethinking as one must now account for API gateways,
IAMs, throttling and more, which means significant time and
resources.

The API footprint of organizations is no longer increasing
organically over time. It now consists of various APIs whose
origins come from mergers and acquisitions, versioning, internal
APIs, 3rd party APIs, drift from original intended usage, dev,
test, debug and diagnostic purposes and so on. This makes
complexity an even bigger issue, as many APIs are undocumented and
unmanaged, and needless to say – unprotected.

Where do ‘Shadow APIs’ come from?

Enforcing a consistent program across each of the different
environments where enterprise assets are located is a challenge in
this hybrid cloud reality. One should take this consistency
challenge into consideration when selecting technology stacks, so
that enforcing policies and governance programs everywhere is not
an issue.

But this is easier said than done, especially in successful
enterprises that merge with and acquire other organizations: each
business uses different technologies, mandating a customized,
bespoke API security process for each new environment that’s
added.

Here’s what you should pay attention
to when evaluating a full lifecycle API security
solution^[2]

API lifecycle? API lifestyle!

According to Moe Shamim, the API lifecycle can be boiled down to
the pillars found in the image below. When fashioning an API
security strategy, one must take into account architecture,
distribution, design and a whole slew of other aspects that impact
the way an organization develops its approach to APIs. You can look
at each of these aspects as controls you inject at every stage of
the API lifecycle. And it essentially ties back to visibility and
centralization discussed above.

An image of API lifestyle pillars

Planning determines issues like whether APIs will only
be used within the network firewall or publicly, as well as issues
like authentication. It’ll also touch upon more technical issues
such as builds, gateway types and the programming languages that
you’ll use. The important thing–and this goes for every decision
you make regarding your security posture–is to make a choice that
aligns with your ecosystem of tools, and takes your threat modeling
into consideration.

In the Build pillar, scanning for OWASP Top 10 issues
is a must, and SAST tools are great for that. Pentesting and
versioning may not necessarily be integrated into your security
posture, but they’re both powerful mechanisms that will surely
benefit your security arsenal.

The Operate pillar includes issues like throttling,
caching, and logging. A robust logging and monitoring mechanism is
a must-have in the remediation phase, as it enables you to fix
vulnerabilities from version to version.

Last but not least, we arrive at the Retire pillar of
the lifecycle. Removing endpoints that are no longer in use is an
essential best practice; basically, if you no longer need a service
– don’t leave it on. And if you don’t need an API at all anymore,
just take it offline; the same goes for cloud accounts.

Tony Curcio claims that one of the key tenets in the governance
of API programs is coordination between the API producers, product
management, and consumers. Looking at the security disposition of
each of those personas and coordinating API policies that ensure
secure use for each is a fundamental aspect of an organization’s
security posture.

Having an API-first mentality within the organization definitely
helps. At IBM, for example, they build their own API management
technology that enables them to expose, secure, and protect their
APIs more easily. Having advanced technology behind you–like Imvison^[3]–also goes a long way.
Their AI technology helps us understand more about attack vectors,
including critical issues like its source.

Taking an intelligence-led security response approach

Gabriel Maties, Senior Solution Architect at Maersk, offers
another perspective. With Maersk being three years into an API
program and following a serious breach, cybersecurity is taken into
account constantly as a way to stay at least as good as the
attackers, if not better.

Sharing his perspective on observability, Gabriel sees API
management as a multi-actor discipline from the very beginning
because it shares resources and exposes them internally. Therefore,
each and every point of entry into your system and its supporting
mechanisms should be carefully observed and monitored
centrally.

This centralization is important because observability is
multidimensional in the sense that there’s never one single aspect
to monitor. This calls for a holistic view of APIs that enables you
to easily understand where APIs are deployed, who owns them, who
consumes them, how they’re consumed, what normal consumption looks
like and how each one is protected. Centralization also enables you
to understand better what each API’s lifecycle looks like, how many
versions exist, what data is shared, where it’s stored and who’s
using it.

Centralization is the only way to manage this complex ecosystem
in a way that ensures maximum benefit and minimum risk.

An image of API visibility layers

Having centralized observability further enables insights, which
allows you to take action on your observations. Observability
allows you to look at ongoing, active attacks that you may not even
know aboutת and even formulate strategies that leverage the actions
taken upon the insights you draw from your observations.

Rule-based security is highly effective, and
machine learning and deep learning are two technologies that
automate and streamline it^[4]. There is simply no
other option as the amount of data to contend with is overwhelming,
not to mention that these technologies enable adaptive threat
protection that helps contend with new threats.

The bad news is that hackers are also using these same
technologies, and dealing with that requires significant
organizational maturity to take the actions required to handle
that. We’re talking about some heavy-duty actions here, like
turning off load balancers, switching over firewalls, and other
infrastructural changes done in an automatic, rapid-fire fashion.
This cannot be done without a high level of maturity across the
organization.

Supervised machine learning can help organizations develop this
maturity. It enables you to handle huge numbers of rule sets and
insights so that you can design automatic action flows. Data
science offers significant know-how in terms of tracking specific
attacker behavior, which is critical when there are different
sources and advanced, persistent threats.

This intelligence-led security response empowers a continuous
adaptive, reflexive response that leans on quantified evidence when
changing and updating rules and processes. This is the only way to
deal with the increasingly sophisticated attacks we’re seeing.

The screens went black: A real-life attack
story

Gabriel talked about a real attack^[5]
that he experienced while working at the Digital Container Shipping
Association (DCSA). One day, about nine months after he joined,
their screens went blank. Disconnecting and unplugging actions
didn’t help, it was already too late and within minutes thousands
of computers were rendered useless.

This was not an attack for financial incentives, but rather a
destructive one meant to bring the DCSA to its knees. Gabriel and
his team’s only choice was to rebuild, as the attackers used
one-way encryption. Obviously, while rebuilding the system,
cybersecurity was a major priority. Dynamic analysis was considered
paramount to their efforts so that they could perform real-time
analysis to empower ongoing learning and threat adaptation. Their
goal was to learn what normal and abnormal internal behavior looked
like, as 80% of attacks are internal.

Following the attack, Gabriel came up with 4 levels of
observability, health checks and a way to determine whether a
system’s health has been compromised. All processes and
architecture decisions were now forced through cybersecurity
assessment and must pass a number of checks and balances. This
doesn’t mean that all the boxes need to be ticked to get a new
process or decision approved, because the main point here is to
drive knowledge of your gaps and weaknesses so that you can
leverage the right capabilities and vendors for your security
philosophy.

Over the last 2 years we’ve seen a growing trend of
organizations adopting specific API tools that help monitor,
discover and unsettle shadow APIs to better understand their risks.
This is a great development, as APIs are totally different from the
application world we came from. The only way to protect APIs is to
adopt unique tools and processes that were built specifically for
them.

API security: Getting the board onboard

The proliferation and severity of cybersecurity attacks in our
landscape are making the boards and executives of many enterprises
take more interest in API protection. Increased visibility is
another way to get execs to understand the risks they’re exposed
to. If you can find a way to show your execs how much-unprotected
data is at risk easily, you’ve won half the battle.

This visibility will, in turn, empower a more adaptive,
reflexive cybersecurity posture that will enable you to
continuously learn, draw insights and modify your posture in
response to new types of attacks.

Get this RFP template to help you
simplify the process of selecting the right API security vendor for
your business^[6]

Developing a consistent, visible security posture across all of
your enterprise assets is a central tenet to any robust
cybersecurity strategy. This security posture must take into
account the four pillars of the API lifecycle: Plan, Build, Operate
and Retire. To do that correctly, you’ve got to choose the
technologies that will enable you to enforce the policies, tools
and governance that you decided upon when starting out on your API
security journey.

Of no less importance is developing a holistic, centralized
strategy that empowers the visibility you need to protect your
assets. Advanced ML and Deep Learning technologies delivered by
innovative companies like Imvision can definitely help you achieve
that.