Why API Security Needs Graph Technology

API-developing organizations can leverage graph to not only better secure their API landscape in light of growing cybersecurity threats, but to better govern, manage, and strategize around their APIs both now and in the future

APIs have been a foundational component of the digital world for decades, but they’ve become critical to organizations worldwide in recent years. APIs help accelerate innovation, expand partner engagement, improve customer experiences, and meet other demands of today’s fast-paced business environments.

 Every time you buy something on Amazon, hundreds of “API calls” are invoked as the store interacts with the merchandisers’ inventory system, with various shipping services to schedule delivery, and with your PayPal account to take payment. Your streaming platforms use APIs to help you easily uncover content that will interest you. APIs confirm your bookings with airlines and hotels from third-party websites, and they help verify you when you log into an application to avoid tedious authentication processes.

APIs have become a hot-button security topic, as each poorly-designed API can represent multiple access points. With the number of APIs expected to reach into  the trillions by 2031 , we’re watching organizations attack surfaces expand massively and rapidly in real time.

There are clear consequences of this uncontrolled expansion, with APIs being named  the number one attack vector in 2022 and with API abuses and related data breaches  expected to nearly double by 2024 . Broken, hacked, and exposed APIs are behind the major high-profile data breaches exposing sensitive personal, medical, and financial data.

"The whole point of APIs is to open up access to applications and data. This access is great for companies and their partners, developers and customers, but it's also music to an attacker's ears. It creates a huge attack surface."  - Mark McNeill, Gartner Analyst

This monitored uptick in attacks on APIs has created a rush to secure them, with the de facto-approach being perimeter-based to help block and prevent incoming attacks. It’s an approach akin to the implementation of firewalls in the 1990s to keep suspicious traffic out of corporate data centers. What we learned then is what we’re learning again now:  that perimeter protections aren’t enough to properly secure the organization at large.

The reality is that checking the standard boxes of protecting the perimeter, having APIs registered on gateways, and even embedding security alongside API development efforts isn’t enough to sustain the level of threats on the horizon. It's not enough to protect against API abuse, either. Perimeter protection should realistically be buying organizations the time they need to take down high-risk APIs and repair them.

“It’s one thing to know the immediate likelihood of an API being exposed by monitoring attacker activity. It’s another level of risk assessment entirely to understand, for example, whether an API provides access to personally identifiable information, whether it would make headlines if it were breached, or whether it can be taken off the table and repaired before attackers have a chance to find it.”  - Phil Meredith, CEO & Founder, Process Tempo

Securing APIs must become a far more comprehensive effort than what it is currently, but this effort is easier said than done. Let’s take a look at why.

Challenges

Converting API Security into a more comprehensive effort is difficult for three key reasons:

1) There is generally no single department responsible for API Security.

Surveys from Salt indicate that 21% of API security responsibility is on developers, 20% on the API team, 16% on the AppSec team, 16% on DevSecOps, 11% on DevOps, 9% on InfoSec, and 4% on the platform or product team.

Such disconnect between who’s responsible for what makes unifying efforts especially challenging, with each individual team maintaining their own agendas, objectives, and KPIs, answering to no-one else but their own department heads.

2) While API security tools, gateways, and even API platforms provide data and information around APIs, this data remains siloed.

API data lives within its corresponding tool or system under the control of the team that has implemented that tool for their own specific purpose. So long as this data remains disconnected and siloed, leaders cannot generate a comprehensive perspective into their API risk levels and truly understand the scope of their potential API security problem.

In addition, other API stakeholders that could leverage certain data either cannot access it or are not aware it even exists. This creates an “invisible” or a “micro” bottleneck - a ground-level disruption or blocker hindering the preferred/optimal flow of data and information.

3) The combination of Challenge  #1 and Challenge  #2 makes generating efficient processes around APIs very difficult.

If leadership cannot access an executive summary of what they’re working with, then directing, prioritizing, and coordinating any kind of effort becomes notoriously difficult. Without a leader knowing which department is producing the most high-risk APIs, for example, how can they allocate resources to support and correct this team's efforts? This question is just one of many, many questions that require answers around the API effort.

These challenges leave organizations with little idea of what they  don’t know about their APIs. Many organizations today don't even know how many APIs they have, which is incredibly jarring from a security perspective.

Having answers to basic questions like these, and being able to establish a degree of transparency, is essential to securing any environment. Yet API-developing organizations continue churning out unknown numbers of APIs into the void.

With problems of this severity spanning across people, processes, and technology, it’s not surprising that many of these issues are either too complex or demanding to take on, too significant a cost to resolve, or are even outright unfixable. Fortunately, so long as graph technology is available, it’s neither of these things.

APIs + Graph Technology: A Match Made In Cybersecurity Heaven

While there is no such thing as a one-size-fits-all solution, there is one critical technology - graph technology - that organizations should be leveraging to bring unparalleled transparency to their API landscapes.

By establishing transparency through graph, API-developing organizations can immediately begin working with a more robust foundation around their APIs of which all other API efforts can then be supported. This support is often provided by an extension of the graph in the form of graph databases, graph data science, and graph analytics.

For those unfamiliar with graph technology, an overview of some key items are available below.

 What is Graph Technology?: Graph technology is a major evolutionary step in data. Graphs store data in a way that mirrors how the human brain thinks, mapping associations and relationships via neurons (nodes) and synapses (relationships). By structuring data this way, graphs help uncover relationships in data that are not often identified or analyzed through traditional means.

 What is a Graph Database?: When embedded within a database format, graph technology can house data across extremely large, interconnected datasets, providing visibility and clarity into even the most complex data environments.

 What is a Knowledge Graph?: A knowledge graph, also known as a semantic network, represents a network of real-world entities—i.e. objects, events, situations, or concepts—and illustrates the relationship between them. This information is usually stored in a graph database and visualized as a graph structure, prompting the term knowledge “graph.”

 What is Graph Data Science (GDS)?: GDS is a science-driven approach to gain knowledge from the relationships and structures in graph-based data, typically to power predictions. Commonly used to power AI and machine learning objectives.

 What is Graph Analytics?: Graph Analytics is data & analytics capabilities embedded directly on top of connected graph data. Types of analytics capabilities often include Path Analysis, Connectivity Analysis, Centrality Analysis, and Network Analysis, but more advanced graph analytics capabilities have an inverse relationship to skill dependency. The more advanced the graph analytic capability, the lower the skill dependency needed to query, analyze, or report on graph data, making it a more preferable option for non-technical or business facing users who aren’t skilled in GDS but who would benefit massively from working with graph-based data.

Knowing what we’ve just learned about graph technology, graph databases, GDS, and graph analytics, the solution to all our API-related problems might now be more apparent. There are three basic steps that API-developing organizations can take that use the combination of these innovative technologies to fix a multitude of their API problems.

Applying Graph

Step 1: Catalog APIs

Converge data from the enterprise’s disconnected API tools, gateways, API platforms, and other systems into a graph data warehouse to create an API Catalog.

This first step creates an organized, standardized repository of API information that is generally the most comprehensive system of record an organization can possess around their APIs. When paired with internal organizational data, these APIs can be mapped and connected to specific departments, teams, and even individual API owners.

An API Catalog of this scope acts as a single source of truth and can be made accessible to all the stakeholders involved in the API effort.

In addition, as the API Catalog typically remains connected to its data sources, the data is always timely and can be refreshed on an ongoing and automated basis. There is incredible value provided to the API effort at large in even taking this first step.

Step 2: Score APIs

Leverage graph to quickly score APIs in the API Catalog.

With rich API datasets mapped together within the API Catalog, organizations can then begin to score APIs based on their own individual security, management, or strategy requirements. The most common practice is to score APIs based on risk and quality scores.

Risk scoring is based on variables such as authentication methods used, if the API exposes PII information, how often API keys are rotated, if the API is published to an API gateway, etc. Quality scoring is based on usage metrics, the number of consuming apps, the number of methods exposed and the potential for the existence of duplicate APIs.

Other metrics can also be easily customized and the APIs scored as per the organization's needs.

Step 3: Report on APIs

 Use GDS and Graph Analytics to Visualize, Analyze, and Report on APIs

Once API risk and quality concerns have been identified, the organization should immediately take steps to begin remediating these issues.

With graph analytics, this data from the API catalog can auto populate pre-built dashboards designed specifically for tracking the remediation effort. With on-demand access to up-to-the-minute data, stakeholders are provided the perspective they need to identify areas that require improvement and to prioritize resources as necessary.

The API Landscape Assessment

To implement these three steps in approximately 30 days, contact us about getting started with the  API Landscape Assessment. You can download an overview of assessment below.

 ✓ Understand key phases

 ✓ See case study results, by the numbers

 ✓ View out-of-the-box templates and reports