Securing APIs through the lens of NIST
14 April 2023
Staying ahead of the game-changing transformation from monolithic to microservices architecture
By Yonathan Michaeli
It’s often said that API security is different and presents new challenges. However, the way to protect your APIs relies on old and proven principles. In this post we look in detail at how to adopt API security in line with the Cybersecurity Framework of NIST (National Institute of Standards and Technology, a US government agency).
Reconciling ‘opening up’ with ‘shutting down’
We are now witnessing the increasing power and impact of APIs within businesses being compounded by the security challenges of cloud architecture and the transformation from monolithic architecture to microservices. APIs, like the cloud, require us to open our systems to the outside world and challenge our old security approach.
So, what exactly is inside APIs that we should be so worried about?
APIs were designed to help us expand quickly and efficiently, which means that the old approach of minimizing the number of exit and entry points to critical systems is no longer relevant. Instead, APIs go big and wide for open systems – and anyone who wants to stay connected and relevant must jump on board. As a result, a single organization faces an ever-expanding attack surface made up of hundreds, if not thousands, of distinct entry and exit points carrying all its sensitive information and exposing it to the outside world.
The nature of APIs also makes attacks simpler to execute, to more devastating effect. Unlike the conventional cyber kill chain, which consisted of seven stages that attackers had to go through in order to exploit and compromise a system, APIs are simple to exploit and effectively shorten the kill chain from seven to three simple stages: reconnaissance, weaponization, and exploitation. There is no need to install malware, get control of your systems, or complete any activities to take advantage of your systems; with APIs, attackers can gain access to a large amount of sensitive information by making simple requests.
All this presents a new set of difficulties for security operations, the majority of which their organizations are unprepared to address. Dangerous assumptions like “our WAF covers us,” “I have an internal red team,” or (even worse), “we have pen testers” provide a false sense of security. So, what can businesses do to stay ahead of the game and ensure the security of their APIs?
The good news is that the basics have not changed; they simply need to be executed in different ways. The NIST Cybersecurity Framework (CSF) is an excellent approach to evaluate yourself and ensure that you adhere to principles rather than tactics and technologies.
What is the NIST Cybersecurity Framework and how does it apply to API security?
The NIST CSF is a widely recognized best practice apparatus for managing cybersecurity risks. It consists of common cybersecurity activities and outcomes that are relevant to all organizations. Its five functions (Identify, Protect, Detect, Respond, and Recover) represent the key stages of the cybersecurity process, complete with a set of categories and subcategories that define the specific activities and outcomes associated with each function.
So, how we can secure APIs via the lens of the NIST framework, leveraging each function in the framework to meet the needs that arise from APIs?
Identify: Be aware of vulnerabilities as soon as possible, and define the risk of each one
This is the first stage and the important principle at its heart is identifying every asset under your control. This stage is critical for API success since the enormous burden of effectively managing APIs and discovering vulnerabilities before they move to production makes this function the weakest link in the process. To truly identify everything in your API structure, you’ll need to employ automation and implement tools that allow you to inspect the APIs not only in traffic but also in code and in the pre-production environment.
Protect: Put in place controls, policies, and countermeasures to reduce the risks of beforehand
API protection is incredibly critical and difficult to achieve, mostly because organizations have so many different APIs written by so many different developers, mandating continual assessment to ensure that all controls and metrics are in place. Some of the measures that organizations should introduce include implementing suitable authentication techniques, and ensuring that every input received through APIs is validated.
Detect: Implement measures to detect potential cybersecurity incidents in a timely manner
In the context of APIs, organizations can use techniques such as API usage monitoring, access log review, error log review, network traffic monitoring, rate limiting, anomaly detection, third-party monitoring services, and security alerts to detect potential security incidents. These detection techniques should be regularly reviewed and adapted to the new types of attacks threatening APIs.
Respond: Have a plan in place to respond to a security incident, including measures to contain the incident and prevent spread
In the context of APIs, organizations can use incident response procedures such as isolating affected systems and APIs, identifying the cause of the incident and removing malicious actors from the systems. They should also implement additional security controls or countermeasures, and document the incident, reviewing the incident response plan and making any necessary updates. Additionally, having an incident response team that is well-trained, and tested, is crucial for the success of the incident response process.
Recover: Maintain resilience and restore affected capabilities and services
The last CSF stage, in the context of APIs, suggests that organizations will learn from the incidents and anomalies they detected and will remediate them for next time to strengthen its API security posture. Again, to ensure capability to manage the recovery/remediation steps correctly, organizations must rely on automations that will prioritize, notify and alert whenever an action should be taken.
API threats break the mold, but core cybersecurity principles are still valid
Look closer to the sequence of the NIST framework. First, you must identify; that is, learn about everything under your authority, especially the attack surface you expose to the network. Second, you must make every effort to prevent malicious activity from occurring by implementing appropriate controls and measurements in early stages of the API development lifecycle. Following these processes alone will significantly lower the risk of your APIs. Unlike application security, the kill chain we outlined before is shorter in APIs, therefore organizations may not have a second chance. The later CSF stages will assist you in mitigating, and you therefore cannot abandon them. Failing to handle runtime protection and recovery playbooks, for example, would aggravate any bad event that occurs in your systems.
To wrap it all up, history teaches us that principles rarely change and it’s usually the techniques that we need to replace. APIs are extremely different from everything we used to know; they break some of the paradigms that we used to lean on. However, securing APIs can be achieved by staying true to the exact same principles organizations followed while securing their applications over the last 20 years. It’s just a case of adapting to the relevant tools that will allow you to follow those principles, which will lead to securing assets against API threats.
