4 Essential Steps to Implement Your Organization’s API Security
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:
- Enable runtime monitoring and protection capabilities
- Establish a baseline inventory and dynamically update
- Harden APIs per runtime insights
- 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.
