Subscribe to the Salt blog to learn about the latest developments in API Security

Blog Post

4 Essential Steps to Implement Your Organization’s API Security

Jennifer Dignum
Mar 17, 2022

The Salt Security team recently achieved another milestone with the launch of the industry’s first API Security Summit. The day-long educational event featured an amazing lineup, including a CISO panel that highlighted the experiences of six senior security executives and a keynote address delivered by Salt Security customer and Armis Security CISO Curtis Simpson.

Drawing on his own API journey as the former CISO at Sysco and current CISO at Armis, Curtis’s session offered a wealth of practical information for any CISO looking to implement an API security program. According to Curtis, building a successful program depends on moving through the following four critical steps:  

  1. Enable runtime monitoring and protection capabilities
  2. Establish a baseline inventory and dynamically update
  3. Harden APIs per runtime insights
  4. Develop more secure APIs

#1. Enable runtime monitoring and protection capabilities

Curtis had a great analogy to demonstrate the importance of runtime monitoring and protection capabilities – the recent log4j vulnerability. (Get an analysis of the log4j vulnerability in this post by Salt Labs.)

When the vulnerability was discovered, a majority of organizations probably had it running somewhere in their environment, either in custom-built or third party-capabilities; however, before you could determine if you had it and whether or not you were vulnerable, you had to first find it.

But, in the meantime, what did most security leaders do? They bought time. How did they do that? They enabled runtime monitoring and protection capabilities.

Exploitation was already occurring moments after the log4j exposure discovery. Take a moment to consider the lost time from the vulnerability’s disclosure to the assessment of exposure to remediation.

And that’s just one exposure. With APIs, security leaders face a breadth of exposures that potentially exist across a multitude of services and solutions within their environments. Curtis explained that is why enabling runtime monitoring and protection capabilities around APIs is absolutely essential.

In Curtis’s own words:

“Most environments are very unfamiliar with the APIs that exist, let alone the exposures or attempts to exploit these APIs that might be playing out in our landscape. It’s incredibly important to buy ourselves some time to do that analysis. It’s very important to focus on that runtime monitoring and protection first.”

#2. Establish a baseline inventory and dynamically update

You have to build a baseline inventory. Curtis pointed out that today’s API inventories are incomplete, regardless of whether they’ve been created via files, catalogs, or gateways.  All these means of producing inventories rely on people for administration. In a fast-paced development environment, this work becomes an administrative chore that may — or may not — get done. And even when it’s done, it’s likely to be done poorly. You simply cannot rely on people to establish the inventory.

Curtis elaborates:

“APIs are being built rapidly. You may see 10s of APIs over the course of a week pop up within an environment. The likelihood that all of those APIs have been inventoried, and established within a gateway or catalog, is VERY low — maybe 60 to 70 percent. But — as I think about inventories — I look at 60 to 70 percent as almost the equivalent of being zero. With a partial picture, it is partial remediation, and it probably means I’ve been ineffective.”

Without a complete picture, you can’t understand your full business exposure and impact or prioritize risk management.

Moreover, according to Curtis, an inventory should be systematically generated and continuously and dynamically updated. At Sysco, APIs were being built every single day, and they were constantly pushed into test, staging, and production environments. Without a continuous inventory, you lack full visibility into risk and exposure, as well as visibility into how the business interacts with systems and services.

#3. Harden APIs leveraging runtime insights

After you’re protected with runtime security and have a dynamic inventory in place, you can look at using runtime insights to harden APIs. APIs are not just straight code where you can look for code flaws in the dev/test phase — need to see the APIs in action to identify logic flaws in those APIs.

To identify logic flaws, you need to constantly monitor APIs to understand what normal vs. abnormal looks like. Bad actors will need to do a lot of reconnaissance to look for logic flaws. They may have minor successes along the way, and you can use those findings to identify areas where you can improve security in your APIs, such as looking for areas where APIs are exposing sensitive data.

According to Curtis:

“Things get complicated very quickly when you’re looking at many, many APIs. You also must look at exploitation opportunities and exposures, and prioritize and act based on that information. If you’re developing and dynamically updating your inventory, you’re also able to dynamically update those insights into your level of exposure. This allows you to focus on the right things, such as getting tickets over to developers to resolve them.”

#4. Develop more secure APIs.

Applying shift-left principles, where you’re addressing security gaps earlier in the development cycle, delivers good benefits. However, as security leaders think about developing more secure APIs, they must also realize that they need to start shifting other capabilities left first. They need to shift foundational capabilities – including code scanning capabilities in the environment, vulnerability scanning, remediation capabilities and such.

While Curtis acknowledged the urgent need to get these capabilities in place for risk management, he also noted that developers cannot take on all shift-left requests at once. He advised security leaders to be considerate of corporate politics when it comes to shifting left:

“We can’t shift everything to the developers to R&D left at the same time because we also have to be cognizant of our political capital. This is both about tech and politics within most of our organizations.”

In addition to the challenge of overloading developers, Curtis also noted the overall limitations of the value of shift-left security measures. He called out that runtime protection provides the greatest and most immediate value and that shift-left capabilities will always be more limited in their protections because they can’t identify the business logic vulnerabilities that surface when APIs are exercised.

Finally, to help develop more secure APIs, leaders should feed what they’re learning from API tools back into developer training. They need to share their own learnings and start ongoing educational sessions run by development leaders and training packages for these groups. Development, R&D and DevOps teams are always trying to become more effective with the tools available to them. They’re constantly reeducating their teams as they are evolving through digital transformations. Security leaders must take advantage of that.

A holistic strategy for API security is critically important to develop, and these guidelines can provide a roadmap for security teams to build out their plans.

We invite you to listen to Curtis’s session in its entirety and all the sessions in the API Security Summit. If you’d like to learn how leading Fortune and Global 500 enterprises are securing their APIs and critical company and customer data using the Salt Security API Protection Platform, contact us.


Salt Security Blog

Sign up for the Salt Newsletter for the latest resources and blog posts.

June 18, 2024

Salt Labs
Research Team

Salt Labs

Increasing API Traffic, Proliferating Attack Activity and Lack of Maturity: Key Findings from Salt Security’s 2024 State of API Security Report

The latest Salt Security State of API Security Report is out now, and we’re thrilled to give a little sneak peek of its contents.

Read more

June 12, 2024

Elad Hoffer
Head of Product R/T Protection


Salt Security Leading the Way in AI-Driven API Security for Next-Generation Threat Protection and Attacker Insights

Learn how the recent introduction of advanced LLM-driven attacker insights further solidifies Salt's position as a leader in API security solutions.

Read more

June 7, 2024

Eric Schwake
Head of Product Marketing

A Salt Security Perspective on the 2024 Gartner® Market Guide for API Protection

Salt Security's API Protection Platform is AI-infused and designed to address the challenges outlined in the Gartner report.

Read more

Download this guide for advice on evaluating key capabilities in API Security

Learn everything you need to know to keep your APIs secure

Get the guide